[openstack-dev] [openstack-infra] How to take over a project?

[Sangho Shin]

Dear OpenStack Infra team,

I would like to know how to take over an OpenStack project.
I am a committer of the networking-onos project 
(https://github.com/openstack/networking-onos 
), and I would like to take over 
the project. 
The current maintainer (cc’d) has already agreed with that.

Please let me know the process to take over (or change the maintainer of) the 
project.

BTW, it looks like even the current maintainer cannot create a new branch of 
the codes. How can we get the authority to create a new branch?

Thank you,

Sangho__
OpenStack Development Mailing 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] [Mistral]I think Mistral need K8S action

[홍선군]

Thank you very much for your help.

 

I'm doing some tests now and I'll let you know if I start the K8S action.

 

Thanks again,

 

Xian Jun Hong

 

From: Dougal Matthews  
Sent: Tuesday, April 17, 2018 6:00 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

 

 

On 16 April 2018 at 05:08,  > wrote:

Thanks for your reply.

 

I will refer to this Ansible action and developing  actions for K8S somewhere 
externally. 

 

Great. Do let us know when you start someting - I would be interested in giving 
feedback and testing or possibly helping out too.

 

 

Regards,

Xian Jun Hong

 

 

From: Dougal Matthews  > 
Sent: Saturday, April 14, 2018 1:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
 >
Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

 

 

On 13 April 2018 at 05:47, Renat Akhmerov  > wrote:

Hi, 

 

I completely agree with you that having such an action would be useful. 
However, I don’t think this kind of action should be provided by Mistral out of 
the box. Actions and triggers are integration pieces for Mistral and are 
natively external to Mistral code base. In other words, this action can be 
implemented anywhere and plugged into a concrete Mistral installation where 
needed.

 

As a home for this action I’d propose 'mistral-extra’ repo where we are 
planning to move OpenStack actions and some more.

Also, if you’d like to contribute you’re very welcome.

 

I would recommend developing actions for K8s somewhere externally, then when 
mistral-extra is ready we can move them over. This is the approach that I took 
for the Ansible actions[1] and they will likely be one of the first additions 
to mistral-extra.

[1]: https://github.com/d0ugal/mistral-ansible-actions


 

 


Thanks

Renat Akhmerov
@Nokia


On 13 Apr 2018, 09:18 +0700, <  
xianjun...@dcn.ssu.ac.kr>, wrote:

Hello  Mistral team.

I'm doing some work on the K8S but I observed that there is only Docker's 
action in Mistral.

I would like to ask Mistral Team, why there is no K8S action in the mistral.

I think it would be useful in Mistral.

If you feel it's necessary, could I add K8S action to mistral?

 

Regards,

Xian Jun Hong

 

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


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

 


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

 

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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[melanie witt]

On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
 >>>The "iso file" will not be inside the guest, but rather passed to 
the guest as a block device, right?
Cloud init expects to find a config drive with following requirements 
[1], in order to make cloud init able to consume config drive , we 
should be able to prepare it,
in some hypervisor, you can define something like following to the VM 
then VM startup is able to consume it


but for z/VM case it allows disk to be created during VM create (define 
)stage but no disk format set, it's the operating system's 
responsibility to define the purpose of the

disk, so what we do is
1) first when we build image ,we create a small AE like cloud-init but 
only purpose is to get files from z/VM internal pipe and handle config 
drive case


What does AE stand for? So, this means in order to use the z/VM driver, 
users must have special images that will ensure the config drive will be 
readable by cloud-init. They can't use standard cloud images.


2) During spawn we create config drive in nova-compute side then send 
the file to z/VM through z/VM internal pipe (omit detail here)
3) During startup of the virtual machine, the small AE is able to mount 
the file as loop device and then in turn cloud-init is able to handle it


because this is our special case, we don't want to upload to cloud-init 
community because of uniqueness and as far as we can tell, no hook in 
cloud-init mechanism allowed as well
to let us 'mount -o loop' ; also, from openstack point of view except 
this small AE (which is documented well) no special thing and 
inconsistent to other drivers


[1]https://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceConfigDrive.py#L225


Where is the AE documented? How do users obtain it? What tools are they 
supposed to use to build images to use with the z/VM driver?


That aside, from what I can see, the z/VM driver behaves unlike any 
other in-tree driver [0-5] in how it handles config drive. Drivers are 
expected to create the config drive and present it to the guest in 
iso9660 or vfat format without requirement of a custom image and the 
existing drivers are doing that.


IMHO, if the z/VM driver can't be fixed to provide proper config drive 
support, we won't be able to approve the implementation patches. I would 
like to hear other opinions about it.


I propose that we remove the z/VM driver blueprint from the runway at 
this time and place it back into the queue while work on the driver 
continues. At a minimum, we need to see z/VM CI running with 
[validation]run_validation = True in tempest.conf before we add the z/VM 
driver blueprint back into a runway in the future.


Cheers,
-melanie

[0] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/hyperv/vmops.py#L661
[1] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/ironic/driver.py#L974
[2] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/libvirt/driver.py#L3595
[3] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/powervm/media.py#L120
[4] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/vmwareapi/vmops.py#L854
[5] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/xenapi/vm_utils.py#L1151


__
OpenStack Development Mailing 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] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Rong Zhu]

Hi Sean!

yaql is OK to this.


On Sat, Apr 14, 2018 at 3:46 AM, Sean McGinnis 
wrote:

> Hello teams,
>
> I am following up on some recently announced changes regarding governed
> projects and tagging rights. See [1] for background.
>
> It was mostly followed before that when a project came under official
> governance that all tagging and releases would then move to using the
> openstack/releases repo and associated automation. It was not officially
> stated
> until recently that this was one of the steps of coming under governance,
> so
> there were a few projects that became official but that continued to do
> their
> own releases.
>
> We've cleaned up most projects' rights to push tags, but for the ones
> listed
> here we waited:
>
> - rally
> - dragflow
> - ec2-api
> - networking-powervm
> - nova-powervm
> - yaql
>
> We would like to finish cleaning up the ACLs for these, but I wanted to
> check
> with the teams to make sure there wasn't a reason why these repos had
> continued
> tagging separately. Please let me know, either here or in the
> #openstack-release channel, if there is something we are overlooking.
>
> Thanks for your attention.
>
> ---
> Sean (smcginnis)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Rong Zhu
__
OpenStack Development Mailing 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] Removing networking-mlnx from Debian?

[Moshe Levi]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Monday, April 16, 2018 10:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] Removing networking-mlnx from Debian?
> 
> On 2018-04-13 14:17:29 + (+), Moshe Levi wrote:
> [...]
> > Yes, How can we add python3 job in zuul for testing it?
> 
> I've proposed
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F561703=02%7C01%7Cmoshele%40mellanox.com
> %7C5bffbf4cda7b4efc8df408d5a3d26fad%7Ca652971c7d2e4d9ba6a4d149256f
> 461b%7C0%7C0%7C636595046579652523=7pNgYdNQnNvno%2FH29ZF
> qh00D6Sn0l5cB6tqnGMePrQ4%3D=0 to add the corresponding
> Python3.5 version of your unit test jobs. Looks like it's passing if you want 
> to
> the openstack-tox-py35 job (Ran: 176 tests in 8.8742 sec.) if you feel like
> approving.
Approved. Thanks :) 
> --
> 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

Re: [openstack-dev] [api] Adding a SDK to developer.openstack.org pages

