On Apr 23, 2013, at 10:48 PM, Monty Taylor <[email protected]> wrote: > > I'd like to make some headway on the tripleo-based stuff that Robert and > I discussed with you guys when we came to the castle. If we can get that > bit in - then deploying a base xenserver image onto some metal once we > have it won't be a special case - and doing the gobs of combinations > like you're talking about should be simple. > > It breaks down into a few different problem areas: > > a) getting the process flow around using openstack to deploy openstack > even on VMs working. pleia2 is working on that using hte virtual bare > metal code right now, and I think it's a great starting point.
We're working on similar inside RAX for our automated dev environments (on-demand devstack, only much more than devstack. Cells, control plane, etc…). The work we're doing is designed to align with HEAT and nova-baremetal^W nova-truss. On our end it may involve writing power plugins and deployment plugins to work with what we have to manage the bare metal -- but that's where we are headed. We want to be deploying our dev environments (and later our actual environments) in the same fashion that upstream is. > > b) figuring out how the OpenStack Infra team interacts with hardware > from folks. We had a session about this at the summit (I think you were > in that one? the week was a bit of a blur...) and some of the issues are > that we'll need it to be isolated enough that dhcp/pxe-ing from one > server to others needs to be ok - but it needs to be managed enough that > there is a way for the infra team to deal with problems should they > arise. jeblair brought up that if we can get hardware donations from > mutiple vendors, then perhaps the vendor response time on a single set > of hardware won't be as important to the gate. This is a bit of a moot > question until there is actual hardware to consider… Which we are working on. I believe the end result of the session was that a set of requirements was going to be written up for what the CI team is looking for w/ regard to hardware and access, so that folks like us can work on providing it. Turns out Rackspace has some experience with doing the managed hosting thing... > > c) Getting the heat+nova based install of openstack working. This is a > thing that we can start pointing you at in the #tripleo channel... and > I'd love to follow-up/re-engage with you on what steps we need to do to > start moving iNova more towards OpenStack Bare Metal/TripleO as an > underlying basis. See above :) This is definitely where our work is going. > > You'll notice I didn't mention puppet or mcollective. That's not because > I hate you or those technologies - just that I think that the > orchestration issues in terms of wrangling the resources are the much > harder ones to solve at the moment - and I think that > mcollective/puppet/chef/razor/crowbar are all highly problematic from > the gate's perspective, because they make it even harder for devs to > debug their gate failing issue. > > Now I'm rambling - maybe let's have a quick chat on the IRC tomorrow to > get a good baseline, and then bring that back to the list here > (recording thinking is a great idea) -jlk _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
