Re: [openstack-dev] [neutron][l2gw] stable/queens tripleo issues

[Gary Kotton]

Thanks!! When its ready we can add it again.
Thank you!

From: Emilien Macchi 
Reply-To: OpenStack List 
Date: Tuesday, February 20, 2018 at 9:14 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron][l2gw] stable/queens tripleo issues

Hey Gary :-)

Yeah our CI isn't ready yet for stable/queens, sorry for that.
I propose to disable TripleO jobs in stable/queens for l2gw project: 
https://review.openstack.org/546059

Hopefully that helps!

Cheers,

On Mon, Feb 19, 2018 at 11:07 PM, Gary Kotton 
> wrote:
Hi,
At the moment the stable/queens branch is broken due to the tripleo CI test 
failing [i]. Does anyone have any hints here on what we should look at? I am 
not sure if this is with ansible/centos…
Thanks
Gary
[i] 
http://logs.openstack.org/88/543188/2/check/tripleo-ci-centos-7-scenario004-multinode-oooq-container/9bc3b75/

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



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

Re: [openstack-dev] [neutron][l2gw] stable/queens tripleo issues

[Emilien Macchi]

Hey Gary :-)

Yeah our CI isn't ready yet for stable/queens, sorry for that.
I propose to disable TripleO jobs in stable/queens for l2gw project:
https://review.openstack.org/546059

Hopefully that helps!

Cheers,

On Mon, Feb 19, 2018 at 11:07 PM, Gary Kotton  wrote:

> Hi,
>
> At the moment the stable/queens branch is broken due to the tripleo CI
> test failing [i]. Does anyone have any hints here on what we should look
> at? I am not sure if this is with ansible/centos…
>
> Thanks
>
> Gary
>
> [i] http://logs.openstack.org/88/543188/2/check/tripleo-ci-
> centos-7-scenario004-multinode-oooq-container/9bc3b75/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Emilien Macchi
__
OpenStack Development Mailing 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] [neutron][l2gw] stable/queens tripleo issues

[Gary Kotton]

Hi,
At the moment the stable/queens branch is broken due to the tripleo CI test 
failing [i]. Does anyone have any hints here on what we should look at? I am 
not sure if this is with ansible/centos…
Thanks
Gary
[i] 
http://logs.openstack.org/88/543188/2/check/tripleo-ci-centos-7-scenario004-multinode-oooq-container/9bc3b75/
__
OpenStack Development Mailing 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][ptl] Final Queens RC Deadline

[Emilien Macchi]

On Mon, Feb 19, 2018 at 8:53 AM, Sean McGinnis 
wrote:
[...]
>
> The final Queens RC deadline is Thursday, 22 FEBRUARY.
>

Too late, you said March. Thanks a lot for the extra-month :-)

/jk
-- 
Emilien Macchi
__
OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[Emilien Macchi]

On Mon, Feb 19, 2018 at 7:03 AM, Jeremy Stanley  wrote:
[...]

> This is hopefully only a temporary measure? I think I've heard it
> mentioned that planning is underway to switch that CI system to Zuul
> v3 (perhaps after 3.0.0 officially releases soon).
>

Adding Tristan and Fabien in copy, they know better about the roadmap.
-- 
Emilien Macchi
__
OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[Joshua Hesketh]

Perhaps we need to consider a backport of the syntax to the 2.5 series?

It could help with the transition for those who need to upgrade. However,
on the other hand it might make deployers more complacent to do so.

On Tue, Feb 20, 2018 at 2:03 AM, Jeremy Stanley  wrote:

> On 2018-02-18 19:25:07 -0800 (-0800), Emilien Macchi wrote:
> [...]
> > My recommendation for TripleO devs: use the old syntax if you want your
> > code to be tested by RDO Third party CI
> [...]
>
> This is hopefully only a temporary measure? I think I've heard it
> mentioned that planning is underway to switch that CI system to Zuul
> v3 (perhaps after 3.0.0 officially releases soon).
> --
> 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Tony Breeds]

On Mon, Feb 19, 2018 at 10:00:59AM -0500, Michael Bayer wrote:
> Hi list -
> 
> Apparently Cinder was misled by my deprecations within the
> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> in https://review.openstack.org/#/c/522290/ the assumption was made
> that these should be imported from oslo_db.tests.sqlalchemy.This
> is an immense mistake on my part that I did not expect people to go
> looking for the same names elsewhere in private packages and now we
> have a serious downstream issue as these modules are not packaged, as
> well as the possibility that the oslo_db.tests. package is now locked
> in time and I have to add deprecations there also.
> 
> If anyone knows of projects (or feels like helping me search) that are
> importing *anything* from oslo_db.tests these must be reverted ASAP.

I get:

[tony@thor openstack]$ grep -Erin '((from|import) oslo_db.tests|from oslo_db 
import tests)' */*/*
openstack/cinder/cinder/tests/unit/db/test_migrations.py:29:from 
oslo_db.tests.sqlalchemy import base as test_base
openstack/glance/glance/tests/functional/db/test_migrations.py:23:from 
oslo_db.tests.sqlalchemy import base as test_base
openstack/glare/glare/tests/unit/db/migrations/test_migrations.py:35:from 
oslo_db.tests.sqlalchemy import base as test_base
openstack/ironic/build/lib/ironic/tests/unit/db/sqlalchemy/test_migrations.py:47:from
 oslo_db.tests.sqlalchemy import base as test_base
openstack/ironic/ironic/tests/unit/db/sqlalchemy/test_migrations.py:47:from 
oslo_db.tests.sqlalchemy import base as test_base
openstack/neutron/neutron/tests/unit/db/test_sqlalchemytypes.py:19:from 
oslo_db.tests.sqlalchemy import base as test_base

+ bunch of oslo_db hits but I guess they're un interesting ;P

I last updated my local clones yesterday so it shouldn't be too far from
the current state.

Yours Tony.


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

Re: [openstack-dev] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Tony Breeds]

On Mon, Feb 19, 2018 at 03:24:24PM +0100, Bogdan Dobrelya wrote:

> With a backport of the YAQL fixes for tht made for Pike, would it be the
> full fix to make a backport of yaql 1.1.3 for Pike repos as well? Or am I
> missing something?

At some level that should be fine.  In the broader OpenSteck perspective
we've been gating with yaql 1.1.3 from pypi for releases > newton.  So
while updating the yaql package on pike to 1.1.3 isn't guaranteed to be
safe it should be fine.

Yours Tony.


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

Re: [openstack-dev] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Tony Breeds]

On Mon, Feb 19, 2018 at 06:10:56PM +0100, Alfredo Moralejo Alonso wrote:

> Recently, we have added a job in post pipeline for openstack/requirements
> in https://review.rdoproject.org to
> automatically post updates in RDO dependencies repo when changes are
> detected in upper-constraints. This
> job will try to automatically update the dependencies when possible or
> notify to take required manual actions
> in some cases.
> 
> I expect this will improve dependencies management in RDO in next releases.

That's cool.  Can you point me at how that's done?  I'm not sure how
you'd automate the builds but that's probably just lack of imagination
on my part ;P

Yours Tony.


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

Re: [openstack-dev] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Zane Bitter]

On 17/02/18 16:40, Dan Prince wrote:

Thanks for the update Emilien. A couple of things to add:

1) This was really difficult to pin-point via the Heat stack error
message ('list index out of range'). I actually had to go and add
LOG.debug statements to Heat to get to the bottom of it. I aim to sync
with a few of the Heat folks next week on this to see if we can do
better here.


The message itself is pretty much all we get from yaql, even in its own 
interpreter:


(py27) cat yaql_data.json
{"data": [{"foo": "bar"}]}
(py27) yaql -d yaql_data.json
Yet Another Query Language - command-line query tool
Version 1.1.3
Copyright (c) 2013-2017 Mirantis, Inc

yaql> dict($.data.where($ != 
null).flatten().selectMany($.items()).groupBy($[0], $[1], $.flatten()))

{
"foo": [
"bar"
]
}
yaql> dict($.data.where($ != 
null).flatten().selectMany($.items()).groupBy($[0], $[1], [$[0], 
$[1].flatten()]))

Execution exception: list index out of range
yaql>

(Note that different lengths of data will give you different errors though.)