[Gilles Dubreuil]

On 06/04/18 22:37, Jeremy Stanley wrote:

On 2018-04-06 12:00:24 +1000 (+1000), Gilles Dubreuil wrote:

I'd like to update the developer.openstack.org to add details about a new
SDK.

What would be the corresponding repo? My searches landed me into
https://docs.openstack.org/doc-contrib-guide/ which is about updating the
docs.openstack.org but not developer.openstack.org. Is the developer section
inside the docs section?

Looks like we could do a better job of linking to the relevant git
repositories from some documents.

I think the file you're looking for is probably:

 https://git.openstack.org/cgit/openstack/api-site/tree/www/index.html

Happy hacking!


That's the one!

Thank you



__
OpenStack Development Mailing 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] [placement] Anchor/Relay Providers

[Jay Pipes]

On 04/16/2018 06:23 PM, Eric Fried wrote:

I still don't see a use in returning the root providers in the
allocation requests -- since there is nothing consuming resources from
those providers.

And we already return the root_provider_uuid for all providers involved
in allocation requests within the provider_summaries section.

So, I can kind of see where we might want to change *this* line of the
nova scheduler:

https://github.com/openstack/nova/blob/stable/pike/nova/scheduler/filter_scheduler.py#L349


from this:

  compute_uuids = list(provider_summaries.keys())

to this:

  compute_uuids = set([
  ps['root_provider_uuid'] for ps in provider_summaries
  ])


If we're granting that it's possible to get all your resources from
sharing providers, the above doesn't help you to know which of your
compute_uuids belongs to which of those sharing-only allocation requests.

I'm fine deferring this part until we have a use case for sharing-only
allocation requests that aren't prompted by an "attach-*" case where we
already know the target host/consumer.  But I'd like to point out that
there's nothing in the API that prevents us from getting such results.


And I'd like to point out that I originally made the GET 
/allocation_candidates API not return allocation requests when there 
were only sharing providers.


Because... well, there's just no viable use cases for it.

-jay

__
OpenStack Development Mailing 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] [placement] Anchor/Relay Providers

[Eric Fried]

> I still don't see a use in returning the root providers in the
> allocation requests -- since there is nothing consuming resources from
> those providers.
> 
> And we already return the root_provider_uuid for all providers involved
> in allocation requests within the provider_summaries section.
> 
> So, I can kind of see where we might want to change *this* line of the
> nova scheduler:
> 
> https://github.com/openstack/nova/blob/stable/pike/nova/scheduler/filter_scheduler.py#L349
> 
> 
> from this:
> 
>  compute_uuids = list(provider_summaries.keys())
> 
> to this:
> 
>  compute_uuids = set([
>  ps['root_provider_uuid'] for ps in provider_summaries
>  ])

If we're granting that it's possible to get all your resources from
sharing providers, the above doesn't help you to know which of your
compute_uuids belongs to which of those sharing-only allocation requests.

I'm fine deferring this part until we have a use case for sharing-only
allocation requests that aren't prompted by an "attach-*" case where we
already know the target host/consumer.  But I'd like to point out that
there's nothing in the API that prevents us from getting such results.

-efried

__
OpenStack Development Mailing 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] [PBR] Patches on PBR

[Gaetan]

Hello,

I have started a few other patches on PBR, can anyone give me some feedback
on them?

https://review.openstack.org/558181
https://review.openstack.org/561731
https://review.openstack.org/559484

They don't do that much, but they can help dev workflow

Thanks a lot !

-
Gaetan


2018-04-08 9:39 GMT+02:00 Gaetan :

> Hello,
>
> I have started a few patch on PBR which fail, but I am not sure the
> reason, they seem related to something external of my changes:
>
> - https://review.openstack.org/#/c/559484/6: 'pbr boostrap' command.
> Error seems:"testtools.matchers._impl.MismatchError: b'STARTING test
> server pbr_testpackage.wsgi' not in b''"
> - https://review.openstack.org/#/c/558181/: proposal for update of
> sem-ver 3 doc
> - https://review.openstack.org/#/c/524436/: Pipfile support (still WIP)
>
> Can you review them?
> Thanks,
>
> -
> Gaetan
>
>
__
OpenStack Development Mailing 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] [Mistral]I think Mistral need K8S action

[Dougal Matthews]

On 16 April 2018 at 05:08, 홍선군  wrote:

> Thanks for your reply.
>
>
>
> I will refer to this Ansible action and developing  actions for K8S
> somewhere externally.
>

Great. Do let us know when you start someting - I would be interested in
giving feedback and testing or possibly helping out too.


>
>
> Regards,
>
> Xian Jun Hong
>
>
>
>
>
> *From:* Dougal Matthews 
> *Sent:* Saturday, April 14, 2018 1:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Mistral]I think Mistral need K8S action
>
>
>
>
>
>
>
> On 13 April 2018 at 05:47, Renat Akhmerov 
> wrote:
>
> Hi,
>
>
>
> I completely agree with you that having such an action would be useful.
> However, I don’t think this kind of action should be provided by Mistral
> out of the box. Actions and triggers are integration pieces for Mistral and
> are natively external to Mistral code base. In other words, this action can
> be implemented anywhere and plugged into a concrete Mistral installation
> where needed.
>
>
>
> As a home for this action I’d propose 'mistral-extra’ repo where we are
> planning to move OpenStack actions and some more.
>
> Also, if you’d like to contribute you’re very welcome.
>
>
>
> I would recommend developing actions for K8s somewhere externally, then
> when mistral-extra is ready we can move them over. This is the approach
> that I took for the Ansible actions[1] and they will likely be one of the
> first additions to mistral-extra.
>
> [1]: https://github.com/d0ugal/mistral-ansible-actions
>
>
>
>
>
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> On 13 Apr 2018, 09:18 +0700, , wrote:
>
> Hello  Mistral team.
>
> I'm doing some work on the K8S but I observed that there is only Docker's
> action in Mistral.
>
> I would like to ask Mistral Team, why there is no K8S action in the
> mistral.
>
> I think it would be useful in Mistral.
>
> If you feel it's necessary, could I add K8S action to mistral?
>
>
>
> Regards,
>
> Xian Jun Hong
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [placement] Anchor/Relay Providers

[Jay Pipes]

On 04/16/2018 04:16 PM, Eric Fried wrote:

I was presenting an example using VM-ish resource classes, because I can
write them down and everybody knows what I'm talking about without me
having to explain what they are.  But remember we want placement to be
usable outside of Nova as well.

