Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Nov 7, 2018 at 11:12 AM Clark Boylan  wrote:

> On Wed, Nov 7, 2018, at 4:47 AM, Mohammed Naser wrote:
> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann 
> wrote:
> > >
> > > Corey Bryant  writes:
> > >
> > > > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant <
> corey.bry...@canonical.com>
> > > > wrote:
> > > >
> > > > I'd like to start moving forward with enabling py37 unit tests for a
> subset
> > > > of projects. Rather than putting too much load on infra by enabling
> 3 x py3
> > > > unit tests for every project, this would just focus on enablement of
> py37
> > > > unit tests for a subset of projects in the Stein cycle. And just to
> be
> > > > clear, I would not be disabling any unit tests (such as py35). I'd
> just be
> > > > enabling py37 unit tests.
> > > >
> > > > As some background, this ML thread originally led to updating the
> > > > python3-first governance goal (
> https://review.openstack.org/#/c/610708/)
> > > > but has now led back to this ML thread for a +1 rather than updating
> the
> > > > governance goal.
> > > >
> > > > I'd like to get an official +1 here on the ML from parties such as
> the TC
> > > > and infra in particular but anyone else's input would be welcomed
> too.
> > > > Obviously individual projects would have the right to reject proposed
> > > > changes that enable py37 unit tests. Hopefully they wouldn't, of
> course,
> > > > but they could individually vote that way.
> > > >
> > > > Thanks,
> > > > Corey
> > >
> > > This seems like a good way to start. It lets us make incremental
> > > progress while we take the time to think about the python version
> > > management question more broadly. We can come back to the other
> projects
> > > to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
> >
> > What's the impact on the number of consumption in upstream CI node usage?
> >
>
> For period from 2018-10-25 15:16:32,079 to 2018-11-07 15:59:04,994,
> openstack-tox-py35 jobs in aggregate represent 0.73% of our total capacity
> usage.
>
> I don't expect py37 to significantly deviate from that. Again the major
> resource consumption is dominated by a small number of projects/repos/jobs.
> Generally testing outside of that bubble doesn't represent a significant
> resource cost.
>
> I see no problem with adding python 3.7 unit testing from an
> infrastructure perspective.
>
> Clark
>
>
>
Thanks all for the input on this. It seems like we have no objections to
moving forward so I'll plan on getting started soon.

Thanks,
Corey
__
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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
wrote:

> Hi All,
>
> I'd like to enable py37 unit tests in the gate.
>
> == Background ==
>
> I work on OpenStack packaging for Ubuntu. During the Rocky release (Ubuntu
> Cosmic) I tried to fix py37 bugs upstream as I came across them. There
> ended up being a lot of py37 issues and after a while, due to time
> constraints, I resorted to just opening bugs and disabling py37 unit tests
> that were failing in our package builds. Luckily enough, even though Cosmic
> ships with python3.6 and python3.7, python3.6 ended up being chosen as the
> default for Cosmic.
>
> == Defaulting to python3.7 ==
>
> The next release of Ubuntu opens in just a few weeks. It will default to
> python3.7 and will not include python3.6. My hope is that if I can help
> enable py37 unit tests upstream now, we can get a wider view at fixing
> issues soon.
>
> == Enabling py37 unit tests ==
>
> Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews up
> to define the py37 zuul job and templates here:
> https://review.openstack.org/#/c/609066
>
> I'd like to start submitting reviews to projects to enable
> openstack-python37-jobs (or variant) for projects that already have
> openstack-python36-jobs in their .zuul.yaml, zuul.yaml,
> .zuul.d/project.yaml.
>
> == Coinciding work ==
>
> There is python3-first work going on now and I completely understand that
> this is going to cause more work for some projects. It seems that now is as
> good of a time as ever to catch up and test with a recent python3 version.
> I'm sure python3.8 and beyond will be here before we know it.
>
> Any thoughts or concerns?
>
> Thanks,
> Corey
>

I'd like to start moving forward with enabling py37 unit tests for a subset
of projects. Rather than putting too much load on infra by enabling 3 x py3
unit tests for every project, this would just focus on enablement of py37
unit tests for a subset of projects in the Stein cycle. And just to be
clear, I would not be disabling any unit tests (such as py35). I'd just be
enabling py37 unit tests.

As some background, this ML thread originally led to updating the
python3-first governance goal (https://review.openstack.org/#/c/610708/)
but has now led back to this ML thread for a +1 rather than updating the
governance goal.

I'd like to get an official +1 here on the ML from parties such as the TC
and infra in particular but anyone else's input would be welcomed too.
Obviously individual projects would have the right to reject proposed
changes that enable py37 unit tests. Hopefully they wouldn't, of course,
but they could individually vote that way.

Thanks,
Corey
__
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] Proposal for a process to keep up with Python releases

[Corey Bryant]

On Fri, Oct 19, 2018 at 3:46 PM Zane Bitter  wrote:

> On 19/10/18 12:30 PM, Clark Boylan wrote:
> > On Fri, Oct 19, 2018, at 8:17 AM, Zane Bitter wrote:
> >> Unit Tests
> >> --
> >>
> >> For unit tests, the most important thing is to test on the versions of
> >> Python we target. It's less important to be using the exact distro that
> >> we want to target, because unit tests generally won't interact with
> >> stuff outside of Python.
> >>
> >> I'd like to propose that we handle this by setting up a unit test
> >> template in openstack-zuul-jobs for each release. So for Stein we'd have
> >> openstack-python3-stein-jobs. This template would contain:
> >
> > Because zuul config is branch specific we could set up every project to
> use a `openstack-python3-jobs` template then define that template
> differently on each branch. This would mean you only have to update the
> location where the template is defined and not need to update every other
> project after cutting a stable branch. I would suggest we take advantage of
> that to reduce churn.
>
> There was a reason I didn't propose that approach: in practice you can't
> add a new gating test to a centralised zuul template definition. If you
> do, many projects will break because the change is not self-testing. At
> best you'll be pitchforked by an angry mob of people who can't get
> anything but py37 fixes through the gate, and at worst they'll all stop
> using the template to get unblocked and then never go back to it.
>
> We don't need everyone to cut over at the same time. We just need them
> to do it in the space of one release cycle. One patch every 6 months is
> not an excessive amount of churn.
>
> >> * A voting gate job for the highest minor version of py3 we want to
> >> support in that release.
> >> * A voting gate job for the lowest minor version of py3 we want to
> >> support in that release.
> >> * A periodic job for any interim minor releases.
> >> * (Starting late in the cycle) a non-voting check job for the highest
> >> minor version of py3 we want to support in the *next* release (if
> >> different), on the master branch only.
> >>
> >> So, for example, (and this is still under active debate) for Stein we
> >> might have gating jobs for py35 and py37, with a periodic job for py36.
> >> The T jobs might only have voting py36 and py37 jobs, but late in the T
> >> cycle we might add a non-voting py38 job on master so that people who
> >> haven't switched to the U template yet can see what, if anything,
> >> they'll need to fix.
> >>
> >> We'll run the unit tests on any distro we can find that supports the
> >> version of Python we want. It could be a non-LTS Ubuntu, Fedora, Debian
> >> unstable, whatever it takes. We won't wait for an LTS Ubuntu to have a
> >> particular Python version before trying to test it.
> >>
> >> Before the start of each cycle, the TC would determine which range of
> >> versions we want to support, on the basis of the latest one we can find
> >> in any distro and the earliest one we're likely to need in one of the
> >> supported Linux distros. There will be a project-wide goal to switch the
> >> testing template from e.g. openstack-python3-stein-jobs to
> >> openstack-python3-treasure-jobs for every repo before the end of the
> >> cycle. We'll have goal champions as usual following up and helping teams
> >> with the process. We'll know where the problem areas are because we'll
> >> have added non-voting jobs for any new Python versions to the previous
> >> release's template.
> >
> > I don't know that this needs to be a project wide goal if you can just
> update the template on the master branch where the template is defined. Do
> that then every project is now running with the up to date version of the
> template. We should probably advertise when this is happening with some
> links to python version x.y breakages/features, but the process itself
> should be quick.
>
> Either way, it'll be project teams themselves fixing any broken tests
> due to a new version being added. So we can either have a formal
> project-wide goal where we project-manage that process across the space
> of a release, or a de-facto project-wide goal where we break everybody
> and then nothing gets merged until they fix it.
>
> > As for python version range selection I worry that that the criteria
> about relies on too much guesswork.
>
> Some guesswork is going to be inevitable, unfortunately, (we have no way
> of knowing what will be in CentOS 8, for example) but I agree that we
> should try to tighten up the criteria as much as possible.
>
> > I do think we should do our best to test future incoming versions of
> python even while not officially supporting them. We will have to support
> them at some point, either directly or via some later version that includes
> the changes from that intermediate version.
>
> +1, I think we should try to add support for higher versions as soon as
> possible. It may take a long time to get into an 

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 17, 2018 at 3:43 PM William M Edmonds 
wrote:

>
> Corey Bryant  wrote on 10/15/2018 05:34:24 PM:
> ...
> > From an ubuntu perspective, ubuntu is going to support stein on 18.
> > 04 LTS (3.6) and 19.04 (3.7) only.
> ...
>
> So folks with Ubuntu 16.04 LTS compute nodes will have to upgrade them all
> to 18.04 before upgrading to Stein? Of course this would be a distro
> statement,and would not preclude someone from building their own
> environment from source/pypi on Ubuntu 16.04. And 16.04 is still pretty
> heavily used, right?
>
> All true statements, and the answers to your questions is yes.

> Ubuntu 18.04 LTS is not supported on PowerVM compute nodes, so the PowerVM
> CI will not be able to switch to running under py3 if code that doesn't
> work in py35 is introduced. At least until RHEL 8 comes out, at which point
> we could switch to using that in our CI. But please don't allow such
> changes before the RHEL 8 release.
>
This sounds like an orthogonal problem but maybe I'm confused.

Corey

>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Tue, Oct 16, 2018 at 10:58 AM Zane Bitter  wrote:

> On 15/10/18 8:00 PM, Monty Taylor wrote:
> > On 10/15/2018 06:39 PM, Zane Bitter wrote:
> >>
> >> In fact, as far as we know the version we have to support in CentOS
> >> may actually be 3.5, which seems like a good reason to keep it working
> >> for long enough that we can find out for sure one way or the other.
> >
> > I certainly hope this is not what ends up happening, but seeing as how I
> > actually do not know - I agree, I cannot discount the possibility that
> > such a thing would happen.
>
> I'm right there with ya.
>
> > That said - until such a time as we get to actually drop python2, I
> > don't see it as an actual issue. The reason being - if we test with 2.7
> > and 3.7 - the things in 3.6 that would break 3.5 get gated by the
> > existence of 2.7 for our codebase.
> >
> > Case in point- the instant 3.6 is our min, I'm going to start replacing
> > every instance of:
> >
> >"foo {bar}".format(bar=bar)
> >
> > in any code I spend time in with:
> >
> >f"foo {bar}"
> >
> > It TOTALLY won't parse on 3.5 ... but it also won't parse on 2.7.
> >
> > If we decide as a community to shift our testing of python3 to be 3.6 -
> > or even 3.7 - as long as we still are testing 2.7, I'd argue we're
> > adequately covered for 3.5.
>
> Yeah, that is a good point. There are only a couple of edge-case
> scenarios where that might not prove to be the case. One is where we
> install a different (or a different version of a) 3rd-party library on
> py2 vs. py3. The other would be where you have some code like:
>
>if six.PY3:
>   some_std_lib_function_added_in_3_6()
>else:
>   py2_code()
>
> It may well be that we can say this is niche enough that we don't care.
>
> In theory the same thing could happen between versions of python3 (e.g.
> if we only tested on 3.5 & 3.7, and not 3.6). There certainly exist
> places where we check the minor version.* However, that's so much less
> likely again that it definitely seems negligible.
>
> * e.g.
>
> https://git.openstack.org/cgit/openstack/oslo.service/tree/oslo_service/service.py#n207
>
> > The day we decide we can drop 2.7 - if we've been testing 3.7 for
> > python3 and it turns out RHEL/CentOS 8 ship with python 3.5, then
> > instead of just deleting all of the openstack-tox-py27 jobs, we'd
> > probably just need to replace them with openstack-tox-py35 jobs, as that
> > would be our new low-water mark.
> >
> > Now, maybe we'll get lucky and RHEL/CentOS 8 will be a future-looking
> > release and will ship with python 3.7 AND so will the corresponding
> > Ubuntu LTS - and we'll get to only care about one release of python for
> > a minute. :)
> >
> > Come on - I can dream, right?
>
> Sure, but let's not get complacent - 3.8 is right around the corner :)
>
>
Btw I confirmed this morning that the plan for 20.04 LTS is to have 3.8, so
it really is around the corner.

Thanks,
Corey

cheers,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Mon, Oct 15, 2018, 4:11 PM Jeremy Stanley  wrote:

> On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote:
> [...]
> > That said, I don't think we should be dropping support/testing for 3.5.
> > According to:
> >
> >   https://governance.openstack.org/tc/reference/pti/python.html
> >
> > 3.5 is the only Python3 version that we require all projects to run tests
> > for.
>
> Until we update it to refer to the version provided by the test
> platforms we document at:
>
>
> https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions
>
> > Out goal is to get everyone running 3.6 unit tests by the end of Stein:
> >
> >
> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
> >
> > but we explicitly said there that we were not dropping support for 3.5 as
> > part of the goal, and should continue to do so until we can effect an
> > orderly transition later.
> [...]
>
> We're not dropping support for 3.5 as part of the python3-first
> goal, but would be dropping it as part of the switch from Ubuntu
> 16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides
> Python 3.6). In the past the OpenStack Infra team has prodded us to
> follow our documented testing platform policies as new versions
> become available, but now with a move to providing infrastructure
> services to other OSF projects as well we're on our own to police
> this.
>
> We _could_ decide that we're going to start running tests on
> multiple versions of Python 3 indefinitely (rather than as a
> transitional state during the switch from Ubuntu Xenial to Bionic)
> but that does necessarily mean running more jobs. We could also
> decide to start targeting different versions of Python than provided
> by the distros on which we run our tests (and build it from source
> ourselves or something) but I think that's only reasonable if we're
> going to also recommend that users deploy OpenStack on top of
> custom-compiled Python interpreters rather than the interpreters
> provided by server distros like RHEL and Ubuntu.
>
> So to sum up the above, it's less a question of whether we're
> dropping Python 3.5 testing in Stein, and more a question of whether
> we're going to continue requiring OpenStack to also be able to run
> on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start
> of the cycle).
>

