Re: [openstack-dev] [ALL][requirements] A freeze is coming and you should be prepared

[Matthew Thode]

On 18-01-24 22:32:27, Matthew Thode wrote:
> On 18-01-24 01:29:47, Matthew Thode wrote:
> > On 18-01-23 01:23:50, Matthew Thode wrote:
> > > Requirements is freezing Friday at 23:59:59 UTC so any last
> > > global-requrements updates that need to get in need to get in now.
> > > 
> > > I'm afraid that my condition has left me cold to your pleas of mercy.
> > > 
> > 
> > Just your daily reminder that the freeze will happen in about 3 days
> > time.  Reviews seem to be winding down for requirements now (which is
> > a good sign this release will be chilled to perfection).
> > 
> 
> There's still a couple of things that may cause bumps for iso8601 and
> oslo.versionedobjects but those are the main things.  The msgpack change
> is also rolling out (thanks dirk :D).  Even with all these changes
> though, in this universe, there's only one absolute. Everything freezes!
> 
> https://review.openstack.org/535520 (oslo.serialization)
> 

Last day, gate is sad and behind, but not my fault you waited til the
last minute :P  (see my first comment).  The Iceman Cometh!

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

[Mathieu Gagné]

On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair  wrote:
> Mathieu Gagné  writes:
>
>> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec  wrote:
>>>
>>>
>>> I'm curious what this means as far as best practices for inter-patch
>>> references.  In the past my understanding was the the change id was
>>> preferred, both because if gerrit changed its URL format the change id links
>>> would be updated appropriately, and also because change ids can be looked up
>>> offline in git commit messages.  Would that still be the case for everything
>>> except depends-on now?
>
> Yes, that's a down-side of URLs.  I personally think it's fine to keep
> using change-ids for anything other than Depends-On, though in many of
> those cases the commit sha may work as well.
>
>> That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
>> means you can more easily cherry-pick between branches without having
>> to change the URL to match the new branch for your dependencies.
>
> Yes, there is a positive and negative aspect to this issue.
>
> On the one hand, for those times where it was convenient to say "depend
> on this change in all its forms across all branches of all projects",
> one must now add a URL for each.
>
> On the other hand, with URLs, it is now possible to indicate that a
> change specifically depends on another change targeted to one branch, or
> targeted to several branches.  Simply list each URL (or don't) as
> appropriate.  That wasn't possible before -- it wall all or none.
>
> -Jim
>

> The old syntax will continue to work for a while

I still believe Change-Id should be supported and not removed as
suggested. The use of URL assumes you have access to Gerrit to fetch
more information about the change.
This might not always be true or possible, especially when Gerrit is
kept private and only the git repository is replicated publicly and
you which to cherry-pick something (and its dependencies) from it.

--
Mathieu

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

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

[Eric Fried]

For my part, I tried it [1] and it doesn't seem to have worked.  (The
functional test failure is what the dep is supposed to have fixed.)  Did
I do something wrong?

[1] https://review.openstack.org/#/c/533821/12

On 01/25/2018 09:33 PM, Mathieu Gagné wrote:
> On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair  wrote:
>> Mathieu Gagné  writes:
>>
>>> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec  wrote:


 I'm curious what this means as far as best practices for inter-patch
 references.  In the past my understanding was the the change id was
 preferred, both because if gerrit changed its URL format the change id 
 links
 would be updated appropriately, and also because change ids can be looked 
 up
 offline in git commit messages.  Would that still be the case for 
 everything
 except depends-on now?
>>
>> Yes, that's a down-side of URLs.  I personally think it's fine to keep
>> using change-ids for anything other than Depends-On, though in many of
>> those cases the commit sha may work as well.
>>
>>> That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
>>> means you can more easily cherry-pick between branches without having
>>> to change the URL to match the new branch for your dependencies.
>>
>> Yes, there is a positive and negative aspect to this issue.
>>
>> On the one hand, for those times where it was convenient to say "depend
>> on this change in all its forms across all branches of all projects",
>> one must now add a URL for each.
>>
>> On the other hand, with URLs, it is now possible to indicate that a
>> change specifically depends on another change targeted to one branch, or
>> targeted to several branches.  Simply list each URL (or don't) as
>> appropriate.  That wasn't possible before -- it wall all or none.
>>
>> -Jim
>>
> 
>> The old syntax will continue to work for a while
> 
> I still believe Change-Id should be supported and not removed as
> suggested. The use of URL assumes you have access to Gerrit to fetch
> more information about the change.
> This might not always be true or possible, especially when Gerrit is
> kept private and only the git repository is replicated publicly and
> you which to cherry-pick something (and its dependencies) from it.
> 
> --
> Mathieu
> 
> __
> OpenStack Development Mailing 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] Swift-backed volume backups are still breaking the gate

[Clay Gerrard]

On Thu, Jan 25, 2018 at 7:01 PM, Matt Riedemann  wrote:

> Is ThreadSafeSysLogHandler something that could live in oslo.log so we
> don't have to whack this mole everywhere at random times?


That might make sense, unless we can get eventlet's monkey patching of the
logging module to do something similar...

FWIW, Swift doesn't use oslo.log and has it's own crufty logging issues:

https://bugs.launchpad.net/swift/+bug/1380815

-Clay
__
OpenStack Development Mailing 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] Swift-backed volume backups are still breaking the gate

