Re: [openstack-dev] [zVM] [python3] tox/zuul issues for zVM OpenStack

2018-10-15 Thread Chen CH Ji
Thank you for your detailed information, we will will on this and add you as reviewer when it's ready, thanks~
 
- Original message -From: William M Edmonds/Raleigh/IBMTo: Chen CH Ji/China/IBM@IBMCN, "OpenStack Development Mailing List \(not for usage questions\)" Cc:Subject: [zVM] [python3] tox/zuul issues for zVM OpenStackDate: Mon, Oct 15, 2018 11:06 PM The current tox.ini for ceilometer-zvm includes this line [1] similar to what ceilometer-powervm was doing up until recently:   -egit+https://github.com/openstack/ceilometer@master#egg=ceilometerWe found that this no longer works since ceilometer was added to upper-constraints [2]. We first got things working again by [3] and are now improving on that by [4]. I expect you will need to make similar changes.I was going to propose this to ceilometer-zvm for you, but then noticed that you don't even have a zuul.yaml file. You're missing changes like [5] adding lower-constraints checking and [6] for the python3-first effort. So that is probably a bigger issue to address first (and for networking-powervm and nova-zvm-virt-driver as well as ceilometer-zvm). When you get to the python3 stuff, I suggest you work with dhellmann on that. He's got scripts to generate at least some of those commits.[1] http://git.openstack.org/cgit/openstack/ceilometer-zvm/tree/tox.ini#n19[2] https://review.openstack.org/#/c/601498[3] https://review.openstack.org/#/c/609058/[4] https://review.openstack.org/#/c/609823/[5] https://review.openstack.org/#/c/555358/[6] https://review.openstack.org/#/c/594984/W. Matthew EdmondsSr. Software Engineer, IBM Power SystemsEmail: edmon...@us.ibm.comPhone: (919) 543-7538 / Tie-Line: 441-7538
 


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


Re: [openstack-dev] [nova] shall we do a spec review day next tuesday oct 23?

2018-10-15 Thread Sylvain Bauza
Le lun. 15 oct. 2018 à 19:07, melanie witt  a écrit :

> Hey all,
>
> Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was
> thinking it would be a good idea to have a spec review day next week on
> Tuesday Oct 23 to spend some focus on spec reviews together.
>
> Spec freeze is s-2 Jan 10, so the review day isn't related to any
> deadlines, but would just be a way to organize and make sure we have
> initial review on the specs that have been proposed so far.
>
> How does Tuesday Oct 23 work for everyone? Let me know if another day
> works better.
>
> So far, efried and mriedem are on board when I asked in the
> #openstack-nova channel. I'm sending this mail to gather more responses
> asynchronously.
>

I'll only be available on the European morning but I can still surely help
around this date. A spec review day is always a good idea :-)


> Cheers,
> -melanie
>
> [1] https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] shall we do a spec review day next tuesday oct 23?

2018-10-15 Thread Jay Pipes
Works for me too, thanks Melanie.

On Mon, Oct 15, 2018, 10:07 AM melanie witt  wrote:

> Hey all,
>
> Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was
> thinking it would be a good idea to have a spec review day next week on
> Tuesday Oct 23 to spend some focus on spec reviews together.
>
> Spec freeze is s-2 Jan 10, so the review day isn't related to any
> deadlines, but would just be a way to organize and make sure we have
> initial review on the specs that have been proposed so far.
>
> How does Tuesday Oct 23 work for everyone? Let me know if another day
> works better.
>
> So far, efried and mriedem are on board when I asked in the
> #openstack-nova channel. I'm sending this mail to gather more responses
> asynchronously.
>
> Cheers,
> -melanie
>
> [1] https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2018-10-15 Thread Tim Burke

> On Oct 15, 2018, at 5:00 PM, Monty Taylor  wrote:
> 
> If we decide as a community to shift our testing of python3 to be 3.6 - or 
> even 3.7 - as long as we still are testing 2.7, I'd argue we're adequately 
> covered for 3.5.

That's not enough for me to be willing to declare support. I'll grant that we'd 
catch the obvious SyntaxErrors, but that could be achieved just as easily (and 
probably more cheaply, resource-wise) with multiple linter jobs. The reason you 
want unit tests to actually run is to catch the not-so-obvious bugs.

For example: there are a bunch of places in Swift's proxy-server where we get a 
JSON response from a backend server, loads() it up, and do some work based on 
it. As I've been trying to get the proxy ported to py3, I keep writing 
json.loads(rest.body.decode()). I'll sometimes get pushback from reviewers 
saying this shouldn't be necessary, and then I need to point out that while 
json.loads() is happy to accept either bytes or unicode on both py27 and py36, 
bytes will cause a TypeError on py35. And since 
https://bugs.python.org/issue17909  was 
termed an enhancement and not a regression (I guess the contract is 
str-or-unicode, for whatever str is?), I'm not expecting a backport.

TLDR; if we want to say that something works, best to actually test that it 
works. I might be willing to believe that py35 and py37 working implies that 
py36 will work, but py27 -> py3x tells me little about whether py3w works for 
any w < x.

Tim__
OpenStack Development Mailing 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] [watcher] [monasca] Bare metal node N+1 redundancy and Proactive HA

2018-10-15 Thread Vu Cong, Tuan
Hi Alex,

> Could you please add me as a patch reviewer once patch is uploaded?
Sure, I will add you as a patch reviewer once the patch is uploaded.

Thank you in advance and have a great day ahead :)

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


Re: [openstack-dev] [ironic] Stepping down as core

2018-10-15 Thread Ruby Loo
Sam,

Thank you so much for all your contributions to ironic! I'll miss you. I'm
glad you aren't disappearing though :)

--ruby

On Thu, Oct 11, 2018 at 4:41 AM Sam Betts (sambetts) 
wrote:

> As many of you will have seen on IRC, I've mostly been appearing AFK for
> the last couple of development cycles. Due to other tasks downstream most
> of my attention has been drawn away from upstream Ironic development. Going
> forward I'm unlikely to be as heavily involved with the Ironic project as I
> have been in the past, so I am stepping down as a core contributor to make
> way for those more involved and with more time to contribute.
>
> That said I do not intend to disappear, Myself and my colleagues plan to
> continue to support the Cisco Ironic drivers, we just won't be so heavily
> involved in core ironic development and its worth noting that although I
> might appear AFK on IRC because my main focus is on other things, I always
> have an ear to the ground and direct pings will generally reach me.
>
> I will be in Berlin for the OpenStack summit, so to those that are
> attending I hope to see you there.
>
> The Ironic project has been (and I hope continues to be) an awesome place
> to contribute too, thank you
>
> Sam Betts
> sambetts
>
>
> __
> OpenStack Development Mailing 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] [os-upstream-institute] Find a slot for a meeting to discuss - ACTION NEEDED

2018-10-15 Thread Kendall Nelson
No we didn't record it, but we also didn't discuss much since only a few
people actually showed up.

Basically we decided that we were only going to have two meetings between
then and the Summit. I don't think there was a whole lot else of particular
note. We can probably recap it in our next meeting.

-Kendall (diablo_rojo)

On Wed, Oct 10, 2018 at 10:20 PM Tony Breeds 
wrote:

> On Sat, Sep 29, 2018 at 02:50:31PM +0200, Ildiko Vancsa wrote:
> > Hi Training Team,
> >
> > Based on the votes on the Doodle poll below we will have our ad-hoc
> meeting __next Friday (October 5) 1600 UTC__.
> >
> > Hangouts link for the call:
> https://hangouts.google.com/call/BKnvu7e72uB_Z-QDHDF2AAEI
>
> I don't suppose it was recorded?
>
> I was lucky enough to be on vacation for 3 weeks, which means I couldn't
> make the call.
>
> 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] [python3] Enabling py37 unit tests

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 17:34:24 -0400 (-0400), Corey Bryant wrote:
[...]
> I was assuming the desire to keep 3.5 stein support was for other distros
> that plan to support stein with 3.5.

If there are other distros which are planning to support OpenStack
Stein on Python 3.5, then they should work with us to get testing in
place on systems running their distro. That said, I'd be surprised
if a new LTS server release of a distro targets Python 3.5... it's
already over 3 years old, and 3.3 and 3.4 each got roughly 5 years
before EOL so I'd expect 3.5 to no longer be supported upstream past
September 2020.
-- 
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


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