The big issue here though is that for failures in validation we report 
the path in the template to the function that failed, but we don't do 
the same for failures in actually resolving the function at runtime. A 
comprehensive fix is challenging without breaking what is supposed to be 
a stable third-party plugin API, but it might be possible. Was that the 
information you needed to debug this?


We do report which resource failed, but for something with a huge 
definition like allNodesConfig I can see why that might not help as much 
as you'd hope.



2) I had initially thought it would have been much better to revert
the (breaking) change to python-yaql. That said it was from 2016! So I
think our window of opportunity for the revert is probably way too
large to consider that. Sounds like we need to publish the yaql
package more often in RDO, etc. So your patch to update our queries is
probably our only option.


I _think_ this should be OK for upgrades, as long as you never do a 
stack update using the existing (Pike) templates after upgrading the 
undercloud to Queens, but... sadface.


I think we need to either merge Thomas's patch that gets rid of this 
function altogether (https://review.openstack.org/#/c/545856/) and 
backport it to older versions of t-h-t, or make yaql itself 
backward-compatible by doing something like 
https://review.openstack.org/#/c/545996/


cheers,
Zane.


On Fri, Feb 16, 2018 at 8:36 PM, Emilien Macchi  wrote:

Upgrading YAQL from 1.1.0 to 1.1.3 breaks advanced queries with groupBy
aggregation.

The commit that broke it is
https://github.com/openstack/yaql/commit/3fb91784018de335440b01b3b069fe45dc53e025

It broke TripleO: https://bugs.launchpad.net/tripleo/+bug/1750032
But Alex and I figured (after a strong headache) that we needed to update
the query like this: https://review.openstack.org/545498

It would be great to avoid this kind of change within minor versions, please
please.

Happy weekend,

PS: I'm adding YAQL to my linkedin profile right now.


Be careful here. Do you really want to write YAQL queries all day!

Dan


--
Emilien Macchi

__
OpenStack Development Mailing 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

[openstack-dev] [nova] review priorities etherpad for rocky

[melanie witt]

Howdy Stackers,

I’ve set up the review priorities etherpad [1] for us to use during the Rocky 
cycle. It’s the same format we had back in Pike with the exception of a couple 
of new sections I’ve added: "Non-priority approved blueprints” and "Co-authors 
wanted”. The idea of the etherpad is to organize a subset of proposed patches 
to focus review and make it easy to find “what can I review today?” The 
etherpad is organized by subteam/topic, so reviewers can easily find the latest 
and greatest patches for each area. As a subteam/topic member, please add links 
to your patches accordingly.

The "Non-priority approved blueprints” is a new section I’d like to try out to 
create some visibility for non-priority work that is ready for review. I’m 
thinking if we have a section for it, it will be easier to keep reviews for 
those blueprints in our rotation. If the section gets too large, we can create 
a new etherpad for that and link to it in the section.

The other new section is called "Co-authors wanted”. Here I’d like to provide a 
place where authors can link patches they’d like to collaborate on with one or 
more other co-authors. The common scenario I think about is: an author has 
researched a bug and is able to propose a patch, but doesn’t have the time or 
the knowhow to provide test coverage in the patch. They could add the patch to 
the “Co-authors wanted” section and if another author is interested, they could 
join the patch, add the test coverage, and add themselves as co-author. By 
doing this, I hope to make it easier for co-authors to work on patches together.

Let me know if you have any questions about the etherpad.

Thanks,
-melanie

[1] https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
__
OpenStack Development Mailing 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] [neutron] networking-midonet 6.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for networking-midonet for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-midonet/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:


http://git.openstack.org/cgit/openstack/networking-midonet/log/?h=stable/queens

Release notes for networking-midonet can be found at:

http://docs.openstack.org/releasenotes/networking-midonet/




__
OpenStack Development Mailing 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] [neutron] networking-ovn 4.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for networking-ovn for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-ovn/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:

http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/queens

Release notes for networking-ovn can be found at:

http://docs.openstack.org/releasenotes/networking-ovn/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/networking-ovn

and tag it *queens-rc-potential* to bring it to the networking-ovn
release crew's attention.


__
OpenStack Development Mailing 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] [neutron] neutron 12.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for neutron for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/queens

Release notes for neutron can be found at:

http://docs.openstack.org/releasenotes/neutron/




__
OpenStack Development Mailing 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] [neutron] neutron-dynamic-routing 12.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for neutron-dynamic-routing for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-dynamic-routing/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:


http://git.openstack.org/cgit/openstack/neutron-dynamic-routing/log/?h=stable/queens

Release notes for neutron-dynamic-routing can be found at:

http://docs.openstack.org/releasenotes/neutron-dynamic-routing/




__
OpenStack Development Mailing 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] [neutron] Bug Deputy Report - resend

[Miguel Lavalle]

There is one critical bug from this week:
https://bugs.launchpad.net/neutron/+bug/1749667 - neutron doesn't correctly
handle unknown protocols and should whitelist known and handled protocols
There is a fix in progress for this already, thanks Brian for picking this
up.

There are three bugs that still need further attention:

https://bugs.launchpad.net/neutron/+bug/1748658 - Restarting Neutron
containers which make use of network namespaces doesn't work
This has a fix for the tripleo side but I believe it still needs attention
from neutron

https://bugs.launchpad.net/neutron/+bug/1749425 - Neutron integrated with
OpenVSwitch drops packets and fails to plug/unplug interfaces from OVS on
router interfaces at scale
There is some discussion in the comments of this bug in regard to easing
reproduction, should help confirmation when as that effort continues.

https://bugs.launchpad.net/neutron/+bug/1749982 - After l3-agent-router-add
inactive router gets all traffic
I didn't get much time with this one but couldn't manage to reproduce it.
However I'm not too familiar with this area, so I'm hoping someone else can
give a more definitive answer.

There is also one bug marked as incomplete:
https://bugs.launchpad.net/neutron/+bug/1748894 - intermittent dhcp failures
This could use some eyes as well to get confirmed.

Thanks everyone,
 - James Anziano
__
OpenStack Development Mailing 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] Thanks Bot - For a happier open source community, give recognition

[Mike Perez]

Every open source community is made up of real people with real feelings. Many
open source contributors are working in their free time to provide essential
software that we use daily. Sometimes praise is lost in the feedback of bugs or
missing features. Focusing on too much negative feedback can lead contributors
to frustration and burnout.

However you end up contributing to OpenStack, or any open source project, I
believe that what gets people excited about working with a community is some
form of recognition.

My first answer to people coming into the OpenStack community is to join our
Project Team Gathering event. Significant changes are discussed here to
understand the technical details to carry out the work in the new release. You
should seek out people who are owners of these changes and volunteer to work on
a portion of the work. Not only are these people interested in your success by
having you take on some of the work they have invested in, but you will be
doing work that interests the entire team. You’ll finish the improvements and
be known as the person in the project with the expertise in that area. You’ll
receive some recognition from the team and the community using your software.
And just like that, you’re hooked because you know your work is making a
difference. Maybe you’ll improve that area of the project more, venture onto
other parts of the project, or even expand to other open source projects.

If you work in the OpenStack community, there’s also another way you can give
and get recognition. In OpenStack IRC channels, you can thank members of the
community publicly with the following command:

#thanks  for being a swell person in that heated discussion!

To be clear,   is replaced with the person you want to give thanks.

Where does this information go? Just like the Success Bot in which we can share
successes as a community, Thanks Bot will post them to the OpenStack wiki. They
will also be featured in the OpenStack Developer Digest.

https://wiki.openstack.org/wiki/Thanks

In developing this feature, I’ve had help and feedback from various members of
the community. You can see my history of thanking people along the way, too.

At the next OpenStack event, you’re still welcome to buy a tasty beverage for
someone to say thanks. But why not give them recognition now too and let them
know how much they’re appreciated in the community?

-- 
Mike Perez (thingee)


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

[openstack-dev] [neutron] Bug Deputy Report

[James Anziano]

Hi all,
 
There is one critical bug from this week:
https://bugs.launchpad.net/neutron/+bug/1749667 - neutron doesn't correctly handle unknown protocols and should whitelist known and handled protocols
There is a fix in progress for this already, thanks Brian for picking this up.
 
There are three bugs that still need further attention:
 
https://bugs.launchpad.net/neutron/+bug/1748658 - Restarting Neutron containers which make use of network namespaces doesn't work
This has a fix for the tripleo side but I believe it still needs attention from neutron
 