>From an ubuntu perspective, ubuntu is going to support stein on 18.04 LTS
(3.6) and 19.04 (3.7) only. With that said does upstream still want to
ensure stein runs on 16.04 if ubuntu itself has no plans to?

I was assuming the desire to keep 3.5 stein support was for other distros
that plan to support stein with 3.5.

Corey

-- 
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Mon, Oct 15, 2018 at 3:15 PM Corey Bryant 
wrote:

>
>
> On Mon, Oct 15, 2018 at 3:01 PM Zane Bitter  wrote:
>
>> On 12/10/18 8:59 AM, Corey Bryant wrote:
>> >
>> >
>> > On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger > > <mailto:a...@suse.com>> wrote:
>> >
>> > On 10/10/2018 23.10, Jeremy Stanley wrote:
>> >  > I might have only pointed this out on IRC so far, but the
>> >  > expectation is that testing 3.5 and 3.6 at the same time was
>> merely
>> >  > transitional since official OpenStack projects should be moving
>> >  > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
>> >  > Bionic (which provides 3.6 and, now, 3.7 as well) during the
>> Stein
>> >  > cycle and so will drop 3.5 testing on master in the process.
>> >
>> > Agreed, this needs some larger communication and explanation on what
>> > to do,
>> >
>> >
>> > The good news is we now have an initial change underway and successful,
>> > dropping py35 and enabling py37:
>> https://review.openstack.org/#/c/609557/
>>
>> Hey Corey,
>> Thanks for getting this underway, it's really important that we keep
>> moving forward (we definitely got behind on the 3.6 transition and are
>> paying for it now).
>>
>> That said, I don't think we should be dropping support/testing for 3.5.
>> According to:
>>
>>https://governance.openstack.org/tc/reference/pti/python.html
>>
>> 3.5 is the only Python3 version that we require all projects to run
>> tests for.
>>
>> Out goal is to get everyone running 3.6 unit tests by the end of Stein:
>>
>>
>>
>> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
>>
>> but we explicitly said there that we were not dropping support for 3.5
>> as part of the goal, and should continue to do so until we can effect an
>> orderly transition later. Personally, I would see that including waiting
>> for all the 3.5-supporting projects to add 3.6 jobs (which has been
>> blocked up until ~this point, as we are only just now close to getting
>> all of the repos using local Zuul config).
>>
>> I do agree that anything that works on 3.5 and 3.7 will almost certainly
>> work on 3.6, so if you wanted to submit a patch to that goal saying that
>> projects could add a unit test job for *either* 3.6 or 3.7 (in addition
>> to 3.5) then I would probably support that. We could then switch all the
>> 3.5 jobs to 3.6 later when we eventually drop 3.5 support. That would
>> mean we'd only ever run 3 unit test jobs (and 2 once 2.7 is eventually
>> dropped) - for the oldest and newest versions of Python 3 that a project
>> supports.
>>
>
> This seems like a reasonable approach to me. I'll get a review up and we
> can see what others think.
>
>
I have the following up for review to modify the python3-first goal to
allow for python3.6 or python3.7 unit test enablement:
https://review.openstack.org/#/c/610708/

Thanks,
Corey


>> cheers,
>> Zane.
>>
>> [This thread was also discussed on IRC starting here:
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-15.log.html#t2018-10-15T18:09:05
>> ]
>>
>> > I'm happy to get things moving along and start proposing changes like
>> > this to other projects and communicating with PTLs along the way. Do
>> you
>> > think we need more discussion/communication on this or should I get
>> started?
>> >
>> > Thanks,
>> > Corey
>> >
>> >
>> > Andreas
>> > --
>> >   Andreas Jaeger aj@{suse.com <http://suse.com>,opensuse.org
>> > <http://opensuse.org>} Twitter: jaegerandi
>> >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> > GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>> > HRB 21284 (AG Nürnberg)
>> >  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
>> > A126
>> >
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/l

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Mon, Oct 15, 2018 at 3:01 PM Zane Bitter  wrote:

> On 12/10/18 8:59 AM, Corey Bryant wrote:
> >
> >
> > On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger  > <mailto:a...@suse.com>> wrote:
> >
> > On 10/10/2018 23.10, Jeremy Stanley wrote:
> >  > I might have only pointed this out on IRC so far, but the
> >  > expectation is that testing 3.5 and 3.6 at the same time was
> merely
> >  > transitional since official OpenStack projects should be moving
> >  > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> >  > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> >  > cycle and so will drop 3.5 testing on master in the process.
> >
> > Agreed, this needs some larger communication and explanation on what
> > to do,
> >
> >
> > The good news is we now have an initial change underway and successful,
> > dropping py35 and enabling py37:
> https://review.openstack.org/#/c/609557/
>
> Hey Corey,
> Thanks for getting this underway, it's really important that we keep
> moving forward (we definitely got behind on the 3.6 transition and are
> paying for it now).
>
> That said, I don't think we should be dropping support/testing for 3.5.
> According to:
>
>https://governance.openstack.org/tc/reference/pti/python.html
>
> 3.5 is the only Python3 version that we require all projects to run
> tests for.
>
> Out goal is to get everyone running 3.6 unit tests by the end of Stein:
>
>
>
> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
>
> but we explicitly said there that we were not dropping support for 3.5
> as part of the goal, and should continue to do so until we can effect an
> orderly transition later. Personally, I would see that including waiting
> for all the 3.5-supporting projects to add 3.6 jobs (which has been
> blocked up until ~this point, as we are only just now close to getting
> all of the repos using local Zuul config).
>
> I do agree that anything that works on 3.5 and 3.7 will almost certainly
> work on 3.6, so if you wanted to submit a patch to that goal saying that
> projects could add a unit test job for *either* 3.6 or 3.7 (in addition
> to 3.5) then I would probably support that. We could then switch all the
> 3.5 jobs to 3.6 later when we eventually drop 3.5 support. That would
> mean we'd only ever run 3 unit test jobs (and 2 once 2.7 is eventually
> dropped) - for the oldest and newest versions of Python 3 that a project
> supports.
>

This seems like a reasonable approach to me. I'll get a review up and we
can see what others think.

Thanks,
Corey


> cheers,
> Zane.
>
> [This thread was also discussed on IRC starting here:
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-15.log.html#t2018-10-15T18:09:05
> ]
>
> > I'm happy to get things moving along and start proposing changes like
> > this to other projects and communicating with PTLs along the way. Do you
> > think we need more discussion/communication on this or should I get
> started?
> >
> > Thanks,
> > Corey
> >
> >
> > Andreas
> > --
> >   Andreas Jaeger aj@{suse.com <http://suse.com>,opensuse.org
> > <http://opensuse.org>} Twitter: jaegerandi
> >SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> > HRB 21284 (AG Nürnberg)
> >  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
> > A126
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Fri, Oct 12, 2018 at 8:59 AM Corey Bryant 
wrote:

>
>
> On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger  wrote:
>
>> On 10/10/2018 23.10, Jeremy Stanley wrote:
>> > I might have only pointed this out on IRC so far, but the
>> > expectation is that testing 3.5 and 3.6 at the same time was merely
>> > transitional since official OpenStack projects should be moving
>> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
>> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
>> > cycle and so will drop 3.5 testing on master in the process.
>>
>> Agreed, this needs some larger communication and explanation on what to
>> do,
>>
>>
> The good news is we now have an initial change underway and successful,
> dropping py35 and enabling py37: https://review.openstack.org/#/c/609557/
>
> I'm happy to get things moving along and start proposing changes like this
> to other projects and communicating with PTLs along the way. Do you think
> we need more discussion/communication on this or should I get started?
>
> Thanks,
> Corey
>

We have a story to track this now at:
https://storyboard.openstack.org/#!/story/2004073

I think we will just get started on proposing changes. I've had a couple of
folks ask if they can help out which is great so we will start to chip away
at the story above. We'll also contact PTLs as we start working on projects
in case they haven't seen this thread.

Of course if anyone objects to us moving forward, please feel free to let
us know.

Thanks,
Corey


>
> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger  wrote:

> On 10/10/2018 23.10, Jeremy Stanley wrote:
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> Agreed, this needs some larger communication and explanation on what to do,
>
>
The good news is we now have an initial change underway and successful,
dropping py35 and enabling py37: https://review.openstack.org/#/c/609557/

I'm happy to get things moving along and start proposing changes like this
to other projects and communicating with PTLs along the way. Do you think
we need more discussion/communication on this or should I get started?

Thanks,
Corey


Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 7:36 PM Goutham Pacha Ravi 
wrote:

> On Wed, Oct 10, 2018 at 2:10 PM Jeremy Stanley  wrote:
> >
> > On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> > > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and
> > > 3.7.
> > [...]
> >
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> ++ on switching python3.5 jobs to testing with python3.7 on Bionic.
> python3.5 wasn't supported on all distros [1][2][3][4][5]. Xenial had it,
> so it was nice to test with it when developing Queens and Rocky.
>
>
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's not
> being installed,
> do you need to make any bindep changes to enable the "universe" ppa and
> install
> python3.7 and python3.7-dev?
>

Following up on this for anyone else who's following along. The python3.7
interpreter and development files are now correctly being installed after
some additional changes in zuul jobs. And we have our first py37 SUCCESS!
https://review.openstack.org/#/c/609557/

Goutham, thanks again for jumping in and adding py37 tests to your projects.

Thanks,
Corey


>
> [1] OpenSuse https://software.opensuse.org/package/python3
> [2] Ubuntu https://packages.ubuntu.com/search?keywords=python3
> [3] Fedora https://apps.fedoraproject.org/packages/python3
> [4] Arch https://www.archlinux.org/packages/extra/x86_64/python/
> [5] Gentoo https://wiki.gentoo.org/wiki/Project:Python/Implementations
> [6] manila https://review.openstack.org/#/c/609558
> [7] python-manilaclient https://review.openstack.org/609557
>
> --
> Goutham
>
> > --
> > Jeremy Stanley
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 7:36 PM Goutham Pacha Ravi 
wrote:

> On Wed, Oct 10, 2018 at 2:10 PM Jeremy Stanley  wrote:
> >
> > On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> > > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and
> > > 3.7.
> > [...]
> >
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> ++ on switching python3.5 jobs to testing with python3.7 on Bionic.
> python3.5 wasn't supported on all distros [1][2][3][4][5]. Xenial had it,
> so it was nice to test with it when developing Queens and Rocky.
>
>
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's not
> being installed,
> do you need to make any bindep changes to enable the "universe" ppa and
> install
> python3.7 and python3.7-dev?
>
>
Great, thanks for doing that! I'll look into what's needed to get python3.7
installed by the CI job.

Corey


> [1] OpenSuse https://software.opensuse.org/package/python3
> [2] Ubuntu https://packages.ubuntu.com/search?keywords=python3
> [3] Fedora https://apps.fedoraproject.org/packages/python3
> [4] Arch https://www.archlinux.org/packages/extra/x86_64/python/
> [5] Gentoo https://wiki.gentoo.org/wiki/Project:Python/Implementations
> [6] manila https://review.openstack.org/#/c/609558
> [7] python-manilaclient https://review.openstack.org/609557
>
> --
> Goutham
>
> > --
> > Jeremy Stanley
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 10:18 AM Jeremy Stanley  wrote:

> On 2018-10-10 16:09:21 +0200 (+0200), Andreas Jaeger wrote:
> [...]
> > So, I'm asking whether there is a good way to not duplicating all
> > jobs to run on all three interpreters. Do we really need testing
> > of all three versions? Or is testing with a subset a manageable
> > risk?
>
> OpenStack projects are hopefully switching to testing on Bionic
> instead of Xenial during the Stein cycle, so will stop testing with
> Python 3.5 on master when that happens (since Bionic provides
> 3.6/3.7 and no 3.5).
>

That would be ideal, in which case dropping py35 and adding py37 for master
in Stein shouldn't require any more resources.

Corey

-- 
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 10:09 AM Andreas Jaeger  wrote:

> On 10/10/2018 15.42, Corey Bryant wrote:
> >
> >
> > On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger  > <mailto:a...@suse.com>> wrote:
> >
> > On 10/10/2018 14.45, Corey Bryant wrote:
> >  > [...]
> >  > == Enabling py37 unit tests ==
> >  >
> >  > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have
> > reviews
> >  > up to define the py37 zuul job and templates here:
> >  > https://review.openstack.org/#/c/609066
> >  >
> >  > I'd like to start submitting reviews to projects to enable
> >  > openstack-python37-jobs (or variant) for projects that already
> have
> >  > openstack-python36-jobs in their .zuul.yaml, zuul.yaml,
> >  > .zuul.d/project.yaml.
> >
> > We have projects testing python 3.5 and 3.6 already. Adding 3.7 to
> > it is
> > a lot of wasted VMs. Can we limit testing and not test all three,
> > please?
> >
> >
> > Well, I wouldn't call any of them wasted if they're testing against a
> > supported Python version.
>
>
> What I mean is that we run too into a situation where we have a large
> backlog of CI jobs since we have to many changes and jobs in flight.
>
> So, I'm asking whether there is a good way to not duplicating all jobs
> to run on all three interpreters. Do we really need testing of all three
> versions? Or is testing with a subset a manageable risk?
>

Fair enough. I'm probably not the right person to answer so perhaps someone
else can chime in. One thing worth pointing out is that it seems the jump
from 3.5 to 3.6 wasn't nearly as painful as the jump from 3.6 to 3.7, at
least in my experience.

Corey


> Andreas
> --
>   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
__
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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger  wrote:

> On 10/10/2018 14.45, Corey Bryant wrote:
> > [...]
> > == Enabling py37 unit tests ==
> >
> > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews
> > up to define the py37 zuul job and templates here:
> > https://review.openstack.org/#/c/609066
> >
> > I'd like to start submitting reviews to projects to enable
> > openstack-python37-jobs (or variant) for projects that already have
> > openstack-python36-jobs in their .zuul.yaml, zuul.yaml,
> > .zuul.d/project.yaml.
>
> We have projects testing python 3.5 and 3.6 already. Adding 3.7 to it is
> a lot of wasted VMs. Can we limit testing and not test all three, please?
>
>
Well, I wouldn't call any of them wasted if they're testing against a
supported Python version.

Corey

Andreas
> --
>   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
__
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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Wed, Oct 10, 2018 at 9:27 AM Jeremy Stanley  wrote:

> On 2018-10-10 08:45:39 -0400 (-0400), Corey Bryant wrote:
> [...]
> > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter
> [...]
>
> Thanks for the heads up! Last time I looked it was still a pre-3.7.0
> beta package, but looks like that has finally been updated to a
> proper release of the interpreter for Bionic in the last few weeks?
>

Yes, it was recently updated. It was originally a sync from Debian and we
got what we got in Bionic but the foundations folks were kind enough to
update it for us. This is a universe package for Bionic so it's not
officially supported but it should be good enough for unit testing. Another
option could be to use a non-LTS image to use a supported release.

Corey

-- 
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devbut t
> <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

[openstack-dev] [python3] Enabling py37 unit tests

[Corey Bryant]

Hi All,

I'd like to enable py37 unit tests in the gate.

== Background ==

I work on OpenStack packaging for Ubuntu. During the Rocky release (Ubuntu
Cosmic) I tried to fix py37 bugs upstream as I came across them. There
ended up being a lot of py37 issues and after a while, due to time
constraints, I resorted to just opening bugs and disabling py37 unit tests
that were failing in our package builds. Luckily enough, even though Cosmic
ships with python3.6 and python3.7, python3.6 ended up being chosen as the
default for Cosmic.

== Defaulting to python3.7 ==

The next release of Ubuntu opens in just a few weeks. It will default to
python3.7 and will not include python3.6. My hope is that if I can help
enable py37 unit tests upstream now, we can get a wider view at fixing
issues soon.

== Enabling py37 unit tests ==

Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews up
to define the py37 zuul job and templates here:
https://review.openstack.org/#/c/609066

I'd like to start submitting reviews to projects to enable
openstack-python37-jobs (or variant) for projects that already have
openstack-python36-jobs in their .zuul.yaml, zuul.yaml,
.zuul.d/project.yaml.

== Coinciding work ==

There is python3-first work going on now and I completely understand that
this is going to cause more work for some projects. It seems that now is as
good of a time as ever to catch up and test with a recent python3 version.
I'm sure python3.8 and beyond will be here before we know it.

Any thoughts or concerns?

Thanks,
Corey
__
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] [Openstack] OpenStack Rocky for Ubuntu 18.04 LTS