2018-10-15 Thread Monty Taylor

On 10/15/2018 06:39 PM, Zane Bitter wrote:


In fact, as far as we know the version we have to support in CentOS may 
actually be 3.5, which seems like a good reason to keep it working for 
long enough that we can find out for sure one way or the other.


I certainly hope this is not what ends up happening, but seeing as how I 
actually do not know - I agree, I cannot discount the possibility that 
such a thing would happen.


That said - until such a time as we get to actually drop python2, I 
don't see it as an actual issue. The reason being - if we test with 2.7 
and 3.7 - the things in 3.6 that would break 3.5 get gated by the 
existence of 2.7 for our codebase.


Case in point- the instant 3.6 is our min, I'm going to start replacing 
every instance of:


  "foo {bar}".format(bar=bar)

in any code I spend time in with:

  f"foo {bar}"

It TOTALLY won't parse on 3.5 ... but it also won't parse on 2.7.

If we decide as a community to shift our testing of python3 to be 3.6 - 
or even 3.7 - as long as we still are testing 2.7, I'd argue we're 
adequately covered for 3.5.


The day we decide we can drop 2.7 - if we've been testing 3.7 for 
python3 and it turns out RHEL/CentOS 8 ship with python 3.5, then 
instead of just deleting all of the openstack-tox-py27 jobs, we'd 
probably just need to replace them with openstack-tox-py35 jobs, as that 
would be our new low-water mark.


Now, maybe we'll get lucky and RHEL/CentOS 8 will be a future-looking 
release and will ship with python 3.7 AND so will the corresponding 
Ubuntu LTS - and we'll get to only care about one release of python for 
a minute. :)


Come on - I can dream, right?

Monty

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


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

2018-10-15 Thread Zane Bitter

On 15/10/18 4:10 PM, Jeremy Stanley wrote:

On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote:
[...]

That said, I don't think we should be dropping support/testing for 3.5.
According to:

   https://governance.openstack.org/tc/reference/pti/python.html

3.5 is the only Python3 version that we require all projects to run tests
for.


Until we update it to refer to the version provided by the test
platforms we document at:

https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions


I'm sure we will update it, but as of now we haven't. People shouldn't 
have to guess which TC-maintained documentation is serious and which 
stuff they should just ignore on an ad-hoc basis. If it says 3.5 then 
the answer is 3.5 until somebody submits a patch and the TC approves it.



Out goal is to get everyone running 3.6 unit tests by the end of Stein:

https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs

but we explicitly said there that we were not dropping support for 3.5 as
part of the goal, and should continue to do so until we can effect an
orderly transition later.

[...]

We're not dropping support for 3.5 as part of the python3-first
goal, but would be dropping it as part of the switch from Ubuntu
16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides
Python 3.6). In the past the OpenStack Infra team has prodded us to
follow our documented testing platform policies as new versions
become available, but now with a move to providing infrastructure
services to other OSF projects as well we're on our own to police
this.

We _could_ decide that we're going to start running tests on
multiple versions of Python 3 indefinitely (rather than as a
transitional state during the switch from Ubuntu Xenial to Bionic)


This is inevitable at some point - we say that we'll support both the 
latest release of Ubuntu LTS *and* CentOS. So far that's been irrelevant 
for Python3 because CentOS has only Python2, but we know that the next 
CentOS release will have Python3 and from that point on we will for sure 
be in a situation where we are supporting multiple Python3 versions, not 
always contiguous, for the indefinite future (because the release cycles 
of Ubuntu & CentOS are not aligned in any way).


In fact, as far as we know the version we have to support in CentOS may 
actually be 3.5, which seems like a good reason to keep it working for 
long enough that we can find out for sure one way or the other.



but that does necessarily mean running more jobs. We could also
decide to start targeting different versions of Python than provided
by the distros on which we run our tests (and build it from source
ourselves or something) but I think that's only reasonable if we're
going to also recommend that users deploy OpenStack on top of
custom-compiled Python interpreters rather than the interpreters
provided by server distros like RHEL and Ubuntu.


I am definitely spoiled by Fedora, where I have every version from 3.3 
to 3.7 installed from the distro packages.



So to sum up the above, it's less a question of whether we're
dropping Python 3.5 testing in Stein, and more a question of whether
we're going to continue requiring OpenStack to also be able to run
on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start
of the cycle).


There's actually another whole level of discussion we probably need to 
have. So far we've talked about unit tests, but running functional tests 
is whole other thing, and one we really do probably want to pick a 
single version of Ubuntu to run on for the sake of the gate (and I'd 
suggest that that version should probably by Bionic, if we can get 
everything working on 3.6 early enough in the cycle).


That process would have been a lot easier if we were earlier on 3.6, so 
I'm grateful to the folks who are already working on 3.7 (which is a 
much more substantial change) to hopefully make this less painful in the 
future.


cheers,
Zane.

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


Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Paul Belanger
On Mon, Oct 15, 2018 at 04:27:00PM -0500, Monty Taylor wrote:
> On 10/15/2018 05:49 AM, Stephen Finucane wrote:
> > On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote:
> > > On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote:
> > > [...]
> > > > We plan to still have a CI gatekeeper, probably Travis CI, to make sure 
> > > > PRs
> > > > past muster before being merged, so it's not like we're wanting to
> > > > circumvent good contribution practices by committing whatever to HEAD.
> > > 
> > > Travis CI has gained the ability to prevent you from merging changes
> > > which fail testing? Or do you mean something else when you refer to
> > > it as a "gatekeeper" here?
> > 
> > Yup but it's GitHub feature rather than specifically a Travis CI
> > feature.
> > 
> >https://help.github.com/articles/about-required-status-checks/
> > 
> > Doesn't help the awful pull request workflow but that's neither here
> > nor there.
> 
> It's also not the same as gating.
> 
> The github feature is the equivalent of "Make sure the votes in check are
> green before letting someone click the merge button"
> 
> The zuul feature is "run the tests between the human decision to merge and
> actually merging with the code in the state it will actually be in when
> merged".
> 
> It sounds nitpicky, but the semantic distinction is important - and it
> catches things more frequently than you might imagine.
> 
> That said - Zuul supports github, and there are Zuuls run by not-openstack,
> so taking a project out of OpenStack's free infrastructure does not mean you
> have to also abandon Zuul. The OpenStack Infra team isn't going to run a
> zuul to gate patches on a GitHub project - but other people might be happy
> to let you use a Zuul so that you don't have to give up the Zuul features in
> place today. If you go down that road, I'd suggest pinging the
> softwarefactory-project.io folks or the openlab folks.
> 
As somebody who has recently moved from a gerrit workflow to a github
workflow using Zuul, keep in mind this is not a 1:1 feature map.  The
biggest difference, as people have said, is code review in github.com is
terrible.  It was something added after the fact, I wish daily to be
able to use gerrit again :)

Zuul does make things better, and 100% with Monty here.  You want Zuul
to be the gate, not travis CI.

- Paul

