Re: [openstack-dev] [constraints] Updating stable branch URL

[Sachi King]

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

[Sachi King]

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

[Sachi King]

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

[Sachi King]

On Wed, 18 Nov 2015 02:07:45 PM Ihar Hrachyshka wrote:
> Robert Collins <robe...@robertcollins.net> wrote:
> > On 14 November 2015 at 02:53, Ihar Hrachyshka <ihrac...@redhat.com> 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

[Sachi King]

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

[Sachi King]

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

[Sachi King]

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

[Sachi King]

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