But also, I thought we had situations where the VCPU and MEMORY_MB were
themselves provided by sharing providers, associated with a compute host
RP that may be itself devoid of inventory.  (This may even be a viable
way to model VMWare's clustery things today.)


I still don't see a use in returning the root providers in the 
allocation requests -- since there is nothing consuming resources from 
those providers.


And we already return the root_provider_uuid for all providers involved 
in allocation requests within the provider_summaries section.


So, I can kind of see where we might want to change *this* line of the 
nova scheduler:


https://github.com/openstack/nova/blob/stable/pike/nova/scheduler/filter_scheduler.py#L349

from this:

 compute_uuids = list(provider_summaries.keys())

to this:

 compute_uuids = set([
 ps['root_provider_uuid'] for ps in provider_summaries
 ])

But other than that, I don't see a reason to change the response from 
GET /allocation_candidates at this time.


Best,
-jay


On 04/16/2018 01:58 PM, Jay Pipes wrote:

Sorry it took so long to respond. Comments inline.

On 03/30/2018 08:34 PM, Eric Fried wrote:

Folks who care about placement (but especially Jay and Tetsuro)-

I was reviewing [1] and was at first very unsatisfied that we were not
returning the anchor providers in the results.  But as I started digging
into what it would take to fix it, I realized it's going to be
nontrivial.  I wanted to dump my thoughts before the weekend.


It should be legal to have a configuration like:

  #    CN1 (VCPU, MEMORY_MB)
  #    /  \
  #   /agg1    \agg2
  #  /  \
  # SS1    SS2
  #  (DISK_GB)  (IPV4_ADDRESS)

And make a request for DISK_GB,IPV4_ADDRESS;
And have it return a candidate including SS1 and SS2.

The CN1 resource provider acts as an "anchor" or "relay": a provider
that doesn't provide any of the requested resource, but connects to one
or more sharing providers that do so.


To be honest, such a request just doesn't make much sense to me.

Think about what that is requesting. I want some DISK_GB resources and
an IP address. For what? What is going to be *using* those resources?

Ah... a virtual machine. In other words, something that would *also* be
requesting some CPU and memory resources as well.

So, the request is just fatally flawed, IMHO. It doesn't represent a use
case from the real world.

I don't believe we should be changing placement (either the REST API or
the implementation of allocation candidate retrieval) for use cases that
don't represent real-world requests.

Best,
-jay

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


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



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

Re: [openstack-dev] [placement] Anchor/Relay Providers

[Eric Fried]

I was presenting an example using VM-ish resource classes, because I can
write them down and everybody knows what I'm talking about without me
having to explain what they are.  But remember we want placement to be
usable outside of Nova as well.

But also, I thought we had situations where the VCPU and MEMORY_MB were
themselves provided by sharing providers, associated with a compute host
RP that may be itself devoid of inventory.  (This may even be a viable
way to model VMWare's clustery things today.)

-efried

On 04/16/2018 01:58 PM, Jay Pipes wrote:
> Sorry it took so long to respond. Comments inline.
> 
> On 03/30/2018 08:34 PM, Eric Fried wrote:
>> Folks who care about placement (but especially Jay and Tetsuro)-
>>
>> I was reviewing [1] and was at first very unsatisfied that we were not
>> returning the anchor providers in the results.  But as I started digging
>> into what it would take to fix it, I realized it's going to be
>> nontrivial.  I wanted to dump my thoughts before the weekend.
>>
>> 
>> It should be legal to have a configuration like:
>>
>>  #    CN1 (VCPU, MEMORY_MB)
>>  #    /  \
>>  #   /agg1    \agg2
>>  #  /  \
>>  # SS1    SS2
>>  #  (DISK_GB)  (IPV4_ADDRESS)
>>
>> And make a request for DISK_GB,IPV4_ADDRESS;
>> And have it return a candidate including SS1 and SS2.
>>
>> The CN1 resource provider acts as an "anchor" or "relay": a provider
>> that doesn't provide any of the requested resource, but connects to one
>> or more sharing providers that do so.
> 
> To be honest, such a request just doesn't make much sense to me.
> 
> Think about what that is requesting. I want some DISK_GB resources and
> an IP address. For what? What is going to be *using* those resources?
> 
> Ah... a virtual machine. In other words, something that would *also* be
> requesting some CPU and memory resources as well.
> 
> So, the request is just fatally flawed, IMHO. It doesn't represent a use
> case from the real world.
> 
> I don't believe we should be changing placement (either the REST API or
> the implementation of allocation candidate retrieval) for use cases that
> don't represent real-world requests.
> 
> Best,
> -jay
> 
> __
> OpenStack Development Mailing 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] Removing networking-mlnx from Debian?

[Jeremy Stanley]

On 2018-04-13 14:17:29 + (+), Moshe Levi wrote:
[...]
> Yes, How can we add python3 job in zuul for testing it?

I've proposed https://review.openstack.org/561703 to add the
corresponding Python3.5 version of your unit test jobs. Looks like
it's passing if you want to the openstack-tox-py35 job (Ran: 176
tests in 8.8742 sec.) if you feel like approving.
-- 
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] [Elections][TC] Announcing Davanum Srinivas (dims) candidacy for TC

[Davanum Srinivas]

Team,

Please consider my candidacy for Rocky. Please see my previous two candidacy
statements [1][2], participation in TC deliberations [3] and recent bootstrap
of SIG-OpenStack/SIG-Kubernetes cross community collaboration [4] with the
Kubernetes/CNCF communities. With the OpenLab initiative, we have been
able to get
our sister projects like GopherCloud, Terraform etc some solid testing and we
are well on our way to co-test master of Kubernetes and OpenStack as well.

While i have been long enough to be considering turning over leadership role to
other folks, i do feel like i have some  unfinished business that i would like
to concentrate on for the next year. I spent quite a bit of time with things
that use OpenStack and have a new  appreciation for the challenges in the field
and in practice. Just for example the need for a "validator" by our partners
in CF [5] illustrates the kind of challenges our users face. I would like to
spend some time working / tackling these kinds of issues. Other things that
i have promised but not yet acted on to my satisfaction are drafting some
initial constellation(s), making it easier on part time contributors, easing
the pain of working in the community for folks in other geographies etc.

I hope you consider my candidacy. I will be working on these things
irrespective
of whether i am elected or not :)

Thanks,
Dims


[1] 
https://git.openstack.org/cgit/openstack/election/plain/candidates/newton/TC/Davanum_Srinivas.txt
[2] 
https://git.openstack.org/cgit/openstack/election/plain/candidates/pike/TC/dims.txt
[3] 
https://review.openstack.org/#/q/project:openstack/governance+reviewedby:%22Davanum+Srinivas+(dims)+%253Cdavanum%2540gmail.com%253E%22
[4] https://github.com/kubernetes/cloud-provider-openstack
[5] https://github.com/cloudfoundry-incubator/cf-openstack-validator

-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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] [placement] Anchor/Relay Providers

[Jay Pipes]

Sorry it took so long to respond. Comments inline.

On 03/30/2018 08:34 PM, Eric Fried wrote:

Folks who care about placement (but especially Jay and Tetsuro)-

I was reviewing [1] and was at first very unsatisfied that we were not
returning the anchor providers in the results.  But as I started digging
into what it would take to fix it, I realized it's going to be
nontrivial.  I wanted to dump my thoughts before the weekend.


It should be legal to have a configuration like:

 #CN1 (VCPU, MEMORY_MB)
 #/  \
 #   /agg1\agg2
 #  /  \
 # SS1SS2
 #  (DISK_GB)  (IPV4_ADDRESS)

And make a request for DISK_GB,IPV4_ADDRESS;
And have it return a candidate including SS1 and SS2.

The CN1 resource provider acts as an "anchor" or "relay": a provider
that doesn't provide any of the requested resource, but connects to one
or more sharing providers that do so.


To be honest, such a request just doesn't make much sense to me.

Think about what that is requesting. I want some DISK_GB resources and 
an IP address. For what? What is going to be *using* those resources?


Ah... a virtual machine. In other words, something that would *also* be 
requesting some CPU and memory resources as well.


So, the request is just fatally flawed, IMHO. It doesn't represent a use 
case from the real world.


I don't believe we should be changing placement (either the REST API or 
the implementation of allocation candidate retrieval) for use cases that 
don't represent real-world requests.


Best,
-jay

