Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases
On 2016-04-19 15:34:16 -0400 (-0400), James Slagle wrote: > A fork would be unfortunate. What about a new repo that's just for > the elements used heavily by infra, e.g., > openstack-infra-elements. [...] We do already have a bunch of elements in openstack-infra/project-config, so most of the velocity concerns have been around "upstream" elements (lately a number of the -minimal distro variants as we've been migrating our nodepool deployment to rely heavily on dib). Decoupling the elements in diskimage-builder from the framework and maintaining them in separately-versioned repositories might help, but regardless Infra team consensus has been primarily to just keep collaborating on those common elements and find downstream workarounds while we wait for bug fixing iteration to take place and releases to be tagged. > I definitely think dib is part of "OpenStack the Product" given it > has to be used by users and operators of TripleO. Makes sense! It's also possible some of the elements bundled in diskimage-builder aren't actually used in "OpenStack the Product" and are just along for the ride, but I don't really know enough about the other consuming projects to be able to say either way. -- Jeremy Stanley __ 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][releases] Remove diskimage-builder from releases
Excerpts from Ian Wienand's message of 2016-04-20 06:25:17 +1000: > On 04/20/2016 03:25 AM, Doug Hellmann wrote: > > It's not just about control, it's also about communication. One of > > the most frequent refrains we hear is "what is OpenStack", and one > > way we're trying to answer that is to publicize all of the things > > we release through releases.openstack.org. > > So for dib, this is mostly about documentation? This isn't about DIB in particular. The change wasn't made because you were doing anything wrong, or not doing something. It's about not having a bunch of special case exceptions so that all projects work the same way and everyone understands what it means to be part of the official project list. DIB, as an official project, was included in the list of repositories for which I adjusted the ACLs. After discussing it with the release team, we're proposing that we revert the ACL changes for projects using the release:independent model. Those projects are already declaring, through that model, that they are not part of the openstack release cycle, and hence not part of what is being managed by the release team. To that end, I've proposed https://review.openstack.org/308044. I've also proposed updates to the governance tag definitions to document the expectations related to this issue for the release tags: https://review.openstack.org/308045 So, consider what model you want to use. If release:independent works for you, then you can keep tagging when you want, and if you care to advertise those releases you can propose changes to openstack/releases after the fact. If you want a release:cycle-* tag, we'll have to figure out how to incorporate the review step in your release process because project tagged as part of the cycle are very definitely things we're managing as part of the product. That said, another goal of the automation work was to provide a way to have tags reviewed before they were applied, though, so I do expect that some time in the future we will have *all* deliverables for all projects going through the tag review process. That will wait until the automation is completed and we have a larger team of reviewers (it will be easier to add members to the team when it isn't necessary to set up a bunch of tools to run locally). At that point I would expect to have enough folks on the team doing those reviews that there would be no schedule-based reason for a project to be unable to manage its tags that way. Doug __ 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][releases] Remove diskimage-builder from releases
On Tue, Apr 19, 2016, at 01:25 PM, Ian Wienand wrote: > On 04/20/2016 03:25 AM, Doug Hellmann wrote: > > It's not just about control, it's also about communication. One of > > the most frequent refrains we hear is "what is OpenStack", and one > > way we're trying to answer that is to publicize all of the things > > we release through releases.openstack.org. > > So for dib, this is mostly about documentation? > > We don't have the issues around stable branches mentioned in the > readme, nor do we worry about the requirements/constraints (proposal > bot has always been sufficient?). > > > Centralizing tagging also helps us ensure consistent versioning > > rules, good timing, good release announcements, etc. > > We so far haven't had issues keeping the version number straight. > > As mentioned, the timing has extra constraints due to use in periodic > infra jobs that I don't think the release team want to be involved > with. It's not like the release team will be going through the > changes in a new release and deciding if they seem OK or not (although > they're welcome to do dib reviews, before things get committed :) So I > don't see what timing constraints will be monitored in this case. > > When you look at this from my point of view, dib was left/is in an > unreleasable state that I've had to clean up [1], we've now missed yet > another day's build [2] and I'm not sure what's different except I now > have to add probably 2 days latency to the process of getting fixes > out there. > > To try and be constructive : is what we want a proposal-bot job that > polls for the latest release and adds it to the diskimage-builder.yaml > file? That seems to cover the documentation component of this. > > Or, if you want to give diskimage-builder-release group permissions on > the repo, so we can +2 changes on the diskimage-builder.yaml file, we > could do that. [3] > > -i > > [1] https://review.openstack.org/#/c/306925/ > [2] https://review.openstack.org/#/c/307542/ > [3] my actual expectation of this happening is about zero I think I have a handle on the different release tags after some reading / IRC chat, and AIUI - as long as DIB is an official project then in the current system it's releases will be going through the release team. Therefore, the discussion about release tag type isn't really relevant to the concerns we seem to be bringing up which mostly center around us worrying over the new step required to get a release out - there doesn't exist a tag which will change this. My concern with this extra step is mostly wondering what the practical benefit to us is? Obviously there is some complexity being added to us getting out a release, and were also involving a whole new team of folks in doing this, so I think this absolutely warrants some benefit over the existing system to us. There's a couple obvious things (having releases go through review rather than just git push is extremely nice), but IMO this doesn't outweigh the downsides of adding an additional review team. I also feel like this is an issue we could solve while still allowing us to retain release control. So, a couple questions: * Is there disagreement with the sentiment that adding the extra releases review team to our release process is not desirable for DIB? I am really wondering if there's some practical benefit here we might be missing... * Are there some benefits inherent to the extra releases review team that we are missing and outweigh the benefits of the added process? I want to make sure to distinguish between things (like gerrit perms with our existing setup) which we could work with the releases team to fix, and things that we can't. Thanks, Greg __ 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][releases] Remove diskimage-builder from releases
On 04/20/2016 06:09 AM, Fox, Kevin M wrote: I've seen dib updated and broken things. I've seen dib elements updated and things broke (centos6 removal in particular hurt.) By the time it gets to a release, however, anything we've broken is already baked in. Any changes in there have already passed review and whatever CI we have. (not to say we can't do better CI to break stuff less. But that's outside the release team's responsibility) -i __ 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][releases] Remove diskimage-builder from releases
On 04/20/2016 03:25 AM, Doug Hellmann wrote: It's not just about control, it's also about communication. One of the most frequent refrains we hear is "what is OpenStack", and one way we're trying to answer that is to publicize all of the things we release through releases.openstack.org. So for dib, this is mostly about documentation? We don't have the issues around stable branches mentioned in the readme, nor do we worry about the requirements/constraints (proposal bot has always been sufficient?). Centralizing tagging also helps us ensure consistent versioning rules, good timing, good release announcements, etc. We so far haven't had issues keeping the version number straight. As mentioned, the timing has extra constraints due to use in periodic infra jobs that I don't think the release team want to be involved with. It's not like the release team will be going through the changes in a new release and deciding if they seem OK or not (although they're welcome to do dib reviews, before things get committed :) So I don't see what timing constraints will be monitored in this case. When you look at this from my point of view, dib was left/is in an unreleasable state that I've had to clean up [1], we've now missed yet another day's build [2] and I'm not sure what's different except I now have to add probably 2 days latency to the process of getting fixes out there. To try and be constructive : is what we want a proposal-bot job that polls for the latest release and adds it to the diskimage-builder.yaml file? That seems to cover the documentation component of this. Or, if you want to give diskimage-builder-release group permissions on the repo, so we can +2 changes on the diskimage-builder.yaml file, we could do that. [3] -i [1] https://review.openstack.org/#/c/306925/ [2] https://review.openstack.org/#/c/307542/ [3] my actual expectation of this happening is about zero __ 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][releases] Remove diskimage-builder from releases
On Tue, Apr 19, 2016, at 10:25 AM, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +: > > On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote: > > > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: > > [...] > > > > I don't expect the stable release team to be involved with all this; > > > > but if we miss windows then we're left either going to efforts getting > > > > one of a handful of people with permissions to do manual rebuilds or > > > > waiting yet another day to get something fixed. Add some timezones > > > > into this, and simple fixes are taking many days to get into builds. > > > > Thus adding points where we can extend this by another 24 hours > > > > really, well, sucks. > > > > > > How often does that situation actually come up? > > > > Semi-often. The project is officially under TripleO but it's sort of > > a shared jurisdiction between some TripleO and Infra contributors. I > > think the release team for diskimage-builder used to shoot for > > tagging weekly (sans emergencies), though that's slacked off a bit > > and is more like every 2 weeks lately. > > That's about the same as or less often than we tag Oslo libraries. > > > DIB is an unfortunate combination of a mostly stable framework and a > > large pre-written set of scripts and declarative data which is > > constantly evolving for widespread use outside the OpenStack > > ecosystem (so most of the change volume is to the latter). As Ian > > points out, the Infra team has already been tempted to stop relying > > on DIB releases at all (or worse, maintain a fork) to reduce overall > > latency for getting emergency fixes reflected in our worker images. > > Sure, that's a compelling argument. I'm not opposed to making it easier > for timely releases, just trying to understand the pressure. > > > I suspect that most of the concern over using OpenStack release > > process for DIB (and similarly Infra projects) is that the added > > complexities introduce delays, especially if there's not a release > > team member available to do on-the-spot approvals on weekends and > > such. I don't know whether extending that to add tagging ACLs for > > the library-release group would help? That would bring the total up > > to 6 people, two more of whom are in non-American timezones, so > > might be worth a try. > > > > It's also worth keeping in mind that we've sort of already > > identified two classes of official OpenStack projects. One is > > "OpenStack the Product" only able to be distributed under the Apache > > license and its contributors bound by a contributor license > > agreement. The other is the output of a loose collective of groups > > writing ancillary tooling consumed by the OpenStack community and > > also often used for a lot of other things completely unrelated to > > OpenStack. I can see where strict coordinated release process and > > consistency for the former makes sense, but a lot of projects in the > > latter category likely see it as unnecessary overkill for their > > releases. > > It's not just about control, it's also about communication. One of > the most frequent refrains we hear is "what is OpenStack", and one > way we're trying to answer that is to publicize all of the things > we release through releases.openstack.org. Centralizing tagging > also helps us ensure consistent versioning rules, good timing, good > release announcements, etc. > > Since dib is part of tripleo, and at least 2 other projects depend > on it directly (sahara-image-elements and manila-image-elements), > I would expect the tripleo team to want it included on the site, > to publish release announcements, etc. > > On the other hand, dib is using the release:independent model, which > indicates that the team in fact doesn't think it should be considered > part of the "product." Maybe we can use that as our flag for which > projects should really be managed by the release team and which > should not, but we don't want projects that want to be part of official > releases to use that model. > > With what I know today, I can't tell which side of the line dib is > really on. Maybe someone can clarify? > > Doug There is a bit more nuance to getting releases out for downstream consumers than just getting DIB fixes out quickly. Often there is a situation where a downstream needs a fix/feature soonish but not critically - maybe DIB is creating images for infra where networking is not working due to a dib bug. Infra can delete the last round of images and still function but its worthwhile to get things fixed soon. In that case we don't want to just rush a release out the door (there's often other things which have been merged and carry some risk), and we (or at least I) like to wait to cut a DIB release until a morning, preferably when a DIB core is around to help debug / verify the fix and any fallout. I am not sure there is an easy fix where we can keep this model without being rele
Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases
As an Op, I've been bitten by both sides of this I've seen dib updated and broken things. I've seen dib elements updated and things broke (centos6 removal in particular hurt.) I've appreciated dib elements getting fixed quickly at times because distro's changed, and the element needed change too and so I didn't have to continue to work around issues. So, I can't say which way forward is best. Just that care has to be taken in all cases. :) Thanks, Kevin From: James Slagle [james.sla...@gmail.com] Sent: Tuesday, April 19, 2016 12:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley wrote: > DIB is an unfortunate combination of a mostly stable framework and a > large pre-written set of scripts and declarative data which is > constantly evolving for widespread use outside the OpenStack > ecosystem (so most of the change volume is to the latter). As Ian > points out, the Infra team has already been tempted to stop relying > on DIB releases at all (or worse, maintain a fork) to reduce overall > latency for getting emergency fixes reflected in our worker images. A fork would be unfortunate. What about a new repo that's just for the elements used heavily by infra, e.g., openstack-infra-elements. As you say, the dib interface is pretty stable, are most of the emergency fixes from the past mostly in elements themselves? You could have openstack-infra-elements be release:independent, giving you the freedom to release emergency fixes as quickly as needed. > It's also worth keeping in mind that we've sort of already > identified two classes of official OpenStack projects. One is > "OpenStack the Product" only able to be distributed under the Apache > license and its contributors bound by a contributor license > agreement. The other is the output of a loose collective of groups > writing ancillary tooling consumed by the OpenStack community and > also often used for a lot of other things completely unrelated to > OpenStack. I can see where strict coordinated release process and > consistency for the former makes sense, but a lot of projects in the > latter category likely see it as unnecessary overkill for their > releases. I definitely think dib is part of "OpenStack the Product" given it has to be used by users and operators of TripleO. -- -- 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 __ 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][releases] Remove diskimage-builder from releases
On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley wrote: > DIB is an unfortunate combination of a mostly stable framework and a > large pre-written set of scripts and declarative data which is > constantly evolving for widespread use outside the OpenStack > ecosystem (so most of the change volume is to the latter). As Ian > points out, the Infra team has already been tempted to stop relying > on DIB releases at all (or worse, maintain a fork) to reduce overall > latency for getting emergency fixes reflected in our worker images. A fork would be unfortunate. What about a new repo that's just for the elements used heavily by infra, e.g., openstack-infra-elements. As you say, the dib interface is pretty stable, are most of the emergency fixes from the past mostly in elements themselves? You could have openstack-infra-elements be release:independent, giving you the freedom to release emergency fixes as quickly as needed. > It's also worth keeping in mind that we've sort of already > identified two classes of official OpenStack projects. One is > "OpenStack the Product" only able to be distributed under the Apache > license and its contributors bound by a contributor license > agreement. The other is the output of a loose collective of groups > writing ancillary tooling consumed by the OpenStack community and > also often used for a lot of other things completely unrelated to > OpenStack. I can see where strict coordinated release process and > consistency for the former makes sense, but a lot of projects in the > latter category likely see it as unnecessary overkill for their > releases. I definitely think dib is part of "OpenStack the Product" given it has to be used by users and operators of TripleO. -- -- 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][releases] Remove diskimage-builder from releases
On Tue, Apr 19, 2016 at 1:25 PM, Doug Hellmann wrote: > It's not just about control, it's also about communication. One of > the most frequent refrains we hear is "what is OpenStack", and one > way we're trying to answer that is to publicize all of the things > we release through releases.openstack.org. Centralizing tagging > also helps us ensure consistent versioning rules, good timing, good > release announcements, etc. > > Since dib is part of tripleo, and at least 2 other projects depend > on it directly (sahara-image-elements and manila-image-elements), > I would expect the tripleo team to want it included on the site, > to publish release announcements, etc. > > On the other hand, dib is using the release:independent model, which > indicates that the team in fact doesn't think it should be considered > part of the "product." Maybe we can use that as our flag for which > projects should really be managed by the release team and which > should not, but we don't want projects that want to be part of official > releases to use that model. > > With what I know today, I can't tell which side of the line dib is > really on. Maybe someone can clarify? dib is part of a TripleO "release" given it's used by users to both install the Undercloud and build Overcloud images. IMO, I think it makes sense to move it from release:independent to release:cycle-with-intermediary. Just fyi, the topic of choosing the right release tags for all the TripleO projects just came up in the TripleO meeting today in light of moving to the centralized release tagging. I would think all the projects would be moving from release:independent to the proposed release:cycle-trailing or release:cycle-with-intermediary. -- -- 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][releases] Remove diskimage-builder from releases
Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +: > On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote: > > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: > [...] > > > I don't expect the stable release team to be involved with all this; > > > but if we miss windows then we're left either going to efforts getting > > > one of a handful of people with permissions to do manual rebuilds or > > > waiting yet another day to get something fixed. Add some timezones > > > into this, and simple fixes are taking many days to get into builds. > > > Thus adding points where we can extend this by another 24 hours > > > really, well, sucks. > > > > How often does that situation actually come up? > > Semi-often. The project is officially under TripleO but it's sort of > a shared jurisdiction between some TripleO and Infra contributors. I > think the release team for diskimage-builder used to shoot for > tagging weekly (sans emergencies), though that's slacked off a bit > and is more like every 2 weeks lately. That's about the same as or less often than we tag Oslo libraries. > DIB is an unfortunate combination of a mostly stable framework and a > large pre-written set of scripts and declarative data which is > constantly evolving for widespread use outside the OpenStack > ecosystem (so most of the change volume is to the latter). As Ian > points out, the Infra team has already been tempted to stop relying > on DIB releases at all (or worse, maintain a fork) to reduce overall > latency for getting emergency fixes reflected in our worker images. Sure, that's a compelling argument. I'm not opposed to making it easier for timely releases, just trying to understand the pressure. > I suspect that most of the concern over using OpenStack release > process for DIB (and similarly Infra projects) is that the added > complexities introduce delays, especially if there's not a release > team member available to do on-the-spot approvals on weekends and > such. I don't know whether extending that to add tagging ACLs for > the library-release group would help? That would bring the total up > to 6 people, two more of whom are in non-American timezones, so > might be worth a try. > > It's also worth keeping in mind that we've sort of already > identified two classes of official OpenStack projects. One is > "OpenStack the Product" only able to be distributed under the Apache > license and its contributors bound by a contributor license > agreement. The other is the output of a loose collective of groups > writing ancillary tooling consumed by the OpenStack community and > also often used for a lot of other things completely unrelated to > OpenStack. I can see where strict coordinated release process and > consistency for the former makes sense, but a lot of projects in the > latter category likely see it as unnecessary overkill for their > releases. It's not just about control, it's also about communication. One of the most frequent refrains we hear is "what is OpenStack", and one way we're trying to answer that is to publicize all of the things we release through releases.openstack.org. Centralizing tagging also helps us ensure consistent versioning rules, good timing, good release announcements, etc. Since dib is part of tripleo, and at least 2 other projects depend on it directly (sahara-image-elements and manila-image-elements), I would expect the tripleo team to want it included on the site, to publish release announcements, etc. On the other hand, dib is using the release:independent model, which indicates that the team in fact doesn't think it should be considered part of the "product." Maybe we can use that as our flag for which projects should really be managed by the release team and which should not, but we don't want projects that want to be part of official releases to use that model. With what I know today, I can't tell which side of the line dib is really on. Maybe someone can clarify? Doug __ 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][releases] Remove diskimage-builder from releases
On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote: > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: [...] > > I don't expect the stable release team to be involved with all this; > > but if we miss windows then we're left either going to efforts getting > > one of a handful of people with permissions to do manual rebuilds or > > waiting yet another day to get something fixed. Add some timezones > > into this, and simple fixes are taking many days to get into builds. > > Thus adding points where we can extend this by another 24 hours > > really, well, sucks. > > How often does that situation actually come up? Semi-often. The project is officially under TripleO but it's sort of a shared jurisdiction between some TripleO and Infra contributors. I think the release team for diskimage-builder used to shoot for tagging weekly (sans emergencies), though that's slacked off a bit and is more like every 2 weeks lately. DIB is an unfortunate combination of a mostly stable framework and a large pre-written set of scripts and declarative data which is constantly evolving for widespread use outside the OpenStack ecosystem (so most of the change volume is to the latter). As Ian points out, the Infra team has already been tempted to stop relying on DIB releases at all (or worse, maintain a fork) to reduce overall latency for getting emergency fixes reflected in our worker images. I suspect that most of the concern over using OpenStack release process for DIB (and similarly Infra projects) is that the added complexities introduce delays, especially if there's not a release team member available to do on-the-spot approvals on weekends and such. I don't know whether extending that to add tagging ACLs for the library-release group would help? That would bring the total up to 6 people, two more of whom are in non-American timezones, so might be worth a try. It's also worth keeping in mind that we've sort of already identified two classes of official OpenStack projects. One is "OpenStack the Product" only able to be distributed under the Apache license and its contributors bound by a contributor license agreement. The other is the output of a loose collective of groups writing ancillary tooling consumed by the OpenStack community and also often used for a lot of other things completely unrelated to OpenStack. I can see where strict coordinated release process and consistency for the former makes sense, but a lot of projects in the latter category likely see it as unnecessary overkill for their releases. -- Jeremy Stanley __ 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][releases] Remove diskimage-builder from releases
Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: > Hi, > > diskimage-builder has fallen under the "centralised release tagging" > mechanism [1], presumably because it is under tripleo. I'd like to > propose that we don't do that. Yes, we've set up all official projects to use the central release request system this cycle. > > Firstly, dib doesn't have any branches to manage. This change doesn't have anything to do with branches. > > dib's other main function is as part of the daily CI image builds. > This means to get a fix into the CI images in a somewhat timely > fashion, we approve the changes and make sure our releases happen > before 14:00 UTC, and monitor the build results closely in nodepool. > > I don't expect the stable release team to be involved with all this; > but if we miss windows then we're left either going to efforts getting > one of a handful of people with permissions to do manual rebuilds or > waiting yet another day to get something fixed. Add some timezones > into this, and simple fixes are taking many days to get into builds. > Thus adding points where we can extend this by another 24 hours > really, well, sucks. How often does that situation actually come up? Doug > > I have previously suggested running dib from git directly to avoid the > release shuffle, but it was felt this was not the way to go [2]. I've > proposed putting the release group back with [3] and cleaning up with > [4]. > > Thanks, > > -i > > [1] https://review.openstack.org/298866 > [2] https://review.openstack.org/283877 > [3] https://review.openstack.org/307531 > [4] https://review.openstack.org/307534 > __ 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][releases] Remove diskimage-builder from releases
Hi, diskimage-builder has fallen under the "centralised release tagging" mechanism [1], presumably because it is under tripleo. I'd like to propose that we don't do that. Firstly, dib doesn't have any branches to manage. dib's other main function is as part of the daily CI image builds. This means to get a fix into the CI images in a somewhat timely fashion, we approve the changes and make sure our releases happen before 14:00 UTC, and monitor the build results closely in nodepool. I don't expect the stable release team to be involved with all this; but if we miss windows then we're left either going to efforts getting one of a handful of people with permissions to do manual rebuilds or waiting yet another day to get something fixed. Add some timezones into this, and simple fixes are taking many days to get into builds. Thus adding points where we can extend this by another 24 hours really, well, sucks. I have previously suggested running dib from git directly to avoid the release shuffle, but it was felt this was not the way to go [2]. I've proposed putting the release group back with [3] and cleaning up with [4]. Thanks, -i [1] https://review.openstack.org/298866 [2] https://review.openstack.org/283877 [3] https://review.openstack.org/307531 [4] https://review.openstack.org/307534 __ 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
