Re: [openstack-dev] [tripleo] Adventures in QuintupleO
On Tue, Apr 21, 2015 at 5:23 PM, Ben Nemec openst...@nemebean.com wrote: On 04/20/2015 04:39 PM, Steve Baker wrote: I've been spending some time getting quintupleo working on top of a Juno RDO OpenStack. I'm at a point now where I think it is worth putting effort into making it easy for anyone to try this. \o/ Ben Nemec has done the hard work of proving this is possible[1] resulting in the repo he uses to bring up an environment which behaves like a baremetal env[2] I'd like to build on this to create a new upstream repo aimed at setting up an environment which is ready for undercloud and overcloud installation. For rdo-management, using it would be documented in its own section of the Setup chapter[3] Ben's heat templates bring up BMC and baremetal nodes. I've been extending those to also define the undercloud network and a bare undercloud node ready for undercloud installation (or optionally an image-based undercloud). Another future enhancement could be to figure out how to use only a single nova server serve all of the BMC requests (possibly with one server having a neutron port per baremetal it is managing) This will still require patching the nethercloud until we can find a way of upstreaming those changes. The repo can at least be where those patches live for now. So my questions for now would be: What should the repo be called? quintuplo-setup? Or just quintupleo. I doubt we're going to have a lot of problems with name collisions. :-) Where should it live? git openstack in the openstack namespace? github rdo-management? I'm not sure, but a few thoughts: It requires hackery of the underlying cloud. I'm wondering if that disqualifies it from the openstack namespace. It's only known to work with the instack-undercloud workflow. In theory that means it should be able to work with devtest, but at the moment we haven't actually used the two together. Which makes me wonder if it should just go in the rdo-management tree, but on the other hand I know there are people interested in it outside of RDO, so I'm not sure that's a perfect fit either. So given that I'm pretty undecided about where this belongs, maybe stackforge would be a good choice until we decide where it's going? We've already had a lot of discussion around the spec[1], and it's approved, so stackforge seems like the wrong place to me. Quintupleo feels more incubator-ish. So why not tripleo-incubator? A separate directory with the documentation and templates would probably be a good start. As for the hacks on the underlying projects, I'd say propose them to the affected projects in gerrit (even if WIP'd for now), and then document how to setup a cloud with those patches. Getting the proposed patches out there (if not done already) would probably help us work through what it's going to take to eventually get them landed, or if we need to go an entirely different direction. [1] http://specs.openstack.org/openstack/tripleo-specs/specs/juno/tripleo-on-openstack.html -- -- James Slagle -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Adventures in QuintupleO
On 23/04/15 23:25, James Slagle wrote: On Tue, Apr 21, 2015 at 5:23 PM, Ben Nemec openst...@nemebean.com wrote: On 04/20/2015 04:39 PM, Steve Baker wrote: I've been spending some time getting quintupleo working on top of a Juno RDO OpenStack. I'm at a point now where I think it is worth putting effort into making it easy for anyone to try this. \o/ Ben Nemec has done the hard work of proving this is possible[1] resulting in the repo he uses to bring up an environment which behaves like a baremetal env[2] I'd like to build on this to create a new upstream repo aimed at setting up an environment which is ready for undercloud and overcloud installation. For rdo-management, using it would be documented in its own section of the Setup chapter[3] Ben's heat templates bring up BMC and baremetal nodes. I've been extending those to also define the undercloud network and a bare undercloud node ready for undercloud installation (or optionally an image-based undercloud). Another future enhancement could be to figure out how to use only a single nova server serve all of the BMC requests (possibly with one server having a neutron port per baremetal it is managing) This will still require patching the nethercloud until we can find a way of upstreaming those changes. The repo can at least be where those patches live for now. So my questions for now would be: What should the repo be called? quintuplo-setup? Or just quintupleo. I doubt we're going to have a lot of problems with name collisions. :-) Where should it live? git openstack in the openstack namespace? github rdo-management? I'm not sure, but a few thoughts: It requires hackery of the underlying cloud. I'm wondering if that disqualifies it from the openstack namespace. It's only known to work with the instack-undercloud workflow. In theory that means it should be able to work with devtest, but at the moment we haven't actually used the two together. Which makes me wonder if it should just go in the rdo-management tree, but on the other hand I know there are people interested in it outside of RDO, so I'm not sure that's a perfect fit either. So given that I'm pretty undecided about where this belongs, maybe stackforge would be a good choice until we decide where it's going? We've already had a lot of discussion around the spec[1], and it's approved, so stackforge seems like the wrong place to me. Quintupleo feels more incubator-ish. So why not tripleo-incubator? A separate directory with the documentation and templates would probably be a good start. OK, I've started with this: https://review.openstack.org/#/c/177032/ which is a combination a stripped-back rdo-management documentation and this: https://github.com/steveb/quintupleo As for the hacks on the underlying projects, I'd say propose them to the affected projects in gerrit (even if WIP'd for now), and then document how to setup a cloud with those patches. They are a directory of patches to juno and kilo for now, ie https://review.openstack.org/#/c/177032/1/quintupleo/patches/kilo/README.md Getting the proposed patches out there (if not done already) would probably help us work through what it's going to take to eventually get them landed, or if we need to go an entirely different direction. I wonder if the neutron patch would be better telling the user to switch to the noop firewall driver, but that hammer might be too big. [1] http://specs.openstack.org/openstack/tripleo-specs/specs/juno/tripleo-on-openstack.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Adventures in QuintupleO
On 04/20/2015 04:39 PM, Steve Baker wrote: I've been spending some time getting quintupleo working on top of a Juno RDO OpenStack. I'm at a point now where I think it is worth putting effort into making it easy for anyone to try this. \o/ Ben Nemec has done the hard work of proving this is possible[1] resulting in the repo he uses to bring up an environment which behaves like a baremetal env[2] I'd like to build on this to create a new upstream repo aimed at setting up an environment which is ready for undercloud and overcloud installation. For rdo-management, using it would be documented in its own section of the Setup chapter[3] Ben's heat templates bring up BMC and baremetal nodes. I've been extending those to also define the undercloud network and a bare undercloud node ready for undercloud installation (or optionally an image-based undercloud). Another future enhancement could be to figure out how to use only a single nova server serve all of the BMC requests (possibly with one server having a neutron port per baremetal it is managing) This will still require patching the nethercloud until we can find a way of upstreaming those changes. The repo can at least be where those patches live for now. So my questions for now would be: What should the repo be called? quintuplo-setup? Or just quintupleo. I doubt we're going to have a lot of problems with name collisions. :-) Where should it live? git openstack in the openstack namespace? github rdo-management? I'm not sure, but a few thoughts: It requires hackery of the underlying cloud. I'm wondering if that disqualifies it from the openstack namespace. It's only known to work with the instack-undercloud workflow. In theory that means it should be able to work with devtest, but at the moment we haven't actually used the two together. Which makes me wonder if it should just go in the rdo-management tree, but on the other hand I know there are people interested in it outside of RDO, so I'm not sure that's a perfect fit either. So given that I'm pretty undecided about where this belongs, maybe stackforge would be a good choice until we decide where it's going? [1] http://blog.nemebean.com/tags/quintupleo [2] https://github.com/cybertron/tripleo-scripts [3] https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/setup.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Adventures in QuintupleO
I've been spending some time getting quintupleo working on top of a Juno RDO OpenStack. I'm at a point now where I think it is worth putting effort into making it easy for anyone to try this. Ben Nemec has done the hard work of proving this is possible[1] resulting in the repo he uses to bring up an environment which behaves like a baremetal env[2] I'd like to build on this to create a new upstream repo aimed at setting up an environment which is ready for undercloud and overcloud installation. For rdo-management, using it would be documented in its own section of the Setup chapter[3] Ben's heat templates bring up BMC and baremetal nodes. I've been extending those to also define the undercloud network and a bare undercloud node ready for undercloud installation (or optionally an image-based undercloud). Another future enhancement could be to figure out how to use only a single nova server serve all of the BMC requests (possibly with one server having a neutron port per baremetal it is managing) This will still require patching the nethercloud until we can find a way of upstreaming those changes. The repo can at least be where those patches live for now. So my questions for now would be: What should the repo be called? quintuplo-setup? Where should it live? git openstack in the openstack namespace? github rdo-management? [1] http://blog.nemebean.com/tags/quintupleo [2] https://github.com/cybertron/tripleo-scripts [3] https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/setup.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