__
OpenStack Development Mailing 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] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Python-ironicclient things
- Accept a version on set_provision_state
- https://review.openstack.org/#/c/558027/
- Wire in header microversion into client negotiation
- https://review.openstack.org/#/c/557850/
- Remaining Rescue patches
- https://review.openstack.org/#/c/499050/  - Fix ``agent`` deploy 
interface to call ``boot.prepare_instance``
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.) Needs to be rebased.
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/
- Bios interface support
- https://review.openstack.org/#/c/511162/
- https://review.openstack.org/#/c/528609/
- db api - https://review.openstack.org/#/c/511402/
- Bug fixes:
- https://review.openstack.org/#/c/556748
- House Keeping:
- https://review.openstack.org/#/c/557441/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
None
irmc:
None - a few works are work in progress

oneview:
None at this time - No subteam at present.

xclarity:
None at this time - No subteam at present.

Subproject priorities
-
bifrost:

ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- Stats (diff between  12 Mar 2018 and 19 Mar 2018)
- Ironic: 225 bugs (+14) + 250 wishlist items (+2). 15 new (+10), 152 in 
progress, 1 critical, 36 high (+3) and 26 incomplete (+2)
- Inspector: 15 bugs (+1) + 26 wishlist items. 1 new (+1), 14 in progress, 0 
critical, 3 high and 4 incomplete
- Nova bugs with Ironic tag: 14 (-1). 1 new, 0 critical, 0 high
- critical:
- sushy: https://bugs.launchpad.net/sushy/+bug/1754514 (basic auth broken 
when SessionService is not present)
- Queens backport release: https://review.openstack.org/#/c/558799/  
MERGED.
- the dashboard was abruptly deleted and needs a new home :(
- use it locally with `tox -erun` if you need to
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- status as of 16 April 2018:
- spec for deployment steps framework has merged: 
https://review.openstack.org/#/c/549493/
- waiting for code from rloo, no timeframe yet

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 16 April 2018:
- Spec has merged: https://review.openstack.org/#/c/496481/
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162
agreed that column type of bios setting value is string, blocked by the gate 
failure
- Add bios_interface db field https://review.openstack.org/528609   
   many +2s, can be merged soon after the patch above is merged
- BIOS Settings: Add DB API: https://review.openstack.org/511402
1x +1, actively reviewed and updated
- BIOS Settings: Add RPC object https://review.openstack.org/511714
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- (april 16) spec has good feedback, one issue to resolve, should be able to 
land this week
- https://review.openstack.org/#/c/559420/

Reference architecture guide (dtantsur, jroll)
--
- story: https://storyboard.openstack.org/#!/story/2001745

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Maybe we should consider unblocking the stable versions at the moment and then 
enabling us to address in each project. 

On 4/16/18, 5:34 PM, "Jeremy Stanley"  wrote:

On 2018-04-16 10:49:17 + (+), Gary Kotton wrote:
> We have seen that a number of stable projects that the sphinx docs
> is broken. The gate job returns ‘retry limit’. An example of the
> error is
> 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
> Does anyone have any idea how to address this?

Potential fixes seem to be adjusting the tools/tox_install.sh in
each of these projects to stop erroring when passed only a single
argument, or switch to relying on tox-siblings in those jobs so that
the neutron-horizon-hack role can be dropped from them entirely.
There is some discussion in https://review.openstack.org/561593 but
a centralized temporary workaround is somewhat risky since the
people in charge of reviewing any eventual revert will have a hard
time knowing when it's finally safe to do so.
-- 
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

Re: [openstack-dev] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Andrey Kurilin]

Hi Sean!

Thanks for raising this question.

As for Rally team, we are using self-tagging approach for several reasons:

- Release notes

  Check the difference between
https://github.com/openstack/nova/releases/tag/17.0.2 and
https://github.com/openstack/rally-openstack/releases/tag/1.0.0.
  The first one includes just autogenerated metadata. The second one
user-friendly notes (they are not ideal, but we are working on making them
better).
  I do not find a way to add custom release notes via openstack/releases
project.

- Time

  Self-tagging the repo allows me to schedule/reschedule the release in
whatever timeframe I decide without pinging anyone and waiting for folks to
return from summit/PTG.
  I do not want to offend anyone, but we all know that such events take
much time for preparation, holding and resting after it.

  Since there are no official OpenStack projects built on top of Rally,
launching any of "integration" jobs while making Rally release is a wasting
of time and money(resources).
  Also, such jobs can block to make a release. I remember sometimes it can
take weeks to pass all gates with tons of rechecks

  https://github.com/openstack/releases#release-approval == "Freezes and no
late releases". It is an opensource and I want to make releases on weekends
if there is any
  reason for doing this (critical fix or the last blocking feature is
merged or whatever).


2018-04-13 22:53 GMT+03:00 Sean McGinnis :

> On Fri, Apr 13, 2018 at 02:46:59PM -0500, Sean McGinnis wrote:
> > Hello teams,
> >
> > I am following up on some recently announced changes regarding governed
> > projects and tagging rights. See [1] for background.
> >
>
> [1] https://review.openstack.org/#/c/557737/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [sdk][osc][openstackclient] Migration to storyboard complete

[Kendall Nelson]

Hello Ben :)

As I've been the one poking at PTLs and doing most of the test migrations
I've been tracking the work here[1] on this StoryBoard board. There's a
story for it all too, but its much easier to see progress and status on the
board. If you or anyone has questions please ping me directly or in
#storyboard!

-Kendall Nelson (diablo_rojo)

[1] https://storyboard.openstack.org/#!/board/45

On Mon, Apr 16, 2018 at 10:18 AM Ben Nemec  wrote:

>
>
> On 04/14/2018 02:29 PM, Sean McGinnis wrote:
> > On Sat, Apr 14, 2018 at 11:37:46AM -0500, Monty Taylor wrote:
> >> Hey everybody,
> >>
> >> The migration of the openstacksdk and python-openstackclient
> repositories to
> >> storyboard has been completed. Each of the repos owned by those teams
> has
> >> been migrated, and project groups now also exist for each.
> >>
> >
> > I just noticed on python-openstackclient, in the repo's README file it
> still
> > points people to launchpad for bug and blueprint tracking.
> >
> > Just one more transition housekeeping item folks need to keep in mind
> when
> > making this switch.
>
> Has anybody been making a checklist as projects go through this process,
> and if not can we start on one?
>
> -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 Development Mailing 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] [sdk][osc][openstackclient] Migration to storyboard complete

[Ben Nemec]

On 04/14/2018 02:29 PM, Sean McGinnis wrote:

On Sat, Apr 14, 2018 at 11:37:46AM -0500, Monty Taylor wrote:

Hey everybody,

The migration of the openstacksdk and python-openstackclient repositories to
storyboard has been completed. Each of the repos owned by those teams has
been migrated, and project groups now also exist for each.



I just noticed on python-openstackclient, in the repo's README file it still
points people to launchpad for bug and blueprint tracking.

Just one more transition housekeeping item folks need to keep in mind when
making this switch.


Has anybody been making a checklist as projects go through this process, 
and if not can we start on one?


-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

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Jeremy Stanley]

On 2018-04-16 10:49:17 + (+), Gary Kotton wrote:
> We have seen that a number of stable projects that the sphinx docs
> is broken. The gate job returns ‘retry limit’. An example of the
> error is
> http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
> Does anyone have any idea how to address this?

