I found my mistake I had to specify the "Feed API user" in the API Key configuration.

Try stopping the service before running the installer, then it should work.

This appears to be a bug with the ProxyRequest property, i.e. if it's true (the default), the response variable is not set. The tracking issue for this is here: https://github.com/Inedo/inedox-inedocore/issues/91

At of ProGet 5.1, that's the only way. We may add support for this in a future version if we get more feature requests

It does not exist yet, I've filed BM-3326 to add it in v6.1.2

The steps are outlined here: https://inedo.com/support/documentation/proget/advanced/cloud-storage

Thank you Stijn Peeters, you are spot on! After I performed the migration on our Default feed this morning all packages are showing up as expected when searched for - wahoo! Thanks again!

You can safely do all of those things :)

I have had issues in the not too distant past, maybe 3-6 months ago upgrading one of my installs of Otter to the latest version, 2.0.9 if memory servers. I would concur that the installs/upgrades could use some love. There definitely should be a 'cleanup' tool to remove all traces of Inedo installs. Ron, I wouldn't give up on using the products. Maybe you can spin up a vm to try this out on as well?

Thanks. That solved it.

Hello Eric, I think Docker requires at least one . in the hostname, and it's trying to access the default Docker hub. Another way that might work would be to add the port number to the hostname: <server name>:443/<feed name>/library/redis (the library part is optional to match the Docker hub, so <server name>:443/<feed name>/redis should also work)

Hello Scott, This is done for 1-part repository names to match the behavior of Docker Hub. You should still be able to access the container without library/; that is, this should also work: <proget_server>:80/<container_feed>/<container_name>:<tag>

Oh I see, you're migrating a legacy NuGet feed! Sorry I misunderstood. With the number of packages you have, a database transaction will put a strain on your database server, which is most certainly where the problem is. Instead, why not back up the database beforehand, then run the migration without verbose logging and a transaction.

Got it! Then this would likely fall inline with an upcoming major feature, and the communication between Otter servers ("main" and "secondary" as you describe) would be done using API/HTTPS/Web requests, in a direction of ("Publisher" -> "Listener").

Basically, you would create a Git-based raft in both instances of Otter, and have them both point to the same Git repository. The biggest gotcha would be that both instances can potentially update the raft, but as long as you're aware of that it wouldn't be a problem.

I see; in this cases, go to Advanced Settings, and change the base url property.

You can edit the connection string using Inedo Hub; it should be listed right under the Configuration tab. Note you will need to stop/start the service and web app afterwards. Might be best to stop both beforehand, however, so you don't have two potentially active databases.

Yes, ProGet supports this. However, you will need a paid version of Chocolatey in order to do that https://chocolatey.org/faq#i-would-like-to-be-able-to-offer-my-non-admin-desktop-users-an-option-for-self-service-type-of-installations

Just to close this post: this was fixed in InedoCore 1.0.12, after diagnosing the issue on a ticket (EDO-5683).

Are you saying you can't create a job from a template? The main purpose of the template is: Instead of specifying the plan and server targeting each time you create a job, you can create a job template that will specify these for you. The template can also specify variables that will need to be entered when the job is run. While this can save you a few steps when running jobs, the biggest benefit of job templates is that, once defined, you can now trigger jobs using a the job trigger API. This will allow you to use nearly any other tool, such as Jenkins or a PowerShell script, to trigger an Otter orchestration job. However, we plan to expand it to be a lot more useful with better variable selection, etc.