Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
On Tue, Jan 28, 2014 at 9:05 PM, Robert Collins robe...@robertcollins.net wrote: So, thoughts... I do see this as useful, but I don't see an all-in-one overcloud as useful for developers of tuskar (or pretty much anything). It's just not realistic enough. True. I do however see the all in one useful to test that your deployment infrastructure is working. PXE is setup right, iscsi is going to work, etc. Networking, on some level, is working. No need to start two vm's to see it fail twice. I'm pro having downloadable images, long as we have rights to do that for whatever OS we're based on. Ideally we'd have images for all the OSes we support (except those with restrictions like RHEL and SLES). Your instructions at the moment need to be refactored to support devtest_testenv and other recent improvements :) Indeed, my goal would be to work what I have into devtest, not the other way around. BTW the MTU note you have will break folks actual environments unless they have jumbo frames on everything- I *really wouldn't do that* - instead work on bug https://bugs.launchpad.net/neutron/+bug/1270646 Good point, I wasn't actually sure if what I was seeing was that bug or not. I'll look into it. Thanks, I appreciate the feedback. -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
Sorry to revive an old thread, but I've updated these images based on the icehouse-2 milestone. I've updated the instructions with the new download links: https://gist.github.com/slagle/981b279299e91ca91bd9 To reiterate, the point here is to give people an easier on ramp to getting a tripleo setup. This is especially important as more developers start to get involved with Tuskar in particular. There is definitely a lot of value in going through the whole devtest process yourself, but it can be a bit daunting initially, and since this eliminates the image building step with pre-built images, I think there's less that can go wrong. Given Clint's earlier feedback, I could see working the seed vm back into these steps and getting the config drive setup into incubator so that everyone that goes through devtest doesn't have to have a custom seed. Then giving folks the option to use prebuilt vm images vs building from scratch. Also, given the pending patches around an all in one Overcloud, we could work the seed back into this, and still be at just 3 vm's. Any other feedback welcome. On Tue, Dec 24, 2013 at 11:50 AM, James Slagle james.sla...@gmail.com wrote: I built some vm image files for testing with TripleO based off of the icehouse-1 milestone tarballs for Fedora and Ubuntu. If folks are interested in giving them a try you can find a set of instructions and how to download the images at: https://gist.github.com/slagle/981b279299e91ca91bd9 The steps are similar to the devtest process, but you use the prebuilt vm images for the undercloud and overcloud and don't need a seed vm. When the undercloud vm is started it uses the OpenStack Configuration Drive as a data source for cloud-init. This eliminates some of the manual configuration that would otherwise be needed. To that end, the steps currently use some different git repos for some of the tripleo tooling since not all of that functionality is upstream yet. I can submit those upstream, but they didn't make a whole lot of sense without the background, so I wanted to provide that first. At the very least, this could be an easier way for developers to get setup with tripleo to do a test overcloud deployment to develop on things like Tuskar. -- -- James Slagle -- -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
So, thoughts... I do see this as useful, but I don't see an all-in-one overcloud as useful for developers of tuskar (or pretty much anything). It's just not realistic enough. I'm pro having downloadable images, long as we have rights to do that for whatever OS we're based on. Ideally we'd have images for all the OSes we support (except those with restrictions like RHEL and SLES). Your instructions at the moment need to be refactored to support devtest_testenv and other recent improvements :) BTW the MTU note you have will break folks actual environments unless they have jumbo frames on everything- I *really wouldn't do that* - instead work on bug https://bugs.launchpad.net/neutron/+bug/1270646 -Rob On 29 January 2014 11:33, James Slagle james.sla...@gmail.com wrote: Sorry to revive an old thread, but I've updated these images based on the icehouse-2 milestone. I've updated the instructions with the new download links: https://gist.github.com/slagle/981b279299e91ca91bd9 To reiterate, the point here is to give people an easier on ramp to getting a tripleo setup. This is especially important as more developers start to get involved with Tuskar in particular. There is definitely a lot of value in going through the whole devtest process yourself, but it can be a bit daunting initially, and since this eliminates the image building step with pre-built images, I think there's less that can go wrong. Given Clint's earlier feedback, I could see working the seed vm back into these steps and getting the config drive setup into incubator so that everyone that goes through devtest doesn't have to have a custom seed. Then giving folks the option to use prebuilt vm images vs building from scratch. Also, given the pending patches around an all in one Overcloud, we could work the seed back into this, and still be at just 3 vm's. Any other feedback welcome. On Tue, Dec 24, 2013 at 11:50 AM, James Slagle james.sla...@gmail.com wrote: I built some vm image files for testing with TripleO based off of the icehouse-1 milestone tarballs for Fedora and Ubuntu. If folks are interested in giving them a try you can find a set of instructions and how to download the images at: https://gist.github.com/slagle/981b279299e91ca91bd9 The steps are similar to the devtest process, but you use the prebuilt vm images for the undercloud and overcloud and don't need a seed vm. When the undercloud vm is started it uses the OpenStack Configuration Drive as a data source for cloud-init. This eliminates some of the manual configuration that would otherwise be needed. To that end, the steps currently use some different git repos for some of the tripleo tooling since not all of that functionality is upstream yet. I can submit those upstream, but they didn't make a whole lot of sense without the background, so I wanted to provide that first. At the very least, this could be an easier way for developers to get setup with tripleo to do a test overcloud deployment to develop on things like Tuskar. -- -- James Slagle -- -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
On Tue, Dec 24, 2013 at 4:28 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Slagle's message of 2013-12-24 10:40:23 -0800: In this approach, everyone uses the same undercloud vm image. In order to make that work, their's a script to build the config drive iso and that is then used to make config changes at boot time to the undercloud. Specifically, there's cloud-init data on the config drive iso to update the virtual power manager user and ssh key, and sets the user's ssh key in authorized keys. Is this because it is less work to build an iso than to customize an existing seed image? How hard would it be to just mount the guest image and drop the json file in it? It might take a little while longer to customize a built seed image, but it would still most likely be under a minute. Building the iso takes about a second. Either approach would be fine. I just chose the config drive because it seemed more like the cloud-init way to bootstrap an image that didn't have a dynamic runtime provided datasource. Of course, I ran into a few bugs in cloud-init testing out the config drive approach, so just modifying the image with libguestfs or qemu-nbd probably would have been just as easy. Anyway I like the approach, though I generally do not like config drive. :) If I were trying to shrink devtest from 3 clouds to 2, I'd eliminate the undercloud, not the seed. The seed is basically an undercloud in a VM with a static configuration. That is what you have described but done in a slightly different way. I am curious what the benefits of this approach are. True, there's not a whole lot of difference between eliminating the seed or the undercloud. You eliminate either one, then call your first cloud whichever you want. To me, the seed has always seemed short lived, once you use it to deploy the undercloud it can go away (eventually, anyway). So, that's why I am calling the first cloud here the undercloud. Plus, since it will eventually include Tuskar and deploy the overcloud, it seemed more inline with the current devtest flow to call it an undercloud. The more I think about it the more I think we should just take the three cloud approach. The seed can be turned off as soon as the undercloud is running, but it allows testing and modification of the seed to undercloud transfer, which is something we are going to need to put work in to at some point. It would be a shame to force developers to switch gears and use something entirely different when they need to get into that. Yea, that certainly makes sense. Also part of my motivation to not have a seed is the memory requirements on the host you're using for devtest. I'm not sure if 8gb is even enough anymore, as I haven't tried a full devtest run that recently. Especially if you're using your main development laptop with other stuff running. If you were able to shut down the seed though after deploying the undercloud, that would definitely help. I think there would be a couple of challenges with that for devtest: - If you had to reboot the undercloud, I think you'd need the seed there for the undercloud's metadata. - The seed vm is the only one in devtest with the 2 network interfaces, default and brbm - The seed handles routing all the traffic for 192.0.2.0/24 Perhaps we could just use your config drive approach for the seed all the time. Then users can start with pre-built images, but don't have to change everything when they want to start changing said images. I'm not 100% convinced that it is needed, but I'd rather have one path than two if we can manage that and not drive away potential contributors. Agreed, I'd like to see it as one path. Similar to how devtest offers different options down that path today, these could be additional options to not have a seed (or be able to just shutdown your seed vm), or use pre built vm's, etc. -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
Excerpts from James Slagle's message of 2013-12-24 08:50:32 -0800: I built some vm image files for testing with TripleO based off of the icehouse-1 milestone tarballs for Fedora and Ubuntu. If folks are interested in giving them a try you can find a set of instructions and how to download the images at: https://gist.github.com/slagle/981b279299e91ca91bd9 This is great, thanks for working hard to make the onramp shorter. :) The steps are similar to the devtest process, but you use the prebuilt vm images for the undercloud and overcloud and don't need a seed vm. When the undercloud vm is started it uses the OpenStack Configuration Drive as a data source for cloud-init. This eliminates some of the manual configuration that would otherwise be needed. To that end, the steps currently use some different git repos for some of the tripleo tooling since not all of that functionality is upstream yet. I can submit those upstream, but they didn't make a whole lot of sense without the background, so I wanted to provide that first. Why would config drive be easier than putting a single json file in /var/lib/heat-cfntools/cfn-init-data the way the seed works? Do you experience problems with that approach that we haven't discussed? If I were trying to shrink devtest from 3 clouds to 2, I'd eliminate the undercloud, not the seed. The seed is basically an undercloud in a VM with a static configuration. That is what you have described but done in a slightly different way. I am curious what the benefits of this approach are. At the very least, this could be an easier way for developers to get setup with tripleo to do a test overcloud deployment to develop on things like Tuskar. Don't let my questions discourage you. This is great as-is! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
On Tue, Dec 24, 2013 at 12:26 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Slagle's message of 2013-12-24 08:50:32 -0800: I built some vm image files for testing with TripleO based off of the icehouse-1 milestone tarballs for Fedora and Ubuntu. If folks are interested in giving them a try you can find a set of instructions and how to download the images at: https://gist.github.com/slagle/981b279299e91ca91bd9 This is great, thanks for working hard to make the onramp shorter. :) The steps are similar to the devtest process, but you use the prebuilt vm images for the undercloud and overcloud and don't need a seed vm. When the undercloud vm is started it uses the OpenStack Configuration Drive as a data source for cloud-init. This eliminates some of the manual configuration that would otherwise be needed. To that end, the steps currently use some different git repos for some of the tripleo tooling since not all of that functionality is upstream yet. I can submit those upstream, but they didn't make a whole lot of sense without the background, so I wanted to provide that first. Why would config drive be easier than putting a single json file in /var/lib/heat-cfntools/cfn-init-data the way the seed works? Do you experience problems with that approach that we haven't discussed? That approach works fine if you're going to build the seed image. In devtest, you modify the cfn-init-data with a sed command, then include it in your build seed image. So, everyone that runs devtest ends up with a unique seed image pretty much. In this approach, everyone uses the same undercloud vm image. In order to make that work, their's a script to build the config drive iso and that is then used to make config changes at boot time to the undercloud. Specifically, there's cloud-init data on the config drive iso to update the virtual power manager user and ssh key, and sets the user's ssh key in authorized keys. If I were trying to shrink devtest from 3 clouds to 2, I'd eliminate the undercloud, not the seed. The seed is basically an undercloud in a VM with a static configuration. That is what you have described but done in a slightly different way. I am curious what the benefits of this approach are. True, there's not a whole lot of difference between eliminating the seed or the undercloud. You eliminate either one, then call your first cloud whichever you want. To me, the seed has always seemed short lived, once you use it to deploy the undercloud it can go away (eventually, anyway). So, that's why I am calling the first cloud here the undercloud. Plus, since it will eventually include Tuskar and deploy the overcloud, it seemed more inline with the current devtest flow to call it an undercloud. At the very least, this could be an easier way for developers to get setup with tripleo to do a test overcloud deployment to develop on things like Tuskar. Don't let my questions discourage you. This is great as-is! Great, thanks. I appreciate the feedback! -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] icehouse-1 test disk images setup
Excerpts from James Slagle's message of 2013-12-24 10:40:23 -0800: On Tue, Dec 24, 2013 at 12:26 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Slagle's message of 2013-12-24 08:50:32 -0800: I built some vm image files for testing with TripleO based off of the icehouse-1 milestone tarballs for Fedora and Ubuntu. If folks are interested in giving them a try you can find a set of instructions and how to download the images at: https://gist.github.com/slagle/981b279299e91ca91bd9 This is great, thanks for working hard to make the onramp shorter. :) The steps are similar to the devtest process, but you use the prebuilt vm images for the undercloud and overcloud and don't need a seed vm. When the undercloud vm is started it uses the OpenStack Configuration Drive as a data source for cloud-init. This eliminates some of the manual configuration that would otherwise be needed. To that end, the steps currently use some different git repos for some of the tripleo tooling since not all of that functionality is upstream yet. I can submit those upstream, but they didn't make a whole lot of sense without the background, so I wanted to provide that first. Why would config drive be easier than putting a single json file in /var/lib/heat-cfntools/cfn-init-data the way the seed works? Do you experience problems with that approach that we haven't discussed? That approach works fine if you're going to build the seed image. In devtest, you modify the cfn-init-data with a sed command, then include it in your build seed image. So, everyone that runs devtest ends up with a unique seed image pretty much. I had not considered this but it makes sense. In this approach, everyone uses the same undercloud vm image. In order to make that work, their's a script to build the config drive iso and that is then used to make config changes at boot time to the undercloud. Specifically, there's cloud-init data on the config drive iso to update the virtual power manager user and ssh key, and sets the user's ssh key in authorized keys. Is this because it is less work to build an iso than to customize an existing seed image? How hard would it be to just mount the guest image and drop the json file in it? Anyway I like the approach, though I generally do not like config drive. :) If I were trying to shrink devtest from 3 clouds to 2, I'd eliminate the undercloud, not the seed. The seed is basically an undercloud in a VM with a static configuration. That is what you have described but done in a slightly different way. I am curious what the benefits of this approach are. True, there's not a whole lot of difference between eliminating the seed or the undercloud. You eliminate either one, then call your first cloud whichever you want. To me, the seed has always seemed short lived, once you use it to deploy the undercloud it can go away (eventually, anyway). So, that's why I am calling the first cloud here the undercloud. Plus, since it will eventually include Tuskar and deploy the overcloud, it seemed more inline with the current devtest flow to call it an undercloud. The more I think about it the more I think we should just take the three cloud approach. The seed can be turned off as soon as the undercloud is running, but it allows testing and modification of the seed to undercloud transfer, which is something we are going to need to put work in to at some point. It would be a shame to force developers to switch gears and use something entirely different when they need to get into that. Perhaps we could just use your config drive approach for the seed all the time. Then users can start with pre-built images, but don't have to change everything when they want to start changing said images. I'm not 100% convinced that it is needed, but I'd rather have one path than two if we can manage that and not drive away potential contributors. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