[Corey Bryant]

The Ubuntu OpenStack team at Canonical is pleased to announce the general
availability of OpenStack Rocky on Ubuntu 18.04 LTS via the Ubuntu Cloud
Archive. Details of the Rocky release can be found at:
https://www.openstack.org/software/rocky

To get access to the Ubuntu Rocky packages:

Ubuntu 18.04 LTS
---

You can enable the Ubuntu Cloud Archive pocket for OpenStack Rocky on
Ubuntu 18.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:rocky
sudo apt update

The Ubuntu Cloud Archive for Rocky includes updates for:

aodh, barbican, ceilometer, ceph (13.2.1), cinder, designate,
designate-dashboard, glance, gnocchi, heat, heat-dashboard, horizon,
ironic, keystone, magnum, manila, manila-ui, mistral, murano,
murano-dashboard, networking-bagpipe, networking-bgpvpn, networking-hyperv,
networking-l2gw, networking-odl, networking-ovn, networking-sfc, neutron,
neutron-dynamic-routing, neutron-fwaas, neutron-lbaas,
neutron-lbaas-dashboard, neutron-vpnaas, nova, nova-lxd, octavia,
openstack-trove, openvswitch (2.10.0), panko, sahara, sahara-dashboard,
senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.

For a full list of packages and versions, please refer to:
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/rocky_versions.html

Python 3 support
-
Python 3 packages are now available for all of the above packages except
swift. All of these packages have successfully been unit tested with at
least Python 3.6. Function testing is ongoing and fixes will continue to be
backported to Rocky.

Python 3 enablement
--
In Rocky, Python 2 packages will still be installed by default for all
packages except gnocchi and octavia, which are Python 3 by default. In a
future release, we will switch all packages to Python 3 by default.

To enable Python 3 for existing installations:
# upgrade to latest Rocky package versions first, then:
sudo apt install python3- [1]
sudo apt install libapache2-mod-wsgi-py3  # not required for all
packages [2]
sudo apt purge python- [1]
sudo apt autoremove --purge
sudo systemctl restart -*
sudo systemctl restart apache2  # not required for all packages [2]

For example:
sudo apt install aodh-*
sudo apt install python3-aodh libapache2-mod-wsgi-py3
sudo apt purge python-aodh
sudo apt autoremove --purge
sudo systemctl restart aodh-* apache2

To enable Python 3 for new installations:
sudo apt install python3- [1]
sudo apt install libapache2-mod-wsgi-py3  # not required for all
packages [2]
sudo apt install -

For example:
sudo apt install python3-aodh libapache2-mod-wsgi-py3 aodh-api

[1] The naming convention of python packages is generally python-
and python3-. For horizon, however, the packages are named
python-django-horizon and python3-django-horizon.

[2] The following packages are run under apache2 and require installation
of libapache2-mod-wsgi-py3 to enable Python 3 support:
aodh-api, cinder-api, barbican-api, keystone, nova-placement-api,
openstack-dashboard, panko-api, sahara-api

Other notable changes

sahara-api: sahara API now runs under apache2 with mod_wsgi

Branch Package Builds
-
If you would like to try out the latest updates to branches, we deliver
continuously integrated packages on each upstream commit via the following
PPA’s:

sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
sudo add-apt-repository ppa:openstack-ubuntu-testing/queens
sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky

Reporting bugs
---
If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thanks to everyone who has contributed to OpenStack Rocky, both upstream
and downstream. Special thanks to the Puppet OpenStack modules team and the
OpenStack Charms team for their continued early testing of the Ubuntu Cloud
Archive, as well as the Ubuntu and Debian OpenStack teams for all of their
contributions.

Have fun and see you in Stein!

Cheers,
Corey
(on behalf of the Ubuntu OpenStack team)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Corey Bryant]

On Wed, Aug 8, 2018 at 10:29 AM, Mehdi Abaakouk  wrote:

> On Wed, Aug 08, 2018 at 08:35:20AM -0400, Corey Bryant wrote:
>
>> On Wed, Aug 8, 2018 at 3:43 AM, Thomas Goirand  wrote:
>>
>> On 08/07/2018 06:10 PM, Corey Bryant wrote:
>>> > I was concerned that there wouldn't be any
>>> > gating until Ubuntu 20.04 (April 2020)
>>> Same over here. I'm concerned that it takes another 2 years, which
>>> really, we cannot afford.
>>>
>>> > but Py3.7 is available in bionic today.
>>>
>>
> Yeah but it's the beta3 version.
>
>
Yes, that's something I mentioned before but it was snipped from the
conversation. We're going to try and get that updated.

Corey

-- 
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Corey Bryant]

On Wed, Aug 8, 2018 at 3:43 AM, Thomas Goirand  wrote:

> On 08/07/2018 06:10 PM, Corey Bryant wrote:
> > I was concerned that there wouldn't be any
> > gating until Ubuntu 20.04 (April 2020)
> Same over here. I'm concerned that it takes another 2 years, which
> really, we cannot afford.
>
> > but Py3.7 is available in bionic today.
>
> Is Bionic going to be released with Py3.7? In Debconf18 in Taiwan, Doko
> didn't seem completely sure about it.
>
>
Bionic was released with py3.7 in April 2018. Py3.6 is the default for
Bionic but Py3.7 is available.

https://launchpad.net/ubuntu/+source/python3.7

Corey

Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Corey Bryant]

On Tue, Aug 7, 2018 at 11:28 AM, Zane Bitter  wrote:

> Top posting to avoid getting into the weeds.
>
> * OpenStack is indeed lagging behind
> * The road to 3.7 (and eventually 3.8) runs through 3.6
> * As part of the project-wide python3-first goal we aim to have everything
> working on 3.6 for Stein, so we are making some progress at least
> * As of now we are *not* dropping support for 3.5 in Stein
> * No matter what we do, the specific issue you're encountering is
> structural: we don't add support for a Python version in the gate until it
> is available in an Ubuntu LTS release, and that doesn't happen until after
> it is available in Debian, so you will always have the problem that new
> Python versions will be introduced in Debian before we have a gate for them
>

Thanks for mentioning this. I was concerned that there wouldn't be any
gating until Ubuntu 20.04 (April 2020) but Py3.7 is available in bionic
today. It's a bit older version but I think that's just because we're early
py3.7 stages, so we'll try to get that updated.

Thanks,
Corey

* Structural problems require structural solutions; "everybody work
> harder/pay more attention/prioritise differently" will not do it
> * I don't see any evidence that people are refusing to review patches that
> fix 3.7 issues, and I certainly don't think fixing them is 'controversial'
>
>
> On 07/08/18 10:11, Thomas Goirand wrote:
>
>> On 08/07/2018 03:24 PM, Sean Mooney wrote:
>>
>>> so im not sure pushing for python 3.7 is the right thing to do. also i
>>> would not
>>> assume all distros will ship 3.7 in the near term. i have not check
>>> lately but
>>> i believe cento 7 unless make 3.4 and 3.6 available in the default repos.
>>> ubuntu 18.04 ships with 3.6 i believe
>>>
>>
>> The current plan for Debian is that we'll be trying to push for Python
>> 3.7 for Buster, which freezes in January. This freeze date means that
>> it's going to be Rocky that will end up in the next Debian release. If
>> Python 3.7 is a failure, then late November, we will remove Python 3.7
>> from Unstable and let Buster release with 3.6.
>>
>> As for Ubuntu, it is currently unclear if 18.10 will be released with
>> Python 3.7 or not, but I believe they are trying to do that. If not,
>> then 19.04 will for sure be released with Python 3.7.
>>
>> im not sure about other linux distros but since most openstack
>>> deployment are done
>>> on LTS releases of operating systems i would suspect that python 3.6
>>> will be the main
>>> python 3 versions we see deployed in production for some time.
>>>
>>
>> In short: that's wrong.
>>
>> having a 3.7 gate is not a bad idea but priority wise have a 3.6 gate
>>> would be much higher on my list.
>>>
>>
>> Wrong list. One version behind.
>>
>> i think we as a community will have to decide on the minimum and
>>> maximum python 3 versions
>>> we support for each release and adjust as we go forward.
>>>
>>
>> Whatever the OpenStack community decides is not going to change what
>> distributions like Debian will do. This type of reasoning lacks a much
>> needed humility.
>>
>> i would suggst a min of 3.5 and max of 3.6 for rocky.
>>>
>>
>> My suggestion is that these bugs are of very high importance and that
>> they should at least deserve attention. That the gate for Python 3.7
>> isn't ready, I can understand, as everyone's time is limited. This
>> doesn't mean that the OpenStack community at large should just dismiss
>> patches that are important for downstream.
>>
>> for stien perhaps bump that to min of 3.6 max 3.7 but i think this is
>>> something that needs to be address community wide
>>> via a governance resolution rather then per project.
>>>
>>
>> At this point, dropping 3.5 isn't a good idea either, even for Stein.
>>
>> it will also
>>> impact the external python lib we can depend on too which is
>>> another reason i think thie need to be a comuntiy wide discussion and
>>> goal that is informed by what distros are doing but
>>> not mandated by what any one distro is doing.
>>> regards
>>> sean.
>>>
>>
>> Postponing any attempt to support anything current is always a bad idea.
>> I don't see why there's even a controversy when one attempts to fix bugs
>> that will, sooner or later, also hit the gate.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
__
OpenStack Development Mailing List 

Re: [openstack-dev] [all] [designate] [heat] [python3] deadlock with eventlet and ThreadPoolExecutor in py3.7

[Corey Bryant]

Ok thanks again for the input.

Corey

On Wed, Jul 25, 2018 at 2:15 PM, Joshua Harlow 
wrote:

> So the only diff is that GreenThreadPoolExecutor was customized to work
> for eventlet (with a similar/same api as ThreadPoolExecutor); as for
> performance I would expect (under eventlet) that GreenThreadPoolExecutor
> would have better performance because it can use the native eventlet green
> objects (which it does try to use) instead of having to go threw the layers
> that ThreadPoolExecutor would have to use to achieve the same (and in this
> case as you found out it looks like those layers are not patched correctly
> in the newest ThreadPoolExecutor).
>
> Otherwise yes, under eventlet imho swap out the executor (assuming you can
> do this) and under threading swap in threadpool executor (ideally if done
> correctly the same stuff should 'just work').
>
> Corey Bryant wrote:
>
>> Josh,
>>
>> Thanks for the input. GreenThreadPoolExecutor does not have the deadlock
>> issue, so that is promising (at least with futurist 1.6.0).
>>
>> Does ThreadPoolExecutor have better performance than
>> GreenThreadPoolExecutor? Curious if we could just swap out
>> ThreadPoolExecutor for GreenThreadPoolExecutor.
>>
>> Thanks,
>> Corey
>>
>> On Wed, Jul 25, 2018 at 12:54 PM, Joshua Harlow > <mailto:harlo...@fastmail.com>> wrote:
>>
>> Have you tried the following instead of threadpoolexecutor (which
>> honestly should work as well, even under eventlet + eventlet
>> patching).
>>
>> https://docs.openstack.org/futurist/latest/reference/index.
>> html#futurist.GreenThreadPoolExecutor
>> <https://docs.openstack.org/futurist/latest/reference/index.
>> html#futurist.GreenThreadPoolExecutor>
>>
>> If you have the ability to specify which executor your code is
>> using, and you are running under eventlet I'd give preference to the
>> green thread pool executor under that situation (and if not running
>> under eventlet then prefer the threadpool executor variant).
>>
>> As for @tomoto question; honestly openstack was created before
>> asyncio was a thing so that was a reason and assuming eventlet
>> patching is actually working then all the existing stdlib stuff
>> should keep on working under eventlet (including
>> concurrent.futures); otherwise eventlet.monkey_patch isn't working
>> and that's breaking the eventlet api. If their contract is that only
>> certain things work when monkey patched, that's fair, but that needs
>> to be documented somewhere (honestly it's time imho to get the hell
>> off eventlet everywhere but that likely requires rewrites of a lot
>> of things, oops...).
>>
>> -Josh
>>
>> Corey Bryant wrote:
>>
>> Hi All,
>>
>> I'm trying to add Py3 packaging support for Ubuntu Rocky and
>> while there
>> are a lot of issues involved with supporting Py3.7, this is one
>> of the
>> big ones that I could use a hand with.
>>
>> With py3.7, there's a deadlock when eventlet monkeypatch of stdlib
>> thread modules is combined with use of ThreadPoolExecutor. I
>> know this
>> affects at least designate. The same or similar also affects heat
>> (though I've not dug into the code the traceback after canceling
>> tests
>> matches that seen with designate). And it may affect other
>> projects that
>> I haven't touched yet.
>>
>> How to recreate [1]:
>> * designate: Add a tox.ini py37 target and run
>> designate.tests.test_workers.test_processing.TestProcessingE
>> xecutor.test_execute_multiple_tasks
>> * heat: Add a tox.ini py37 target and run tests
>> * general: Run bpo34173-recreate.py
>> <https://bugs.python.org/file47709/bpo34173-recreate.py
>> <https://bugs.python.org/file47709/bpo34173-recreate.py>> from
>> issue
>> 34173 (see below).
>> [1] ubuntu cosmic has py3.7
>>
>> In issue 508 (see below) @tomoto asks "Eventlet and asyncio
>> solve same
>> problem. Why would you want concurrent.futures and eventlet in
>> same
>> application?"
>>
>> I told @tomoto that I'd seek input to that question from
>> upstream. I
>> know there've been efforts to move away from eventlet but I just
>> don't
>> have the knowledge to  p