__
OpenStack Development Mailing 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][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Monty Taylor

On 10/10/2018 03:17 PM, Ben Nemec wrote:



On 10/10/18 1:35 PM, Greg Hill wrote:


    I'm not sure how using pull requests instead of Gerrit changesets 
would

    help "core reviewers being pulled on to other projects"?


The 2 +2 requirement works for larger projects with a lot of 
contributors. When you have only 3 regular contributors and 1 of them 
gets pulled on to a project and can no longer actively contribute, you 
have 2 developers who can +2 each other but nothing can get merged 
without that 3rd dev finding time to add another +2. This is what 
happened with Taskflow a few years back. Eventually the other 2 gave 
up and moved on also.


As the others have mentioned, this doesn't need to continue to be a 
blocker. If the alternative is nobody working on the project at all, a 
single approver policy is far better. In practice it's probably not much 
different from having a general oslo core rubber stamp +2 a patch that 
was already reviewed by a taskflow expert.


Just piling on on this. We do single-core approves in openstacksdk, 
although for REALLY hairy patches I try to get a few more people to get 
eyeballs on something.




    Is this just about preferring not having a non-human gatekeeper like
    Gerrit+Zuul and being able to just have a couple people merge 
whatever
    they want to the master HEAD without needing to talk about +2/+W 
rights?



We plan to still have a CI gatekeeper, probably Travis CI, to make 
sure PRs past muster before being merged, so it's not like we're 
wanting to circumvent good contribution practices by committing 
whatever to HEAD. But the +2/+W rights thing was a huge PITA to deal 
with with so few contributors, for sure.


I guess this would be the one concern I'd have about moving it out. We 
still have a fair number of OpenStack projects depending on taskflow[1] 
to one degree or another, and having taskflow fully integrated into the 
OpenStack CI system is nice for catching problems with proposed changes 
early.


I second this. Especially for a library like taskflow where the value is 
in the behavior engine, describing that as an API with an API surface is 
a bit harder than just testing a published library interface.


It's also worth noting that we're working on plans to get the OpenStack 
Infra systems rebranded so that concerns people might have about brand 
association can be mitigated.


I think there was some work recently to get OpenStack CI voting 
on Github, but it seems inefficient to do work to move it out of 
OpenStack and then do more work to partially bring it back.


Zuul supports cross-source dependencies and we have select github repos 
configured in OpenStack's Zuul so that projects can do cross-project 
verification.


I suppose the other option is to just stop CI'ing on OpenStack and rely 
on the upper-constraints gating we do for our other dependencies. That 
would be unfortunate, but again if the alternative is no development at 
all then it might be a necessary compromise.


I agree - if the main roadblock is just the 2x+2 policy, which is 
solvable without moving anything, then the pain of moving the libraries 
out to github just to turn around and cobble together a cross-source 
advisory testing system seems not very worth it and I'd be more inclined 
to use upper-constraints.


By and large moving these is going to be pretty disruptive, so I'd 
personally prefer that they stayed where they. There are PLENTY of 
things hosted in OpenStack's infrastructure that are not OpenStack - or 
even OpenStack specific.


1: 
http://codesearch.openstack.org/?q=taskflow=nope=requirements.txt= 





    If it's just about preferring the pull request workflow versus the
    Gerrit rebase workflow, just say so. Same for just preferring the
    Github
    UI versus Gerrit's UI (which I agree is awful).


I mean, yes, I personally prefer the Github UI and workflow, but that 
was not a primary consideration. I got used to using gerrit well 
enough. It was mostly the  There's also a sense that if a project is 
in the Openstack umbrella, it's not useful outside Openstack, and 
Taskflow is designed to be a general purpose library. The hope is that 
just making it a regular open source project might attract more users 
and contributors.


I think we might be intertwining a few things that don't have to be 
intertwined.


The libraries are currently part of the OpenStack umbrella, and as part 
of that are hosted in OpenStack's developer infrastructure.


They can remain "part of OpenStack" and be managed with a relaxed core 
reviewer policy. This way, should they be desired, things like the 
release management team can still be used.


They can cease being "part of OpenStack" without needing to move away 
from the OpenStack Developer Infrastructure. As I mentioned earlier 
we're working on rebranding the Developer Infrastructure, so if there is 
a concern that a git repo existing within the Developer Infrastructure 
implies being "part of 

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

2018-10-15 Thread Matthew Oliver
Just an FYI, it doesn't solved cached images, but Swift does support at
rest encryption, so if using the Swift store backend you can at least know
your image on disk on the storage nodes would be safe.
We still need to add more functionality like key rotation, but we do
integrate with kmip sevices or barbican.

Still could be a good idea for other projects. I wasn't the one who wrote
the Swift at-rest encryption but happy to, probably badly, help answer
questions cause we might have some interesting lessons learned.

Matt

On Tue, Oct 16, 2018 at 12:36 AM Josephine Seifert <
josephine.seif...@secustack.com> wrote:

> Hello OpenStack developers,
>
> we have made an etherpad as there were a few questions concerning
> the library we want to use for the encryption and decryption method:
>
>
> https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
>
>
> Am 11.10.2018 um 15:10 schrieb Josephine Seifert:
> > Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
> >> Dear OpenStack developers,
> >>
> >> as you suggested, we have written individual specs for Nova [1] and
> >> Cinder [2] so far and will write another spec for Glance soon. We'd
> >> appreciate any feedback and reviews on the specs :)
> >>
> >> Thank you in advance,
> >> Markus Hentsch
> >>
> >> [1] https://review.openstack.org/#/c/608696/
> >> [2] https://review.openstack.org/#/c/608663/
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > The spec for Glance is also on gerrit now:
> >
> > https://review.openstack.org/#/c/609667/
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2018-10-15 Thread Corey Bryant
On Mon, Oct 15, 2018, 4:11 PM Jeremy Stanley  wrote:

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

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

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

Corey

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


Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Monty Taylor

On 10/15/2018 05:49 AM, Stephen Finucane wrote:

On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote:

On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote:
[...]

We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs
past muster before being merged, so it's not like we're wanting to
circumvent good contribution practices by committing whatever to HEAD.


Travis CI has gained the ability to prevent you from merging changes
which fail testing? Or do you mean something else when you refer to
it as a "gatekeeper" here?


Yup but it's GitHub feature rather than specifically a Travis CI
feature.

   https://help.github.com/articles/about-required-status-checks/

Doesn't help the awful pull request workflow but that's neither here
nor there.


It's also not the same as gating.

The github feature is the equivalent of "Make sure the votes in check 
are green before letting someone click the merge button"


The zuul feature is "run the tests between the human decision to merge 
and actually merging with the code in the state it will actually be in 
when merged".


It sounds nitpicky, but the semantic distinction is important - and it 
catches things more frequently than you might imagine.


That said - Zuul supports github, and there are Zuuls run by 
not-openstack, so taking a project out of OpenStack's free 
infrastructure does not mean you have to also abandon Zuul. The 
OpenStack Infra team isn't going to run a zuul to gate patches on a 
GitHub project - but other people might be happy to let you use a Zuul 
so that you don't have to give up the Zuul features in place today. If 
you go down that road, I'd suggest pinging the 
softwarefactory-project.io folks or the openlab folks.


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

2018-10-15 Thread Monty Taylor

On 10/15/2018 07:08 AM, Jeremy Stanley wrote:

On 2018-10-15 11:54:28 +0100 (+0100), Stephen Finucane wrote:
[...]

As an aside, are there any plans to enable PolyGerrit [1] in the
OpenStack Gerrit instance?

[...]

I believe so, but first we need to upgrade to a newer Gerrit version
which provides it (that in turn requires a newer Java which needs a
server built from a newer distro version, which is all we've gotten
through on the upgrade plan so far).


I'm working on this now, so hopefully we should have an ETA soonish.

__
OpenStack Development Mailing 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] Forum Schedule - Seeking Community Review

2018-10-15 Thread Jimmy McArthur

Ha ha! Good catch :)  On it.


Matt Riedemann 
October 15, 2018 at 4:08 PM


Not a conflict, but it looks like there is a duplicate for Lee talking 
about encrypted volumes:


https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=yarwood 



Unless he just loves it so much he needs to talk about it twice.



__
OpenStack Development Mailing 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] Forum Schedule - Seeking Community Review

2018-10-15 Thread Matt Riedemann

On 10/15/2018 3:01 PM, Jimmy McArthur wrote:
The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 
If you see a glaring content conflict within the Forum itself, please 
let me know.


Not a conflict, but it looks like there is a duplicate for Lee talking 
about encrypted volumes:


https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=yarwood

Unless he just loves it so much he needs to talk about it twice.

--

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-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

2018-10-15 Thread Monty Taylor

Heya,

Tobias and I were chatting at OpenStack Days Nordic about the Public 
Cloud Working Group potentially taking over as custodians of the vendor 
profile information [0][1] we keep in openstacksdk (and previously in 
os-client-config)


I think this is a fine idea, but we've got some dancing to do I think.

A few years ago Dean and I talked about splitting the vendor data into 
its own repo. We decided not to at the time because it seemed like extra 
unnecessary complication. But I think we may have reached that time.


We should split out a new repo to hold the vendor data json files. We 
can manage this repo pretty much how we manage the 
service-types-authority [2] data now. Also similar to that (and similar 
to tzdata) these are files that contain information that is true 
currently and is not release specific - so it should be possible to 
update to the latest vendor files without updating to the latest 
openstacksdk.


If nobody objects, I'll start working through getting a couple of new 
repos created. I'm thinking openstack/vendor-profile-data, owned/managed 
by Public Cloud WG, with the json files, docs, json schema, etc, and a 
second one, openstack/os-vendor-profiles - owned/managed by the 
openstacksdk team that's just like os-service-types [3] and is a 
tiny/thin library that exposes the files to python (so there's something 
to depend on) and gets proposed patches from zuul when new content is 
landed in openstack/vendor-profile-data.