Potential fixes seem to be adjusting the tools/tox_install.sh in
each of these projects to stop erroring when passed only a single
argument, or switch to relying on tox-siblings in those jobs so that
the neutron-horizon-hack role can be dropped from them entirely.
There is some discussion in https://review.openstack.org/561593 but
a centralized temporary workaround is somewhat risky since the
people in charge of reviewing any eventual revert will have a hard
time knowing when it's finally safe to do so.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [devstack][infra] pip vs psutil

[Jens Harbott]

2018-04-16 7:46 GMT+00:00 Ian Wienand :
> On 04/15/2018 09:32 PM, Gary Kotton wrote:
>>
>> The gate is currently broken with
>>  https://launchpad.net/bugs/1763966.
>> https://review.openstack.org/#/c/561427/
>>  Can unblock us in the short term. Any other ideas?
>
>
> I'm thinking this is probably along the lines of the best idea.  I
> left a fairly long comment on this in [1], but the root issue here is
> that if a system package is created using distutils (rather than
> setuptools) we end up with this problem with pip10.
>
> That means the problem occurs when we a) try to overwrite a system
> package and b) that package has been created using distutils.  This
> means it is a small(er) subset of packages that cause this problem.
> Ergo, our best option might be to see if we can avoid such packages on
> a one-by-one basis, like here.
>
> In some cases, we could just delete the .egg-info file, which is
> approximately what was happening before anyway.
>
> In this particular case, the psutils package is used by glance & the
> peakmem tracker.  Under USE_PYTHON3, devstack's pip_install_gr only
> installs the python3 library; however the peakmem tracker always uses
> python2 -- leaing to missing library the failures in [2].  I have two
> thoughts; either install for both python2 & 3 always [3] or make
> peakmem tracker obey USE_PYTHON3 [4].  We can discuss the approach in
> the reviews.
>
> The other option is to move everything to virtualenv's, so we never
> conflict with a system package, as suggested by clarkb [5] or
> pabelanger [6].  These are more invasive changes, but also arguably
> more correct.
>
> Note diskimage-builder, and hence our image generation for some
> platforms, is also broken.  Working on that in [7].

The cap in devstack has been merged in master and stable/queens, other
merges are being help up by unstable volume checks or so it seems.

There is also another issue caused by pip 10 treating some former
warning as error now. I've tried to list all "global" (Infra+QA)
related issues in [8], feel free to amend as needed.

[8] https://etherpad.openstack.org/p/pip10-mitigation

__
OpenStack Development Mailing 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] [election][tc] TC Candidacy for Graham Hayes

[Graham Hayes]

Hi,

I am submitting my candidacy for the OpenStack Technical Committee.

I have been contributing to OpenStack since the Havana cycle [1][2],
mainly in
Designate. I have also been involved with the TC, and its meetings since
Designate applied for incubation all the way back in Atlanta (the first time
we were there).

Over the last 6 months I have become more involved in the TC, and have been
an active contributor to TC discussions (both on IRC and in person) and
governance [3].

I have been PTL for Designate for Mitaka, Newton, Ocata, Queens and Rocky
cycles, and a core for a longer period. I believe my experience working in a
younger, smaller project within OpenStack is a benefit. Along with the
experience of working on software as an end user of OpenStack I can help us
ensure the Technical Committee is mindful of the unique challenges these
projects and users can face.

With the broadening of the scope of the OpenStack Foundation, I believe that
it is an important part of the TC's role to have robust, and frank
discussions
with the Board of Directors and I believe that I have done a reasonable
job of
summarizing [4][5] what happens at the Board of Directors meetings to the
community over the last 6 months.

The need for the candid discussions is not restricted to the Foundation
and the
board - the new strategic focus areas that the foundation is expanding into
need our technical leadership to engage with them and ensure that we are all
working towards the overall goal of the foundation and promoting open
infrastructure. We need to make collaborating, and sharing resources and
expertise where it makes sense a priority.

What it does not mean is changing what OpenStack is nor changing
OpenStack to
cater for a single use case. This is a situation where better education
of how
OpenStack and it components can be used and orchestrated is needed, and
a lot
of this work should be directed by the TC. I don't think the TC will
always (or
even most of the time) be the correct people to engage, but I think we
should
lead the way by finding the correct people with the knowledge and
experience,
and helping support them and provide them with a platform to provide
guidance
to these groups.

When it comes to pushing forward the TC vision[6] I think the community has
made great steps forward to realizing it, on all but one section. We engage
with groups like the CNCF, and specifically Kubernetes and help drive
OpenStack
adoption with first class support for the OpenStack Cloud Provider, the
Cinder
Container Storage Interface and other projects. We still need to find a
way to
show the world what a top tier private open source infrastructure of
components
like OpenStack, Kubernetes, Cloud Foundry or OpenShift looks like, and
helping
companies understand why this is the way forward for their infrastructure.

Unfortunately, helping users, deployers and C(T|I)Os understand this
would be
easier with well written and and clearly documented "constellations" - I
have
always found talking in the abstract is a lot more difficult than discussing
something tangible. For the last 5 years I have worked on product teams
building products based on OpenStack, Kubernetes and Cloud Foundry, and
I think
this experience will be a great asset in developing our first generation of
constellations, which is something I think we need to focus on for the next
term of the TC.

I think that having constellations will also help us solve the perennial
question of what OpenStack is. By having sets of projects, we can show that
OpenStack is extremely flexible - and that there are projects for
different use
cases. Far too much time is spent circling back to the "What is OpenStack" -
which I foresee getting even more complex as the OpenStack Foundation grows
beyond the OpenStack Project, and having a solid, stable answer to what
we are
is going to be vital.

I would like to thank you for taking the time to read my thoughts - and ask
you to consider me for your vote. If elected I will strive to be vocal
for the
community that I have gotten so much from. I want to give some more back to
them ensure that the OpenStack Project continues to be the go to
software for
Infrastructure as a Service.

Thanks again,

 - Graham


1 - http://stackalytics.com/?release=all=commits_id=grahamhayes
2 - https://www.openstack.org/community/members/profile/12766/graham-hayes
3 -
https://review.openstack.org/#/q/project:openstack/governance+(commentby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22+OR+reviewedby:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22++OR+owner:%22Graham+Hayes+%253Cgr%2540ham.ie%253E%22)
4 -
http://graham.hayes.ie/posts/dublin-ptg-summary/#board-of-directors-meeting
5 -
http://graham.hayes.ie/posts/sydney-openstack-summit/#sunday-board-joint-leadership-meeting
6 -
https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html



signature.asc
Description: OpenPGP digital signature

[openstack-dev] [Os-brick][Cinder] NVMe-oF NQN string

[Szwed, Maciej]

Hi,
I'm wondering why in Os-brick implementation of NVMe-oF in 
os_brick/initiator/connectors/nvme.py, line 97 we do split on 'nqn'. Connection 
properties, including 'nqn', are provided by Cinder driver and when user want 
to implement new driver that will use NVMe-of he/she needs to create NQN string 
with additional string and dot proceeding the desired NQN string. This 
additional string is unused across whole NVMe-oF implementation. This creates 
confusion for people when creating new Cinder driver. What was its purpose? Can 
we drop that split?

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

[openstack-dev] [nova] Notification update week 16

[Balázs Gibizer]

Hi,

After the long silence here is the current notification status info.

Bugs


New bugs