https://bugs.launchpad.net/neutron/+bug/1749425 - Neutron integrated with OpenVSwitch drops packets and fails to plug/unplug interfaces from OVS on router interfaces at scale
There is some discussion in the comments of this bug in regard to easing reproduction, should help confirmation when as that effort continues.
 
https://bugs.launchpad.net/neutron/+bug/1749982 - After l3-agent-router-add inactive router gets all traffic
I didn't get much time with this one but couldn't manage to reproduce it. However I'm not too familiar with this area, so I'm hoping someone else can give a more definitive answer.
 
There is also one bug marked as incomplete:
https://bugs.launchpad.net/neutron/+bug/1748894 - intermittent dhcp failures
This could use some eyes as well to get confirmed.
 
Thanks everyone,
 - James Anziano


__
OpenStack Development Mailing 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-operators] User Committee Elections

[Arkady.Kanevsky]

I saw election email with the pointer to votes.
See no reason for stopping it now. But extending vote for 1 more week makes 
sense.
Thanks,
Arkady

From: Melvin Hillsman [mailto:mrhills...@gmail.com]
Sent: Monday, February 19, 2018 11:32 AM
To: user-committee ; OpenStack Mailing List 
; OpenStack Operators 
; OpenStack Dev 
; commun...@lists.openstack.org
Subject: [Openstack-operators] User Committee Elections

Hi everyone,

We had to push the voting back a week if you have been keeping up with the UC 
elections[0]. That being said, election officials have sent out the poll and so 
voting is now open! Be sure to check out the candidates - https://goo.gl/x183he 
- and get your vote in before the poll closes.

[0] https://governance.openstack.org/uc/reference/uc-election-feb2018.html

--
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
OpenStack Development Mailing 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]

[Dmitrii Shcherbakov]

> Data migration from where to where? We access the current state by 
retrieving the data from leader db, or am I missing something here?


In case there are changes in how data is stored in one version of a 
charm vs the other.


Another problem is application versioning: we do have version-specific 
templates but this data may be versioned too. Old entries may not be 
simple strings, e.g. they can be small objects which can change 
following version changes (new data added or removed in a pre-defined way).


I can also see potential scenarios where you would need to gracefully 
retire old data as features get deprecated and, eventually, removed. So, 
during an upgrade you would have two copies of stateful data and a charm 
would react differently depending on the current application version 
set. After an upgrade the old copy could be automatically discarded.


> Perhaps I'm being naive but I don't see these developing into data 
sets large enough to cause performance problems.


I don't think it's going to be used for large data sets either but you 
never know.


> Each time the action is run the context associated with the action is 
deleted and recreated. If an action argument is unset I guess we could 
interpret that as leave-unchanged.


Leave unchanged - yes. Still need to be able to delete completely though.

What I like about actions is that you can clearly express imperative 
steps with arguments that you have to perform after a deployment and 
they have a very specific type of data in mind which is fetched from 
stateful applications out of band by an operator.


On 19.02.2018 18:11, Liam Young wrote:

On Mon, Feb 19, 2018 at 9:05 AM, Dmitrii Shcherbakov
 wrote:

Hi Liam,


I was recently looking at how to support custom configuration that relies
on post deployment setup.

I would describe the problem in general as follows:

1) charms can get context not only from Juju (config options, relation data,
leader data), environment (operating system release, OpenStack release,
services running etc.) but also from a stateful data store (e.g. a Keystone
database);
2) it's not easy to track application state from a charm because:
authentication is needed to fetch persistent state, notifications from a
data store cannot be reliably set up because charm code is ran periodically
and it is not always present in memory (polling is neither timely nor
efficient). Another problem is that software that holds the state needs to
support data change notifications which raises version compatibility
questions.

By using actions we move the responsibility for data retrieval and change
notifications to an operator but a more generic scenario would be modeling a
feedback loop from an application to Juju as a modeling system where changes
can be either automatic or gated by an operator (an orchestrator). Making it
automatic would mean that a service would get notifications/poll data from a
state store and would be authorized to use Juju client to make certain
changes.

This is an interesting idea, but there is no such mechanism within
Juju that I know of.


Another problem to solve is maintenance of that state: if we start
maintaining a key-value DB in leader settings we need to think about data
migration over time and how to access the current state.

Data migration from where to where? We access the current state by retrieving
the data from leader db, or am I missing something here?


In other words, in
CRUD, the "C" part is relatively straightforward, "R" is more complicated
with large data sets (if I have a lot of leader data, how do I interpret it
efficiently?),

Perhaps I'm being naive but I don't see these developing into data
sets large enough
to cause performance problems.


"UD" is less clear - seems like there will have to be 3 or 4
actions per feature for C, [R], U and D or one action that can multiplex
commands.

Each time the action is run the context associated with the action is deleted
and recreated. If an action argument is unset I guess we could interpret that as
leave-unchanged.


This brings me to the question of how is it different from state-specific
config values with a complex structure.

To my mind the difference is complexity for the end user. An action has clearly
defined arguments and the charm action code looks after forming this into
the correct context.


Instead of leader data, a per-charm
config option could hold state data in some format namespaced by a feature
name or config file name to render. A data model would be needed to make
sure we can create versioned application-specific state buckets (e.g. for
upgrades, hold both states, then remove the old one).

Application version-specific config values is something not modeled in Juju
although custom application versions are present
(https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set).
Version information has to be set via a hook tool which means that it has to
come from a 

[openstack-dev] User Committee Elections

[Melvin Hillsman]

Hi everyone,

We had to push the voting back a week if you have been keeping up with the
UC elections[0]. That being said, election officials have sent out the poll
and so voting is now open! Be sure to check out the candidates -
https://goo.gl/x183he - and get your vote in before the poll closes.

[0] https://governance.openstack.org/uc/reference/uc-election-feb2018.html

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
OpenStack Development Mailing 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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Alfredo Moralejo Alonso]

On Sun, Feb 18, 2018 at 1:35 AM, Tony Breeds 
wrote:

> On Sat, Feb 17, 2018 at 04:40:12PM -0500, Dan Prince wrote:
> > Thanks for the update Emilien. A couple of things to add:
> >
> > 1) This was really difficult to pin-point via the Heat stack error
> > message ('list index out of range'). I actually had to go and add
> > LOG.debug statements to Heat to get to the bottom of it. I aim to sync
> > with a few of the Heat folks next week on this to see if we can do
> > better here.
> >
> > 2) I had initially thought it would have been much better to revert
> > the (breaking) change to python-yaql. That said it was from 2016! So I
> > think our window of opportunity for the revert is probably way too
> > large to consider that. Sounds like we need to publish the yaql
> > package more often in RDO, etc. So your patch to update our queries is
> > probably our only option.
>
> I'm keen to sit down at the PTG for a quick discussion on how the
> requirements team can better support RDO (and therefore tripleo) to
> test these OpenStack deliverables sooner.
>
> As you point out the commit was from Aug 2016, which was released in Mar
> 2017.  It was added to upper-constraints almost immediately and
> global-requirements (as the minimum supported version) in Aug 2017.
>
> However, it was only recently added to RDO.
>
> So if there is anything we can do on the requirements team to signal
> these changes that isn't being done already lets work out what it is :)
>
>
Recently, we have added a job in post pipeline for openstack/requirements
in https://review.rdoproject.org to
automatically post updates in RDO dependencies repo when changes are
detected in upper-constraints. This
job will try to automatically update the dependencies when possible or
notify to take required manual actions
in some cases.

I expect this will improve dependencies management in RDO in next releases.




> Yours Tony.
>
> __
> OpenStack Development Mailing 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

Summarizing all the reviews:

Doug's proposed check in oslo_db.tests: https://review.openstack.org/#/c/545859/
Mark oslo_db internal fixtures private:   https://review.openstack.org/545862
Cinder: https://review.openstack.org/545860
Neutron: https://review.openstack.org/545868
Ironic: https://review.openstack.org/545874
Glance: https://review.openstack.org/545878
Glare: https://review.openstack.org/545883