Re: [openstack-dev] [all] [designate] [heat] [python3] deadlock with eventlet and ThreadPoolExecutor in py3.7

[Corey Bryant]

Josh,

Thanks for the input. GreenThreadPoolExecutor does not have the deadlock
issue, so that is promising (at least with futurist 1.6.0).

Does ThreadPoolExecutor have better performance than
GreenThreadPoolExecutor? Curious if we could just swap out
ThreadPoolExecutor for GreenThreadPoolExecutor.

Thanks,
Corey

On Wed, Jul 25, 2018 at 12:54 PM, Joshua Harlow 
wrote:

> Have you tried the following instead of threadpoolexecutor (which honestly
> should work as well, even under eventlet + eventlet patching).
>
> https://docs.openstack.org/futurist/latest/reference/index.
> html#futurist.GreenThreadPoolExecutor
>
> If you have the ability to specify which executor your code is using, and
> you are running under eventlet I'd give preference to the green thread pool
> executor under that situation (and if not running under eventlet then
> prefer the threadpool executor variant).
>
> As for @tomoto question; honestly openstack was created before asyncio was
> a thing so that was a reason and assuming eventlet patching is actually
> working then all the existing stdlib stuff should keep on working under
> eventlet (including concurrent.futures); otherwise eventlet.monkey_patch
> isn't working and that's breaking the eventlet api. If their contract is
> that only certain things work when monkey patched, that's fair, but that
> needs to be documented somewhere (honestly it's time imho to get the hell
> off eventlet everywhere but that likely requires rewrites of a lot of
> things, oops...).
>
> -Josh
>
> Corey Bryant wrote:
>
>> Hi All,
>>
>> I'm trying to add Py3 packaging support for Ubuntu Rocky and while there
>> are a lot of issues involved with supporting Py3.7, this is one of the
>> big ones that I could use a hand with.
>>
>> With py3.7, there's a deadlock when eventlet monkeypatch of stdlib
>> thread modules is combined with use of ThreadPoolExecutor. I know this
>> affects at least designate. The same or similar also affects heat
>> (though I've not dug into the code the traceback after canceling tests
>> matches that seen with designate). And it may affect other projects that
>> I haven't touched yet.
>>
>> How to recreate [1]:
>> * designate: Add a tox.ini py37 target and run
>> designate.tests.test_workers.test_processing.TestProcessingE
>> xecutor.test_execute_multiple_tasks
>> * heat: Add a tox.ini py37 target and run tests
>> * general: Run bpo34173-recreate.py
>> <https://bugs.python.org/file47709/bpo34173-recreate.py> from issue
>> 34173 (see below).
>> [1] ubuntu cosmic has py3.7
>>
>> In issue 508 (see below) @tomoto asks "Eventlet and asyncio solve same
>> problem. Why would you want concurrent.futures and eventlet in same
>> application?"
>>
>> I told @tomoto that I'd seek input to that question from upstream. I
>> know there've been efforts to move away from eventlet but I just don't
>> have the knowledge to  provide a good answer to him.
>>
>> Here are the bugs/issues I currently have open for this:
>> https://github.com/eventlet/eventlet/issues/508
>> <https://github.com/eventlet/eventlet/issues/508>
>> https://bugs.launchpad.net/designate/+bug/1782647
>> <https://bugs.launchpad.net/designate/+bug/1782647>
>> https://bugs.python.org/issue34173 <https://bugs.python.org/issue34173>
>>
>> Any help with this would be greatly appreciated!
>>
>> Thanks,
>> Corey
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
__
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] [designate] [heat] [python3] deadlock with eventlet and ThreadPoolExecutor in py3.7

[Corey Bryant]

Hi All,

I'm trying to add Py3 packaging support for Ubuntu Rocky and while there
are a lot of issues involved with supporting Py3.7, this is one of the big
ones that I could use a hand with.

With py3.7, there's a deadlock when eventlet monkeypatch of stdlib thread
modules is combined with use of ThreadPoolExecutor. I know this affects at
least designate. The same or similar also affects heat (though I've not dug
into the code the traceback after canceling tests matches that seen with
designate). And it may affect other projects that I haven't touched yet.

How to recreate [1]:
* designate: Add a tox.ini py37 target and run designate.tests.test_workers.
test_processing.TestProcessingExecutor.test_execute_multiple_tasks
* heat: Add a tox.ini py37 target and run tests
* general: Run bpo34173-recreate.py
 from issue 34173
(see below).
[1] ubuntu cosmic has py3.7

In issue 508 (see below) @tomoto asks "Eventlet and asyncio solve same
problem. Why would you want concurrent.futures and eventlet in same
application?"

I told @tomoto that I'd seek input to that question from upstream. I know
there've been efforts to move away from eventlet but I just don't have the
knowledge to  provide a good answer to him.

Here are the bugs/issues I currently have open for this:
https://github.com/eventlet/eventlet/issues/508
https://bugs.launchpad.net/designate/+bug/1782647
https://bugs.python.org/issue34173

Any help with this would be greatly appreciated!

Thanks,
Corey
__
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] [packaging] Extended Maintenance and Distro LTS coordination

[Corey Bryant]

At the summit in Vancouver there were sessions discussing Extended
Maintenance. The general focus was on keeping upstream branches open in
extended maintenance mode after 18 months rather than EOLing them. If at
some point fixes cannot land in a given project's branch, and there is no
reasonable solution, then the branch would need to be EOL'd for that
project.

Personally I think this is great. In Ubuntu we want all fixes to land
upstream first for supported releases, but once upstream branches reach
EOL, we end up carrying local patches in our packages. I assume other
distros do the same, so any sharing we can do here would make shorter work
for all involved.

During the first EM session, David Ames mentioned that perhaps distros
could coordinate on what releases will be their LTS's to enable more focus
on specific EM branches and Doug Hellman suggested an email to the list. I
don't know how other distros choose their OpenStack LTS's or if anything
will change from distro to distro but it seems to be worth a discussion.

I'm going to give an overview of the Ubuntu OpenStack LTS releases below
(current and planned). What are other distros' LTS's (current and planned)
and do we line up at all?

Ubuntu LTS (for background)
--
Every 2 years in April a new Ubuntu LTS is released and support supported
for 5 years. For example:
* Ubuntu 16.04 - released in April 2016; supported until April 2021
* Ubuntu 18.04 - released in April 2018; supported until April 2023
* Ubuntu 20.04 - released in April 2020; supported until April 2025

Ubuntu OpenStack LTS
---
Ubuntu OpenStack LTS is provided in 3 different scenarios:
1) Each Ubuntu LTS supports the most recent release of OpenStack available
at the time of the release for 5 years.
2) Each N-1 Ubuntu LTS supports that same release --^ of OpenStack for 3
years.
3) Each Ubuntu LTS supports the latest release of OpenStack that is
available as of April of odd years for 3 years.

Examples of 1:
* Ubuntu 16.04 - OpenStack Mitaka supported for 5 years (via Ubuntu 16.04
archive)
* Ubuntu 18.04 - OpenStack Queens supported for 5 years (via Ubuntu 18.04
archive)
* Ubuntu 20.04 - OpenStack U* supported for 5 years (via Ubuntu 20.04
archive) [1]

Examples of 2:
* Ubuntu 14.04 - OpenStack Mitaka supported for 3 years (via Ubuntu Cloud
Archive)
* Ubuntu 16.04 - OpenStack Queens supported for 3 years (via Ubuntu Cloud
Archive)
* Ubuntu 18.04 - OpenStack U* supported for 3 years (via Ubuntu Cloud
Archive) [1]

Examples of 3:
* Ubuntu 16.04 - OpenStack Ocata supported for 3 years (via Ubuntu Cloud
Archive)
* Ubuntu 18.04 - OpenStack Stein supported for 3 years (via Ubuntu Cloud
Archive) [1]

[1] Future OpenStack release; assumes the same OpenStack release cadence
continues

If you'd like to see a visual of this release cadence, there's a chart at
https://www.ubuntu.com/info/release-end-of-life under "Ubuntu OpenStack
release end of life".

Thanks,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] OpenStack Queens for Ubuntu 18.04 LTS

[Corey Bryant]

On Fri, Apr 27, 2018 at 11:23 AM, Tobias Urdin <tobias.ur...@crystone.com>
wrote:

> Hello,
>
> I was very interested in packaging Zun for Ubuntu however I did not have
> the time to properly get started.
>
> I was able to package kuryr-lib, I've uploaded it here for now
> https://github.com/tobias-urdin/deb-kuryr-lib
>
>
> Would love to see both Zun and Qinling in Ubuntu to get a good grip on the
> container world :)
> Best regards
>
>
Awesome Tobias. I can take a closer look next week if you'd like.

Thanks,
Corey

>
> On 04/27/2018 04:59 PM, Corey Bryant wrote:
>
> On Fri, Apr 27, 2018 at 10:20 AM, Hongbin Lu <hongbin...@gmail.com> wrote:
>
>> Corey,
>>
>> Thanks for the information. Would you clarify what is "working packages
>> from the community"?
>>
>> Best regards,
>> Hongbin
>>
>
> Sorry I guess that comment is probably a bit vague.
>
> The OpenStack packages are open source like many other projects. They're
> Apache 2 licensed and we gladly accept contributions. :)
>
> This is a good starting point for working with the Ubuntu OpenStack
> packages:
> https://wiki.ubuntu.com/OpenStack/CorePackages
>
> If you or someone else were to provide package sources for zun that DTRT
> to create binary packages, and if they can test them, then I'd be happy to
> review/sponsor the Ubuntu and cloud-archive uploads.
>
> Thanks,
> Corey
>
>
>>
>> On Fri, Apr 27, 2018 at 9:30 AM, Corey Bryant <corey.bry...@canonical.com
>> > wrote:
>>
>>>
>>>
>>> On Fri, Apr 27, 2018 at 9:03 AM, Hongbin Lu <hongbin...@gmail.com>
>>> wrote:
>>>
>>>> Hi Corey,
>>>>
>>>> What are the requirements to include OpenStack Zun into the Ubuntu
>>>> packages? We have a comprehensive installation guide [1] that are using by
>>>> a lot of users when they were installing Zun. However, the missing of
>>>> Ubuntu packages is inconvenient for our users. What the Zun team can help
>>>> for adding Zun to Ubuntu.
>>>>
>>>> [1] https://docs.openstack.org/zun/latest/install/index.html
>>>>
>>>> Best regards,
>>>> Hongbin
>>>>
>>>
>>> Hi Hongbin,
>>>
>>> If we were to get working packages from the community and commitment to
>>> test, I'd be happy to sponsor uploads to Ubuntu and backport to the cloud
>>> achive.
>>>
>>> Thanks,
>>> Corey
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] OpenStack Queens for Ubuntu 18.04 LTS

[Corey Bryant]

On Fri, Apr 27, 2018 at 10:20 AM, Hongbin Lu <hongbin...@gmail.com> wrote:

> Corey,
>
> Thanks for the information. Would you clarify what is "working packages
> from the community"?
>
> Best regards,
> Hongbin
>

Sorry I guess that comment is probably a bit vague.

The OpenStack packages are open source like many other projects. They're
Apache 2 licensed and we gladly accept contributions. :)

This is a good starting point for working with the Ubuntu OpenStack
packages:
https://wiki.ubuntu.com/OpenStack/CorePackages

If you or someone else were to provide package sources for zun that DTRT to
create binary packages, and if they can test them, then I'd be happy to
review/sponsor the Ubuntu and cloud-archive uploads.

Thanks,
Corey


>
> On Fri, Apr 27, 2018 at 9:30 AM, Corey Bryant <corey.bry...@canonical.com>
> wrote:
>
>>
>>
>> On Fri, Apr 27, 2018 at 9:03 AM, Hongbin Lu <hongbin...@gmail.com> wrote:
>>
>>> Hi Corey,
>>>
>>> What are the requirements to include OpenStack Zun into the Ubuntu
>>> packages? We have a comprehensive installation guide [1] that are using by
>>> a lot of users when they were installing Zun. However, the missing of
>>> Ubuntu packages is inconvenient for our users. What the Zun team can help
>>> for adding Zun to Ubuntu.
>>>
>>> [1] https://docs.openstack.org/zun/latest/install/index.html
>>>
>>> Best regards,
>>> Hongbin
>>>
>>
>> Hi Hongbin,
>>
>> If we were to get working packages from the community and commitment to
>> test, I'd be happy to sponsor uploads to Ubuntu and backport to the cloud
>> achive.
>>
>> Thanks,
>> Corey
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] OpenStack Queens for Ubuntu 18.04 LTS

[Corey Bryant]

On Fri, Apr 27, 2018 at 9:03 AM, Hongbin Lu  wrote:

> Hi Corey,
>
> What are the requirements to include OpenStack Zun into the Ubuntu
> packages? We have a comprehensive installation guide [1] that are using by
> a lot of users when they were installing Zun. However, the missing of
> Ubuntu packages is inconvenient for our users. What the Zun team can help
> for adding Zun to Ubuntu.
>
> [1] https://docs.openstack.org/zun/latest/install/index.html
>
> Best regards,
> Hongbin
>

Hi Hongbin,

If we were to get working packages from the community and commitment to
test, I'd be happy to sponsor uploads to Ubuntu and backport to the cloud
achive.

Thanks,
Corey
__
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] [Openstack] OpenStack Queens for Ubuntu 18.04 LTS

[Corey Bryant]

Hi All,

With yesterday’s release of Ubuntu 18.04 LTS (the Bionic Beaver) the Ubuntu
OpenStack team at Canonical is pleased to announce the general availability
of OpenStack Queens on Ubuntu 18.04 LTS. This release of Ubuntu is a Long
Term Support release that will be supported for 5 years.

Further details for the Ubuntu 18.04 release can be found at:
https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes.

And further details for the OpenStack Queens release can be found at:
https://www.openstack.org/software/queens.

Installing on Ubuntu 18.04 LTS
--
No extra steps are required required; just start installing OpenStack!

