Re: [openstack-dev] [TripleO] Getting to a 1.0
On 03/07/2015 04:34 AM, Dan Prince wrote: On Tue, 2015-03-03 at 17:30 -0500, James Slagle wrote: Hi, Don't let the subject throw you off :) I wasn't sure how to phrase what I wanted to capture in this mail, and that seemed reasonable enough. I wanted to kick off a discussion about what gaps people think are missing from TripleO before we can meet the goal of realistically being able to use TripleO in production. The things in my mind are: Upgrades - I believe the community is trending away from the image based upgrade rebuild process. The ongoing Puppet integration work is integrated with Heat's SoftwareConfig/SoftwareDeployment features and is package driven. There is still work to be done, especially around supporting rollbacks, but I think this could be part of the answer to how the upgrade problem gets solved. +1 Using packages solves some problems very nicely. We haven't solved all the CI related issues around using packages with upstream but it is getting better. I mention this because it would be nice to have CI testing on the upgrade process automated at some point... HA - We have an implementation of HA in tripleo-image-elements today. However, the Puppet codepath leaves that mostly unused. The Puppet modules however do support HA. Is that the answer here as well? In general most of the puppet modules support the required HA bits. We are still working to integrate some of the final pieces here but in general I expect this to proceed quickly. going back to CI, I think this would benefit from an additional CI job given we have a non-voting HA job running on precise/elements, I'd like to add one running on fedora/puppet, maybe initially non-voting as well this said, it would also be nice to have a job which deploys additional block storage (cinder) and object storage (swift) nodes ... ... and to save some resources, maybe we can switch 'check-tripleo-ironic-overcloud-f20puppet-nonha' and 'check-tripleo-ironic-overcloud-precise-nonha' to deploy a single compute node instead of two CLI - We have devtest. I'm not sure if anyone would argue that should be used in production. It could be...but I don't think that was it's original goal and it shows. The downstreams of TripleO that I'm aware of each ended up more of less having their own CLI tooling. Obviously I'm only very familiar with one of the downstreams, but in some instances I believe parts of devtest were reused, and other times not. That begs the question, do we need a well represented unified CLI in TripleO? We have a pretty good story about using Nova/Ironic/Heat[0] to deploy OpenStack, and devtest is one such implementation of that story. Perhaps we need something more production oriented. I think this is an interesting idea and perhaps has some merit. I'd like to see some specific examples showing how the unified CLI might make things easier for end users... I am of the same feeling; AFAIK devtest was meant to setup a development environment, not a production environment, more on this later Baremetal management - To what extent should TripleO venture into this space? I'm thinking things like discovery/introspection, ready state, and role assignment. Ironic is growing features to expose things like RAID management via vendor passthrough API's. Should TripleO take a role in exercising those API's? It's something that could be built into the flow of the unified CLI if we were to end up going that route. Bootstrapping - The undercloud needs to be bootstrapped/deployed/installed itself. We have the seed vm to do that. I've also worked on an implementation to install an undercloud via an installation script assuming the base OS is already installed. Are these the only 2 options we should consider, or are there other ideas that will integrate better into existing infrastructure? And also should we think about possibly renaming these? I find that many times when talking about TripleO to someone new they find the whole undercloud/overcloud thing confusing. Calling the undercloud the baremetal cloud makes it click. I don't think we need more; what I would like to have instead is a tool, targeted at end users, capable of setting up an undercloud without going through the seed this said, I am really not sure if that should be a wrapper around devtest --no-undercloud or a tool which turns the existing base os into an undercloud; both seem to have pros and cons Release Cadence with wider OpenStack - I'd love to be able to say on the day that a new release of OpenStack goes live that you can use TripleO to deploy that release in production...and here's how you'd do it personally, while I tried to join this conversation in the past, I am still unsure whether for tripleo a stable/master approach would work better or not than a synchronized release cadence -- Giulio Fidente GPG KEY: 08D733BA __ OpenStack Development Mailing List
Re: [openstack-dev] [TripleO] Getting to a 1.0
On Tue, 2015-03-03 at 17:30 -0500, James Slagle wrote: Hi, Don't let the subject throw you off :) I wasn't sure how to phrase what I wanted to capture in this mail, and that seemed reasonable enough. I wanted to kick off a discussion about what gaps people think are missing from TripleO before we can meet the goal of realistically being able to use TripleO in production. The things in my mind are: Upgrades - I believe the community is trending away from the image based upgrade rebuild process. The ongoing Puppet integration work is integrated with Heat's SoftwareConfig/SoftwareDeployment features and is package driven. There is still work to be done, especially around supporting rollbacks, but I think this could be part of the answer to how the upgrade problem gets solved. +1 Using packages solves some problems very nicely. We haven't solved all the CI related issues around using packages with upstream but it is getting better. I mention this because it would be nice to have CI testing on the upgrade process automated at some point... HA - We have an implementation of HA in tripleo-image-elements today. However, the Puppet codepath leaves that mostly unused. The Puppet modules however do support HA. Is that the answer here as well? In general most of the puppet modules support the required HA bits. We are still working to integrate some of the final pieces here but in general I expect this to proceed quickly. CLI - We have devtest. I'm not sure if anyone would argue that should be used in production. It could be...but I don't think that was it's original goal and it shows. The downstreams of TripleO that I'm aware of each ended up more of less having their own CLI tooling. Obviously I'm only very familiar with one of the downstreams, but in some instances I believe parts of devtest were reused, and other times not. That begs the question, do we need a well represented unified CLI in TripleO? We have a pretty good story about using Nova/Ironic/Heat[0] to deploy OpenStack, and devtest is one such implementation of that story. Perhaps we need something more production oriented. I think this is an interesting idea and perhaps has some merit. I'd like to see some specific examples showing how the unified CLI might make things easier for end users... Baremetal management - To what extent should TripleO venture into this space? I'm thinking things like discovery/introspection, ready state, and role assignment. Ironic is growing features to expose things like RAID management via vendor passthrough API's. Should TripleO take a role in exercising those API's? It's something that could be built into the flow of the unified CLI if we were to end up going that route. Bootstrapping - The undercloud needs to be bootstrapped/deployed/installed itself. We have the seed vm to do that. I've also worked on an implementation to install an undercloud via an installation script assuming the base OS is already installed. Are these the only 2 options we should consider, or are there other ideas that will integrate better into existing infrastructure? And also should we think about possibly renaming these? I find that many times when talking about TripleO to someone new they find the whole undercloud/overcloud thing confusing. Calling the undercloud the baremetal cloud makes it click. Release Cadence with wider OpenStack - I'd love to be able to say on the day that a new release of OpenStack goes live that you can use TripleO to deploy that release in production...and here's how you'd do it What other items should we include here? I almost added a point for Stability, but let's just assume we want to make everything as stable as we possibly can :). I know I've mostly raised questions. I have some of my own answers in mind. But, I was actually hoping to get others talking about what the right answers might be. [0] Plus the other supporting cast of characters: Keystone/Glance/Neutron/Swift. Thanks. __ 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] Getting to a 1.0
Hi, Don't let the subject throw you off :) I wasn't sure how to phrase what I wanted to capture in this mail, and that seemed reasonable enough. I wanted to kick off a discussion about what gaps people think are missing from TripleO before we can meet the goal of realistically being able to use TripleO in production. The things in my mind are: Upgrades - I believe the community is trending away from the image based upgrade rebuild process. The ongoing Puppet integration work is integrated with Heat's SoftwareConfig/SoftwareDeployment features and is package driven. There is still work to be done, especially around supporting rollbacks, but I think this could be part of the answer to how the upgrade problem gets solved. HA - We have an implementation of HA in tripleo-image-elements today. However, the Puppet codepath leaves that mostly unused. The Puppet modules however do support HA. Is that the answer here as well? CLI - We have devtest. I'm not sure if anyone would argue that should be used in production. It could be...but I don't think that was it's original goal and it shows. The downstreams of TripleO that I'm aware of each ended up more of less having their own CLI tooling. Obviously I'm only very familiar with one of the downstreams, but in some instances I believe parts of devtest were reused, and other times not. That begs the question, do we need a well represented unified CLI in TripleO? We have a pretty good story about using Nova/Ironic/Heat[0] to deploy OpenStack, and devtest is one such implementation of that story. Perhaps we need something more production oriented. Baremetal management - To what extent should TripleO venture into this space? I'm thinking things like discovery/introspection, ready state, and role assignment. Ironic is growing features to expose things like RAID management via vendor passthrough API's. Should TripleO take a role in exercising those API's? It's something that could be built into the flow of the unified CLI if we were to end up going that route. Bootstrapping - The undercloud needs to be bootstrapped/deployed/installed itself. We have the seed vm to do that. I've also worked on an implementation to install an undercloud via an installation script assuming the base OS is already installed. Are these the only 2 options we should consider, or are there other ideas that will integrate better into existing infrastructure? Release Cadence with wider OpenStack - I'd love to be able to say on the day that a new release of OpenStack goes live that you can use TripleO to deploy that release in production...and here's how you'd do it What other items should we include here? I almost added a point for Stability, but let's just assume we want to make everything as stable as we possibly can :). I know I've mostly raised questions. I have some of my own answers in mind. But, I was actually hoping to get others talking about what the right answers might be. [0] Plus the other supporting cast of characters: Keystone/Glance/Neutron/Swift. Thanks. -- -- 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