How's that sound?

Thanks!
Monty

[0] 
http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors
[1] 
https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html

[2] http://git.openstack.org/cgit/openstack/service-types-authority
[3] http://git.openstack.org/cgit/openstack/os-service-types

__
OpenStack Development Mailing 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] [tc][all] Discussing goals (upgrades) with community @ office hours

2018-10-15 Thread Michael Johnson
I am interested in participating in this discussion.

I think we have had a few goals that were selected before all of the
parts were in place. This leads to re-work and/or pushing goals work
into the already busy milestone 3 time frame.

Michael
On Mon, Oct 15, 2018 at 5:16 AM Chris Dent  wrote:
>
> On Sat, 13 Oct 2018, Mohammed Naser wrote:
>
> > Does this seem like it would be of interest to the community?  I am
> > currently trying to transform our office hours to be more of a space
> > where we have more of the community and less of discussion between us.
>
> If we want discussion to actually be with the community at large
> (rather than giving lip service to the idea), then we need to be
> more oriented to using email. Each time we have an office hour or a
> meeting in IRC or elsewhere, or an ad hoc Hangout, unless we are
> super disciplined about reporting the details to email afterwards, a
> great deal of information falls on the floor and individuals who are
> unable to attend because of time, space, language or other
> constraints are left out.
>
> For community-wide issues, synchronous discussion should be the mode
> of last resort. Anything else creates a priesthood with a
> disempowered laity wondering how things got away from them.
>
> For community goals, in particular, preferring email for discussion
> and planning seems pretty key.
>
> I wonder if instead of specifying topics for TC office hours, we kill
> them instead? They've turned into gossiping echo chambers.
>
> --
> Chris Dent   ٩◔̯◔۶   https://anticdent.org/
> freenode: cdent tw: 
> @anticdent__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [Openstack-operators] [goals][upgrade-checkers] Week R-26 Update

2018-10-15 Thread Ben Nemec



On 10/15/18 3:27 AM, Jean-Philippe Evrard wrote:

On Fri, 2018-10-12 at 17:05 -0500, Matt Riedemann wrote:

The big update this week is version 0.1.0 of oslo.upgradecheck was
released. The documentation along with usage examples can be found
here
[1]. A big thanks to Ben Nemec for getting that done since a few
projects were waiting for it.

In other updates, some changes were proposed in other projects [2].

And finally, Lance Bragstad and I had a discussion this week [3]
about
the validity of upgrade checks looking for deleted configuration
options. The main scenario I'm thinking about here is FFU where
someone
is going from Mitaka to Pike. Let's say a config option was
deprecated
in Newton and then removed in Ocata. As the operator is rolling
through
from Mitaka to Pike, they might have missed the deprecation signal
in
Newton and removal in Ocata. Does that mean we should have upgrade
checks that look at the configuration for deleted options, or
options
where the deprecated alias is removed? My thought is that if things
will
not work once they get to the target release and restart the service
code, which would definitely impact the upgrade, then checking for
those
scenarios is probably OK. If on the other hand the removed options
were
just tied to functionality that was removed and are otherwise not
causing any harm then I don't think we need a check for that. It was
noted that oslo.config has a new validation tool [4] so that would
take
care of some of this same work if run during upgrades. So I think
whether or not an upgrade check should be looking for config option
removal ultimately depends on the severity of what happens if the
manual
intervention to handle that removed option is not performed. That's
pretty broad, but these upgrade checks aren't really set in stone
for
what is applied to them. I'd like to get input from others on this,
especially operators and if they would find these types of checks
useful.

[1] https://docs.openstack.org/oslo.upgradecheck/latest/
[2] https://storyboard.openstack.org/#!/story/2003657
[3]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
[4]
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html



Hey,

Nice topic, thanks Matt!

TL:DR; I would rather fail explicitly for all removals, warning on all
deprecations. My concern is, by being more surgical, we'd have to
decide what's "not causing any harm" (and I think deployers/users are
best to determine what's not causing them any harm).
Also, it's probably more work to classify based on "severity".
The quick win here (for upgrade-checks) is not about being smart, but
being an exhaustive, standardized across projects, and _always used_
source of truth for upgrades, which is complemented by release notes.

Long answer:

At some point in the past, I was working full time on upgrades using
OpenStack-Ansible.

Our process was the following:
1) Read all the project's releases notes to find upgrade documentation
2) With said release notes, Adapt our deploy tools to handle the
upgrade, or/and write ourselves extra documentation+release notes for
our deployers.
3) Try the upgrade manually, fail because some release note was missing
x or y. Find root cause and retry from step 2 until success.

Here is where I see upgrade checkers improving things:
1) No need for deployment projects to parse all release notes for
configuration changes, as tooling to upgrade check would be directly
outputting things that need to change for scenario x or y that is
included in the deployment project. No need to iterate either.

2) Test real deployer use cases. The deployers using openstack-ansible
have ultimate flexibility without our code changes. Which means they
may have different code paths than our gating. Including these checks
in all upgrades, always requiring them to pass, and making them
explicit about the changes is tremendously helpful for deployers:
- If config deprecations are handled as warnings as part of the same
process, we will output said warnings to generate a list of action
items for the deployers. We would use only one tool as source of truth
for giving the action items (and still continue the upgrade);
- If config removals are handled as errors, the upgrade will fail,
which is IMO normal, as the deployer would not have respected its
action items.


Note that deprecated config opts should already be generating warnings 
in the logs. It is also possible now to use fatal-deprecations with 
config opts: 
https://github.com/openstack/oslo.config/commit/5f8b0e0185dafeb68cf04590948b9c9f7d727051


I'm not sure that's exactly what you're talking about, but those might 
be useful to get us at least part of the way there.




In OSA, we could probably implement a deployer override (variable). It
would allow the deployers an explicit bypass of an upgrade failure. "I
know I am doing this!". It would be useful for doing multiple serial
upgrades.

In 

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

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote:
[...]
> That said, I don't think we should be dropping support/testing for 3.5.
> According to:
> 
>   https://governance.openstack.org/tc/reference/pti/python.html
> 
> 3.5 is the only Python3 version that we require all projects to run tests
> for.

Until we update it to refer to the version provided by the test
platforms we document at:

https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions

> Out goal is to get everyone running 3.6 unit tests by the end of Stein:
> 
> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
> 
> but we explicitly said there that we were not dropping support for 3.5 as
> part of the goal, and should continue to do so until we can effect an
> orderly transition later.
[...]

We're not dropping support for 3.5 as part of the python3-first
goal, but would be dropping it as part of the switch from Ubuntu
16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides
Python 3.6). In the past the OpenStack Infra team has prodded us to
follow our documented testing platform policies as new versions
become available, but now with a move to providing infrastructure
services to other OSF projects as well we're on our own to police
this.

We _could_ decide that we're going to start running tests on
multiple versions of Python 3 indefinitely (rather than as a
transitional state during the switch from Ubuntu Xenial to Bionic)
but that does necessarily mean running more jobs. We could also
decide to start targeting different versions of Python than provided
by the distros on which we run our tests (and build it from source
ourselves or something) but I think that's only reasonable if we're
going to also recommend that users deploy OpenStack on top of
custom-compiled Python interpreters rather than the interpreters
provided by server distros like RHEL and Ubuntu.

So to sum up the above, it's less a question of whether we're
dropping Python 3.5 testing in Stein, and more a question of whether
we're going to continue requiring OpenStack to also be able to run
on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start
of the cycle).
-- 
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] Forum Schedule - Seeking Community Review

2018-10-15 Thread Jimmy McArthur

Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to let 
us know :)


Cheers,
Jimmy


full-schedule (2).pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

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

Thanks,
Corey


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

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Joshua Harlow
I'm ok with trying this move out and seeing how it goes (maybe it will 
be for the better, idk).


-Josh


On 10/10/2018 10:41 AM, Greg Hill wrote:
I've been out of the openstack loop for a few years, so I hope this 
reaches the right folks.