Installing on Ubuntu 16.04 LTS
--
If you’re interested in OpenStack Queens on Ubuntu 16.04, please refer to
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127851.html,
which coincided with the upstream OpenStack Queens release.

Packages

The 18.04 archive includes updates for:

aodh, barbican, ceilometer, ceph (12.2.4), cinder, congress, designate,
designate-dashboard, dpdk (17.11), glance, glusterfs (3.13.2), gnocchi,
heat, heat-dashboard, horizon, ironic, keystone, libvirt (4.0.0), magnum,
manila, manila-ui, mistral, murano, murano-dashboard, networking-bagpipe,
networking-bgpvpn, networking-hyperv, networking-l2gw, networking-odl,
networking-ovn, networking-sfc, neutron, neutron-dynamic-routing,
neutron-fwaas, neutron-lbaas, neutron-lbaas-dashboard, neutron-taas,
neutron-vpnaas, nova, nova-lxd, openstack-trove, openvswitch (2.9.0),
panko, qemu (2.11), rabbitmq-server (3.6.10), sahara, sahara-dashboard,
senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.

For a full list of packages and versions, please refer to [0].

Branch Package Builds
-
If you want to try out the latest updates to stable branches, we are
delivering continuously integrated packages on each upstream commit in the
following PPA’s:

sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
sudo add-apt-repository ppa:openstack-ubuntu-testing/queens

bear in mind these are built per-commitish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs
--
If you run into any issues please report bugs using the ‘ubuntu-bug’ tool:

sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thank you to all who contributed to OpenStack Queens and Ubuntu Bionic both
upstream and in Debian/Ubuntu packaging!

Regards,
Corey
(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/queens_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack] OpenStack Queens for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team at Canonical is pleased to announce the general
availability of OpenStack Queens on Ubuntu 16.04 LTS via the Ubuntu Cloud
Archive. Details of the Queens release can be found at:
https://www.openstack.org/software/queens

To get access to the Ubuntu Queens packages:

Ubuntu 16.04 LTS


You can enable the Ubuntu Cloud Archive pocket for OpenStack Queens on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:queens
sudo apt update

The Ubuntu Cloud Archive for Queens includes updates for:

aodh, barbican, ceilometer, ceph (12.2.2), cinder, congress, designate,
designate-dashboard, dpdk (17.11), glance, glusterfs (3.13.2), gnocchi,
heat, heat-dashboard, horizon, ironic, keystone, libvirt (4.0.0), magnum,
manila, manila-ui, mistral, murano, murano-dashboard, networking-bagpipe,
networking-bgpvpn, networking-hyperv, networking-l2gw, networking-odl,
networking-ovn, networking-sfc, neutron, neutron-dynamic-routing,
neutron-fwaas, neutron-lbaas, neutron-lbaas-dashboard, neutron-taas,
neutron-vpnaas, nova, nova-lxd, openstack-trove, openvswitch (2.9.0),
panko, qemu (2.11), rabbitmq-server (3.6.10), sahara, sahara-dashboard,
senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar.

For a full list of packages and versions, please refer to [0].

Branch Package Builds
---
If you would like to try out the latest updates to branches, we deliver
continuously integrated packages on each upstream commit via the following
PPA’s:

   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
   sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
   sudo add-apt-repository ppa:openstack-ubuntu-testing/pike
   sudo add-apt-repository ppa:openstack-ubuntu-testing/queens

Reporting bugs
-
If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thanks to everyone who has contributed to OpenStack Queens, both upstream
and downstream!

Have fun and see you in Rocky!

Regards,
Corey
(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/queens_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Corey Bryant]

On Wed, Feb 21, 2018 at 9:35 AM, Thomas Goirand  wrote:

> Hi there!
>
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get help through this list.
>
> In here:
>
> heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/
> js/
>
> we have minified *only* versions of Javascript.
>
>
There's also a bug open for this:
https://bugs.launchpad.net/heat-dashboard/+bug/1747687

Regards,
Corey


> 1/ Why is there only minified versions? That's non-free to me, Debian,
> and probably any other distro caring about OpenStack.
> 2/ Why do we even have a folder called "vendors"? Doesn't this sound
> really a bad practice?
> 3/ Why is there so many angular-*.min.js files? Do we need them all?
> 4/ Why isn't the package using xstatic-angular and friends?
>
> As it stands, I can't upload heat-dashboard to Debian for Queens, and
> it's been removed from Horizon... :(
>
> Oh, and I almost forgot! When running unit tests, I get:
>
> PYTHON=python$i NOSE_WITH_OPENSTACK=1 \
> NOSE_OPENSTACK_COLOR=1 \
> NOSE_OPENSTACK_RED=0.05 \
> NOSE_OPENSTACK_YELLOW=0.025 \
> NOSE_OPENSTACK_SHOW_ELAPSED=1 \
> DJANGO_SETTINGS_MODULE=heat_dashboard.test.settings \
> python$i
> /home/zigo/sources/openstack/queens/services/heat-
> dashboard/build-area/heat-dashboard-1.0.2/manage.py
> test heat_dashboard.test --settings=heat_dashboard.test.settings
>
> No local_settings file found.
> Traceback (most recent call last):
>   File
> "/home/zigo/sources/openstack/queens/services/heat-
> dashboard/build-area/heat-dashboard-1.0.2/manage.py",
> line 23, in 
> execute_from_command_line(sys.argv)
>
> [ ... some stack dump ...]
>
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 147, in acquire
> self._do_open()
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 119, in _do_open
> self.lockfile = open(self.path, 'a')
> PermissionError: [Errno 13] Permission denied:
> '/usr/lib/python3/dist-packages/openstack_dashboard/
> local/_usr_lib_python3_dist-packages_openstack_dashboard_
> local_.secret_key_store.lock'
>
> What thing is attempting to write in my read only /usr, while Horizon is
> correctly installed, and writing its secret key material as it should,
> in /var/lib/openstack-dashboard? It's probably due to me, but here, how
> can I make heat-dashboard unit test behave during package build? What's
> this "No local_settings file found" thing? Other dashboards didn't
> complain in this way...
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

[Corey Bryant]

On Tue, Jan 23, 2018 at 8:44 AM, Lee Yarwood  wrote:

> A breif progress update in-line below.
>
> On 22-01-18 14:22:12, Lee Yarwood wrote:
> > Hello,
> >
> > With M3 and FF rapidly approaching this week I wanted to post a brief
> > overview of the QEMU native LUKS series.
> >
> > The full series is available on the following topic, I'll go into more
> > detail on each of the changes below:
> >
> > https://review.openstack.org/#/q/topic:bp/libvirt-qemu-
> native-luks+status:open
> >
> > libvirt: Collocate encryptor and volume driver calls
> > https://review.openstack.org/#/c/460243/ (Missing final +2 and +W)
> >
> > This refactor of the Libvirt driver connect and disconnect volume code
> > has the added benefit of also correcting a number of bugs around the
> > attaching and detaching of os-brick encryptors. IMHO this would be
> > useful in Queens even if the rest of the series doesn't land.
> >
> > libvirt: Introduce disk encryption config classes
> > https://review.openstack.org/#/c/464008/ (Missing final +2 and +W)
> >
> > This is the most straight forward change of the series and simply
> > introduces the required config classes to wire up native LUKS decryption
> > within the domain XML of an instance. Hopefully nothing controversial.
>
> Both of these have landed, my thanks to jaypipes for his reviews!
>
> > libvirt: QEMU native LUKS decryption for encrypted volumes
> > https://review.openstack.org/#/c/523958/ (Missing both +2s and +W)
> >
> > This change carries the bulk of the implementation, wiring up encrypted
> > volumes during their initial attachment. The commit message has a
> > detailed run down of the various upgrade and LM corner cases we attempt
> > to handle here, such as LM from a P to Q compute, detaching a P attached
> > encrypted volume after upgrading to Q etc.
>
> Thanks to melwitt and mdbooth for your reviews! I've respun to address
> the various nits and typos pointed out in this change. Ready and waiting
> to respin again if any others crop up.
>
> > Upgrade and LM testing is enabled by the following changes:
> >
> > fixed_key: Use a single hardcoded key across devstack deployments
> > https://review.openstack.org/#/c/536343/
> >
> > compute: Introduce an encrypted volume LM test
> > https://review.openstack.org/#/c/536177/
> >
> > This is being tested by tempest-dsvm-multinode-live-migration and
> > grenade-dsvm-neutron-multinode-live-migration in the following DNM Nova
> > change, enabling volume backed LM tests:
> >
> > DNM: Test LM with encrypted volumes
> > https://review.openstack.org/#/c/536350/
> >
> > Hopefully that covers everything but please feel free to ping if you
> > would like more detail, background etc. Thanks in advance,
>
> grenade-dsvm-neutron-multinode-live-migration is currently failing due
> to our use of the Ocata UCA on stable/pike leading to the following
> issue with the libvirt 2.5.0 build it provides:
>
> libvirt 2.5.0-3ubuntu5.6~cloud0 appears to be compiled without gnutls
> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1744758
>
>
Hey Lee,

We have a new version of libvirt in ocata-proposed now that should fix your
issue and is ready for testing. Thanks for your work on this and for
opening the bug.

Corey

I've cherry-picked the following devstack change back to stable/pike and
> pulled it into the test change above for Nova, hopefully working around
> these failures:
>
> Update to using pike cloud-archive
> https://review.openstack.org/#/c/536798/
>
> tempest-dsvm-multinode-live-migration is also failing but AFAICT they
> are unrelated to this overall series and appear to be more generic
> volume backed live migration failures.
>
> Thanks again!
>
> Lee
> --
> Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> 2D76
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [snaps] proposing Pete Vander Giessen for snaps-core and snaps-release group membership

[Corey Bryant]

On Mon, Aug 14, 2017 at 4:27 PM, Ryan Beisner 
wrote:

> Hi Snappers
>
> I'm writing to propose Pete Vander Giessen to the *snaps-core* and
> *snaps-release* groups.  Pete has done a good bit of work in OpenStack
> Snaps, particularly snap testing and CI tooling.  I feel he would add a lot
> of value to the general dev/review process, as well as to the release
> processes.
>
> Cheers,
>
> Ryan
>

Definitely a +2 from me. Pete has been providing solid reviews for a while
now. Pete is also leading snap testing/CI/CD, and has been contributing
significantly to these efforts.

Thanks,
Corey
__
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] [snaps] proposing David Ames for snaps-core and snaps-release group membership

[Corey Bryant]

On Mon, Aug 14, 2017 at 4:22 PM, Ryan Beisner 
wrote:

> Hi Snappers
>
> I'm writing to propose David Ames to the *snaps-core* and *snaps-release*
> groups.  David has done a good bit of work in OpenStack Snaps.  I feel he
> would add a lot of value to the general dev/review process, as well as to
> the release processes.
>
> Cheers,
>
> Ryan
>
>
Definitely a +2 from me. David is an excellent reviewer, providing solid
reviews to the snaps themselves. He also has a perspective that is very
useful in that he has been working on enabling snaps in the OpenStack
charms.

Thanks,
Corey
__
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] [charms] Onboarding session at next weeks summit

[Corey Bryant]

I'll be there as well. Looking forward to seeing everyone and meeting some
new folks.

Corey

On Tue, May 2, 2017 at 6:36 AM, James Page  wrote:

> Hi All
>
> The OpenStack summit is nearly upon us and for this summit we're running a
> project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
> details) for anyone who wants to get started either using the OpenStack
> Charms or contributing to the development of the Charms,
>
> The majority of the core development team will be present so its a great
> opportunity to learn more about our project from a use and development
> perspective!
>
> I've created an etherpad at [1] so if you're intending on coming along,
> please put your name down with some details on what you would like to get
> out of the session.
>
> Cheers
>
> James
>
> [0] http://tiny.cc/onhwky
> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [snaps] proposing Dmitrii Shcherbakov for core review team

[Corey Bryant]

On Wed, Mar 22, 2017 at 11:02 AM, James Page  wrote:

> Hi Snappers
>
> Dmitrii did some good work on the ceilometer snap and has been providing
> reviews and feedback of other changes in the queue over the last few months
> as well has hanging out and being a sounding board/answering questions in
> #openstack-snaps.
>
> He's also working out how to get libvirt functional in a snap (no mean
> feat).
>
> I'd like to propose Dmitrii to the snaps core reviewers team.
>
> Cheers
>
> James
>
>
+1

I have full confidence in Dmitrii.  He's already a great asset to snaps and
will be great to have as a core reviewer.

Corey
__
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] [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud archive ocata repo bust

[Corey Bryant]

On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang 
wrote:

> Kolla deploy ubuntu gate is red now. here is the related bug[0].
>
> libvirt failed to access the console.log file when booting instance. After
> made some debugging, i got following.
>
>
Jeffrey,  This is likely fixed in ocata-proposed and should be promoted to
ocata-updates soon after testing completes.
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667033.

Corey


# how console.log works
> nova create a empty console.log with nova:nova ( this is another bug
> workaround actually[1]), then libvirt ( running with root ) will change the
> file owner to qemu process user/group ( configured by dynamic_ownership ).
> Now qemu process can write logs into this file.
>
> # what's wrong now
> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to write
> logs into console.log file
>
> # other test
>
> * ubuntu + fallback libvirt 1.3.x works [2]
> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to
>   nova:nova works, too.[3]
> * centos + libvirt 2.0.0 works, never saw such issue in centos.
>
> # conclusion
> I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership
>
>
> [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654
> [1] https://github.com/openstack/nova/blob/master/
> nova/virt/libvirt/driver.py#L2922,L2952
> [2] https://review.openstack.org/442673
> [3] https://review.openstack.org/442850
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.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
>
>
__
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] [deployment][snaps][ansible][puppet][charms] OpenStack snaps delivery strategy

[Corey Bryant]

On Thu, Mar 2, 2017 at 10:57 AM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Adding the [deployment] tag as the catch-all for deployment projects as I
> think they’d be interested.
>
>
>
>
>
Ah thanks Jesse, appreciate that.  I didn't realize that tag existed.

Corey
__
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] [snaps][ansible][puppet][charms] OpenStack snaps delivery strategy

[Corey Bryant]

Hi All,

I'm working to get a strategy in place for delivery of OpenStack snaps.
Below I've outlined an initial strategy, and I'd like to get your input.

I'm particularly interested in input from snap folks of course, but also
from projects that install OpenStack and may want to be involved in snap
CI/gating (ie. Ansible, Puppet, Charms, etc).