[Low] https://bugs.launchpad.net/nova/+bug/1757407 Notification sending 
sometimes hits the keystone API to get glance endpoints
As the versioned notifications does not use the glance endpoints info 
we can avoid hitting the keystone API if notification_format is set to 
'versioned'



[Medium] https://bugs.launchpad.net/nova/+bug/1763051 Need to audit 
when notifications are sent during live migration
We need to go throught the live migration codepath and make sure that 
the different live migartion notifications sent at a proper time.



[Low] https://bugs.launchpad.net/nova/+bug/1761405 impossible to 
disable notifications
The way to turn off emitting notification from nova is to set the 
oslo_messaging_notifications.driver config option to 'noop'. We need to 
document this better in the notification devref and in the 
notification_format config option.



There are two follow up bugs opened based on the Matt's review comments 
in https://review.openstack.org/#/c/403660:


[Low] https://bugs.launchpad.net/nova/+bug/1764390 Replace passing 
system_metadata to notification functions with instance.system_metadata 
usage


[Low] https://bugs.launchpad.net/nova/+bug/1764392 Avoid bandwidth 
usage db query in notifications when the virt driver does not support 
collecting such data



Old bugs


[High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when
sending notification during attach_interface
Fix merged to most of the stable branches. The backport for ocata is 
still open but has +2 from Tony.

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

[High] https://bugs.launchpad.net/nova/+bug/1739325 Server operations
fail to complete with versioned notifications if payload contains unset
non-nullable fields
No progress. We still need to understand how this problem happens to
find the proper solution.

[Low] https://bugs.launchpad.net/nova/+bug/1487038
nova.exception._cleanse_dict should use
oslo_utils.strutils._SANITIZE_KEYS
Old abandoned patches exist but need somebody to pick them up:
* https://review.openstack.org/#/c/215308/
* https://review.openstack.org/#/c/388345/


Versioned notification transformation
-
https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-rocky+status:open

There are some patches that only needs a second +2:
* https://review.openstack.org/#/c/460625 Transform 
aggregate.update_metadata notification
* https://review.openstack.org/#/c/403660 Transform instance.exists 
notification


Introduce instance.lock and instance.unlock notifications
-
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
Implementation proposed but needs some work: 
https://review.openstack.org/#/c/526251/



Add the user id and project id of the user initiated the instance
action to the notification
-
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
Implementation patch exists but still needs work 
https://review.openstack.org/#/c/536243/



Add request_id to the InstanceAction versioned notifications

https://blueprints.launchpad.net/nova/+spec/add-request-id-to-instance-action-notifications
Implemenation needs a rebase and review 
https://review.openstack.org/#/c/553288/



Sending full traceback in versioned notifications
-
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications
I have to propose the implementation.

Add versioned notifications for removing a member from a server group
-
The specless bp
https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications
is pending approval as we would like to see the POC code first. Takashi 
has been proposed the POC code https://review.openstack.org/#/c/559076/ 
so we have to look at it.



Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
Kevin proposed a lot of patches. \o/ Now I have to go and review them.

Weekly meeting
--
The next meeting will be held on 17th of April on #openstack-meeting-4
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180417T17

Cheers,
gibi




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

[openstack-dev] [nova][xenapi] does get_all_bw_counters driver call nova-network only?

[Balázs Gibizer]

Hi,

The get_all_bw_counters() virt driver [1] is only supported by xenapi 
today. However Matt raised the question [2] if this is a nova-network 
only feature. As in that case we can simply remove it.


Cheers,
gibi

[1] 
https://github.com/openstack/nova/blob/68afe71e26e60a3e4ad30083cc244c57540d4da9/nova/virt/xenapi/driver.py#L383
[2] 
https://review.openstack.org/#/c/403660/78/nova/compute/manager.py@6855





__
OpenStack Development Mailing 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][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
Here is an example - https://review.openstack.org/#/c/560893/
Thanks
Gary

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Monday, April 16, 2018 at 2:28 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] 
Stable/queens build sphinx docs broken

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List 
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing 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][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List 
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing 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][dynamic routing] RYU Breaks lower constraints

[Slawomir Kaplonski]

I just sent a patch to bump Ryu version in Neutron’s requirements to fix lower 
constraints job there also: https://review.openstack.org/#/c/561579/


> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
> o godz. 09:13:
> 
> Please see https://review.openstack.org/561443
> 
> On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro"  wrote:
> 
>On Sun, 15 Apr 2018 21:02:42 +0900,
>Gary Kotton wrote:
>> 
>> [1  ]
>> [1.1  ]
>> Hi,
>> That sounds reasonable. I wonder if the RYU folk can chime in here.
>> Thanks
> 
>I don't fully understand the recent g-r change yet, but
>I guess neutron-dynamic-routing should  also have ryu>=4.24.
>I'll check this tommorrow.
> 
>> From: Akihiro MOTOKI 
>> Reply-To: OpenStack List 
>> Date: Sunday, April 15, 2018 at 12:43 PM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower 
>> constraints
>> 
>> Gary,
>> 
>> I think this is caused by the recent pip change and pip no longer cannot 
>> import pip from code. The right solution seems to bump the minimum version 
>> of ryu.
>> 
>> Thought?
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html
>> 
>> Akihiro
>> 
>> 2018/04/15 午後6:06 "Gary Kotton" 
>> >:
>> Hi,
>> It seems like ther RYU import is breaking the project:
>> 
>> 
>> 2018-04-15 
>> 08:41:34.654681
>>  | ubuntu-xenial | b'--- import errors ---\nFailed to import test module: 
>> neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
>>  (most recent call last):\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>  line 456, in _find_test_path\nmodule = 
>> self._get_module_from_name(name)\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>  line 395, in _get_modu
> le_from_name\n__import__(name)\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py",
>  line 21, in \nfrom ryu.services.protocols.bgp import 
> bgpspeaker\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py",
>  line 21, in \nfrom ryu.lib.packet.bgp import (\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py 
> ower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py>", 
> line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6, ipv4, 
> ipv6, lldp, mpls, packet,\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py",
>  line 18, in \nfrom . import vlan\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/vlan.py",
>  line 21, in \nfrom . import ipv4\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py 
> ttp://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py>",
>  line 23, in \nfrom . import tcp\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/tcp.py",

Re: [openstack-dev] [kolla][stable][tc] Kolla deployment guide link is missing on docs.o.o

[Jeffrey Zhang]

Thanks Andreas,

patch is pushed, please check https://review.openstack.org/#/c/561578/

On Mon, Apr 16, 2018 at 6:02 PM, Andreas Jaeger  wrote:

> On 2018-04-16 11:52, Jeffrey Zhang wrote:
> > Seems kolla deployment guide doc link is missing here[0]. But it exists
> > on pike[1] and ocata[2]
> >
> > How could we fix this?
>
> See https://docs.openstack.org/doc-contrib-guide/doc-index.html and sent
> a patch for openstack-manuals repository,
>
> Andreas
>
> > [0] https://docs.openstack.org/queens/deploy/
> > [1] https://docs.openstack.org/pike/deploy/
> > ​[2] https://docs.openstack.org/ocata/deploy/​
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me 
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [kolla][stable][tc] Kolla deployment guide link is missing on docs.o.o

[Andreas Jaeger]

On 2018-04-16 11:52, Jeffrey Zhang wrote:
> Seems kolla deployment guide doc link is missing here[0]. But it exists
> on pike[1] and ocata[2]
> 
> How could we fix this?

See https://docs.openstack.org/doc-contrib-guide/doc-index.html and sent
a patch for openstack-manuals repository,

Andreas

> [0] https://docs.openstack.org/queens/deploy/
> [1] https://docs.openstack.org/pike/deploy/
> ​[2] https://docs.openstack.org/ocata/deploy/​
> 
> -- 
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


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

Re: [openstack-dev] Removing networking-mlnx from Debian?

[Moshe Levi]

What are the python3 issues that you see?

tox -epy34 and all the unit test are passing? (tested on cento 7.4) 



[1] 
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_processing_network
 2.642
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network_filter_phynset
  2.572
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_config_dont_update
  2.310
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_port_deleted_port
   2.291
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_port_non_migration
  2.252
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_delete_pending_port_update
 2.250
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_filter_phynset
 2.237
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_driver
  2.201
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network_update_pending_network_create
   2.135
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network
 1.981
__
 summary 
___
  py34: commands succeeded
  congratulations :)