Josh Harlow (original author of taskflow and related libraries) and I 
have been discussing the option of moving taskflow out of the 
openstack umbrella recently. This move would likely also include the 
futurist and automaton libraries that are primarily used by taskflow. 
The idea would be to just host them on github and use the regular 
Github features for Issues, PRs, wiki, etc, in the hopes that this 
would spur more development. Taskflow hasn't had any substantial 
contributions in several years and it doesn't really seem that the 
current openstack devs have a vested interest in moving it forward. I 
would like to move it forward, but I don't have an interest in being 
bound by the openstack workflow (this is why the project stagnated as 
core reviewers were pulled on to other projects and couldn't keep up 
with the review backlog, so contributions ground to a halt).


I guess I'm putting it forward to the larger community. Does anyone 
have any objections to us doing this? Are there any non-obvious 
technicalities that might make such a transition difficult? Who would 
need to be made aware so they could adjust their own workflows?


Or would it be preferable to just fork and rename the project so 
openstack can continue to use the current taskflow version without 
worry of us breaking features?


Greg



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


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


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

2018-10-15 Thread Corey Bryant
On Mon, Oct 15, 2018 at 3:01 PM Zane Bitter  wrote:

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

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

Thanks,
Corey


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


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

2018-10-15 Thread Zane Bitter

On 12/10/18 8:59 AM, Corey Bryant wrote:



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


On 10/10/2018 23.10, Jeremy Stanley wrote:
 > I might have only pointed this out on IRC so far, but the
 > expectation is that testing 3.5 and 3.6 at the same time was merely
 > transitional since official OpenStack projects should be moving
 > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
 > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
 > cycle and so will drop 3.5 testing on master in the process.

Agreed, this needs some larger communication and explanation on what
to do,


The good news is we now have an initial change underway and successful, 
dropping py35 and enabling py37: https://review.openstack.org/#/c/609557/


Hey Corey,
Thanks for getting this underway, it's really important that we keep 
moving forward (we definitely got behind on the 3.6 transition and are 
paying for it now).


That said, I don't think we should be dropping support/testing for 3.5. 
According to:


  https://governance.openstack.org/tc/reference/pti/python.html

3.5 is the only Python3 version that we require all projects to run 
tests for.


Out goal is to get everyone running 3.6 unit tests by the end of Stein:


https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs

but we explicitly said there that we were not dropping support for 3.5 
as part of the goal, and should continue to do so until we can effect an 
orderly transition later. Personally, I would see that including waiting 
for all the 3.5-supporting projects to add 3.6 jobs (which has been 
blocked up until ~this point, as we are only just now close to getting 
all of the repos using local Zuul config).


I do agree that anything that works on 3.5 and 3.7 will almost certainly 
work on 3.6, so if you wanted to submit a patch to that goal saying that 
projects could add a unit test job for *either* 3.6 or 3.7 (in addition 
to 3.5) then I would probably support that. We could then switch all the 
3.5 jobs to 3.6 later when we eventually drop 3.5 support. That would 
mean we'd only ever run 3 unit test jobs (and 2 once 2.7 is eventually 
dropped) - for the oldest and newest versions of Python 3 that a project 
supports.


cheers,
Zane.

[This thread was also discussed on IRC starting here: 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-15.log.html#t2018-10-15T18:09:05]


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


Thanks,
Corey


Andreas
-- 
  Andreas Jaeger aj@{suse.com ,opensuse.org

} Twitter: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Felix Imendörffer, Jane Smithard, Graham Norton,
        HRB 21284 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
A126


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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




__
OpenStack Development Mailing 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] shall we do a spec review day next tuesday oct 23?

2018-10-15 Thread melanie witt

Hey all,

Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was 
thinking it would be a good idea to have a spec review day next week on 
Tuesday Oct 23 to spend some focus on spec reviews together.


Spec freeze is s-2 Jan 10, so the review day isn't related to any 
deadlines, but would just be a way to organize and make sure we have 
initial review on the specs that have been proposed so far.


How does Tuesday Oct 23 work for everyone? Let me know if another day 
works better.


So far, efried and mriedem are on board when I asked in the 
#openstack-nova channel. I'm sending this mail to gather more responses 
asynchronously.


Cheers,
-melanie

[1] https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule

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


Re: [openstack-dev] [glance][upgrade-checkers] Question about glance rocky upgrade release note

2018-10-15 Thread Lance Bragstad
I haven't implemented any checks, but I did take a shot at laying down the
scaffolding for implementing upgrade checks in glance [0].

Anyone who is more familiar with glance should be able to build off of that
commit by implementing specific checks in glance/cmd/status.py

[0] https://review.openstack.org/#/c/610661/

On Mon, Oct 15, 2018 at 10:49 AM Brian Rosmaita 
wrote:

> On 9/24/18 3:13 PM, Matt Riedemann wrote:
> > On 9/24/2018 2:06 PM, Matt Riedemann wrote:
> >> Are there more specific docs about how to configure the 'image import'
> >> feature so that I can be sure I'm careful? In other words, are there
> >> specific things a "glance-status upgrade check" check could look at
> >> and say, "your image import configuration is broken, here are details
> >> on how you should do this"
> Apologies for this delayed reply.
> > I guess this answers the question about docs:
> >
> >
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html
>
> Yes, you found the correct docs.  They could probably use a revision to
> eliminate some of the references to Pike and Queens, but I think the
> content is accurate with respect to proper configuration of image import.
> > Would a basic upgrade check be such that if glance-api.conf contains
> > enable_image_import=False, you're going to have issues since that option
> > is removed in Rocky?
>
> I completely missed this question when I saw this email a few weeks ago.
>
> Yes, if a Queens glance-api.conf has enable_image_import=False, then it
> was disabled on purpose since the default in Queens was True.  Given the
> Rocky defaults for import-related config (namely, all import_methods are
> enabled), the operator may need to make some kind of adjustment.
>
> As a side point, although the web-download import method is enabled by
> default in Rocky, it has whitelist/blacklist configurability to restrict
> what kind of URIs end-users may access.  By default, end users are only
> able to access URIs using the http or https scheme on the standard ports.
>
> Thanks for working on the upgrade-checker goal for Glance!
>
> __
> OpenStack Development Mailing 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] [glance][upgrade-checkers] Question about glance rocky upgrade release note

2018-10-15 Thread Brian Rosmaita
On 9/24/18 3:13 PM, Matt Riedemann wrote:
> On 9/24/2018 2:06 PM, Matt Riedemann wrote:
>> Are there more specific docs about how to configure the 'image import'
>> feature so that I can be sure I'm careful? In other words, are there
>> specific things a "glance-status upgrade check" check could look at
>> and say, "your image import configuration is broken, here are details
>> on how you should do this"
Apologies for this delayed reply.
> I guess this answers the question about docs:
> 
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html

Yes, you found the correct docs.  They could probably use a revision to
eliminate some of the references to Pike and Queens, but I think the
content is accurate with respect to proper configuration of image import.
> Would a basic upgrade check be such that if glance-api.conf contains
> enable_image_import=False, you're going to have issues since that option
> is removed in Rocky?

I completely missed this question when I saw this email a few weeks ago.

Yes, if a Queens glance-api.conf has enable_image_import=False, then it
was disabled on purpose since the default in Queens was True.  Given the
Rocky defaults for import-related config (namely, all import_methods are
enabled), the operator may need to make some kind of adjustment.

As a side point, although the web-download import method is enabled by
default in Rocky, it has whitelist/blacklist configurability to restrict
what kind of URIs end-users may access.  By default, end users are only
able to access URIs using the http or https scheme on the standard ports.

Thanks for working on the upgrade-checker goal for Glance!

__
OpenStack Development Mailing 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] [zVM] [python3] tox/zuul issues for zVM OpenStack

2018-10-15 Thread William M Edmonds


The current tox.ini for ceilometer-zvm includes this line [1] similar to
what ceilometer-powervm was doing up until recently:

   -egit+https://github.com/openstack/ceilometer@master#egg=ceilometer

We found that this no longer works since ceilometer was added to
upper-constraints [2]. We first got things working again by [3] and are now
improving on that by [4]. I expect you will need to make similar changes.

I was going to propose this to ceilometer-zvm for you, but then noticed
that you don't even have a zuul.yaml file. You're missing changes like [5]
adding lower-constraints checking and [6] for the python3-first effort. So
that is probably a bigger issue to address first (and for
networking-powervm and nova-zvm-virt-driver as well as ceilometer-zvm).
When you get to the python3 stuff, I suggest you work with dhellmann on
that. He's got scripts to generate at least some of those commits.