First a quick background of snaps, tracks, channels, and versions (skip to
"Strategy" if you're already familiar with these concepts):

Snaps
-
If you're not familiar with OpenStack snaps, see James Pages' intro at:
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109743.html
And if you'd like to just tip your toes in the water quickly, you can give
the openstackclients snap a try:
https://javacruft.wordpress.com/2017/02/03/snap-install-openstackclients/

Tracks
-
Snaps have the concept of tracks, which allow for publishing different
series of software (ie. newton, ocata, pike would be separate tracks). In
each track, you can publish a snap to any of the 4 channels based on how
stable it is.

Channels
-
Snaps can be published to 4 different channels:
* edge:  for your most recent changes, probably untested
* beta:  used to provide preview releases of tested changes
* candidate:  used to vet uploads that should require no further code
changes before moving to stable
* stable:  what most users will consume, stable and tested

Version
--
Snaps include metadata where the software version can be specified.

For more details on tracks, channels, and versions, see:
https://snapcraft.io/docs/reference/channels


Strategy
---
Ok on to the strategy. Below I've outlined a proposed strategy for
delivering snaps to the 4 different channels based on the level of testing
they've undergone. Long-term we'd like to see the majority of this process
automated, therefore the strategy I describe here is the end goal (and
hence my overuse of "auto-").

Track Strategy

pike:  auto-publish to pike channels according to channel strategy
ocata -> latest [0]:  auto-publish to latest (ocata) channels according to
channel strategy
newton: auto-publish to newton channels according to channel strategy
mitaka: auto-publish to mitaka channels according to channel strategy
[0] The 'latest' track is the default for users when they install a snap.
Therefore the 'latest' track will always include the latest stable release.

New repo in support of channel strategy
-
snap-releases:
In order to enable channel testing, and publishing, of a known good set of
snaps across OpenStack projects, I'd like to create a new 'snap-releases'
repo. This would be a simple repo of yaml mappings, similar to [1], that
would contain the current tracks/channels/versions for candidate and stable
channels. For example, the snap-releases/ocata/cinder file may have
'candidate: 9.1.1' and 'stable: 9.0.0'.
[1] https://github.com/openstack/releases/tree/master/deliverables

Channel Strategy
-
edge: each snap is auto-published to edge on every upstream commit
1) edge stage is triggered by each new upstream commit
2) version field is auto-populated with short git hash or pbr version
3) auto-publish snap to edge channel
notes:
* unit tests will have already passed on upstream gate by this time and
prior to all future stages (and snaps don't apply any new patches)
* voting projects may want to vote more often than beta releases but voting
on every edge update seems overboard; they could also vote on individual
snap repo changes but they may be seldom.

beta: each snap is auto-published to beta on every upstream stable point
release or development milestone
1) beta stage is triggered by new upstream release tar, e.g. cinder newton
watches for 9.x.x
2) version field auto-populated with release version, e.g. for cinder,
version=9.1.1
3) auto-open launchpad bug for SRU (stable release update)
4) auto-publish snap to beta channel
5) auto-propose snap-releases gerrit review to change candidate version;
for example:
- candidate: 9.0.0, stable: 9.0.0
+ candidate: 9.1.1, stable: 9.0.0
6) voting projects smoke test, and vote, with this snap from beta, and all
other snaps from candidate
7) SRU bug auto-updated with results of review
8) human interaction required if tests fail and may require fixed snap to
be re-published

candidate: each snap is auto-published to candidate after successful
testing of beta
1) candidate stage is triggered when snap-releases gerrit review for
candidate is merged
2) auto-publish snap to candidate channel
3) SRU bug tagged with verification-needed
4) auto-propose snap-releases gerrit review to change stable version; for
example:
- candidate: 9.1.1, stable: 9.0.0
+ candidate: 9.1.1, stable: 9.1.1
5) voting projects run, and vote, with this snap from candidate, and all
other snaps from stable
6) SRU bug auto-tagged verification-done or verfication-failed based on

[openstack-dev] [Openstack] OpenStack Ocata for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team at Canonical is pleased to announce the general
availability of OpenStack Ocata on Ubuntu 16.04 LTS via the Ubuntu Cloud
Archive. Ocata is the latest release of OpenStack and the first in the new
OpenStack release cadence, with a focus on stabilization of existing
features along with usability improvements. Details of the Ocata release
can be found at:  https://www.openstack.org/software/ocata

To get access to the Ubuntu Ocata packages:

Ubuntu 16.04 LTS



You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:ocata

sudo apt update

The Ubuntu Cloud Archive for Ocata includes updates for:

aodh, barbican, ceilometer, cinder, congress, designate,
designate-dashboard, dpdk (16.11), glance, gnocchi, heat, horizon, ironic,
libvirt (2.5.0), keystone, magnum, manila, manila-ui, mistral, murano,
murano-dashboard, networking-ovn, networking-sfc, neutron,
neutron-dynamic-routing, neutron-fwaas, neutron-lbaas,
neutron-lbaas-dashboard, nova, nova-lxd, openstack-trove, panko, qemu
(2.8), sahara, sahara-dashboard, senlin, swift, trove-dashboard, watcher
and zaqar

For a full list of packages and versions, please refer to [0].

Migration considerations



* API’s now running under apache2 with mod_wsgi

In Ocata we’ve updated the following APIs to run under apache2 with
mod_wsgi: aodh-api, barbican-api, ceilometer-api, cinder-api, and the
nova-placement-api. Please keep this in mind as the packages will no longer
install systemd unit files for these services, and will instead install
apache2 with corresponding apache2 site configuration.

* libvirt 2.5.0 changes

In this release of libvirt, the libvirt-bin systemd service has been
renamed to libvirtd, and the unix_sock_group has changed from libvirtd to
libvirt.

* openstack-dashboard changes

In Ocata we’ve moved static assets from
/usr/share/openstack-dashboard/static to
/var/lib/openstack-dashboard/static.

Known Issues

---

nova console log is empty with libvirt 2.5.0:
https://bugs.launchpad.net/bugs/1667033

Branch Package Builds

---

If you would like to try out the latest updates to branches, we deliver
continuously integrated packages on each upstream commit via the following
PPA’s:

  sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

  sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

  sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

  sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata

Reporting bugs

-

If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thanks to everyone who has contributed to OpenStack Ocata, both upstream
and downstream.  And special thanks to the puppet modules team for their
continued early testing of OpenStack development releases.

Have fun and see you in Pike!

Regards,

Corey

(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Thu, Feb 16, 2017 at 1:30 AM, Chen CH Ji  wrote:

> Should be this one https://bugs.launchpad.net/nova/+bug/1664913 and
> *https://review.openstack.org/434179*
>  ?
>
> Hey Kevin, sorry I didn't notice your patch/bug.  It looks like this is on
it's way to getting merged:  https://review.openstack.org/#/c/434533
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 4:34 PM, Corey Bryant <corey.bry...@canonical.com>
wrote:

>
> On Wed, Feb 15, 2017 at 4:26 PM, melanie witt <melwi...@gmail.com> wrote:
>
>> On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
>>
>>> This works but you have to specify all of the args (--cell_uuid, --name,
>>> --transport-url and --database_connection).  Otherwise you'll hit
>>> this: http://paste.ubuntu.com/24003055/
>>>
>>
>> Corey,
>>
>> Thanks for pointing that out.
>>
>> It looks like the command intended to have --transport-url and
>> --database_connection as optional but missed defaulting them to None in the
>> function parameter list.
>>
>> -melanie
>
>
> I think I figured it out.  I'll submit a patch in a little bit.
>
>
>
You're correct btw :)


-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 4:26 PM, melanie witt <melwi...@gmail.com> wrote:

> On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
>
>> This works but you have to specify all of the args (--cell_uuid, --name,
>> --transport-url and --database_connection).  Otherwise you'll hit
>> this: http://paste.ubuntu.com/24003055/
>>
>
> Corey,
>
> Thanks for pointing that out.
>
> It looks like the command intended to have --transport-url and
> --database_connection as optional but missed defaulting them to None in the
> function parameter list.
>
> -melanie


I think I figured it out.  I'll submit a patch in a little bit.

-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 10:20 AM, Dan Smith  wrote:

> > The problem is there's no way to update an existing cell's transport_url
> > via nova-manage.
>
> There is:
>
> https://review.openstack.org/#/c/431582/


Dan,

This works but you have to specify all of the args (--cell_uuid, --name,
--transport-url and --database_connection).  Otherwise you'll hit this:
http://paste.ubuntu.com/24003055/

-- 
Regards,
Corey


>
>
> > It appears the only way to get around this is manually deleting the old
> > cell1 record from the db.
>
> No, don't do that :)
>
> > I'd like to hear more opinions on this but it really seems like this
> > should be a priority to fix prior to the Ocata final release.
>
> Already done!
>
> --Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Corey Bryant]

On Wed, Feb 15, 2017 at 7:42 AM, Thomas Goirand  wrote:

> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
>
Thanks for all of your work, Thomas.  Wishing you the best.

For others following along, we do have up-to-date versions of these
packages in Ocata for Ubuntu.  For a full reports of packages please see:
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html


> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.


> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>
> __
> 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
>



-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

On Wed, Feb 15, 2017 at 10:20 AM, Dan Smith  wrote:

> > The problem is there's no way to update an existing cell's transport_url
> > via nova-manage.
>
> There is:
>
> https://review.openstack.org/#/c/431582/
>
> > It appears the only way to get around this is manually deleting the old
> > cell1 record from the db.
>
> No, don't do that :)
>
> > I'd like to hear more opinions on this but it really seems like this
> > should be a priority to fix prior to the Ocata final release.
>
> Already done!
>
>
Awesome thanks!

-- 
Regards,
Corey
__
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] [nova] scaling rabbitmq with cells v2 requires manual database update

[Corey Bryant]

Hi all,

Cells v2 in Ocata requires manual database updates each time you scale
rabbitmq.  In my opinion this is a pretty significant regression.  Prior to
cells v2 (no cells) rabbitmq could be scaled without manual database
updates.

The problem is there's no way to update an existing cell's transport_url
via nova-manage.

If you run 'nova-manage cell_v2 create_cell --name cell1' a second time,
the database ends up with two cell1 db records.

It appears the only way to get around this is manually deleting the old
cell1 record from the db.

More details are in the bug at:  https://bugs.launchpad.net/bugs/1664759

I'd like to hear more opinions on this but it really seems like this should
be a priority to fix prior to the Ocata final release.

-- 
Regards,
Corey
__
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] [Openstack] OpenStack Ocata B2 for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of the OpenStack Ocata B2 milestone in Ubuntu 16.04 LTS via the Ubuntu
Cloud Archive.

Ubuntu 16.04 LTS



You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:ocata

sudo apt update

The Ubuntu Cloud Archive for Ocata includes updates for:

aodh (commit 5363ff85), barbican, ceilometer (commit aa3f491bb), cinder,
congress, designate, designate-dashboard, glance, heat, horizon (commit
158a4c1a), keystone, libvirt (2.5.0), manila, mistral, networking-ovn,
neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas (commit 47c217e4),
nova, openstack-trove, panko (1.0.0), qemu (2.6.1), sahara, senlin, swift
(2.12.0), watcher (0.33.0), and zaqar.

For a full list of packages and versions, please refer to [0].

API’s now running under apache2 with mod_wsgi

--

In this milestone we’ve updated the following APIs to run under apache2
with mod_wsgi: aodh-api, barbican-api, ceilometer-api, cinder-api, and
nova-placement-api.

Please keep this in mind as the packages will no longer install systemd
unit files for these services, and will instead install apache2 with
corresponding apache2 sites.

libvirt 2.5.0 changes

---

In this release of libvirt, the libvirt-bin systemd service has been
renamed to libvirtd, and the unix_sock_group has changed from libvirtd to
libvirt.

Branch Package Builds

---

If you would like to try out the latest updates to branches, we are
delivering continuously integrated packages on each upstream commit via the
following PPA’s:

  sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

  sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

  sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

  sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata

Reporting bugs

-

If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

 sudo ubuntu-bug nova-conductor

Thanks to all who have contributed thus far to OpenStack Ocata, both
upstream and downstream.  And special thanks to the puppet modules team for
their continued early testing of Ocata.

Have fun!

Regards,

Corey

(on behalf of the Ubuntu OpenStack team)

[0] http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-
archive/ocata_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] CI status for Ubuntu

[Corey Bryant]

On Fri, Jan 20, 2017 at 6:34 PM, Alex Schultz  wrote:

> Just FYI,
>
> We switched the Ubuntu scenario jobs to non-voting this week due to
> the large amount of breakage caused by the ocata-proposed update to m2
> based packages.  The Ubuntu beaker jobs are still voting on the
> modules themselves.
>
> Here's where we're keeping track of issues:
>
> https://etherpad.openstack.org/p/puppet-ubuntu-ocata-m2
>
> So if anyone wants to jump in and help that would be great.  We
> addressed the libvirt, ceilometer and aodh issues. Still outstanding
> as of now are items related to the webob 1.7, designate mdns failure
> and python-gabbi missing for tempest.  There might be more issues, but
> this is what we're aware of at the moment.
>
> Thanks,
> -Alex
>
>
>
Alex, I just wanted to make sure webob is no longer an issue for you now.
It should be ok now that we're at version 1:1.6.2-2.

-- 
Regards,
Corey
__
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] [keystone] [nova] [glance] [oslo] webob 1.7

[Corey Bryant]

On Thu, Jan 19, 2017 at 9:50 PM, Corey Bryant <corey.bry...@canonical.com>
wrote:

>
>
> On Thu, Jan 19, 2017 at 8:29 PM, Joshua Harlow <harlo...@fastmail.com>
> wrote:
>
>> Corey Bryant wrote:
>>
>>>
>>> Added [nova] and [oslo] to the subject.  This is also affecting nova and
>>> oslo.middleware.  I know Sean's initial response on the thread was that
>>> this shouldn't be a priority for ocata but we're completely blocked by
>>> it.  Would those teams be able to prioritize a fix for this?
>>>
>>>
>> Is this the issue for that https://github.com/Pylons/webob/issues/307 ?
>>
>>
> Yes, at least for glance that is part of the issue, the dropping of the
> http_method_probably_has_body check.
>
>
>> If so, then perhaps we need to comment and work together on that and
>> introduce a fix into webob? Would that be the correct path here? What
>> otherwise would be needed to 'prioritize a fix' for it?
>>
>>
> That doesn't appear to be a bug in webob from what I can see in the issue
> 307 discussion, just a change of behavior that various projects need to
> adapt to if they're going to support webob 1.7.x.
>
>
>
Debian just uploaded python-webob 1:1.6.2-2 to replace 1.7.0-1.  I didn't
know this was an option, so I apologize for the noise.  Thanks to those who
already started on patches.  I imagine they'll be needed in Pike.  We'll
get 1:1.6.2-2 synced over to zesty and that should solve our webob problems
in Ocata.

