Quote Originally Posted by castedo View Post
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.

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.


Quote Originally Posted by castedo View Post
I am no longer attempting to launch SUSE instances on EC2 and instead am now migrating to CentOS 7.

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 Originally Posted by castedo View Post
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.

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 Originally Posted by castedo View Post
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.

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.



Quote Originally Posted by castedo View Post
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.

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.