On Mon, Feb 19, 2018 at 11:32 AM, Doug Hellmann  wrote:
> Excerpts from Michael Bayer's message of 2018-02-19 10:55:52 -0500:
>> wow that's heavy-handed.  should that be in an oslo utility package of
>> some kind ?
>
> I thought about that, but figured we should wait and see whether we
> actually want to take the approach before polishing it. If we do we can
> add a function in oslo.utils.
>
>>
>> On Mon, Feb 19, 2018 at 10:52 AM, Doug Hellmann  
>> wrote:
>> > Excerpts from Doug Hellmann's message of 2018-02-19 10:15:34 -0500:
>> >> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
>> >> > Hi list -
>> >> >
>> >> > Apparently Cinder was misled by my deprecations within the
>> >> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
>> >> > in https://review.openstack.org/#/c/522290/ the assumption was made
>> >> > that these should be imported from oslo_db.tests.sqlalchemy.This
>> >> > is an immense mistake on my part that I did not expect people to go
>> >> > looking for the same names elsewhere in private packages and now we
>> >> > have a serious downstream issue as these modules are not packaged, as
>> >> > well as the possibility that the oslo_db.tests. package is now locked
>> >> > in time and I have to add deprecations there also.
>> >> >
>> >> > If anyone knows of projects (or feels like helping me search) that are
>> >> > importing *anything* from oslo_db.tests these must be reverted ASAP.
>> >> >
>> >>
>> >> If we have modules or classes we don't expect people to be importing
>> >> directly, we need to prefix the names with _ to comply with the naming
>> >> conventions we have previously told everyone to look for to recognize
>> >> private code.
>> >>
>> >> I think it's safe to treat "tests" as an exception (after resolving
>> >> this case) but we should probably document that.
>> >>
>> >> Doug
>> >
>> > Once we resolve the current set of imports, we can land a patch like
>> > https://review.openstack.org/545859 to prevent this from happening in
>> > the future.
>> >
>> > Doug
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing 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] [magnum] Example bringup of Istio on Magnum k8s + Octavia

[Timothy Swanson (tiswanso)]

In case anyone is interested in the details, I went through the exercise of a 
basic bringup of Istio on Magnum k8s (with stable/pike):  
https://tiswanso.github.io/istio/istio_on_magnum.html

I hope to update with follow-on items that may also be explored, such as:
- Istio automatic side-car injection via adding the k8s admission controller 
during cluster create
- Add Raw VM app to istio service-mesh


Big thanks to Spyros (strigazi) for helping me through some magnum bringup 
snags.


—Tim Swanson
(tiswanso)
__
OpenStack Development Mailing 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][ptl] Final Queens RC Deadline

[Sean McGinnis]

On Mon, Feb 19, 2018 at 11:50:21AM -0500, David Moreau Simard wrote:
> On Mon, Feb 19, 2018 at 10:44 AM, Sean McGinnis  wrote:
> > Hey everyone,
> >
> > Just a quick reminder that Thursday, 22 March, is the deadline for any final
> > Queens release candidates. After this point we will enter a quiet period 
> > for a
> > week in preparation of tagging the final Queens release during the PTG week.
> 
> February, right ?
> 
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
> 
> dmsimard = [irc, github, twitter]

Whoops!!! Yes, sorry. I am getting way ahead of myself I guess.

The final Queens RC deadline is Thursday, 22 FEBRUARY.

Sorry about any confusion. Thanks David for correcting that.

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

Re: [openstack-dev] [TripleO] Deep dive on Ansible Integration Thursday Feb 22 1400UTC

[David Moreau Simard]

Thanks for recording it!

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Mon, Feb 19, 2018 at 9:41 AM, James Slagle  wrote:
> As mentioned in the TripleO meeting last week, I volunteered to give a
> deep dive on the state of TripleO and Ansible integration with
> config-download.
>
> I'll do that this week on Thursday February 22nd at 1400UTC.
>
> Anyone can join via bluejeans: https://bluejeans.com/7754237859/
> Etherpad: https://bluejeans.com/7754237859/
> Optional pre-reading:
> https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/ansible_config_download.html
>
> The session will be recorded and later uploaded to Youtube at:
> https://www.youtube.com/channel/UCNGDxZGwUELpgaBoLvABsTA
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing 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] [release][ptl] Final Queens RC Deadline

[David Moreau Simard]

On Mon, Feb 19, 2018 at 10:44 AM, Sean McGinnis  wrote:
> Hey everyone,
>
> Just a quick reminder that Thursday, 22 March, is the deadline for any final
> Queens release candidates. After this point we will enter a quiet period for a
> week in preparation of tagging the final Queens release during the PTG week.

February, right ?

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] [tripleo] Draft schedule for PTG

[Emilien Macchi]

Alex and I have been working on the agenda for next week, based on what
people proposed in topics.

The draft calendar is visible here:
https://calendar.google.com/calendar/embed?src=tgpb5tv12mlu7kge5oqertje78%40group.calendar.google.com=Europe%2FDublin

Also you can import the ICS from:
https://calendar.google.com/calendar/ical/tgpb5tv12mlu7kge5oqertje78%40group.calendar.google.com/public/basic.ics

Note this is a draft - we would love your feedback about the proposal.

Some sessions might be too short or too long? You to tell us. (Please look
at event details for descriptions).
Also, for each session we need a "driver", please tell us if you volunteer
to do it.

Please let us know here and we'll make adjustment, we have plenty of room
for it.

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Doug Hellmann]

Excerpts from Michael Bayer's message of 2018-02-19 10:55:52 -0500:
> wow that's heavy-handed.  should that be in an oslo utility package of
> some kind ?

I thought about that, but figured we should wait and see whether we
actually want to take the approach before polishing it. If we do we can
add a function in oslo.utils.

> 
> On Mon, Feb 19, 2018 at 10:52 AM, Doug Hellmann  wrote:
> > Excerpts from Doug Hellmann's message of 2018-02-19 10:15:34 -0500:
> >> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
> >> > Hi list -
> >> >
> >> > Apparently Cinder was misled by my deprecations within the
> >> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> >> > in https://review.openstack.org/#/c/522290/ the assumption was made
> >> > that these should be imported from oslo_db.tests.sqlalchemy.This
> >> > is an immense mistake on my part that I did not expect people to go
> >> > looking for the same names elsewhere in private packages and now we
> >> > have a serious downstream issue as these modules are not packaged, as
> >> > well as the possibility that the oslo_db.tests. package is now locked
> >> > in time and I have to add deprecations there also.
> >> >
> >> > If anyone knows of projects (or feels like helping me search) that are
> >> > importing *anything* from oslo_db.tests these must be reverted ASAP.
> >> >
> >>
> >> If we have modules or classes we don't expect people to be importing
> >> directly, we need to prefix the names with _ to comply with the naming
> >> conventions we have previously told everyone to look for to recognize
> >> private code.
> >>
> >> I think it's safe to treat "tests" as an exception (after resolving
> >> this case) but we should probably document that.
> >>
> >> Doug
> >
> > Once we resolve the current set of imports, we can land a patch like
> > https://review.openstack.org/545859 to prevent this from happening in
> > the future.
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

On Mon, Feb 19, 2018 at 10:57 AM, Andrey Kurilin  wrote:
> As for downstream you can do whatever you want, but it looks like this issue
> should be solved in upstream. I mean if "tests" directory is located at the
> top level of the repo, no one will use it.

again, the search at
http://codesearch.openstack.org/?q=oslo_db.tests=nope==
shows four downstream projects using it.   I am now submitting gerrits
for all four and also getting internal downstream patches to fix
internally.  this is as bad as it gets.




> Also, setuptools supports `exclude` option which should solve the issue as
> well.
>
>
>
> 2018-02-19 17:41 GMT+02:00 Michael Bayer :
>>
>> On Mon, Feb 19, 2018 at 10:39 AM, Andrey Kurilin 
>> wrote:
>> > Can someone explain me the reason for including "tests" module into
>> > packages?
>>
>> the "tests" module should not be inside packages.   Downstream we have
>> CI running Cinder's test suite against packaged dependencies, which
>> fails because we don't package oslo_db.tests.
>>
>>
>> >
>> >
>> > 2018-02-19 17:00 GMT+02:00 Michael Bayer :
>> >>
>> >> Hi list -
>> >>
>> >> Apparently Cinder was misled by my deprecations within the
>> >> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
>> >> in https://review.openstack.org/#/c/522290/ the assumption was made
>> >> that these should be imported from oslo_db.tests.sqlalchemy.This
>> >> is an immense mistake on my part that I did not expect people to go
>> >> looking for the same names elsewhere in private packages and now we
>> >> have a serious downstream issue as these modules are not packaged, as
>> >> well as the possibility that the oslo_db.tests. package is now locked
>> >> in time and I have to add deprecations there also.
>> >>
>> >> If anyone knows of projects (or feels like helping me search) that are
>> >> importing *anything* from oslo_db.tests these must be reverted ASAP.
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Kurilin.
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Andrey Kurilin]