[Matt Riedemann]

On 1/25/2018 6:41 PM, Clay Gerrard wrote:

Does it help that swift also had to fix this?

https://github.com/openstack/swift/blob/6d2503652b5f666275113cf9f3e185a2d9b3a121/swift/common/utils.py#L4415

The interesting/useful bit is where we replace our primary loghandlers 
createLock method to use one of these [Green|OS]-thread-safe PipeMutex 
lock things...


Is ThreadSafeSysLogHandler something that could live in oslo.log so we 
don't have to whack this mole everywhere at random times?


--

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] Issue with eventlet monkey patching

[Sławomir Kapłoński]

Hi,

Recently we found in Neutron errors with starting our agents which uses 
eventlet.monkey_patch() method. Bug is described in [1].

I heard on IRC that it's not related only to Neutron so here is what we found 
about that.
It looks that this issue happens on Ubuntu with python2.7 
2.7.12-1ubuntu0~16.04.3 with eventlet < 0.22.0 (in OpenStack requirements it is 
set to 0.20.0).
There is no this issue with python2.7.12-1ubuntu0~16.04.2 and eventlet 0.20.0

Something similar was already reported for monotonic in [2]. From one of 
comments there we found that problem can be caused because: 
"ctypes.util.find_library is now using subprocess.Popen, instead of os.popen 
(python/cpython@eb063011), and eventlet monkey-patches subprocess.Popen but not 
os.popen."

It looks that eventlet patch [3] fixes/workaround this issue.
I pushed similar patch to Neutron [4] and it looks that our issue is solved for 
now.

I hope that maybe this info will be helpful for You :)

[1] https://bugs.launchpad.net/neutron/+bug/1745013
[2] https://www.bountysource.com/issues/43892421-new-monotonic-broken-on-docker
[3] 
https://github.comhttps://review.openstack.org/#/c/537863/1/eventlet/eventlet/commit/b756447bab51046dfc6f1e0e299cc997ab343701
 
[4] https://review.openstack.org/#/c/537863

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
OpenStack Development Mailing 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][l3][flavors] FFE request for patch no 523257 and 532993

[Bhatia, Manjeet S]

Hello all !

I'd like to request a FFE for patch 523257 [1] that adds new resources and 
events to handle operations
For routers if L3 flavors framework is used. The neutron-lib part is already 
merged [lib] thanks to Boden and
Miguel for quick reviews on that. The second patch 53993 [2] adds the missing 
notifications for floatingip update
and delete events without which l3 flavor drivers Backends isn't able to 
perform the update and delete operations
on floatingip's correctly. These two patches are needed for L3 flavors driver 
in networking-odl [nodll3].


[1]. https://review.openstack.org/#/c/523257
[2]. https://review.openstack.org/#/c/532993

[lib] https://review.openstack.org/#/c/535512/
[nodll3] https://review.openstack.org/#/c/504182/


Thanks and regards !
Manjeet Singh Bhatia
__
OpenStack Development Mailing 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][l3][flavors][floatingip] FFE request for patch no 523257 and 532993

[Bhatia, Manjeet S]

Hello all !

I'd like to request a FFE for patch 523257 [1] that adds new resources and 
events to handle operations
For routers if L3 flavors framework is used. The neutron-lib part is already 
merged [lib] thanks to Boden and
Miguel for quick reviews on that. The second patch 53993 [2] adds the missing 
notifications for floatingip update
and delete events without which l3 flavor drivers Backends isn't able to 
perform the update and delete operations
on floatingip's correctly. These two patches are needed for L3 flavors driver 
in networking-odl [nodll3].


[1]. https://review.openstack.org/#/c/523257
[2]. https://review.openstack.org/#/c/532993

[lib] https://review.openstack.org/#/c/535512/
[nodll3] https://review.openstack.org/#/c/504182/


Sorry for 2nd email on this I forgot to add [openstack-dev] subject in last one.


Thanks and regards !
Manjeet Singh Bhatia

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

[openstack-dev] [tripleo] branching stable/queens for tripleoclient

[Emilien Macchi]

Hi,

We're about to release Queens milestone 3.

https://review.openstack.org/537752

Which means, we'll branch tripleoclient stable/queens this week.
Since we don't follow stable policy anymore, we can in theory accept any
backport but I would ask our team to backport only bugfixes and things
related to upgrades at that point (unless an FFE was granted).

Also, we'll have to create queens CI jobs in RDO CI & upstream zuul. No big
deal but just FYI.

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

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

[Ben Nemec]

On 01/24/2018 02:31 PM, Monty Taylor wrote:

On 01/24/2018 02:25 PM, David Shrewsbury wrote:

This is a (the?) killer feature.


On Wed, Jan 24, 2018 at 11:33 AM, James E. Blair > wrote:


    Hi,

    We recently introduced a new URL-based syntax for Depends-On: footers
    in commit messages:

   Depends-On: https://review.openstack.org/535851
    

    The old syntax will continue to work for a while, but please begin 
using

    the new syntax on new changes.

    Why are we changing this?  Zuul has grown the ability to interact 
with
    multiple backend systems (Gerrit, GitHub, and plain Git so far), 
and we

    have extended the cross-repo-dependency feature to support multiple
    systems.  But Gerrit is the only one that uses the change-id syntax.
    URLs, on the other hand, are universal.

    That means you can write, as in https://review.openstack.org/535541
    , a
    commit message such as:

   Depends-On:
    https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17
    

    Or in a Github pull request like
    https://github.com/ansible/ansible/pull/20974
    , you can write:

   Depends-On: https://review.openstack.org/536159
    

    But we're getting a bit ahead of ourselves here -- we're just getting
    started with Gerrit <-> GitHub dependencies and we haven't worked
    everything out yet.  While you can Depends-On any GitHub URL, you 
can't

    add any project to required-projects yet, and we need to establish a
    process to actually report on GitHub projects.  But cool things are
    coming.

    We will continue to support the Gerrit-specific syntax for a while,
    probably for several months at least, so you don't need to update the
    commit messages of changes that have accumulated precious +2s.  
But do
    please start using the new syntax now, so that we can age the old 
syntax

    out.

    There are a few differences in using the new syntax:

    * Rather than copying the change-id from a commit message, you'll 
need
   to get the URL from Gerrit.  That means the dependent change 
already
   needs to be uploaded.  In some complex situations, this may 
mean that
   you need to amend an existing commit message to add in the URL 
later.


   If you're uploading both changes, Gerrit will output the URL 
when you

   run git-review, and you can copy it from there.  If you are
    looking at
   an existing change in Gerrit, you can copy the URL from the 
permalink

   at the top left of the page.  Where it says "Change 535855 - Needs
   ..." the change number itself is the permalink of the change.



Is the permalink the only valid format here for gerrit? Or does the fully
expanded link also work. E.g.,

    Depends-On: https://review.openstack.org/536540

versus

    Depends-On: https://review.openstack.org/#/c/536540/


The fully expanded one works too. See:

   https://review.openstack.org/#/c/520812/

for an example of a patch with expanded links.


I'm curious what this means as far as best practices for inter-patch 
references.  In the past my understanding was the the change id was 
preferred, both because if gerrit changed its URL format the change id 
links would be updated appropriately, and also because change ids can be 
looked up offline in git commit messages.  Would that still be the case 
for everything except depends-on now?


__
OpenStack Development Mailing 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] Swift-backed volume backups are still breaking the gate

[Matt Riedemann]

We thought things were fixed with [1] but it turns out that swiftclient 
logs requests and responses at DEBUG level, so we're still switching 
thread context during a backup write and failing the backup operation, 
causing copious amounts of pain in the gate and piling up the rechecks.


I've got a workaround here [2] which will hopefully be good enough to 
stabilize things for awhile, but there is probably not much point in 
rechecking a lot of patches, at least ones that run through the 
integrated gate, until that is merged.


[1] https://review.openstack.org/#/c/537437/
[2] https://review.openstack.org/#/c/538027/

--

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] [keystone] FFE for application credentials

[Lance Bragstad]

Hey all,

The work for application credentials [0] has been up for a while,
reviewers are happy with it, and it is slowly making it's way through
the gate. I propose we consider a feature freeze exception given the
state of the gate and the frequency of rechecks/failures.

Thoughts, comments, or concerns?

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/application-credentials




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

[openstack-dev] [keystone] FFE for unified limits

[Lance Bragstad]

Hey all,

The work for unified limits [0] has been up for a while, reviewers are
happy with it being experimental, and it is slowly making it's way
through the gate. I propose we consider a feature freeze exception given
the state of the gate and the frequency of rechecks/failures.

Thoughts, comments, or concerns?

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limits




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

[openstack-dev] [keystone] FFE for application credentials

[Lance Bragstad]

Hey all,

The work for system assignments and system scope [0] has been up for a
while, reviewers are happy with it, and it is slowly making it's way
through the gate. I propose we consider a feature freeze exception given
the state of the gate and the frequency of rechecks/failures.

Thoughts, comments, or concerns?

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope




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

Re: [openstack-dev] [keystone] FFE for application credentials

[Lance Bragstad]

The subject of this message should have been "FFE for system scope"...
not application credentials. Apologies for the confusion.

On 01/25/2018 03:15 PM, Lance Bragstad wrote:
> Hey all,
>
> The work for system assignments and system scope [0] has been up for a
> while, reviewers are happy with it, and it is slowly making it's way
> through the gate. I propose we consider a feature freeze exception given
> the state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
>
>




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

Re: [openstack-dev] [keystone] FFE for unified limits

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for unified limits [0] has been up for a while, reviewers are
> happy with it being experimental, and it is slowly making it's way
> through the gate. I propose we consider a feature freeze exception given
> the state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limits
>
>
>
> __
> OpenStack Development Mailing 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] [keystone] FFE for application credentials

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for application credentials [0] has been up for a while,
> reviewers are happy with it, and it is slowly making it's way through
> the gate. I propose we consider a feature freeze exception given the
> state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/application-credentials
>
>
>
> __
> OpenStack Development Mailing 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] [keystone] FFE for application credentials

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for system assignments and system scope [0] has been up for a
> while, reviewers are happy with it, and it is slowly making it's way
> through the gate. I propose we consider a feature freeze exception given
> the state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
>
>
>
> __
> OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[Mathieu Gagné]

On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec  wrote:
>
>
> I'm curious what this means as far as best practices for inter-patch
> references.  In the past my understanding was the the change id was
> preferred, both because if gerrit changed its URL format the change id links
> would be updated appropriately, and also because change ids can be looked up
> offline in git commit messages.  Would that still be the case for everything
> except depends-on now?
>

That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
means you can more easily cherry-pick between branches without having
to change the URL to match the new branch for your dependencies.

--
Mathieu

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

Re: [openstack-dev] [keystone] FFE for unified limits

[Harry Rybacki]

On Thu, Jan 25, 2018 at 4:17 PM, Colleen Murphy  wrote:
> +1
>
+1
> On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad  wrote:
>> Hey all,
>>
>> The work for unified limits [0] has been up for a while, reviewers are
>> happy with it being experimental, and it is slowly making it's way
>> through the gate. I propose we consider a feature freeze exception given
>> the state of the gate and the frequency of rechecks/failures.
>>
>> Thoughts, comments, or concerns?
>>
>> [0]
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limits
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [keystone] FFE for application credentials

[Harry Rybacki]

On Thu, Jan 25, 2018 at 4:24 PM, Colleen Murphy  wrote:
> +1
>
+1

> On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
>> Hey all,
>>
>> The work for system assignments and system scope [0] has been up for a
>> while, reviewers are happy with it, and it is slowly making it's way
>> through the gate. I propose we consider a feature freeze exception given
>> the state of the gate and the frequency of rechecks/failures.
>>
>> Thoughts, comments, or concerns?
>>
>> [0]
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [cinder] Deprecation of Kaminario and Pure automatic calculation for max_over_subscription_ratio

[Erlon Cruz]

Folks,

In the Queens release, Cinder has implemented an internal mechanism to
automatically calculate the max_over_subscription_ratio[1]. As Kaminario
and Pure drivers already have a config option and are doing that
internally, we kindly recommend that the driver maintainers deprecate those
options in favor of the more generic option
(max_over_subscription_ratio=auto) in order to maintain a better more
consistent behavior among drivers.

You can find me (erlon) at #openstack-cinder if you have any further
questions.

Sincerely,
Erlon


[1] https://review.openstack.org/#/c/534854/
__
OpenStack Development Mailing 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] Issue with eventlet monkey patching

[Brian Rosmaita]

Thanks Slawek, this indeed looks like the problem we are having with
Glance.  Searchlight, too.


On Thu, Jan 25, 2018 at 10:53 AM, Sławomir Kapłoński
 wrote:
> Hi,
>
> Recently we found in Neutron errors with starting our agents which uses 
> eventlet.monkey_patch() method. Bug is described in [1].
>
> I heard on IRC that it's not related only to Neutron so here is what we found 
> about that.
> It looks that this issue happens on Ubuntu with python2.7 
> 2.7.12-1ubuntu0~16.04.3 with eventlet < 0.22.0 (in OpenStack requirements it 
> is set to 0.20.0).
> There is no this issue with python2.7.12-1ubuntu0~16.04.2 and eventlet 0.20.0
>
> Something similar was already reported for monotonic in [2]. From one of 
> comments there we found that problem can be caused because:
> "ctypes.util.find_library is now using subprocess.Popen, instead of os.popen 
> (python/cpython@eb063011), and eventlet monkey-patches subprocess.Popen but 
> not os.popen."
>
> It looks that eventlet patch [3] fixes/workaround this issue.
> I pushed similar patch to Neutron [4] and it looks that our issue is solved 
> for now.
>
> I hope that maybe this info will be helpful for You :)
>
> [1] https://bugs.launchpad.net/neutron/+bug/1745013
> [2] 
> https://www.bountysource.com/issues/43892421-new-monotonic-broken-on-docker
> [3] 
> https://github.comhttps://review.openstack.org/#/c/537863/1/eventlet/eventlet/commit/b756447bab51046dfc6f1e0e299cc997ab343701
> [4] https://review.openstack.org/#/c/537863
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> __
> OpenStack Development Mailing 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] [tripleo] branching stable/queens for tripleoclient

[Emilien Macchi]

On Thu, Jan 25, 2018 at 10:59 AM, Emilien Macchi  wrote:

> Hi,
>
> We're about to release Queens milestone 3.
>
> https://review.openstack.org/537752
>
> Which means, we'll branch tripleoclient stable/queens this week.
> Since we don't follow stable policy anymore, we can in theory accept any
> backport but I would ask our team to backport only bugfixes and things
> related to upgrades at that point (unless an FFE was granted).
>
> Also, we'll have to create queens CI jobs in RDO CI & upstream zuul. No
> big deal but just FYI.
>

I think https://review.openstack.org/#/c/538053/ and
https://review.rdoproject.org/r/#/c/11598/ are the main things to do on
short term.
We'll also have periodic jobs but that can wait.


>
> Any comment / feedback is welcome,
> Thanks!
> --
> Emilien Macchi
>



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

Re: [openstack-dev] [nova][thirdparty][CI] Nova IBM zKVM CI broken

[Andreas Scheuring]

CI should be back online now, tests are running again… Let’s see if the tests 
succeed..

The issue was, that for some reason a new pip package ‘python-pcre’ got 
installed. But the build failed, as the build dependency 'libpcre3-dev’ as not 
satisfied. Now the package 'libpcre3-dev' is part of the daily nodepool image 
build.

---
Andreas Scheuring (andreas_s)



On 25. Jan 2018, at 10:57, Andreas Scheuring  
wrote:

Hi, the Nova IBM zKVM CI is currently producing invalid builds. Please ignore 
the -1 results for now. I’m working on fixing it. Will let you know once it’s 
working fine again.  Thanks!

---
Andreas Scheuring (andreas_s)



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

[James E. Blair]

Mathieu Gagné  writes:

> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec  wrote:
>>
>>
>> I'm curious what this means as far as best practices for inter-patch
>> references.  In the past my understanding was the the change id was
>> preferred, both because if gerrit changed its URL format the change id links
>> would be updated appropriately, and also because change ids can be looked up
>> offline in git commit messages.  Would that still be the case for everything
>> except depends-on now?

Yes, that's a down-side of URLs.  I personally think it's fine to keep
using change-ids for anything other than Depends-On, though in many of
those cases the commit sha may work as well.

> That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
> means you can more easily cherry-pick between branches without having
> to change the URL to match the new branch for your dependencies.

Yes, there is a positive and negative aspect to this issue.

On the one hand, for those times where it was convenient to say "depend
on this change in all its forms across all branches of all projects",
one must now add a URL for each.

On the other hand, with URLs, it is now possible to indicate that a
change specifically depends on another change targeted to one branch, or
targeted to several branches.  Simply list each URL (or don't) as
appropriate.  That wasn't possible before -- it wall all or none.

-Jim

__
OpenStack Development Mailing 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][oslo.log] JSON logs are missing the request ID

[Doug Hellmann]

Excerpts from Saverio Proto's message of 2018-01-24 22:18:39 +0100:
> > 3.34.0 is a queens series release, which makes it more likely that more
> > other dependencies would need to be updated. Even backporting the
> > changes to the Ocata branch and releasing it from there would require
> > updating several other libraries.
> > 
> 
> That is what I was fearing. Consider that our upgrade schedule is now to
> have Pike by the end of 2018. Unless we try to skip a release.

You should seriously consider upgrading to at least Queens. Pike will be out
of community support by Sept 2018 (https://releases.openstack.org). Some
of the community deployment tools have support for "fast-forward"
upgrades (allowing you to install several versions in series and only
launch the cloud again when the final version is installed). You can
check with the team that manages your deployment tool to see if it
supports this capability.

> > Are you using packages from Canonical, or are you building them
> > yourself?
> 
> I am using the packages from Canonical, but I am familiar patching those
> packages and merge my changes upstream back to Canonical.
> If the problem is just dependencies with the ".deb" packages, I can
> handle that. But if the problem is really python code not working
> together across multiple components, then I have little hope to fix this
> in Newton.

I don't know Canonical's support policies, but it may be possible to
backport a patch to oslo.log to provide the missing information.

> Thanks for the support, if I manage to make some progress on this I will
> send an update on this thread on the mailing list.

Good luck, and please do let me know how it goes.

Doug

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

[openstack-dev] [nova] q-3 tag and gate status

[Matt Riedemann]

At this point in the day, I'm going to push the q-3 tag. We have quite a 
few things approved but not yet merged (some for over 20 hours in the 
gate now).


The latest list of stuff that's approved is in the etherpad here:

https://etherpad.openstack.org/p/nova-queens-blueprint-status

I don't expect FFEs for the rest of it. We've got a lot of code to 
recheck grind through the gate in the next several days, and we're only 
two weeks from RC1, so I don't want to spend time reviewing feature code 
for FFEs and instead focus on bug triage / fixes, docs, testing, etc 
because we're bound to have some stuff crop up late as a result of 
what's being merged this week.


I would like to somehow focus on prioritizing reviews early in Rocky on 
the series of blueprints that have been carried for multiple releases 
now so that we can flush those through before taking on more work, but 
that's a discussion for the PTG.


--

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] [tripleo] CI'ing ceph-ansible against TripleO scenarios

[Emilien Macchi]

Is there any plans to run TripleO CI jobs in ceph-ansible?
I know the project is on github but thanks to zuulv3 we can now easily
configure ceph-ansible to run Ci jobs in OpenStack Infra.

It would be really great to investigate that in the near future so we avoid
eventual regressions.
Sebastien, Giulio, John, thoughts?
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Swift-backed volume backups are still breaking the gate

[Clay Gerrard]

Does it help that swift also had to fix this?

https://github.com/openstack/swift/blob/6d2503652b5f666275113cf9f3e185a2d9b3a121/swift/common/utils.py#L4415

The interesting/useful bit is where we replace our primary loghandlers
createLock method to use one of these [Green|OS]-thread-safe PipeMutex lock
things...

-Clay

On Thu, Jan 25, 2018 at 1:12 PM, Matt Riedemann  wrote:

> We thought things were fixed with [1] but it turns out that swiftclient
> logs requests and responses at DEBUG level, so we're still switching thread
> context during a backup write and failing the backup operation, causing
> copious amounts of pain in the gate and piling up the rechecks.
>
> I've got a workaround here [2] which will hopefully be good enough to
> stabilize things for awhile, but there is probably not much point in
> rechecking a lot of patches, at least ones that run through the integrated
> gate, until that is merged.
>
> [1] https://review.openstack.org/#/c/537437/
> [2] https://review.openstack.org/#/c/538027/
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][ptl][all] please approve the reno updates for queens

[Doug Hellmann]

As part of creating branches for projects, the job proposes updates to
add a "queens" page to the release notes build. The script prepares a
best-effort version of the update, but local variances in the
repositories means that doesn't always work.

Please take the patches over and fix them, then land them as quickly as
is reasonable to ensure that the release notes for your project are
published correctly.

https://review.openstack.org/#/q/topic:reno-queens

Thanks!
Doug

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

Re: [openstack-dev] [tripleo] CI'ing ceph-ansible against TripleO scenarios

[Paul Belanger]

On Thu, Jan 25, 2018 at 04:22:56PM -0800, Emilien Macchi wrote:
> Is there any plans to run TripleO CI jobs in ceph-ansible?
> I know the project is on github but thanks to zuulv3 we can now easily
> configure ceph-ansible to run Ci jobs in OpenStack Infra.
> 
> It would be really great to investigate that in the near future so we avoid
> eventual regressions.
> Sebastien, Giulio, John, thoughts?
> -- 
> Emilien Macchi

Just a note, we haven't actually agree to enable CI for github projects just
yet.  While it is something zuul can do now, I believe we still need to decide
when / how to enable it.

We are doing some initial testing with ansible/ansible however.

-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] [kuryr][libnetwork] Release kuryr-libnetwork 1.x for Queens

[Antoni Segura Puimedon]

On Mon, Jan 22, 2018 at 3:46 PM, Daniel Mellado
 wrote:
> +1
>
>
> El 21/1/18 a las 8:13, Irena Berezovsky escribió:
>
> +1
>
> On Fri, Jan 19, 2018 at 9:42 PM, Hongbin Lu  wrote:
>>
>> Hi Kuryr team,
>>
>> I think Kuryr-libnetwork is ready to move out of beta status. I propose to
>> make the first 1.x release of Kuryr-libnetwork for Queens and cut a stable
>> branch on it. What do you think about this proposal?

Agreed. Thanks a lot for bringing it up Hongbin!

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

Re: [openstack-dev] [release][puppet] Tarballs missing for some puppet modules in pike

[Alfredo Moralejo Alonso]

Hi,

We had the same issue again in release-post job for
https://review.openstack.org/#/c/536927/

Logs in
http://logs.openstack.org/32/323c387a2d1794e0679510657629470da8f7de92/release-post/tag-releases/b2091f1/job-output.txt.gz
shows a similar issue. The script stuck at doing a "git fetch"

Best regards,

Alfredo


On Fri, Jan 19, 2018 at 6:29 PM, Alfredo Moralejo Alonso <
amora...@redhat.com> wrote:

>
>
> On Fri, Jan 19, 2018 at 5:50 PM, Sean McGinnis 
> wrote:
>
>> >
>> > Just an update - it does look like it was just the one job failure.
>> There are
>> > multiple puppet-* releases done as part of the one job, and it appears
>> they are
>> > processed in alphabetically order. So this last time it got as far as
>> > puppet-swift (at least further along than puppet-horizon) before it hit
>> this
>> > timeout.
>> >
>> > I'm fairly confident once we get the job to run again it should make it
>> through
>> > these last few releases.
>> >
>>
>> Jeremy was able to re-queue the job, and it appears everything completed
>> as
>> expected. I've taken a quick look through the tarballs, and I think
>> everything
>> is there. Please take a look and let me know if you see anything unusual.
>>
>>
> Yeah, everything looks ok to me now.
>
> Thanks for your help,
>
> Alfredo
>
>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matthew Booth]

On 24 January 2018 at 22:57, Matt Riedemann  wrote:

> On 1/22/2018 8:22 AM, Lee Yarwood wrote:
>
>> Hello,
>>
>> With M3 and FF rapidly approaching this week I wanted to post a brief
>> overview of the QEMU native LUKS series.
>>
>> The full series is available on the following topic, I'll go into more
>> detail on each of the changes below:
>>
>> https://review.openstack.org/#/q/topic:bp/libvirt-qemu-nativ
>> e-luks+status:open
>>
>> libvirt: Collocate encryptor and volume driver calls
>> https://review.openstack.org/#/c/460243/ (Missing final +2 and +W)
>>
>> This refactor of the Libvirt driver connect and disconnect volume code
>> has the added benefit of also correcting a number of bugs around the
>> attaching and detaching of os-brick encryptors. IMHO this would be
>> useful in Queens even if the rest of the series doesn't land.
>>
>> libvirt: Introduce disk encryption config classes
>> https://review.openstack.org/#/c/464008/ (Missing final +2 and +W)
>>
>> This is the most straight forward change of the series and simply
>> introduces the required config classes to wire up native LUKS decryption
>> within the domain XML of an instance. Hopefully nothing controversial.
>>
>> libvirt: QEMU native LUKS decryption for encrypted volumes
>> https://review.openstack.org/#/c/523958/ (Missing both +2s and +W)
>>
>> This change carries the bulk of the implementation, wiring up encrypted
>> volumes during their initial attachment. The commit message has a
>> detailed run down of the various upgrade and LM corner cases we attempt
>> to handle here, such as LM from a P to Q compute, detaching a P attached
>> encrypted volume after upgrading to Q etc.
>>
>> Upgrade and LM testing is enabled by the following changes:
>>
>> fixed_key: Use a single hardcoded key across devstack deployments
>> https://review.openstack.org/#/c/536343/
>>
>> compute: Introduce an encrypted volume LM test
>> https://review.openstack.org/#/c/536177/
>>
>> This is being tested by tempest-dsvm-multinode-live-migration and
>> grenade-dsvm-neutron-multinode-live-migration in the following DNM Nova
>> change, enabling volume backed LM tests:
>>
>> DNM: Test LM with encrypted volumes
>> https://review.openstack.org/#/c/536350/
>>
>> Hopefully that covers everything but please feel free to ping if you
>> would like more detail, background etc. Thanks in advance,
>>
>> Lee
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> The patch is already approved, and I asked melwitt to write a release
> note, at which point it was noted that swap volume will not work with
> native luks encrypted volumes. That's a regression.
>

It's only a regression since swap_volume with encrypted volumes was fixed
in https://review.openstack.org/#/c/460243/, which landed on Monday as part
of this series. Prior to Monday, swap_volume with encrypted volumes would
result in the raw encrypted volume being presented to the guest after the
swap.

We need to at least report a nova bug for this so we can work on some kind
> of fallback to the non-native decryption until there is a libvirt/qemu fix
> upstream and we can put version conditionals in place for when we can
> support swap volume with a native luks-encrypted volume.
>

In the context of the above, I don't think this is a priority as clearly
nobody is currently doing it. There's already a bug to track the problem in
libvirt, which is linked in a code comment. Admittedly that BZ is
unnecessarily private, which I noted in review, but we've reached out to
the author to ask them to open it up as there's nothing sensitive going on
in there.

In general, anything qemu can do natively makes Nova both simpler and more
robust because we don't have to modify the host configuration. This
eliminates a whole class of error states and race conditions, because when
we kill qemu there's nothing left to clean up.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)
__
OpenStack Development Mailing 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][thirdparty][CI] Nova IBM zKVM CI broken

[Andreas Scheuring]

Hi, the Nova IBM zKVM CI is currently producing invalid builds. Please ignore 
the -1 results for now. I’m working on fixing it. Will let you know once it’s 
working fine again.  Thanks!

---
Andreas Scheuring (andreas_s)



__
OpenStack Development Mailing 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] PTL Election Season

[Kashyap Chamarthy]

On Mon, Jan 22, 2018 at 05:09:31PM -0600, Matt Riedemann wrote:

[...]

> To anyone that cares, I don't plan on running for Nova PTL again for the
> Rocky release. Queens was my fourth tour and it's definitely time for
> someone else to get the opportunity to lead here. I don't plan on going
> anywhere and I'll be here to help with any transition needed assuming
> someone else (or a couple of people hopefully) will run in the election.
> It's been a great experience and I thank everyone that has had to put up
> with me and my obsessive paperwork and process disorder in the meantime.

Hey Matt,

Thanks (understatement!) for the all the brilliant work (and also for
all the thankless tasks).  I deeply appreciate how effectively you
handle communication in public and the energy that you bring to the
project.  It is a great joy interacting and working with you.

I continue to be amazed at how you can stay on top of almost everything
(at least give the illusion of it -- it reminds me of the "Sheperd
Tone"[*]), _while_ getting things done.

Glad to hear you're not going anywhere.  

To be continued.

[*] https://en.wikipedia.org/wiki/Shepard_tone
https://www.youtube.com/watch?v=LVWTQcZbLgY

-- 
/kashyap

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

Re: [openstack-dev] [requirements] [vitrage][glance] global requirements update for python-vitrageclient

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Adding Glance team. 
Any idea what could be wrong?

Thanks,
Ifat.


On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)"  
wrote:

Hi,

I tried to update the version of python-vitrageclient [1], but the 
legacy-requirements-integration-dsvm test failed with an error that does not 
seem related to my changes:

error: can't copy 'etc/glance-image-import.conf': doesn't exist or not a 
regular file

I noticed that two other changes [2][3] failed with the same error.

Can you please help?

Thanks,
Ifat.


[1] https://review.openstack.org/#/c/537307
[2] https://review.openstack.org/#/c/535460/
[3] https://review.openstack.org/#/c/536142/



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

[openstack-dev] [release] Release countdown for week R-4, January 27 - February 2

[Sean McGinnis]

Happy deadline week everyone. Here's what's coming up for next week.

Development Focus
-

The R-4 week is our one deadline free week between the lib freezes and Queens-3
milestone and RC.

Work should be focused on fixing any requirements update issues, critical bugs,
and wrapping up feature work to prepare for the Release Candidate deadline (for
deliverables following the with-milestones model) or final Queens releases (for
deliverables following the with-intermediary model) next Thursday, 8th of
February.

General Information
---

For deliverables following the cycle-with-milestones model, we are now past
Feature Freeze. The focus should be on determining and fixing release-critical
bugs. At this stage only bugfixes should be approved for merging in the master
branches: feature work should only be considered if explicitly granted a
Feature Freeze exception by the team PTL (after a public discussion on the
mailing-list).

StringFreeze is now in effect, in order to let the I18N team do the translation
work in good conditions. The StringFreeze is currently soft (allowing
exceptions as long as they are discussed on the mailing-list
and deemed worth the effort). It will become a hard StringFreeze on 8th of
February along with the RC.

The requirements repository is also frozen, until all cycle-with-milestones
deliverables have produced a RC1 and have their stable/queens branches.

Note that deliverables that are not tagged for release by the appropriate
deadline will be reviewed to see if they are still active enough to stay on the
official project list.

Actions
-

stable/queens branches should be created soon for all non-already-branched
libraries. You should expect 2-3 changes to be proposed for each: a .gitreview
update, a reno update (skipped for projects not using reno), and a tox.ini
constraints URL update. Please review those in priority so that the branch can
be functional ASAP.

For cycle-with-intermediary deliverables, release liaisons should consider
releasing their latest version, and creating stable/queens branches from it
ASAP.

For cycle-with-milestones deliverables, release liaisons should wait until R-3
week to create RC1 (to avoid having an RC2 created quickly after). Review
release notes for any missing information, and start
preparing "prelude" release notes as summaries of the content of the release so
that those are merged before the first release candidate.

Along with the prelude work, it is also a good time to start planning what
highlights you want for your project team in the cycle highlights:

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html

For release-independent deliverables, release liaisons should check that their
deliverable file includes all the existing releases, so that they can be
properly accounted for in the releases.openstack.org website.

If your team has not done so, remember to file Queens goal completion
information, as explained in:

https://governance.openstack.org/tc/goals/index.html#completing-goals

Upcoming Deadlines & Dates
--

Rocky PTL nominations: January 29 - February 1
Rocky PTL election: February 7 - 14
OpenStack Summit Vancouver CFP deadline: February 8
Rocky PTG in Dublin: Week of February 26, 2018

-- 
Sean McGinnis (smcginnis)

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

Re: [openstack-dev] [release][puppet] Tarballs missing for some puppet modules in pike

[Sean McGinnis]

On Thu, Jan 25, 2018 at 10:49:10AM +0100, Alfredo Moralejo Alonso wrote:
> Hi,
> 
> We had the same issue again in release-post job for
> https://review.openstack.org/#/c/536927/
> 
> Logs in
> http://logs.openstack.org/32/323c387a2d1794e0679510657629470da8f7de92/release-post/tag-releases/b2091f1/job-output.txt.gz
> shows a similar issue. The script stuck at doing a "git fetch"
> 
> Best regards,
> 
> Alfredo
> 

Thanks Alfredo. I have requested that job be run again.

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

[openstack-dev] [all][api] API-SIG meeting cancelled

[Chris Dent]

Today's (25th January) API-SIG meeting has been cancelled. The usual
chairs are either travelling or ill. Regular schedule will resume
next week.

--
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] [vitrage] Vitrage templates are now loaded using a new API

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

A new API for Vitrage template add and template delete was added this week.

As part of this change, Vitrage templates are now stored in a database and are 
no longer read from the file system. In case you are using templates, make sure 
to call the new API and add them to Vitrage once you get the latest version.

More details can be found on the spec [1] and on Vitrage API [2] and CLI [3] 
documentation.

Thanks,
Ifat.

[1] 
https://specs.openstack.org/openstack/vitrage-specs/specs/queens/implemented/template-CRUD.html
 
[2] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html 
[3] https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html 
 



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

[openstack-dev] (no subject)

[Osaf Ali]

osa...@gmail.com
__
OpenStack Development Mailing 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] RHOSP 10 registering nodes for the undercloud fails

[Anda Nicolae]

Hello,

I am trying to deploy OpenStack 10 using OpenStack Platform Director 10.
I am using a bare-metal server with RedHat 7.4, on which I have created 3 VMs: 
1st VM is the undercloud node, 2nd VM is the overcloud controller node and the 
3rd VM is the overcloud compute node.
The bare-metal server I am using is also my KVM hypervisor for the overcloud.
The bare-metal server has 2 interfaces: an external interface used in 
instackenv.json for registering the overcloud nodes and a provisioning 
interface which will be used for provisioning the overcloud nodes.

My 1st question is: Is it mandatory that the KVM hypervisor for the overcloud 
VMs and the undercloud are the same machine?
As you can see, in my case the undercloud VM and the KVM hypervisor are 
different machines.
I saw a blog post which used a topology similar to mine: 
https://keithtenzer.com/2017/04/20/red-hat-openstack-platform-10-newton-installation-and-configuration-guide/

The error I am getting while running:
openstack baremetal import -- json ~/.instackenv.json
is in ironic_conductor.log: Failed to validate power driver interface for node 
. Error: SSH connection cannot be established: Failed to establish SSH 
connection to host 

I have created the instackenv.json file which looks similar to this:

  "arch": "x86_64",
  "host-ip": "kvm_hypervisor_external_ip_address",
  "power_manager": 
"nova.virt.baremetal.virtual_power_driver.VirtualPowerManager",
  "ssh-user": "stack",
  "ssh-key": "$(cat ~/.ssh/id_rsa)",
  "nodes": [
{
  "mac": [
""
  ],
  "name": "overcloud-controller",
  "capabilities" : "profile:control",
  "cpu": "4",
  "memory": "6000",
  "disk": "50",
  "arch": "x86_64",
  "pm_user": "stack",
  "pm_addr": "kvm_hypervisor_external_ip_address",
  "pm_password": "$(cat ~/.ssh/id_rsa)",
  "pm_type": "pxe_ssh"
}
,
{
  "mac": [
""
  ],
  "name": "overcloud-compute",
  "capabilities" : "profile:compute",
  "cpu": "4",
  "memory": "6000",
  "disk": "50",
  "arch": "x86_64",
  "pm_user": "stack",
  "pm_addr": "hypervisor_external_ip_address",
  "pm_password": "$(cat ~/.ssh/id_rsa)",
  "pm_type": "pxe_ssh"
}
  ]
}

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