Re: [openstack-dev] [TripleO] milestone-proposed branches
Robert Collins wrote: On 3 March 2014 23:12, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config Are you willing to run through the steps on the How_To_Release wiki for these repos, or should I do it next week? Just let me know how or what to coordinate. Thanks. I looked into more details and there are a number of issues as TripleO projects were not really originally configured to be released. First, some basic jobs are missing, like a tarball job for tripleo-incubator. Do we need one? tripleo-incubator has no infrastructure to make tarballs. So that has to be created de novo, and its not really structured to be sdistable - its a proving ground. This needs more examination. Slagle could however use a git branch effectively. I'd say you don't need such a job, but then I'm not the one asking for that repository to be included in next week's cutting of icehouse-3. James asks if I'd be OK to run through the steps on the How_To_Release wiki, and that wiki page is all about publishing tarballs. So my answer is, if you want to run the release scripts for tripleo-incubator, then you need a tarball job. Then the release scripts are made for integrated projects, which follow a number of rules that TripleO doesn't follow: - One Launchpad project per code repository, under the same name (here you have tripleo-* under tripleo + diskimage-builder separately) Huh? diskimage-builder is a separate project, with a separate repo. No conflation. Same for os-*-config, though I haven't made a LP project for os-cloud-config yet (but its not a dependency yet either). Just saying that IF you want to use the release scripts (and it looks like you actually don't want that), you'll need a 1:1 LP - repo match. Currently in LP you have tripleo (covering tripleo-* repos), diskimage-builder, and the os-* projects (which I somehow missed). To reuse the release scripts you'd have to split tripleo in LP into multiple projects. Finally the person doing the release needs to have push annotated tags / create reference permissions over refs/tags/* in Gerrit. This seems to be missing for a number of projects. We have this for all the projects we release; probably not incubator because *we don't release it*- and we had no intent of doing releases for tripleo-incubator - just having a stable branch so that there is a thing RH can build rpms from is the key goal. I agree with you. I only talked about it because James mentioned it in his to be released list. In all cases I'd rather limit myself to incubated/integrated projects, rather than extend to other projects, especially on a busy week like feature freeze week. So I'd advise that for icehouse-3 you follow the following simplified procedure: - Add missing tarball-creation jobs - Add missing permissions for yourself in Gerrit - Skip milestone-proposed branch creation - Push tag on master when ready (this will result in tarballs getting built at tarballs.openstack.org) Optionally: - Create icehouse series / icehouse-3 milestone for projects in LP - Manually create release and upload resulting tarballs to Launchpad milestone page, under the projects that make the most sense (tripleo-* under tripleo, etc) I'm still a bit confused with the goals here. My original understanding was that TripleO was explicitly NOT following the release cycle. How much of the integrated projects release process do you want to reuse ? We do a feature freeze on icehouse-3, then bugfix on master until -rc1, then we cut an icehouse release branch (milestone-proposed), unfreeze master and let it continue as Juno. Is that what you want to do too ? Do you want releases ? Or do you actually just want stable branches ? This is the etherpad: https://etherpad.openstack.org/p/icehouse-updates-stablebranches - that captures our notes from the summit. TripleO has a whole is not committing to stable maintenance nor API service integrated releases as yet: tuskar is our API service which will follow that process next cycle, but right now it has its guts open undergoing open heart surgery. Everything else we do semver on - like the openstack clients (novaclient etc) - and our overall process is aimed at moving things from incubator into stable trees as they mature. We'll be stabilising the interfaces in tripleo-heat-templates and tripleo-image-elements somehow in future too - but we don't have good answers to some aspects there yet. BUT We want
Re: [openstack-dev] [TripleO] milestone-proposed branches
On Tue, Mar 4, 2014 at 2:08 AM, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: On 3 March 2014 23:12, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config Are you willing to run through the steps on the How_To_Release wiki for these repos, or should I do it next week? Just let me know how or what to coordinate. Thanks. I looked into more details and there are a number of issues as TripleO projects were not really originally configured to be released. First, some basic jobs are missing, like a tarball job for tripleo-incubator. Do we need one? tripleo-incubator has no infrastructure to make tarballs. So that has to be created de novo, and its not really structured to be sdistable - its a proving ground. This needs more examination. Slagle could however use a git branch effectively. I'd say you don't need such a job, but then I'm not the one asking for that repository to be included in next week's cutting of icehouse-3. James asks if I'd be OK to run through the steps on the How_To_Release wiki, and that wiki page is all about publishing tarballs. So my answer is, if you want to run the release scripts for tripleo-incubator, then you need a tarball job. Then the release scripts are made for integrated projects, which follow a number of rules that TripleO doesn't follow: - One Launchpad project per code repository, under the same name (here you have tripleo-* under tripleo + diskimage-builder separately) Huh? diskimage-builder is a separate project, with a separate repo. No conflation. Same for os-*-config, though I haven't made a LP project for os-cloud-config yet (but its not a dependency yet either). Just saying that IF you want to use the release scripts (and it looks like you actually don't want that), you'll need a 1:1 LP - repo match. Currently in LP you have tripleo (covering tripleo-* repos), diskimage-builder, and the os-* projects (which I somehow missed). To reuse the release scripts you'd have to split tripleo in LP into multiple projects. Finally the person doing the release needs to have push annotated tags / create reference permissions over refs/tags/* in Gerrit. This seems to be missing for a number of projects. We have this for all the projects we release; probably not incubator because *we don't release it*- and we had no intent of doing releases for tripleo-incubator - just having a stable branch so that there is a thing RH can build rpms from is the key goal. I agree with you. I only talked about it because James mentioned it in his to be released list. In all cases I'd rather limit myself to incubated/integrated projects, rather than extend to other projects, especially on a busy week like feature freeze week. So I'd advise that for icehouse-3 you follow the following simplified procedure: - Add missing tarball-creation jobs - Add missing permissions for yourself in Gerrit - Skip milestone-proposed branch creation - Push tag on master when ready (this will result in tarballs getting built at tarballs.openstack.org) Optionally: - Create icehouse series / icehouse-3 milestone for projects in LP - Manually create release and upload resulting tarballs to Launchpad milestone page, under the projects that make the most sense (tripleo-* under tripleo, etc) I'm still a bit confused with the goals here. My original understanding was that TripleO was explicitly NOT following the release cycle. How much of the integrated projects release process do you want to reuse ? We do a feature freeze on icehouse-3, then bugfix on master until -rc1, then we cut an icehouse release branch (milestone-proposed), unfreeze master and let it continue as Juno. Is that what you want to do too ? Do you want releases ? Or do you actually just want stable branches ? This is the etherpad: https://etherpad.openstack.org/p/icehouse-updates-stablebranches - that captures our notes from the summit. TripleO has a whole is not committing to stable maintenance nor API service integrated releases as yet: tuskar is our API service which will follow that process next cycle, but right now it has its guts open undergoing open heart surgery. Everything else we do semver on - like the openstack clients (novaclient etc) - and our overall process is aimed at moving things from incubator into stable trees as they mature. We'll be stabilising the interfaces in tripleo-heat-templates and tripleo-image-elements somehow in
Re: [openstack-dev] [TripleO] milestone-proposed branches
James Slagle wrote: I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config Are you willing to run through the steps on the How_To_Release wiki for these repos, or should I do it next week? Just let me know how or what to coordinate. Thanks. I looked into more details and there are a number of issues as TripleO projects were not really originally configured to be released. First, some basic jobs are missing, like a tarball job for tripleo-incubator. Then the release scripts are made for integrated projects, which follow a number of rules that TripleO doesn't follow: - One Launchpad project per code repository, under the same name (here you have tripleo-* under tripleo + diskimage-builder separately) - The person doing the release should be a driver (or release manager) for the project (here, Robert is the sole driver for diskimage-builder) - Projects should have an icehouse series and a icehouse-3 milestone Finally the person doing the release needs to have push annotated tags / create reference permissions over refs/tags/* in Gerrit. This seems to be missing for a number of projects. In all cases I'd rather limit myself to incubated/integrated projects, rather than extend to other projects, especially on a busy week like feature freeze week. So I'd advise that for icehouse-3 you follow the following simplified procedure: - Add missing tarball-creation jobs - Add missing permissions for yourself in Gerrit - Skip milestone-proposed branch creation - Push tag on master when ready (this will result in tarballs getting built at tarballs.openstack.org) Optionally: - Create icehouse series / icehouse-3 milestone for projects in LP - Manually create release and upload resulting tarballs to Launchpad milestone page, under the projects that make the most sense (tripleo-* under tripleo, etc) I'm still a bit confused with the goals here. My original understanding was that TripleO was explicitly NOT following the release cycle. How much of the integrated projects release process do you want to reuse ? We do a feature freeze on icehouse-3, then bugfix on master until -rc1, then we cut an icehouse release branch (milestone-proposed), unfreeze master and let it continue as Juno. Is that what you want to do too ? Do you want releases ? Or do you actually just want stable branches ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] milestone-proposed branches
On 3 March 2014 23:12, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config Are you willing to run through the steps on the How_To_Release wiki for these repos, or should I do it next week? Just let me know how or what to coordinate. Thanks. I looked into more details and there are a number of issues as TripleO projects were not really originally configured to be released. First, some basic jobs are missing, like a tarball job for tripleo-incubator. Do we need one? tripleo-incubator has no infrastructure to make tarballs. So that has to be created de novo, and its not really structured to be sdistable - its a proving ground. This needs more examination. Slagle could however use a git branch effectively. Then the release scripts are made for integrated projects, which follow a number of rules that TripleO doesn't follow: - One Launchpad project per code repository, under the same name (here you have tripleo-* under tripleo + diskimage-builder separately) Huh? diskimage-builder is a separate project, with a separate repo. No conflation. Same for os-*-config, though I haven't made a LP project for os-cloud-config yet (but its not a dependency yet either). - The person doing the release should be a driver (or release manager) for the project (here, Robert is the sole driver for diskimage-builder) Will fix. - Projects should have an icehouse series and a icehouse-3 milestone James should be able to do this once we have drivers fixed up. Finally the person doing the release needs to have push annotated tags / create reference permissions over refs/tags/* in Gerrit. This seems to be missing for a number of projects. We have this for all the projects we release; probably not incubator because *we don't release it*- and we had no intent of doing releases for tripleo-incubator - just having a stable branch so that there is a thing RH can build rpms from is the key goal. In all cases I'd rather limit myself to incubated/integrated projects, rather than extend to other projects, especially on a busy week like feature freeze week. So I'd advise that for icehouse-3 you follow the following simplified procedure: - Add missing tarball-creation jobs - Add missing permissions for yourself in Gerrit - Skip milestone-proposed branch creation - Push tag on master when ready (this will result in tarballs getting built at tarballs.openstack.org) Optionally: - Create icehouse series / icehouse-3 milestone for projects in LP - Manually create release and upload resulting tarballs to Launchpad milestone page, under the projects that make the most sense (tripleo-* under tripleo, etc) I'm still a bit confused with the goals here. My original understanding was that TripleO was explicitly NOT following the release cycle. How much of the integrated projects release process do you want to reuse ? We do a feature freeze on icehouse-3, then bugfix on master until -rc1, then we cut an icehouse release branch (milestone-proposed), unfreeze master and let it continue as Juno. Is that what you want to do too ? Do you want releases ? Or do you actually just want stable branches ? This is the etherpad: https://etherpad.openstack.org/p/icehouse-updates-stablebranches - that captures our notes from the summit. TripleO has a whole is not committing to stable maintenance nor API service integrated releases as yet: tuskar is our API service which will follow that process next cycle, but right now it has its guts open undergoing open heart surgery. Everything else we do semver on - like the openstack clients (novaclient etc) - and our overall process is aimed at moving things from incubator into stable trees as they mature. We'll be stabilising the interfaces in tripleo-heat-templates and tripleo-image-elements somehow in future too - but we don't have good answers to some aspects there yet. BUT We want to support members of the TripleO community that are interested in shipping stable editions of TripleO even while it still building up to being a product, which James is leading the effort on - so we need to find reasonable compromises on areas of friction in the interim. Cheers, Rob -- 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] milestone-proposed branches
On 1 March 2014 16:23, James Slagle james.sla...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:46 PM, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: I read through that wiki page. I did have a couple of questions: Who usually runs through the steps there? You? or a project member? Me for integrated projects (and most incubated ones). A project member for everything else. When repo_tarball_diff.sh is run, are there any acceptable missing files? I'm seeing an AUTHORS and ChangeLog file showing up in the output from our repos, those are automatically generated, so I assume those are ok. There are also some egg_info files showing up, which I also think can be safely ignored. (I submitted a patch that updates the grep command used in the script: https://review.openstack.org/#/c/68471/ ) Yes, there is a number of normal things appearing there, like the autogenerated AUTHORS, Changelog, ignored files and egg_info stuff. The goal of the script is to spot any unusual thing. Hi Thierry, I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder These: http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config don't make sense to me to branch - we consume them via releases from PyPI, not branches, so to freeze for stability you just need to specify known good release versions to consume. -Rob -- 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] milestone-proposed branches
On Wed, Jan 22, 2014 at 6:46 PM, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: I read through that wiki page. I did have a couple of questions: Who usually runs through the steps there? You? or a project member? Me for integrated projects (and most incubated ones). A project member for everything else. When repo_tarball_diff.sh is run, are there any acceptable missing files? I'm seeing an AUTHORS and ChangeLog file showing up in the output from our repos, those are automatically generated, so I assume those are ok. There are also some egg_info files showing up, which I also think can be safely ignored. (I submitted a patch that updates the grep command used in the script: https://review.openstack.org/#/c/68471/ ) Yes, there is a number of normal things appearing there, like the autogenerated AUTHORS, Changelog, ignored files and egg_info stuff. The goal of the script is to spot any unusual thing. Hi Thierry, I'd like to ask that the following repositories for TripleO be included in next week's cutting of icehouse-3: http://git.openstack.org/openstack/tripleo-incubator http://git.openstack.org/openstack/tripleo-image-elements http://git.openstack.org/openstack/tripleo-heat-templates http://git.openstack.org/openstack/diskimage-builder http://git.openstack.org/openstack/os-collect-config http://git.openstack.org/openstack/os-refresh-config http://git.openstack.org/openstack/os-apply-config Are you willing to run through the steps on the How_To_Release wiki for these repos, or should I do it next week? Just let me know how or what to coordinate. Thanks. -- -- 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] milestone-proposed branches
On Thu, Jan 16, 2014 at 10:32 AM, Thierry Carrez thie...@openstack.org wrote: James Slagle wrote: [...] And yes, I'm volunteering to do the work to support the above, and the release work :). Let me know if you have any question or need help. The process and tools used for the integrated release are described here: https://wiki.openstack.org/wiki/Release_Team/How_To_Release Thanks Thierry, I wanted to give this a go for icehouse milestone 2, but given that those were cut yesterday and there are still some outstanding doc updates in review, I'd like to shoot for milestone 3 instead. Is there anything additional we need to do to make that happen? I read through that wiki page. I did have a couple of questions: Who usually runs through the steps there? You? or a project member? When repo_tarball_diff.sh is run, are there any acceptable missing files? I'm seeing an AUTHORS and ChangeLog file showing up in the output from our repos, those are automatically generated, so I assume those are ok. There are also some egg_info files showing up, which I also think can be safely ignored. (I submitted a patch that updates the grep command used in the script: https://review.openstack.org/#/c/68471/ ) Thanks. Also note that we were considering switching from using milestone-proposed to using proposed/*, to avoid reusing branch names: https://review.openstack.org/#/c/65103/ -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- 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] milestone-proposed branches
James Slagle wrote: I read through that wiki page. I did have a couple of questions: Who usually runs through the steps there? You? or a project member? Me for integrated projects (and most incubated ones). A project member for everything else. When repo_tarball_diff.sh is run, are there any acceptable missing files? I'm seeing an AUTHORS and ChangeLog file showing up in the output from our repos, those are automatically generated, so I assume those are ok. There are also some egg_info files showing up, which I also think can be safely ignored. (I submitted a patch that updates the grep command used in the script: https://review.openstack.org/#/c/68471/ ) Yes, there is a number of normal things appearing there, like the autogenerated AUTHORS, Changelog, ignored files and egg_info stuff. The goal of the script is to spot any unusual thing. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] milestone-proposed branches
On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote: Note that tripleo-incubator is special and should not be released. It is intentionally kept unfrozen and unreleased to make sure there is no illusion of stability. I think it would be nice if we could point people at a devtest that they could use with our other released stuff. Without that, we might make a change to devtest, such as showing the use of a new heat parameter in our templates, and if they're trying to follow along with a released tripleo-heat-templates then they would have a problem. Without a branch of incubator, there's no story or documentation around using any of our released stuff. You could follow along with devtest to get an idea of how it's supposed to work and indeed it might even work, but I don't think that's good enough. There is tooling in incubator that has proved it's usefulness. Take an example like setup-endpoints, what we're effectively saying without allowing people to use that is that there is a useful tool that will setup endpoints for you, but don't use it with our released stuff because it's not gauranteed to work and instead make these 10'ish calls to keystone via some other method. Then you'd also end up with a different but parallel set of instructions for using our released stuff vs. not. This is prohibitive to someone who may want to setup a tripleo CI/CD cloud deploying stable icehouse or from milestone branches. I think people would just create their own fork of tripleo-incubator and use that. If there are components in it that need releasing, they should be moved into relevant projects or forked into their own projects. I'd be fine with that approach, except that's pretty much everything in incubator, the scripts, templates, generated docs, etc. Instead of creating a new forked repo, why don't we just rename tripleo-incubator to tripleo-deployment and have some stable branches that people could use with our releases? I don't feel like that precludes tripleo from having no stability on the master branch at all. Excerpts from Ryan Brady's message of 2014-01-16 07:42:33 -0800: +1 for releases. In the past I requested a tag for tripleo-incubator to make it easier to build a package and test. In my case a common tag would be easier to track than trying to gather all of the commit hashes where the projects are compatible. Ryan - Original Message - From: James Slagle james.sla...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Thursday, January 16, 2014 10:13:58 AM Subject: [openstack-dev] [TripleO] milestone-proposed branches At last summit, we talked about doing stable branches and releases for the TripleO projects for Icehouse. I'd like to propose doing a milestone-proposed branch[1] and tagged release for icehouse milestones 2 and 3. Sort of as dry run and practice, as I think it could help tease out some things we might not have considered when we do try to do icehouse stable branches. The icehouse milestone 2 date is January 23rd [2]. So, if there is concensus to do this, we probably need to get the branches created soon, and then do any bugfixes in the branches (master too of course) up unitl the 23rd. I think it'd be nice if we had a working devtest to use with the released tarballs. This raises a couple of points: - We probably need a way in devtest to let people use a different branch (or tarball) of the stuff that is git cloned. - What about tripleo-incubator itself? We've said in the past we don't want to attempt to stabilize or release that due to it's incubator nature. But, if we don't have a stable set of devtest instructions (and accompanying scripts like setup-endpoints, etc), then using an ever changing devtest with the branches/tarballs is not likely to work for very long. And yes, I'm volunteering to do the work to support the above, and the release work :). Thoughts? [1] https://wiki.openstack.org/wiki/BranchModel [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- 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] milestone-proposed branches
Hey, so I think my criteria would be: - low chance of user confusion - little or no overhead for dev until we're more broadly ready for long term support So - if you want to make an incubator release branch thats fine with me but: - please make sure the docs in the branch and trunk explain the situation: - no guarantee of release - release stability - no guarantee of upgrade stability - it's a point-in-time snapshot of a moving story -Rob On 18 January 2014 02:18, James Slagle james.sla...@gmail.com wrote: On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote: Note that tripleo-incubator is special and should not be released. It is intentionally kept unfrozen and unreleased to make sure there is no illusion of stability. I think it would be nice if we could point people at a devtest that they could use with our other released stuff. Without that, we might make a change to devtest, such as showing the use of a new heat parameter in our templates, and if they're trying to follow along with a released tripleo-heat-templates then they would have a problem. Without a branch of incubator, there's no story or documentation around using any of our released stuff. You could follow along with devtest to get an idea of how it's supposed to work and indeed it might even work, but I don't think that's good enough. There is tooling in incubator that has proved it's usefulness. Take an example like setup-endpoints, what we're effectively saying without allowing people to use that is that there is a useful tool that will setup endpoints for you, but don't use it with our released stuff because it's not gauranteed to work and instead make these 10'ish calls to keystone via some other method. Then you'd also end up with a different but parallel set of instructions for using our released stuff vs. not. This is prohibitive to someone who may want to setup a tripleo CI/CD cloud deploying stable icehouse or from milestone branches. I think people would just create their own fork of tripleo-incubator and use that. If there are components in it that need releasing, they should be moved into relevant projects or forked into their own projects. I'd be fine with that approach, except that's pretty much everything in incubator, the scripts, templates, generated docs, etc. Instead of creating a new forked repo, why don't we just rename tripleo-incubator to tripleo-deployment and have some stable branches that people could use with our releases? I don't feel like that precludes tripleo from having no stability on the master branch at all. Excerpts from Ryan Brady's message of 2014-01-16 07:42:33 -0800: +1 for releases. In the past I requested a tag for tripleo-incubator to make it easier to build a package and test. In my case a common tag would be easier to track than trying to gather all of the commit hashes where the projects are compatible. Ryan - Original Message - From: James Slagle james.sla...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Thursday, January 16, 2014 10:13:58 AM Subject: [openstack-dev] [TripleO] milestone-proposed branches At last summit, we talked about doing stable branches and releases for the TripleO projects for Icehouse. I'd like to propose doing a milestone-proposed branch[1] and tagged release for icehouse milestones 2 and 3. Sort of as dry run and practice, as I think it could help tease out some things we might not have considered when we do try to do icehouse stable branches. The icehouse milestone 2 date is January 23rd [2]. So, if there is concensus to do this, we probably need to get the branches created soon, and then do any bugfixes in the branches (master too of course) up unitl the 23rd. I think it'd be nice if we had a working devtest to use with the released tarballs. This raises a couple of points: - We probably need a way in devtest to let people use a different branch (or tarball) of the stuff that is git cloned. - What about tripleo-incubator itself? We've said in the past we don't want to attempt to stabilize or release that due to it's incubator nature. But, if we don't have a stable set of devtest instructions (and accompanying scripts like setup-endpoints, etc), then using an ever changing devtest with the branches/tarballs is not likely to work for very long. And yes, I'm volunteering to do the work to support the above, and the release work :). Thoughts? [1] https://wiki.openstack.org/wiki/BranchModel [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [TripleO] milestone-proposed branches
tl;dr: You're right, it would be useful. Points on what is blocking it below: Excerpts from James Slagle's message of 2014-01-17 05:18:01 -0800: On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote: Note that tripleo-incubator is special and should not be released. It is intentionally kept unfrozen and unreleased to make sure there is no illusion of stability. I think it would be nice if we could point people at a devtest that they could use with our other released stuff. Without that, we might make a change to devtest, such as showing the use of a new heat parameter in our templates, and if they're trying to follow along with a released tripleo-heat-templates then they would have a problem. Without a branch of incubator, there's no story or documentation around using any of our released stuff. You could follow along with devtest to get an idea of how it's supposed to work and indeed it might even work, but I don't think that's good enough. There is tooling in incubator that has proved it's usefulness. Take an example like setup-endpoints, what we're effectively saying without allowing people to use that is that there is a useful tool that will setup endpoints for you, but don't use it with our released stuff because it's not gauranteed to work and instead make these 10'ish calls to keystone via some other method. Then you'd also end up with a different but parallel set of instructions for using our released stuff vs. not. I'll address the bigger points here below, but for the record, I think setup-endpoints and register-endpoint are stable enough now that they should just be included with keystoneclient or keystone. Perhaps rewritten as subcommands to the keystone cli, but even as-is they would be useful in keystoneclient's bin dir IMO. This is prohibitive to someone who may want to setup a tripleo CI/CD cloud deploying stable icehouse or from milestone branches. I think people would just create their own fork of tripleo-incubator and use that. If there are components in it that need releasing, they should be moved into relevant projects or forked into their own projects. I'd be fine with that approach, except that's pretty much everything in incubator, the scripts, templates, generated docs, etc. Instead of creating a new forked repo, why don't we just rename tripleo-incubator to tripleo-deployment and have some stable branches that people could use with our releases? I don't feel like that precludes tripleo from having no stability on the master branch at all. If we are prepared to make basic release-to-release stability guarantees for everything in incubator (or kick the few things we aren't prepared to do that for out to a new incubator) then huzzah! Lets do what you suggest above. :) I just don't think we're there yet, and I'd rather see us fork off the things that are ready as they get to that point rather than try to make a giant push to freeze the whole thing. I'm afraid we'd have users in a bad position by expecting the icehouse version of assert-user to still be there and keep working in Juno. To put some analysis where my rhetoric is, I've taken a look at all of the scripts. By my count there are 43 scripts, 10 of which are not really part of TripleO. By lines of code, there are about 1954 lines of actual code and 600 lines in the not TripleO parts. So between 20 and 30 percent of the code shouldn't be part of TripleO and should be pushed into their own releasable places. I've included the classifications below. Also before any of it gets released we need: * Gating * Commitment to real documentation * Thierry's blessing. :) ==Script classifications== CD cloud related - never freezes assert-users assert-admin-users assert-user -- Perhaps merge with os-adduser --Belongs in keystoneclient setup-endpoints register-endpoint os-adduser -- Might need a rename? --Belongs in glanceclient: load-image --Could be forked into a tripleo-devtest project: boot-seed-vm setup-network configure-vm create-nodes set-os-type devtest_setup.sh devtest_seed.sh devtest_variables.sh devtest.sh refresh-env cleanup-env devtest_ramdisk.sh extract-docs.awk devtest_undercloud.sh devtest_overcloud.sh write-tripleorc install-dependencies devtest_end.sh register-nodes extract-docs devtest_testenv.sh takeovernode --Not devtest only, releasable, but specific to TripleO: init-keystone setup-overcloud-passwords pull-tools setup-seed-vm stack-ready user-config get-vm-mac setup-clienttools setup-neutron setup-undercloud-passwords setup-baremetal --Useful, but too tiny for their own repo: os-make-password -- arguably we should just use pwgen wait_for send-irc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] milestone-proposed branches
On 18 January 2014 09:09, Clint Byrum cl...@fewbar.com wrote: tl;dr: You're right, it would be useful. Points on what is blocking it below: I'll address the bigger points here below, but for the record, I think setup-endpoints and register-endpoint are stable enough now that they should just be included with keystoneclient or keystone. Perhaps rewritten as subcommands to the keystone cli, but even as-is they would be useful in keystoneclient's bin dir IMO. They aren't really - I had to edit them yesterday :). We need to finish a full production deployment I think to properly assess that. And... with tuskar coming along we may not need these tools at all :). If we are prepared to make basic release-to-release stability guarantees for everything in incubator (or kick the few things we aren't prepared to do that for out to a new incubator) then huzzah! Lets do what you suggest above. :) I just don't think we're there yet, and I'd rather see us fork off the things that are ready as they get to that point rather than try to make a giant push to freeze the whole thing. I'm afraid we'd have users in a bad position by expecting the icehouse version of assert-user to still be there and keep working in Juno. Giant push to freeze the whole thing is quite different to I want to maintain a stable release of what we have now - if someone wants to do that, I think we should focus on enabling them, not on creating more work. That said, I think stable releases of CD'd tooling is an odd concept in itself, but thats a different discussion. -Rob -- 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] milestone-proposed branches
James Slagle wrote: [...] And yes, I'm volunteering to do the work to support the above, and the release work :). Let me know if you have any question or need help. The process and tools used for the integrated release are described here: https://wiki.openstack.org/wiki/Release_Team/How_To_Release Also note that we were considering switching from using milestone-proposed to using proposed/*, to avoid reusing branch names: https://review.openstack.org/#/c/65103/ -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] milestone-proposed branches
Note that tripleo-incubator is special and should not be released. It is intentionally kept unfrozen and unreleased to make sure there is no illusion of stability. If there are components in it that need releasing, they should be moved into relevant projects or forked into their own projects. Excerpts from Ryan Brady's message of 2014-01-16 07:42:33 -0800: +1 for releases. In the past I requested a tag for tripleo-incubator to make it easier to build a package and test. In my case a common tag would be easier to track than trying to gather all of the commit hashes where the projects are compatible. Ryan - Original Message - From: James Slagle james.sla...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Thursday, January 16, 2014 10:13:58 AM Subject: [openstack-dev] [TripleO] milestone-proposed branches At last summit, we talked about doing stable branches and releases for the TripleO projects for Icehouse. I'd like to propose doing a milestone-proposed branch[1] and tagged release for icehouse milestones 2 and 3. Sort of as dry run and practice, as I think it could help tease out some things we might not have considered when we do try to do icehouse stable branches. The icehouse milestone 2 date is January 23rd [2]. So, if there is concensus to do this, we probably need to get the branches created soon, and then do any bugfixes in the branches (master too of course) up unitl the 23rd. I think it'd be nice if we had a working devtest to use with the released tarballs. This raises a couple of points: - We probably need a way in devtest to let people use a different branch (or tarball) of the stuff that is git cloned. - What about tripleo-incubator itself? We've said in the past we don't want to attempt to stabilize or release that due to it's incubator nature. But, if we don't have a stable set of devtest instructions (and accompanying scripts like setup-endpoints, etc), then using an ever changing devtest with the branches/tarballs is not likely to work for very long. And yes, I'm volunteering to do the work to support the above, and the release work :). Thoughts? [1] https://wiki.openstack.org/wiki/BranchModel [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
