Why after two months is this problem still happening?
The key reason one would pay extra per hour to run SLES instancing in EC2 is so that high quality updates can be delivered from SUSE repositories. And yet using SLES on EC2 seems to result in this feature getting disabled.
And on a related note, why has zypper been designed to ever automatically REMOVE repositories? It is rather disappointing to run “zypper up” and see a long list of SUSE repositories automatically removed PERMANENTLY for no justified reason. This is a very NOT robust and very fragile design. I am running SLES instances on EC2 and automatically billed.
Could you please provide more details? I understand the frustration, but voicing them without providing details does not help in getting the issue addressed.
There have been many changes to infrastructure that provides the updates in the last 2 month and new images have been released to take advantage of the new infrastructure. Older images that are still public and connect to the old infrastructure may still exhibit the problem, it is simply not possible to re-release older images. A plan to phase out the old infrastructure is still being worked out.
If you launch the latest images you should not encounter this problem. In any event details such as the region where this occurs, the ami-ID from which the instance was launched are always needed in order to provide any help.
The instance I witnessed this problem on was ami-d8c940b0 (amazon/suse-sles-11-sp3-v20141105-pv-mag-i386). It is the newest (Nov 5) ami listed in the EC2 launch wizard for (PV, 32-bit, Magnetic) SUSE Linux (Community AMIs). There are more details in the link above to the EC2 forum thread on the same topic.
I am no longer attempting to launch SUSE instances on EC2 and instead am now migrating to CentOS 7.
The real issue to me is a deeper issue of what SUSE is charging extra money for on EC2 vs the service level actually delivered.
I was happily paying extra money to run SUSE Linux Enterprise (both VMs locally and servers in EC2) under the impression that the infrastructure for package repositories with important updates was reliable. I don’t think I would have chosen to pay extra money to run SUSE Linux Enterprise knowing what service level the package repository infrastructure was actually going to achieve in reality.
I was surprised when “zypper up” was not actually updating my SLES 11 server after a week of shellshock hitting the news. I was even more surprised when I read your post that old images were using old infrastructure and that old infrastructure was no longer supported and I would just have to launch a new server with a different ami. This week, with continued problems from the old to new infrastructure, my surprise has turned into feeling bad for you guys in having infrastructure that seems to work so poorly.
I imagine there are some difficult and tough decisions that you guys at SUSE have had to make in terms of infrastructure support level. I won’t question those business decisions, but I do want to share a soon-to-be-former customer’s experience and perspective. Perhaps it’s something management should hear.
In summary, having the “old” infrastructure fail to work on "old"images has convinced me to stop paying extra money for SLE and instead migrate to CentOS, both on local VMs and servers in the EC2. I understand that the “old” infrastructure and “old” images have been abandoned as “old”. But what motivated me to pay extra money was the hope of a service level that would keep my servers updated. SLES 11 SP3 servers created less than a year ago I was expecting to NOT be too old.
I hope the new acquisition pumps some new energy and resources into making SUSE Linux a better alternative to RedHat and Ubuntu. Best wishes.
Yes, we did have another certificate snafu, but this has been fixed, and it was a separet incident from the one mentioned in the initial post.
Sorry to hear that, I really believe that if were to migrate to a 64 bit image that uses the new infrastructure you would have a great experience.
[QUOTE=castedo;25310]The real issue to me is a deeper issue of what SUSE is charging extra money for on EC2 vs the service level actually delivered.
I was happily paying extra money to run SUSE Linux Enterprise (both VMs locally and servers in EC2) under the impression that the infrastructure for package repositories with important updates was reliable. I don’t think I would have chosen to pay extra money to run SUSE Linux Enterprise knowing what service level the package repository infrastructure was actually going to achieve in reality.[/QUOTE]
Well in reality it is receiving a lot of attention. It just happens that things do get old and at some point we have to switch, like an old car. At some point people buy new cars because old ones no longer work the way they used to. In this case the old infrastructure is very difficult to maintain and thus bad things happen. This is why we have implemented a new infrastrcuture that has redundency built in, has fully automated access controls, plus other stuff. Additionally with there not being any advantage to running 32 bit instances in the cloud the decision was made not to transition 32 bit images to the new infrastrcuture. There will be a post about deprecation of 32 bit images in the not too distant future.
[QUOTE=castedo;25310]I was surprised when “zypper up” was not actually updating my SLES 11 server after a week of shellshock hitting the news. I was even more surprised when I read your post that old images were using old infrastructure and that old infrastructure was no longer supported and I would just have to launch a new server with a different ami. This week, with continued problems from the old to new infrastructure, my surprise has turned into feeling bad for you guys in having infrastructure that seems to work so poorly.
I imagine there are some difficult and tough decisions that you guys at SUSE have had to make in terms of infrastructure support level. I won’t question those business decisions, but I do want to share a soon-to-be-former customer’s experience and perspective. Perhaps it’s something management should hear.[/QUOTE]
Thanks for sharing and I understand the frustration. Too bad you do not have the opportunity to try out the latest 64 bit images that access the new infrastructure.
Well there is a migration path for 64 bit server, just not for 32 bit, sorry. As mentioned there is no advantage to running a 32 bit image, all 32 bit code runs equally well if not better in a 64 bit environment and the cost per hour in the cloud are the same.