Re: [openstack-dev] [diskimage-builder] Does anyone use "fedora" target?
On 17-08-29 17:21:00, Ian Wienand wrote: > Hi, > > The "fedora" element -- the one that downloads the upstream .qcow2 and > re-packages it -- is currently broken as the links we use have > disappeared [1]. Even allowing for this, it's still broken with some > changes to the kernel install scripts [2]. AFAICT, the only thing > noticing this is our CI. > > fedora-minimal takes a different approach of building the system > within a blank chroot. It's what we use to create the upstream > images. > > I believe the octavia jobs switched to fedora-minimal? > > Is there anyone still using these image-based jobs? Is there any > reason why you can't use fedora-minimal? I don't really see this as > being that useful, and our best path forward might be just to retire > it. > > Thanks, > > -i > > [1] https://review.openstack.org/497734 > [2] https://bugs.launchpad.net/diskimage-builder/+bug/1713381 > > __ > 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 We use it downstream to build ironic images using the process kevin documented here. https://cloudnull.io/2016/11/osic-building-baremetal-ironic-images/ It can probably be updated but it'd be nice for it to not disapear out from under us. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 17-08-29 14:09:32, Claudiu Belu wrote: > Hello, > > As many of you know, during Kilo, the neutron vendor decomposition happened, > which lead to the birth of many networking-* libraries, including > networking-hyperv. When it was time for us to make a release for that cycle, > pretty much every networking-* project followed the release version number at > that time, which was 2015.1.0. After Kilo, the versioning changed to the > current format. > > networking-hyperv currently contains the "hyperv" mechanism_driver, which is > needed in order to bind neutron ports to Hyper-V compute nodes using > neutron-hyperv-agent L2 agents. > > Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, > and whenever someone upgrades networking-hyperv through pip (pip install -U > networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already > installed, networking-hyperv==2015.1.0 is installed, as that is considered > the "latest" version: > > (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv > > (test) ubuntu@ubuntu:~$ pip install networking-hyperv > ... > (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv > networking-hyperv==2015.1.0 > > This is a common pitfall for people using pip to install / upgrade > networking-hyperv. It's actually become a ritual for new developers to > mistakenly install the "latest" version. :) > > Now, my question is: could we / should we unpublish the 2015.1.0 version? > > [1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0" > https://review.openstack.org/#/c/498409/1 > [1] #openstack-release: > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28 > [2] #openstack-release: > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36 > > > Best regards, > > Claudiu Belu > > __ > 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 I think we have three options here. 1. Unpublish. This is probably the simplest, but generally goes against the policy of pypi to never unpublish things (it is not a hard and fast rule though). 2. Rename. A bunch of work for downstreams but technically cleaner/better than unpublishing, allows a more consistant naming scheme to be used if desired at least. 3. reversion. Start new versions at 3000 or something, kinda dirty imo. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 17-08-29 15:58:55, Jeremy Stanley wrote: > On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote: > [...] > > 3. reversion. Start new versions at 3000 or something, kinda > > dirty imo. > > And sort of a 3.1 option is to prepend a PEP 440 version epoch: > > https://www.python.org/dev/peps/pep-0440/#version-epochs > > Challenge there is that, while Git can handle a ! in a tag name, PBR > doesn't know to sort that after implicit 0 epochs nor does a lot of > our release automation have the ability to cope with version epochs > and adding support for them would entail a lot of careful work and > thorough testing. Also having upstream epochs could wreak havoc with > downstream distro package maintainers, look confusing in > tarball/wheel filenames (hopefully all modern platforms are at least > not going to break when there's a ! in a filename), and so on. > > The concerns were touched on in this thread from 2015 when the > versioning changes were going into effect: > > http://lists.openstack.org/pipermail/openstack-dev/2015-July/069085.html > > Pretty unlikely to happen if you ask me. I'm just bringing it up > preemptively since odds are someone else with less history/memory of > the scenarios we discussed back then is likely to bring it up as a > silver bullet solution otherwise. > -- > Jeremy Stanley I almost mentioned that, but as you said, the barrier to entry there is so high. -- Matthew Thode signature.asc Description: PGP signature __ 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][stable] EOL tags and upper-constraints.txt in tox.ini
On 17-09-20 13:35:44, Michal Pryc wrote: > Hi, > > EOL releases for the nova component (checked neutron as well, possibly many > other components) have wrong pointers to the upper-constraints.txt files as > they are referencing stable/branch rather then branch-eol, see example: > > https://github.com/openstack/nova/blob/liberty-eol/tox.ini#L12 > > Line: > https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/liberty > > Should be: > https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=liberty-eol > > EOL means there should be no more changes to the release, but in this case > process of EOL'ing made regression as now it's impossible to run tests > against those tags (this applies to liberty/mitaka and in the future newer > releases). > > Should this be fixed somehow or EOL isn't really meant to be touched and > fixed and those will be left broken ? > > -- > best > Michal Pryc > __ > 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 I think this is an error in our process that should be fixed (newton is going EOL soon). While it'd be nice to fix I don't think it's worth the effort as an EOL'd and now unbranched project. We could create a temporary branch from the commit and retag, but as a rule we should not use the same tag twice (removing the pointer that existed and reusing it to point to a diferent commit). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][stable] EOL tags and upper-constraints.txt in tox.ini
On 17-09-20 13:43:51, Tony Breeds wrote: > On Wed, Sep 20, 2017 at 01:08:45PM -0400, Doug Hellmann wrote: > > Excerpts from Jeremy Stanley's message of 2017-09-20 13:36:38 +: > > > On 2017-09-20 08:41:14 -0400 (-0400), Doug Hellmann wrote: > > > [...] > > > > Is there any reason not to use the published files for all regular > > > > builds, instead of having tox.ini point to a git URL? Maybe only for > > > > regular builds off of stable branches? > > > > > > I'm not sure what you mean by "regular builds" but the plan as I > > > > s/regular/non-CI/ > > > > > understood it was to switch from git.o.o URLs to releases.o.o URLs > > > in the tox.ini files in all branches of projects already consuming > > > constraints files that way. > > > > > > As early as now (if we already had the publication job in place) we > > > could update them all in master branches to retrieve something like > > > https://releases.openstack.org/constraints/queens-upper-constraints.txt > > > and then once stable/queens is branched in all repos (including the > > > requirements repo), switch the job to begin publishing to a URL for > > > rocky and push tox.ini updates to master branches switching the URL > > > to that as early in the cycle as possible. Alternatively, we could > > > publish master and queens copies (identical initially) and expect > > > the master branch tox.ini files to refer to master but then switch > > > them to queens on the stable/queens branch during RC. It just comes > > > down to which the stable/requirements/release teams think makes the > > > most sense from a procedural perspective. > > > > We should think through which of those approaches is going to result in > > the least amount of synchronization. We do have a window in which to > > make changes in a given branch for consuming projects, but making the > > relevant changes in the requirements repository seems like it could be > > error prone, especially because we try to branch it after the other > > repositories. > > The solution I thought we decide on at the PTG is: > * Add a post job to all branches that publish a constraints/$series.txt >to $server (I don't mind if it's releases.o.o or tarballs.o.o). > * On the master branch we publish both master.txt and $series.txt >(currently queens.txt) when we fork rocky from master we update the >publish job to publish master and rocky.txt.As Doug points out >there is a timing race here but it;s much smaller than the one we >have now. > * We update the projects to use the static (non-git) URL for the >constraints files. > * We update the release tools to generate the new style URL. > > Optionally, and this requires discussion, we use a custom tox_install.sh > to extract the branch from .gitreview and generate the URL which would > remove the need for the last step. There are clearly pros and cons to > that so I'm not advocating for it now. > > Those constraints files would never be removed but they'd stop getting > updated when we EOL the requirements branch. > > How does that sound? > > Yours Tony. That's correct, I haven't had time this week to create the jobs quite yet, but hope to do so either this weekend or next week. It's #3 in our list of items to generate tasks/bugs from. https://etherpad.openstack.org/p/queens-PTG-requirements -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][stable] publish upper-constraints.txt periodic vs post
On 17-09-20 14:09:15, Tony Breeds wrote: > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote: > > > The solution I thought we decide on at the PTG is: > > * Add a post job to all branches that publish a constraints/$series.txt > >to $server (I don't mind if it's releases.o.o or tarballs.o.o). > > Actually we might be better to do this daily from the periodic pipeline. > In our CI we always gate with what is in git so that wouldn't be > impacted. The question is do we need external consumers to be "up to > the minute" or is a days lag acceptable? > > I kinda feel like it's okay to be a little laggy. > > Yours Tony. I don't think this should be periodic, I'll try to argue the point via a pros/cons listing. I think we should be trying to have users use upper-constraints via what is currently known as stable, to me that means more often than once a day. I'm probably a bit biased, so feel free to update :D pros - periodic * simple update schedule (once a day) * easier on infra (publish just once vs up to 20-30 times a day) cons - periodic * point in time (once a day) does not guarantee that that point works while we try to ensure all projects are not impacted by changes, we are not perfect * we would be making it harder for people to use upper-constraints externally for one thing (via longer turn around time) * some projects may be using upper-constraints.txt from the url only pros - post * upper-constraints are available via published location immediately * sets good precident for end users/devs to use it cons - post * both breaks and fixes quick * more load on infra to publish (20-30 times a day) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][stable] publish upper-constraints.txt periodic vs post
On 17-09-21 12:09:52, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2017-09-21 10:43:50 -0500: > > On 17-09-20 14:09:15, Tony Breeds wrote: > > > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote: > > > > > > > The solution I thought we decide on at the PTG is: > > > > * Add a post job to all branches that publish a constraints/$series.txt > > > >to $server (I don't mind if it's releases.o.o or tarballs.o.o). > > > > > > Actually we might be better to do this daily from the periodic pipeline. > > > In our CI we always gate with what is in git so that wouldn't be > > > impacted. The question is do we need external consumers to be "up to > > > the minute" or is a days lag acceptable? > > > > > > I kinda feel like it's okay to be a little laggy. > > > > > > Yours Tony. > > > > I don't think this should be periodic, I'll try to argue the point via a > > pros/cons listing. I think we should be trying to have users use > > upper-constraints via what is currently known as stable, to me that > > means more often than once a day. > > > > I'm probably a bit biased, so feel free to update :D > > > > pros - periodic > > * simple update schedule (once a day) > > * easier on infra (publish just once vs up to 20-30 times a day) > > > > cons - periodic > > * point in time (once a day) does not guarantee that that point works > > while we try to ensure all projects are not impacted by changes, we > > are not perfect > > * we would be making it harder for people to use upper-constraints > > externally > > for one thing (via longer turn around time) > > * some projects may be using upper-constraints.txt from the url only > > > > pros - post > > * upper-constraints are available via published location immediately > > * sets good precident for end users/devs to use it > > > > cons - post > > * both breaks and fixes quick > > * more load on infra to publish (20-30 times a day) > > > > Another point against a periodic job is that it would be a change from > what we're doing now, where constraints are updated as soon as the git > cache is updated. > > I think we should publish using a post-merge job. The job isn't > expensive, right? It's just copying some files out of git onto the > web server? > > Do we really land 20-30 changes to the constraints list on an average > day? > > Doug > It is just copying the file, so nothing big (small file). I'd say 20-30 changes on a very busy day (giving it the worst case). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][stable] EOL tags and upper-constraints.txt in tox.ini
On 17-09-21 12:13:23, Doug Hellmann wrote: > Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400: > > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote: > > > > > I like the idea. I'm not sure why, if the constraints file is only used > > > for the dependency installation step, we still need tox_install.sh? > > > > Right now that isn't true, when we get something like my idea > > implemented we'd still need the tox_install.sh in projects that need > > services (not published on pypi) like horizon plugins or neutron stadium > > projects. Fixing that issue is a totally different discussion, one I > > started at the PTG but I need to let those conversations settle and do > > research on wasy to fix that. > > > > > If > > > that's just to avoid updating the URL when we create branches, I can > > > live with continuing to do that step if we figure out some other way to > > > minimize the open race window. > > > > So lets check we're on the same page with the race window point. At the > > moment the process looks like: > > 1. projects tag RC1 and when generate a stable/series branch. > > 2. We generate a reviews that updates .gitreview > > 3. We generate a reviews that updates .tox.ini > > 4. time passes > > 5. requirements creates a stable/series branch > > 6. requirements thaws > > > > Now the race is that if projects merge the patch from step 3 before step > > 5 they're broken (on stable/series) because there isn't a > > 'stable/series' in the requirements repo. There are some additional issues > > for cycle-trailing projects but nothing radically different. > > > > Correct? > > > > Assuming I have that right In the new world: > > > > 0. requirements publish master.txt and series.txt > > 1. projects tag RC1 and when generate a stable/series branch. > > 2. We generate a reviews that updates .gitreview > > 3. We generate a reviews that updates .tox.ini > > 4. time passes > > 5. requirements creates a stable/series branch > > 6. requiremenst now publish series.txt, new_series.txt and master.txt > > 6. requirements thaws > > Where in that sequence do we make the change so that we're not > publishing to series.txt from the new stable branch in requirements and > from master in requirements? Between step 4 and 5? Or is the job smart > enough to not do that? > > Where in the sequence do we add new_series.txt? Also between 4 and 5? > That step of switching from publishing series.txt to new-series.txt happens in step 6. Step 6 should be dependant on step 5's patchset/review. The requirements freeze itself hapens some time during step 4 I think. > > In this scenario We've removed the race as there is a series.txt file > > available befoer the project and requirements branch. > > > > Also[1] if, right now, projects used queens.txt we wouldn't need to > > update tox.ini when we branch stable/queens, but we would need to update > > master. This is a point of confusion that we'll need to document and > > possible check for somewhere in our tools. > > > > Yours Tony. > > > > [1] This just occurred to me > > __ > 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 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][stable] EOL tags and upper-constraints.txt in tox.ini
eview and UPPER_CONSTRAINTS
> > changes
> > ACTIONS: Projects merge .gitreview and
> > UPPER_CONSTRAINTS changes
> > Feb 12 - Feb 16R-2
> > ACTIONS: Projects create stable/queens branch for
> > openstack/requirements
> > ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS
> > changes
> > ACTIONS: Projects merge .gitreview and
> > UPPER_CONSTRAINTS changes
> > ACTIONS: Make sure master publishes {rocky,master}.txt
> > (optionally add the S release at this point,
> > it doesn't hurt)
>
> We could add new "future" series names as soon as we know them, since we
> would just be publishing to a file that nothing uses.
>
> > Feb 19 - Feb 23R-1
> > Feb 26 - Mar 02R+0Queens release
> > Mar 05 - Mar 09R+1
> > Mar 12 - Mar 16R+2Queens cycle-trailing release deadline
> >
> > There's a whole other side issue about how long requirements is frozen
> > for. Ignoring that do you think the above process will remove the race,
> > and mean that EOL branches can possibly continue to run tests?
> >
> >
> > Yours Tony.
>
> Yes, that does look like a sound approach.
>
> Doug
>
Sounds good, I've created a bug we can start linking reviews to (along
with documenting the final plan).
https://bugs.launchpad.net/openstack-requirements/+bug/1719006
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
__
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] [requirements] moving driver dependencies to global-requirements?
On 17-10-30 20:48:37, arkady.kanev...@dell.com wrote: > The second seem to be better suited for per driver requirement handling and > per HW type per function. > Which option is easier to handle for container per dependency for the future? > > > Thanks, > Arkady > > -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Monday, October 30, 2017 2:47 PM > To: openstack-dev > Subject: Re: [openstack-dev] [ironic] [requirements] moving driver > dependencies to global-requirements? > > Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100: > > Hi all, > > > > So far driver requirements [1] have been managed outside of > > global-requirements. > > This was mostly necessary because some dependencies were not on PyPI. > > This is no longer the case, and I'd like to consider managing them > > just like any other dependencies. Pros: > > 1. making these dependencies (and their versions) more visible for > > packagers 2. following the same policies for regular and driver > > dependencies 3. ensuring co-installability of these dependencies with > > each other and with the remaining openstack 4. potentially using > > upper-constraints in 3rd party CI to test what packagers will probably > > package 5. we'll be able to finally create a tox job running unit > > tests with all these dependencies installed (FYI these often breaks in > > RDO CI) > > > > Cons: > > 1. more work for both the requirements team and the vendor teams 2. > > inability to use ironic release notes to explain driver requirements > > changes 3. any objections from the requirements team? > > > > If we make this change, we'll drop driver-requirements.txt, and will > > use setuptools extras to list then in setup.cfg (this way is supported > > by g-r) similar to what we do in ironicclient [2]. > > > > We either will have one list: > > > > [extras] > > drivers = > >sushy>=a.b > >python-dracclient>=x.y > >python-prolianutils>=v.w > >... > > > > or (and I like this more) we'll have a list per hardware type: > > > > [extras] > > redfish = > >sushy>=a.b > > idrac = > >python-dracclient>=x.y > > ilo = > >... > > ... > > > > WDYT? > > The second option is what I would expect. > > Doug > > > > > [1] > > https://github.com/openstack/ironic/blob/master/driver-requirements.tx > > t [2] > > https://github.com/openstack/python-ironicclient/blob/master/setup.cfg > > #L115 > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The first question I have is if ALL the drivers are suposed to be co-installable with eachother. If so, adding them to requirements sounds fine, as long as each one follows https://github.com/openstack/requirements/#for-new-requirements . As far as the format, I prefer option 2 (the breakout option). I'm not sure if the bot will need an update, but I suspect not as it tries to keep ordering iirc. -- Matthew Thode signature.asc Description: PGP signature __ 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] [requirements] moving driver dependencies to global-requirements?
On 17-10-30 20:48:37, arkady.kanev...@dell.com wrote: > The second seem to be better suited for per driver requirement handling and > per HW type per function. > Which option is easier to handle for container per dependency for the future? > > > Thanks, > Arkady > > -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Monday, October 30, 2017 2:47 PM > To: openstack-dev > Subject: Re: [openstack-dev] [ironic] [requirements] moving driver > dependencies to global-requirements? > > Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100: > > Hi all, > > > > So far driver requirements [1] have been managed outside of > > global-requirements. > > This was mostly necessary because some dependencies were not on PyPI. > > This is no longer the case, and I'd like to consider managing them > > just like any other dependencies. Pros: > > 1. making these dependencies (and their versions) more visible for > > packagers 2. following the same policies for regular and driver > > dependencies 3. ensuring co-installability of these dependencies with > > each other and with the remaining openstack 4. potentially using > > upper-constraints in 3rd party CI to test what packagers will probably > > package 5. we'll be able to finally create a tox job running unit > > tests with all these dependencies installed (FYI these often breaks in > > RDO CI) > > > > Cons: > > 1. more work for both the requirements team and the vendor teams 2. > > inability to use ironic release notes to explain driver requirements > > changes 3. any objections from the requirements team? > > > > If we make this change, we'll drop driver-requirements.txt, and will > > use setuptools extras to list then in setup.cfg (this way is supported > > by g-r) similar to what we do in ironicclient [2]. > > > > We either will have one list: > > > > [extras] > > drivers = > >sushy>=a.b > >python-dracclient>=x.y > >python-prolianutils>=v.w > >... > > > > or (and I like this more) we'll have a list per hardware type: > > > > [extras] > > redfish = > >sushy>=a.b > > idrac = > >python-dracclient>=x.y > > ilo = > >... > > ... > > > > WDYT? > > The second option is what I would expect. > > Doug > > > > > [1] > > https://github.com/openstack/ironic/blob/master/driver-requirements.tx > > t [2] > > https://github.com/openstack/python-ironicclient/blob/master/setup.cfg > > #L115 > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Meant to reply from this address, but below is my original response. The first question I have is if ALL the drivers are suposed to be co-installable with eachother. If so, adding them to requirements sounds fine, as long as each one follows https://github.com/openstack/requirements/#for-new-requirements . As far as the format, I prefer option 2 (the breakout option). I'm not sure if the bot will need an update, but I suspect not as it tries to keep ordering iirc. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements] moving driver dependencies to global-requirements?
On 17-11-15 09:32:33, Dmitry Tantsur wrote: > On 10/31/2017 12:11 AM, richard.pi...@dell.com wrote: > > > From: Dmitry Tantsur [mailto:dtant...@redhat.com] > > > > > Cons: > > > 1. more work for both the requirements team and the vendor teams > > > > Please elaborate on the additional work you envision for the vendor teams. > > Any requirements updates with have to be submitted to the requirements repo. > It may take longer (may not). > We (requirements) are prety good about being on top of reviews :P > > > > > 2. inability to use ironic release notes to explain driver requirements > > > changes > > > > Where could that information move to? > > I think it's a generic question, to be honest. We don't inform operators of > requirements changes via release notes. I don't have an easy answer. > Should each driver have it's own release notes then? Not sure if that'd help. > > > > > We either will have one list: > > > > > > [extras] > > > drivers = > > > sushy>=a.b > > > python-dracclient>=x.y > > > python-prolianutils>=v.w > > > ... > > > > > > or (and I like this more) we'll have a list per hardware type: > > > > > > [extras] > > > redfish = > > > sushy>=a.b > > > idrac = > > > python-dracclient>=x.y > > > ilo = > > > ... > > > ... > > > > > > WDYT? > > > > > > > Overall, a big +1. I prefer the second approach. > > > > A couple of questions ... > > > > 1. If two (2) hardware types have the same requirement, would they both > > enter it in their lists? > > Yes > > > 2. And would that be correctly handled? > > Tony checked it (see his response to this thread) - yes. > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] adding uwsgi to global-requirements
On 17-12-19 19:50:59, Sam Yaple wrote: > > Original Message > > Subject: Re: [openstack-dev] [requirements] adding uwsgi to > > global-requirements > > Local Time: December 19, 2017 6:34 PM > > UTC Time: December 19, 2017 11:34 PM > > From: mtrein...@kortar.org > > To: Sam Yaple , OpenStack Development Mailing List (not for > > usage questions) > > > >> We don't want to dictate how people are deploying the webapps, instead we > >> say > >> we use the normal interfaces for deploying python webapps. So if your used > >> to > >> use mod_wsgi with apache, gunicorn + ngix, or uwsgi standalone, etc. you > >> can do > >> that. uwsgi in this context is the same as apache. It's not actually a > >> requirement for any project, you can install and run everything without > >> it, and > >> in fact many people do. > >> > >> The other half of this is that just pip installing uwsgi is not always > >> enough > >> to actually leverage using it with a webserver. You also need the web > >> server > >> support for talking to uwsgi. If that's how you use choose to deploy it, > >> which > >> is not always straightforward. For example, take a look at how it is > >> installed > >> in devstack to make uwsgi work properly with apache. [3] There are also > >> other > >> concerns using pip to install uwsgi. uWSGI is a C application and not > >> actually > >> a python project. It also supports running applications in several > >> languages[4], > >> not just python. The pypi published install is kind of a hack to download > >> the > >> tarball and compile the application with only the python bindings compiled. > >> The setup.py literally calls out to gcc to build it, it's essentially a > >> makefile > >> written in python. [5][6] > >> > >> So what advantage do we get by adding it to global requirements when it's > >> not > >> actually a requirement for any project, nor is it even python code? > > Not to discount the rest of your reply, but it does seem geared toward the > idea that this would force people to use uwsgi. > > The advantage is quite singular in my opinion, using upper-constraints.txt as > a pinning mechanism for testing the same version of uwsgi everywhere. > Additionally, projects do consume global-requirements.txt and > upper-constraints.txt and build _all_ wheels listed within. If uwsgi is not > in that list, it is an external package that must be specified to be built, > with appropriate version pinning now ona per-project basis. > > The fact that uwsgi is widely used, even as an implementation detail, is the > strongest arguement i have for shared version control of it. > So what happens when someone wants to use gunicorn or add another wsgi server to be tracked by the requirements repo? One of the the things we are around for is so projects know what library to use for X. We generally don't have any library that provides the same function as another without very good reason (the kafka stuff comes to mind). Is there any project that imports uwsgi python libraries as a dependency (or plans to)? If not, why would we tracking it? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0
On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote: > Hi, > > There is an open bug in launchpad about the new release of Networkx 2.0, that > is backward incompatible with versions 1.x [1]. > Is there a plan to change the Networkx version in the global requirements in > Queens? We need to make some code refactoring in Vitrage, and I’m trying to > understand how urgent it is. > > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576 > Mistral, Vitrage, Octavia, Taskflow, Watcher Those are the projects using NetworkX that'd need to be updated. http://codesearch.openstack.org/?q=networkx&i=nope&files=.*requirements.*&repos= I'm open to uncapping networkx if these projects have buyin. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0
On 17-12-20 10:56:50, Matthew Thode wrote: > On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote: > > Hi, > > > > There is an open bug in launchpad about the new release of Networkx 2.0, > > that is backward incompatible with versions 1.x [1]. > > Is there a plan to change the Networkx version in the global requirements > > in Queens? We need to make some code refactoring in Vitrage, and I’m trying > > to understand how urgent it is. > > > > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576 > > > > Mistral, Vitrage, Octavia, Taskflow, Watcher > > Those are the projects using NetworkX that'd need to be updated. > http://codesearch.openstack.org/?q=networkx&i=nope&files=.*requirements.*&repos= > > I'm open to uncapping networkx if these projects have buyin. > I've created https://review.openstack.org/531902 that your patches can depend upon. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [qa][requirements] CentOS libvirt versus newton/ocata libvirt-python
On 18-01-12 12:42:49, Ian Wienand wrote: > Hi, > > So I guess since CentOS included libvirt 3.2 (7-1708, or around RHEL > 7.4), it's been incompatible with libvirt-python requirements of 2.1.0 > in newton [1] and 2.5.0 in ocata [2] (pike, at 3.5.0, works). > > Do we want to do anything about this? I can think of several options > > * bump the libvirt-python versions on older branches > > * Create an older centos image (can't imagine we have the person > bandwidth to maintain this) > > * Hack something in devstack (seems rather pointless to test > something so far outside deployments). > > * Turn off CentOS testing for old devstack branches > > None are particularly appealing... > > (I'm sorry if this has been discussed, I have great déjà vu about it, > maybe we were talking about it at summit or something). > I thought I remembered something about it, but couldn't find it in the archives. First, about newton, it's dead (2017-10-11). Next, about ocata, it looks like it can support newer libvirt, but just because a distro updated a library doesn't mean we have to update. IIRC, for ubuntu they use cloud-archives to get the right version of libvirt, does something like that exist for centos/redhat? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [glance][oslo][requirements] oslo.serialization fails with glance
https://review.openstack.org/531788 is the review we are seeing it in, but 2.22.0 failed as well. I'm guessing it was introduced in either https://github.com/openstack/oslo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 or https://github.com/openstack/oslo.serialization/commit/cdb2f60d26e3b65b6370f87b2e9864045651c117 -- Matthew Thode signature.asc Description: PGP signature __ 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] [glance][oslo][requirements] oslo.serialization fails with glance
On 18-01-13 00:41:28, Matthew Thode wrote: > https://review.openstack.org/531788 is the review we are seeing it in, > but 2.22.0 failed as well. > > I'm guessing it was introduced in either > > https://github.com/openstack/oslo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 > or > https://github.com/openstack/oslo.serialization/commit/cdb2f60d26e3b65b6370f87b2e9864045651c117 bamp -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [glance][oslo][requirements] oslo.serialization fails with glance
On 18-01-16 19:12:16, ChangBo Guo wrote: > What's the issue for Glance, any bug link ? > > 2018-01-16 0:12 GMT+08:00 Matthew Thode : > > > On 18-01-13 00:41:28, Matthew Thode wrote: > > > https://review.openstack.org/531788 is the review we are seeing it in, > > > but 2.22.0 failed as well. > > > > > > I'm guessing it was introduced in either > > > > > > https://github.com/openstack/oslo.serialization/commit/ > > c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 > > > or > > > https://github.com/openstack/oslo.serialization/commit/ > > cdb2f60d26e3b65b6370f87b2e9864045651c117 > > > > bamp > > The best bug for this is https://bugs.launchpad.net/oslo.serialization/+bug/1728368 and we are currently getting test fails in https://review.openstack.org/531788 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [all][requirements] Freeze is coming next week
So get your changes in or get left behind :D -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] Freeze is coming next week
On 18-01-17 01:25:10, Matthew Thode wrote: > So get your changes in or get left behind :D > Just to be clear, the HARD deadline for the freeze will be Friday January 26th at 23:59:59 UTC -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [glance][oslo][requirements] [ironic]oslo.serialization fails with glance
On 18-01-17 21:24:12, John Villalovos wrote: > I have updated the bug with info I found out: > https://bugs.launchpad.net/oslo.serialization/+bug/1728368 > > Also I did a test patch with a proposed change: > https://review.openstack.org/#/c/535166/ > > This patch causes the unit tests to work. > > As a note there is a deprecation warning in the current code (without my > patch) that says in the future it will raise a ValueError() as can be seen > in a recently merged patch: > http://logs.openstack.org/72/533872/6/check/openstack-tox-py27/4709e32/job-output.txt.gz#_2018-01-16_13_10_38_931593 > > The test patch gets rid of that deprecation warning for the exceptions. > > Though I did see another warning about the "Response" object: > http://logs.openstack.org/66/535166/2/check/openstack-tox-py35/33d0827/job-output.txt.gz#_2018-01-18_05_13_52_603162 > > But that is for someone else to figure out :) > > > > On Wed, Jan 17, 2018 at 7:13 PM, ChangBo Guo wrote: > > > add Ironic team in the loop > > > > the revert patch got -1 from ironic folks , more details please see the > > comments in https://review.openstack.org/534736 > > The possible solution is to figure out why the change break Glance's unit > > test. which side should be fixed. > > > > > > > > 2018-01-17 20:14 GMT+08:00 ChangBo Guo : > > > >> I dig a little. It shows success when updating constraint to 2.21.2 [1] > >> but failure when updating constraint to 2.22.0 [2]. according to release > >> information [3]. > >> It means 2.21.1 works with glance test but 2.21.2 doesn't work well with > >> glance. The only issue patch is https://github.com/openstack/o > >> slo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8. > >> > >> > >> [1] https://review.openstack.org/514833 > >> [2] https://review.openstack.org/#/c/525136 > >> [3] https://github.com/openstack/releases/blob/master/deliverabl > >> es/queens/oslo.serialization.yaml > >> > >> > >> Actions: > >> > >> Block oslo.serialization version 2.21.2, 2.22.0, 2. 23.0in > >> https://review.openstack.org/534739 > >> Revert c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 in > >> https://review.openstack.org/534736 > >> > >> > >> > >> > >> 2018-01-16 23:35 GMT+08:00 Matthew Thode : > >> > >>> On 18-01-16 19:12:16, ChangBo Guo wrote: > >>> > What's the issue for Glance, any bug link ? > >>> > > >>> > 2018-01-16 0:12 GMT+08:00 Matthew Thode : > >>> > > >>> > > On 18-01-13 00:41:28, Matthew Thode wrote: > >>> > > > https://review.openstack.org/531788 is the review we are seeing > >>> it in, > >>> > > > but 2.22.0 failed as well. > >>> > > > > >>> > > > I'm guessing it was introduced in either > >>> > > > > >>> > > > https://github.com/openstack/oslo.serialization/commit/ > >>> > > c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 > >>> > > > or > >>> > > > https://github.com/openstack/oslo.serialization/commit/ > >>> > > cdb2f60d26e3b65b6370f87b2e9864045651c117 > >>> > > > >>> > > bamp > >>> > > > >>> > >>> The best bug for this is > >>> https://bugs.launchpad.net/oslo.serialization/+bug/1728368 and we are > >>> currently getting test fails in https://review.openstack.org/531788 > >>> Thanks for that, will keep an eye on it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [ptg] Dublin PTG proposed track schedule
On 18-01-18 11:20:21, Thierry Carrez wrote: > Hi everyone, > > Here is the proposed pre-allocated track schedule for the Dublin PTG: > > https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true > > You'll also notice that some teams (in orange below the table in above > link) do not have pre-allocated slots. One key difference this time > around is that we set aside a larger number of rooms and meeting spots > for dynamically scheduling tracks. The idea is to avoid pre-allocating > smaller tracks to a specific time slot that might or might not create > conflicts, and let that team book a space at a time that makes the most > sense for them, while the event happens. This dynamic booking will be > done through the PTGbot. > > So the unscheduled teams (in orange) are expected to take advantage of > this flexibility and schedule themselves during the event. This > flexibility is not limited to those orange teams: other teams may want > to meet for more than their pre-allocated time slots, and can book extra > space as well. For example if you are on the First Contact SIG and > realize on Tuesday afternoon that you would like to continue the > discussions on Friday morning, it's easy to extend your track to a time > slot there. > > Note that this system also replaces the old ethercalc-scheduled > "reservable rooms". If a group of people forms around a specific issue > and wants to discuss it, they can ask for their own additional "track" > and schedule it dynamically as well. > > Finally, you'll notice we have extra space set aside on Monday-Tuesday > to discuss "hot" last-minute cross-project issues -- if you have ideas > of topics that we need to discuss in-person, please let us know. > As one of the teams in orange, what specific steps, if any, do we need to take to schedule a specific time/place for a meeting? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [ALL][requirements] A freeze is coming and you should be prepared
Requirements is freezing Friday at 23:59:59 UTC so any last global-requrements updates that need to get in need to get in now. I'm afraid that my condition has left me cold to your pleas of mercy. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-23 01:23:50, Matthew Thode wrote: > Requirements is freezing Friday at 23:59:59 UTC so any last > global-requrements updates that need to get in need to get in now. > > I'm afraid that my condition has left me cold to your pleas of mercy. > Just your daily reminder that the freeze will happen in about 3 days time. Reviews seem to be winding down for requirements now (which is a good sign this release will be chilled to perfection). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-24 01:29:47, Matthew Thode wrote: > On 18-01-23 01:23:50, Matthew Thode wrote: > > Requirements is freezing Friday at 23:59:59 UTC so any last > > global-requrements updates that need to get in need to get in now. > > > > I'm afraid that my condition has left me cold to your pleas of mercy. > > > > Just your daily reminder that the freeze will happen in about 3 days > time. Reviews seem to be winding down for requirements now (which is > a good sign this release will be chilled to perfection). > There's still a couple of things that may cause bumps for iso8601 and oslo.versionedobjects but those are the main things. The msgpack change is also rolling out (thanks dirk :D). Even with all these changes though, in this universe, there's only one absolute. Everything freezes! https://review.openstack.org/535520 (oslo.serialization) -- Matthew Thode signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-24 22:32:27, Matthew Thode wrote: > On 18-01-24 01:29:47, Matthew Thode wrote: > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > global-requrements updates that need to get in need to get in now. > > > > > > I'm afraid that my condition has left me cold to your pleas of mercy. > > > > > > > Just your daily reminder that the freeze will happen in about 3 days > > time. Reviews seem to be winding down for requirements now (which is > > a good sign this release will be chilled to perfection). > > > > There's still a couple of things that may cause bumps for iso8601 and > oslo.versionedobjects but those are the main things. The msgpack change > is also rolling out (thanks dirk :D). Even with all these changes > though, in this universe, there's only one absolute. Everything freezes! > > https://review.openstack.org/535520 (oslo.serialization) > Last day, gate is sad and behind, but not my fault you waited til the last minute :P (see my first comment). The Iceman Cometh! -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [vitrage][glance][ironic] global requirements update for python-vitrageclient
On 18-01-26 10:47:38, Mark Goddard wrote: > Looks like this should be resolved by > https://review.openstack.org/#/c/537453/. > Mark > > On 26 January 2018 at 10:33, Mark Goddard wrote: > > > Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient > > 2.2.0. These are required in order to use the ironic node traits feature in > > nova. > > > > [1] https://review.openstack.org/#/c/538093 > > [2] https://review.openstack.org/#/c/538066/3 > > > > On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) < > > ifat.a...@nokia.com> wrote: > > > >> Adding Glance team. > >> Any idea what could be wrong? > >> > >> Thanks, > >> Ifat. > >> > >> > >> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" < > >> ifat.a...@nokia.com> wrote: > >> > >> Hi, > >> > >> I tried to update the version of python-vitrageclient [1], but the > >> legacy-requirements-integration-dsvm test failed with an error that does > >> not seem related to my changes: > >> > >> error: can't copy 'etc/glance-image-import.conf': doesn't exist or > >> not a regular file > >> > >> I noticed that two other changes [2][3] failed with the same error. > >> > >> Can you please help? > >> > >> Thanks, > >> Ifat. > >> > >> > >> [1] https://review.openstack.org/#/c/537307 > >> [2] https://review.openstack.org/#/c/535460/ > >> [3] https://review.openstack.org/#/c/536142/ yep, requirements is hard blocked on that atm -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-26 00:12:38, Matthew Thode wrote: > On 18-01-24 22:32:27, Matthew Thode wrote: > > On 18-01-24 01:29:47, Matthew Thode wrote: > > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > > global-requrements updates that need to get in need to get in now. > > > > > > > > I'm afraid that my condition has left me cold to your pleas of mercy. > > > > > > > > > > Just your daily reminder that the freeze will happen in about 3 days > > > time. Reviews seem to be winding down for requirements now (which is > > > a good sign this release will be chilled to perfection). > > > > > > > There's still a couple of things that may cause bumps for iso8601 and > > oslo.versionedobjects but those are the main things. The msgpack change > > is also rolling out (thanks dirk :D). Even with all these changes > > though, in this universe, there's only one absolute. Everything freezes! > > > > https://review.openstack.org/535520 (oslo.serialization) > > > > Last day, gate is sad and behind, but not my fault you waited til the > last minute :P (see my first comment). The Iceman Cometh! > All right everyone, Chill. Looks like we have another couple days to get stuff in for gate's slowness. The new deadline is 23:59:59 UTC 29-01-2018. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-26 23:05:11, Matthew Thode wrote: > On 18-01-26 00:12:38, Matthew Thode wrote: > > On 18-01-24 22:32:27, Matthew Thode wrote: > > > On 18-01-24 01:29:47, Matthew Thode wrote: > > > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > > > global-requrements updates that need to get in need to get in now. > > > > > > > > > > I'm afraid that my condition has left me cold to your pleas of mercy. > > > > > > > > > > > > > Just your daily reminder that the freeze will happen in about 3 days > > > > time. Reviews seem to be winding down for requirements now (which is > > > > a good sign this release will be chilled to perfection). > > > > > > > > > > There's still a couple of things that may cause bumps for iso8601 and > > > oslo.versionedobjects but those are the main things. The msgpack change > > > is also rolling out (thanks dirk :D). Even with all these changes > > > though, in this universe, there's only one absolute. Everything freezes! > > > > > > https://review.openstack.org/535520 (oslo.serialization) > > > > > > > Last day, gate is sad and behind, but not my fault you waited til the > > last minute :P (see my first comment). The Iceman Cometh! > > > > All right everyone, Chill. Looks like we have another couple days to > get stuff in for gate's slowness. The new deadline is 23:59:59 UTC > 29-01-2018. > It's a cold town. The current status is as follows. It looks like the gate is clearing up. oslo.versionedobjects-1.31.2 and iso8601 will be in a gr bump but that's it. monasca-tempest-plugin is not going to get in by freeze at this rate (has fixes needed in the review). There was some stuff needed to get nova-client/osc to work together again, but mriedem seems to have it in hand (and no gr updates it looks like). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-27 21:37:53, Matthew Thode wrote: > On 18-01-26 23:05:11, Matthew Thode wrote: > > On 18-01-26 00:12:38, Matthew Thode wrote: > > > On 18-01-24 22:32:27, Matthew Thode wrote: > > > > On 18-01-24 01:29:47, Matthew Thode wrote: > > > > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > > > > global-requrements updates that need to get in need to get in now. > > > > > > > > > > > > I'm afraid that my condition has left me cold to your pleas of > > > > > > mercy. > > > > > > > > > > > > > > > > Just your daily reminder that the freeze will happen in about 3 days > > > > > time. Reviews seem to be winding down for requirements now (which is > > > > > a good sign this release will be chilled to perfection). > > > > > > > > > > > > > There's still a couple of things that may cause bumps for iso8601 and > > > > oslo.versionedobjects but those are the main things. The msgpack change > > > > is also rolling out (thanks dirk :D). Even with all these changes > > > > though, in this universe, there's only one absolute. Everything freezes! > > > > > > > > https://review.openstack.org/535520 (oslo.serialization) > > > > > > > > > > Last day, gate is sad and behind, but not my fault you waited til the > > > last minute :P (see my first comment). The Iceman Cometh! > > > > > > > All right everyone, Chill. Looks like we have another couple days to > > get stuff in for gate's slowness. The new deadline is 23:59:59 UTC > > 29-01-2018. > > > > It's a cold town. The current status is as follows. It looks like the > gate is clearing up. oslo.versionedobjects-1.31.2 and iso8601 will be > in a gr bump but that's it. monasca-tempest-plugin is not going to get > in by freeze at this rate (has fixes needed in the review). There was > some stuff needed to get nova-client/osc to work together again, but > mriedem seems to have it in hand (and no gr updates it looks like). > Allow me to break the Ice. My name is Freeze. Learn it well for it's the chilling sound of your doom! Can you feel it coming? The icy cold of space! It's less than 24 hours til the freeze fomrally happens, the only outstanding item is that oslo.versionedobjects seems to need another fix for the iso8601 bump. osc-placement won't be added to requirements at this point as there has been no responce on their review. https://review.openstack.org/538515 python-vitrageclient looks like it'll make it in if gate doesn't break. msgpack may also be late, but we'll see (just workflow'd). openstacksdk may need a gr bump, I'm waiting on a response from mordred https://review.openstack.org/538695 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] A freeze is coming and you should be prepared
On 18-01-29 08:30:37, Sean McGinnis wrote: > > > > ... the > > only outstanding item is that oslo.versionedobjects seems to need > > another fix for the iso8601 bump. ... > > I took a look at the failing jobs for the oslo.versionobjects bump, and it > appears this is not directly related. > > There are failures in nova, cinder, and keystone with the new > oslo.versionedobjects. This appears to be due to a mix of UTC time handling in > these projects between their own local implementations and usage of the > timeutils inside oslo.versionedobjects. > > The right answer might be to get all of these local implementations moved out > into something like oslo.utils, but for the time being, these patches will > need > to land before we can raise oslo.versionedobjects (and raise the iso8601 > version that triggered this work). > > Cinder - https://review.openstack.org/#/c/536182/2 > Nova - https://review.openstack.org/#/c/535700/3 > Keystone - https://review.openstack.org/#/c/538263/1 > > There are similar patches in other projects (I think they are all using the > same topic) that will need to land as well that don't appear to be covered in > the requirements cross jobs. > Added them as depends-on to https://review.openstack.org/538549 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] Tonight Hell freezes over!
On 18-01-28 20:47:42, Matthew Thode wrote: > On 18-01-27 21:37:53, Matthew Thode wrote: > > On 18-01-26 23:05:11, Matthew Thode wrote: > > > On 18-01-26 00:12:38, Matthew Thode wrote: > > > > On 18-01-24 22:32:27, Matthew Thode wrote: > > > > > On 18-01-24 01:29:47, Matthew Thode wrote: > > > > > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > > > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > > > > > global-requrements updates that need to get in need to get in now. > > > > > > > > > > > > > > I'm afraid that my condition has left me cold to your pleas of > > > > > > > mercy. > > > > > > > > > > > > > > > > > > > Just your daily reminder that the freeze will happen in about 3 days > > > > > > time. Reviews seem to be winding down for requirements now (which > > > > > > is > > > > > > a good sign this release will be chilled to perfection). > > > > > > > > > > > > > > > > There's still a couple of things that may cause bumps for iso8601 and > > > > > oslo.versionedobjects but those are the main things. The msgpack > > > > > change > > > > > is also rolling out (thanks dirk :D). Even with all these changes > > > > > though, in this universe, there's only one absolute. Everything > > > > > freezes! > > > > > > > > > > https://review.openstack.org/535520 (oslo.serialization) > > > > > > > > > > > > > Last day, gate is sad and behind, but not my fault you waited til the > > > > last minute :P (see my first comment). The Iceman Cometh! > > > > > > > > > > All right everyone, Chill. Looks like we have another couple days to > > > get stuff in for gate's slowness. The new deadline is 23:59:59 UTC > > > 29-01-2018. > > > > > > > It's a cold town. The current status is as follows. It looks like the > > gate is clearing up. oslo.versionedobjects-1.31.2 and iso8601 will be > > in a gr bump but that's it. monasca-tempest-plugin is not going to get > > in by freeze at this rate (has fixes needed in the review). There was > > some stuff needed to get nova-client/osc to work together again, but > > mriedem seems to have it in hand (and no gr updates it looks like). > > > > Allow me to break the Ice. My name is Freeze. Learn it well for it's > the chilling sound of your doom! Can you feel it coming? The icy cold > of space! It's less than 24 hours til the freeze fomrally happens, the > only outstanding item is that oslo.versionedobjects seems to need > another fix for the iso8601 bump. osc-placement won't be added to > requirements at this point as there has been no responce on their > review. > > https://review.openstack.org/538515 > > python-vitrageclient looks like it'll make it in if gate doesn't break. > msgpack may also be late, but we'll see (just workflow'd). > openstacksdk may need a gr bump, I'm waiting on a response from mordred > > https://review.openstack.org/538695 > Tonight Hell freezes over! At just about 3 hours til your frozen doom I thought I'd send a final update. Since gate is still being slow the current plan is to stop accepting any new reviews to requirements (procedural -W) at the cutoff time. At that point we'll work on getting the existing approved items through gate, then work on branching. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] Prepare for a bitter harvest, winter has come at last!
On 18-01-29 14:44:20, Matthew Thode wrote: > On 18-01-28 20:47:42, Matthew Thode wrote: > > On 18-01-27 21:37:53, Matthew Thode wrote: > > > On 18-01-26 23:05:11, Matthew Thode wrote: > > > > On 18-01-26 00:12:38, Matthew Thode wrote: > > > > > On 18-01-24 22:32:27, Matthew Thode wrote: > > > > > > On 18-01-24 01:29:47, Matthew Thode wrote: > > > > > > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > > > > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > > > > > > global-requrements updates that need to get in need to get in > > > > > > > > now. > > > > > > > > > > > > > > > > I'm afraid that my condition has left me cold to your pleas of > > > > > > > > mercy. > > > > > > > > > > > > > > > > > > > > > > Just your daily reminder that the freeze will happen in about 3 > > > > > > > days > > > > > > > time. Reviews seem to be winding down for requirements now > > > > > > > (which is > > > > > > > a good sign this release will be chilled to perfection). > > > > > > > > > > > > > > > > > > > There's still a couple of things that may cause bumps for iso8601 > > > > > > and > > > > > > oslo.versionedobjects but those are the main things. The msgpack > > > > > > change > > > > > > is also rolling out (thanks dirk :D). Even with all these changes > > > > > > though, in this universe, there's only one absolute. Everything > > > > > > freezes! > > > > > > > > > > > > https://review.openstack.org/535520 (oslo.serialization) > > > > > > > > > > > > > > > > Last day, gate is sad and behind, but not my fault you waited til the > > > > > last minute :P (see my first comment). The Iceman Cometh! > > > > > > > > > > > > > All right everyone, Chill. Looks like we have another couple days to > > > > get stuff in for gate's slowness. The new deadline is 23:59:59 UTC > > > > 29-01-2018. > > > > > > > > > > It's a cold town. The current status is as follows. It looks like the > > > gate is clearing up. oslo.versionedobjects-1.31.2 and iso8601 will be > > > in a gr bump but that's it. monasca-tempest-plugin is not going to get > > > in by freeze at this rate (has fixes needed in the review). There was > > > some stuff needed to get nova-client/osc to work together again, but > > > mriedem seems to have it in hand (and no gr updates it looks like). > > > > > > > Allow me to break the Ice. My name is Freeze. Learn it well for it's > > the chilling sound of your doom! Can you feel it coming? The icy cold > > of space! It's less than 24 hours til the freeze fomrally happens, the > > only outstanding item is that oslo.versionedobjects seems to need > > another fix for the iso8601 bump. osc-placement won't be added to > > requirements at this point as there has been no responce on their > > review. > > > > https://review.openstack.org/538515 > > > > python-vitrageclient looks like it'll make it in if gate doesn't break. > > msgpack may also be late, but we'll see (just workflow'd). > > openstacksdk may need a gr bump, I'm waiting on a response from mordred > > > > https://review.openstack.org/538695 > > > > Tonight Hell freezes over! > > At just about 3 hours til your frozen doom I thought I'd send a final > update. Since gate is still being slow the current plan is to stop > accepting any new reviews to requirements (procedural -W) at the cutoff > time. At that point we'll work on getting the existing approved items > through gate, then work on branching. > requirements is now frozen, any review after 538994 will require a FFE. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements] cross project testing
One of the things that seems to happen now and then is that an update to requirements breaks gate for other projects in some way. One thing that helps is cross project testing, though we do that on a one off basis I'd like to see this testing become more codified. I have a review out that does a (very) hackish proof of concept, I've tested both functional and unit testing, both pass. https://review.openstack.org/#/c/345011/ (saved the functional testing, don't have the unit test link...) http://logs.openstack.org/11/345011/5/check/gate-requirements-pep8/5afcdf9/console.html So, my question to put to other projects is, which tests of yours do we hit when requirements break things for you. This list will hopefully be used to figure out what we can test our changes against to not cause the badness. Any notes on this would be appreciated :D -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] cross project testing
On 07/22/2016 10:54 PM, Matthew Thode wrote: > One of the things that seems to happen now and then is that an update to > requirements breaks gate for other projects in some way. One thing that > helps is cross project testing, though we do that on a one off basis I'd > like to see this testing become more codified. I have a review out that > does a (very) hackish proof of concept, I've tested both functional and > unit testing, both pass. > > https://review.openstack.org/#/c/345011/ > > (saved the functional testing, don't have the unit test link...) > http://logs.openstack.org/11/345011/5/check/gate-requirements-pep8/5afcdf9/console.html > > So, my question to put to other projects is, which tests of yours do we > hit when requirements break things for you. This list will hopefully be > used to figure out what we can test our changes against to not cause the > badness. > > Any notes on this would be appreciated :D > > > > __ > 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 > I forgot to mention, but thanks to Ian (sigmavirus) for pointing me to the script I modified for this (came from bandit). -- -- Matthew Thode (prometheanfire) __ 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] [ptl][requirements] nomination period started
We've started a period of self nomination in preparation for the requirements project fully moving into project (as it's still under Doug Hellmann). We are gathering the self nominations here before we vote next week. https://etherpad.openstack.org/p/requirements-ptl-newton Nominees should also send an email to the openstack-dev list. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [ptl][requirements] nomination period started
On 07/27/2016 08:41 AM, Matthew Thode wrote: > We've started a period of self nomination in preparation for the > requirements project fully moving into project (as it's still under Doug > Hellmann). > > We are gathering the self nominations here before we vote next week. > https://etherpad.openstack.org/p/requirements-ptl-newton > > Nominees should also send an email to the openstack-dev list. > And here's my self nomination email I originally joined as a packager as we use requirements for some dependency definitions. I have since moved on to work on making requirements changes verify changes against outside projects so as to not break things once merged (better testing). other than that, just keeping up on the queue :D If you have any questions or concerns feel free to ask. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [ptl][requirements] nomination period started
On 07/27/2016 09:07 AM, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2016-07-27 08:41:17 -0500: >> We've started a period of self nomination in preparation for the >> requirements project fully moving into project (as it's still under Doug >> Hellmann). >> >> We are gathering the self nominations here before we vote next week. >> https://etherpad.openstack.org/p/requirements-ptl-newton >> >> Nominees should also send an email to the openstack-dev list. >> > > Thanks for kicking this off, Matt! I'm looking forward to seeing this > team fully self-sufficient. > > From the etherpad, I see a deadline set of August 5. Is that for > nominations, or the election to have an outcome? > > For the record, Anita has agreed to be the primary election official, > and I will assist her. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > That's for the self nomination period. Immediately after that is when the election would be, we may vote in the meeting that day for just one of us to be put forward or do a normal election, I don't think we've clarified that yet. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [ptl][requirements] nomination period started
On 07/27/2016 04:08 PM, Jeremy Stanley wrote: > On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote: >> We've started a period of self nomination in preparation for the >> requirements project fully moving into project (as it's still under Doug >> Hellmann). >> >> We are gathering the self nominations here before we vote next week. >> https://etherpad.openstack.org/p/requirements-ptl-newton >> >> Nominees should also send an email to the openstack-dev list. > > Have you determined whether your electorate are traditional project > technical contributors (Gerrit owners of changes merged to the > openstack/requirements repo over the past year) like most teams use, > or is there a different focus and constituency for this team? > We have talked about it somewhat, but just assumed it'd be those that have submitted (and had merge) changes. Doug's suggestion to include the current 'wip' core team might be good, I know at least Tony and I didn't know for sure if we'd be disqualified or not. The term 'interim' for ptl I think is just because elections are coming up soon. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Why do we need a Requirements Team and PTL
On 08/06/2016 09:34 AM, Davanum Srinivas wrote: > Folks, > > Question asked by Julien here: > https://twitter.com/juldanjou/status/761897228596350976 > > Answer: > There's a boat load of work that goes on in global requirements > process. Here's the list of things that we dropped on the new team > being formed: > https://etherpad.openstack.org/p/requirements-tasks > > Please feel free to look at the requirements repo, weekly chats etc to > get an idea. > > Also if if you disagree, please bring it up in a community forum so > you get better answers for your concerns. > > Thanks, > Dims > To add, that list has been cleaned up since we first started, so there was more on it then just that. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] History lesson please
On 08/09/2016 09:25 AM, Ian Cordasco wrote: > > > -Original Message- > From: Sean Dague > Reply: OpenStack Development Mailing List (not for usage questions) > > Date: August 9, 2016 at 05:44:55 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [requirements] History lesson please > >> On 08/09/2016 02:38 AM, Tony Breeds wrote: >>> Hi all, >>> I guess this is aimed at the long term requirements team members. >>> >>> The current policy for approving requirements[1] bumps contains the >>> following text: >>> >>> Changes to update the minimum version of a library developed by the >>> OpenStack community can be approved by one reviewer, as long as the >>> constraints are correct and the tests pass. >>> >>> Perhaps I'm a little risk adverse but this seems a little strange to me. Can >>> folks that know more about how this came about help me understand why that >>> is? >>> >>> Yours Tony. >>> >>> [1] >>> https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions >>> >> >> With constraints, the requirements minimum bump is pretty low risk. Very >> little of our jobs are impacted by it. >> >> It's in many ways more risking to leave minimums where they are and bump >> constraints, because the minimums could be lying that they still work at >> the lower level. >> >> -Sean > > I maintain a few libraries outside of OpenStack that have generous lower > limits and testing them is resource intensive both as a developer and in > continuous integration. I'd love to see OpenStack be *more* aggressive about > the oldest version it supports because in most cases I severely distrust the > version ranges we use. I do recognize, however, that we have to coordinate > with some distributions that will not update their packaged versions (which > are often an old version number with security patches poorly cherry-picked). > So you may need to coordinate with them before bumping version minimums as > well. > > -- > Ian Cordasco > > > __ > 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 > One of the things on our todo list is to test the 'lower-constraints' to make sure they still work with the head of branch. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] History lesson please
On 08/09/2016 10:22 AM, Ian Cordasco wrote: > -Original Message- > From: Matthew Thode > Reply: prometheanf...@gentoo.org , OpenStack > Development Mailing List (not for usage questions) > > Date: August 9, 2016 at 09:53:53 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [requirements] History lesson please > >> One of the things on our todo list is to test the 'lower-constraints' to >> make sure they still work with the head of branch. > > That's not sufficient. You need to find versions in between the lowest tested > version and the current version to also make sure you don't end up with > breakage. You might have somepackage that has a lower version of 2.0.1 and a > current constraint of 2.12.3. You might even have a blacklist of versions in > between those two versions, but you still need other versions to ensure that > things in between those continue to work. > > THe tiniest of accidental incompatibilities can cause some of the most > bizarre bugs. > > -- > Ian Cordasco > I'm aware of this, but this would be a good start. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] History lesson please
On 08/09/2016 01:37 PM, John Dickinson wrote: > In that case, they are still co-installable, because the nova minimum > satisfies both. The requirements project currently advocates the use of upper-requirements.txt as what is targeted for packagers. This is what's tested. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] History lesson please
On 08/10/2016 07:30 AM, Ian Cordasco wrote: > To be clear, I think the requirements work Tony is doing has the potential to > make things worse for some subset of deployers/operators. > > -- > Ian Cordasco Any change we make has the potential to make things worse for some subset :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Why module has been deleted even if it is consumed by the project?
On 08/12/2016 09:53 AM, Andrey Pavlov wrote: > Thanks for the answer, > > I don't know why - but requirements job is not in the list of jobs. It > present only in comment from jenkins. > Logs are here > - > http://logs.openstack.org/67/354667/1/check/gate-ec2-api-requirements/4e9e1da/ > > And I would like to include ec2api project > to openstack/requirements/projects.txt > Is it possible? Ya, you can you'll first need to add the check-requirements job to your list of test in project-config. Once it's added there we can add your project to projects.txt The relevant section of the readme is here. https://github.com/openstack/requirements/#enforcement-in-projects -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Why module has been deleted even if it is consumed by the project?
On 08/12/2016 01:47 PM, Andrey Pavlov wrote: > ec2-api (and gce-api) already has this job, so I just add them to > projects.txt, right? > > https://review.openstack.org/#/c/354899/ yep, looks good, +2 -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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][infra] Binary Package Dependencies - not only for Python
On 08/16/2016 05:38 PM, Brant Knudson wrote: > s bindep.txt meant to be used by anything other than OpenStack CI? (As > in, are packagers going to rely on it?) > > In keystone's bindep.txt, we have packages listed like: > > |libldap2-dev [platform:dpkg] | > > > -> Which is only needed if you install with keystone[ldap] (see > keystone's setup.cfg[1]). > > | > | > > | > > |libsqlite3-dev [platform:dpkg] | > > > -> Which is only needed for unit tests. > > .. and maybe others that aren't needed in all deployments. > > So there's a use case for a) integrating with extras, and b) a > "test-bindep.txt". > > Maybe this is supported already or is known work to do, or maybe > somebody's looking for something to work on. > > [1] http://git.openstack.org/cgit/openstack/keystone/tree/setup.cfg#n28 > | > > -- > - Brant I look at it (as a packager), though it is somewhat dubious as to whether or not what's there is actually needed. Having test-bindep.txt like we have test-requirements would be helpful. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] mod_wsgi: what services are people using with it?
On 08/17/2016 03:22 PM, Nick Papadonis wrote: > Hi Folks, > > I was hacking in this area on Mitaka and enabled Glance, Cinder, Heat, > Swift, Ironic, Horizon and Keystone under Apache mod_wsgi instead of the > Eventlet server.Cinder, Keystone, Heat and Ironic provide Python > source in Github to easily enable this. It appears that Glance and > Swift (despite the existence of > https://github.com/openstack/swift/blob/2bf5eb775fe3ad6d3a2afddfc7572318e85d10be/doc/source/apache_deployment_guide.rst) > provide no such Python source to call from the Apache conf file. > > That said, is anyone using Glance, Swift, Neutron or Nova (marked > experimental) in production environments with mod_wsgi? I had to put > together code to launch a subset of these which does not appear > integrated in Github. Appreciate your insight. > > Thanks, > Nick > > > __ > 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 > This might be better for the ops list, so cc'd them. I don't use apache / mod_wsgi, but I do use uwsgi with cinder, horizon, keystone, neutron and nova. At the moment it's just glance that's not using it, but there was a bug iirc with how it interacted with uwsgi. I should look into it again. I even made a blog post about it a while back. https://mthode.org/posts/2016/Mar/of-openstack-and-uwsgi/ -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] mod_wsgi: what services are people using with it?
On 08/17/2016 03:52 PM, Nick Papadonis wrote: > Comments > > > Thanks for the quick response! > > Glance worked for me in Mitaka. I had to specify 'chunked transfers' > and increase the size limit to 5GB. I had to pull some of the WSGI > source from glance and alter it slightly to call from Apache. > > I saw that Nova claims mod_wsgi is 'experimental'. Interested in it's > really experimental or folks use it in production. > > Nick ya, cinder is experimental too (at least in my usage) as I'm using python3 as well :D For me it's a case of having to test the packages I build. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Let's drop the postgresql gate job
On 08/18/2016 10:00 AM, Matt Riedemann wrote: > It's that time of year again to talk about killing this job, at least > from the integrated gate (move it to experimental for people that care > about postgresql, or make it gating on a smaller subset of projects like > oslo.db). > > The postgresql job used to have three interesting things about it: > > 1. It ran keystone with eventlet (which is no longer a thing). > 2. It runs the n-api-meta service rather than using config drive. > 3. It uses postgresql for the database. > > So #1 is gone, and for #3, according to the April 2016 user survey (page > 40) [1], 4% of reporting deployments are using it in production. > > I don't think we're running n-api-meta in any other integrated gate > jobs, but I'm pretty sure there is at least one neutron job out there > that's running with it that way. We could also consider making the > nova-net dsvm full gate job run n-api-meta, or vice-versa with the > neutron dsvm full gate job. > > We also have to consider that with HP public cloud being gone as a node > provider and we've got fewer test nodes to run with, we have to make > tough decisions about which jobs we're going to run in the integrated gate. > > I'm bringing this up again because Nova has a few more jobs it would > like to make voting on it's repo (neutron LB and live migration, at > least in the check queue) but there are concerns about adding yet more > jobs that each change has to get through before it's merged, which means > if anything goes wrong in any of those we can have a 24 hour turnaround > on getting an approved change back through the gate. > > [1] > https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf > I don't know about nova, but at least in keystone when I was testing upgrades I found an error that had to be fixed before release of Mitaka. Guess I'm part of the 4% :( -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] mod_wsgi: what services are people using with it?
On 08/17/2016 03:52 PM, Nick Papadonis wrote: > Comments > > > Glance worked for me in Mitaka. I had to specify 'chunked transfers' > and increase the size limit to 5GB. I had to pull some of the WSGI > source from glance and alter it slightly to call from Apache. > > I saw that Nova claims mod_wsgi is 'experimental'. Interested in it's > really experimental or folks use it in production. > > Nick I haven't found any docs on getting mod_wsgi working for glance do you happen to have a link? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Let's drop the postgresql gate job
On 08/18/2016 10:00 AM, Matt Riedemann wrote: > It's that time of year again to talk about killing this job, at least > from the integrated gate (move it to experimental for people that care > about postgresql, or make it gating on a smaller subset of projects like > oslo.db). > > The postgresql job used to have three interesting things about it: > > 1. It ran keystone with eventlet (which is no longer a thing). > 2. It runs the n-api-meta service rather than using config drive. > 3. It uses postgresql for the database. > > So #1 is gone, and for #3, according to the April 2016 user survey (page > 40) [1], 4% of reporting deployments are using it in production. > > I don't think we're running n-api-meta in any other integrated gate > jobs, but I'm pretty sure there is at least one neutron job out there > that's running with it that way. We could also consider making the > nova-net dsvm full gate job run n-api-meta, or vice-versa with the > neutron dsvm full gate job. > > We also have to consider that with HP public cloud being gone as a node > provider and we've got fewer test nodes to run with, we have to make > tough decisions about which jobs we're going to run in the integrated gate. > > I'm bringing this up again because Nova has a few more jobs it would > like to make voting on it's repo (neutron LB and live migration, at > least in the check queue) but there are concerns about adding yet more > jobs that each change has to get through before it's merged, which means > if anything goes wrong in any of those we can have a 24 hour turnaround > on getting an approved change back through the gate. > > [1] > https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf > Perhaps a better option would be to get oslo.db to run cross-project checks like we do in requirements. That way the right team is covering the usage of postgres and we still have coverage while still lowering gate load for most projects. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] Let's drop the postgresql gate job
On 08/18/2016 01:50 PM, Matt Riedemann wrote: > On 8/18/2016 1:18 PM, Matthew Thode wrote: >> Perhaps a better option would be to get oslo.db to run cross-project >> checks like we do in requirements. That way the right team is covering >> the usage of postgres and we still have coverage while still lowering >> gate load for most projects. >> >> >> >> __ >> >> 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 >> > > I don't see the value in this unless there are projects that have > pg-specific code in them. The reason we have cross-project unit test > jobs for reqs changes is requirements changes in upper-constraints can > break and wedge the gate for a project, or multiple project. E.g. > removing something in a backward incompatible way, or the project with > the unit test is mocking something out poorly (like we've seen lately > with nova and python-neutronclient releases). > That makes sense, just improving the oslo.db test coverage for postgres (if that's even necessary) would be good. The only other thing I'd like to see (and it may already be done) is to have pg upgrade test coverage, aka, I don't want to hit that keystone bug again :P But that's a different conversation. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [telemetry] Oslo.db 4.13.1 broke Gnocchi
On 09/02/2016 03:43 AM, Julien Danjou wrote: > On Fri, Sep 02 2016, Julien Danjou wrote: > >> I'll look into fixing that, though any help would be welcome. > > My attempt at: > https://review.openstack.org/364767 > > > > __ > 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 > Sucks this was broken but let us (requirements) know when it's released so we can make a feature freeze exception (and email the list with [requirements][FFE] in the title). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [requirements][FFE] global-requirements update to positional to 1.1.1
https://review.openstack.org/366631 The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the current minimum requirement) results in various unit test failures in barbican, related to parsing of request headers in generated contexts for unit testing. Updating to 1.1.1 resolves this issue. This is specifically affecting barbican and RDO testing (from discussion and the review). The reason I think an FFE is needed is because downstream packagers, while encouraged to package based on upper-constraints sometimes don't. Meaning they'd miss something like this. Arguments against are that this will have knock on effects down the line (will require re-releases and re-re-releases because of updating things like keystone (this is deep in the depgraph)), so is bad from a release team work point of view. Also, I think this just effects testing, so the impact of this is more minor than something more serious (not JUST breaking testing). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2
https://review.openstack.org/366298 This is just a bump to upper-constraints so is more minor to get testing working and fix the bug that occurred in Gnocchi (and possibly others). We are able to mask the 'bad' versions of oslo.db and unmask pymysql 0.7.7 after the freeze (and backport them to stable/newton) so this is easier to merge. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2
On 09/07/2016 08:58 AM, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500: >> https://review.openstack.org/366298 >> >> This is just a bump to upper-constraints so is more minor to get testing >> working and fix the bug that occurred in Gnocchi (and possibly others). >> >> We are able to mask the 'bad' versions of oslo.db and unmask pymysql >> 0.7.7 after the freeze (and backport them to stable/newton) so this is >> easier to merge. >> > > If we have a known-bad version of the library, maybe it would be better > to incorporate that info into the global-requirements list before we > branch the requirements repository? I'm not sure what we've done in > this case for past cycles. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Are you fine with the knock on effects that a gr update would cause? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2
On 09/07/2016 07:44 PM, Joshua Harlow wrote: > >> >> Gnocchi is a service. It's not in the pip requirements list for >> ceilometer, so releasing a new version of oslo.db and having that >> trigger a new release of gnocchi won't also trigger a new release >> of ceilometer to update its dependency list. >> >> The service projects are not yet at their RC1 point, so haven't been >> branched. Neither has the requirements list. If blocking the "bad" >> version of oslo.db doesn't trigger a cascade of new library releases, we >> should do it before we tag RC1 and branch the requirements list so that >> we don't have to try to backport the block into newton. >> > > So just to aid this along, wanted to check what was the recommended > procedure here. https://review.openstack.org/#/c/366362/ is the final > fix for this (I hope). > > I'm guessing (but would like input before doing much here) we need that > backported to stable/newton and getting out 4.13.3 > > Does that sound about right to folks, or was the desire to block pymysql > (which I believe is fixed by now?) and then just block the bad oslo.db > release (4.13.2) and continue with the release train as is. > > Want to make sure I pick the right path here ;) > > -Josh > > __ > 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 I think the backport/release and mask of the bad oslo.db should be enough. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2
On 09/08/2016 03:59 AM, Ihar Hrachyshka wrote: > I backported the fix to stable/newton: > https://review.openstack.org/#/c/367221/ > > Once it’s in, we’ll trigger another oslo.db release. > > As for the blocking patch for requirements: > https://review.openstack.org/#/c/365565/, I disagree that we should > block oslo.db 4.13.0, because atm pymysql 0.7.7 is blocked in > global-requirements.txt: > > https://github.com/openstack/requirements/blob/4ace2473e4b2eaa283864d74d241c9705f23dd91/global-requirements.txt#L163 > > > and hence there is no known issue with oslo.db 4.13.0 release. I know > there is a patch that unblocks the pymysql release on review: > https://review.openstack.org/#/c/364541/ but it’s not merged right now, > so I don’t see a reason to include block for oslo.db 4.13.0 now. If > anything, it’s that latter patch that should include it. > > The thing is, there is nothing wrong about oslo.db 4.13.0 comparing to > any previous release: all of them are broken with pymysql 0.7.7. If we > are to unblock pymysql 0.7.7 now, we should as well block all previous > releases of oslo.db, meaning bumping the minimal supported version from > 4.10.0+ to 4.13.3+ (when the later is even released; we are still at the > stage of backport). > > Ihar > Ya that makes sense, the patch can be altered to just block 4.13.1,2 (assuming 4.13.3 really does fix it) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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][FFE] pymod2pkg 0.5.4
On 09/09/2016 05:26 AM, Dirk Müller wrote: > Hi, > > OpenStack RPM Packaging would like to update to pymod2pkg 0.5.4: > > https://review.openstack.org/#/c/367388/ > > this package is only used by packaging (renderspec and rpm-packaging > git repos) that are on a release-independent schedule (iirc we're > tagged as never-release) and > since we're packaging, we needed to wait until all the deps we depend > on were released to finalize packaging and include the needed fixes. > > it is bugfix only with no effect whatsoever on any of the OpenStack > Newton deliverables as far as I can say. > > Please approve, > > Thanks, > Dirk > > __ > 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 > I don't think this will impact and cause a rerelease for any project so I'm fine with this. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton
On 09/09/2016 02:29 PM, Pradeep Kilambi wrote: > Hi, > > This is FFE request to get ceilometerclient 2.6.1 into upper > constraints. There is already a patch for this blocked by freeze[1]. > > ceilometerclient 2.6.1 was cut 3 days after the freeze looks like and it > includes various critical fixes such as[2]. Without this aodh logs fill > up with following errors[3] and alarm creation fails. > > Please consider approving this for newton asap. > > Thanks, > > ~ Prad > > [1] https://review.openstack.org/#/c/367386/ > [2] https://review.openstack.org/#/c/366638/ > [3] > http://logs.openstack.org/96/366896/4/check/gate-tripleo-ci-centos-7-scenario001-multinode-nv/97ed4b4/logs/subnode-2/var/log/aodh/evaluator.txt.gz#_2016-09-09_13_05_23_261 > > > __ > 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 > Does this mean that the minimum (GR needs raising as well)? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton
On 09/09/2016 04:24 PM, gordon chung wrote: > > > On 09/09/16 03:45 PM, Matthew Thode wrote: >> Does this mean that the minimum (GR needs raising as well)? > > iiuc, just the max or upper-constraints. > > cheers, > k, I already +2'd it as I think this is fine, waiting on glorious leader (tonyb) to +2+W it. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [FFE] two xstatic packages to be bumped in upper-constraints, please
On 09/12/2016 07:39 PM, Richard Jones wrote: > Hi folks, > > We have two patches to upper-constraints up that we'd like to see merged > for Newton. The package updates in question only changed meta-data, but > they did so in a way that fixes issues for downstream, and it makes > sense to keep upper-constraints in line with what they'll be packaging. > > The reviews are: > > update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1 > https://review.openstack.org/#/c/368970/ > > update constraint for XStatic-smart-table to new release 1.4.13.2 > https://review.openstack.org/#/c/366194/ > > > Thanks, > > Richard > > > > __ > 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 > Both of these are bumps to upper-constraints, which is good. Also, I don't see a problem with downstream projects (as found via codesearch). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [requirement][cyborg]FFE - pyspdk requirement dependency
On 18-01-30 11:58:17, Thierry Carrez wrote: > We We wrote: > > The pyspdk is a important tool library [1] which supports Cyborg SPDK > > driver [2] to manage the backend SPDK-base app, so we need to upload > > pyspdk into the pypi [3] and then append 'pyspdk>=0.0.1’ item into > > ‘OpenStack/Cyborg/requirements.txt’ , so that SPDK driver can be built > > correctly when zuul runs. However, It's not what we thought it would be, > > if we want to add the new requirements, we should get support from > > upstream OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item. > > Before we talk FFE, pyspdk looks a bit far away from being something > OpenStack code can depend on. In particular: > > - it's not clearly licensed under a supported license (no LICENSE file > in the source code) > - Missing metadata entries in setup.cfg means we are missing a lot of > context information about this library > > Those need to be fixed before we can even consider adding this library > to global requirements... > I agree. Also, there's no mention of python3 or testing in the repo. The licence looks like gplv3, which is fine for non-openstack code. There's also no commit since the initial commit. Unless I'm looking at the wrong repo, I'm going to say no to this FFE. https://github.com/lschw/pyspdf -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][Blazar] FFE - add python-blazarclient in global-requirements
On 18-01-30 17:03:58, Masahito MUROI wrote: > Hi requirements team, > > This is a FFE request for adding python-blazarclient to > global-requirements.txt. Blazar team had release problems for updating the > blazarclient to pypo. > > Luckily, the problems are fixed and the client is published at pypi this > morning. > > 1. https://review.openstack.org/#/c/539126/ > LGTM, +2 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirement][cyborg]FFE - pyspdk requirement dependency
On 18-01-31 10:15:12, Thierry Carrez wrote: > Doug Hellmann wrote: > > Excerpts from We We's message of 2018-01-31 01:54:04 +0800: > >>> Hi, > >> > >>> I have modified and resubmitted pyspdk to the pypi. Please check it. > >> > >>> Thx, > >> > >>> Helloway > > > > Is there a public source repository for the library somewhere? > > Looks like it lives at: > https://github.com/hellowaywewe/py-spdk > > Since the primary objections are not really due to the FFE state but > more due to the nature of the library, this should probably first be > proposed as a change to openstack/requirements and discussed there... > > When it's ready but blocked by FF we can return to a ML thread to > discuss it... > Thanks for the link, and yes should probably just be discussed in a review. Missing a setup.py/cfg and license and testing all make it seem like a no-go though. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements][ptl] Announcing my candidacy for PTL of the requirements project
I would like to announce my candidacy for PTL of the Requirements project for the Rocky cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. 2. Speaking of global-requirements updates, the primary goal this cycle will continue to work on project specific requirements. All projects would continue to use upper-constraints.txt to ensure co-installability, but would be able to manage their requirements.txt file, largely on their own. https://bugs.launchpad.net/openstack-requirements/+bug/1719009 is the bug tracking per-project requirements. 3. Un-cap requirements where possible (stuff like eventlet). 4. Publish constraints and requirements to streamline the freeze process. https://bugs.launchpad.net/openstack-requirements/+bug/1719006 is the bug tracking the publish job. 5. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 6. Audit global-requirements minimums. While technically not supported from a co-installability or stability standpoint (as it's not tested), we should endeavor to have the global-requirements minimums work in Openstack. Ensuring any bugs, features or changes that have happened since the global-requirements minimum was released til the upper-constraints was defined are not NEEDED by Openstack. This will rely on the cross gating work tonyb did. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, Matthew Thode IRC: prometheanfire -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] FFE for delayed libraries
On 18-02-01 13:44:19, Sean McGinnis wrote: > Due to gate issues and other delays, there's quite a handful of libs that were > not released in time for the requirements freeze. > > We now believe we've gotten all libraries processed for the final Queens > releases. In order to reduce the load, we have batches all upper constraints > bumps for these libs into one patch: > > https://review.openstack.org/#/c/540105/ > > This is my official FFE request to have these updates accepted yet for Queens > past the requirements freeze. > > If anyone is aware of any issues with these, please bring that to our > attention > as soon as possible. > > Thanks, > Sean > > > Affected Updates > > > update constraint for python-saharaclient to new release 1.5.0 > update constraint for instack-undercloud to new release 8.2.0 > update constraint for paunch to new release 2.2.0 > update constraint for python-mistralclient to new release 3.2.0 > update constraint for python-senlinclient to new release 1.7.0 > update constraint for pycadf to new release 2.7.0 > update constraint for os-refresh-config to new release 8.2.0 > update constraint for tripleo-common to new release 8.4.0 > update constraint for reno to new release 2.7.0 > update constraint for os-net-config to new release 8.2.0 > update constraint for os-apply-config to new release 8.2.0 > update constraint for os-client-config to new release 1.29.0 > update constraint for ldappool to new release 2.2.0 > update constraint for aodhclient to new release 1.0.0 > update constraint for python-searchlightclient to new release 1.3.0 > update constraint for mistral-lib to new release 0.4.0 > update constraint for os-collect-config to new release 8.2.0 > update constraint for ceilometermiddleware to new release 1.2.0 > update constraint for tricircleclient to new release 0.3.0 > update constraint for requestsexceptions to new release 1.4.0 > update constraint for python-magnumclient to new release 2.8.0 > update constraint for tosca-parser to new release 0.9.0 > update constraint for python-tackerclient to new release 0.11.0 > update constraint for python-heatclient to new release 1.14.0 > officially accepted, thanks for keeping me updated while this was going on. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements][FFE] Release ovsdbapp 0.9.1
On 18-02-02 15:59:42, Terry Wilson wrote: > ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a > gate-fixing one-line fix (https://review.openstack.org/#/c/537241). > Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once > the package is built? > Is this just for upper-constraints.txt or for global-requirements.txt as well? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements][FFE] Release ovsdbapp 0.9.1
On 18-02-02 18:02:38, Terry Wilson wrote: > On Fri, Feb 2, 2018 at 4:30 PM, Matthew Thode > wrote: > > On 18-02-02 15:59:42, Terry Wilson wrote: > >> ovsdbapp 0.9.1 (review https://review.openstack.org/#/c/539489/) has a > >> gate-fixing one-line fix (https://review.openstack.org/#/c/537241). > >> Can I get a FFE for bumping the requirements to ovsdbapp 0.9.1 once > >> the package is built? > >> > > > > Is this just for upper-constraints.txt or for global-requirements.txt as > > well? > > A global-requirements.txt probably makes more sense since 0.9.0 > introduced the issue. I don't see any reason why someone would want to > install it over 0.9.1. It's literally a one-line difference between > the two. > It doesn't look like there are any re-releases that'd occur because of this, so you have my signoff. http://codesearch.openstack.org/?q=ovsdbapp&i=nope&files=.*requirements.*&repos= -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [sdk][release][requirements] FFE request for openstacksdk 0.11.3
On 18-02-04 09:32:25, Monty Taylor wrote: > Hi! > > I'd like to request another FFE to fix several neutron commands in > python-openstackclient for queens and also to unbreak > python-openstackclient's gate. > > The release proposal patch is here: > > https://review.openstack.org/540657 > > The issue at hand was: > > The osc-functional-devstack-tips job, which tests master changes of > openstackclient and openstacksdk against each other with > openstackclient's functional tests was broken and was not testing > master against master but rather master of openstackclient against > released version of SDK. Therefore, the gate that was protecting us > against breakages like these was incorrect and let us land a patch that made > invalid query parameters raise errors instead of silently not filtering - > without also adding missing but needed query parameters as valid. > > The gate job has been fixed and SDK as of the proposed commit fixes the > osc-functional-devstack-tips job. That can be seen in > https://review.openstack.org/540554/ The osc-functional-devstack job, which > checks OSC master against released SDK is broken with sdk 0.11.2 because of > the bug fixed in the SDK patch. > > We would want to bump the upper-constraints from 0.11.2 to 0.11.3 in both > stable/queens and master upper-constraints files. > As a UC bump you have my +2 It seems like these things require a gr bump even more now, which would cause client re-releases iirc. My question has more to do with having this not happen again. Do you cross gate with other projects (clients)? That would allow you to check what's going into your master with what's in the client master to ensure no breakage. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][release] FFE for sushy bug-fix release
On 18-02-05 15:15:18, Dmitry Tantsur wrote: > Hi all, > > I'm requesting an exception to proceed with the release of the sushy > library. To my best knowledge, the library is only consumed by ironic and at > least one other vendor support library which is outside of the official > governance. The release request is [1]. It addresses a last minute bug in > the authentication code, without it authentication will not work in some > cases. > > Thanks, > Dmitry > > [1] https://review.openstack.org/540824 > > P.S. > We really need a feature freeze period for libraries to avoid this.. But it > cannot be introduced with the current library release freeze. Another PTG > topic? :) > As discussed on IRC you have my ack -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][release] FFE for constraints update for python-tackerclient bug-fix release
On 18-02-07 23:01:25, Yongsheng Gong wrote: > Hi, > > The tacker client has na initial queens release which does not have right > reno notes. Recently I have added some reno patches. > And also the team wants a feature to land in the queens release. > > I have requested the newer release at > https://review.openstack.org/#/c/541638/ > <https://review.openstack.org/#/c/541638/> > > The new feature is at https://review.openstack.org/#/c/541631/ > <https://review.openstack.org/#/c/541631/> > > Please see how we can get it released? > It should have time to get in for the freeze, the question I have is 'What in openstack is broken if we update upper-contraints after the freeze instead of before?' A follow up question is 'does this need a global-requirements.txt bump?' +2 from me on the UC bump though -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers] Hel
Hi all, it looks like some of your projects may need to cut a queens branch/release. Is there anything we can do to move it along? The following is the list I'm working off of (will be updated as projects release) https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f As of right now it's as follows. # Projects without team or release model could not be found in openstack/releases for queens openstack/almanach openstack/compute-hyperv openstack/ekko openstack/gce-api openstack/glare openstack/ironic-staging-drivers openstack/kosmos openstack/mixmatch openstack/mogan openstack/nemesis openstack/networking-dpm openstack/networking-l2gw openstack/networking-powervm openstack/nova-dpm openstack/nova-lxd openstack/nova-powervm openstack/os-xenapi openstack/python-cratonclient openstack/python-glareclient openstack/python-kingbirdclient openstack/python-moganclient openstack/python-oneviewclient openstack/python-valenceclient openstack/swauth openstack/tap-as-a-service openstack/trio2o openstack/valence openstack/vmware-nsx openstack/vmware-nsxlib # Projects missing a release/branch for queens openstackclientOpenStackClient anchor Security ec2-apiec2-api django_openstack_auth horizon horizon-cisco-ui horizon bifrostironic ironic-python-agent-builderironic magnum magnum magnum-ui magnum manila-image-elements manila masakari masakari masakari-monitors masakari python-masakariclient masakari os-service-types shade tacker tacker # I think this one is released tacker-horizon tacker # but not this one # Repos with type: horizon-plugin (typically release a little later) manila-ui manila neutron-vpnaas-dashboard neutron senlin-dashboard senlin solum-dashboardsolum watcher-dashboard watcher # Repos with type: other heat-agentsheat ironic-python-agentironic kuryr-kubernetes kuryr neutron-vpnaas neutron networking-hyperv winstackers # Repos with type: service ironic ironic swift swift tricircle tricircle vitragevitrage watcherwatcher -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [heat][horizon][ironic][neutron][swift][tricircle][vitrage][watcher] Help needed for your release
On 18-02-07 16:33:52, Luke Hinds wrote: > On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode > wrote: > > > Hi all, > > > > it looks like some of your projects may need to cut a queens > > branch/release. Is there anything we can do to move it along? > > > > The following is the list I'm working off of (will be updated as > > projects release) > > https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f > > > > As of right now it's as follows. > > > From what I know anchor (security) has no maintainers / cores now, so I > guess it would make sense to perhaps archive (I will follow this through > outside this thread), so for now there is no need to tag a queens branch / > release. Ya, a bunch of those are maintainerless, the ones of primary concern are those managed by ironic, swift, tricircle, vitrage, watcher, heat and neutron -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [ptg] Track around release cycle, consumption models and stable branches
On 18-02-07 12:42:05, Thierry Carrez wrote: > Hi everyone, > > I was wondering if anyone would be interested in brainstorming the > question of how to better align our release cycle and stable branch > maintenance with the OpenStack downstream consumption models. That > includes discussing the place of the distributions, the need for LTS, > and where does the open source upstream project stop. > > I have hesitated to propose it earlier, as it sounds like a topic that > should be discussed with the wider community at the Forum. And it will, > but it feels like this needs a deeper pre-discussion in a productive > setting, and tonyb and eumel8 have been proposing that topic on the > missing topics etherpad[1], so we might as well take some time at the > PTG to cover that. > > Would anyone be interested in such a discussion ? It would be scheduled > on the Tuesday. How much time would we need ? I was thinking we could > use only Tuesday afternoon. > > [1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics > I'll make myself available with both my requirements and distro packaging hats. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]
On 18-02-08 00:08:40, Ivan Kolodyazhny wrote: > Hi Matt, > > As discussed earlier today at the Horizon's meeting [2], we're not going to > release horizon-cisco-ui and django_openstack_auth because of projects > retirement [3] and [4]. > > > [2] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-02- > 07-20.02.html > [3] https://review.openstack.org/#/c/541803/ > [4] > http://lists.openstack.org/pipermail/openstack-dev/2018-January/126428.html > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Wed, Feb 7, 2018 at 11:31 PM, Tony Breeds > wrote: > > > On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote: > > > > > Okay It's safe to ignore then ;P We should probably remove it from > > > projects.txt if it really is empty I'll propose that. > > > > Oh my bad, ironic-python-agent-builder was included as it's included as > > an ironic project[1] NOT because it;s listed in projects.txt. Given > > that it's clearly not for me to remove anything. > > > > Having said that if the project hasn't had any updates at all since it's > > creation in July 2017 perhaps it's no longer needed and could be > > removed? > > > > Yours Tony. > > > > [1] http://git.openstack.org/cgit/openstack/governance/tree/ > > reference/projects.yaml#n1539 > > > > __ > > 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 > > > > Yep, already removing horizon-cisco-ui from requirements. (since infra jumped the gun on us :P ) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements][monasca] FFE request for monasca-common
On 18-02-08 14:41:21, Dirk Müller wrote: > 2018-02-08 11:05 GMT+01:00 Bedyk, Witold : > > > I would like to request FFE for monasca-common to be bumped in upper > > constraints. The version has been bumped together with the rest of Monasca > > components [1]. Monasca-common is used only in Monasca projects [2]. > > The changes between 2.7.0 and 2.8.0 are: > > +2.8.0 > +- > + > +* Enable tempest tests as voting > +* Add messages for testing unicode > +* Zuul: Remove project name > +* Remove not used mox library > +* Updated from global requirements > +* Updated from global requirements > > > The requirements changes are removal of mox, and fix for oslotest to > sync the queens level requirements. so this looks good to me. +1 > Yep, LGTM as well (just approved) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [PTL][SIG][PTG]Team Photos
On 18-02-08 10:00:58, Michael Johnson wrote: > Hi Kendall, > > Can you put Octavia down for 2:10 on Thursday after neutron? > Thanks, > Michael > > > On Wed, Feb 7, 2018 at 9:15 PM, Kendall Nelson wrote: > > Hello PTLs and SIG Chairs! > > > > So here's the deal, we have 50 spots that are first come, first served. We > > have slots available before and after lunch both Tuesday and Thursday. > > > > The google sheet here[1] should be set up so you have access to edit, but if > > you can't for some reason just reply directly to me and I can add your team > > to the list (I need team/sig name and contact email). > > > > I will be locking the google sheet on Monday February 26th so I need to know > > if your team is interested by then. > > > > See you soon! > > > > - Kendall Nelson (diablo_rojo) > > > > [1] > > https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing > > And Requirements after that (at 2:20 Thursday) -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements] more help needed
The following do not have a stable/queens branch and could cause requirements to remain frozen until they do. If I get no response by tomorrow afternoon my time (about 24 horus from the time this email was SENT) I may still move to unfreeze requirements. [tricircle] tricircle [heat] heat-agents There are other projects needing a stable/queens branch as well, but those are the main two. Below you'll find all the non-cycle-trailing projects that do requirements syncs without stable/queens branches. Projects without team or release model could not be found in openstack/releases for queens openstack/almanach openstack/compute-hyperv openstack/ekko openstack/gce-api openstack/glare openstack/ironic-staging-drivers openstack/kosmos openstack/mixmatch openstack/mogan openstack/nemesis openstack/networking-dpm openstack/networking-hpe openstack/networking-l2gw openstack/nova-dpm openstack/nova-lxd openstack/os-xenapi openstack/python-glareclient openstack/python-kingbirdclient openstack/python-moganclient openstack/python-oneviewclient openstack/python-valenceclient openstack/swauth openstack/tap-as-a-service openstack/trio2o openstack/valence openstack/vmware-nsx openstack/vmware-nsxlib openstackclientOpenStackClient os-service-types OpenStackSDK anchor Security ec2-apiec2-api magnum-ui magnum manila-image-elements manila masakari masakari masakari-monitors masakari python-masakariclient masakari tacker tacker tacker-horizon tacker Repos with type: horizon-plugin blazar-dashboard blazar heat-dashboard heat manila-ui manila senlin-dashboard senlin solum-dashboardsolum Repos with type: other heat-agentsheat networking-hyperv winstackers Repos with type: service tricircle tricircle -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][tricircle][heat] more help needed
On 18-02-08 15:20:54, Matthew Thode wrote: > The following do not have a stable/queens branch and could cause > requirements to remain frozen until they do. If I get no response by > tomorrow afternoon my time (about 24 horus from the time this email was > SENT) I may still move to unfreeze requirements. > > [tricircle] > tricircle > > [heat] > heat-agents > > There are other projects needing a stable/queens branch as well, but > those are the main two. Below you'll find all the non-cycle-trailing > projects that do requirements syncs without stable/queens branches. > > > Projects without team or release model could not be found in > openstack/releases for queens > openstack/almanach > openstack/compute-hyperv > openstack/ekko > openstack/gce-api > openstack/glare > openstack/ironic-staging-drivers > openstack/kosmos > openstack/mixmatch > openstack/mogan > openstack/nemesis > openstack/networking-dpm > openstack/networking-hpe > openstack/networking-l2gw > openstack/nova-dpm > openstack/nova-lxd > openstack/os-xenapi > openstack/python-glareclient > openstack/python-kingbirdclient > openstack/python-moganclient > openstack/python-oneviewclient > openstack/python-valenceclient > openstack/swauth > openstack/tap-as-a-service > openstack/trio2o > openstack/valence > openstack/vmware-nsx > openstack/vmware-nsxlib > openstackclientOpenStackClient > os-service-types OpenStackSDK > anchor Security > ec2-apiec2-api > magnum-ui magnum > manila-image-elements manila > masakari masakari > masakari-monitors masakari > python-masakariclient masakari > tacker tacker > tacker-horizon tacker > > Repos with type: horizon-plugin > blazar-dashboard blazar > heat-dashboard heat > manila-ui manila > senlin-dashboard senlin > solum-dashboardsolum > > Repos with type: other > heat-agents heat > networking-hyperv winstackers > > Repos with type: service > tricircle tricircle > adding tags... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements][kolla][openstack-ansible][puppet][tripleo] requirements unfreeze and you, how you should handle it
As the title states, cycle trailing projects will need to change their requirements update behavior until they create stable/queens branches. When requirements unfreezes we will be doing rocky work, meaning that requirements updates to your projects (our master to your master) will be for rocky. I requests that all the projects tagged in the email's subject get a +1 from a requirements core before merging until they branch stable/queens. Once they branch stable/queens the projects are free to proceed as normal. If the projects tagged in the subject can ack me (email or irc) I'd appreciate it, would give us some peace of mind to unfreeze tomorrow. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]
On 18-02-09 17:21:26, Sam P wrote: > Hi Matthew, > > Thanks for the info. > For Masakari, after discussing with release team, all following 3 project > will do independent > release for Queens. > masakari masakari > > masakari-monitorsmasakari > python-masakariclient masakari > > Still need 3-4 days to create stable/queens for masakari and > masakari-monitors > and python-masakariclinet can be done late today. > I will create stable/queens as soon as we merged the required patches. > Requirement update will unfreeze soon, and we will hold the requirement > updates till we create stable/queens. > > > --- Regards, > Sampath > > > On Thu, Feb 8, 2018 at 7:33 PM, Dmitry Tantsur wrote: > > > On 02/07/2018 10:31 PM, Tony Breeds wrote: > > > >> On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote: > >> > >> Okay It's safe to ignore then ;P We should probably remove it from > >>> projects.txt if it really is empty I'll propose that. > >>> > >> > >> Oh my bad, ironic-python-agent-builder was included as it's included as > >> an ironic project[1] NOT because it;s listed in projects.txt. Given > >> that it's clearly not for me to remove anything. > >> > >> Having said that if the project hasn't had any updates at all since it's > >> creation in July 2017 perhaps it's no longer needed and could be > >> removed? > >> > > > > We do plan to use it, we just never had time to populate it :( > > > > > >> Yours Tony. > >> > >> [1] http://git.openstack.org/cgit/openstack/governance/tree/refe > >> rence/projects.yaml#n1539 > >> Sounds good, thanks for the update. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [heat][tacker][murano][RelMgmt] heat-translator deliverable type?
On 18-02-09 10:10:10, Sean McGinnis wrote: > Hello Heat team, > > The release team just recently noticed the heat-translator deliverable is > marked as a type of "other" and is following the release-model of > "cycle-with-intermediary". > > It appears this is actually a library though. It's hard to tell, but it is > either a client lib or non-client lib. In either case, we need to mark it as > such and treat its release according to that type. > > In order to stabilize requirements changes, we have two separate deadlines, > first for non-client libs, then a week later for client libs. Since > heat-translator appears to be a dependency used by other projects, it will > need > to be subject to those release deadlines. > > Can the team clarify what type of library this is, and change the type going > forward to accurately reflect that? > > Please let the release team know if there are any questions. > I think tacker and murano may be using it in a non-intended way (those are the only projects I could find that's using it). https://github.com/openstack/tacker/search?utf8=%E2%9C%93&q=translator&type= https://github.com/openstack/murano/search?utf8=%E2%9C%93&q=translator&type= -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements] we are now unfrozen and branched
This means we are back to business as usual. cycle trailing projects have been warned not to merge requirements updates until they branch or get an ack from a requirements core. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] we are now unfrozen and branched
On 18-02-12 16:13:30, William M Edmonds wrote: > I'm not seeing a stable/queens branch for openstack/requirements yet. Is > that not what you meant? When is that projected? > > Matthew Thode wrote on 02/12/2018 11:25:44 AM: > > This means we are back to business as usual. > > > > cycle trailing projects have been warned not to merge requirements > > updates until they branch or get an ack from a requirements core. > > It's done now, gate problems delayed it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [mistral][release][ffe] Requesting FFE for supporting source execution id in the Mistral client
On 18-02-14 17:03:10, Renat Akhmerov wrote: > Hi, > > We were asked to do a FFE request to be able to release a new version of > Mistral client out of stable/queens branch. > > The backport patch: https://review.openstack.org/#/c/543393/ > The release patch: https://review.openstack.org/#/c/543402 > > The reason to do that after the feature freeze is that we didn’t backport > (and release) this patch by mistake (simply missed it) whereas the > corresponding functionality was already included on the server side and went > to Queens-3 and subsequent releases. > > From my side I can assure that the change is backwards compatible and very > much wanted in stable/queens by many users. > > Hence we’re kindly asking to approve the release patch. > FFE approved from the requirements side. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements][trove][tatu][barbican][compass][daisycloud][freezer][fuel][nova][openstack-ansible][pyghmi][solum] Migration from pycrypto
Development has stalled, (since 2014). It's been forked but now would be a good time to move to a more actively maintained crypto library like cryptography. Requirements wishes to drop pycrypto. Let me know if there's anything we can do to facilitate this. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][trove][tatu][barbican][compass][daisycloud][freezer][fuel][nova][openstack-ansible][pyghmi][solum] Migration from pycrypto
On 18-02-14 13:55:53, Sean McGinnis wrote: > On Wed, Feb 14, 2018 at 10:09:47AM -0600, Matthew Thode wrote: > > Development has stalled, (since 2014). It's been forked but now would > > be a good time to move to a more actively maintained crypto library like > > cryptography. > > > > Requirements wishes to drop pycrypto. Let me know if there's anything > > we can do to facilitate this. > > > > -- > > Matthew Thode (prometheanfire) > > We did have a discussion on the ML, and I think a little at one of the PTGs, > about the path forward for this. IIRC, there was one other potential supported > package that was considered for an option, but we settled on cryptography as > the recommended path forward to get off of pycrypto. I think it had to do with > ease of being able to just drop in the new package with minimal affected code. > Yep, I remember it, I'm not mentioning it because I'd like to focus on moving to cryptography rather than move to the fork. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [FFE][requirements][release][oslo] osprofiler bug fix needed
On 18-02-12 02:14:51, Nguyễn Trọng Vĩnh (Tovin Seven) wrote: > Hello, > > Currently, Oslo release for Queens is out. > However, OSProfiler faces an issue that make some Nova CLI command not > working. > Detail for this issue: https://launchpad.net/bugs/1743586 > > Patch that fix this bug: https://review.openstack.org/#/c/535219/ > Back port for this: https://review.openstack.org/#/c/537735/ > Release new version for OSProfiler with this bug fix in Queens: > https://review.openstack.org/#/c/541645/ > > Therefore, I send this email to get a FFE for it. > Requirements is fine with this, sorry for the delay. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] Debian OpenStack packages switching to Py3 for Queens
On 18-02-15 09:31:19, Thomas Goirand wrote: > Hi, > > Since I'm getting some pressure from other DDs to actively remove Py2 > support from my packages, I'm very much considering switching all of the > Debian packages for Queens to using exclusively Py3. I would have like > to read some opinions about this. Is it a good time for such move? I > hope it is, because I'd like to maintain as few Python package with Py2 > support at the time of Debian Buster freeze. > > Also, doing Queens, I've noticed that os-xenapi is still full of py2 > only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch: > > https://review.openstack.org/544809 > Gentoo has Openstack packaged for both python2.7 and python3.(5,6) for pike. Queens will be the same for us at least, but I haven't had problems with at least the core services running them all through python3.x. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][release] FFE for tooz 1.60.0
On 18-02-15 15:13:59, Dirk Müller wrote: > Hi, > > I would like to ask for a exception to add tooz 1.60.0 to > stable/queens. As part of the msgpack-python -> msgpack switch over we > converted all > dependencies, but the tooz release did not include the dependency > switch (not sure why, the branch point was just before the fix). > > As it is a one liner dependency change and it brings everything in > stable/queens in a consistent state related to the dependencies (and > for > those who try to package openstack msgpack and msgpack-python do > file-conflict so can not be coinstalled) I would like to ask for a > FFE. > +2+W from requirements -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] Debian OpenStack packages switching to Py3 for Queens
On 18-02-15 13:38:45, Matthew Thode wrote: > On 18-02-15 09:31:19, Thomas Goirand wrote: > > Hi, > > > > Since I'm getting some pressure from other DDs to actively remove Py2 > > support from my packages, I'm very much considering switching all of the > > Debian packages for Queens to using exclusively Py3. I would have like > > to read some opinions about this. Is it a good time for such move? I > > hope it is, because I'd like to maintain as few Python package with Py2 > > support at the time of Debian Buster freeze. > > > > Also, doing Queens, I've noticed that os-xenapi is still full of py2 > > only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch: > > > > https://review.openstack.org/544809 > > > > Gentoo has Openstack packaged for both python2.7 and python3.(5,6) for > pike. Queens will be the same for us at least, but I haven't had > problems with at least the core services running them all through > python3.x. > Edit: Everything BUT swift... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements][puppet] upper-constraints is now un-frozen
With the release of Queens, master upper-constraints is now unlocked. The only projects that should be concerned about this are cycle trailing jobs that have not branched. The only project I'm aware of that has not branched is [puppet]. So just be aware that we are going to start moving on to rocky. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] Let's switch from pyldap to python-ldap >= 3
On 18-03-03 18:44:59, Thomas Goirand wrote: > Hi, > > Pyldap started as a fork of python-ldap. But recently, its features were > merged into the python-ldap python module >= 3, and pyldap is now > deprecated. Let's switch to python-ldap >= 3, and remove pyldap from > requirements. > > This has already been done in Debian. The python-ldap source package now > carries a python-pyldap transition package, which installs python-ldap. > > What's the procedure? Should I first send a patch to the global-reqs > repo first? > I think we should do it like this. 1. add python-ldap-3.x to requirements (though it looks like that's still a beta 2. move existing pyldap to python-ldap 3. remove pyldap -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] [requirements][zun] update websocket-client and kubernetes libraries
Requirements plans to update both versions, removing the current cap on websocket-cient. The plan to do so is as follows. a. Remove the cap on websocket-client b. merge the gr-update into python-zunclient c. make release of python-zunclient d. Alter the constrained versions of websocket-client and kubernetes - to be co-installable with openstack libs (python-zunclient) e. Raise the minimum acceptable version for kubernetes raise the minimum version of websocket-client - raise to above the versions kubernetes had problems with -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] a plan to stop syncing requirements into projects
On 18-03-15 09:45:38, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2018-03-15 14:34:50 +0100: > > Doug Hellmann wrote: > > > [...] > > > TL;DR > > > - > > > > > > Let's stop copying exact dependency specifications into all our > > > projects to allow them to reflect the actual versions of things > > > they depend on. The constraints system in pip makes this change > > > safe. We still need to maintain some level of compatibility, so the > > > existing requirements-check job (run for changes to requirements.txt > > > within each repo) will change a bit rather than going away completely. > > > We can enable unit test jobs to verify the lower constraint settings > > > at the same time that we're doing the other work. > > > > Thanks for the very detailed plan, Doug. It all makes sense to me, > > although I have a precision question (see below). > > > > > [...] > > >We also need to change requirements-check to look at the exclusions > > >to ensure they all appear in the global-requirements.txt list > > >(the local list needs to be a subset of the global list, but > > >does not have to match it exactly). We can't have one project > > >excluding a version that others do not, because we could then > > >end up with a conflict with the upper constraints list that could > > >wedge the gate as we had happen in the past. > > > [...] > > > 2. We should stop syncing dependencies by turning off the > > >propose-update-requirements job entirely. > > > > > >Turning off the job will stop the bot from proposing more > > >dependency updates to projects. > > > [...] > > > After these 3 steps are done, the requirements team will continue > > > to maintain the global-requirements.txt and upper-constraints.txt > > > files, as before. Adding a new dependency to a project will still > > > involve a review step to add it to the global list so we can monitor > > > licensing, duplication, python 3 support, etc. But adjusting the > > > version numbers once that dependency is in the global list will be > > > easier. > > > > How would you set up an exclusion in that new world order ? We used to > > add it to the global-requirements file and the bot would automatically > > sync it to various consuming projects. > > > > Now since any exclusion needs to also appear on the global file, you > > would push it first in the global-requirements, then to the project > > itself, is that correct ? In the end the global-requirements file would > > only contain those exclusions, right ? > > > > The first step would need to be adding it to the global-requirements.txt > list. After that, it would depend on how picky we want to be. If the > upper-constraints.txt list is successfully updated to avoid the release, > we might not need anything in the project. If the project wants to > provide detailed guidance about compatibility, then they could add the > exclusion. For example, if a version of oslo.config breaks cinder but > not nova, we might only put the exclusion in global-requirements.txt and > the requirements.txt for cinder. > I wonder if we'd be able to have projects decide via a flag in their tox or zuul config if they'd like to opt into auto-updating exclusions only. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] a plan to stop syncing requirements into projects
s to change the >minimum version of a dependency within a project. > >Maintaining a global list of minimums also implies that we >consider it OK to run OpenStack as a whole with that list. This >message conflicts with the message we've been sending about the >upper constraints list since that was established, which is that >we have a known good list of versions and deploying all of >OpenStack with different versions of those dependencies is >untested. > As noted above I think that gathering the min versions/maskings from openstack projects to be valuable (especially to packagers who already use our likely invalid values already). > After these 3 steps are done, the requirements team will continue > to maintain the global-requirements.txt and upper-constraints.txt > files, as before. Adding a new dependency to a project will still > involve a review step to add it to the global list so we can monitor > licensing, duplication, python 3 support, etc. But adjusting the > version numbers once that dependency is in the global list will be > easier. > Thanks for writing this up, I think it looks good in general, but like you mentioned before, there is some discussion to be had about gathering and creating a versionspec from all of openstack for requirements. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][requirements] a plan to stop syncing requirements into projects
change would immediately allow all projects currently > > >following the global requirements lists to specify different > > >lower bounds from that global list, as long as those lower bounds > > >still allow the dependencies to be co-installable. (The upper > > >bounds, managed through the upper-constraints.txt list, would > > >still be built by selecting the newest compatible version because > > >that is how pip's dependency resolver works.) > > > > > > 2. We should stop syncing dependencies by turning off the > > >propose-update-requirements job entirely. > > > > > >Turning off the job will stop the bot from proposing more > > >dependency updates to projects. > > > > > >As part of deleting the job we can also remove the "requirements" > > >case from playbooks/proposal/propose_update.sh, since it won't > > >need that logic any more. We can also remove the update-requirements > > >command from the openstack/requirements repository, since that > > >is the tool that generates the updated list and it won't be > > >needed if we aren't proposing updates any more. > > > > > > 3. Remove the minimum specifications from the global requirements > > >list to make clear that the global list is no longer expressing > > >minimums. > > > > > >This clean-up step has been a bit more controversial among the > > >requirements team, but I think it is a key piece. As the minimum > > >versions of dependencies diverge within projects, there will no > > >longer *be* a real global set of minimum values. Tracking a list of > > >"highest minimums", would either require rebuilding the list from the > > >settings in all projects, or requiring two patches to change the > > >minimum version of a dependency within a project. > > > > > >Maintaining a global list of minimums also implies that we > > >consider it OK to run OpenStack as a whole with that list. This > > >message conflicts with the message we've been sending about the > > >upper constraints list since that was established, which is that > > >we have a known good list of versions and deploying all of > > >OpenStack with different versions of those dependencies is > > >untested. > > > > > > > As noted above I think that gathering the min versions/maskings from > > openstack projects to be valuable (especially to packagers who already > > use our likely invalid values already). > > OK. I don't feel that strongly about the cleanup work, so if we want to > keep the lower bounds in place I think that's OK. > > > > > > After these 3 steps are done, the requirements team will continue > > > to maintain the global-requirements.txt and upper-constraints.txt > > > files, as before. Adding a new dependency to a project will still > > > involve a review step to add it to the global list so we can monitor > > > licensing, duplication, python 3 support, etc. But adjusting the > > > version numbers once that dependency is in the global list will be > > > easier. > > > > > > > Thanks for writing this up, I think it looks good in general, but like > > you mentioned before, there is some discussion to be had about gathering > > and creating a versionspec from all of openstack for requirements. > > > -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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