[1] http://git.openstack.org/cgit/openstack/ceilometer-zvm/tree/tox.ini#n19
[2] https://review.openstack.org/#/c/601498
[3] https://review.openstack.org/#/c/609058/
[4] https://review.openstack.org/#/c/609823/
[5] https://review.openstack.org/#/c/555358/
[6] https://review.openstack.org/#/c/594984/

W. Matthew Edmonds
Sr. Software Engineer, IBM Power Systems
Email: edmon...@us.ibm.com
Phone: (919) 543-7538 / Tie-Line: 441-7538
__
OpenStack Development Mailing 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][neutron-release] feature/graphql branch rebase

2018-10-15 Thread Miguel Lavalle
Hi Gilles,

The merge of master into feature/graphql  has been approved:
https://review.openstack.org/#/c/609455. In the future, you can create your
own merge patch following the instructions here:
https://docs.openstack.org/infra/manual/drivers.html#merge-master-into-feature-branch.
The Neutron team will catch it in Gerrit and review it

Regards

Miguel

On Thu, Oct 4, 2018 at 11:44 PM Gilles Dubreuil  wrote:

> Hey Neutron folks,
>
> I'm just reiterating the request.
>
> Thanks
>
>
> On 20/06/18 11:34, Gilles Dubreuil wrote:
> > Could someone from the Neutron release group rebase feature/graphql
> > branch against master/HEAD branch please?
> >
> > Regards,
> > Gilles
> >
> >
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

2018-10-15 Thread Lance Bragstad
On Mon, Oct 15, 2018 at 8:52 AM Ed Leafe  wrote:

> On Oct 15, 2018, at 7:40 AM, Chris Dent  wrote:
> >
> > I'd like some input from the community on how we'd like this to go.
>
> I would say it depends on the long-term plans for paste. Are we planning
> on weaning ourselves off of paste, and simply need to maintain it until
> that can be completed, or are we planning on encouraging its use?
>
>
Keystone started doing this last release and we're just finishing it up
now. The removal of keystone's v2.0 API and our hand-rolled API dispatching
ended up being the perfect storm for us to say "let's just remove paste
entirely and migrate to something supported".

It helped that we stacked a couple of long-standing work items behind the
paste removal, but it was a ton of work [0]. I think Morgan was going to
put together a summary of how we approached the removal. If the long-term
goal is to help projects move away from Paste, then we can try and share
some of the knowledge we have.

[0] https://twitter.com/MdrnStm/status/1050519620724056065


>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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] [watcher] [monasca] Bare metal node N+1 redundancy and Proactive HA

2018-10-15 Thread Чадин Александр Сергеевич
On 10.10.2018 12:43, Vu Cong, Tuan wrote:
> Then, I will fill the gap for communication between Monasca and Watcher by 
> uploading new patch to Monasca.

Could you please add me as a patch reviewer once patch is uploaded?

Thanks!

-- 
Alexander Chadin

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


Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

2018-10-15 Thread Ed Leafe
On Oct 15, 2018, at 7:40 AM, Chris Dent  wrote:
> 
> I'd like some input from the community on how we'd like this to go.

I would say it depends on the long-term plans for paste. Are we planning on 
weaning ourselves off of paste, and simply need to maintain it until that can 
be completed, or are we planning on encouraging its use?


-- Ed Leafe






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


Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables

2018-10-15 Thread Sean McGinnis
On Fri, Oct 12, 2018 at 11:44:11AM -0400, Doug Hellmann wrote:
> Sean McGinnis  writes:
> 
> > [snip]
> >
> > One of the big motivators in the past was also to have output that 
> > downstream
> > distros and users could pick up for testing and early packaging. Based on 
> > our
> > admittedly anecdotal small sample, it doesn't appear this is actually a big
> > need, so we propose to stop tagging milestone releases for the
> > cycle-with-milestone projects.
> 
> One of the issues that was raised from downstream consumers [1] is that
> this complicates upgrade testing using packages, since tools like yum
> will think that the stable branch (with a final version tag) has a
> higher version number than master (with a dev version computed off of
> the first release candidate where the stable branch was created).
> 
> [snip]
> 
> We need all projects to increment their version at least by one minor
> version at the start of each cycle to save space for patch releases on
> the stable branch, so we looked at a few options for triggering that
> update automatically.
> 
> [snip]
> 
> A similarly low impact solution is to use pbr's Sem-Ver calculation
> feature and inject patches into master to bump the version being
> computed by 1 feature level (which should move from x.y.z.0rc1 to
> somethinglike x.y+1.0.devN). See [2] for details about how this works.
> 
> This is the approach I prefer, and I have a patch to the branching
> scripts to add the Sem-Ver instruction to the patches we already
> generate to update reno [3].
> 
> That change should take care of our transition from Stein->T, but we're
> left with versions in Stein that are lower than Rocky right now. So, as
> a one time operation, Sean is going to propose empty patches with the
> Sem-Ver instruction in the commit message to all of the repositories for
> Stein deliverables that have stable/rocky branches.
> 