Imo, it creates more problems than profits. If someone wants to change the
code and run tests -> use git repositories. Prepared python package is not
about this.

2018-02-19 17:57 GMT+02:00 Doug Hellmann :

> IIRC we started doing that so that consumers building their own packages
> can run the tests for the packages easily. I don't know how many people
> are doing that, and apparently at least some downstream consumers aren't
> packaging everything anyway so they couldn't run those tests.
>
> Excerpts from Andrey Kurilin's message of 2018-02-19 17:39:11 +0200:
> > Can someone explain me the reason for including "tests" module into
> > packages?
> >
> > 2018-02-19 17:00 GMT+02:00 Michael Bayer :
> >
> > > Hi list -
> > >
> > > Apparently Cinder was misled by my deprecations within the
> > > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> > > in https://review.openstack.org/#/c/522290/ the assumption was made
> > > that these should be imported from oslo_db.tests.sqlalchemy.This
> > > is an immense mistake on my part that I did not expect people to go
> > > looking for the same names elsewhere in private packages and now we
> > > have a serious downstream issue as these modules are not packaged, as
> > > well as the possibility that the oslo_db.tests. package is now locked
> > > in time and I have to add deprecations there also.
> > >
> > > If anyone knows of projects (or feels like helping me search) that are
> > > importing *anything* from oslo_db.tests these must be reverted ASAP.
> > >
> > > 
> __
> > > OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Andrey Kurilin]

As for downstream you can do whatever you want, but it looks like this
issue should be solved in upstream. I mean if "tests" directory is located
at the top level of the repo, no one will use it.
Also, setuptools supports `exclude` option which should solve the issue as
well.



2018-02-19 17:41 GMT+02:00 Michael Bayer :

> On Mon, Feb 19, 2018 at 10:39 AM, Andrey Kurilin 
> wrote:
> > Can someone explain me the reason for including "tests" module into
> > packages?
>
> the "tests" module should not be inside packages.   Downstream we have
> CI running Cinder's test suite against packaged dependencies, which
> fails because we don't package oslo_db.tests.
>
>
> >
> >
> > 2018-02-19 17:00 GMT+02:00 Michael Bayer :
> >>
> >> Hi list -
> >>
> >> Apparently Cinder was misled by my deprecations within the
> >> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> >> in https://review.openstack.org/#/c/522290/ the assumption was made
> >> that these should be imported from oslo_db.tests.sqlalchemy.This
> >> is an immense mistake on my part that I did not expect people to go
> >> looking for the same names elsewhere in private packages and now we
> >> have a serious downstream issue as these modules are not packaged, as
> >> well as the possibility that the oslo_db.tests. package is now locked
> >> in time and I have to add deprecations there also.
> >>
> >> If anyone knows of projects (or feels like helping me search) that are
> >> importing *anything* from oslo_db.tests these must be reverted ASAP.
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > 
> __
> > OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Doug Hellmann]

IIRC we started doing that so that consumers building their own packages
can run the tests for the packages easily. I don't know how many people
are doing that, and apparently at least some downstream consumers aren't
packaging everything anyway so they couldn't run those tests.

Excerpts from Andrey Kurilin's message of 2018-02-19 17:39:11 +0200:
> Can someone explain me the reason for including "tests" module into
> packages?
> 
> 2018-02-19 17:00 GMT+02:00 Michael Bayer :
> 
> > Hi list -
> >
> > Apparently Cinder was misled by my deprecations within the
> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> > in https://review.openstack.org/#/c/522290/ the assumption was made
> > that these should be imported from oslo_db.tests.sqlalchemy.This
> > is an immense mistake on my part that I did not expect people to go
> > looking for the same names elsewhere in private packages and now we
> > have a serious downstream issue as these modules are not packaged, as
> > well as the possibility that the oslo_db.tests. package is now locked
> > in time and I have to add deprecations there also.
> >
> > If anyone knows of projects (or feels like helping me search) that are
> > importing *anything* from oslo_db.tests these must be reverted ASAP.
> >
> > __
> > OpenStack Development Mailing 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

wow that's heavy-handed.  should that be in an oslo utility package of
some kind ?

On Mon, Feb 19, 2018 at 10:52 AM, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2018-02-19 10:15:34 -0500:
>> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
>> > Hi list -
>> >
>> > Apparently Cinder was misled by my deprecations within the
>> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
>> > in https://review.openstack.org/#/c/522290/ the assumption was made
>> > that these should be imported from oslo_db.tests.sqlalchemy.This
>> > is an immense mistake on my part that I did not expect people to go
>> > looking for the same names elsewhere in private packages and now we
>> > have a serious downstream issue as these modules are not packaged, as
>> > well as the possibility that the oslo_db.tests. package is now locked
>> > in time and I have to add deprecations there also.
>> >
>> > If anyone knows of projects (or feels like helping me search) that are
>> > importing *anything* from oslo_db.tests these must be reverted ASAP.
>> >
>>
>> If we have modules or classes we don't expect people to be importing
>> directly, we need to prefix the names with _ to comply with the naming
>> conventions we have previously told everyone to look for to recognize
>> private code.
>>
>> I think it's safe to treat "tests" as an exception (after resolving
>> this case) but we should probably document that.
>>
>> Doug
>
> Once we resolve the current set of imports, we can land a patch like
> https://review.openstack.org/545859 to prevent this from happening in
> the future.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-02-19 10:15:34 -0500:
> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
> > Hi list -
> > 
> > Apparently Cinder was misled by my deprecations within the
> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> > in https://review.openstack.org/#/c/522290/ the assumption was made
> > that these should be imported from oslo_db.tests.sqlalchemy.This
> > is an immense mistake on my part that I did not expect people to go
> > looking for the same names elsewhere in private packages and now we
> > have a serious downstream issue as these modules are not packaged, as
> > well as the possibility that the oslo_db.tests. package is now locked
> > in time and I have to add deprecations there also.
> > 
> > If anyone knows of projects (or feels like helping me search) that are
> > importing *anything* from oslo_db.tests these must be reverted ASAP.
> > 
> 
> If we have modules or classes we don't expect people to be importing
> directly, we need to prefix the names with _ to comply with the naming
> conventions we have previously told everyone to look for to recognize
> private code.
> 
> I think it's safe to treat "tests" as an exception (after resolving
> this case) but we should probably document that.
> 
> Doug

Once we resolve the current set of imports, we can land a patch like
https://review.openstack.org/545859 to prevent this from happening in
the future.

Doug

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

[openstack-dev] [release][ptl] Final Queens RC Deadline

[Sean McGinnis]

Hey everyone,

Just a quick reminder that Thursday, 22 March, is the deadline for any final
Queens release candidates. After this point we will enter a quiet period for a
week in preparation of tagging the final Queens release during the PTG week.

If you have any patches merged to stable/queens that are critical to be part of
the Queens release, please make sure everything has been backported and propose
a new RC before the deadline.

And just remember, after the official release is complete, that will open up
things for doing normal stable releases of Queens.

PTLs, after Thursday, please watch for a patch from the release management team
tagging the final release. While not required, your ack on that patch would be
appreciated.

Thanks!

Sean


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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

On Mon, Feb 19, 2018 at 10:39 AM, Andrey Kurilin  wrote:
> Can someone explain me the reason for including "tests" module into
> packages?

the "tests" module should not be inside packages.   Downstream we have
CI running Cinder's test suite against packaged dependencies, which
fails because we don't package oslo_db.tests.


>
>
> 2018-02-19 17:00 GMT+02:00 Michael Bayer :
>>
>> Hi list -
>>
>> Apparently Cinder was misled by my deprecations within the
>> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
>> in https://review.openstack.org/#/c/522290/ the assumption was made
>> that these should be imported from oslo_db.tests.sqlalchemy.This
>> is an immense mistake on my part that I did not expect people to go
>> looking for the same names elsewhere in private packages and now we
>> have a serious downstream issue as these modules are not packaged, as
>> well as the possibility that the oslo_db.tests. package is now locked
>> in time and I have to add deprecations there also.
>>
>> If anyone knows of projects (or feels like helping me search) that are
>> importing *anything* from oslo_db.tests these must be reverted ASAP.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

