Re: [openstack-dev] [constraints] Updating stable branch URL
On Tue, Jun 28, 2016 at 9:38 AM, Tony Breeds wrote: > On Mon, Jun 27, 2016 at 11:28:47PM +, Jeremy Stanley wrote: > >> I want to say there was a reason we were branching the requirements >> repo last, but now I can't remember what it is (or if we even did >> branch it last). Thierry or Doug likely recall but are indisposed >> this week so I suggest waiting until they're around to reply before >> making a decision on this anyway (especially since it's the Release >> Managers who will need to adjust that process if it does merit >> changing). I don't remember the specifics, but I had a chat about this some time ago, and concur. As well, requirements branched a couple weeks after both Nova and Neutron this time around, I didn't check any others. Regardless, I don't think there is any way to make a compelling argument that the constraints URL should ever dictate when the reqs repo should be branched, even if there weren't current restrictions to this. > I'm not certain how this is different to updating .gitreview and the default > branch? Can't we extend the tools[1] that do that step with the updating of > tox.ini? I initially had the same thought as Jeremy here, forgetting it could sit in review on the stable branch. While having it sit in the queue and needing to be manually checked if it can be merged yet is sub-optimal, I think that is probably the best option so far. The commit message could contain details as to the limitations/a link to documentation. > It could be worked around with > additional logic to fall back on the master URL if the branch > doesn't exist, but it's also possible we just document this as a > shortcoming for the sake of simplicity. This would be wonderful, but I think it would raise the barrier to entry on constraints a bit too high and would end up relying a bit too much on un-gated code that would mostly be cargo-cult. To support this with tox, would require wrapping the tox install_command on any project that wishes to use constraints, and modifying existing wrapped install_command, which is common with the neutron-*aas projects, without any easy way to update any of them. > OK, lets wait and see what they say. Sounds good. Cheers, Sachi __ 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] [constraints] Updating stable branch URL
To facilitate upper-constraints on developer systems we have a hard-coded URL in projects tox.ini. This URL needs to change when after the openstack/requirements repo has created a branch for the stable release. This is in reference to [0]. There was some mention of possibly adding this to stable-branch creation procedure, but as requirements tends to release later, and that it would require a whole bunch of special notes this seems sub-optimal. Any thoughts on the best way to support this without a bunch of manual work? [0]: https://review.openstack.org/#/c/267941/ Cheers, Sachi __ 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] Sachi King for oslo core
Thanks for the vote of confidence all, I look forward to expanding what I'm working on. Cheers, Sachi __ 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][neutron] upper constraints for stable/liberty
On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote: > Robert Collins wrote: > > On 14 November 2015 at 02:53, Ihar Hrachyshka wrote: > >> I was recently looking into how stable/liberty branches are set for > >> neutron > >> in terms of requirements caps, and I realized that we don’t have neither > >> version caps nor upper constraints applied to unit test jobs in > >> stable/liberty gate. We have -constraints targets defined in tox.ini, but > >> they are not running in gate. > >> > >> I believe this situation leaves us open to breakages by any random > >> library > >> releases out there. Am I right? If so, I would like to close the breakage > >> vector for projects I care (all neutron stadium). > >> > >> I suggest we do the following: > >> > >> - unless there is some specific reason for that, stop running > >> unconstrained > >> jobs in neutron/master; > > > > Sachi King is working up a bit of data mining to confirm that the > > constraints jobs are only failing when unconstrained jobs fail - then > > we're going to propose the change to project-config to switch around > > which vote. > > For what I saw in neutron, it never fails unless there is actual constraint > not bumped. Scraping before flipping the switch was just to be really sure we were not going to break anything before we went for it. After scraping master and stable/liberty everything does indeed look good. The script found some issues, but they were all caused by a bug in a tox release. If anyone is interested in pulling the stats out to verify I have uploaded my scraper to [0]. It's rough, but it got me the data. > >> - enable voting for constraints jobs in neutron/liberty; once proved to > >> work > >> fine, stop running unconstrained jobs in neutron/liberty; > > > > I expect the same query can answer this as well. > > > >> - for neutron-*aas, introduce constraints targets in tox.ini, enable > >> jobs in > >> gate; make them vote there/remove old jobs; > >> - after that, backport constraints targets to stable/liberty; make them > >> vote > >> there/remove old jobs. > > > > We're going to advocate widespread adoption once the neutron master > > ones are voting > > > >> Does the plan make sense? > > > > Totally :) As non-Neutron-contributors we've just been conservative in > > our recommendations; if Neutron wants to move a little faster by > > taking on a little risk, thats *totally cool* IMO. > > I believe there is general understanding that it’s the way to go, and we > were already happy to be guinea pigs for initial data mining, so I don’t > expect problems getting the core team onboard. > > My question was more about what we do with stable/liberty branches. Is it > part of the plan that we backport the constraint jobs there? Yes, the plan is to switch the -constraints jobs to voting in liberty as well. We've got -constraints operating in a non-voting fasion there just as in master and it looks good to flip over as well. I've pushed [1] up for review to flip neutron's -constraints to voting on both master and liberty. I could definatly use some eyes over it, as well as voice from the neutron team to give the signal that it has the go-ahead. [0] https://github.com/nakato/checkconstraints [1] https://review.openstack.org/#/c/247306/ Cheers, Sachi __ 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] [Cross Project] [Neutron] [Nova] Tox.ini changes for Constraints testing
Hi, I'm working on setting up both Nova and Neutron with constrained unit tests. More details about this can be found in the changes can be found in it's blueprint [0]. An example issue this will prevent is Neutron's recent gate breakage caused by a new netaddr version. [1] Now that the base changes have landed in project-config the next step is to modify tox.ini to run an alterniate install command when called with the 'constraints' factor. Nova: https://review.openstack.org/205931/ Neutron: https://review.openstack.org/219134/ This change is a no-op for current gate jobs and developer workflows, only adding the functionality required for the new constraints jobs and manual execution of the constrained tests when desired. Once these have been added we can then proceed adding the py27 and 34 jobs, which will be non-voting at this point. Nova: https://review.openstack.org/219582/ Neutron: https://review.openstack.org/219610/ [0] http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html [1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073239.html If there are any other projects interested in being an early adopter of constrained unit tests, please let me know. Cheers, Sachi __ 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] Netaddr 0.7.16 and gate breakage
On Tue, Sep 1, 2015 at 3:15 AM, Carl Baldwin wrote: > On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote: >> On 31 August 2015 at 09:53, Jeremy Stanley wrote: >>> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: >>> > I was under the impression that we had a plan to stop allowing these >>> > external updates break our gate jobs. >>> [...] >>> >>> We do, and it succeeded in protecting master branch integration test >>> jobs from this new netaddr release: >>> >>> https://review.openstack.org/218737 >>> >>> This was able to get implemented fairly early because DevStack >>> already contained mechanisms for relying on the requirements repo to >>> define its behavior WRT dependencies. The logistics for pinning >>> versions in every project's unit tests, however, are more complex >>> and not yet in place (but are in progress). Also where grenade is >>> concerned, the breakage is on the stable/kilo side where we don't >>> have constraints pinning implemented (since that work has been >>> primarily in master this cycle and targeting liberty). > > Thanks for the update Jeremy. It looks like there is still some work > to do that I wasn't aware of. Is there somewhere where we can follow > the progress of this work? Hi Carl, currently we're working on getting the required work into project config, which means the change to tox.ini is currently going through some revisions. Project config: https://review.openstack.org/207262/ Nova tox.ini example: https://review.openstack.org/205931 I've created a change for Neutron's tox.ini. This doesn't change anything, so it should pass CI, but if there's a merge conflict with a external CI's tox.ini this will flush it out. https://review.openstack.org/219134/ >> Great...if there is any collaboration required by the individual projects, >> please do not hesitate to reach out...we'd be happy to do our part. > > +1 Let us know how to pitch in. For now there's not much to do, the project-config change is the change that has to go in first. Once that is in we can get the 'constraints' factor into individual projects tox.ini and add the constraints jobs. If neutron would like to be one of the initial projects to enable these tests that would be quite helpful as I've yet to recruit any initial projects. Cheers, Sachi __ 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] [oslo] oslo.service graduating - Primary Maintainers
Hi, Oslo service is graduating and is looking for a primary maintainer. The following are the listed maintainers for the submodules that are not orphans. service - Michael Still periodic_task - Michael Still Requestutils - Sandy Walsh systemd - Alan Pevec Would any of you like to take up being the primary maintainer for oslo.service? Additionally do you have any pending work that we should delay graduation for? Further details can be found in the in-progress spec. https://review.openstack.org/#/c/142659/ Cheers, Sachi signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] kilo graduation plans
On Wednesday, November 12, 2014 02:06:02 PM Doug Hellmann wrote: > During our “Graduation Schedule” summit session we worked through the list of > modules remaining the in the incubator. Our notes are in the etherpad [1], > but as part of the "Write it Down” theme for Oslo this cycle I am also > posting a summary of the outcome here on the mailing list for wider > distribution. Let me know if you remembered the outcome for any of these > modules differently than what I have written below. > > Doug > > > > Deleted or deprecated modules: > > funcutils.py - This was present only for python 2.6 support, but it is no > longer used in the applications. We are keeping it in the stable/juno branch > of the incubator, and removing it from master > (https://review.openstack.org/130092) > > hooks.py - This is not being used anywhere, so we are removing it. > (https://review.openstack.org/#/c/125781/) > > quota.py - A new quota management system is being created > (https://etherpad.openstack.org/p/kilo-oslo-common-quota-library) and should > replace this, so we will keep it in the incubator for now but deprecate it. > > crypto/utils.py - We agreed to mark this as deprecated and encourage the use > of Barbican or cryptography.py (https://review.openstack.org/134020) > > cache/ - Morgan is going to be working on a new oslo.cache library as a > front-end for dogpile, so this is also deprecated > (https://review.openstack.org/134021) > > apiclient/ - With the SDK project picking up steam, we felt it was safe to > deprecate this code as well (https://review.openstack.org/134024). > > xmlutils.py - This module was used to provide a security fix for some XML > modules that have since been updated directly. It was removed. > (https://review.openstack.org/#/c/125021/) > > > > Graduating: > > oslo.context: > - Dims is driving this > - https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-context > - includes: > context.py > > oslo.service: During the "Oslo graduation schedule" meet up someone was mentioning they'd be willing to help out as a contact for questions during this process. Can anyone put me in contact with that person or remember who he was? > - Sachi is driving this > - https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-service > - includes: > eventlet_backdoor.py > loopingcall.py > periodic_task.py > request_utils.py > service.py > sslutils.py > systemd.py > threadgroup.py > > oslo.utils: > - We need to look into how to preserve the git history as we import these > modules. > - includes: > fileutils.py > versionutils.py > > > > Remaining untouched: > > scheduler/ - Gantt probably makes this code obsolete, but it isn’t clear > whether Gantt has enough traction yet so we will hold onto these in the > incubator for at least another cycle. > > report/ - There’s interest in creating an oslo.reports library containing > this code, but we haven’t had time to coordinate with Solly about doing that. > > > > Other work: > > We will continue the work on oslo.concurrency and oslo.log that we started > during Juno. > > [1] https://etherpad.openstack.org/p/kilo-oslo-library-proposals > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev