Re: [openstack-dev] [tripleo] 'overcloud deploy' doesn't restart haproxy (Pike)

[Juan Antonio Osorio]

It is unfortunately a known issue and is present in queens and master as
well. I think Michele (bandini on IRC) was working on it.

On Thu, 21 Jun 2018, 06:45 Lars Kellogg-Stedman,  wrote:

> I've noticed that when updating the overcloud with 'overcloud deploy',
> the deploy process does not restart the haproxy containers when there
> are changes to the haproxy configuration.
>
> Is this expected behavior?
>
> --
> Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
> http://blog.oddbit.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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

On Thu, Jun 21, 2018 at 12:13 PM, Tony Breeds  wrote:
> On Wed, Jun 20, 2018 at 08:54:56PM +0900, Takashi Yamamoto wrote:
>
>> do you have a plan to submit these changes on gerrit?
>
> I didn't but I have now:
>
>  * https://review.openstack.org/577028
>  * https://review.openstack.org/577029
>
> Feel free to edit/test as you like.

thank you!

>
> 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] [heat] [heat-translator] Need new release of heat-translator library

[Patil, Tushar]

Thank you all for your support.

Updating upper constraints patch is already merged.
https://review.openstack.org/#/c/576917/1

We have proposed a patch to update lower constraints of heat-translator library 
to 1.1.0 in openstack/requirements project.
https://review.openstack.org/#/c/577021/

Regards,
Tushar Patil

On Jun 21, 2018, at 1:01 AM, HADDLETON, Robert W (Bob) 
mailto:bob.haddle...@nokia.com>> wrote:

This request had come to me from someone else in the Tacker team and I was 
working on including a couple of other patchsets in the release, but this is 
fine.

Please tag these requests as [heat-translator] in the subject so they get 
flagged to me and I'm happy to work them.

Bob

On 6/20/2018 10:40 AM, Rico Lin wrote:
I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for 
heat-translator team

Ben Nemec mailto:openst...@nemebean.com>> 於 2018年6月20日 
週三 下午10:26寫道：


On 06/20/2018 02:58 AM, Patil, Tushar wrote:
> Hi,
>
> Few weeks back, we had proposed a patch [1] to add support for translation of 
> placement policies and that patch got merged.
>
> This feature will be consumed by tacker specs [2] which we are planning to 
> implement in Rocky release and it's implementation is uploaded in patch [3]. 
> Presently, the tests are failing on patch [3] becoz it requires newer version 
> of heat-translator library.
>
> Could you please release a new version of heat-translator library so that we 
> can complete specs[2] in Rocky timeframe.

Note that you can propose a release to the releases repo[1] and then you
just need the PTL or release liaison to sign off on it.

1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

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


--
May The Force of OpenStack Be With You,
Rico Lin
irc: ricolin








Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged,confidential, 
and proprietary data. If you are not the intended recipient,please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.
__
OpenStack Development Mailing 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] 'overcloud deploy' doesn't restart haproxy (Pike)

[Lars Kellogg-Stedman]

I've noticed that when updating the overcloud with 'overcloud deploy',
the deploy process does not restart the haproxy containers when there
are changes to the haproxy configuration.

Is this expected behavior?

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.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

Re: [openstack-dev] [magnum] K8S apiserver key sync

[Remo Mattei]

Thanks Fei, 
I did post the question on that channel no much noise there though.. I would 
really like to get this configured since we are pushing for production. 

Thanks 

> On Jun 20, 2018, at 8:27 PM, Fei Long Wang  wrote:
> 
> Hi Remo,
> 
> I can't see obvious issue from the log you posted. You can pop up at 
> #openstack-containers IRC channel as for Magnum questions. Cheers.
> 
> 
> On 21/06/18 08:56, Remo Mattei wrote:
>> Hello guys, what will be the right channel to as a question about having K8 
>> (magnum working with Tripleo)? 
>> 
>> I have the following errors..
>> 
>> http://pastebin.mattei.co/index.php/view/2d1156f1 
>> 
>> 
>> Any tips are appreciated. 
>> 
>> Thanks 
>> Remo 
>> 
>>> On Jun 19, 2018, at 2:13 PM, Fei Long Wang >> > wrote:
>>> 
>>> Hi there,
>>> 
>>> For people who maybe still interested in this issue. I have proposed a 
>>> patch, see https://review.openstack.org/576029 
>>>  And I have verified with Sonobuoy for 
>>> both multi masters (3 master nodes) and single master clusters, all worked. 
>>> Any comments will be appreciated. Thanks.
>>> 
>>> 
>>> On 21/05/18 01:22, Sergey Filatov wrote:
 Hi!
 I’d like to initiate a discussion about this bug: [1].
 To resolve this issue we need to generate a secret cert and pass it to 
 master nodes. We also need to store it somewhere to support scaling.
 This issue is specific for kubernetes drivers. Currently in magnum we have 
 a general cert manager which is the same for all the drivers.
 
 What do you think about moving cert_manager logic into a driver-specific 
 area?
 Having this common cert_manager logic forces us to generate client cert 
 with “admin” and “system:masters” subject & organisation names [2], 
 which is really something that we need only for kubernetes drivers.
 
 [1] https://bugs.launchpad.net/magnum/+bug/1766546 
 
 [2] 
 https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
  
 
 
 
 ..Sergey Filatov
 
 
 
> On 20 Apr 2018, at 20:57, Sergey Filatov  > wrote:
> 
> Hello,
> 
> I looked into k8s drivers for magnum I see that each api-server on master 
> node generates it’s own service-account-key-file. This causes issues with 
> service-accounts authenticating on api-server. (In case api-server 
> endpoint moves).
> As far as I understand we should have either all api-server keys synced 
> on api-servesr or pre-generate single api-server key.
> 
> What is the way for magnum to get over this issue?
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 
>>> 
>>> -- 
>>> Cheers & Best regards,
>>> Feilong Wang (王飞龙)
>>> --
>>> Senior Cloud Software Engineer
>>> Tel: +64-48032246
>>> Email: flw...@catalyst.net.nz 
>>> Catalyst IT Limited
>>> Level 6, Catalyst House, 150 Willis Street, Wellington
>>> -- 
>>> __
>>> OpenStack Development Mailing 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 
>> 
> 
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz 

Re: [openstack-dev] [magnum] K8S apiserver key sync

[Fei Long Wang]

Hi Remo,

I can't see obvious issue from the log you posted. You can pop up at
#openstack-containers IRC channel as for Magnum questions. Cheers.


On 21/06/18 08:56, Remo Mattei wrote:
> Hello guys, what will be the right channel to as a question about
> having K8 (magnum working with Tripleo)? 
>
> I have the following errors..
>
> http://pastebin.mattei.co/index.php/view/2d1156f1
>
> Any tips are appreciated. 
>
> Thanks 
> Remo 
>
>> On Jun 19, 2018, at 2:13 PM, Fei Long Wang > > wrote:
>>
>> Hi there,
>>
>> For people who maybe still interested in this issue. I have proposed
>> a patch, see https://review.openstack.org/576029 And I have verified
>> with Sonobuoy for both multi masters (3 master nodes) and single
>> master clusters, all worked. Any comments will be appreciated. Thanks.
>>
>>
>> On 21/05/18 01:22, Sergey Filatov wrote:
>>> Hi!
>>> I’d like to initiate a discussion about this bug: [1].
>>> To resolve this issue we need to generate a secret cert and pass it
>>> to master nodes. We also need to store it somewhere to support scaling.
>>> This issue is specific for kubernetes drivers. Currently in magnum
>>> we have a general cert manager which is the same for all the drivers.
>>>
>>> What do you think about moving cert_manager logic into a
>>> driver-specific area?
>>> Having this common cert_manager logic forces us to generate client
>>> cert with “admin” and “system:masters” subject & organisation names
>>> [2], 
>>> which is really something that we need only for kubernetes drivers.
>>>
>>> [1] https://bugs.launchpad.net/magnum/+bug/1766546
>>> [2] 
>>> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>>
>>>
>>> ..Sergey Filatov
>>>
>>>
>>>
 On 20 Apr 2018, at 20:57, Sergey Filatov >>> > wrote:

 Hello,

 I looked into k8s drivers for magnum I see that each api-server on
 master node generates it’s own service-account-key-file. This
 causes issues with service-accounts authenticating on api-server.
 (In case api-server endpoint moves).
 As far as I understand we should have either all api-server keys
 synced on api-servesr or pre-generate single api-server key.

 What is the way for magnum to get over this issue?
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> -- 
>> Cheers & Best regards,
>> Feilong Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> -- 
>> __
>> OpenStack Development Mailing 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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Tony Breeds]

On Wed, Jun 20, 2018 at 08:54:56PM +0900, Takashi Yamamoto wrote:
 
> do you have a plan to submit these changes on gerrit?

I didn't but I have now:

 * https://review.openstack.org/577028
 * https://review.openstack.org/577029

Feel free to edit/test as you like.

Yours Tony.


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

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

[Chris Friesen]

On 06/20/2018 10:00 AM, Sylvain Bauza wrote:


When we reviewed the spec, we agreed as a community to say that we should still
get race conditions once the series is implemented, but at least it helps 
operators.
Quoting :
"It would also be possible for another instance to steal NUMA resources from a
live migrated instance before the latter’s destination compute host has a chance
to claim them. Until NUMA resource providers are implemented [3]
 and allow for an essentially atomic
schedule+claim operation, scheduling and claiming will keep being done at
different times on different nodes. Thus, the potential for races will continue
to exist."
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#proposed-change


My understanding of that quote was that we were acknowledging the fact that when 
using the ResourceTracker there was an unavoidable race window between the time 
when the scheduler selected a compute node and when the resources were claimed 
on that compute node in check_can_live_migrate_destination().  And in this model 
no resources are actually *used* until they are claimed.


As I understand it, Artom is proposing to have a larger race window, essentially 
from when the scheduler selects a node until the resource audit runs on that node.


Chris

__
OpenStack Development Mailing 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] [qa]Canceling the today QA Office Hour

[Ghanshyam Mann]

Hi All,

Most of the QA members are in Open Source Summit Japan, so we will skip the 
today office hour. 

-gmann





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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Tung Doan]

Hi Doug,
I posted in wrong thread :) Sorry for that. The right one is
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131688.html

Vào Th 5, 21 thg 6, 2018 vào lúc 01:00 Doug Hellmann <
d...@doughellmann.com> đã viết:

> Excerpts from Tung Doan's message of 2018-06-21 00:35:38 +0200:
> >  I agree with Bobh. Considering both Heat Translator and Tosca Parser
> under
> > the management of Tacker could affect other projects. We have recently
> > announced OpenStack Apmec [1] (MEC Orchestration Service) which
> > consumed these two projects as well.
> > In case Heat PTL does not have enough bandwidth to take care of the
> release
> > of these two projects. I just wonder whether it is reasonable to release
> > them when having only the approval of their PTL.
> >
> > [1] https://github.com/openstack/apmec/tree/master/apmec
>
> According to
> https://governance.openstack.org/tc/reference/projects/heat.html the
> Heat PTL *is* the PTL for heat-translators. Any internal team structure
> that implies otherwise is just that, an internal team structure.
>
> I'm really unclear on what the problem is here. The PTL requested a
> release; it looked fine; I approved it; it was completed.
>
> The release team tries to facilitate releases happening as quickly
> as possible so we don't block work anyone else is trying to do.
> There was no apparent reason to wait for this one.  If the teams
> using heat-translator want to coordinate on when releases happen
> for some reason, then please deal with that before requesting the
> releases (and use a W-1 on the patch if you want us to hold off
> until you get approval).  The release team has said we do not want
> to have to keep up with separate liaisons for individual deliverables
> because it's too much to for us to track.
>
> In the mean time, releases are cheap and we can have as many of
> them as we want, so if there are additional features in the pipeline
> that will be ready to be released soon we can just do that when
> they merge.
>
> And if changes are going into heat-translator that might break
> consuming projects, we should deal with that the way we do in other
> libraries and set up cross-project gating to try to catch the
> problems ahead of time. (Maybe that testing is already in place?)
> We can also use the constraint system to block "bad" releases if
> they do happen. But it's generally better for us to be releasing
> libraries and tools as often as possible, so that any breaking
> changes come as part of a small set and so new features are available
> shortly after they are implemented.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Doug Hellmann]

Excerpts from Tung Doan's message of 2018-06-21 00:35:38 +0200:
>  I agree with Bobh. Considering both Heat Translator and Tosca Parser under
> the management of Tacker could affect other projects. We have recently
> announced OpenStack Apmec [1] (MEC Orchestration Service) which
> consumed these two projects as well.
> In case Heat PTL does not have enough bandwidth to take care of the release
> of these two projects. I just wonder whether it is reasonable to release
> them when having only the approval of their PTL.
> 
> [1] https://github.com/openstack/apmec/tree/master/apmec

According to
https://governance.openstack.org/tc/reference/projects/heat.html the
Heat PTL *is* the PTL for heat-translators. Any internal team structure
that implies otherwise is just that, an internal team structure.

I'm really unclear on what the problem is here. The PTL requested a
release; it looked fine; I approved it; it was completed.

The release team tries to facilitate releases happening as quickly
as possible so we don't block work anyone else is trying to do.
There was no apparent reason to wait for this one.  If the teams
using heat-translator want to coordinate on when releases happen
for some reason, then please deal with that before requesting the
releases (and use a W-1 on the patch if you want us to hold off
until you get approval).  The release team has said we do not want
to have to keep up with separate liaisons for individual deliverables
because it's too much to for us to track.

In the mean time, releases are cheap and we can have as many of
them as we want, so if there are additional features in the pipeline
that will be ready to be released soon we can just do that when
they merge.

And if changes are going into heat-translator that might break
consuming projects, we should deal with that the way we do in other
libraries and set up cross-project gating to try to catch the
problems ahead of time. (Maybe that testing is already in place?)
We can also use the constraint system to block "bad" releases if
they do happen. But it's generally better for us to be releasing
libraries and tools as often as possible, so that any breaking
changes come as part of a small set and so new features are available
shortly after they are implemented.

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] [heat] Need new release of heat-translator library

[Tung Doan]

 I agree with Bobh. Considering both Heat Translator and Tosca Parser under
the management of Tacker could affect other projects. We have recently
announced OpenStack Apmec [1] (MEC Orchestration Service) which
consumed these two projects as well.
In case Heat PTL does not have enough bandwidth to take care of the release
of these two projects. I just wonder whether it is reasonable to release
them when having only the approval of their PTL.

[1] https://github.com/openstack/apmec/tree/master/apmec
__
OpenStack Development Mailing 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] [barbican] [tc] key store in base services

[Adam Harwell]

Looks like I missed this so I'm late to the party, but:

Ade is technically correct, Octavia doesn't explicitly depend on Barbican,
as we do support castellan generically.

*HOWEVER*: we don't just store and retrieve our own secrets -- we rely on
loading up user created secrets. This means that for Octavia to work, even
if we use castellan, we still need some way for users to interact with the
secret store via an API, and what that means in openstack in still
Barbican. So I would still say that Barbican is a dependency for us
logistically, if not technically.

For example, internally at GoDaddy we were investigating deploying Vault
with a custom user-facing API/UI for allowing users to store secrets that
could be consumed by Octavia with castellan (don't get me started on how
dumb that is, but it's what we were investigating).
The correct way to do this in an openstack environment is the openstack
secret store API, which is Barbican. So, while I am personally dealing with
an example of very painfully avoiding Barbican (which may have been a
non-issue if Barbican were a base service), I have a tough time reconciling
not including Barbican itself as a requirement.

   --Adam (rm_work)

On Wed, Jun 20, 2018, 11:37 Jeremy Stanley  wrote:

> On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
> [...]
> > Seeing no further objections, I give you
> > https://review.openstack.org/572656 for the next step.
>
> That change merged just a few minutes ago, and
>
> https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
> now includes:
>
> A Castellan-compatible key store
>
> OpenStack components may keep secrets in a key store, using
> Oslo’s Castellan library as an indirection layer. While
> OpenStack provides a Castellan-compatible key store service,
> Barbican, other key store backends are also available for
> Castellan. Note that in the context of the base services set
> Castellan is intended only to provide an interface for services
> to interact with a key store, and it should not be treated as a
> means to proxy API calls from users to that key store. In order
> to reduce unnecessary exposure risks, any user interaction with
> secret material should be left to a dedicated API instead
> (preferably as provided by Barbican).
>
> Thanks to everyone who helped brainstorming/polishing, and here's
> looking forward to a ubiquity of default security features and
> functionality in future OpenStack releases!
> --
> 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] [PTG] Updates!

[Erlon Cruz]

+1 on the game night! Reserve a room only for that :)

Em qua, 20 de jun de 2018 às 15:25, Kendall Nelson 
escreveu:

> Hello Everyone!
>
> Wanted to give you some updates on PTG4 planning. We have finalized the
> list of SIGs/ Groups/WGs/Teams that are attending. They are as follows:
>
>-
>
>Airship
>-
>
>API SIG
>-
>
>Barbican/Security SIG
>-
>
>Blazar
>-
>
>Chef OpenStack
>-
>
>Cinder
>-
>
>Cyborg
>-
>
>Designate
>-
>
>Documentation
>-
>
>Edge Computing Group
>-
>
>First Contact SIG
>-
>
>Glance
>-
>
>Heat
>-
>
>Horizon
>-
>
>Infrastructure
>-
>
>Interop WG
>
>
>-
>
>Ironic
>-
>
>Kata
>-
>
>Keystone
>-
>
>Kolla
>-
>
>LOCI
>-
>
>Manila
>-
>
>Masakari
>-
>
>Mistral
>-
>
>Monasca
>-
>
>Neutron
>-
>
>Nova
>-
>
>Octavia
>-
>
>OpenStack Ansible
>-
>
>OpenStack Charms
>-
>
>OpenStack Helm
>-
>
>OpenStackClient
>
>
>
>-
>
>Operator Meetup
>Puppet OpenStack
>-
>
>QA
>-
>
>Oslo
>-
>
>Public Cloud WG
>-
>
>Release Management
>-
>
>Requirements
>-
>
>Sahara
>-
>
>Scientific SIG
>-
>
>Self-Healing SIG
>-
>
>SIG- K8s
>-
>
>StarlingX
>-
>
>Swift
>-
>
>TC
>-
>
>TripleO
>-
>
>Upgrades SIG
>-
>
>Watcher
>-
>
>Zuul (pending confirmation)
>
> Thierry and I are working on placing them into a strawman schedule to
> reduce conflicts between related or overlapping groups. We should have more
> on what that will look like and a draft for you all to review in the next
> few weeks.
>
> We also wanted to remind you all of the Travel Support Program. We are
> again doing a two phase selection. The first deadline is approaching: July
> 1st. At this point we have less than a dozen applicants so if you need it
> or even think you need it, I urge you to apply here[1].
>
> Also! Reminder that we have a finite number of rooms in the hotel block so
> please book early to make sure you get the discounted rate before they run
> out. You can book those rooms here[2] (pardon the ugly URL).
>
> Can't wait to see you all there!
>
> -Kendall Nelson (diablo_rojo)
>
> P.S. Gonna try to do a game night again since you all seemed to enjoy it
> so much last time :)
>
> [1]
> https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018
>
> [2]
> https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18&app=resvlink&stop_mobi=yes
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] K8S apiserver key sync

[Remo Mattei]

Hello guys, what will be the right channel to as a question about having K8 
(magnum working with Tripleo)? 

I have the following errors..

http://pastebin.mattei.co/index.php/view/2d1156f1

Any tips are appreciated. 

Thanks 
Remo 

> On Jun 19, 2018, at 2:13 PM, Fei Long Wang  wrote:
> 
> Hi there,
> 
> For people who maybe still interested in this issue. I have proposed a patch, 
> see https://review.openstack.org/576029  
> And I have verified with Sonobuoy for both multi masters (3 master nodes) and 
> single master clusters, all worked. Any comments will be appreciated. Thanks.
> 
> 
> On 21/05/18 01:22, Sergey Filatov wrote:
>> Hi!
>> I’d like to initiate a discussion about this bug: [1].
>> To resolve this issue we need to generate a secret cert and pass it to 
>> master nodes. We also need to store it somewhere to support scaling.
>> This issue is specific for kubernetes drivers. Currently in magnum we have a 
>> general cert manager which is the same for all the drivers.
>> 
>> What do you think about moving cert_manager logic into a driver-specific 
>> area?
>> Having this common cert_manager logic forces us to generate client cert with 
>> “admin” and “system:masters” subject & organisation names [2], 
>> which is really something that we need only for kubernetes drivers.
>> 
>> [1] https://bugs.launchpad.net/magnum/+bug/1766546 
>> 
>> [2] 
>> https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>  
>> 
>> 
>> 
>> ..Sergey Filatov
>> 
>> 
>> 
>>> On 20 Apr 2018, at 20:57, Sergey Filatov >> > wrote:
>>> 
>>> Hello,
>>> 
>>> I looked into k8s drivers for magnum I see that each api-server on master 
>>> node generates it’s own service-account-key-file. This causes issues with 
>>> service-accounts authenticating on api-server. (In case api-server endpoint 
>>> moves).
>>> As far as I understand we should have either all api-server keys synced on 
>>> api-servesr or pre-generate single api-server key.
>>> 
>>> What is the way for magnum to get over this issue?
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz 
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
> __
> OpenStack Development Mailing 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] [tricircle] Zuul v3 integration status

[Boden Russell]

Thanks for that.

I'm a bit concerned about how to proceed with dependencies in the
meantime, it's not realistic to hold all such patches until S.

Perhaps we can continue this discussion in [1]?

[1] https://bugs.launchpad.net/tricircle/+bug/1776922



On 6/19/18 7:38 PM, linghucongsong wrote:
> we will plan this as a bp, but maybe can not finished it
>
> in the R release, we promise must be finish it in the next openstack
> version.
>


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

[openstack-dev] [PTG] Updates!

[Kendall Nelson]

Hello Everyone!

Wanted to give you some updates on PTG4 planning. We have finalized the
list of SIGs/ Groups/WGs/Teams that are attending. They are as follows:

   -

   Airship
   -

   API SIG
   -

   Barbican/Security SIG
   -

   Blazar
   -

   Chef OpenStack
   -

   Cinder
   -

   Cyborg
   -

   Designate
   -

   Documentation
   -

   Edge Computing Group
   -

   First Contact SIG
   -

   Glance
   -

   Heat
   -

   Horizon
   -

   Infrastructure
   -

   Interop WG


   -

   Ironic
   -

   Kata
   -

   Keystone
   -

   Kolla
   -

   LOCI
   -

   Manila
   -

   Masakari
   -

   Mistral
   -

   Monasca
   -

   Neutron
   -

   Nova
   -

   Octavia
   -

   OpenStack Ansible
   -

   OpenStack Charms
   -

   OpenStack Helm
   -

   OpenStackClient



   -

   Operator Meetup
   Puppet OpenStack
   -

   QA
   -

   Oslo
   -

   Public Cloud WG
   -

   Release Management
   -

   Requirements
   -

   Sahara
   -

   Scientific SIG
   -

   Self-Healing SIG
   -

   SIG- K8s
   -

   StarlingX
   -

   Swift
   -

   TC
   -

   TripleO
   -

   Upgrades SIG
   -

   Watcher
   -

   Zuul (pending confirmation)

Thierry and I are working on placing them into a strawman schedule to
reduce conflicts between related or overlapping groups. We should have more
on what that will look like and a draft for you all to review in the next
few weeks.

We also wanted to remind you all of the Travel Support Program. We are
again doing a two phase selection. The first deadline is approaching: July
1st. At this point we have less than a dozen applicants so if you need it
or even think you need it, I urge you to apply here[1].

Also! Reminder that we have a finite number of rooms in the hotel block so
please book early to make sure you get the discounted rate before they run
out. You can book those rooms here[2] (pardon the ugly URL).

Can't wait to see you all there!

-Kendall Nelson (diablo_rojo)

P.S. Gonna try to do a game night again since you all seemed to enjoy it so
much last time :)

[1]
https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018

[2]
https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18&app=resvlink&stop_mobi=yes
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][tacker][heat-translator] deliverables of heat-translator library

[Zane Bitter]

On 20/06/18 12:38, HADDLETON, Robert W (Bob) wrote:
The Tacker team is dependent on tosca-parser and heat-translator but 
they are not the only consumers.


I agree the structure is odd, and Sahdev has more of the history than I do.


History lesson:

At the time (2014) OpenStack was organised into 'Programs', that could 
contain multiple projects. It seemed to make sense to bring 
heat-translator into the Orchestration Program. It had its own PTL 
(Sahdev) and its own core team (although Heat cores from the time still 
have +2 rights on it), and operated essentially independently.


There were discussions about eventually combining it with heatclient or 
even Heat itself once it was mature, but that hasn't come up in quite a 
while and there are no resources available to work on it now anyway.


When we scrapped 'Programs', it just got converted to a deliverable of 
the Heat project, instead of its own separate project. In practice, 
however, nothing actually changed and it kept its own (technically 
unofficial, I think) PTL and operated independently. That's the source 
of the weirdness.


Since then the number of core reviewers has dropped considerably and 
people have difficulty getting patches in and releases made. Most of the 
people bugging me about that have been from Tacker, hence the suggestion 
to move the project over there: since they are the biggest users they 
could help maintain it.


In the past the requests from the Tacker team have come to Sahdev/me and 
we have created
releases as needed.  For some reason this time a request went to the 
Heat ML, in addition to

a separate request to me directly.

I'm open to changes in the structure but I don't think Tacker is the 
right place to put the

deliverables.


What would you suggest?

cheers,
Zane.


Bob

On 6/20/2018 11:31 AM, Rico Lin wrote:
To continue the discussion in 
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131681.html


Add Tacker and heat-translator to make sure all aware this discussion

On Thu, Jun 21, 2018 at 12:28 AM Doug Hellmann > wrote:


Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> On 20/06/18 11:40, Rico Lin wrote:
> > I send a release patch now
https://review.openstack.org/#/c/576895/
> > Also, add Bob Haddleton to this ML who is considering as PTL for
> > heat-translator team
>
> Is it time to consider moving the heat-translator and
tosca-parser repos
> from being deliverables of Heat to deliverables of Tacker? The
current
> weird structure dates from the days of the experiment with
OpenStack
> 'Programs' (vs. Projects).
>
> Heat cores don't really have time to be engaging with
heat-translator,
> and Tacker is clearly the major user and the thing that keeps
getting
> blocked on needing patches merged and releases made.

It sounds like it. I had no idea there was any reason to look to
anyone
other than the Heat PTL or liaison for approval of that release. A WIP
on the patch would have been OK, too, but if the Tacker team is really
the one responsible we should update the repo governance.

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

-- 
May The Force of OpenStack Be With You,

*/Rico Lin
/*irc: ricolin









__
OpenStack Development Mailing 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] [osc][python-openstackclient] osc-included image signing

[Dean Troyer]

[Apologies for the relay in responding...]

On Fri, Jun 1, 2018 at 8:13 AM, Josephine Seifert
 wrote:
> our team has implemented a prototype for an osc-included image signing. We
> would like to propose a spec or something like this, but haven't found where
> to start at. So here is a brief concept of what we want to contribute:
>
> https://etherpad.openstack.org/p/osc-included_image_signing
>
> Please advise us which steps to take next!

This looks like a great addition, thanks!

I am not familiar with cursive, it is not a current dependency of OSC.
Also, does this depend on barbican client at all?  That is not a
direct dependency of OSC,  If it does have a hard dependency on
barbican client, we would need to handle the errors if it is not
installed.

We do not have a formal spec process in OSC, that etherpad[0[ and
story [1] look good.  Tasks 19810 and 19812 could likely be done in
the same review depending on how things are structured.

Go ahead and post WIP reviews and we can look at it further.  To merge
I'll want all of the usual tests, docs, release notes, etc but don't
wait if that is not all done up front.

dt


[0] https://etherpad.openstack.org/p/osc-included_image_signing
[1] https://storyboard.openstack.org/?#!/story/2002128

-- 

Dean Troyer
dtro...@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

Re: [openstack-dev] [openstackclient][openstacksdk] why does openstackclient rely on openstacksdk for get a network client

[Monty Taylor]

On 06/20/2018 10:23 AM, Dean Troyer wrote:

On Tue, Jun 19, 2018 at 9:42 PM, zijian1...@163.com  wrote:

Thks for replying, just want to confirm, you mentioned "We have intended to
migrate everything to use
OpenStackSDK", the current use of python-*client is:
1. OSC
2. all services that need to interact with other services (e.g.:  nova
libraries: self.volume_api = volume_api or cinder.API())
Do you mean that both of the above will be migrated to use the OpenStack
SDK?


I am only directly speaking for OSC.  Initially we did not think that
services using the SDK would be feasible, Monty has taken it to a
place where that should now be a possibility.  I am willing to find
out that doing so is a good idea. :)


Yes, I think this is a good idea to explore - but I also think we should 
be conservative with the effort. There are things we'll need to learn 
about and improve.


We're VERY close to time for making the push to get OSC converted (we 
need to finish one more patch for version discovery / microversion 
support first - and I'd really like to get an answer for the 
Resource/munch/shade interaction in - but that's honestly realistically 
like 2 or maybe 3 patches, even though they will be 2 or 3 complex patches.


I started working a bit on osc-lib patches - I'll try to get those 
pushed up soon.


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] [nova] [placement] placement update 18-24

[Matt Riedemann]

Thanks for this, a few things inline.

On 6/15/2018 10:04 AM, Chris Dent wrote:


The flip side of this is that it highlights that we have a growing
documentation debt with the many features provided by placement and
how to make best use of them in nova (and other services that might
like to use placement). Before the end of the cycle we will need to
be sure that we set aside a considerable chunk of time to address
this gap.


I'm glad you mentioned this so I didn't have to. :) The two things off 
the top of my head that are going to be important for docs are:


1. How to deploy / model shared disk. Seems fairly straight-forward, and 
we could even maybe create a multi-node ceph job that does this - 
wouldn't that be awesome?!?!


2. Adding the placement database stuff to the install guide and the 
placement upgrade notes. I assume that for fresh installs, we want 
people using the placement database configuration so they don't have to 
move later during an upgrade, so that seems like a no-brainer. The 
upgrade docs for placement are per-release and should have a mention of 
the placement database and any notes / pointers (the spec?) on migration 
options. What we heard at the summit, for the most part, was 10 minutes 
of down time in the API for a DB copy and re-config was OK for most, and 
others that need zero downtime have ways of doing that as well. We don't 
need a definitive guide, just high level wording on options.




There is now a [heal allocations
CLI](https://review.openstack.org/#/c/565886/) which is designed to
help people migrate away from the CachingScheduler (which doesn't
use placement).


Not only that, but we can use it to heal missing/sentinel consumers from 
the "consumer generations" blueprint. I've started something for that here:


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



Nova host aggregates are now magically mirrored as placement
aggregates and, amongst other things, this is used to honor the
[availability_zone hint via
placement](https://review.openstack.org/#/c/546282/).


The aggregates mirror blueprint is not done until the 'nova-manage 
placement sync_aggregates' command is in place, which is started here:


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



# Extraction



All of the functional changes for the placement DB stuff are merged or 
approved, I think there are just some cleanup follow-ups and docs needed 
still, but otherwise that's done I think and could probably be removed 
from the runway slot it's in?




* 
   Convert driver supported capabilities to compute node provider
   traits


I (finally) got around to rebasing this yesterday. There are a few TODOs 
left but it shouldn't be too bad, hopefully I can close that out when I 
get back next week.


--

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

Re: [openstack-dev] [heat][tacker][heat-translator] deliverables of heat-translator library

[HADDLETON, Robert W (Bob)]

The Tacker team is dependent on tosca-parser and heat-translator but 
they are not the only consumers.


I agree the structure is odd, and Sahdev has more of the history than I do.

In the past the requests from the Tacker team have come to Sahdev/me and 
we have created
releases as needed.  For some reason this time a request went to the 
Heat ML, in addition to

a separate request to me directly.

I'm open to changes in the structure but I don't think Tacker is the 
right place to put the

deliverables.

Bob

On 6/20/2018 11:31 AM, Rico Lin wrote:
To continue the discussion in 
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131681.html


Add Tacker and heat-translator to make sure all aware this discussion

On Thu, Jun 21, 2018 at 12:28 AM Doug Hellmann > wrote:


Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> On 20/06/18 11:40, Rico Lin wrote:
> > I send a release patch now
https://review.openstack.org/#/c/576895/
> > Also, add Bob Haddleton to this ML who is considering as PTL for
> > heat-translator team
>
> Is it time to consider moving the heat-translator and
tosca-parser repos
> from being deliverables of Heat to deliverables of Tacker? The
current
> weird structure dates from the days of the experiment with
OpenStack
> 'Programs' (vs. Projects).
>
> Heat cores don't really have time to be engaging with
heat-translator,
> and Tacker is clearly the major user and the thing that keeps
getting
> blocked on needing patches merged and releases made.

It sounds like it. I had no idea there was any reason to look to
anyone
other than the Heat PTL or liaison for approval of that release. A WIP
on the patch would have been OK, too, but if the Tacker team is really
the one responsible we should update the repo governance.

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

-- 
May The Force of OpenStack Be With You,

*/Rico Lin
/*irc: ricolin






<>__
OpenStack Development Mailing 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] [barbican] [tc] key store in base services

[Jeremy Stanley]

On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
[...]
> Seeing no further objections, I give you
> https://review.openstack.org/572656 for the next step.

That change merged just a few minutes ago, and
https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
now includes:

A Castellan-compatible key store

OpenStack components may keep secrets in a key store, using
Oslo’s Castellan library as an indirection layer. While
OpenStack provides a Castellan-compatible key store service,
Barbican, other key store backends are also available for
Castellan. Note that in the context of the base services set
Castellan is intended only to provide an interface for services
to interact with a key store, and it should not be treated as a
means to proxy API calls from users to that key store. In order
to reduce unnecessary exposure risks, any user interaction with
secret material should be left to a dedicated API instead
(preferably as provided by Barbican).

Thanks to everyone who helped brainstorming/polishing, and here's
looking forward to a ubiquity of default security features and
functionality in future OpenStack releases!
-- 
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] [heat][tacker][heat-translator] deliverables of heat-translator library

[Rico Lin]

To continue the discussion in
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131681.html

Add Tacker and heat-translator to make sure all aware this discussion

On Thu, Jun 21, 2018 at 12:28 AM Doug Hellmann 
wrote:

> Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> > On 20/06/18 11:40, Rico Lin wrote:
> > > I send a release patch now https://review.openstack.org/#/c/576895/
> > > Also, add Bob Haddleton to this ML who is considering as PTL for
> > > heat-translator team
> >
> > Is it time to consider moving the heat-translator and tosca-parser repos
> > from being deliverables of Heat to deliverables of Tacker? The current
> > weird structure dates from the days of the experiment with OpenStack
> > 'Programs' (vs. Projects).
> >
> > Heat cores don't really have time to be engaging with heat-translator,
> > and Tacker is clearly the major user and the thing that keeps getting
> > blocked on needing patches merged and releases made.
>
> It sounds like it. I had no idea there was any reason to look to anyone
> other than the Heat PTL or liaison for approval of that release. A WIP
> on the patch would have been OK, too, but if the Tacker team is really
> the one responsible we should update the repo governance.
>
> 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
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> On 20/06/18 11:40, Rico Lin wrote:
> > I send a release patch now https://review.openstack.org/#/c/576895/
> > Also, add Bob Haddleton to this ML who is considering as PTL for 
> > heat-translator team
> 
> Is it time to consider moving the heat-translator and tosca-parser repos 
> from being deliverables of Heat to deliverables of Tacker? The current 
> weird structure dates from the days of the experiment with OpenStack 
> 'Programs' (vs. Projects).
> 
> Heat cores don't really have time to be engaging with heat-translator, 
> and Tacker is clearly the major user and the thing that keeps getting 
> blocked on needing patches merged and releases made.

It sounds like it. I had no idea there was any reason to look to anyone
other than the Heat PTL or liaison for approval of that release. A WIP
on the patch would have been OK, too, but if the Tacker team is really
the one responsible we should update the repo governance.

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] [puppet-openstack][announce][debian] puppet-openstack now has full Debian support

[Tobias Urdin]

Great work Thomas!

We also got a good overview on some challenges and issues regarding
moving to python3 support for the Puppet modules in the future.
But we can easily state that the main work will lay with making sure
there is python3 supported distro packages.

Which you with Debian python3 support has also paved the way with.
Looking forward to all python3 release in the future, all aboard the train!

Best regards
Tobias

On 06/20/2018 04:25 PM, Thomas Goirand wrote:
> Dear Stackers,
>
> I am glad/overjoyed/jazzed to announce the global availability of
> puppet-openstack for Debian. Indeed, a few minutes ago, the CI turned
> all green for Debian:
>
> https://review.openstack.org/#/c/576416
>
> (note: the red one for CentOS is to be ignored, it looks like
> non-deterministic error)
>
> This is after 3 months of hard work, and more than 50 patches, sometimes
> on upstream code base (for example in Cinder, Sahara, and Neutron),
> often because of Python 3 or uwsgi/mod_wsgi related problems. Some of
> these patches aren't merged yet upstream, but are included in the Debian
> packages already. Also note that Debian fully supports SSL and ipv6
> endpoints.
>
> I'd like here to publicly thanks all of the puppet-openstack core
> reviewers for their help and enthusiasm. A big thanks to mnaser,
> tobasco, EmilienM and mwhahaha. Guys, you've been really awesome and
> helpful with me. Also a big thanks to these upstream helping with fixing
> these bits as explained above, and especially annp for fixing the
> neutron-rpc-server related problems, with the patch also pending reviews
> at: https://review.openstack.org/#/c/555608/
>
> All of these puppet modules are available directly in Debian in a
> packaged form. To get them, simply do:
>
> apt-get install openstack-puppet-modules
>
> in Debian Sid, or using the Debian backports repository at:
>
> http://stretch-queens.infomaniak.ch/debian
>
> Still to fix, is neutron-fwaas, which seems to not like either Python 3
> or using neutron-api over uwsgi (I'm not sure which of these yet).
> Upstream neutron developers are currently investigating this. For this
> reason, neutron firewall extension is currently disabled for the
> l3-agent, but will be reactivated as soon as a proper fix is found.
>
> Also, Ceph in Debian is currently a way behind (so we have to use
> upstream Debian repository for Stretch), as it lacks a proper Python 3
> support, and still no Luminous release uploaded to Sid. I intend to
> attempt to fix this, to get a chance to get this in time for Buster.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Zane Bitter]

On 20/06/18 11:40, Rico Lin wrote:

I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for 
heat-translator team


Is it time to consider moving the heat-translator and tosca-parser repos 
from being deliverables of Heat to deliverables of Tacker? The current 
weird structure dates from the days of the experiment with OpenStack 
'Programs' (vs. Projects).


Heat cores don't really have time to be engaging with heat-translator, 
and Tacker is clearly the major user and the thing that keeps getting 
blocked on needing patches merged and releases made.


Ben Nemec mailto:openst...@nemebean.com>> 於 
2018年6月20日 週三 下午10:26寫道：




On 06/20/2018 02:58 AM, Patil, Tushar wrote:
 > Hi,
 >
 > Few weeks back, we had proposed a patch [1] to add support for
translation of placement policies and that patch got merged.
 >
 > This feature will be consumed by tacker specs [2] which we are
planning to implement in Rocky release and it's implementation is
uploaded in patch [3]. Presently, the tests are failing on patch [3]
becoz it requires newer version of heat-translator library.
 >
 > Could you please release a new version of heat-translator library
so that we can complete specs[2] in Rocky timeframe.

Note that you can propose a release to the releases repo[1] and then
you
just need the PTL or release liaison to sign off on it.

1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

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

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



--
May The Force of OpenStack Be With You,
*/Rico Lin
/*irc: ricolin




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




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

[openstack-dev] [magnum] New temporary meeting on Thursdays 1700UTC

[Spyros Trigazis]

Hello list,

We are going to have a second weekly meeting for magnum for 3 weeks
as a test to reach out to contributors in the Americas.

You can join us tomorrow (or today for some?) at 1700UTC in
#openstack-containers .

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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[HADDLETON, Robert W (Bob)]

This request had come to me from someone else in the Tacker team and I 
was working on including a couple of other patchsets in the release, but 
this is fine.


Please tag these requests as [heat-translator] in the subject so they 
get flagged to me and I'm happy to work them.


Bob

On 6/20/2018 10:40 AM, Rico Lin wrote:

I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for 
heat-translator team


Ben Nemec mailto:openst...@nemebean.com>> 於 
2018年6月20日 週三 下午10:26寫道：




On 06/20/2018 02:58 AM, Patil, Tushar wrote:
> Hi,
>
> Few weeks back, we had proposed a patch [1] to add support for
translation of placement policies and that patch got merged.
>
> This feature will be consumed by tacker specs [2] which we are
planning to implement in Rocky release and it's implementation is
uploaded in patch [3]. Presently, the tests are failing on patch
[3] becoz it requires newer version of heat-translator library.
>
> Could you please release a new version of heat-translator
library so that we can complete specs[2] in Rocky timeframe.

Note that you can propose a release to the releases repo[1] and
then you
just need the PTL or release liaison to sign off on it.

1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

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

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



--
May The Force of OpenStack Be With You,
*/Rico Lin
/*irc: ricolin





<>__
OpenStack Development Mailing 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] NUMA-aware live migration: easy but incomplete vs complete but hard

[Sylvain Bauza]

On Tue, Jun 19, 2018 at 9:59 PM, Artom Lifshitz  wrote:

> > Adding
> > claims support later on wouldn't change any on-the-wire messaging, it
> would
> > just make things work more robustly.
>
> I'm not even sure about that. Assuming [1] has at least the right
> idea, it looks like it's an either-or kind of thing: either we use
> resource tracker claims and get the new instance NUMA topology that
> way, or do what was in the spec and have the dest send it to the
> source.
>
> That being said, I still think I'm still in favor of choosing the
> "easy" way out. For instance, [2] should fail because we can't access
> the api db from the compute node. So unless there's a simpler way,
> using RT claims would involve changing the RPC to add parameters to
> check_can_live_migration_destination, which, while not necessarily
> bad, seems like useless complexity for a thing we know will get ripped
> out.
>
> When we reviewed the spec, we agreed as a community to say that we should
still get race conditions once the series is implemented, but at least it
helps operators.
Quoting :
"It would also be possible for another instance to steal NUMA resources
from a live migrated instance before the latter’s destination compute host
has a chance to claim them. Until NUMA resource providers are implemented
[3]  and allow for an essentially
atomic schedule+claim operation, scheduling and claiming will keep being
done at different times on different nodes. Thus, the potential for races
will continue to exist."
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#proposed-change

So, my own opinion is that yes, the "easy" way out is better than no way.
>From what I undertand (and let's be honest I hadn't time to look at your
code yet), your series don't diverge from the proposed implementation so I
don't see a problem here. If, for some reasons, you need to write an
alternative, just tell us why (and ideally write a spec amendment patch so
the spec is consistent with the series).

-Sylvain




[1] https://review.openstack.org/#/c/576222/
> [2] https://review.openstack.org/#/c/576222/3/nova/compute/manager.py@5897
>
> __
> OpenStack Development Mailing 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][osc][cliff][tacker] New release of cmd2 break cliff and tacker client

[Doug Hellmann]

Excerpts from super user's message of 2018-06-20 15:49:25 +0900:
> Hi everyone,
> 
> New release of cmd2 0.9.0 seems to break cliff and python-tackerclient.
> 
> The cmd2 library changed the way it handles parsing input commands. It now
> uses a different library, which means the values passed to the commands are
> no longer PyParsing objects and are instead Statement objects. These
> objects do not have a “parsed” property, so the receiving code needs to
> work with them differently.
> 
> The patch https://review.openstack.org/571524 tries to fix this in the
> places within cliff where it was failing in interactive mode.
> 
> Please consider reviewing this patch and have a new release for cliff so
> that the python-tackerclient pass the py35 tests.
> 
> Thank you,
> Nguyen Hai

That patch is now merged and I have requested a release of cliff
(https://review.openstack.org/576897).

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] [all] Non-OpenStack projects under the Foundation umbrella

[Amy Marrich]

Nice write up, thanks Zane!

Amy (spotz)

On Wed, Jun 20, 2018 at 10:33 AM, Zane Bitter  wrote:

> You may or may not be aware that the Foundation is in the process of
> expanding its mission to support projects other than OpenStack. It's a
> confusing topic and it's hard to find information about it all in one
> place, so I collected everything I was able to piece together during the
> Summit into a blog post that I hope will help to clarify the current status:
>
> https://www.zerobanana.com/archive/2018/06/14#osf-expansion
>
> cheers,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Rico Lin]

I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for
heat-translator team

Ben Nemec  於 2018年6月20日 週三 下午10:26寫道：

>
>
> On 06/20/2018 02:58 AM, Patil, Tushar wrote:
> > Hi,
> >
> > Few weeks back, we had proposed a patch [1] to add support for
> translation of placement policies and that patch got merged.
> >
> > This feature will be consumed by tacker specs [2] which we are planning
> to implement in Rocky release and it's implementation is uploaded in patch
> [3]. Presently, the tests are failing on patch [3] becoz it requires newer
> version of heat-translator library.
> >
> > Could you please release a new version of heat-translator library so
> that we can complete specs[2] in Rocky timeframe.
>
> Note that you can propose a release to the releases repo[1] and then you
> just need the PTL or release liaison to sign off on it.
>
> 1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst
>
> -Ben
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

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

[openstack-dev] [python3] building tools for the transition

[Doug Hellmann]

I want to thank Nguyễn Trí Hải, Ma Lei, and Huang Zhiping for
agreeing to be a part of the goal champion team for the python3
goal for Stein.

The next step for us is to build some tools to make the process a
little easier.

One of the aspects of this goal that makes it difficult is that we
need to change so many repositories. There are more than 480
repositories associated with official project teams. I do not think
we want to edit their zuul configurations by hand. :-)

It would be ideal if we had a script that could read the
openstack-infra/project-config/zuul.d/projects.yaml file to find
the project settings for a repository and copy those settings into
the right settings file within the repository. We could then review
the patch locally before proposing the change to gerrit.  A second
script to remove the settings from the project-config file, and
then submit that second change as a patch that has a Depends-On
listed for the first patch would also be useful.

Another aspect that makes it difficult is that zuul is very flexible
with how it reads its configuration files. The configuration can
be in .zuul.yaml, zuul.yaml, .zuul.d/*.yaml, or zuul.d/*.yaml.
Projects have not been consistent with the way they have named their
files, and that will make writing a script to automate editing them
more difficult. For example, I found automaton/.zuul.yaml,
rally/zuul.yaml, oslo.config/.zuul.d, and python-ironicclient/zuul.d.

When I was working on adding the lower-constraints jobs, I created some
tools in https://github.com/dhellmann/openstack-requirements-stop-sync
to help create the patches, and we may be able to reuse some of that
code to make similar changes for this goal.
https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/make_patches.sh
is the script that makes the patches, and
https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/add_job.py
is the python script that edits the YAML file.

The task for this goal is a little more complicated, since we are
not just adding 1 template to the existing project settings.  We
may have to add several templates and jobs to the existing settings,
merging the two sets together, and removing branch specifiers at
the same time. And we may need to do that in several branches.

Would a couple of you have time to work on the script to prepare
the patches? We can work in the openstack/goal-tools repository so
that we can collaborate on the code in an official OpenStack
repository (instead of using my GitHub project).

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] [all] Non-OpenStack projects under the Foundation umbrella

[Zane Bitter]

You may or may not be aware that the Foundation is in the process of 
expanding its mission to support projects other than OpenStack. It's a 
confusing topic and it's hard to find information about it all in one 
place, so I collected everything I was able to piece together during the 
Summit into a blog post that I hope will help to clarify the current status:


https://www.zerobanana.com/archive/2018/06/14#osf-expansion

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] [openstackclient][openstacksdk] why does openstackclient rely on openstacksdk for get a network client

[Dean Troyer]

On Tue, Jun 19, 2018 at 9:42 PM, zijian1...@163.com  wrote:
> Thks for replying, just want to confirm, you mentioned "We have intended to
> migrate everything to use
> OpenStackSDK", the current use of python-*client is:
> 1. OSC
> 2. all services that need to interact with other services (e.g.:  nova
> libraries: self.volume_api = volume_api or cinder.API())
> Do you mean that both of the above will be migrated to use the OpenStack
> SDK?

I am only directly speaking for OSC.  Initially we did not think that
services using the SDK would be feasible, Monty has taken it to a
place where that should now be a possibility.  I am willing to find
out that doing so is a good idea. :)

dt

-- 

Dean Troyer
dtro...@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

Re: [openstack-dev] [puppet-openstack][announce][debian] repository address (was: puppet-openstack now has full Debian support)

[Thomas Goirand]

On 06/20/2018 04:23 PM, Thomas Goirand wrote:
> or using the Debian backports repository at:
> 
> http://stretch-queens.infomaniak.ch/debian

I really meant:

deb http://stretch-queens.debian.net/debian \
strech-queens-backports main
deb http://stretch-queens.debian.net/debian \
strech-queens-backports-nochange main

which is the official URL for the 2 Stretch backports repositories.
Please use that address, always, as we may point it somewhere in the
future at some point (maybe in Infomaniak global mirror).

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Julien Danjou]

On Wed, Jun 20 2018, Bedyk, Witold wrote:

Hi Witek,

It's not a transparency issue. It's a manpower issue. We are only 2
developers active on Ceilometer: me and Mehdi. Neither me nor Mehdi
wants to maintain Monasca stuff; meaning, we don't want to spend time
reviewing patches, having bug opened, or whatever. There's no interest
for us in that.

THe Prometheus publisher you mention has been written by Mehdi and we've
approved it because it fits the roadmap of the Ceilometer developers
that we are — and, again we're just two.

We have other projects — such as Panko — that provide Ceilometer
publishers and their code is in Panko, not in Ceilometer. It's totally
possible and sane.

Now, if you really, really, care that much about Ceilometer and its
integration with Monasca, and if you have an amazing roadmap that'll
make Ceilometer better and awesome, please, do start with that.

Right now it just looks like more work for us with no gain. :(

> could you please add some transparency to the decision process on which
> publishers are acceptable and which not? Just two months ago you have added 
> new
> Prometheus publisher. That's around the same time when our code was submitted
> to review.
>
> We have delivered tested code and offer its maintenance. The code is
> self-contained and does not touch Ceilometer core. If it's broken, just 
> Monasca
> interface won't work.
>
> Please reconsider it again.
>
> Greetings
> Witek
>
>
>> -Original Message-
>> From: Julien Danjou 
>> Sent: Mittwoch, 20. Juni 2018 14:07
>> To: Bedyk, Witold 
>> Cc: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
>> publisher for Ceilometer
>> 
>> On Wed, Jun 20 2018, Bedyk, Witold wrote:
>> 
>> Same as Gordon. You should maintain that in your own repo.
>> There's just no bandwidth in Ceilometer right now for things like that.
>> :(
>> 
>> > Hello Telemetry Team,
>> >
>> > any opinion on this?
>> >
>> > Best greetings
>> > Witek
>> >
>> >
>> >> -Original Message-
>> >> From: Bedyk, Witold 
>> >> Sent: Mittwoch, 13. Juni 2018 10:28
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> 
>> >> Subject: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
>> >> publisher for Ceilometer
>> >>
>> >> Hello Telemetry Team,
>> >>
>> >> We would like to contribute a Monasca publisher to Ceilometer project
>> >> [1] and add it to the list of currently supported transports [2].
>> >> The goal of the plugin is to send Ceilometer samples to Monasca API.
>> >>
>> >> I understand Gordon's concerns about adding maintenance overhead for
>> >> Ceilometer team which he expressed in review but the code is pretty
>> >> much self-contained and does not affect Ceilometer core. It's not our
>> >> intention to shift the maintenance effort and Monasca team should
>> >> still be responsible for this code.
>> >>
>> >> Adding this plugin will help in terms of interoperability of both
>> >> projects and can be useful for wider parts of the OpenStack community.
>> >>
>> >> Please let me know your thoughts. I hope we can get this code merged.
>> >>
>> >> Cheers
>> >> Witek
>> >>
>> >>
>> >> [1] https://review.openstack.org/562400
>> >> [2]
>> >> https://docs.openstack.org/ceilometer/latest/contributor/architecture
>> >> .html
>> >> #processing-the-data
>> >
>> 
>> --
>> Julien Danjou
>> /* Free Software hacker
>>https://julien.danjou.info */
>
>

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Ben Nemec]

On 06/20/2018 02:58 AM, Patil, Tushar wrote:

Hi,

Few weeks back, we had proposed a patch [1] to add support for translation of 
placement policies and that patch got merged.

This feature will be consumed by tacker specs [2] which we are planning to 
implement in Rocky release and it's implementation is uploaded in patch [3]. 
Presently, the tests are failing on patch [3] becoz it requires newer version 
of heat-translator library.

Could you please release a new version of heat-translator library so that we 
can complete specs[2] in Rocky timeframe.


Note that you can propose a release to the releases repo[1] and then you 
just need the PTL or release liaison to sign off on it.


1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

__
OpenStack Development Mailing 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] [puppet-openstack][announce][debian] puppet-openstack now has full Debian support

[Thomas Goirand]

Dear Stackers,

I am glad/overjoyed/jazzed to announce the global availability of
puppet-openstack for Debian. Indeed, a few minutes ago, the CI turned
all green for Debian:

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

(note: the red one for CentOS is to be ignored, it looks like
non-deterministic error)

This is after 3 months of hard work, and more than 50 patches, sometimes
on upstream code base (for example in Cinder, Sahara, and Neutron),
often because of Python 3 or uwsgi/mod_wsgi related problems. Some of
these patches aren't merged yet upstream, but are included in the Debian
packages already. Also note that Debian fully supports SSL and ipv6
endpoints.

I'd like here to publicly thanks all of the puppet-openstack core
reviewers for their help and enthusiasm. A big thanks to mnaser,
tobasco, EmilienM and mwhahaha. Guys, you've been really awesome and
helpful with me. Also a big thanks to these upstream helping with fixing
these bits as explained above, and especially annp for fixing the
neutron-rpc-server related problems, with the patch also pending reviews
at: https://review.openstack.org/#/c/555608/

All of these puppet modules are available directly in Debian in a
packaged form. To get them, simply do:

apt-get install openstack-puppet-modules

in Debian Sid, or using the Debian backports repository at:

http://stretch-queens.infomaniak.ch/debian

Still to fix, is neutron-fwaas, which seems to not like either Python 3
or using neutron-api over uwsgi (I'm not sure which of these yet).
Upstream neutron developers are currently investigating this. For this
reason, neutron firewall extension is currently disabled for the
l3-agent, but will be reactivated as soon as a proper fix is found.

Also, Ceph in Debian is currently a way behind (so we have to use
upstream Debian repository for Stretch), as it lacks a proper Python 3
support, and still no Luminous release uploaded to Sid. I intend to
attempt to fix this, to get a chance to get this in time for Buster.

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [oslo] [placement] setting oslo config opts from environment

[Chris Dent]

On Tue, 19 Jun 2018, Doug Hellmann wrote:

I certainly have no objection to doing the work in oslo.config. As
I described on IRC today, I think we would want to implement it
using the new driver feature we're working on this cycle, even if
the driver is enabled automatically so users don't have to turn it
on. We already special case command line options and the point of
the driver interface is to give us a way to extend the lookup logic
without having to add more special cases.


I've started a draft spec at https://review.openstack.org/#/c/576860/

Some details still need to be filled in, but it's enough to frame
the idea.
--
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] Openstack-Zun Service Appears down

[Usman Awais]

Dear Zuners,

I have installed RDO pike. I stopped openstack-nova-compute service on one
of the hosts, and installed a zun-compute service. Although all the
services seems to be running ok on both controller and compute but when I
do

 openstack appcontainer service list

It gives me following

++--+-+---+--+-+-+---+
| Id | Host | Binary  | State | Disabled | Disabled Reason |
Updated At  | Availability Zone |
++--+-+---+--+-+-+---+
|  1 | node1.os.lab | zun-compute | down  | False| None|
2018-06-20 13:14:31 | nova  |
++--+-+---+--+-+-+---+

I have checked all ports in both directions they are open, including etcd
ports and others. All services are running, only docker service has the
warning message saying "failed to retrieve docker-runc version: exec:
\"docker-runc\": executable file not found in $PATH". There is also a
message at zun-compute
"/usr/lib64/python2.7/site-packages/sqlalchemy/sql/default_comparator.py:161:
SAWarning: The IN-predicate on "container.uuid" was invoked with an empty
sequence. This results in a contradiction, which nonetheless can be
expensive to evaluate.  Consider alternative strategies for improved
performance."

Please guide...

Regards,
Muhammad Usman Awais
__
OpenStack Development Mailing 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] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

Hi Julien,

could you please add some transparency to the decision process on which 
publishers are acceptable and which not? Just two months ago you have added new 
Prometheus publisher. That's around the same time when our code was submitted 
to review.

We have delivered tested code and offer its maintenance. The code is 
self-contained and does not touch Ceilometer core. If it's broken, just Monasca 
interface won't work.

Please reconsider it again.

Greetings
Witek


> -Original Message-
> From: Julien Danjou 
> Sent: Mittwoch, 20. Juni 2018 14:07
> To: Bedyk, Witold 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> publisher for Ceilometer
> 
> On Wed, Jun 20 2018, Bedyk, Witold wrote:
> 
> Same as Gordon. You should maintain that in your own repo.
> There's just no bandwidth in Ceilometer right now for things like that.
> :(
> 
> > Hello Telemetry Team,
> >
> > any opinion on this?
> >
> > Best greetings
> > Witek
> >
> >
> >> -Original Message-
> >> From: Bedyk, Witold 
> >> Sent: Mittwoch, 13. Juni 2018 10:28
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> >> publisher for Ceilometer
> >>
> >> Hello Telemetry Team,
> >>
> >> We would like to contribute a Monasca publisher to Ceilometer project
> >> [1] and add it to the list of currently supported transports [2].
> >> The goal of the plugin is to send Ceilometer samples to Monasca API.
> >>
> >> I understand Gordon's concerns about adding maintenance overhead for
> >> Ceilometer team which he expressed in review but the code is pretty
> >> much self-contained and does not affect Ceilometer core. It's not our
> >> intention to shift the maintenance effort and Monasca team should
> >> still be responsible for this code.
> >>
> >> Adding this plugin will help in terms of interoperability of both
> >> projects and can be useful for wider parts of the OpenStack community.
> >>
> >> Please let me know your thoughts. I hope we can get this code merged.
> >>
> >> Cheers
> >> Witek
> >>
> >>
> >> [1] https://review.openstack.org/562400
> >> [2]
> >> https://docs.openstack.org/ceilometer/latest/contributor/architecture
> >> .html
> >> #processing-the-data
> >
> 
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */

__
OpenStack Development Mailing 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] Ports port_binding attribute is changing to an iterable

[Takashi Yamamoto]

hi,

On Thu, Jun 7, 2018 at 4:32 AM, Miguel Lavalle  wrote:
> Dear OpenStack Networking community of projects,
>
> As part of the implementation of multiple port bindings in the Neutron
> reference implementation
> (https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html),
> the port_binding relationship in the Port DB model is changing to be an
> iterable:
>
> https://review.openstack.org/#/c/414251/66/neutron/plugins/ml2/models.py@64
>
> and its name is being changed to port_bindings:
>
> https://review.openstack.org/#/c/571041/4/neutron/plugins/ml2/models.py@61
>
> Corresponding changes are being made to the Port Oslo Versioned Object:
>
> https://review.openstack.org/#/c/414251/66/neutron/objects/ports.py@285
> https://review.openstack.org/#/c/571041/4/neutron/objects/ports.py@285
>
> I did my best to find usages of these attributes in the Neutron Stadium
> projects and only found them in networking-odl:
> https://review.openstack.org/#/c/572212/2/networking_odl/ml2/mech_driver.py.
> These are the other projects that I checked:
>
> networking-midonet
> networking-ovn
> networking-bagpipe
> networking-bgpvpn
> neutron-dynamic-routing
> neutron-fwaas
> neutron-vpnaas
> networking-sfc
>
> I STRONGLY ENCOURAGE these projects teams to double check and see if you
> might be affected. I also encourage projects in the broader OpenStack
> Networking community of projects to check for possible impacts. We will be
> holding these two patches until June 14th before merging them.

i checked the following projects. they looked ok.

networking-midonet
networking-ovn
neutron-vpnaas
tap-as-a-service

>
> If you need help dealing with the change, please ping me in the Neutron
> channel
>
> Best regards
>
> Miguel
>
> __
> OpenStack Development Mailing 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] minimum libvirt version for nova-compute

[Lee Yarwood]

On 20-06-18 07:32:08, Matt Riedemann wrote:
> On 6/20/2018 6:54 AM, Lee Yarwood wrote:
> > We can bump the minimum here but then we have to play a game of working
> > out the oldest version the above fix was backported to across the
> > various distros. I'd rather see this address by the Libvirt maintainers
> > in Debian if I'm honest.
> 
> Just a thought, but in nova we could at least do:
> 
> 1. Add a 'known issues' release note about the issue and link to the libvirt
> patch.

ACK
 
> and/or
> 
> 2. Handle libvirtError in that case, check for the "Incorrect number of
> padding bytes" string in the error, and log something with a breadcrumb to
> the libvirt fix - that would be for people that miss the release note, or
> hit the issue past rocky and wouldn't have found the release note because
> they're on Stein+ now.

Yeah that's fair, I'll submit something for both of the above today.

Cheers,

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


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

Re: [openstack-dev] minimum libvirt version for nova-compute

[Matt Riedemann]

On 6/20/2018 6:54 AM, Lee Yarwood wrote:

We can bump the minimum here but then we have to play a game of working
out the oldest version the above fix was backported to across the
various distros. I'd rather see this address by the Libvirt maintainers
in Debian if I'm honest.


Just a thought, but in nova we could at least do:

1. Add a 'known issues' release note about the issue and link to the 
libvirt patch.


and/or

2. Handle libvirtError in that case, check for the "Incorrect number of 
padding bytes" string in the error, and log something with a breadcrumb 
to the libvirt fix - that would be for people that miss the release 
note, or hit the issue past rocky and wouldn't have found the release 
note because they're on Stein+ now.


--

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] [docs] Office hours instead of regular docs project meetings?

[Petr Kovar]

Hi all,

Due to low attendance in docs project meetings in recent months, I'd like
to propose turning regular docs meetings into office hours, like many other
OpenStack teams did.

My idea is to hold office hours every Wednesday, same time we held our
docs meetings, at 16:00 UTC, in our team channel #openstack-doc where
many community members already hang out and ask their questions about
OpenStack docs.

Objections, comments, thoughts? 

Would there be interest to also hold office hours during a more
APAC-friendly time slot? We'd need to volunteers to take care of it, please
let me know!

Thanks,
pk

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

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Julien Danjou]

On Wed, Jun 20 2018, Bedyk, Witold wrote:

Same as Gordon. You should maintain that in your own repo.
There's just no bandwidth in Ceilometer right now for things like that.
:(

> Hello Telemetry Team,
>
> any opinion on this?
>
> Best greetings
> Witek
>
>
>> -Original Message-
>> From: Bedyk, Witold 
>> Sent: Mittwoch, 13. Juni 2018 10:28
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
>> publisher for Ceilometer
>> 
>> Hello Telemetry Team,
>> 
>> We would like to contribute a Monasca publisher to Ceilometer project [1]
>> and add it to the list of currently supported transports [2].
>> The goal of the plugin is to send Ceilometer samples to Monasca API.
>> 
>> I understand Gordon's concerns about adding maintenance overhead for
>> Ceilometer team which he expressed in review but the code is pretty much
>> self-contained and does not affect Ceilometer core. It's not our intention to
>> shift the maintenance effort and Monasca team should still be responsible
>> for this code.
>> 
>> Adding this plugin will help in terms of interoperability of both projects 
>> and
>> can be useful for wider parts of the OpenStack community.
>> 
>> Please let me know your thoughts. I hope we can get this code merged.
>> 
>> Cheers
>> Witek
>> 
>> 
>> [1] https://review.openstack.org/562400
>> [2]
>> https://docs.openstack.org/ceilometer/latest/contributor/architecture.html
>> #processing-the-data
>

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

Hello Telemetry Team,

any opinion on this?

Best greetings
Witek


> -Original Message-
> From: Bedyk, Witold 
> Sent: Mittwoch, 13. Juni 2018 10:28
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> publisher for Ceilometer
> 
> Hello Telemetry Team,
> 
> We would like to contribute a Monasca publisher to Ceilometer project [1]
> and add it to the list of currently supported transports [2].
> The goal of the plugin is to send Ceilometer samples to Monasca API.
> 
> I understand Gordon's concerns about adding maintenance overhead for
> Ceilometer team which he expressed in review but the code is pretty much
> self-contained and does not affect Ceilometer core. It's not our intention to
> shift the maintenance effort and Monasca team should still be responsible
> for this code.
> 
> Adding this plugin will help in terms of interoperability of both projects and
> can be useful for wider parts of the OpenStack community.
> 
> Please let me know your thoughts. I hope we can get this code merged.
> 
> Cheers
> Witek
> 
> 
> [1] https://review.openstack.org/562400
> [2]
> https://docs.openstack.org/ceilometer/latest/contributor/architecture.html
> #processing-the-data
__
OpenStack Development Mailing 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] minimum libvirt version for nova-compute

[Lee Yarwood]

On 20-06-18 11:23:24, Thomas Goirand wrote:
> Hi,
> 
> Trying to get puppet-openstack to validate with Debian, I got surprised
> that mounting encrypted volume didn't work for me, here's the stack dump
> with libvirt 3.0.0 from Debian Stretch:
> 
>File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py",
> line 1463, in attach_volume
>  guest.attach_device(conf, persistent=True, live=live)
>File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py",
> line 303, in attach_device
>  self._domain.attachDeviceFlags(device_xml, flags=flags)
>File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 186, in
> doit
>  result = proxy_call(self._autowrap, f, *args, **kwargs)
>File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 144, in
> proxy_call
>  rv = execute(f, *args, **kwargs)
>File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 125, in
> execute
>  six.reraise(c, e, tb)
>File "/usr/lib/python3/dist-packages/eventlet/support/six.py", line
> 625, in reraise
>  raise value
>File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 83, in
> tworker
>  rv = meth(*args, **kwargs)
>File "/usr/lib/python3/dist-packages/libvirt.py", line 585, in
> attachDeviceFlags
>  if ret == -1: raise libvirtError ('virDomainAttachDeviceFlags()
> failed', dom=self)
>  libvirt.libvirtError: internal error: unable to execute QEMU command
> 'object-add': Incorrect number of padding bytes (57) found on decrypted data

That's actually a bug and not a lack of support in the version of
libvirt you're using:

Unable to use LUKS passphrase that is exactly 16 bytes long 
https://bugzilla.redhat.com/show_bug.cgi?id=1447297

[libvirt] [PATCH] Fix padding of encrypted data
https://www.redhat.com/archives/libvir-list/2017-May/msg00030.html

> After switching to libvirt 4.3.0 (my own backport from Debian Testing),
> it does work. So, while the minimum version of libvirt seems to be
> enough for normal operation, it isn't for encrypted volumes.
> 
> Therefore, I wonder if Nova shouldn't declare a minimum version of
> libvirt higher than it claims at the moment. I'm stating that,
> especially because we had this topic a few weeks ago.

We can bump the minimum here but then we have to play a game of working
out the oldest version the above fix was backported to across the
various distros. I'd rather see this address by the Libvirt maintainers
in Debian if I'm honest. 

Cheers,

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


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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

hi,

On Thu, May 17, 2018 at 12:51 PM, Tony Breeds  wrote:
> On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote:
>> On 18-05-16 17:07:09, Doug Hellmann wrote:
>> > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
>> > > Sphinx has breaking changes (yet again) and we need to figure out how to
>> > > deal with it.  I think the fix will be simple for affected projects, but
>> > > we should probably move forward on this.  The error people are getting
>> > > seems to be 'Field list ends without a blank line; unexpected unindent.'
>> > >
>> > > I'd like to keep on 1.7.4 and have the affected projects fix the error
>> > > so we can move on, but the revert has been proposed (and approved to get
>> > > gate unbroken for them).  https://review.openstack.org/568248  Any
>> > > advice from the community is welcome.
>> > >
>> >
>> > Is it sphinx, or docutils?
>> >
>> > Do you have an example of the error?
>> >
>>
>> From https://bugs.launchpad.net/networking-midonet/+bug/1771092
>>
>> 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error:
>> 2018-05-13 14:22:06.176967 | ubuntu-xenial | 
>> /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring
>>  of 
>> midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field
>>  list ends without a blank line; unexpected unindent.
>>
>
> Adding something like:
>
> (.docs) [tony@thor networking-midonet]$ ( cd ../neutron && git diff )
> diff --git a/neutron/db/l3_db.py b/neutron/db/l3_db.py
> index 33b5d99b1..66794542a 100644
> --- a/neutron/db/l3_db.py
> +++ b/neutron/db/l3_db.py
> @@ -1091,8 +1091,8 @@ class L3_NAT_dbonly_mixin(l3.RouterPluginBase,
>  :param internal_subnet: The subnet for the fixed-ip.
>  :param external_network_id: The external network for floating-ip.
>
> -:raises: ExternalGatewayForFloatingIPNotFound if no suitable router
> -is found.
> +:raises: ExternalGatewayForFloatingIPNotFound if no suitable router \
> + is found.
>  """
>
>  # Find routers(with router_id and interface address) that
> (.docs) [tony@thor networking-midonet]$ ( cd ../os-vif && git diff )
> diff --git a/os_vif/plugin.py b/os_vif/plugin.py
> index 56566a6..2a437a6 100644
> --- a/os_vif/plugin.py
> +++ b/os_vif/plugin.py
> @@ -49,10 +49,11 @@ class PluginBase(object):
>  Given a model of a VIF, perform operations to plug the VIF properly.
>
>  :param vif: `os_vif.objects.vif.VIFBase` object.
> -:param instance_info: `os_vif.objects.instance_info.InstanceInfo`
> -object.
> -:raises `processutils.ProcessExecutionError`. Plugins implementing
> -this method should let `processutils.ProcessExecutionError`
> +:param instance_info: `os_vif.objects.instance_info.InstanceInfo` \
> +  object.
> +
> +:raises `processutils.ProcessExecutionError`. Plugins implementing \
> +this method should let `processutils.ProcessExecutionError` \
>  bubble up.
>  """
>
> @@ -63,9 +64,10 @@ class PluginBase(object):
>
>  :param vif: `os_vif.objects.vif.VIFBase` object.
>  :param instance_info: `os_vif.objects.instance_info.InstanceInfo`
> -object.
> -:raises `processutils.ProcessExecutionError`. Plugins implementing
> -this method should let `processutils.ProcessExecutionError`
> +  object.
> +
> +:raises `processutils.ProcessExecutionError`. Plugins implementing \
> +this method should let `processutils.ProcessExecutionError` \
>  bubble up.
>  """
>
> fixes the midonet docs build for me (locally) on sphinx 1.7.4.  I'm far from a
> sphinx expert but the chnages to neutron and os-vif seem correct to me.

do you have a plan to submit these changes on gerrit?

>
> Perhaps the sphinx parser just got more strict?
>
> 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] [nova]Notification update week 25

[Balázs Gibizer]

On Tue, Jun 19, 2018 at 7:07 PM, Matt Riedemann  
wrote:

On 6/18/2018 10:10 AM, Balázs Gibizer wrote:

* Introduce instance.lock and instance.unlock notifications
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances


This hasn't been updated in quite awhile. I wonder if someone else 
wants to pick that up now?


I'm OK if somebody picks it up. I will try to give review support.
Cheers,
gibi



--

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] minimum libvirt version for nova-compute

[Thomas Goirand]

Hi,

Trying to get puppet-openstack to validate with Debian, I got surprised
that mounting encrypted volume didn't work for me, here's the stack dump
with libvirt 3.0.0 from Debian Stretch:

   File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py",
line 1463, in attach_volume
 guest.attach_device(conf, persistent=True, live=live)
   File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py",
line 303, in attach_device
 self._domain.attachDeviceFlags(device_xml, flags=flags)
   File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 186, in
doit
 result = proxy_call(self._autowrap, f, *args, **kwargs)
   File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 144, in
proxy_call
 rv = execute(f, *args, **kwargs)
   File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 125, in
execute
 six.reraise(c, e, tb)
   File "/usr/lib/python3/dist-packages/eventlet/support/six.py", line
625, in reraise
 raise value
   File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 83, in
tworker
 rv = meth(*args, **kwargs)
   File "/usr/lib/python3/dist-packages/libvirt.py", line 585, in
attachDeviceFlags
 if ret == -1: raise libvirtError ('virDomainAttachDeviceFlags()
failed', dom=self)
 libvirt.libvirtError: internal error: unable to execute QEMU command
'object-add': Incorrect number of padding bytes (57) found on decrypted data

After switching to libvirt 4.3.0 (my own backport from Debian Testing),
it does work. So, while the minimum version of libvirt seems to be
enough for normal operation, it isn't for encrypted volumes.

Therefore, I wonder if Nova shouldn't declare a minimum version of
libvirt higher than it claims at the moment. I'm stating that,
especially because we had this topic a few weeks ago.

Thoughts anyone?
Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [heat] Need new release of heat-translator library

[Patil, Tushar]

Hi,

Few weeks back, we had proposed a patch [1] to add support for translation of 
placement policies and that patch got merged.

This feature will be consumed by tacker specs [2] which we are planning to 
implement in Rocky release and it's implementation is uploaded in patch [3]. 
Presently, the tests are failing on patch [3] becoz it requires newer version 
of heat-translator library.

Could you please release a new version of heat-translator library so that we 
can complete specs[2] in Rocky timeframe.

Thank you.

Regards,
Tushar Patil
Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged,confidential, 
and proprietary data. If you are not the intended recipient,please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.

__
OpenStack Development Mailing 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] [watcher] weekly meeting

[Чадин Александр Сергеевич]

Watchers,

We have meeting today at 8:00 UTC on #openstack-meeting-3 channel.

Best Regards,

Alex

__
OpenStack Development Mailing 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] [ceilometer][panko][pike] elasticsearch integration

[cristian.calin]

Some more details, I tried running with python3 and the error I got with it is 
a bit more detailed:

{"asctime": "2018-06-20 07:06:11.537","process": "24","levelname": 
"ERROR","name": "ceilometer.pipeline", "instance": {},"message":"Unable to load 
publisher panko://"}: tenacity.RetryError: RetryError[]
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >Traceback (most 
recent call last):
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/tenacity/__init__.py", line 251, 
in call
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >result = 
fn(*args, **kwargs)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/panko/storage/__init__.py", line 
71, in _inner
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return 
get_connection(url, conf)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/panko/storage/__init__.py", line 
86, in get_connection
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return 
mgr.driver(url, conf)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/panko/storage/impl_elasticsearch.py",
 line 74, in __init__
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >use_ssl = 
conf.database.es_ssl_enabled
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/oslo_config/cfg.py", line 3363, in 
__getattr__
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return 
self._conf._get(name, self._group)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/oslo_config/cfg.py", line 2925, in 
_get
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >value = 
self._do_get(name, group, namespace)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/oslo_config/cfg.py", line 2942, in 
_do_get
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >info = 
self._get_opt_info(name, group)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/oslo_config/cfg.py", line 3099, in 
_get_opt_info
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >raise 
NoSuchOptError(opt_name, group)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  
>oslo_config.cfg.NoSuchOptError: no such option es_ssl_enabled in group 
[database]
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >The above exception 
was the direct cause of the following exception:
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >Traceback (most 
recent call last):
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/ceilometer/pipeline.py", line 419, 
in __init__
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >
self.publishers.append(publisher_manager.get(p))
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/ceilometer/pipeline.py", line 713, 
in get
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >
'ceilometer.%s.publisher' % self._purpose)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/ceilometer/publisher/__init__.py", 
line 36, in get_publisher
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return 
loaded_driver.driver(parse_result)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/panko/publisher/database.py", line 
35, in __init__
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >self.conn = 
storage.get_connection_from_config(conf)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/panko/storage/__init__.py", line 
73, in get_connection_from_config
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return _inner()
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/tenacity/__init__.py", line 171, 
in wrapped_f
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >return 
self.call(f, *args, **kw)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/tenacity/__init__.py", line 248, 
in call
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >
start_time=start_time)
2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline  >  File 
"/opt/ceilometer/lib/python3.5/site-packages/tenacity/__init__.py", line 217, 
in iter
2018-06-20 07