On Mon, Feb 19, 2018 at 10:15 AM, Doug Hellmann  wrote:
> Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
>> Hi list -
>>
>> Apparently Cinder was misled by my deprecations within the
>> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
>> in https://review.openstack.org/#/c/522290/ the assumption was made
>> that these should be imported from oslo_db.tests.sqlalchemy.This
>> is an immense mistake on my part that I did not expect people to go
>> looking for the same names elsewhere in private packages and now we
>> have a serious downstream issue as these modules are not packaged, as
>> well as the possibility that the oslo_db.tests. package is now locked
>> in time and I have to add deprecations there also.
>>
>> If anyone knows of projects (or feels like helping me search) that are
>> importing *anything* from oslo_db.tests these must be reverted ASAP.
>>
>
> If we have modules or classes we don't expect people to be importing
> directly, we need to prefix the names with _ to comply with the naming
> conventions we have previously told everyone to look for to recognize
> private code.

doing that now

>
> I think it's safe to treat "tests" as an exception (after resolving
> this case) but we should probably document that.

the example of three projects that did this without any of us knowing
should illustrate that we really can't make that assumption.


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

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Andrey Kurilin]

Can someone explain me the reason for including "tests" module into
packages?


2018-02-19 17:00 GMT+02:00 Michael Bayer :

> Hi list -
>
> Apparently Cinder was misled by my deprecations within the
> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> in https://review.openstack.org/#/c/522290/ the assumption was made
> that these should be imported from oslo_db.tests.sqlalchemy.This
> is an immense mistake on my part that I did not expect people to go
> looking for the same names elsewhere in private packages and now we
> have a serious downstream issue as these modules are not packaged, as
> well as the possibility that the oslo_db.tests. package is now locked
> in time and I have to add deprecations there also.
>
> If anyone knows of projects (or feels like helping me search) that are
> importing *anything* from oslo_db.tests these must be reverted ASAP.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Sean McGinnis]

On Mon, Feb 19, 2018 at 04:13:04PM +0100, Andreas Jaeger wrote:
> On 2018-02-19 16:00, Michael Bayer wrote:
> > Hi list -
> > 
> > Apparently Cinder was misled by my deprecations within the
> > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> > in https://review.openstack.org/#/c/522290/ the assumption was made
> > that these should be imported from oslo_db.tests.sqlalchemy.This
> > is an immense mistake on my part that I did not expect people to go
> > looking for the same names elsewhere in private packages and now we
> > have a serious downstream issue as these modules are not packaged, as
> > well as the possibility that the oslo_db.tests. package is now locked
> > in time and I have to add deprecations there also.
> > 
> > If anyone knows of projects (or feels like helping me search) that are
> > importing *anything* from oslo_db.tests these must be reverted ASAP.
> 
> cinder, glance, ironic,... see
> 
> http://codesearch.openstack.org/?q=oslo_db.tests=nope==
> 
> ;(
> 
> Andreas

I don't see any recommendation in the deprecation warning. What should we be
using now instead?

Sean

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Doug Hellmann]

Excerpts from Michael Bayer's message of 2018-02-19 10:00:59 -0500:
> Hi list -
> 
> Apparently Cinder was misled by my deprecations within the
> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> in https://review.openstack.org/#/c/522290/ the assumption was made
> that these should be imported from oslo_db.tests.sqlalchemy.This
> is an immense mistake on my part that I did not expect people to go
> looking for the same names elsewhere in private packages and now we
> have a serious downstream issue as these modules are not packaged, as
> well as the possibility that the oslo_db.tests. package is now locked
> in time and I have to add deprecations there also.
> 
> If anyone knows of projects (or feels like helping me search) that are
> importing *anything* from oslo_db.tests these must be reverted ASAP.
> 

If we have modules or classes we don't expect people to be importing
directly, we need to prefix the names with _ to comply with the naming
conventions we have previously told everyone to look for to recognize
private code.

I think it's safe to treat "tests" as an exception (after resolving
this case) but we should probably document that.

Doug

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

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Andreas Jaeger]

On 2018-02-19 16:00, Michael Bayer wrote:
> Hi list -
> 
> Apparently Cinder was misled by my deprecations within the
> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
> in https://review.openstack.org/#/c/522290/ the assumption was made
> that these should be imported from oslo_db.tests.sqlalchemy.This
> is an immense mistake on my part that I did not expect people to go
> looking for the same names elsewhere in private packages and now we
> have a serious downstream issue as these modules are not packaged, as
> well as the possibility that the oslo_db.tests. package is now locked
> in time and I have to add deprecations there also.
> 
> If anyone knows of projects (or feels like helping me search) that are
> importing *anything* from oslo_db.tests these must be reverted ASAP.

cinder, glance, ironic,... see

http://codesearch.openstack.org/?q=oslo_db.tests=nope==

;(

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] [charms]

[Liam Young]

On Mon, Feb 19, 2018 at 9:05 AM, Dmitrii Shcherbakov
 wrote:
> Hi Liam,
>
>> I was recently looking at how to support custom configuration that relies
>> on post deployment setup.
>
> I would describe the problem in general as follows:
>
> 1) charms can get context not only from Juju (config options, relation data,
> leader data), environment (operating system release, OpenStack release,
> services running etc.) but also from a stateful data store (e.g. a Keystone
> database);
> 2) it's not easy to track application state from a charm because:
> authentication is needed to fetch persistent state, notifications from a
> data store cannot be reliably set up because charm code is ran periodically
> and it is not always present in memory (polling is neither timely nor
> efficient). Another problem is that software that holds the state needs to
> support data change notifications which raises version compatibility
> questions.
>
> By using actions we move the responsibility for data retrieval and change
> notifications to an operator but a more generic scenario would be modeling a
> feedback loop from an application to Juju as a modeling system where changes
> can be either automatic or gated by an operator (an orchestrator). Making it
> automatic would mean that a service would get notifications/poll data from a
> state store and would be authorized to use Juju client to make certain
> changes.

This is an interesting idea, but there is no such mechanism within
Juju that I know of.

>
> Another problem to solve is maintenance of that state: if we start
> maintaining a key-value DB in leader settings we need to think about data
> migration over time and how to access the current state.

Data migration from where to where? We access the current state by retrieving
the data from leader db, or am I missing something here?

> In other words, in
> CRUD, the "C" part is relatively straightforward, "R" is more complicated
> with large data sets (if I have a lot of leader data, how do I interpret it
> efficiently?),

Perhaps I'm being naive but I don't see these developing into data
sets large enough
to cause performance problems.

> "UD" is less clear - seems like there will have to be 3 or 4
> actions per feature for C, [R], U and D or one action that can multiplex
> commands.

Each time the action is run the context associated with the action is deleted
and recreated. If an action argument is unset I guess we could interpret that as
leave-unchanged.

>
> This brings me to the question of how is it different from state-specific
> config values with a complex structure.

To my mind the difference is complexity for the end user. An action has clearly
defined arguments and the charm action code looks after forming this into
the correct context.

> Instead of leader data, a per-charm
> config option could hold state data in some format namespaced by a feature
> name or config file name to render. A data model would be needed to make
> sure we can create versioned application-specific state buckets (e.g. for
> upgrades, hold both states, then remove the old one).
>
> Application version-specific config values is something not modeled in Juju
> although custom application versions are present
> (https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set).
> Version information has to be set via a hook tool which means that it has to
> come from a custom config option anyway. Each charm has its own method to
> specify an application version and config dependencies are not modeled
> explicitly - one has to implement that logic in a charm without any Juju API
> for charms present the way I see it.
>
> config('key', 'app-version') - would be something to aim for.
>
> Do you have any thoughts about leader data vs a special complex config
> option per charm and versioning?
>
> Thanks!

Thanks for the feedback Dmitrii

__
OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[Jeremy Stanley]

On 2018-02-18 19:25:07 -0800 (-0800), Emilien Macchi wrote:
[...]
> My recommendation for TripleO devs: use the old syntax if you want your
> code to be tested by RDO Third party CI
[...]

This is hopefully only a temporary measure? I think I've heard it
mentioned that planning is underway to switch that CI system to Zuul
v3 (perhaps after 3.0.0 officially releases soon).
-- 
Jeremy Stanley


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

[openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

[Michael Bayer]

Hi list -

Apparently Cinder was misled by my deprecations within the
oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and
in https://review.openstack.org/#/c/522290/ the assumption was made
that these should be imported from oslo_db.tests.sqlalchemy.This
is an immense mistake on my part that I did not expect people to go
looking for the same names elsewhere in private packages and now we
have a serious downstream issue as these modules are not packaged, as
well as the possibility that the oslo_db.tests. package is now locked
in time and I have to add deprecations there also.

If anyone knows of projects (or feels like helping me search) that are
importing *anything* from oslo_db.tests these must be reverted ASAP.

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

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

updates:
- tempest-full-queens and tempest-full-py3-queens are now available for
testing of branchless repositories [0]. They are used for tempest and
devstack-gate. If you own a tempest plugin in a branchless repo, you may
consider adding similar jobs to your plugin if you use it for tests on
stable/queen as well.
- if you have migrated jobs based on devstack-tempest please let me know,
I'm building reference docs and I'd like to include as many examples as
possible
- work on multi-node is in progress, but not ready still - you can follow
the patches in the multinode branch [1]
- updates on some of the points from my previous email are inline below

Andrea Frittoli (andreaf)

[0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
[1]
https://review.openstack.org/#/q/status:open++branch:master+topic:multinode


On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli 
wrote:

> Dear all,
>
> this is the first or a series of ~regular updates on the migration of
> Tempest / Grenade jobs to  Zuul v3 native.
>
> The QA team together with the infra team are working on providing the
> OpenStack community with a set of base Tempest / Grenade jobs that can be
> used as a basis to write new CI jobs / migrate existing legacy ones with a
> minimal effort and very little or no Ansible knowledge as a precondition.
>
> The effort is tracked in an etherpad [0]; I'm trying to keep the
> etherpad up to date but it may not always be a source of truth.
>
> Useful jobs available so far:
> - devstack-tempest [0] is a simple tempest/devstack job that runs keystone
> glance nova cinder neutron swift and tempest *smoke* filter
> - tempest-full [1] is similar but runs a full test run - it replaces the
> legacy tempest-dsvm-neutron-full from the integrated gate
> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
> legacy tempest-dsvm-py35
>

Some more details on this topic: what I did not mention in my previous
email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
create Zuul V3 Tempest / Grenade native jobs for your projects you need to
through away the legacy playbooks and defined new jobs in .zuul.yaml, as
documented in the zuul v3 docs [2].
The parent job for a single node Tempest job will usually be
devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].

[2]
https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs

[3] http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21

[4] https://review.openstack.org/#/c/543048/5


>
> Both tempest-full and tempest-full-py3 are part of integrated-gate
> templates, starting from stable/queens on.
> The other stable branches still run the legacy jobs, since
> devstack ansible changes have not been backported (yet). If we do backport
> it will be up to pike maximum.
>
> Those jobs work in single node mode only at the moment. Enabling multinode
> via job configuration only require a new Zuul feature [4][5] that should be
> available soon; the new feature allows defining host/group variables in the
> job definition, which means setting variables which are specific to one
> host or a group of hosts.
> Multinode DVR and Ironic jobs will require migration of the ovs-* roles
> form devstack-gate to devstack as well.
>
> Grenade jobs (single and multinode) are still legacy, even if the *legacy*
> word has been removed from the name.
> They are currently temporarily hosted in the neutron repository. They are
> going to be implemented as Zuul v3 native in the grenade repository.
>
> Roles are documented, and a couple of migration tips for DEVSTACK_GATE
> flags is available in the etherpad [0]; more comprehensive examples /
> docs will be available as soon as possible.
>
> Please let me know if you find this update useful and / or if you would
> like to see different information in it.
> I will send further updates as soon as significant changes / new features
> become available.
>
> Andrea Frittoli (andreaf)
>
> [0] https://etherpad.openstack.org/p/zuulv3-native-devstack-tempest-jobs
> [1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n1
> [2] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n29
> [3] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n47
> [4] https://etherpad.openstack.org/p/zuulv3-group-variables
> [5] https://review.openstack.org/#/c/544562/
>
__
OpenStack Development Mailing 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] [TripleO] Deep dive on Ansible Integration Thursday Feb 22 1400UTC

[James Slagle]

As mentioned in the TripleO meeting last week, I volunteered to give a
deep dive on the state of TripleO and Ansible integration with
config-download.

I'll do that this week on Thursday February 22nd at 1400UTC.

Anyone can join via bluejeans: https://bluejeans.com/7754237859/
Etherpad: https://bluejeans.com/7754237859/
Optional pre-reading:
https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/ansible_config_download.html

The session will be recorded and later uploaded to Youtube at:
https://www.youtube.com/channel/UCNGDxZGwUELpgaBoLvABsTA

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] Queens RC review dashboard

[Lance Bragstad]

Nice, thanks for the reviews. I'll check with the release team if we don't
have a stable core approve them by midday.

On Sun, Feb 18, 2018 at 6:31 PM, Matt Riedemann  wrote:

> On 2/1/2018 9:51 AM, Lance Bragstad wrote:
>
>> Just like with feature freeze, I put together a review dashboard that
>> contains patches we need to land in order to cut a release candidate
>> [0]. I'll be adding more patches throughout the day, but so far there
>> are 21 changes there waiting for review. If there is something I missed,
>> please don't hesitate to ping me and I'll get it added. Thanks for all
>> the hard work. We're on the home stretch!
>>
>> [0]https://goo.gl/XVw3wr
>>
>
> I reviewed your open stable/queens changes, left a question in one about
> how you want to handle the 'fixes' release note.
>
> I thought since I'm stable core I could +2 these but I can't, looks like
> keystone-stable-maint or the release core team can do that.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing 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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Bogdan Dobrelya]

On 2/19/18 3:18 PM, Sofer Athlan-Guyot wrote:

Hi,

Emilien Macchi  writes:


Upgrading YAQL from 1.1.0 to 1.1.3 breaks advanced queries with groupBy
aggregation.

The commit that broke it is
https://github.com/openstack/yaql/commit/3fb91784018de335440b01b3b069fe45dc53e025

It broke TripleO: https://bugs.launchpad.net/tripleo/+bug/1750032
But Alex and I figured (after a strong headache) that we needed to update
the query like this: https://review.openstack.org/545498



This is great, but we still have a pending issue.  Mixed upgrade jobs
are failing from Pike on.  Those are very experimental jobs[1][2] but
the error is present.  The problem being that in mixed version we have
the 1.1.3 yaql version (master undercloud) but not the fix in the
templates which are either N-1 or N-3.

But if we get the fix in previous version, the deployment shouldn't work
anymore as we would not have yaql 1.1.3, but the new syntax.


With a backport of the YAQL fixes for tht made for Pike, would it be the 
full fix to make a backport of yaql 1.1.3 for Pike repos as well? Or am 
I missing something?




It's not only CI which is affected.  Any kind of mixed version operation
would fail as well.

[1] P->Q: 
http://logs.openstack.org/62/545762/3/experimental/tripleo-ci-centos-7-scenario001-multinode-oc-upgrade/afc98a5/logs/undercloud/home/zuul/overcloud_deploy.log.txt.gz#_2018-02-19_09_48_54
[2] Fast Forward Upgrade: 
http://logs.openstack.org/86/525686/55/experimental/tripleo-ci-centos-7-scenario001-multinode-ffu-upgrade/5412555/logs/undercloud/home/zuul/overcloud_deploy.log.txt.gz


It would be great to avoid this kind of change within minor versions,
please please.

Happy weekend,

PS: I'm adding YAQL to my linkedin profile right now.
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Sofer Athlan-Guyot]

Hi,

Emilien Macchi  writes:

> Upgrading YAQL from 1.1.0 to 1.1.3 breaks advanced queries with groupBy
> aggregation.
>
> The commit that broke it is
> https://github.com/openstack/yaql/commit/3fb91784018de335440b01b3b069fe45dc53e025
>
> It broke TripleO: https://bugs.launchpad.net/tripleo/+bug/1750032
> But Alex and I figured (after a strong headache) that we needed to update
> the query like this: https://review.openstack.org/545498
>