> -Original Message-
> From: Moshe Levi
> Sent: Friday, April 13, 2018 5:14 PM
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: RE: [openstack-dev] Removing networking-mlnx from Debian?
> 
> Hi Thomas,
> 
> Networking-mlnx is still maintained.
> We will fix all the issues next week and I will create a tag for it.
> 
> > -Original Message-
> > From: Thomas Goirand [mailto:z...@debian.org]
> > Sent: Friday, April 13, 2018 2:50 PM
> > To: OpenStack Development Mailing List  > d...@lists.openstack.org>
> > Subject: [openstack-dev] Removing networking-mlnx from Debian?
> >
> > Hi,
> >
> > Is networking-mlnx actively maintained? It doesn't look like it to me,
> > there's still no Queens release. It also fails to build in Debian,
> > with apparently no Python 3 support.
> >
> > Without any reply from an active maintainer, I'll ask for this package
> > to be removed from Debian.
> >
> > Please let me know,
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> >
> __
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> > openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> >
> dev=02%7C01%7Cmoshele%40mellanox.com%7C7cb48464a3b24d0fc10
> >
> e08d5a134b5a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6365
> >
> 92171104919078=BFuUnC5qJWNm0J7WPZtosLJeuww%2BVwc4s%2Bu
> > rIaF3jbQ%3D=0
__
OpenStack Development Mailing 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] [kolla][stable][tc] Kolla deployment guide link is missing on docs.o.o

[Jeffrey Zhang]

Seems kolla deployment guide doc link is missing here[0]. But it exists on
pike[1] and ocata[2]

How could we fix this?

[0] https://docs.openstack.org/queens/deploy/
[1] https://docs.openstack.org/pike/deploy/
​[2] https://docs.openstack.org/ocata/deploy/​

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

[openstack-dev] [glance] Priorities for WC 16th of April

[Erno Kuvaja]

Hi all,

Now when client release is out and milestone 1 is approaching quickly
I'd like to draw your attention to few things in Glance development.

1) reviews of outstanding specs
2) work towards removal of the Images API v1
3) Pending delete rollback ability

Lets get the reviews to specs so we have clear picture by the summit
next month what we are doing, work towards removing the Images API v1
endpoints as early as possible so we avoid nasty surprises at the end
of the cycle and get the first new features merged in.

Thanks all for your continuous support driving towards another great
Glance release!

- Erno -jokke- Kuvaja

__
OpenStack Development Mailing 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] [horizon] Meeting time and location are changed

[Ivan Kolodyazhny]

Hi team,

Please be informed that Horizon meeting time has been changed [1]. We'll
have our weekly meetings at 15.00 UTC starting this week at
'openstack-meeting-alt' channel. We had to change meeting channel too due
to the conflict with others.


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

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.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

[openstack-dev] [bandit] Migration to PyCQA

[Luke Hinds]

Hi All,

As most of you are aware, a decision was made to migrate the maintenance of
Bandit to PyCQA [0].

In order to kick things off, I have started a pad [1] to make sure we
capture all the steps needed for a seamless migration.

Please do look at this and provide input / feedback. @Jeremy, including you
for the zuul side of things.

We will start covering this as a topic each Thursday on the security-sig
meeting, until we are confident to 'hit the button' and move the project
over.

[0] https://github.com/PyCQA
[1] https://etherpad.openstack.org/p/bandit-migration

Please be mindful of including Ian on replies, who may not be subscribed
the the -dev list.

-- 
Luke Hinds
__
OpenStack Development Mailing 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] [stable][trove] keep trove-stable-maint members up-to-date

[赵超]

Hi , core stable team,

There are some patches to stable branches to the different trove repos, and
they are always progressing slowly ,because none of the current trove team
core members are in the trove-stable-maint. I tried to contact with the
previous PTLs about expanding the 'trove-stable-maint' group and keep the
group up-to-date, however got no response yet.

I noticed that 'stable-maint-core' is always included in the individual
project -stable-maint group, could the core stable team help to update the
'trove-stable-maint' group (adding me to it could be sufficient by now)?

Thanks!

-- 
To be free as in freedom.
__
OpenStack Development Mailing 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] [devstack][infra] pip vs psutil

[Ian Wienand]

On 04/15/2018 09:32 PM, Gary Kotton wrote:

The gate is currently broken with
 https://launchpad.net/bugs/1763966. https://review.openstack.org/#/c/561427/
 Can unblock us in the short term. Any other ideas?


I'm thinking this is probably along the lines of the best idea.  I
left a fairly long comment on this in [1], but the root issue here is
that if a system package is created using distutils (rather than
setuptools) we end up with this problem with pip10.

That means the problem occurs when we a) try to overwrite a system
package and b) that package has been created using distutils.  This
means it is a small(er) subset of packages that cause this problem.
Ergo, our best option might be to see if we can avoid such packages on
a one-by-one basis, like here.

In some cases, we could just delete the .egg-info file, which is
approximately what was happening before anyway.

In this particular case, the psutils package is used by glance & the
peakmem tracker.  Under USE_PYTHON3, devstack's pip_install_gr only
installs the python3 library; however the peakmem tracker always uses
python2 -- leaing to missing library the failures in [2].  I have two
thoughts; either install for both python2 & 3 always [3] or make
peakmem tracker obey USE_PYTHON3 [4].  We can discuss the approach in
the reviews.

The other option is to move everything to virtualenv's, so we never
conflict with a system package, as suggested by clarkb [5] or
pabelanger [6].  These are more invasive changes, but also arguably
more correct.

Note diskimage-builder, and hence our image generation for some
platforms, is also broken.  Working on that in [7].

-i


[1] https://github.com/pypa/pip/issues/4805#issuecomment-340987536
[2] https://review.openstack.org/561427
[3] https://review.openstack.org/561524
[4] https://review.openstack.org/561525
[5] https://review.openstack.org/558930
[6] https://review.openstack.org/#/c/552939
[7] https://review.openstack.org/#/c/561479/

__
OpenStack Development Mailing 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] [devstack][infra] pip vs psutil

[Slawomir Kaplonski]

Right. Thx Gary :)

> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
> o godz. 09:14:
> 
> Hi,
> I think that we need https://review.openstack.org/561471 until we have a 
> proper solution.
> Thanks
> Gary
> 
> On 4/16/18, 10:13 AM, "Slawomir Kaplonski"  wrote:
> 
>Hi,
> 
>I just wanted to ask if there is any ongoing work on 
> https://bugs.launchpad.net/devstack/+bug/1763966 to fix grenade failures? It 
> looks that e.g. all grenade jobs in neutron are broken currently :/
> 
>> Wiadomość napisana przez Gary Kotton  w dniu 15.04.2018, 
>> o godz. 13:32:
>> 
>> Hi,
>> The gate is currently broken with https://launchpad.net/bugs/1763966. 
>> https://review.openstack.org/#/c/561427/ Can unblock us in the short term. 
>> Any other ideas?
>> Thanks
>> Gary
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>— 
>Best regards
>Slawek Kaplonski
>skapl...@redhat.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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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] [devstack][infra] pip vs psutil

[Gary Kotton]

Hi,
I think that we need https://review.openstack.org/561471 until we have a proper 
solution.
Thanks
Gary

On 4/16/18, 10:13 AM, "Slawomir Kaplonski"  wrote:

Hi,

I just wanted to ask if there is any ongoing work on 
https://bugs.launchpad.net/devstack/+bug/1763966 to fix grenade failures? It 
looks that e.g. all grenade jobs in neutron are broken currently :/

> Wiadomość napisana przez Gary Kotton  w dniu 
15.04.2018, o godz. 13:32:
> 
> Hi,
> The gate is currently broken with https://launchpad.net/bugs/1763966. 
https://review.openstack.org/#/c/561427/ Can unblock us in the short term. Any 
other ideas?
> Thanks
> Gary
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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] [neutron][dynamic routing] RYU Breaks lower constraints

[Gary Kotton]

Please see https://review.openstack.org/561443

On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro"  wrote:

On Sun, 15 Apr 2018 21:02:42 +0900,
Gary Kotton wrote:
> 
> [1  ]
> [1.1  ]
> Hi,
> That sounds reasonable. I wonder if the RYU folk can chime in here.
> Thanks

I don't fully understand the recent g-r change yet, but
I guess neutron-dynamic-routing should  also have ryu>=4.24.
I'll check this tommorrow.

> From: Akihiro MOTOKI 
> Reply-To: OpenStack List 
> Date: Sunday, April 15, 2018 at 12:43 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower 
constraints
> 
> Gary,
> 
> I think this is caused by the recent pip change and pip no longer cannot 
import pip from code. The right solution seems to bump the minimum version of 
ryu.
> 
> Thought?
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html
> 
> Akihiro
> 
> 2018/04/15 午後6:06 "Gary Kotton" 
>:
> Hi,
> It seems like ther RYU import is breaking the project:
> 
> 
> 2018-04-15 
08:41:34.654681
 | ubuntu-xenial | b'--- import errors ---\nFailed to import test module: 
neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
 (most recent call last):\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
 line 456, in _find_test_path\nmodule = self._get_module_from_name(name)\n  
File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
 line 395, in _get_modu
 le_from_name\n__import__(name)\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py",
 line 21, in \nfrom ryu.services.protocols.bgp import bgpspeaker\n  
File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py",
 line 21, in \nfrom ryu.lib.packet.bgp import (\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py", 
line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6, ipv4, 
ipv6, lldp, mpls, packet,\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py",
 line 18, in \nfrom . import vlan\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/vlan.py",
 line 21, in \nfrom . import ipv4\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py",
 line 23, in \nfrom . import tcp\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/tcp.py",
 line 24, in \nfrom . import bgp\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/bgp.py",
 line 52, in \nfrom ryu.utils import binary_str\n  File 

Re: [openstack-dev] [devstack][infra] pip vs psutil

[Slawomir Kaplonski]

Hi,

I just wanted to ask if there is any ongoing work on 
https://bugs.launchpad.net/devstack/+bug/1763966 to fix grenade failures? It 
looks that e.g. all grenade jobs in neutron are broken currently :/

> Wiadomość napisana przez Gary Kotton  w dniu 15.04.2018, 
> o godz. 13:32:
> 
> Hi,
> The gate is currently broken with https://launchpad.net/bugs/1763966. 
> https://review.openstack.org/#/c/561427/ Can unblock us in the short term. 
> Any other ideas?
> Thanks
> Gary
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks for the question and comments

>>> metadata service question
Fully agree metadata is something that we need support, and as it need some
network setup on NAT ,as you pointed out, without metadata there are some
functions missing ; so it's already in our support plan , currently we plan
to use config drive and later (with the enhance with our neutron support as
well) to support metadata service

>>>The "iso file" will not be inside the guest, but rather passed to the
guest as a block device, right?
Cloud init  expects to find a config drive with following requirements [1],
in order to make cloud init able to consume config drive , we should be
able to prepare it,
in some hypervisor, you can define something like following to the VM then
VM startup is able to consume it

but for z/VM case it allows disk to be created during VM create
(define )stage but no disk format set, it's the operating system's
responsibility to define the purpose of the
disk, so what we do is
1) first when we build image ,we create a small AE like cloud-init but only
purpose is to get files from z/VM internal pipe and handle config drive
case
2) During spawn we create config drive in nova-compute side then send the
file to z/VM through z/VM internal pipe (omit detail here)
3) During startup of the virtual machine, the small AE is able to mount the
file as loop device and then in turn cloud-init is able to handle it

because this is our special case, we don't want to upload to cloud-init
community because of uniqueness and as far as we can tell, no hook in
cloud-init mechanism allowed as well
to let us 'mount -o loop' ; also, from openstack point of view except this
small AE (which is documented well) no special thing and inconsistent to
other drivers

[1]
https://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceConfigDrive.py#L225

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Dan Smith 
To: "Chen CH Ji" 
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   04/13/2018 09:46 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



> for the run_validation=False issue, you are right, because z/VM driver
> only support config drive and don't support metadata service ,we made
> bad assumption and took wrong action to disabled the whole ssh check,
> actually according to [1] , we should only disable
> CONF.compute_feature_enabled.metadata_service but keep both
> self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
> order to make config drive test validation take effect, our CI will
> handle that

Why don't you support the metadata service? That's a pretty fundamental
mechanism for nova and openstack. It's the only way you can get a live
copy of metadata, and it's the only way you can get access to device
tags when you hot-attach something. Personally, I think that it's
something that needs to work.

> For the tgz/iso9660 question below, this is because we got wrong info
> from low layer component folks back to 2012 and after discuss with
> some experts again, actually we can create iso9660 in the driver layer
> and pass down to the spawned virtual machine and during startup
> process, the VM itself will mount the iso file and consume it, because
> from linux perspective, either tgz or iso9660 doesn't matter , only
> need some files in order to transfer the information from openstack
> compute node to the spawned VM.  so our action is to change the format
> from tgz to iso9660 and keep consistent to other drivers.

The "iso file" will not be inside the guest, but rather passed to the
guest as a block device, right?

> For the config drive working mechanism question, according to [2] z/VM
> is Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2
> hypervisor, there is no file system in z/VM hypervisor (I omit too
> much detail here) , so we can't do something like linux operation
> system to keep a file as qcow2 image in the host operating system,

I'm not sure what the type-1-ness has to do with this. The hypervisor
doesn't need to support any specific filesystem for this to work. Many
drivers we have in the tree are type-1 (xen, vmware, hyperv, powervm)
and you can argue that KVM is type-1-ish. They support configdrive.

> what we do is use a special file pool to store the config drive and
> during VM init process, we read that file from special device and
> attach to VM as iso9660 format then cloud-init will handle the follow
> up, the cloud-init handle process is identical to other platform

This and the previous mention of this sort of behavior has me
concerned. Are you describing some sort of process