Hi @nuno-guerreiro-rosa_9280,

Sorry for the late notice but the release of 5.3.14 was pushed back to later today. I'm sorry if this caused inconvieninces for you.

Thanks,
Rich

Hi @srbauti_9412,

The best solution to this would be to create a new NuGet feed that uses a self-connector to connect back to your existing NuGet feeds. You can then use the connector filters to handle filtering by your package name format.

Thanks,
Rich

Hi @aneequaye_1868 & @informatique_1703,

I may have found a potential cause for this. Can you verify a feed folder exists in your /proget-packages/? You should see proget-packages/.docker/common and/or /proget-packages/.docker/F<Feed ID> (ex: proget-packages/.docker/F1).

Thanks,
Rich

Hi @philipp-grathwohl_1687,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making an HTTP GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to HTTP POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @toni-wenzel_6045,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making a GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @csyy321_2677,

What version of CENTOS is your Docker host running on? Can you also tell me what version of docker is installed?

Thanks,
Rich

Hi @nicolas-morissette_6285,

No problem! If you are still having issues after you reach out, please feel free to reply back to this topic.

Thanks,
Rich

Hi @nicolas-morissette_6285,

I believe Azure DevOps NuGet feeds depricated alternate credentials back in March and they will only support PATs moving forward. Here is an article on the deprication Azure DevOps Will No Longer Support Alternate Credentials.

I know you were sepcifying your Azure AD username and password, but I believe Microsoft treated those as an alternate method because the normal Azure AD login requires OAuth based logins moving forward. The PAT was their solution for adding a way to authenticate without requiring a user to intervene in the login process.

Thanks,
Rich

Hi @aneequaye_1868,

Would you be able to run an ls -l to check your folder permissions? I have seen some recent issues that linux reports back some weird errors when a folder doesn't have the proper read/write/delete permissions.

Thanks,
Rich

Hi @msimkin_1572,

What feed types are you using? Some of our feed types have a built-in process to verify this for you.

Thanks,
Rich

Hi @informatique_1703,

Thanks for clarifying that for me. The issue did exist in 5.2.32, but the scenario to recreate it was different. Now that I understand that the blob is not in the database (I apologize for missing that before), I don't think the clear cache issue caused this. Just to verify, when you searched for the blob digest in the database, did you limit it only to that FeedId? Or did you just search for any blobs with that digest? Could you send me the SQL query you used? Also, can you check to see if this feed is configured to use shared storage? You can find that by navigating to the Manage Feed page and selecting the Storage & Retention tab, then click the Configure link to the right of Blob Storage.

Thanks,
Rich

Hi @informatique_1703,

I'm sorry for the confusion. If the clear cache was ran in 5.3.12 or lower, that may have removed the shared blob from your storage location, but left the link in the database. Upgrading to 5.3.13 removes the possibility of deleting a blob that is still in use from your storage location. Can you verify if 2622b3cbec4c3f908fde9a413e48eca0145887f5c0719a4384d2e862978270b0 exists in your storage location? You can also see by going to an image that has that blob layer and looking at the 'Layers` tab. If it has a red exclimation mark next to the layer, then it was most likely removed from the storage location.

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @informatique_1703,

I think I see the issue here. There was a bug, PG-1832, in the clear docker connector cache that was patched in ProGet 5.3.13. The issue that was happening is that the clear cache would fail when a blob was shared between a chached image and a local image. The side affect is that it would delete the blob from the storage location, but it fail to remove the reference from the database. This causes our API to think the blob exists but then fails to find it on the disk.

This is why a new feed will work because you are pushing the new layer up that doesn't already exist in the feed. If you copy the blob named 2622b3cbec4c3f908fde9a413e48eca0145887f5c0719a4384d2e862978270b0 from the new feed storage location to the old feed storage location, then most likely the push will work. You can find the storage location by checking the Storage.PackagesRootPath, Storage.DockerRepositoryLibrary, and Storage.DockerBlobStorageLibrary in Administration -> Advanced Settings. You may also need to check in the Manage Feed settings for a registry level storage or if your registry is using Shared Storage.

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

The docker login issue has been scheduled to release in ProGet 5.3.14 on October 30, 2020. I will let you know if anything changes.

Thanks,
Rich

Hi @informatique_1703,

Are you using any docker connectors on this feed? If so, have you cleared the cache on these recently? Also, if you create a new feed, then push the image, does that error happen?

Thanks,
Rich

Hi @informatique_1703,

Would you be able to switch to the progetmono image and see if you still have this issue? I would like to rule out .NET Core as a cause.

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

Thank you for all the extra information. I believe I have found the culprit, but I will need to work with the team internally to determine the proper fix. It looks like the call to /v2/ that tells docker it needs to authenticate is not returning the proper headers. This is a .NET Core only issue.

The reason that Docker is the only feed affected now is because of how the docker client/api works. It basically walks through the process of an API looking for the API to return very specific errors and headers. That is how the client knows what to do next. In the case of auth, it will first hit /v2/ and look for a 401 unauthroized and some specific headers to tell it to redirect to /v2/_auth and to pass an Authorize header. That is not happening. I will update when we have scheduled this for release.

Thanks,
Rich

Hi @informatique_1703,

Currently, the only way to transfer all docker images automatically between feeds is by using feed replication, which requires an enterprise license.

One manual option is to promote the image from your old feed to your new feed. You would need to do that on each image manually though.

Is your ProGet instacnce installed on Windows or are you using a Docker image based version of ProGet?

Thanks,
Rich

Hi @philippe-camelio_3885,

Just to verify, you are running the command line as an administrator correct? Can you also please verify the user you are trying to run the service as has the correct password and is not locked out on the domain?

Thanks,
Rich