This is great, but we still have a pending issue.  Mixed upgrade jobs
are failing from Pike on.  Those are very experimental jobs[1][2] but
the error is present.  The problem being that in mixed version we have
the 1.1.3 yaql version (master undercloud) but not the fix in the
templates which are either N-1 or N-3.

But if we get the fix in previous version, the deployment shouldn't work
anymore as we would not have yaql 1.1.3, but the new syntax.

It's not only CI which is affected.  Any kind of mixed version operation
would fail as well.

[1] P->Q: 
http://logs.openstack.org/62/545762/3/experimental/tripleo-ci-centos-7-scenario001-multinode-oc-upgrade/afc98a5/logs/undercloud/home/zuul/overcloud_deploy.log.txt.gz#_2018-02-19_09_48_54
[2] Fast Forward Upgrade: 
http://logs.openstack.org/86/525686/55/experimental/tripleo-ci-centos-7-scenario001-multinode-ffu-upgrade/5412555/logs/undercloud/home/zuul/overcloud_deploy.log.txt.gz

> It would be great to avoid this kind of change within minor versions,
> please please.
>
> Happy weekend,
>
> PS: I'm adding YAQL to my linkedin profile right now.
> -- 
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing 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] [PTG] Project interviews at the PTG

[Rich Bowen]

I promise this is the last time I'll bug you about this. (Except 
on-site, of course!)


I still have lots and lots of space for team/project/whatever interviews 
at the PTG. You can sign up at 
https://docs.google.com/spreadsheets/d/1MK7rCgYXCQZP1AgQ0RUiuc-cEXIzW5RuRzz5BWhV4nQ/edit#gid=0 



You can see some examples of previous interviews at 
http://youtube.com/RDOCommunity


For the most part, interviews focus on what your team accomplished 
during the Queens cycle and what you want to work on in Rocky. However, 
we can also talk about other things like governance, community, related 
projects, licensing, or anything else that you feel is related to the 
OpenStack community.


I encourage you to talk with your team, and find 2 or 3 people who can 
speak most eloquently about what you are trying to do, and find a time 
that works for you.


I'll also have the schedules posted on-site, so you can sign up there, 
if you're still unsure of your schedule. But signing up ahead of time 
lets me know whether Wednesday is really a vacation day. ;-)


See you in Dublin!

--
Rich Bowen - rbo...@redhat.com
@RDOcommunity // @CentOSProject // @rbowen

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

Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

[Petr Kovar]

On Fri, 16 Feb 2018 17:49:37 +0100
Thomas Goirand  wrote:

> On 02/16/2018 03:42 PM, Petr Kovar wrote:
> > On Thu, 15 Feb 2018 09:31:19 +0100
> > Thomas Goirand  wrote:
> > 
> >> Hi,
> >>
> >> Since I'm getting some pressure from other DDs to actively remove Py2
> >> support from my packages, I'm very much considering switching all of the
> >> Debian packages for Queens to using exclusively Py3. I would have like
> >> to read some opinions about this. Is it a good time for such move? I
> >> hope it is, because I'd like to maintain as few Python package with Py2
> >> support at the time of Debian Buster freeze.
> >>
> >> Also, doing Queens, I've noticed that os-xenapi is still full of py2
> >> only stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
> >>
> >> https://review.openstack.org/544809
> > 
> > Hey Thomas, slightly off-topic to this, but would it be a good idea to
> > resurrect OpenStack install guides for Debian if Debian packages are still
> > maintained?
> 
> Yes it would. I'm not sure where to start, since all the doc has moved
> to individual projects.

Right, I'd probably start with projects listed in minimal deployment:

https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment

Copying Ubuntu-specific pages might save some time. Old content is
still available from
https://github.com/openstack/openstack-manuals/tree/a1f1748478125ccd68d90a98ccc06c7ec359d3a0/doc/install-guide/source.

Best,
pk

__
OpenStack Development Mailing 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] [ffu][upgrades] Dublin PTG room and agenda

[Lee Yarwood]

Hello all,

A very late mail to highlight that there will once again be a 1 day
track/room dedicated to talking about Fast-forward upgrades at the
upcoming PTG in Dublin. The etherpad for which is listed below:

https://etherpad.openstack.org/p/ffu-ptg-rocky

Please feel free to add items to the pad, I'd really like to see some
concrete action items finally come from these discussions ahead of R.

Thanks in advance and see you in Dublin!

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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

Re: [openstack-dev] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Sergii Golovatiuk]

Hi,

On Sat, Feb 17, 2018 at 10:40 PM, Dan Prince  wrote:
> Thanks for the update Emilien. A couple of things to add:
>
> 1) This was really difficult to pin-point via the Heat stack error
> message ('list index out of range'). I actually had to go and add
> LOG.debug statements to Heat to get to the bottom of it. I aim to sync
> with a few of the Heat folks next week on this to see if we can do
> better here.

YAQL has CLI util that can be used for debugging queries. I found it
quite useful.

>
> 2) I had initially thought it would have been much better to revert
> the (breaking) change to python-yaql. That said it was from 2016! So I
> think our window of opportunity for the revert is probably way too
> large to consider that. Sounds like we need to publish the yaql
> package more often in RDO, etc. So your patch to update our queries is
> probably our only option.

That's true.

>
> On Fri, Feb 16, 2018 at 8:36 PM, Emilien Macchi  wrote:
>> Upgrading YAQL from 1.1.0 to 1.1.3 breaks advanced queries with groupBy
>> aggregation.
>>
>> The commit that broke it is
>> https://github.com/openstack/yaql/commit/3fb91784018de335440b01b3b069fe45dc53e025
>>
>> It broke TripleO: https://bugs.launchpad.net/tripleo/+bug/1750032
>> But Alex and I figured (after a strong headache) that we needed to update
>> the query like this: https://review.openstack.org/545498
>>
>> It would be great to avoid this kind of change within minor versions, please
>> please.
>>
>> Happy weekend,
>>
>> PS: I'm adding YAQL to my linkedin profile right now.
>
> Be careful here. Do you really want to write YAQL queries all day!
>
> Dan
>
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing 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



-- 
Best Regards,
Sergii Golovatiuk

__
OpenStack Development Mailing 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] [charms]

[Dmitrii Shcherbakov]

Hi Liam,

> I was recently looking at how to support custom configuration that 
relies on post deployment setup.


I would describe the problem in general as follows:

1) charms can get context not only from Juju (config options, relation 
data, leader data), environment (operating system release, OpenStack 
release, services running etc.) but also from a stateful data store 
(e.g. a Keystone database);
2) it's not easy to track application state from a charm because: 
authentication is needed to fetch persistent state, notifications from a 
data store cannot be reliably set up because charm code is ran 
periodically and it is not always present in memory (polling is neither 
timely nor efficient). Another problem is that software that holds the 
state needs to support data change notifications which raises version 
compatibility questions.


By using actions we move the responsibility for data retrieval and 
change notifications to an operator but a more generic scenario would be 
modeling a feedback loop from an application to Juju as a modeling 
system where changes can be either automatic or gated by an operator (an 
orchestrator). Making it automatic would mean that a service would get 
notifications/poll data from a state store and would be authorized to 
use Juju client to make certain changes.


Another problem to solve is maintenance of that state: if we start 
maintaining a key-value DB in leader settings we need to think about 
data migration over time and how to access the current state. In other 
words, in CRUD, the "C" part is relatively straightforward, "R" is more 
complicated with large data sets (if I have a lot of leader data, how do 
I interpret it efficiently?), "UD" is less clear - seems like there will 
have to be 3 or 4 actions per feature for C, [R], U and D or one action 
that can multiplex commands.


This brings me to the question of how is it different from 
state-specific config values with a complex structure. Instead of leader 
data, a per-charm config option could hold state data in some format 
namespaced by a feature name or config file name to render. A data model 
would be needed to make sure we can create versioned 
application-specific state buckets (e.g. for upgrades, hold both states, 
then remove the old one).


Application version-specific config values is something not modeled in 
Juju although custom application versions are present 
(https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set). 
Version information has to be set via a hook tool which means that it 
has to come from a custom config option anyway. Each charm has its own 
method to specify an application version and config dependencies are not 
modeled explicitly - one has to implement that logic in a charm without 
any Juju API for charms present the way I see it.


config('key', 'app-version') - would be something to aim for.

Do you have any thoughts about leader data vs a special complex config 
option per charm and versioning?


Thanks!

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