Re: [Openstack] Best approach for deploying Essex?
+1 on the Ubuntu 12.04 Precise and Essex. Whilst there are other methods and OS of choice, given you've been using 11.10 - 12.04 is the natural home for it. The betas of Precise are rock-solid and can vouch for the Ubuntu packaging following quite quickly behind the devs. I highly recommend this approach. Kev On 3 April 2012 20:02, Lillie Ross-CDSR11 ross.lil...@motorolasolutions.com wrote: Hi Adam, Thanks for the update. Actually, I'm in the process of reading about your testing and integration framework for Openstack ( http://ubuntuserver.wordpress.com/2012/02/08/704/) as I write this. Yes, Keystone integration seemed to be the big bugaboo in the Ubuntu/Diablo release. I've successfully got everything authenticating with keystone in our current deployment, but as you well know, this precludes using S3 bindings with Swift, and you must use the Openstack glance client to bundle/upload images. This had me pulling my hair out in the early stages. Today I've spun up 3 generic 11.10 servers that I'm planning on testing the next Ubuntu release and Openstack packages. Should I start my testing with the beta1 release of 12.04LTS? In particular I'm interested in seeing and understanding the process of migrating my existing installation and configs to the new release. Once I'm satisfied that I understand everything (not possible) in the new release, I can migrate our operational cloud in a couple of days. Also, what's the best place to keep abreast on the Ubuntu/Canonical integration of openstack? The Ubuntu Wiki? Mailing list? Thanks again, Ross On Apr 3, 2012, at 1:21 PM, Adam Gandelman wrote: On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. Hey Ross- I can say that the Ubuntu precise packages have been kept relatively in-sync with each components' trunk git repository this cycle. We've made a concerted effort to do weekly snapshot uploads of all Openstack components into the Precise archive starting from the beginning of the Essex+Precise dev cycles. We've also maintained our own trunk PPA (updated continously) around which we center our testing efforts. Now that we're nearing the release of Essex, we've been ensuring the release candidates hit our archive as soon as they are released. As soon as Essex final hits, it'll be uploaded into Ubuntu and give any users who care the remainder of the Ubuntu dev cycle (~1 month) to test and identify issues before LTS ships. Re: deployment assumptions. Last cycle, we were caught off-guard by Keystone's last-minute inclusion into Openstack core and the dependencies this introduced (dashboard especially) It's not that we were making assumptions about how Openstack Diablo should be deployed, just that there was no way we could shoe-horn a new component into the release so late in the game. This time around, a similar curve ball was thrown our way with the Keystone Lite rewrite, but we were able to get this sorted on our end relatively quickly to ensure pending security reviews and main inclusion processes for Keystone weren't blocked. We're making very few assumptions going into LTS and hope to provide as-close-to-pure Essex experience as any. I can only think of a few patches we're carrying, and there are only two default configuration files we ship that differ from those you'd find in the git repos [2]. Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. Hope that helps, and of course we welcome your testing and bug reports! -Adam [1] We ship a default nova.conf that configures some Ubuntu defaults: defaults to libvirt compute, uses nova-rootwrap for sudo shell execution (requested by our security team), uses tgt iscsi initiator instead of ietd (tgt is supported in our main archive, ietd is not). Our default Keystone config defaults to the SQL catalog backend instead of the default templated file, though I think SQL catalog is the new default in folsom. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
Re: [Openstack] Best approach for deploying Essex?
On Tue, Apr 3, 2012 at 2:21 PM, Adam Gandelman ad...@canonical.com wrote: On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. [snip] Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. DreamHost is interested! It'd be great if you could do this :-) d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Best approach for deploying Essex?
Hi Kevin, I'm in the process of looking at the Ubuntu packages. I've booted up 3 12.04 instances in our existing cloud and have installed the Ubuntu packages. I'm playing with the new keystone 'lite' service as I write this. In fact, I'm looking at your script to bootstrap keystone versus the script installed via the package in /usr/share/keystone. So far so good, other than some iptable hacks that will be needed (I believe, but haven't looked closely) to let these instances to see their underlying public ip addresses (no problem, obviously seeing their private vlan address). Thanks for your inputs. Regards, Ross On Apr 4, 2012, at 4:20 AM, Kevin Jackson wrote: +1 on the Ubuntu 12.04 Precise and Essex. Whilst there are other methods and OS of choice, given you've been using 11.10 - 12.04 is the natural home for it. The betas of Precise are rock-solid and can vouch for the Ubuntu packaging following quite quickly behind the devs. I highly recommend this approach. Kev On 3 April 2012 20:02, Lillie Ross-CDSR11 ross.lil...@motorolasolutions.commailto:ross.lil...@motorolasolutions.com wrote: Hi Adam, Thanks for the update. Actually, I'm in the process of reading about your testing and integration framework for Openstack (http://ubuntuserver.wordpress.com/2012/02/08/704/) as I write this. Yes, Keystone integration seemed to be the big bugaboo in the Ubuntu/Diablo release. I've successfully got everything authenticating with keystone in our current deployment, but as you well know, this precludes using S3 bindings with Swift, and you must use the Openstack glance client to bundle/upload images. This had me pulling my hair out in the early stages. Today I've spun up 3 generic 11.10 servers that I'm planning on testing the next Ubuntu release and Openstack packages. Should I start my testing with the beta1 release of 12.04LTS? In particular I'm interested in seeing and understanding the process of migrating my existing installation and configs to the new release. Once I'm satisfied that I understand everything (not possible) in the new release, I can migrate our operational cloud in a couple of days. Also, what's the best place to keep abreast on the Ubuntu/Canonical integration of openstack? The Ubuntu Wiki? Mailing list? Thanks again, Ross On Apr 3, 2012, at 1:21 PM, Adam Gandelman wrote: On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. Hey Ross- I can say that the Ubuntu precise packages have been kept relatively in-sync with each components' trunk git repository this cycle. We've made a concerted effort to do weekly snapshot uploads of all Openstack components into the Precise archive starting from the beginning of the Essex+Precise dev cycles. We've also maintained our own trunk PPA (updated continously) around which we center our testing efforts. Now that we're nearing the release of Essex, we've been ensuring the release candidates hit our archive as soon as they are released. As soon as Essex final hits, it'll be uploaded into Ubuntu and give any users who care the remainder of the Ubuntu dev cycle (~1 month) to test and identify issues before LTS ships. Re: deployment assumptions. Last cycle, we were caught off-guard by Keystone's last-minute inclusion into Openstack core and the dependencies this introduced (dashboard especially) It's not that we were making assumptions about how Openstack Diablo should be deployed, just that there was no way we could shoe-horn a new component into the release so late in the game. This time around, a similar curve ball was thrown our way with the Keystone Lite rewrite, but we were able to get this sorted on our end relatively quickly to ensure pending security reviews and main inclusion processes for Keystone weren't blocked. We're making very few assumptions going into LTS and hope to provide as-close-to-pure Essex experience as any. I can only think of a few patches we're carrying, and there are only two default configuration files we ship that differ from those you'd find in the git repos [2]. Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. Hope that helps, and of course we
Re: [Openstack] Best approach for deploying Essex?
On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. Hey Ross- I can say that the Ubuntu precise packages have been kept relatively in-sync with each components' trunk git repository this cycle. We've made a concerted effort to do weekly snapshot uploads of all Openstack components into the Precise archive starting from the beginning of the Essex+Precise dev cycles. We've also maintained our own trunk PPA (updated continously) around which we center our testing efforts. Now that we're nearing the release of Essex, we've been ensuring the release candidates hit our archive as soon as they are released. As soon as Essex final hits, it'll be uploaded into Ubuntu and give any users who care the remainder of the Ubuntu dev cycle (~1 month) to test and identify issues before LTS ships. Re: deployment assumptions. Last cycle, we were caught off-guard by Keystone's last-minute inclusion into Openstack core and the dependencies this introduced (dashboard especially) It's not that we were making assumptions about how Openstack Diablo should be deployed, just that there was no way we could shoe-horn a new component into the release so late in the game. This time around, a similar curve ball was thrown our way with the Keystone Lite rewrite, but we were able to get this sorted on our end relatively quickly to ensure pending security reviews and main inclusion processes for Keystone weren't blocked. We're making very few assumptions going into LTS and hope to provide as-close-to-pure Essex experience as any. I can only think of a few patches we're carrying, and there are only two default configuration files we ship that differ from those you'd find in the git repos [2]. Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. Hope that helps, and of course we welcome your testing and bug reports! -Adam [1] We ship a default nova.conf that configures some Ubuntu defaults: defaults to libvirt compute, uses nova-rootwrap for sudo shell execution (requested by our security team), uses tgt iscsi initiator instead of ietd (tgt is supported in our main archive, ietd is not). Our default Keystone config defaults to the SQL catalog backend instead of the default templated file, though I think SQL catalog is the new default in folsom. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Best approach for deploying Essex?
Hi Adam, Thanks for the update. Actually, I'm in the process of reading about your testing and integration framework for Openstack (http://ubuntuserver.wordpress.com/2012/02/08/704/) as I write this. Yes, Keystone integration seemed to be the big bugaboo in the Ubuntu/Diablo release. I've successfully got everything authenticating with keystone in our current deployment, but as you well know, this precludes using S3 bindings with Swift, and you must use the Openstack glance client to bundle/upload images. This had me pulling my hair out in the early stages. Today I've spun up 3 generic 11.10 servers that I'm planning on testing the next Ubuntu release and Openstack packages. Should I start my testing with the beta1 release of 12.04LTS? In particular I'm interested in seeing and understanding the process of migrating my existing installation and configs to the new release. Once I'm satisfied that I understand everything (not possible) in the new release, I can migrate our operational cloud in a couple of days. Also, what's the best place to keep abreast on the Ubuntu/Canonical integration of openstack? The Ubuntu Wiki? Mailing list? Thanks again, Ross On Apr 3, 2012, at 1:21 PM, Adam Gandelman wrote: On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. Hey Ross- I can say that the Ubuntu precise packages have been kept relatively in-sync with each components' trunk git repository this cycle. We've made a concerted effort to do weekly snapshot uploads of all Openstack components into the Precise archive starting from the beginning of the Essex+Precise dev cycles. We've also maintained our own trunk PPA (updated continously) around which we center our testing efforts. Now that we're nearing the release of Essex, we've been ensuring the release candidates hit our archive as soon as they are released. As soon as Essex final hits, it'll be uploaded into Ubuntu and give any users who care the remainder of the Ubuntu dev cycle (~1 month) to test and identify issues before LTS ships. Re: deployment assumptions. Last cycle, we were caught off-guard by Keystone's last-minute inclusion into Openstack core and the dependencies this introduced (dashboard especially) It's not that we were making assumptions about how Openstack Diablo should be deployed, just that there was no way we could shoe-horn a new component into the release so late in the game. This time around, a similar curve ball was thrown our way with the Keystone Lite rewrite, but we were able to get this sorted on our end relatively quickly to ensure pending security reviews and main inclusion processes for Keystone weren't blocked. We're making very few assumptions going into LTS and hope to provide as-close-to-pure Essex experience as any. I can only think of a few patches we're carrying, and there are only two default configuration files we ship that differ from those you'd find in the git repos [2]. Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. Hope that helps, and of course we welcome your testing and bug reports! -Adam [1] We ship a default nova.conf that configures some Ubuntu defaults: defaults to libvirt compute, uses nova-rootwrap for sudo shell execution (requested by our security team), uses tgt iscsi initiator instead of ietd (tgt is supported in our main archive, ietd is not). Our default Keystone config defaults to the SQL catalog backend instead of the default templated file, though I think SQL catalog is the new default in folsom. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