-- 
Regards,
Corey
__
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] [keystone] [nova] [glance] [oslo] webob 1.7

[Corey Bryant]

On Thu, Jan 19, 2017 at 8:29 PM, Joshua Harlow <harlo...@fastmail.com>
wrote:

> Corey Bryant wrote:
>
>>
>> Added [nova] and [oslo] to the subject.  This is also affecting nova and
>> oslo.middleware.  I know Sean's initial response on the thread was that
>> this shouldn't be a priority for ocata but we're completely blocked by
>> it.  Would those teams be able to prioritize a fix for this?
>>
>>
> Is this the issue for that https://github.com/Pylons/webob/issues/307 ?
>
>
Yes, at least for glance that is part of the issue, the dropping of the
http_method_probably_has_body check.


> If so, then perhaps we need to comment and work together on that and
> introduce a fix into webob? Would that be the correct path here? What
> otherwise would be needed to 'prioritize a fix' for it?
>
>
That doesn't appear to be a bug in webob from what I can see in the issue
307 discussion, just a change of behavior that various projects need to
adapt to if they're going to support webob 1.7.x.

-- 
Regards,
Corey
__
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] [keystone] [nova] [glance] [oslo] webob 1.7

[Corey Bryant]

On Thu, Jan 19, 2017 at 11:34 AM, Corey Bryant <corey.bry...@canonical.com>
wrote:

>
>
> On Thu, Jan 19, 2017 at 10:46 AM, Ian Cordasco <sigmaviru...@gmail.com>
> wrote:
>
>> -----Original Message-
>> From: Corey Bryant <corey.bry...@canonical.com>
>> Reply: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Date: January 19, 2017 at 08:52:25
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject:  Re: [openstack-dev] [keystone] webob 1.7
>>
>> > On Wed, Jan 18, 2017 at 9:08 AM, Ian Cordasco
>> > wrote:
>> >
>> > > -Original Message-
>> > > From: Chuck Short
>> > > Reply: OpenStack Development Mailing List (not for usage questions)
>> > >
>> > > Date: January 18, 2017 at 08:01:46
>> > > To: OpenStack Development Mailing List
>> > > Subject: [openstack-dev] [keystone] webob 1.7
>> > >
>> > > > Hi
>> > > >
>> > > > We have been expericing problems with newer versions of webob (webob
>> > > 1.7).
>> > > > Reading the changelog, it seems that the upstream developers have
>> > > > introduced some backwards incompatibility with previous versions of
>> webob
>> > > > that seems to be hitting keystone and possibly other projects as
>> well
>> > > > (nova/glance in particular). For keystone this bug has been
>> reported in
>> > > bug
>> > > > #1657452. I would just like to get more developer's eyes on this
>> > > particular
>> > > > issue and possibly get a fix. I suspect its starting to hit other
>> distros
>> > > > as well or already have hit.
>> > >
>> > > Hey Chuck,
>> > >
>> > > This is also affecting Glance
>> > > (https://bugs.launchpad.net/glance/+bug/1657459). I suspect what
>> we'll
>> > > do for now is blacklist the 1.7.x releases in openstack/requirements.
>> > > It seems a bit late in the cycle to bump the minimum version to 1.7.0
>> > > so we can safely fix this without having to deal with
>> > > incompatibilities between versions.
>> > >
>> > > --
>> > > Ian Cordasco
>> > >
>> > > 
>> __
>> > > OpenStack Development Mailing List (not for usage questions)
>> > > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > >
>> >
>> > Hi Ian,
>> >
>> > Were you suggesting there's a new version of webob in the works that
>> fixes
>> > this so we could bump upper-constraints and blacklist 1.7.x?
>>
>> No. I was suggesting that OpenStack not try to work with the 1.7
>> series of WebOb.
>>
>>
> Ok
>
>
>> > Unfortunately at this point we're at webob 1.7.0 in Ubuntu and there's
>> no
>> > going backward for us. The corresponding bugs were already mentioned in
>> > this thread but worth noting again, these are the bugs tracking this:
>> >
>> > https://bugs.launchpad.net/nova/+bug/1657452
>> > https://bugs.launchpad.net/glance/+bug/1657459
>> >
>> > So far this affects nova, glance, and keystone (David has a patch in
>> review
>> > - https://review.openstack.org/#/c/422234/).
>>
>> I'll have to see if we can get that prioritized for Glance next week
>> as a bug fix candidate post Ocata-3. We decided our priorities for the
>> next week just a short while ago. I'm going to see if we can move it
>> onto this week's list though.
>>
>>
> Thanks, that would be great.
>
>
>
Added [nova] and [oslo] to the subject.  This is also affecting nova and
oslo.middleware.  I know Sean's initial response on the thread was that
this shouldn't be a priority for ocata but we're completely blocked by it.
Would those teams be able to prioritize a fix for this?

-- 
Regards,
Corey
__
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] [keystone] webob 1.7

[Corey Bryant]

On Thu, Jan 19, 2017 at 10:46 AM, Ian Cordasco <sigmaviru...@gmail.com>
wrote:

> -Original Message-
> From: Corey Bryant <corey.bry...@canonical.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: January 19, 2017 at 08:52:25
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [keystone] webob 1.7
>
> > On Wed, Jan 18, 2017 at 9:08 AM, Ian Cordasco
> > wrote:
> >
> > > -Original Message-
> > > From: Chuck Short
> > > Reply: OpenStack Development Mailing List (not for usage questions)
> > >
> > > Date: January 18, 2017 at 08:01:46
> > > To: OpenStack Development Mailing List
> > > Subject: [openstack-dev] [keystone] webob 1.7
> > >
> > > > Hi
> > > >
> > > > We have been expericing problems with newer versions of webob (webob
> > > 1.7).
> > > > Reading the changelog, it seems that the upstream developers have
> > > > introduced some backwards incompatibility with previous versions of
> webob
> > > > that seems to be hitting keystone and possibly other projects as well
> > > > (nova/glance in particular). For keystone this bug has been reported
> in
> > > bug
> > > > #1657452. I would just like to get more developer's eyes on this
> > > particular
> > > > issue and possibly get a fix. I suspect its starting to hit other
> distros
> > > > as well or already have hit.
> > >
> > > Hey Chuck,
> > >
> > > This is also affecting Glance
> > > (https://bugs.launchpad.net/glance/+bug/1657459). I suspect what we'll
> > > do for now is blacklist the 1.7.x releases in openstack/requirements.
> > > It seems a bit late in the cycle to bump the minimum version to 1.7.0
> > > so we can safely fix this without having to deal with
> > > incompatibilities between versions.
> > >
> > > --
> > > 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
> > >
> >
> > Hi Ian,
> >
> > Were you suggesting there's a new version of webob in the works that
> fixes
> > this so we could bump upper-constraints and blacklist 1.7.x?
>
> No. I was suggesting that OpenStack not try to work with the 1.7
> series of WebOb.
>
>
Ok


> > Unfortunately at this point we're at webob 1.7.0 in Ubuntu and there's no
> > going backward for us. The corresponding bugs were already mentioned in
> > this thread but worth noting again, these are the bugs tracking this:
> >
> > https://bugs.launchpad.net/nova/+bug/1657452
> > https://bugs.launchpad.net/glance/+bug/1657459
> >
> > So far this affects nova, glance, and keystone (David has a patch in
> review
> > - https://review.openstack.org/#/c/422234/).
>
> I'll have to see if we can get that prioritized for Glance next week
> as a bug fix candidate post Ocata-3. We decided our priorities for the
> next week just a short while ago. I'm going to see if we can move it
> onto this week's list though.
>
>
Thanks, that would be great.

-- 
Regards,
Corey
__
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] [keystone] webob 1.7

[Corey Bryant]

On Wed, Jan 18, 2017 at 9:08 AM, Ian Cordasco 
wrote:

> -Original Message-
> From: Chuck Short 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: January 18, 2017 at 08:01:46
> To: OpenStack Development Mailing List 
> Subject:  [openstack-dev] [keystone] webob 1.7
>
> > Hi
> >
> > We have been expericing problems with newer versions of webob (webob
> 1.7).
> > Reading the changelog, it seems that the upstream developers have
> > introduced some backwards incompatibility with previous versions of webob
> > that seems to be hitting keystone and possibly other projects as well
> > (nova/glance in particular). For keystone this bug has been reported in
> bug
> > #1657452. I would just like to get more developer's eyes on this
> particular
> > issue and possibly get a fix. I suspect its starting to hit other distros
> > as well or already have hit.
>
> Hey Chuck,
>
> This is also affecting Glance
> (https://bugs.launchpad.net/glance/+bug/1657459). I suspect what we'll
> do for now is blacklist the 1.7.x releases in openstack/requirements.
> It seems a bit late in the cycle to bump the minimum version to 1.7.0
> so we can safely fix this without having to deal with
> incompatibilities between versions.
>
> --
> 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
>

Hi Ian,

Were you suggesting there's a new version of webob in the works that fixes
this so we could bump upper-constraints and blacklist 1.7.x?

Unfortunately at this point we're at webob 1.7.0 in Ubuntu and there's no
going backward for us.  The corresponding bugs were already mentioned in
this thread but worth noting again, these are the bugs tracking this:

https://bugs.launchpad.net/nova/+bug/1657452
https://bugs.launchpad.net/glance/+bug/1657459

So far this affects nova, glance, and keystone (David has a patch in review
- https://review.openstack.org/#/c/422234/).

-- 
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] OpenStack Ocata B1 for Ubuntu 16.04 LTS

[Corey Bryant]

On Thu, Dec 1, 2016 at 9:31 PM, Jeffrey Zhang 
wrote:

> Cool. And Kolla has upgrade ubuntu repo to b1 in master branch.
>
> btw, if there is any way or help doc for proposing a new package into
> ubuntu-cloud-archive? like kolla.
>
>
>
Hi Jeffrey,

There's currently no kolla package in debian or ubuntu so it would need to
be started from scratch.  If you were to provide a quality package and
support for it I'd be happy to sponsor your uploads into ubuntu and the
cloud archive.

I can give you more pointers but as a starter here's where we host our
package source:
https://code.launchpad.net/~ubuntu-server-dev/+git

-- 
Regards,
Corey
__
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] [Openstack] OpenStack Ocata B1 for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,


The Ubuntu OpenStack team is pleased to announce the general availability
of the OpenStack Ocata B1 milestone in Ubuntu 16.04 LTS via the Ubuntu
Cloud Archive.


Ubuntu 16.04 LTS




You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
Ubuntu 16.04 installations by running the following commands:


echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
xenial-updates/ocata main" | sudo tee /etc/apt/sources.list.d/ocata-uca.list

sudo apt install -y ubuntu-cloud-keyring

sudo apt update


The Ubuntu Cloud Archive for Ocata includes updates for: cinder, glance,
horizon, keystone, manila, networking-ovn, neutron, neutron-fwaas,
neutron-lbaas, neutron-dynamic-routing, nova, openstack-trove, and swift
(2.11.0).


You can check out the full list of packages and versions at [0].


Branch Package Builds

---


If you want to try out the latest updates to stable branches, we are
delivering continuously integrated packages on each upstream commit via the
following PPA’s:


   sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

   sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata


bear in mind these are built per-commit-ish (30 min checks for new commits
at the moment) so ymmv from time-to-time.


Reporting bugs

-


Any issues please report bugs using the 'ubuntu-bug' tool:


  sudo ubuntu-bug nova-conductor


this will ensure that bugs get logged in the right place in Launchpad.


Thanks and have fun!


Regards,

Corey

(on behalf of the Ubuntu OpenStack team)


[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Newton for Ubuntu 16.04 LTS and Ubuntu 16.10

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of OpenStack Newton, available in today’s release of Ubuntu 16.10 (Yakkety
Yak) [0] and also available for Ubuntu 16.04 LTS (Xenial Xerus) via the
Ubuntu Cloud Archive.

Ubuntu 16.04 LTS



You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
Ubuntu 16.04 installations by running the following commands:

  sudo add-apt-repository cloud-archive:newton

  sudo apt update

The Ubuntu Cloud Archive for Newton includes updates for: Aodh, Barbican,
Ceilometer, Cinder, Congress, Designate, DPDK (16.07), Glance, Gnocchi,
Heat, Horizon, Ironic (6.2.1), Keystone, Magnum, Manila, Mistral, Murano,
Networking-L2GW, Networking-ODL, Networking-OVN, Networking-SFC, Neutron,
Neutron-Dynamic-Routing, Neutron-FWaaS, Neutron-LBaaS, Neutron-TaaS,
Neutron-VPNaaS, Nova, Nova-LXD, OpenvSwitch (2.6.0), Sahara, Senlin, Swift
(2.10.0), Trove, and Zaqar.

You can see the full list of packages and versions at [1].

Ubuntu 16.10

--

No extra steps required; just start installing OpenStack!

Branch Package Builds

---

If you want to try out the latest updates to stable branches, we are
delivering continuously integrated packages on each upstream commit in the
following PPA’s:

  sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

  sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

  sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

bear in mind these are built per-commitish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs



Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thank you to all who contributed to OpenStack Newton both upstream and in
Debian/Ubuntu packaging!

Regards,

Corey

(on behalf of the Ubuntu OpenStack team)

[0] https://wiki.ubuntu.com/YakketyYak/ReleaseNotes

[1]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack] OpenStack Newton B3 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of OpenStack Newton B3 milestone in Ubuntu 16.10 and for Ubuntu 16.04 LTS
via the Ubuntu Cloud Archive.

Ubuntu 16.04 LTS

You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:newton
sudo apt update

The Ubuntu Cloud Archive for Newton includes updates for Aodh, Barbican,
Ceilometer, Cinder, Designate, Glance, Heat, Horizon, Ironic (6.1.0),
Keystone, Manila, Networking-OVN, Neutron, Neutron-FWaaS, Neutron-LBaaS,
Neutron-VPNaaS, Nova, and Trove.

You can see the full list of packages and versions at [0].

Ubuntu 16.10
--
No extra steps required; just start installing OpenStack!

Branch Package Builds
---
If you want to try out the latest master branch updates, or updates to
stable branches, we are delivering continuously integrated packages on each
upstream commit in the following PPA’s:

   sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

bear in mind these are built per-commitish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thanks and have fun!

Regards,

Corey
(on behalf of the Ubuntu OpenStack team)

[0] http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-
archive/newton_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack] OpenStack Newton B2 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of OpenStack Newton B2 milestone in Ubuntu 16.10 and for Ubuntu 16.04 LTS
via the Ubuntu Cloud Archive.

Ubuntu 16.04 LTS


You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:newton
sudo apt update

The Ubuntu Cloud Archive for Newton includes updates for Barbican,
Ceilometer, Cinder, Congress, Designate, Glance, Heat, Horizon, Ironic
(6.0.0), Keystone, Manila, Murano, Murano-Agent, Neutron, Neutron-FWaaS,
Neutron-LBaaS, Neutron-VPNaaS, Nova, Sahara, Senlin, Trove, Swift (2.9.0),
and Zaqar.

You can see the full list of packages and versions at [0].

Ubuntu 16.10


No extra steps required; just start installing OpenStack!

Branch Package Builds
-

If you want to try out the latest master branch updates, or updates to
stable branches, we are maintaining continuously integrated packages in the
following PPA’s:

   sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

bear in mind these are built per-commitish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs
--

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thanks and have fun!

Cheers,

Corey
(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.html


-- 
Regards,
Corey
__
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] [Openstack] OpenStack Newton B1 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team is pleased to announce the general availability
of the OpenStack Newton B1 milestone in Ubuntu 16.10 and for Ubuntu 16.04
LTS via the Ubuntu Cloud Archive.

Ubuntu 16.04 LTS


You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
Ubuntu 16.04 installations by running the following commands:

echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
xenial-updates/newton main" | sudo tee
/etc/apt/sources.list.d/newton-uca.list
sudo apt-get install -y ubuntu-cloud-keyring
sudo apt-get update

The Ubuntu Cloud Archive for Newton includes updates for Cinder, Designate,
Glance, Heat, Horizon, Keystone, Manila, Neutron, Neutron-FWaaS,
Neutron-LBaaS, Neutron-VPNaaS, Nova, and Swift (2.8.0).

You can check out the full list of packages and versions at [0].

Ubuntu 16.10
--

No extra steps required; just start installing OpenStack!

Branch Package Builds
---

We’ve resurrected the branch package builds of OpenStack projects that we
had in place a while back - if you want to try out the latest master branch
updates, or updates to stable branches, the following PPA’s are now
up-to-date and maintained:

   sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

bear in mind these are built per-commit-ish (30 min checks for new commits
at the moment) so ymmv from time-to-time.

Reporting bugs
-

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thanks and have fun!

Regards,
Corey
(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Plans to converge on one ldap client?

[Corey Bryant]

On Tue, May 24, 2016 at 1:23 PM, Morgan Fainberg <morgan.fainb...@gmail.com>
wrote:

>
>
> On Tue, May 24, 2016 at 8:55 AM, Corey Bryant <corey.bry...@canonical.com>
> wrote:
>
>>
>>
>> On Tue, May 24, 2016 at 11:11 AM, Morgan Fainberg <
>> morgan.fainb...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, May 24, 2016 at 5:53 AM, Corey Bryant <
>>> corey.bry...@canonical.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Are there any plans to converge on one ldap client across projects?
>>>> Some projects have moved to ldap3 and others are using pyldap (both are in
>>>> global requirements).
>>>>
>>>> The issue we're running into in Ubuntu is that we can only have one
>>>> ldap client in Ubuntu main, while the others will live in universe.
>>>>
>>>> --
>>>> Regards,
>>>> Corey
>>>>
>>>>
>>> Out of curiosity, what drives this requirement? pyldap and ldap3 do not
>>> overlap in namespace and can co-install just fine. This is no different
>>> than previously having python-ldap and ldap3.
>>>
>>> It seems a little arbitrary to say only one of these can be in main, but
>>> this is why i am asking.
>>>
>>>
>> No problem, thanks for asking.  I agree, it's no different than
>> python-ldap and ldap3 and it's not a co-installability issue.  This is just
>> a policy for Ubuntu main.  If we file a Main Inclusion Request (MIR) for a
>> new ldap client then we'll be asked to work on what's needed to get the
>> other client package out of main, which consists of patching use of one
>> client for the other.
>>
>>
> Ah, ok sure; still sounds a little silly imho, but only so much we can do
> on that front ;). So the reality is keystone is
>

Everything in main is fully supported, so limiting those efforts to a
single client makes sense.


> considering ldap3, but there have been concerns about ldap3's interface
> compared to the relatively tried-and-true pyldap (a clean fork+py3 support
> of python-ldap). Long term we may move to ldap3. Short term, we wanted
> python3 support, so the drop in replacement for python-ldap was the clear
> winner (ldap3 is significantly more work to support, and even when/if we
> support it there will be a period where we support both, just in different
> drivers).
>

I like the approach to having different drivers, at least for a transition
period.  That would be very useful from a distro perspective.


>
> Basically, if we add ldap3 to keystone, we will be supporting both for a
> non-insignificant time. For now we're leaning on pyldap for the foreseeable
> future.
>
>
>>
Thanks. Appreciate the information!

-- 
Regards,
Corey
__
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] Plans to converge on one ldap client?

