Closed harshavardhana closed 2 years ago
baronfel
commented
2 years ago Hello! We're actively pushing packages today for the 6.0.301 SDK release and associated runtime packages and there's a delay in that process. Please follow https://github.com/dotnet/core/issues/7536 for the latest details.
MichaCo
commented
2 years ago @baronfel is there any way to prevent those kind of errors? I found some of my Azure VMs in Azure Batch not starting up with a failed startup task (which installs dotnet 6) That's production processing we rely on.
I also never encountered something like that before NET6. We are running the same stuff for ~4 years now, started with netcore2.1
I guess it did recover after a while, but still, scary stuff ^^
Thanks, Michael
baronfel
commented
2 years ago I can't speak to your particular setup, but it's fairly common to split the 'install prerequisites' step from the 'start up an instance' step of your deployment solution. For example, in container-based scenarios you'd have a container image base layer that was responsible for getting .NET 6 installed, then the application is a separate layer. In this way you separate the concerns. Something analogous to that may be available for your hosting solution.
Another option may be to pin the version of the packages that you are using - if you specify exact version numbers to your runtime packages, the act of pushing new packages won't impact your solution.
MichaCo
commented
2 years ago Thanks for the reply @baronfel, makes sense. I tried to prevent creating custom images for azure batch (to not deal with our own container registry). But yes, that would probably be the best way to prevent any surprises.
harshavardhana
commented
2 years ago I can't speak to your particular setup, but it's fairly common to split the 'install prerequisites' step from the 'start up an instance' step of your deployment solution. For example, in container-based scenarios you'd have a container image base layer that was responsible for getting .NET 6 installed, then the application is a separate layer. In this way you separate the concerns. Something analogous to that may be available for your hosting solution.
Another option may be to pin the version of the packages that you are using - if you specify exact version numbers to your runtime packages, the act of pushing new packages won't impact your solution.
My expectation is very simple here there is an official way to install things that broke, next I tried to pin the versions that said those versions are no longer available?
The solution to this is please don't break the DEB pushes, don't push partial changes - all changes including deps must be pushed together.
FWIW this issue has been resolved already as the necessary packages made its way to relevant mirrors.
when can we have MSFT not break .Net SDKs on such a regular basis?
Originally posted by @harshavardhana in https://github.com/dotnet/docs/issues/29349#issuecomment-1155714476