Re: [openstack-dev] [tripleo][ui] Dependency management
On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichonwrote: > On 19 January 2018 at 18:43, Honza Pokorny wrote: >> We've recently discovered an issue with the way we handle dependencies for >> tripleo-ui. This is an explanation of the problem, and a proposed solution. >> I'm looking for feedback. >> >> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for >> tripleo-ui: >> >> * Native npm jobs >> * Undercloud integration jobs >> >> After the upgrade, the integration jobs went away. Our goal is to add them >> back. >> >> There is a difference in how these two types of jobs handle dependencies. >> Native npm jobs use the "npm install" command to acquire packages, and >> undercloud jobs use RPMs. The tripleo-ui project uses a separate RPM for >> dependencies called openstack-tripleo-ui-deps. >> >> Because of the requirement to use a separate RPM for dependencies, there is >> some >> extra work needed when a new dependency is introduced, or an existing one is >> upgraded. Once the patch that introduces the dependency is merged, we have >> to >> increment the version of the -deps package, and rebuild it. It then shows >> up in >> the yum repos used by the undercloud. >> >> To make matters worse, we recently upgraded our infrastructure to nodejs >> 8.9.4 >> and npm 5.6.0 (latest stable). This makes it so we can't write "purist" >> patches >> that simply introduce a new dependency to package.json, and nothing more. >> The >> code that uses the new dependency must be included. I tend to think that >> each >> commit should work on its own so this can be seen as a plus. >> >> This presents a problem: you can't get a patch that introduces a new >> dependency >> merged because it's not included in the RPM needed by the undercloud ci job. >> >> So, here is a proposal on how that might work: >> >> 1. Submit a patch for review that introduces the dependency, along with code >>changes to support it and validate its inclusion >> 2. Native npm jobs will pass >> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM >> 4. We ask RDO to review for licensing >> 5. Once reviewed, new -deps package is built >> 6. Recheck >> 7. All jobs pass > > Perhaps there should be a step after 3 or 4 to have the patch normally > reviewed, and wait for it to have two +2s before building the new > package? Otherwise we may end up with wasted work to get a new package > ready for dependencies that were eventually dismissed. Thanks Julie for reminding me of this thread! I agree we can only build ui-deps package when the review is about to merge. I've proposed https://github.com/rdo-common/openstack-tripleo-ui-deps/pull/19 which allows us to build the package with the review and patchset numbers, before it's merged. Please review and we can try it on the next deps update! Cheers, Alan __ 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][release][deployment] Packaging problems due to branch/release ordering
2017-03-13 15:49 GMT+01:00 Doug Hellmann: ... > We test this upgrade scenario in the upstream CI, too. The difference > is that grenade can tell pip "install exactly the version I am > pointing to in this directory on disk," rather than relying on > version numbers to notice that an upgrade is needed (or should be > avoided, as the case may be). > > Is it possible to do that with system packages in some way, too, without > pinning package versions in puppet or tripleo? That would not test the regular update flow, we'd have to use workaround for the period before milestone 1 and run explicit yum downgrade with the explicit package list to force lower version packages to install. That means real upgrades would not be tested until this kludge is removed after first milestone is released. Instead, I'll look at adding automatic bump in RDO Trunk builder before milestone1 i.e. when it detects master version is lower than stable branches. Cheers, Alan __ 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][release][deployment] Packaging problems due to branch/release ordering
2017-03-09 14:58 GMT+01:00 Jeremy Stanley: > In the past we addressed this by automatically merging the release > tag back into master, but we stopped doing that a cycle ago because > it complicated release note generation. Also this was including RC >= 2 and final tags so as soon as the first stable maintenance version was released, master was again lower version. Cheers, Alan __ 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][release][deployment] Packaging problems due to branch/release ordering
2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso: > On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy wrote: >> https://bugs.launchpad.net/tripleo/+bug/1669462 >> >> I'm not clear on the best path forward at this point, but the simplest one >> suggested so far is to simply tag a new pre-milestone/alpha release for all >> master branches, which will enable testing upgrades to master. That would be indeed simplest and cleanest solution but it has been rejected in the past, IIUC with reasoning that projects are not sure what will be their next version. IMHO that should not be the case if the project has decided to have a stable branch and follows semver and stable branch policy: in that case project will keep X.Y frozen on stable so master should be bumped to at least X.Y+1 immediately after branching stable. For a project using PBR postversioning (almost all by now) this can be achieved by either pushing the appropriate alpha git tag or by using PBR Sem-Ver: feature https://docs.openstack.org/developer/pbr/#version Now, purists would complain that artificial commit right after branching is not really adding a feature but you could look at it as a credit because you surely will implement new features in the new version! If project is without stable:follows-policy tag and it will keep adding features on the stable branch, increasing Y part of semver or if they already decided to bump X major version, Sem-Ver: api-break can be used. Example for TripleO projects for opening Ocata: https://review.openstack.org/#/q/topic:open-ocata+Sem-Ver: > As reference, puppet team proposed a solution for this issue in > openstack puppet modules in > http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html > > However, as mentioned before this is affecting all projects, not only > puppet ones. Solution for OpenStack Puppet modules is to explicitly set pre-version in metadata.json. We had used pre-versioning before in regular OpenStack projects by setting version in setup.cfg but this has been abandoned and instead we rely on PBR to compute the next version. >> I know we don't expect to fully support upgrades to pre-milestone releases, >> but the requirement here is to simply enable testing them. >> >> A side-benefit of this regular testing e.g via CI is we'll find upgrade >> issues >> much faster than waiting for one or more milestone releases to happen then >> doing an upgrade-debug firedrill later in the cycle (which has been bad for >> project and deployment teams IMO, so it'd be good to figure out this first >> step to enable earlier testing of upgrades to the development release). >> >> Any thoughts on how we can resolve this would be much appreciated, thanks! I was suggested that upgrade jobs could force install i.e. basically doing downgrades before milestone1 but that's not testing upgrades! Versioning is very fundamental for packaging and reflects upstream version, we cannot fake versions in packaging. In the spirit of Continuous Everything, versioning should also be continuous and ensured that master version is always > previous releases. Projects doing stable branches could take action individually using Sem-Ver keyword but better would be to define this as a rule for having stable branches and enforce it cross projects by the release procedure. Cheers, Alan __ 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] FFE to add Congress to Triple-o
Waiting for Alan to give -1/+1 on the RDO side, but it's a +1 for me on the TripleO side. +1 from me, I should finish missing PuLP dependency in RDO today __ 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] [release][stable] nominating Alan Pevec (apevec) for stable release core
> Welcome to the team, Alan! Thanks all! Alan __ 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] [rdo-list] [RDO][DLRN] DLRN worker downtime during the weekend
> We need to run some maintenance operations on the DLRN instance next weekend, > starting on Friday 13 @ 19:00 UTC. I've aborted the purge and restarted Ocata master builder so we can get reverts built for CI blocker https://bugs.launchpad.net/nova/+bug/1656276 Cheers, Alan __ 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] [ironic] [stable] Proposing Jay Faulkner for ironic-stable-maint
> Well, apparently I don't have access to add you, so we'll have > to wait for Tony or someone else from the stable team to do that > thing. :) Done and welcome Jay! Cheers, Alan __ 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] [stable][release] Final releases for stable/liberty and liberty-eol
> 1. Final stable/liberty releases should happen next week, probably by > Thursday 11/17. I see only Cinder did it https://review.openstack.org/397282 and Nova is under review https://review.openstack.org/397841 Is that all or other project are not aware Liberty is EOL now? Cheers, Alan __ 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] possible backports for stable/newton
> Since our cherry picks don't seem to be considered equivalents by git > (probably because of modified commit messages) I'd like to understand why is that, do you have an example? It should work when recommendation[*] is followed. Cheers, Alan [*] http://docs.openstack.org/project-team-guide/stable-branches.html#change-ids __ 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] [packstack] Proposal to add Alfredo Moralejo as core reviewer
> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core > reviewer for Packstack. +1 With Alfredo in packstack-core, Spanish-speaking population will gain relative majority and we should totally rename it to Packistack ;) Cheers, Alan __ 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] [release] RDO Newton packages released
The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions - CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project ( http://openstack.org ), which is the work of more than 2700 contributors from around the world. (Source http://stackalytics.com/ ) The RDO community project ( https://www.rdoproject.org/ ) curates, packages, builds, tests, and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. At latest count, RDO contains 1157 packages ( https://www.rdoproject.org/documentation/package-list/ ). All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. Getting Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try the RDO QuickStart ( http://rdoproject.org/Quickstart ) You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use the TripleO Quickstart ( https://www.rdoproject.org/tripleo/ ) and you'll be running a production cloud in short order. Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack ( http://trystack.org/ ), where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack Getting Help The RDO Project participates in a Q service at ask.openstack.org ( http://ask.openstack.org ), for more developer oriented content we recommend joining the rdo-list mailing list ( https://www.redhat.com/mailman/listinfo/rdo-list ). Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site ( https://www.rdoproject.org/documentation ). The #rdo channel on Freenode IRC is also an excellent place to find help and give help. We also welcome comments and requests on the CentOS Mailing lists ( https://lists.centos.org/ ) and the CentOS IRC Channels (#centos, and #centos-devel, on irc.freenode.net), however we have a more focused audience in the RDO venues. Getting Involved To get involved in the OpenStack RPM packaging effort, see the RDO community pages ( https://www.rdoproject.org/community/ ) and the CentOS Cloud SIG page ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). See also the RDO packaging documentation ( https://www.rdoproject.org/packaging/ ). Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity ( http://twitter.com/rdocommunity ) on Twitter. If you prefer Facebook, we're there too ( http://facebook.com/rdocommunity ), and also Google+ ( http://tm3.org/rdogplus ). And, if you're going to be in Barcelona for the OpenStack Summit ( http://openstack.org/summit/ ) two weeks from now, join us on Tuesday evening at the Barcelona Princess, 5pm - 8pm, for an evening with the RDO and Ceph communities. If you can't make it in person, we'll be streaming it on YouTube ( https://www.youtube.com/watch?v=ji-WqEXZRTY ). Cheers, Alan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] [release] RDO Newton packages released
The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions - CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project ( http://openstack.org ), which is the work of more than 2700 contributors from around the world. (Source http://stackalytics.com/ ) The RDO community project ( https://www.rdoproject.org/ ) curates, packages, builds, tests, and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. At latest count, RDO contains 1157 packages ( https://www.rdoproject.org/documentation/package-list/ ). All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. Getting Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try the RDO QuickStart ( http://rdoproject.org/Quickstart ) You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use the TripleO Quickstart ( https://www.rdoproject.org/tripleo/ ) and you'll be running a production cloud in short order. Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack ( http://trystack.org/ ), where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack Getting Help The RDO Project participates in a Q service at ask.openstack.org ( http://ask.openstack.org ), for more developer oriented content we recommend joining the rdo-list mailing list ( https://www.redhat.com/mailman/listinfo/rdo-list ). Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site ( https://www.rdoproject.org/documentation ). The #rdo channel on Freenode IRC is also an excellent place to find help and give help. We also welcome comments and requests on the CentOS Mailing lists ( https://lists.centos.org/ ) and the CentOS IRC Channels (#centos, and #centos-devel, on irc.freenode.net), however we have a more focused audience in the RDO venues. Getting Involved To get involved in the OpenStack RPM packaging effort, see the RDO community pages ( https://www.rdoproject.org/community/ ) and the CentOS Cloud SIG page ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). See also the RDO packaging documentation ( https://www.rdoproject.org/packaging/ ). Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity ( http://twitter.com/rdocommunity ) on Twitter. If you prefer Facebook, we're there too ( http://facebook.com/rdocommunity ), and also Google+ ( http://tm3.org/rdogplus ). And, if you're going to be in Barcelona for the OpenStack Summit ( http://openstack.org/summit/ ) two weeks from now, join us on Tuesday evening at the Barcelona Princess, 5pm - 8pm, for an evening with the RDO and Ceph communities. If you can't make it in person, we'll be streaming it on YouTube ( https://www.youtube.com/watch?v=ji-WqEXZRTY ). Cheers, Alan __ 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] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
2016-09-22 15:58 GMT+02:00 Matt Riedemann: > 1. We don't bump minimums just because a new thing comes out in a given > release, we only bump minimums when something that uses that dependency > needs a higher minimum version. > > 2. Looking at this: > > https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml > > I read the first release of oslo.concurrency in liberty was 1.9.0, not > 2.6.0. I meant first after stable/liberty was branched, without bumping to that before release we end up with a situation like this, where we don't have a release vehicle for stable fixes in the libraries. Cheers, Alan __ 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] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
> We have: > * global-requirements.txt: > origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 But wasn't that wrong from the start? First Liberty release of oslo.concurrency was 2.6.0 why was that not bumped in g-r ? Cheers, Alan __ 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] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"
2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy: >> (3) Do nothing, leave the bug unfixed in stable/liberty > > That was the unspoken third option, thanks for spelling it out. :-) Yes, let's abandon both reviews. Cheers, Alan __ 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] [oslo.db] [release] opportunistic tests breaking randomly
> Olso.db 4.13.3 did hit the scene about the time this showed up. So I > think we need to strongly consider blocking it and revisiting these > issues post newton. So that means reverting all stable/newton changes, previous 4.13.x have been already blocked https://review.openstack.org/365565 How would we proceed, do we need to revert all backport on stable/newton? Cheers, Alan __ 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] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group
+1 __ 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] Delorean fail blocks CI for stable branches
On Thu, Jul 21, 2016 at 12:42 PM, Derek Higginswrote: > Trying to catch up here and summarizing as a top post ack for the summary > either of these, based only on which was proposed first i'd go for > 345070 ack, I've abandoned 345106 > Start a discussion in rdo about how exactly people expect --local and > --dev to behave and if there is need for a 3rd option to cover the > tripleo use case, If we find any changes are needed to delorean, make > them and then remove the hacks from tripleo-ci so we're less likely to > hit problems in future. IIRC Javer fixed --local to avoid some edge case we have hit when running DLRN in production on trunk.rdoproject.org but I forgot details, he'll chime-in when he's back from PTO. Explicit --local-source would cover tripleo ci use-case, but let's first collect all requirements in https://github.com/openstack-packages/DLRN/issues/22 e.g. tripleo.sh script also has a sed patch to make postinstall step optional, so let's address all interfaces at the same time. Cheers, Alan __ 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] Delorean fail blocks CI for stable branches
On Wed, Jul 20, 2016 at 7:49 PM, Sagi Shnaidmanwrote: > How then it worked before? Can you show me the patch that broke this > functionality in delorean? It should be about 15 Jul when jobs started to > fail. commented in lp > How then master branch works? It also runs on patched repo and succeeds. I explained that but looks like we're talking past each other. > I don't think we can use this workaround, each time this source file will > change - all our jobs will fail again? It's not even a workaround. > Please let's stop discussing and let's solve it finally, it blocks our CI > for stable patches. Sure, I've assigned https://bugs.launchpad.net/tripleo/+bug/1604039 to myself and proposed a patch. Alan __ 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] Delorean fail blocks CI for stable branches
> as a quickfix in tripleo.sh you could patch dlrn and set local=True in correction, patch local=False there while running dlrn command with --local to keep source checkout as-is __ 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] Delorean fail blocks CI for stable branches
>> ^ ... --local here keeps local checkout untouched, so you end up with >> default rpm-master in distro git checkout. >> If you remove --local it will reset local checkouts to the branches >> specified in projects.ini >> > Alan, > I don't want to reset local checkouts and reset branches - I need to build > with these checkout, it's all CI is for. DLRN finds matching packaging branch only when you let it reset git checkouts. For tripleo-ci use-case we would need to add a new option to keep source repo as-is and reset packaging checkout only, in the meantime as a quickfix in tripleo.sh you could patch dlrn and set local=True in [2] Alan [1] https://github.com/openstack-packages/DLRN/blob/master/dlrn/shell.py#L522-L536 [2] https://github.com/openstack-packages/DLRN/blob/master/dlrn/drivers/rdoinfo.py#L83-L84 __ 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] Delorean fail blocks CI for stable branches
> git clone https://git.openstack.org/openstack/tripleo-heat-templates > cd tripleo-heat-templates/ > git checkout -b stable/mitaka origin/stable/mitaka ^ this is manually switching to the stable source branch > sed -i -e "s%distro=.*%distro=rpm-mitaka%" projects.ini > sed -i -e "s%source=.*%source=stable/mitaka%" projects.ini ^ this configures dlrn to the correct combination of distro and source branches, but ... > ./venv/bin/dlrn --config-file projects.ini --head-only --package-name > openstack-tripleo-heat-templates --local ^ ... --local here keeps local checkout untouched, so you end up with default rpm-master in distro git checkout. If you remove --local it will reset local checkouts to the branches specified in projects.ini Alan __ 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] [stable][all] Tagging kilo-eol for "the world"
> openstack/packstack BigTent Just to clarify, Packstack has not formally applied to BigTent yet, it has only been automatically migrated from stackforge to openstack namespace. But yes, please keep its kilo branch for now until we properly wrap it up. Cheers, Alan __ 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] [packstack] Update packstack core list
>> I would like to step up as PTL if everybody is ok with it. > > Go for it Iván! +1 __ 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] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?
> So, if Delorean includes packages built from untagged commits in Nit clarification: let's call it RDO Trunk repository (Delorean is a tool, recently renamed https://github.com/openstack-packages/dlrn ) > multiple branches, placed in the same package repository where an > automated installation tool can't tell stable/mitaka from master, > that would be bad. Please tell me that's not what happens? It is not what happens, there are separate repositories for packages built from master and stable branches but it is still confusing, and I'm not sure why is such a big deal to just push one empty commit with Sem-Ver: api-break when we have that nice PBR automagic ? Previously pre-versioning was used and version had to be bumped explicitly in setup.cfg when opening master for the new version e.g. https://review.openstack.org/#q,Ib634eb7acb64ff1d7be49852972295074b11557a,n,z Another example (not release:managed project but still) where we have this confusion is gnocchi: openstack/gnocchi > master $ python ./setup.py --version 2.0.1.dev61 openstack/gnocchi > stable/2.0 $ python ./setup.py --version 2.0.3.dev13 Cheers, Alan __ 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] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?
2016-03-24 2:21 GMT+01:00 Robert Collins: > Trunk will rapidly exceed mitaka's versions, leading to no confusion too. That's the case now, RC1 tags are reachable from both branches and master has more patches, generating higher .devN part. But once RC2 and final tags are pushed, generated version will be higher on stable/mitaka branch: >>> from packaging.version import Version, parse >>> rc2=Version("13.0.0.0rc2") >>> master=Version("13.0.0.0rc2.dev9") >>> master > rc2 False >>> ga=Version("13.0.0") >>> master > ga False Cheers, Alan __ 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] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?
> The release team discussed this at the summit and agreed that it didn't > really matter. The only folks seeing the auto-generated versions are those > doing CD from git, and they should not be mixing different branches of a > project in a given environment. So I don't think it is strictly necessary to > raise the major version, or give pbr the hint to do so. ok, I'll send confused RDO trunk users here :) That means until first Newton milestone tag is pushed, master will have misleading version. Newton schedule is not defined yet but 1st milestone is normally 1 month after Summit, and 2 months from now is rather large window. Cheers, Alan __ 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] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?
2016-02-26 19:51 GMT+01:00 Robert Collins: > On 27 February 2016 at 00:13, Neil Jerram wrote: >> I understand the semantic versioning algorithm for calculating a new >> version. But what do I run, in a git repository, to do that calculation >> for me, and output: > > pbr does that automatically, generating a pre-release version. The > regular part of the version is the lowest version number you can use > that will match the semver rules. So to help PBR, all projects should be inserting commit with Sem-Ver: api-break after stable/mitaka was cut, without that we have the same major version on both branches e.g. nova: $ git checkout master $ python ./setup.py --version 13.0.0.0rc2.dev48 $ git checkout stable/mitaka $ python ./setup.py --version 13.0.0.0rc2.dev10 After pushing empty commit to the master with the message like: Newton bump major version Sem-Ver: api-break Change-Id: I8a2270d5a0f45342fe418b3018f31e6ef054fe9e $ python ./setup.py --version 14.0.0.dev49 Any reason not to do that? Other option is to push alpha tag to master, but that would be weird IMHO. Cheers, Alan __ 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] How do I calculate the semantic version prior to a release?
2016-02-29 9:32 GMT+01:00 Thomas Bechtold: >> >> python setup.py rpm_version >> > >> > The output for i.e. for Manila is here "1...b3.dev138" And in Tempest rpm_version outputs 4.0.0.dev22 while setup.py --version says 10.0.1.dev79 ?! >> > Which is not really correct. The version is "2.0.0.0b3.dev138" . >> > rpm supports the tilde ("~") for pre versions. Converting a PEP440 >> > compatible version to a rpm version can be done with code like: Fedora does not use ~ for pre-versions[1] instead Release: starting with 0 is used for pre-releases [2] >> Does it? Thats great. It didn't as far as anyone here knew when we >> wrote the spec - >> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/pbr-semver.rst >> - or we'd have avoiding a tonne of complexity. I did mention Fedora pre-release versioning in that spec review https://review.openstack.org/#/c/96608/10/specs/juno/pbr-semver.rst@235 >> I see from http://www.rpm.org/ticket/56 that it only came in in RPM 4.10 - >> is RPM >> 4.10 available on all the RPM platforms we support? Including I guess >> old RHEL's and stuff? > > Good question. For SUSE, SLE12 has rpm 4.11 which is fine. No idea about RHEL. EL7 has rpm 4.11 too but ~ is not used, it follows above Fedora guidelines for pre-releases. Cheers, Alan [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag [2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages __ 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] [packstack] Update packstack core list
2016-03-16 11:23 GMT+01:00 Lukas Bezdicka <lbezd...@redhat.com>: >> ... >> - Martin Mágr >> - Iván Chavero >> - Javier Peña >> - Alan Pevec >> >> I have a doubt about Lukas, he's contributed an awful lot to >> Packstack, just not over the last 90 days. Lukas, will you be >> contributing in the future? If so, I'd include him in the proposal as >> well. > > Thanks, yeah I do plan to contribute just haven't had time lately for > packstack. I'm also adding David Simard who recently contributed integration tests. Since there hasn't been -1 votes for a week, I went ahead and implemented group membership changes in gerrit. Thanks to the past core members, we will welcome you back on the next One more topic to discuss is if we need PTL election? I'm not sure we need formal election yet and de-facto PTL has been Martin Magr, so if there aren't other proposal let's just name Martin our overlord? Cheers, Alan __ 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] [stable] Stable* wiki updates
Hi stable-maints, FYI I've updated https://wiki.openstack.org/wiki/StableBranch and https://wiki.openstack.org/wiki/StableBranchRelease now that all policy and team information has ben included in the Project Team Guide. Please review in case I missed something! Cheers, Alan __ 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] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent
> The tricky bit is that RDO does not include patches in our packages > built from trunk (trunk.rdoproject.org), and for liberty we first check > if stable/liberty exists, then fallback to master if it does not. So the > presence of stable/liberty that is not actually the recommended way to > build IPA for liberty is a bit not ideal for us. Trunk builder will first use branch specified per project per release, and we can now override that easily in rdoinfo. > All of that said, I totally understand not wanting to delete a branch. > Especially since I think I am the one who Dmitry is referring to asking > for it. (Though I think what I wanted was releases which is subtly > different) that goes under "for historical reasons" :) > I think there are some hacks I could make in our trunk builder if I at > least have a ML post like this as justification. I am not 100% sure that > is possible though. No hacks needed and I've referenced this ML post: https://github.com/redhat-openstack/rdoinfo/pull/158 Please let me know if that's what you wanted, to avoid further confusion :) Cheers, Alan __ 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] [openstack-announce] [release][stable][horizon] horizon release 8.0.1 (liberty)
> With package available at: > > https://pypi.python.org/pypi/horizon AFAICT non-client/non-oslo stable point releases are NOT uploaded to pypi, are they? e.g. last horizon on pypi is version 2012.2 Should we start uploading them to pypi or change the email template for services projects? Cheers, Alan __ 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] [stable] kilo 2015.1.3 freeze exception request for cve fixes
2016-01-15 11:08 GMT+01:00 Dave Walker: > On 15 January 2016 at 10:01, Thierry Carrez wrote: >> Ihar Hrachyshka wrote: >>> >>> +1. CVE fixes obviously should be granted an exception. >> >> >> +1 >> > > Agreed, I have already +2'd on Gerrit. Can another core please do the same? Done and workflow started. Cheers, Alan __ 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] [ironic] RFC: stop using launchpad milestones and blueprints
>>> I wonder how to avoid giving impression that development has stopped on >>> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as >>> we no longer push tarballs to launchpad. .0 is clear indication that's GA tarball, but to make it clear you can update Launchpad series summary https://launchpad.net/ironic/liberty/+edit to include the link to http://docs.openstack.org/releases/releases/liberty.html#liberty-ironic >> If, over time, we see a lot of folks actually confused about the >> move we can figure out a way to migrate the old data elsewhere so >> it can be deleted. But that's not going to happen this cycle, so >> please leave it intact for now. > Understood, thanks for explanation. So I withdraw suggestion #2. Count me confused, when I saw Ironic 4.2.2 announcement and then 4.2.1 as latest in Launchpad. I propose to remove https://launchpad.net/ironic/+milestone/4.2.1 - it has no release notes and only one minor bug, so that's not much information loss and cuts this confusing corner case. For historical purposes, tarball is still available at http://tarballs.openstack.org/ironic/ironic-4.2.1.tar.gz. This should be the only non-reno Liberty release, for other projects it would be super nice if release team could bulk add link http://docs.openstack.org/releases/releases/liberty.html#liberty-$PROJECT in all Liberty series summaries in Launchpad. Cheers, Alan __ 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] [Magnum] Liberty RPMs for RDO
Hi Mathieu, 2015-11-30 10:54 GMT+01:00 Mathieu Velten: > Hi, > > Let me first introduce myself : I am currently working at CERN to help > evaluate and deploy Magnum. > > In this regard Ricardo recently sends an email regarding Puppet > modules, this one is about RPMs of Magnum for CentOS with RDO. Nice, looking forward to review it! > You can find here a repository containing the source and binary RPMs > for magnum and python-magnumclient. > http://linuxsoft.cern.ch/internal/repos/magnum7-testing/ This one is 403 ? > The version 1.0.0.0b2.dev4 is the Magnum Liberty release and the > 1.1.0.0-5 version is the Mitaka M1 release using Liberty dependencies > (one client commit regarding keystone auth and one server commit > regarding oslo.config have been reverted). > > Let me know how I can contribute the spec files to somewhere more > suitable. Let's discuss this on rdo-list (CCed) Cheers, Alan __ 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] [stable] Post-release bump after 2014.2.4?
> I've confirmed that the juno side of kilo grenade is not blowing up [1], but > I'm not sure why it's not blowing up. Trying to figure that out. It would blow up if something were merged after 2014.2.4 tag which won't happen before version in setup.cfg is either bumped or removed so we're safe :) Cheers, Alan __ 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] [release][stable][keystone] keystonemiddleware release 1.5.3 (kilo)
> keystonemiddleware 1.5.3: Middleware for OpenStack Identity periodic-ceilometer-python27-kilo started failing after this release First bad: http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-kilo/40c5453/testr_results.html.gz test_acl_scenarios failing with 401 Unauthorized __ 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] [stable] Post-release bump after 2014.2.4?
> But to illustrate better the issue I'm seeing: > http://tarballs.openstack.org/cinder/cinder-stable-juno.tar.gz contains > a directory cinder-2014.2.4.dev24, which is kind of wrong. That's the > bit that I'd like to see fixed. That version was correct at the time tarball was generated, if it were regenerated now that tag was pushed, it would be cinder-2014.2.4 You could either ask infra to regenerate those tarballs or generate tarballs yourself (python ./setup.py sdist in git checkout) instead of relying on tarballs.o.o. Cheers, Alan __ 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] [release][stable] OpenStack 2014.2.4 (juno)
2015-11-20 3:22 GMT+01:00 Davanum Srinivas: > fyi https://review.openstack.org/#/c/247677/ That's not the right answer to Rochelle's plea :) It was actually already answered by Matt, with a suggestion that _Kilo_ grenade job could simply checkout 2014.2.4 tag instead of stable/juno and for that we don't need to keep branches around. Cheers, Alan __ 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] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> So we were brainstorming this with Rocky the other night. Would this be > possible to do by following: > 1) we still tag juno EOL in few days time > 2) we do not remove the stable/juno branch Why not? > 3) we run periodic grenade jobs for kilo >From a quick look, grenade should work with a juno-eol tag instead of stable/juno, it's just a git reference. "Zombie" Juno->Kilo grenade job would need to set BASE_DEVSTACK_BRANCH=juno-eol and for devstack all $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be the same commit). Maybe I'm missing some corner case in devstack where stable/* is assumed but if so that should be fixed anyway. Leaving branch around is a bad message, it implies there support for it, while there is not. Cheers, Alan __ 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] [stable] Call for testing: 2014.2.4 candidate tarballs
Hi all, we are scheduled to publish 2014.2.4, last Juno point release, on Thursday November 19th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova, Sahara and Trove. Draft release notes are available at https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.4 We'd appreciate anyone who could test the candidate 2014.2.4 tarballs: http://tarballs.openstack.org/ceilometer/ceilometer-stable-juno.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-juno.tar.gz http://tarballs.openstack.org/glance/glance-stable-juno.tar.gz http://tarballs.openstack.org/heat/heat-stable-juno.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-juno.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-juno.tar.gz http://tarballs.openstack.org/neutron/neutron-stable-juno.tar.gz http://tarballs.openstack.org/nova/nova-stable-juno.tar.gz http://tarballs.openstack.org/sahara/sahara-stable-juno.tar.gz http://tarballs.openstack.org/trove/trove-stable-juno.tar.gz Thanks, Alan __ 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> Speaking of your "hacky" patch: yes and no. It makes the gate passing, > it doesn't change the code itself. For most people, this will work fine. > > The right way to do it, would be to create a juno branch for doa and > cap requirements there. > > How to do this? Is there a procedure to request a branch? Let's not go there, I've approved "hacky" one. Cheers, Alan __ 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> This is a call to stable-maint teams for Nova, Keystone, Glance, > Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review > open stable/juno changes[2] and approve/abandon them as appropriate. CCing CPLs listed in https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch I got only ACK from Erno for Glance, anyone other project ready? > [2] > https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z AFAICT there are at least two blockers for 2014.2.4: - horizon - django_openstack_auth issue Tony mentions in https://review.openstack.org/172826 - nova - gate-grenade-dsvm-ironic-sideways failures e.g. in https://review.openstack.org/227800 Cheers, Alan __ 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
Hi, while we continue discussion about the future of stable branches in general and stable/juno in particular, I'd like to execute the current plan which was[1] 2014.2.4 (eol) early November, 2015. release manager: apevec Iff there's enough folks interested (I'm not) in keep Juno alive longer, they could resurrect it but until concrete plan is done let's be honest and stick to the agreed plan. This is a call to stable-maint teams for Nova, Keystone, Glance, Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review open stable/juno changes[2] and approve/abandon them as appropriate. Proposed timeline is: * Thursday Nov 12 stable/juno freeze[3] * Thursday Nov 19 release 2014.2.1 Cheers, Alan [1] https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fjuno_releases_.2812_months.29 [2] https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z [3] documented in https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers TODO add in new location http://docs.openstack.org/project-team-guide/stable-branches.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team
>> The Stable Branch Policy, lets not put it in any repo. >> Doing that would give indication that we expect changes into it and I'd >> prefer that policy mostly staying stable as well. What indication did it give when it was in wiki? :) > It actually already is in a repo: > http://git.openstack.org/cgit/openstack/project-team-guide/tree/doc/source/stable-branches.rst https://wiki.openstack.org/wiki/StableBranch should be replaced with the link to it to avoid confusion. There were changes since it was moved to the repo: https://wiki.openstack.org/w/index.php?title=StableBranch=history Which team approves the changes in the project-team-guide, can it be per file? Regarding stable team spin-off, I think it's worth discussing further to define exact scope, then see show of hands before formally setting the team up as I'm afraid we don't have the critical mass yet. I'm personally tied up with other obligations next few months so cannot actively help or lead this initial effort. Cheers, Alan __ 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] [release] RDO Liberty released in CentOS Cloud SIG
I am pleased to announce the general availability of the RDO build for OpenStack Liberty for CentOS Linux 7 x86_64, suitable for building private, public and hybrid clouds. OpenStack Liberty is the 12th release of the open source software collaboratively built by a large number of contributors around the OpenStack.org project space. The RDO community project ( https://www.rdoproject.org/ ) curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a founding member of the CentOS Cloud Infrastructure SIG ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). The Cloud Infrastructure SIG focus on delivering a great user experience for CentOS Linux users looking to build and maintain their own onpremise, public or hybrid clouds. In addition to the comprehensive OpenStack services, libraries and clients, this release also provides Packstack, a simple installer for proof-of-concept installations, as small as a single all-in-one box and RDO Manager ( https://www.rdoproject.org/RDO-Manager ) , an OpenStack deployment and management tool for production environments based on the OpenStack TripleO project. --- QuickStart: Ensure you have a fully updated CentOS Linux 7/x86_64 machine, and run : sudo yum install centos-release-openstack-liberty sudo yum install openstack-packstack packstack --allinone For a more detailed quickstart please refer to the RDO Project hosted guide at https://www.rdoproject.org/QuickStart For RDO Manager consult https://www.rdoproject.org/RDO-Manager page. RDO project is closely tracking upstream OpenStack projects using the Delorean tool[1] which is producing RPM packages from upstream development branches. Since the previous OpenStack Kilo release, RDO is participating in the Cloud SIG and using CentOS provided infrastructure. Towards the end of developement cycle packages are imported into CentOS Cloud SIG buildsystem[2] and get eventually published in Cloud SIG repositories[3]. [1] http://trunk.rdoproject.org/ [2] http://wiki.centos.org/HowTos/CommunityBuildSystem [3] http://mirror.centos.org/centos/7/cloud/x86_64/ Getting Help: The RDO Project provides a Q service at ask.openstack.org, for more developer oriented content we recommend joining the mailing list at https://www.redhat.com/mailman/listinfo/rdo-list. Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation at https://www.rdoproject.org/Docs. We also welcome comments and requests on the CentOS Mailing lists ( https://lists.centos.org/ ) and the CentOS IRC Channels ( #centos on irc.freenode.net ), however we have a more focused audience in the RDO venues. To get involved in the OpenStack RPM packaging effort, see https://www.rdoproject.org/Get_involved and https://wiki.centos.org/SpecialInterestGroup/Cloud Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter. And, if you're going to be in Tokyo for the OpenStack Summit next week, join us on Wednesday at lunch for the RDO community meetup ( http://sched.co/4MYy ). I'd like to thank all RDO developers and CentOS Project for their effort and support resulting in this release, especially dmsimard - for continuously improving RDO CI jpena - for keeping Delorean service up and running jruzicka - for the rdopkg auto-magic number80 - for countless reviews and packaging wisdom social - for puppet module mastery trown - for leading RDO Manager side of the show! Special thanks to all the folks who helped with last minute testing in IRC #rdo channel ! Thanks, Alan Pevec Cloud SIG and RDO project member ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [all][stable][release] 2015.1.2
2015-10-14 10:59 GMT+02:00 Thierry Carrez: > Sean Dague wrote: >> I think that whoever sets the tag should also push those fixes. We had >> some kilo content bogging down the gate today because of this kind of >> failure. Better to time this as close as possible with the tag setting. > > Right. The ideal process is to push the version bump and cut the tag > from the commit just before that. That is how it's done on the main > release when we start cutting the release branch at RC1. I've now documented this step in StableReleaseBranch wiki: https://wiki.openstack.org/w/index.php?title=StableBranchRelease=92628=92626 Cheers, Alan __ 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] Do all OpenStack daemons support sd_notify?
Thanks for responding, does this make it longest by time duration thread ever? :) 2015-10-15 22:44 GMT+02:00 Thomas Goirand <z...@debian.org>: > On 12/16/2014 11:59 AM, Alan Pevec wrote: ... >> Current implementation in oslo service sends notification only just >> before entering the wait loop, because at that point all >> initialization should be done and service ready to serve. Does anyone >> have a suggestion for the better place where to notify service >> readiness? > What you describe above looks like a defect in the implementation. Of > course, waiting for more than 90s should be considered as failed, and I > wouldn't want in any case to have this timeout increased. Failed > attempts to connect to Rabbit shouldn't, IMO, be the cause for not > sending the notify signal. But if service requires message bus for normal operations, it is not ready to server requests, is it? Cheers, Alan __ 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] [all][stable][release] 2015.1.2
> For Horizon, it would make sense to move this a week back. We discovered > a few issues in Liberty, which are present in current kilo, too. I'd > love to cherry-pick a few of them to kilo. What are LP bug#s ? Are you saying that fixes are still work in progress on master and not ready for backporting yet? > Unfortunately, it takes a bit, until Kilo (or in general: stable) > reviews are being done. One suggestion how to speed up reviews of such patch series: put them all under the same topic for an easy gerrit URL, then ping on #openstack-stable. Stable backport reviews are supposed to be done primarily by per-project stable-maint teams but stable-maint-core could also help. Cheers, Alan __ 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] Patches coming for .coveragerc
2015-09-21 16:12 GMT+02:00 Monty Taylor: > We're running a script right now to submit a change to every project with > this change. The topic will be coverage-v4 stable/kilo has uncapped coverage>=3.6 do we patch-spam it or cap coverage? stable/juno has coverage>=3.6,<=3.7.1 Cheers, Alan __ 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] [stable] 2015.1.2 readiness check WAS : gate-trove-functional-dsvm-mysql needs some stable branch love
>> [1] https://bugs.launchpad.net/trove-integration/+bug/1479358 >> [2] https://review.openstack.org/#/c/207193/ This fix has been merged and bug closed but Trove on stable/kilo is not green yet, summary from https://etherpad.openstack.org/p/stable-tracker * Trove * various proboscis.case.MethodTest errors * Mock issues too, some fixed (but not all) at https://review.openstack.org/202015 MERGED but periodic-trove-python27-kilo is still failing: * http://logs.openstack.org/periodic-stable/periodic-trove-python27-kilo/3a6b8c7/console.html In https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat we have planned 2015.1.2 mid-September, 2015 are we ready to freeze stable/kilo now? Cheers, Alan __ 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] [requirements] attention requirements-cores, please look out for constraints updates
> I'd like to add in a lower-constraints.txt set of pins and actually > start reporting on whether our lower bounds *work*. Do you have a spec in progress for lower-constraints.txt? It should help catch issues like https://review.openstack.org/221267 There are also lots of entries in global-requirements without minimum version set while they should: http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n226 Cheers, Alan __ 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] [depfreeze] [keystone] Set minimum version for passlib
Hi all, according to https://wiki.openstack.org/wiki/DepFreeze I'm requesting depfreeze exception for https://review.openstack.org/221267 This is just a sync with reality, copying Javier's description: (Keystone) commit a7235fc0511c643a8441efd3d21fc334535066e2 [1] uses passlib.utils.MAX_PASSWORD_SIZE, which was only introduced to passlib in version 1.6 Cheers, Alan [1] https://review.openstack.org/217449 __ 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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits
The only alternative seems to be to have on-demand stable-branch tagging. The main drawbacks of that option are that consumers of the stable branch are unnecessarily limited to specific tagged commits, and depend on various project teams to remember to push them. As Doug suggested, stable releases would be triggered by submitting a patch to the releases repository, so maybe we could be auto-generating release proposals periodically (monthly, weekly?) as a reminder to the team if there hasn't been a release in that period? Also OSSA merge could trigger an async release proposal too. Cheers, Alan __ 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] [swift] swift memory usage in centos7 devstack jobs
2) Should this also be sent to centos-devel folks so that they don't upgrade/update the pyopenssl in their distro repos until the issue is resolved ? I think let's give the upstream issues a little while to play-out, then we decide our next steps around use of the library based on that information. pyOpenSSL was bumped to 0.14 https://review.openstack.org/197986 does it work now on EL7 ? Cheers, Alan __ 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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits
To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80 (kilo) and Nova 10.0.218 (juno). I am not a fan of doing this second option at all. We would be polluting the ref space of our repos with redundant information making the output of `git tag` unusable to humans. If this was not redundant info and a tag of 11.0.80 provided more information than a generated version of 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not. It actual does: auto-tagged commit means it passed our CI hence project stands behind it. PBR-generated Z-version could be just local change which has never seen any CI yet. Using pbr to generate versions avoids that problem, but introduces the challenge of not being able to necessarily figure out which commit corresponds to a given version number from the outside. Say I want to check out version 11.0.80 for some reason (maybe .81 has a bug I don't want to deploy). How do I do that without a tag? That also, PBR-generated version is not universally reproducible. So what about making auto-tagging on stable branches optional for projects: by default if project has a stable branch(es) they will get auto-tagging but project could also opt-out and push X.Y.Z tags themselves, via the same release process like Oslo and clients. Cheers, Alan __ 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-announce] OpenStack 2015.1.1 released
Hello everyone, The OpenStack Stable Maintenance team is happy to announce the release of the 2015.1.1 stable Kilo release. We have been busy reviewing and accepting backported bugfixes to the stable/kilo branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A total of 162 bugs have been fixed across all projects. These updates to Kilo are intended to be low risk with no intentional regressions or API changes. The list of bugs, tarballs and other milestone information for each project may be found on Launchpad: https://launchpad.net/ceilometer/kilo/2015.1.1 https://launchpad.net/cinder/kilo/2015.1.1 https://launchpad.net/glance/kilo/2015.1.1 https://launchpad.net/heat/kilo/2015.1.1 https://launchpad.net/horizon/kilo/2015.1.1 https://launchpad.net/ironic/kilo/2015.1.1 https://launchpad.net/keystone/kilo/2015.1.1 https://launchpad.net/neutron/kilo/2015.1.1 https://launchpad.net/nova/kilo/2015.1.1 https://launchpad.net/sahara/kilo/2015.1.1 OpenStack Database Service (Trove) did not have stable/kilo fixes at this time and will skip 2015.1.1 release. Release notes may be found on the wiki: https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.1 Thanks, Alan ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
Re: [OpenStack-Infra] [openstack-dev] [all][infra] CI System is broken
2015-07-30 10:19 GMT+02:00 Andreas Jaeger a...@suse.com: It might be that some jobs from the last few hours were not enqueued and Zuul might have lost the events, It seems tag events for 2015.1.1 in neutron-*aas were lost, I pushed them around midnight GMT July 31: https://git.openstack.org/cgit/openstack/neutron-faas/tag/?id=2015.1.1 https://git.openstack.org/cgit/openstack/neutron-lbaas/tag/?id=2015.1.1 https://git.openstack.org/cgit/openstack/neutron-vpnaas/tag/?id=2015.1.1 but http://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-2015.1.1.tar.gz etc. did not show up yet! This is the last step before I can announce 2015.1.1 point release, all other project have been tagged and released successfully. Cheers, Alan ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again. Err, no. Post-versioning means all projects use semantic rather than date-based version numbers, which happens starting with *liberty*. Remaining kilo and juno stable releases will still need to use pre-versioning. Actually, post/pre doesn't make a difference on stable branches. I tried locally on keystone stable/kilo and generated versions stay the same. * current pre-version setup i.e. version = 2015.1.2 in setup.cfg ** commit 070b51603879f0f70f85f72e9e82126d1bb398ba Bump stable/kilo next version to 2015.1.2 2015.1.2.dev1 ** review 205130 rebased on top of 070b516 Bump... 2015.1.2.dev2 * post-version i.e. version = line removed from setup.cfg on top of 070b516 Bump... commit fb9582acc739d7719da0f1cc5f29b9e24097e025 Author: Alan Pevec alan.pe...@redhat.com Date: Thu Jul 30 12:07:27 2015 +0200 Switch to post-versioning Change-Id: Ie4758058672bdeff86147f796d53f602a65228f1 diff --git a/setup.cfg b/setup.cfg index e8d84e3..da0edb9 100644 --- a/setup.cfg +++ b/setup.cfg @@ -1,6 +1,5 @@ [metadata] name = keystone -version = 2015.1.2 summary = OpenStack Identity description-file = README.rst 2015.1.2.dev2 ** review 205130 rebased on top of Switch to post-versioning 2015.1.2.dev3 And when I tag that commit locally: $ git tag 2015.1.2 $ python ./setup.py --version 2015.1.2 Then one backport on top of that: 2015.1.3.dev1 So all is good and safe to remove version = lines from setup.cfg on stable branches. Cheers, Alan __ 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] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
The way we did it in the past was to push the setup.cfg version=2015.1.2 bump BEFORE we tag, then once that is merged, tag the previous commit in history as 2015.1.1. That way you avoid the lockstep (and ensure no intermediary badly-versioned tarball can be produced). Any reason why that wouldn't work anymore ? It should've worked but we didn't update the current stable release procedure which I was following. We have documented pushing tags in step https://wiki.openstack.org/wiki/StableBranchRelease#Tag and pushing version bumps only later, after Close bugs and Upload The Release: https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat Let's update this procedure since we still have few Kilo and Juno point releases to be done. Cheers, Alan __ 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] [horizon] [stable] Freeze exception
I would like to request for a freeze exception for the this bug: https://bugs.launchpad.net/horizon/+bug/1474618 This is the patch: https://review.openstack.org/#/c/206184/ Too late for 2015.1.1, tags (except neutron) have been pushed but certainly fine to merge to stable/kilo. Cheers, Alan __ 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] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again. Cheers, Alan __ 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] [stable]{kilo][glance] freeze exceptions
We have been waiting python-cinderclient stable/kilo release for couple of weeks to be able to merge glance_store stable/kilo backports. Namigly: https://review.openstack.org/#/q/status:open+project:openstack/glance_store+branch:stable/kilo,n,z As Alan blocked them all, I’d like to ask everyone hold your horses with the 2015.1.1 release until cinder gets their client released so we can fix the glance store for the release. This was actually freeze script misfire, it matched glance substring. glance_store was not part of point releases, same as clients and Oslo libs are not, so I'll remove my -2s BTW, what is the estimate for the cinderclient stable/kilo release? Cheers, Alan __ 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] [stable][kilo] Call for testing: 2015.1.1 candidate tarballs
Hi all, We are scheduled to publish 2015.1.1 Kilo point releases, on Thursday July 16th for Ceilometer, Cinder, Glance, Heat, Horizon, Ironic, Keystone, Neutron, Nova, Sahara and Trove. We'd appreciate anyone who could test the candidate 2015.1.1 tarballs, which include all changes aside from any pending freeze exceptions: http://tarballs.openstack.org/ceilometer/ceilometer-stable-kilo.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-kilo.tar.gz http://tarballs.openstack.org/glance/glance-stable-kilo.tar.gz http://tarballs.openstack.org/heat/heat-stable-kilo.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-kilo.tar.gz http://tarballs.openstack.org/ironic/ironic-stable-kilo.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-kilo.tar.gz http://tarballs.openstack.org/neutron/neutron-stable-kilo.tar.gz http://tarballs.openstack.org/nova/nova-stable-kilo.tar.gz http://tarballs.openstack.org/sahara/sahara-stable-kilo.tar.gz http://tarballs.openstack.org/trove/trove-stable-kilo.tar.gz Thanks, Alan __ 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] CenOS7 kilo cannot find service type cloudformation when create heat endpoint .
today when I create heat_cfn endpoint: openstack endpoint create \ --publicurl http://controller:8000/v1 \ --internalurl http://controller:8000/v1 \ --adminurl http://controller:8000/v1 \ --region RegionOne \ cloudformation I encontered the following errer message: ERROR: openstack No service with a type, name or ID of 'cloudformation' exists. cloudformation service should be created in the step 3.f in http://docs.openstack.org/kilo/install-guide/install/yum/content/heat-install-controller-node.html Did that work w/o error, does openstack service list show it? I just follow the guide of http://docs.openstack.org/kilo/install-guide/install/yum/content/ and I replace the repository from http://rdoproject.org/repos/openstack-kilo/rdo-testing-kilo.rpm to http://rdoproject.org/repos/openstack-kilo/rdo-testing-kilo.rpm This should be http://rdoproject.org/repos/openstack-kilo/rdo-release-kilo.rpm Cheers, Alan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job
2015-07-02 5:00 GMT+02:00 Ian Wienand iwien...@redhat.com: So I looked into this with Gilles, and that error is a red-herring (it's just saying the rdo repos don't create the presto/deltarpm stuff); yep the real issue is when python-requests fails to install [1] a bit later due to [2] (mentioned in comments of [3]). [2] is unrelated EL6 issue, job is running on EL7 + RDO Kilo repo So this is really a upstream packaging issue and not an issue with the nodepool images. I could not reproduce on a clean centos7, so I'd like to grab nodepool image to have a closer look: https://bugs.launchpad.net/puppet-openstack/+bug/1470685/comments/1 Cheers, Alan __ 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] [puppet] [infra] issues with beaker/centos7 job
I could not reproduce on a clean centos7, so I'd like to grab nodepool image to have a closer look After having a closer look, I see that image has requests 2.7 installed from pypi which overwrites python-requests RPM installation and wreaks havoc when trying to upgrade RPM. I'm not sure why and where is pypi used during the image build but it should not be installed system-wide on RPM system. If really needed, install it in venv. Cheers, Alan __ 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-announce] OpenStack 2014.1.5 released
Hello everyone, The OpenStack Stable Maintenance team is eager to announce the release of the 2014.1.5 stable Icehouse. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A total of 41 bugs have been fixed across all projects since 2014.1.4. These updates to Icehouse are intended to be low risk with no intentional regressions or API changes. The list of bugs, tarballs and other milestone information for each project may be found on Launchpad: https://launchpad.net/cinder/icehouse/2014.1.5 https://launchpad.net/glance/icehouse/2014.1.5 https://launchpad.net/horizon/icehouse/2014.1.5 https://launchpad.net/keystone/icehouse/2014.1.5 https://launchpad.net/nova/icehouse/2014.1.5 https://launchpad.net/neutron/icehouse/2014.1.5 https://launchpad.net/ceilometer/icehouse/2014.1.5 https://launchpad.net/heat/icehouse/2014.1.5 Release notes may be found on the wiki: https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.5 No further upstream Icehouse releases are planned. Thanks, Alan ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[Openstack] OpenStack 2014.1.5 released
Hello everyone, The OpenStack Stable Maintenance team is eager to announce the release of the 2014.1.5 stable Icehouse. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A total of 41 bugs have been fixed across all projects since 2014.1.4. These updates to Icehouse are intended to be low risk with no intentional regressions or API changes. The list of bugs, tarballs and other milestone information for each project may be found on Launchpad: https://launchpad.net/cinder/icehouse/2014.1.5 https://launchpad.net/glance/icehouse/2014.1.5 https://launchpad.net/horizon/icehouse/2014.1.5 https://launchpad.net/keystone/icehouse/2014.1.5 https://launchpad.net/nova/icehouse/2014.1.5 https://launchpad.net/neutron/icehouse/2014.1.5 https://launchpad.net/ceilometer/icehouse/2014.1.5 https://launchpad.net/heat/icehouse/2014.1.5 Release notes may be found on the wiki: https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.5 No further upstream Icehouse releases are planned. Thanks, Alan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs
Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5 https://launchpad.net/cinder/+milestone/2014.1.5 https://launchpad.net/glance/+milestone/2014.1.5 https://launchpad.net/heat/+milestone/2014.1.5 https://launchpad.net/horizon/+milestone/2014.1.5 https://launchpad.net/keystone/+milestone/2014.1.5 https://launchpad.net/neutron/+milestone/2014.1.5 https://launchpad.net/nova/+milestone/2014.1.5 https://launchpad.net/trove/+milestone/2014.1.5 We'd appreciate anyone who could test the candidate 2014.1.5 tarballs: http://tarballs.openstack.org/ceilometer/ceilometer-stable-icehouse.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-icehouse.tar.gz http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz http://tarballs.openstack.org/heat/heat-stable-icehouse.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-icehouse.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-icehouse.tar.gz http://tarballs.openstack.org/neutron/neutron-stable-icehouse.tar.gz http://tarballs.openstack.org/nova/nova-stable-icehouse.tar.gz http://tarballs.openstack.org/trove/trove-stable-icehouse.tar.gz Thanks, Alan __ 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] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs
http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz copy-paste fail, this should be: http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs
Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5 https://launchpad.net/cinder/+milestone/2014.1.5 https://launchpad.net/glance/+milestone/2014.1.5 https://launchpad.net/heat/+milestone/2014.1.5 https://launchpad.net/horizon/+milestone/2014.1.5 https://launchpad.net/keystone/+milestone/2014.1.5 https://launchpad.net/neutron/+milestone/2014.1.5 https://launchpad.net/nova/+milestone/2014.1.5 https://launchpad.net/trove/+milestone/2014.1.5 We'd appreciate anyone who could test the candidate 2014.1.5 tarballs: http://tarballs.openstack.org/ceilometer/ceilometer-stable-icehouse.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-icehouse.tar.gz http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz http://tarballs.openstack.org/heat/heat-stable-icehouse.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-icehouse.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-icehouse.tar.gz http://tarballs.openstack.org/neutron/neutron-stable-icehouse.tar.gz http://tarballs.openstack.org/nova/nova-stable-icehouse.tar.gz http://tarballs.openstack.org/trove/trove-stable-icehouse.tar.gz Thanks, Alan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs
http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz copy-paste fail, this should be: http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz __ 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] Targeting icehouse-eol?
let's release this last one (codename: Farewell ?) point release. I can do this next week after we finish pending reviews. Remaining stable/icehouse reviews[1] have -2 or -1 except https://review.openstack.org/176019 which I've asked neutron-stable-maint to review. Matt, anything else before we can tag 2014.1.5 and icehouse-eol ? Cheers, Alan [1] https://review.openstack.org/#/q/status:open+AND+branch:stable/icehouse+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove%29,n,z __ 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] [all] [stable] No longer doing stable point releases
The only issue is having a correct version number. Swift could well iterate after 20151, for example doing 20151.1 then 20151.2, etc. Swift never had coordinated YEAR.N versions, https://wiki.openstack.org/wiki/Swift/version_map and they never released a version from their stable/* branches. e.g. 2.2.1 and 2.2.2 are in Launchpad Series kilo https://launchpad.net/swift/kilo and were created from master branch, not stable/juno as one would expect. I heard Swift team call them Juno version released during Kilo cycle which confused me a lot but if you take into account that Swift master is stable and always backward compatible, it does make sense. In short, Swift is different enough so best not to force them into coordinated point releases which is what we did. And when you think of it more, Swift model should be the goal for all OpenStack project: stable master, always backward compatbile, no upgrade issues = no need for stable/* branches :) So we could do what you're asking (option B) for Kilo stable releases, but I think it's not really a viable option for stable/liberty onward. I fail to understand how version numbers are related to doing synchronized point releases. Sure, we have a problem with the version numbers, but we can still do a point release of all the server projects at once. I don't see what value does the same tag across certain set of projects bring? Taking it to the extreme, why don't you put the same version across all packages in a distro? Reality is that each openstack is independent and compatibility among them is ensured by CI not by using the coordinated version tags. FYI, after a CVE, I have uploaded cinder with this version number: 2015.1.0+2015.06.06.git24.493b6c7f12-1 And with modified[*] plan D it would be 2015.1.25 IMO, it looks ugly, and not comprehensive to Debian users. If I really have to go this way, I will, but I would have not to. You don't, if you'd support planD :) Though there's now zero guidance at what should be the speed of releasing server packages to our users. Why there should be any guidance from upstream? Let your users tell you and with planD you can update whenever requested fix is merged on stable! So I totally get that we should still have reference points to be able to tell this is fixed in openstack/nova stable/liberty starting with 12.1.134post34 (or whatever we settle with). I totally get that any of those should ship with relevant release notes. But that's about all I think we need ? That's not a little thing that you're pointing at: having reference points is very important. But yeah, it may be the only thing... Like we will only loose track of what is fixed in which version. :( On the contrary, with planD you'd have reference points and lots of them :) And release notes would be generated from commit messages - this requires better commit messages on stable branches but that's always good. Here's how it would look like for current Cinder stable/kilo: CHANGES === 2015.1.25 - * Disallow backing files when uploading volumes to image 2015.1.24 - * Dispose DB connections between backend proc starts 2015.1.23 - * Allow provisioning to reach max oversubscription ... Cheers, Alan [*] modified plan D: automatically sign and push git tag after each commit on stable branch. We get both, tags and tarballs in one go. __ 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] [all] [stable] No longer doing stable point releases
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com: Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid SemVer (http://semver.org/) Right, so semver compatible versioning on stable/kilo would be 2015.1.N but PBR doesn't support that. If we want to be pedantic about the version numbers generated by PBR (at the gate, in tox, etc.), it should be next version number.devN That's what PBR does now, even for projects without version in setup.cfg, it assumes MAJOR.MINOR.PATCH++ from the last tag on the branch. Cheers, Alan __ 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] [all] [stable] No longer doing stable point releases
and *Plan D* would be to start doing automatic per-project micro-versions on each commit: e.g. 2015.1.N where N is increased on each commit. How do you gpg sign these tags? I hope the solution isn't to store a key in infra without a passphrase. Plan D doesn't include git tags, 2015.1.N would be generated by PBR automatically. FYI, I don't use tarballs (just git), and generate my own orig.tar.xz out of a signed git tag, so I am not affected by this. We could generate it too but upstream SourceURL is preferred[1] so it can be easily verified. BTW there's an issue re. verification that https://tarballs.openstack.org/ is using cert for security.openstack.org but should be easily fixed by infra. Cheers, Alan [1] https://fedoraproject.org/wiki/Packaging:SourceURL __ 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] [all] [stable] No longer doing stable point releases
How do you check if project X in version n works with project Y in version m, using this non-scheduled point release free for all model? That was an illusion of point releases, as Thierry said there wasn't significantly more testing and I don't remember any testing reports during stable freeze periods. All we had was upstream CI testing, but that's what we get for every commit. Why every 2 weeks? Why every month? Sure, no problem, every distro can update whenever it works for them, what is important for me is that we have a common reference points. With plan D that would be automatically generated maj.min.N where N is the number of commits since maj.min tag which doesn't depend on anyone's manually pushing git tag. Not synchronizing brings a bunch of problems. The only problem raised by synchronous point releases is we don't have enough resources, which I fail to understand, given how cheap it is to tag a release. If the release managers don't have enough time to do so, it is my view that it's ok to give this power to individual projects. But that's orthogonal to having synchronous point releases. Tag is indeed cheap, this is more about reflecting reality and not keeping this synchronized illusion alive. BTW point release process is more[1] than just pushing signed git tag, the most time consuming work is cats herding (i.e. pushing for reviews before the freeze) and Launchpad pruning. The former was hopeless and will be even more with big-tent and the latter we should avoid by automatically generated changelog. Cheers, Alan [1] https://wiki.openstack.org/wiki/StableBranchRelease __ 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] [all] [stable] No longer doing stable point releases
If the downsteam consumer has their own extra patches ontop of the stable branch, then it seems D is even less useful than A. It is not - downstream (speaking for RDO) I would keep Version: 2015.1.N where N is stable patch# so that we have a common reference point with other distros. Our patches, if any, then come on top this, so it's clear which patches are added by distro. Cheers, Alan __ 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] Targeting icehouse-eol?
The only open question I have is if we need to do an Icehouse point release prior to the tag and dropping the branch, but I don't think that's happened in the past with branch end of life - the eol tag basically serves as the placeholder to the last 'release'. I don't think we need to do a point release, there will be the icehouse-eol tag which will mark the same thing. But, even if we later decide to add a point release to mark the same thing it is trivial to push another tag for the same sha1. I CC-ed the stable branch release managers for their opinion on it. We definitely announced a 2014.1.5 last icehouse release, so I think we should probably do one. Ideally we would have time to coordinate it in the coming week so that both plans are compatible. Based on previoius 15 months plan, 2014.1.5 was targeting July 2015, so releasing it next week would be close enough: https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases I'm not sure if release machinery would work after removing the branch so let's release this last one (codename: Farewell ?) point release. I can do this next week after we finish pending reviews. Cheers, Alan __ 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] [all] [stable] No longer doing stable point releases
You will get different checksums with tar and/or gzip, you can check the extracted files and they should be the same. Yes, content is the same, it's just difference in timestamps of folders and generated files (ChangeLog, egg-info etc). I would like to see signed commits in the 'official' repos (at git.openstack.org), if only because relying on sha alone doesn't seem enough for some. Yeah, maybe RPM and I are just too old and should drop reproducibility requirement :) It might be nitpicking to expect exact same bits but it seems that only missing part is an option to tell sdist to set specific timestamp on generated files and folders. Cheers, Alan __ 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] [all] [stable] No longer doing stable point releases
One issue is how would we provide source tarballs, statically hosting tarballs for each and every micro version is not realistic, also those wouldn't be signed. Sorry, but why isn't it realistic, and why wouldn't they be signed? I thought storage requirements to generate tarball for each commit for each project is unrealistic but infra could tell. Re. signing - I was judging from current stable release procedure[*] where tarballs are manually signed by the release manager before upload to Launchpad. Cheers, Alan [*] https://wiki.openstack.org/wiki/StableBranchRelease#Upload_The_Release __ 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] [all] [stable] No longer doing stable point releases
*Plan C* would be to just let projects tag stable point releases from time to time. That would solve all the original stated problems. And that would solve objections 2 and 3, which I think are the most valid ones. and *Plan D* would be to start doing automatic per-project micro-versions on each commit: e.g. 2015.1.N where N is increased on each commit. There's just TBD item how to provide source tarballs for this. This would solve 3. reference points for OSSAs and relnotes. Solution for 2. could be to add doc/source/release-notes.rst for each project wishing to maintain it, docs are already published for each branch e.g. http://docs.openstack.org/developer/keystone/kilo/ Cheers, Alan __ 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] [all] [stable] No longer doing stable point releases
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org: On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote: This is generally my opinion as-well, I always hoped that *every* commit would be considered a release rather than an arbitrary tagged date. [...] If we switch away from lockstep major/minor release versioning anyway (again separate discussion underway but seems a distinct possibility) then I think the confusion over why stable point releases are mismatched becomes less of an issue. At that point we may want to reconsider and actually tag each of them with a sequential micro (patch in semver terminology) version bump. Could help in communication around security fixes in particular. Yes, if dropping stable point releases, sub-version schema is still needed for clear communication in OSSAs and proposed continuous releases notes. One issue is how would we provide source tarballs, statically hosting tarballs for each and every micro version is not realistic, also those wouldn't be signed. RPM packages traditionally expect pristine upstream tarballs which can be verified and generating them from git is not reproducible e.g. right now in nova stable/kilo branch: python ./setup.py sdist mv dist/nova-2015.1.1.dev20.tar.gz dist/nova-2015.1.1.dev20.tar.gz-TAKE1 python ./setup.py sdist diff dist/nova-2015.1.1.dev20.tar.gz-TAKE1 dist/nova-2015.1.1.dev20.tar.gz Binary files dist/nova-2015.1.1.dev20.tar.gz-TAKE1 and dist/nova-2015.1.1.dev20.tar.gz differ Before dropping point releases, I would like to have: * idempotent sdist on the same SHA * dynamic tarball generation service like github archive * switch to micro-version i.e. current nova stable/kilo would be 2015.1.20 Cheers, Alan __ 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] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0
This is a problem of dependency resolution rather than an issue of keystoneclient specifically. You can see that glanceclient has a cap on keystoneclient that the installed version doesn't meet. python-keystoneclient=1.1.0,1.4.0 is requirement on python-glanceclient stable/kilo branch, while python-keystoneclient 1.4.0 is master. Are you using stable/kilo or master devstack? Problem is that openstackclient stable/kilo is missing requirements caps so if installed earlier it will pull latest published on pypi which is out of bounds for Kilo. https://review.openstack.org/174341 should fix that Cheers, Alan __ 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] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?
I'm working on removing mox in favor of mox3 to reduce a bit our dependency. Then mox3 should be imported to openstack namespace as suggested by Chuck in Dec 2013. Looks like last known source repository is https://github.com/emonty/pymox with last commit from Aug 2013 or did it move somewhere else? Cheers, Alan __ 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] [swift] swift memory usage in centos7 devstack jobs
I'll spend a bit more time on this -- I haven't determined if it's centos or swift specific yet -- but in the mean-time, beware of recent pyOpenSSL But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu? Alan __ 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] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?
blast from the past... 2013-12-04 19:17 GMT+01:00 Chuck Short chuck.sh...@canonical.com: On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov ndipa...@redhat.com wrote: ... 1) Figure out what is the deal with mox3 and decide if owning it will really be less trouble than porting nova. To be hones - I was unable to even find the code repo for it, only [3]. If anyone has more info - please weigh in. We'll also need volunteers Monty and I did this last cycle, its apart of the openstack project, although its not available in gerrit. Which should be fixed so we can start getting bug fixes in for it. Looks like this was not done, last pypi upload was mox3-0.7.0.tar.gz on 2013-08-15 by owner openstackci but I don't see it in https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml ? There was a bug reported about py34 incompatibility which was worked around in one specific project, but oslotest has a dependency on mox3 so I moved it to oslotest https://bugs.launchpad.net/oslotest/+bug/1403214 What's the status of migration to mock, can mox and mox3 be dropped from global-requirements ? Cheers, Alan __ 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] OpenStack 2014.1.4 released
Hello everyone, The OpenStack Stable Maintenance team is happy to announce the 2014.1.4 stable Icehouse release. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A total of 89 bugs have been fixed across all projects since 2014.1.3. These updates to Icehouse are intended to be low risk with no intentional regressions or API changes. The list of bugs, tarballs and other milestone information for each project may be found on Launchpad: https://launchpad.net/ceilometer/icehouse/2014.1.4 https://launchpad.net/cinder/icehouse/2014.1.4 https://launchpad.net/glance/icehouse/2014.1.4 https://launchpad.net/heat/icehouse/2014.1.4 https://launchpad.net/horizon/icehouse/2014.1.4 https://launchpad.net/keystone/icehouse/2014.1.4 https://launchpad.net/neutron/icehouse/2014.1.4 https://launchpad.net/nova/icehouse/2014.1.4 https://launchpad.net/trove/icehouse/2014.1.4 Release notes may be found on the wiki: https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.4 The freeze on the stable/icehouse branches will be lifted today as we begin working toward 2014.1.5, the last planned official Icehouse release. Thanks, Alan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions
Hi, next Icehouse stable point release 2014.1.4 has been slipping last few weeks due to various gate issues, see Recently closed section in https://etherpad.openstack.org/p/stable-tracker for details. Branch looks good enough now to push the release tomorrow (Thursdays are traditional release days) and I've put freeze -2s on the open reviews. I'm sorry about the short freeze period but branch was effectively frozen last two weeks due to gate issues and further delay doesn't make sense. Attached is the output from the stable_freeze script for thawing after tags are pushed. At the same time I'd like to propose following freeze exceptions for the review by stable-maint-core: * https://review.openstack.org/144714 - Eventlet green threads not released back to pool Justification: while not OSSA fix, it does have SecurityImpact tag * https://review.openstack.org/163035 - [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Justification: pending merge on master and juno Cheers, Alan stable_freeze.txt-2014.1.4 Description: Binary data __ 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] [all] Testtools 1.7.0 may error if you installed it before reading this email
So, we can work around this in devstack, but it seems like there is a more fundamental bug here that setup project isn't following dependencies. Dep chain was: testtools (from zake=0.1-tooz=0.12,=0.3-ceilometer==2014.2.3.dev2) Unneeded _runtime_ dependency on testtools was removed in https://github.com/yahoo/Zake/commit/215620ca51c3c883279ba62ccc860a274219ecc1 Is this just another 'pip is drunk' issue in it not actually satisfying requirements? Seems that pip is drunk by design, clarkb explained that pip only updates deps if you pass the --upgrade flag. Cheers, Alan __ 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] [all] Testtools 1.7.0 may error if you installed it before reading this email
The wheel has been removed from PyPI and anyone installing testtools 1.7.0 now will install from source which works fine. On stable/icehouse devstack fails[*] with pkg_resources.VersionConflict: (unittest2 0.5.1 (/usr/lib/python2.7/dist-packages), Requirement.parse('unittest2=1.0.0')) when installing testtools 1.7.0 unittest2 is not capped in stable/icehouse requirements, why is it not upgraded by pip? Cheers, Alan [*] e.g. http://logs.openstack.org/14/144714/3/check/check-tempest-dsvm-neutron/4d195b5/logs/devstacklog.txt.gz __ 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] [neutron] New version of python-neutronclient release: 2.3.11
https://review.openstack.org/#/c/157535/ Do you know where it ends ? We could set up Depends lines on those requirements stable/* reviews and line them up so that they are ready to merge when openstackclient is fixed in devstack. Alternative workaround is https://review.openstack.org/157654 which is blocked on swift-dsvm-functional issue fixed by https://review.openstack.org/157670 which is blocked on neutronclient i.e. we got a cyclic dep here which will require ninja merge to resolve. I suggest to start with ninja merging 157670 which looks the most innocent. Once we get icehouse working again we can look at backporting venv patch series to devstack icehouse. Cheers, Alan __ 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] [neutron] New version of python-neutronclient release: 2.3.11
(I believe the version cap for icehouse 2.4 is expected to a policy like this). Yes, that assumed Semantic Versioning (semver.org) which 2.3.11 broke. Cheers, Alan __ 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] [all][tc] Lets keep our community open, lets fight for it
I think there's a place for private conversation (eg. discussing a security issue that corresponds to a CVE... CVE's are a special exception and I'd even argue on the need of private conversations there. Discussing CVEs in private came up few times but I'm not sure IRC is secure enough for that. IMHO discussion about embargoed issues must be kept in private Launchpad bugs but I'd like to hear from VMT team. Cheers, Alan __ 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] [stable] juno is fubar in the gate
Tracking etherpad: https://etherpad.openstack.org/p/wedged-stable-gate-feb-2015 BTW there is a tracking etherpad updated by https://wiki.openstack.org/wiki/StableBranch#Stable_branch_champions https://etherpad.openstack.org/p/stable-tracker linked in https://wiki.openstack.org/wiki/StableBranch#Gate_Status and announced on this list http://lists.openstack.org/pipermail/openstack-dev/2015-January/05.html From crossed items in Recently closed section you can see that branch champions have been busy. You are missing the fact that a bunch of us (Matt Treinish, myself and others) are frustrated by the fact that we end up fixing stable branches whenever they break because we touch tempest, grenade and other projects that require working stable branches. But we do not want to be working on stable branches ourselves. I begrudgingly stepped up to work on pinning all requirements on stable branches, to reduce the number of times stable branches break and ruin my day. But my plan to cap dependencies has been delayed several times by stable branches breaking again and again, along with unwinding undesired behaviors in our testing harnesses. Most recently, stable/juno grenade broke on February 4th (due to the release of tempest-lib 0.2.0). This caused bug So that's a change in tooling, not stable branch itself. Idea when 15 months for Icehouse was discussed was that branchless Tempest would make it easier, but now it turns out that's making both tooling and stable branch unhappy. What I expect to happen when issues like this arise is interested parties work together to fix things and be proactive and make stable testing more robust. Instead we currently have people who have no desire to work on stable branches maintaining them. At least parts of stable team have been pro-active (see above etherpad) but I guess we have a communication issue here: has anyonetried to contact stable branch champions (juno=Adam, icehouse=Ihar) and what exactly do you expect stable team to do? AFAICT these are all changes in tooling where stable-maint is not core (devstack, tempest)... BTW Icehouse 2014.1.4 was planned[*] for Feb 19 with freeze starting on Feb 12, I'll delay it for now until we sort the current situation out. Cheers, Alan [*] https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases __ 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] django-openstack-auth and stable/icehouse
Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-openstack-auth==1.1.9 # git sha 2079383 It's because of this: 2015-01-27 19:33:44.152 | Collecting oslo.config=1.4.0 (from python-keystoneclient=0.11.1-python-openstackclient=1.0.1) After that installs 1.6.0, consequent pip runs assume that 1.6.0 is always better than 1.4.0 and disregards version cap, hence does not downgrade the library. Should we finally cap versions for clients so that they don't fetch new library versions? Clients are capped in stable/icehouse requirements but devstack in gate seems to be installing them from git master (note # git sha) Cheers, Alan __ 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] django-openstack-auth and stable/icehouse
Bumping minimal oslo.config version due to the issue in django-openstack-auth seems like a wrong way to do it. Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-openstack-auth==1.1.9 # git sha 2079383 Cheers, Alan __ 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