[Corey Bryant]

On Tue, May 24, 2016 at 11:11 AM, Morgan Fainberg <morgan.fainb...@gmail.com
> wrote:

>
>
> On Tue, May 24, 2016 at 5:53 AM, Corey Bryant <corey.bry...@canonical.com>
> wrote:
>
>> Hi All,
>>
>> Are there any plans to converge on one ldap client across projects?  Some
>> projects have moved to ldap3 and others are using pyldap (both are in
>> global requirements).
>>
>> The issue we're running into in Ubuntu is that we can only have one ldap
>> client in Ubuntu main, while the others will live in universe.
>>
>> --
>> Regards,
>> Corey
>>
>>
> Out of curiosity, what drives this requirement? pyldap and ldap3 do not
> overlap in namespace and can co-install just fine. This is no different
> than previously having python-ldap and ldap3.
>
> It seems a little arbitrary to say only one of these can be in main, but
> this is why i am asking.
>
>
No problem, thanks for asking.  I agree, it's no different than python-ldap
and ldap3 and it's not a co-installability issue.  This is just a policy
for Ubuntu main.  If we file a Main Inclusion Request (MIR) for a new ldap
client then we'll be asked to work on what's needed to get the other client
package out of main, which consists of patching use of one client for the
other.

-- 
Regards,
Corey
__
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] Plans to converge on one ldap client?

[Corey Bryant]

Hi All,

Are there any plans to converge on one ldap client across projects?  Some
projects have moved to ldap3 and others are using pyldap (both are in
global requirements).

The issue we're running into in Ubuntu is that we can only have one ldap
client in Ubuntu main, while the others will live in universe.

-- 
Regards,
Corey
__
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][packaging][summit] input needed on summit discussion about global requirements

[Corey Bryant]

On Tue, Apr 19, 2016 at 12:24 PM, Ian Cordasco 
wrote:

>
>
> -Original Message-
> From: Thomas Goirand 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: April 18, 2016 at 17:21:36
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [release][requirements][packaging][summit]
> input needed on summit discussion about global requirements
>
> > Hi Doug,
> >
> > I very much welcome opening such a thread before the discussion at the
> > summit, as often, sessions are too short. Taking the time to write
> > things down first also helps having a more constructive discussion.
> >
> > Before I reply to each individual message below, let me attempt to reply
> > to the big picture seen in your etherpad. I was tempted to insert
> > comments on each lines of it, but I'm not sure how this would be
> > received, and probably it's best to attempt to reply more globally.
> >
> > From what I understand, the biggesgt problems you're trying to solve is
> > that managing the global-reqs is really time consuming from the release
> > team point of view, and especially its propagation to individual
> > projects. There's IMO many things that we could do to improve the
> > situation, which would be acceptable from the package maintainers point
> > of view.
> >
> > First of all, from what I could see in the etherpad, I see a lot of
> > release work which I consider not useful for anyone: not for downstream
> > distros, not upstream projects. Mostly, the propagation of the
> > global-requirements.txt to each and every individual Python library or
> > service *for OpenStack maintained libs* could be reviewed. Because 1/
> > distros will always package the highest version available in
> > upper-constraints.txt, and 2/ it doesn't really reflect a reality. As
> > you pointed out, project A may need a new feature from lib X, but
> > project B wont care. I strongly believe that we should leave lower
> > boundaries as a responsibility of individual projects. What important
> > though, is to make sure that the highest version released does work,
> > because that's what we will effectively package.
> >
> > What we can then later on do, at the distribution level, is artificially
> > set the lower bounds of versions to whatever we've just uploaded for a
> > given release of OpenStack. In fact, I've been doing this a lot already.
> > For example, I uploaded Eventlet 0.17.4, and then 0.18.4. There was
> > never anything in the between. Therefore, doing a dependency like:
> >
> > Depends: python-eventlet (>= 0.18.3)
> >
> > makes no sense, and I always pushed:
> >
> > Depends: python-eventlet (>= 0.18.4)
> >
> > as this reflects the reality of distros.
> >
> > If we generalize this concept, then I could push the minimum version of
> > all oslo libs into every single package for a given version of OpenStack.
> >
> > What is a lot more annoying though, is for packages which I do not
> > control directly, and which are used by many other non-OpenStack
> > packages inside the distribution. For example, Django, SQLAlchemy or
> > jQuery, to only name a few.
> >
> > I have absolutely no problem upping the lower bounds for all of
> > OpenStack components aggressively. We don't have gate jobs for the lower
> > bounds of our requirements. If we decide that it becomes the norm, I can
> > generalize and push for doing this even more. For example, after pushing
> > the update of an oslo lib B version X, I could push such requirements
> > everywhere, which in fact, would be a good thing (as this would trigger
> > rebuilds and recheck of all unit tests). Though, all of this would
> > benefit from a lot of automation and checks.
> >
> > On your etherpad, you wrote:
> >
> > "During the lead-up to preparing the final releases, one of the tracking
> > tasks we have is to ensure all projects have synced their global
> > requirements updates. This is another area where we could reduce the
> > burden on the release team."
> >
> > Well, don't bother, this doesn't reflect a reality anyway (ie: maybe
> > service X can use an older version of oslo.utils), so that's not really
> > helpful in any way.
> >
> > You also wrote:
> >
> > "Current ranges in global-requirements are large but most projects do
> > not actively test the oldest supported version (or other versions in
> > between) meaning that the requirement might result in broken packages."
> >
> > Yeah, that's truth, I've seen this and reported a few bugs (the last I
> > have in memory is Neutron requiring SQLA >= 1.0.12). Though that's still
> > very useful hints for package maintainers *for 3rd party libs* (as I
> > wrote, it's less important for OpenStack components). We have a few
> > breakage here and there, but they are hopefully fixes.
> >
> > Though having a single version that projects are allowed to test 

Re: [openstack-dev] [release] mitaka-3 development milestone

[Corey Bryant]

On Fri, Mar 4, 2016 at 11:49 AM, Thierry Carrez 
wrote:

> Hello everyone,
>
> The last milestone of the Mitaka development cycle, "mitaka-3", is now
> reached. Some OpenStack projects following the milestone-based release
> schedule took the opportunity to publish a development artifact, which
> contains all the new features and bugfixes that have been added since
> mitaka-2 6 weeks ago:
>
> aodh 2.0.0.0b3:
> https://tarballs.openstack.org/aodh/aodh-2.0.0.0b3.tar.gz
>
> barbican 2.0.0.0b3:
> https://tarballs.openstack.org/barbican/barbican-2.0.0.0b3.tar.gz
>
> ceilometer 6.0.0.0b3:
> https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0b3.tar.gz
>
> cinder 8.0.0.0b3:
> https://tarballs.openstack.org/cinder/cinder-8.0.0.0b3.tar.gz
>
> congress 3.0.0.0b3:
> https://tarballs.openstack.org/congress/congress-3.0.0.0b3.tar.gz
>
> designate 2.0.0.0b3:
> https://tarballs.openstack.org/designate/designate-2.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/designate-dashboard/designate-dashboard-2.0.0.0b3.tar.gz
>
> glance 12.0.0.0b3:
> https://tarballs.openstack.org/glance/glance-12.0.0.0b3.tar.gz
>
> heat 6.0.0.0b3:
> https://tarballs.openstack.org/heat/heat-6.0.0.0b3.tar.gz
>
> horizon 9.0.0.0b3:
> https://tarballs.openstack.org/horizon/horizon-9.0.0.0b3.tar.gz
>
> keystone 9.0.0.0b3:
> https://tarballs.openstack.org/keystone/keystone-9.0.0.0b3.tar.gz
>
> manila 2.0.0.0b3:
> https://tarballs.openstack.org/manila/manila-2.0.0.0b3.tar.gz
>
> mistral 2.0.0.0b3:
> https://tarballs.openstack.org/mistral/mistral-2.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-2.0.0.0b3.tar.gz
> https://tarballs.openstack.org/mistral-extra/mistral-extra-2.0.0.0b3.tar.gz
>
> murano 2.0.0.0b3:
> https://tarballs.openstack.org/murano/murano-2.0.0.0b3.tar.gz
>
> neutron 8.0.0.0b3:
> https://tarballs.openstack.org/neutron/neutron-8.0.0.0b3.tar.gz
> https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0b3.tar.gz
> https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b3.tar.gz


Hi Thierry,

I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
https://tarballs.openstack.org/neutron-vpnaas.  Do we need an update there?

Thanks,
Corey
__
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] Any projects using sqlalchemy-utils?

[Corey Bryant]

On Mon, Feb 15, 2016 at 7:57 AM, Julien Danjou <jul...@danjou.info> wrote:

> On Fri, Feb 12 2016, Corey Bryant wrote:
>
> > taskflow started using it recently, however it's only needed for a single
> > type in taskflow (JSONType).  I'm wondering if it's worth the effort of
> > maintaining it and it's dependencies in Ubuntu main or if perhaps we can
> > just revert this bit to define the JSONType internally.
>
> As Haïkel said, we use it for a while in Gnocchi, and have no intention
> or copy/pasting its code. It's even likely I'll spread its use in other
> telemetry projects.


> If an effort should be made, it's probably to merge from
> sqlalchemy-utils to sqlalchemy. :)
>
> If there's any reason it's a burden to maintain this Python package
> compared to others in Ubuntu, let us know, maybe we can fix/enhance
> something upstream?
>
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
>


It's not a problem at all.  I just wanted to make sure there were more
projects using sqlalchemy-utils than the single type used in taskflow.  And
there are!  So that answers my question.  Thanks.

-- 
Regards,
Corey
__
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] Any projects using sqlalchemy-utils?

[Corey Bryant]

Are any projects using sqlalchemy-utils?

taskflow started using it recently, however it's only needed for a single
type in taskflow (JSONType).  I'm wondering if it's worth the effort of
maintaining it and it's dependencies in Ubuntu main or if perhaps we can
just revert this bit to define the JSONType internally.

-- 
Regards,
Corey
__
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