The patch to automatically propose the sem-ver flag on branching stable/* has
landed and I have tested it out with our release-test repo. This seems to work
well and is a much lower impact than other options we had considered.

I have a set of patches queued up to now do this one-time manual step for the
rocky to stein transition.

**Please watch for these "empty" patches from me and get them through quickly
if they look OK to you.**

I have checked the list of repos to make sure none of them have done any sort
off milestone release yet for stein. If you are aware of any that I have
missed, please let me know.

There is a strong warning with using this PBR feature that it is not obvious
that having this metadata tag in the commit has this effect on a repo and it is
very, very disruptive to try to undo its use. So please do not copy, backport,
or do anything else with any of the commits that contain this flag.

Any questions at all, please ask here or in the #openstack-release channel.

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] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

2018-10-15 Thread Josephine Seifert
Hello OpenStack developers,

we have made an etherpad as there were a few questions concerning
the library we want to use for the encryption and decryption method:

https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption


Am 11.10.2018 um 15:10 schrieb Josephine Seifert:
> Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
>> Dear OpenStack developers,
>>
>> as you suggested, we have written individual specs for Nova [1] and
>> Cinder [2] so far and will write another spec for Glance soon. We'd
>> appreciate any feedback and reviews on the specs :)
>>
>> Thank you in advance,
>> Markus Hentsch
>>
>> [1] https://review.openstack.org/#/c/608696/
>> [2] https://review.openstack.org/#/c/608663/
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> The spec for Glance is also on gerrit now:
>
> https://review.openstack.org/#/c/609667/
>
> __
> OpenStack Development Mailing 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] [neutron] Bug deputy report - week 42

2018-10-15 Thread Slawomir Kaplonski
Hi,

I was on bug deputy in week of 8.10.2018 to 15.10.2018.
Below is summary of reported bugs for Neutron:


Bugs which needs some look to confirm them:
* https://bugs.launchpad.net/neutron/+bug/1795432 - neutron does not create the 
necessary iptables rules for dhcp agents when linuxbridge is used
This one should be confirmed on multinode environment with Linuxbridge, 
I didn’t have such env to work on that.

* https://bugs.launchpad.net/neutron/+bug/1797368 - Trunk: different behavior 
of admin_state_up attribute between trunk and port
I have no experience with trunks and I would like someone else to take 
a look on that. From description it looks for me that it’s valid issue

* https://bugs.launchpad.net/neutron/+bug/1795816 - neutron_dynamic_routing Bgp 
floatingip_update KeyError: 'last_known_router_id
Should be good that someone more familiar with neutron-dynamic-routing 
could take a look on it.
I don’t have environment to confirm it but from bug report it looks as 
valid bug.
Importance set to medium


Bugs triaged or triage in progress already:
* https://bugs.launchpad.net/neutron/+bug/1796491 - DVR Floating IP setup in 
the SNAT namespace of the network node and also in the qrouter namespace in the 
compute node 
Swami is checking if it wasn’t already fixed…

* https://bugs.launchpad.net/neutron/+bug/1796824 - Port in some type of 
device_owner should not allow update IP address
Importance set to Medium

* https://bugs.launchpad.net/neutron/+bug/1797037 - Extra routes configured on 
routers are not set in the router namespace and snat namespace with DVR-HA 
routers
already in progress, importance Medium

* https://bugs.launchpad.net/neutron/+bug/1796854 - Neutron doesn't respect 
advscv role while creating port
Importance set to Medium, this is an neutron-lib issue

* https://bugs.launchpad.net/neutron/+bug/1796976 - neutron.conf needs 
lock_path set for router to operate 
Docs issue - importance Low,

* https://bugs.launchpad.net/neutron/+bug/1797084 - Stale namespaces when 
fallback tunnels are present
Importance Low, patch already proposed by dalvarez

* https://bugs.launchpad.net/neutron/+bug/1797298 - Router gateway device are 
repeatedly configured When ha changed
Importance Low, patch already proposed

* https://bugs.launchpad.net/neutron/+bug/1796703 - HA router interfaces in 
standby state 
Needs look by some L3 experts - I already raised this on on L3 Sub-team 
meeting and Brian is triaging it now

* https://bugs.launchpad.net/neutron/+bug/1796230 - no libnetfilter-log1 
package on centos 
Waiting for reply for Brian’s question now….

* https://bugs.launchpad.net/neutron/+bug/1763608 - Netplan ignores Interfaces 
without IP Addresses 
I asked how it’s related to neutron as I don’t understand that. Waiting 
for reply now.

* https://bugs.launchpad.net/neutron/+bug/1795222 - [l3] router agent side 
gateway IP not changed if directly change IP address
Importance medium, patch already proposed

* https://bugs.launchpad.net/neutron/+bug/1797663 - refactor def 
_get_dvr_sync_data from neutron/db/l3_dvr_db.py
Importance wishlist,

* https://bugs.launchpad.net/neutron/+bug/1796629 - Incorrectly passing ext_ips 
as gw_ips after creating router gateway
Importance set to medium


RFEs:
* https://bugs.launchpad.net/neutron/+bug/1796925 - [RFE] port forwarding 
floating IP QoS
* https://bugs.launchpad.net/neutron/+bug/1797140 - [RFE] create port by 
providing parameters subnet_id only

Potential RFEs maybe:
* https://bugs.launchpad.net/neutron/+bug/1792890 - The user can delete a 
security group which is used as remote-group-id
It looks like maybe potential RFE as it may change current API behavior


— 
Slawek Kaplonski
Senior software engineer
Red Hat


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


Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

2018-10-15 Thread Sean McGinnis
On Mon, Oct 15, 2018 at 01:40:37PM +0100, Chris Dent wrote:
> 
> Back in August [1] there was an email thread about the Paste package
> being essentially unmaintained and several OpenStack projects still
> using it. At that time we reached the conclusion that we should
> investigate having OpenStack adopt Paste in some form as it would
> take some time or be not worth it to migrate services away from it.
> 
> [snip]
> 
> I'd like some input from the community on how we'd like this to go.
> Some options.
> 
> * Chris becomes the de-facto maintainer of paste and I do whatever I
>   like to get it healthy and released.
> 
> * Several volunteers from the community take over the existing
>   bitbucket setup [2] and keep it going there.
> 
> * Several volunteers from the community import the existing
>   bitbucket setup to OpenStack^wOpenDev infra and manage it.
> 
> What would people like? Who would like to volunteer?
> 

Maybe some combination of bullets one and three?

This seems like it would increase visibility in the community if it were moved
under the OpenDev umbrella. Then we could also leverage our release automation
as/when needed. It might also then attract some of the driveby contributions.


__
OpenStack Development Mailing 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][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Dmitry Tantsur

On 10/10/18 7:41 PM, Greg Hill wrote:
I've been out of the openstack loop for a few years, so I hope this reaches the 
right folks.


Josh Harlow (original author of taskflow and related libraries) and I have been 
discussing the option of moving taskflow out of the openstack umbrella recently. 
This move would likely also include the futurist and automaton libraries that 
are primarily used by taskflow.


Just for completeness: futurist and automaton are also heavily relied on by 
ironic without using taskflow.


The idea would be to just host them on github 
and use the regular Github features for Issues, PRs, wiki, etc, in the hopes 
that this would spur more development. Taskflow hasn't had any substantial 
contributions in several years and it doesn't really seem that the current 
openstack devs have a vested interest in moving it forward. I would like to move 
it forward, but I don't have an interest in being bound by the openstack 
workflow (this is why the project stagnated as core reviewers were pulled on to 
other projects and couldn't keep up with the review backlog, so contributions 
ground to a halt).


I guess I'm putting it forward to the larger community. Does anyone have any 
objections to us doing this? Are there any non-obvious technicalities that might 
make such a transition difficult? Who would need to be made aware so they could 
adjust their own workflows?


Or would it be preferable to just fork and rename the project so openstack can 
continue to use the current taskflow version without worry of us breaking features?


Greg


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




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


[openstack-dev] [all] [tc] [api] Paste Maintenance

2018-10-15 Thread Chris Dent


Back in August [1] there was an email thread about the Paste package
being essentially unmaintained and several OpenStack projects still
using it. At that time we reached the conclusion that we should
investigate having OpenStack adopt Paste in some form as it would
take some time or be not worth it to migrate services away from it.

I went about trying to locate the last set of maintainers and get
access to picking it up. It took a while, but I've now got owner
bits for both bitbucket and PyPI and enthusiastic support from the
previous maintainer for OpenStack to be the responsible party.

I'd like some input from the community on how we'd like this to go.
Some options.

* Chris becomes the de-facto maintainer of paste and I do whatever I
  like to get it healthy and released.

* Several volunteers from the community take over the existing
  bitbucket setup [2] and keep it going there.

* Several volunteers from the community import the existing
  bitbucket setup to OpenStack^wOpenDev infra and manage it.

What would people like? Who would like to volunteer?

At this stage the main piece of blocking work is a patch [3] (and
subsequent release) to get things working happily in Python 3.7.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-August/132792.html
[2] https://bitbucket.org/ianb/paste
[3] https://bitbucket.org/ianb/paste/pull-requests/41/python-37-support/diff

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [tc][all] Discussing goals (upgrades) with community @ office hours

2018-10-15 Thread Chris Dent

On Sat, 13 Oct 2018, Mohammed Naser wrote:


Does this seem like it would be of interest to the community?  I am
currently trying to transform our office hours to be more of a space
where we have more of the community and less of discussion between us.


If we want discussion to actually be with the community at large
(rather than giving lip service to the idea), then we need to be
more oriented to using email. Each time we have an office hour or a
meeting in IRC or elsewhere, or an ad hoc Hangout, unless we are
super disciplined about reporting the details to email afterwards, a
great deal of information falls on the floor and individuals who are
unable to attend because of time, space, language or other
constraints are left out.

For community-wide issues, synchronous discussion should be the mode
of last resort. Anything else creates a priesthood with a
disempowered laity wondering how things got away from them.

For community goals, in particular, preferring email for discussion
and planning seems pretty key.

I wonder if instead of specifying topics for TC office hours, we kill
them instead? They've turned into gossiping echo chambers.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] Polygerrit (was: [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo)

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 11:54:28 +0100 (+0100), Stephen Finucane wrote:
[...]
> As an aside, are there any plans to enable PolyGerrit [1] in the
> OpenStack Gerrit instance?
[...]

I believe so, but first we need to upgrade to a newer Gerrit version
which provides it (that in turn requires a newer Java which needs a
server built from a newer distro version, which is all we've gotten
through on the upgrade plan so far).
-- 
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] [edge][glance][ptg]: Image handling wiki updated

2018-10-15 Thread Csatari, Gergely (Nokia - HU/Budapest)
Hi,

I've updated the Image handling in edge environment wiki 
[1] based 
on the notes 
[2] from the 
Denver ptg discussions.

Please check and comment.

Thanks,
Gerg0

[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/glance-stein-edge-architecture
__
OpenStack Development Mailing 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][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Chris Dent

On Wed, 10 Oct 2018, Greg Hill wrote:


I guess I'm putting it forward to the larger community. Does anyone have
any objections to us doing this? Are there any non-obvious technicalities
that might make such a transition difficult? Who would need to be made
aware so they could adjust their own workflows?


I've been on both sides of conversations like this a few different
times. Generally speaking people who are not already in the
OpenStack environment express an unwillingness to participate
because of perceptions of walled-garden and too-many-hoops.

Whatever the reality of the situation, those perceptions matter, and
for libraries that are already or potentially useful to people who
are not in OpenStack, being "outside" is probably beneficial. And
for a library that is normally installed (or should optimally be
installed because, really, isn't it nice to be decoupled?) via pip,
does it matter to OpenStack where it comes from?


Or would it be preferable to just fork and rename the project so openstack
can continue to use the current taskflow version without worry of us
breaking features?


Fork sounds worse.

I've had gabbi contributors tell me, explicitly, that they would not
bother contributing if they had to go through what they perceive to
be the OpenStack hoops. That's anecdata, but for me it is pretty
compelling.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [infra] Polygerrit (was: [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo)

2018-10-15 Thread Stephen Finucane
On Wed, 2018-10-10 at 13:35 -0500, Greg Hill wrote:
> > If it's just about preferring the pull request workflow versus the 
> > Gerrit rebase workflow, just say so. Same for just preferring the Github 
> > UI versus Gerrit's UI (which I agree is awful).
> 
> I mean, yes, I personally prefer the Github UI and workflow, but that
> was not a primary consideration. I got used to using gerrit well
> enough. It was mostly the  There's also a sense that if a project is
> in the Openstack umbrella, it's not useful outside Openstack, and
> Taskflow is designed to be a general purpose library. The hope is
> that just making it a regular open source project might attract more
> users and contributors. This may or may not bear out, but as it is,
> there's no real benefit to staying an openstack project on this front
> since nobody is actively working on it within the community.

As an aside, are there any plans to enable PolyGerrit [1] in the
OpenStack Gerrit instance? The Gerrit documentation lists the feature
as a beta [2], but I suspect that might be out-of-date given how long
it's been around and folks suggesting the opposite elsewhere [3].

Stephen

[1] https://www.youtube.com/watch?v=WsPhoPGUsss
[2] https://www.gerritcodereview.com/dev-polygerrit.html#
[3] https://gitenterprise.me/2018/04/23/gerrithub-adopts-100-polygerrit/


__
OpenStack Development Mailing 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][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-15 Thread Stephen Finucane
On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote:
> On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote:
> [...]
> > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs
> > past muster before being merged, so it's not like we're wanting to
> > circumvent good contribution practices by committing whatever to HEAD.
> 
> Travis CI has gained the ability to prevent you from merging changes
> which fail testing? Or do you mean something else when you refer to
> it as a "gatekeeper" here?

Yup but it's GitHub feature rather than specifically a Travis CI
feature.

  https://help.github.com/articles/about-required-status-checks/

Doesn't help the awful pull request workflow but that's neither here
nor there.

Stephen


__
OpenStack Development Mailing 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] [edge][keystone][ptg]: Keystone edge architectures wiki updated

2018-10-15 Thread Csatari, Gergely (Nokia - HU/Budapest)
Hi,

I've updated the Keystone edge architectures wiki 
[1] based on the 
notes [2] we 
generated in the Denver workshop.

Please check and comment.

Thanks,
Gerg0

[1]: https://wiki.openstack.org/wiki/Keystone_edge_architectures
[2]: https://etherpad.openstack.org/p/keystone-stein-edge-architecture

__
OpenStack Development Mailing 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] [goals][upgrade-checkers] Week R-26 Update

2018-10-15 Thread Jean-Philippe Evrard
On Fri, 2018-10-12 at 17:05 -0500, Matt Riedemann wrote:
> The big update this week is version 0.1.0 of oslo.upgradecheck was 
> released. The documentation along with usage examples can be found
> here 
> [1]. A big thanks to Ben Nemec for getting that done since a few 
> projects were waiting for it.
> 
> In other updates, some changes were proposed in other projects [2].
> 
> And finally, Lance Bragstad and I had a discussion this week [3]
> about 
> the validity of upgrade checks looking for deleted configuration 
> options. The main scenario I'm thinking about here is FFU where
> someone 
> is going from Mitaka to Pike. Let's say a config option was
> deprecated 
> in Newton and then removed in Ocata. As the operator is rolling
> through 
> from Mitaka to Pike, they might have missed the deprecation signal
> in 
> Newton and removal in Ocata. Does that mean we should have upgrade 
> checks that look at the configuration for deleted options, or
> options 
> where the deprecated alias is removed? My thought is that if things
> will 
> not work once they get to the target release and restart the service 
> code, which would definitely impact the upgrade, then checking for
> those 
> scenarios is probably OK. If on the other hand the removed options
> were 
> just tied to functionality that was removed and are otherwise not 
> causing any harm then I don't think we need a check for that. It was 
> noted that oslo.config has a new validation tool [4] so that would
> take 
> care of some of this same work if run during upgrades. So I think 
> whether or not an upgrade check should be looking for config option 
> removal ultimately depends on the severity of what happens if the
> manual 
> intervention to handle that removed option is not performed. That's 
> pretty broad, but these upgrade checks aren't really set in stone
> for 
> what is applied to them. I'd like to get input from others on this, 
> especially operators and if they would find these types of checks
> useful.
> 
> [1] https://docs.openstack.org/oslo.upgradecheck/latest/
> [2] https://storyboard.openstack.org/#!/story/2003657
> [3] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
> [4] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html
> 

Hey,

Nice topic, thanks Matt!

TL:DR; I would rather fail explicitly for all removals, warning on all
deprecations. My concern is, by being more surgical, we'd have to
decide what's "not causing any harm" (and I think deployers/users are
best to determine what's not causing them any harm).
Also, it's probably more work to classify based on "severity".
The quick win here (for upgrade-checks) is not about being smart, but
being an exhaustive, standardized across projects, and _always used_
source of truth for upgrades, which is complemented by release notes.

Long answer:

At some point in the past, I was working full time on upgrades using
OpenStack-Ansible.

Our process was the following:
1) Read all the project's releases notes to find upgrade documentation
2) With said release notes, Adapt our deploy tools to handle the
upgrade, or/and write ourselves extra documentation+release notes for
our deployers.
3) Try the upgrade manually, fail because some release note was missing
x or y. Find root cause and retry from step 2 until success.

Here is where I see upgrade checkers improving things:
1) No need for deployment projects to parse all release notes for
configuration changes, as tooling to upgrade check would be directly
outputting things that need to change for scenario x or y that is
included in the deployment project. No need to iterate either.

2) Test real deployer use cases. The deployers using openstack-ansible
have ultimate flexibility without our code changes. Which means they
may have different code paths than our gating. Including these checks
in all upgrades, always requiring them to pass, and making them
explicit about the changes is tremendously helpful for deployers:
- If config deprecations are handled as warnings as part of the same
process, we will output said warnings to generate a list of action
items for the deployers. We would use only one tool as source of truth
for giving the action items (and still continue the upgrade);
- If config removals are handled as errors, the upgrade will fail,
which is IMO normal, as the deployer would not have respected its
action items.

In OSA, we could probably implement a deployer override (variable). It
would allow the deployers an explicit bypass of an upgrade failure. "I
know I am doing this!". It would be useful for doing multiple serial
upgrades.

In that case, deployers could then share together their "recipes" for
handling upgrade failure bypasses for certain multi-upgrade (jumps)
scenarios. After a while, we could think of feeding those back to
upgrade checkers.

3) I like the approach of having oslo-config-validator. However, I must
admit it's 

Re: [openstack-dev] [tc][all] Discussing goals (upgrades) with community @ office hours

2018-10-15 Thread Jean-Philippe Evrard
On Sat, 2018-10-13 at 15:04 +0200, Mohammed Naser wrote:
> I wanted to propose one of the upcoming office hours to perhaps
> invite
> some of the community members (PTL, developers, anyone!) as well as
> the TC with goal champions to perhaps discuss some of these goals to
> help everyone get a clear view on what's going on.
> 
> Does this seem like it would be of interest to the community?  I am
> currently trying to transform our office hours to be more of a space
> where we have more of the community and less of discussion between
> us.
> 

Great idea, mnaser. I think it's good if we discuss all together during
office hours!

I believe the office hours should not only be used for discussing
progress by subject-matter experts (SME), but also a place for the
community to discuss cross-team issues, and victories.

I like to have goal champions talking about progress in the next office
hours. +1!

JP


__
OpenStack Development Mailing 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] [Searchlight] Week of Stein R-26 report

2018-10-15 Thread Trinh Nguyen
Dear team,

Here is the report of last week, Stein R-26 (Oct 8-12):

https://www.dangtrinh.com/2018/10/searchlight-weekly-report-stein-r-26.html

If you have any questions, please let me know.

Bests,

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