Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Nachi Ueno]

Hi  Russell

Your tool is awesome.
I have also two idea (I believe it's not crazy :P ).

1) Show LOC of the review
Long patch takes long time..

2) Show priority of the review
If it shows priority of the review, it wil be more useful, because
we should work on the order of the priorities.
The priority of the patch can be defined by related bug report or blueprint.
(It is also awesome, if the Gerrit shows this priority )

Best
Nachi

2013/6/28 Monty Taylor :
>
>
> On 06/28/2013 05:43 PM, Russell Bryant wrote:
>> On 06/28/2013 03:44 PM, Boris Pavlovic wrote:
>>> Russell,
>>>
>>> I have some crazy Idea, about how to make reviewing more stable.
>>> And how to avoid old patches at all.
>>>
>>> "Old" means that last update was more then N days ago.
>>>
>>> If there are patches that are older then N days:
>>> we just hide "review" button for all patches except old patches.
>>> When they are reviewed we return our button back. =)
>>
>> Heh, yes, that is a crazy idea.
>>
>> If a critical bug fix or a security patch is posted, we need to be able
>> to review it ASAP.
>>
>> Not all patches are equal ... some things take longer because they are
>> bigger, more complex, or for some other reason harder to review.  In
>> many cases, not *all* of nova-core is qualified or comfortable with
>> reviewing a given change.  They should still be able to reivew the
>> patches appropriate for them.
>
> At the infra bootcamp we just finished, we had the crazy idea that if
> the review queue's total size passed a threshold, the project should
> block submission of new patches until the queue decreased in size again.
>
> I also think this is a terrible idea - but I thought I'd toss it out
> there to let people see what happens when you put a bunch of dev
> infra-minded people in a New York Loft in the summer...
>
> Monty
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

[Anne Gentle]

On Fri, Jun 28, 2013 at 7:31 AM, Christopher Yeoh  wrote:

> Hi,
>
> The following is a list of API extensions for which there are no plans to
> port. Please shout if you think any of them needs to be!
>

What does "no plans to port" mean for people already using Floating IPs and
Cloudpipe via API extensions? Sounds like it could mean a couple of things
-
- these are becoming core and won't be an extension any more
- these won't be available in v3
- something else

Also should you cast a wider net asking for feedback on this removal (if it
is a removal)? I know openstack-dev is about the future but there may be
more ways to get input.

Thanks,
Anne


>
> baremetal_nodes.py
> os_networks.py
> networks_associate.py
> os_tenant_networks.py
> virtual_interfaces.py
> createserverext.py
> floating_ip_dns.py
> floating_ip_pools.py
> floating_ips_bulk.py
> floating_ips.py
> cloudpipe.py
> cloudpipe_update.py
> volumes.py
>
> Also I'd like to propose that after H2 any new API extension submitted HAS
> to have a v3 version. That will give us enough time to ensure that the V3
> API in Havana can do everything that the V2 one except where we explicitly
> don't want to support something.
>
> For developers who have had new API extensions merged in H2 but haven't
> submitted a v3 version, I'd appreciate it if you could check the following
> etherpad to see if your extension is on the list and put it on there ASAP
> if it isn't there already:
>
> https://etherpad.openstack.org/NovaV3ExtensionPortWorkList
>
> I've tried to keep track of new API extensions to make sure we do v3 ports
> but may have missed some.
>
> Chris
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Anne Gentle
annegen...@justwriteclick.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Monty Taylor]

On 06/28/2013 05:43 PM, Russell Bryant wrote:
> On 06/28/2013 03:44 PM, Boris Pavlovic wrote:
>> Russell, 
>>
>> I have some crazy Idea, about how to make reviewing more stable. 
>> And how to avoid old patches at all. 
>>
>> "Old" means that last update was more then N days ago.
>>
>> If there are patches that are older then N days:
>> we just hide "review" button for all patches except old patches.
>> When they are reviewed we return our button back. =)
> 
> Heh, yes, that is a crazy idea.
> 
> If a critical bug fix or a security patch is posted, we need to be able
> to review it ASAP.
> 
> Not all patches are equal ... some things take longer because they are
> bigger, more complex, or for some other reason harder to review.  In
> many cases, not *all* of nova-core is qualified or comfortable with
> reviewing a given change.  They should still be able to reivew the
> patches appropriate for them.

At the infra bootcamp we just finished, we had the crazy idea that if
the review queue's total size passed a threshold, the project should
block submission of new patches until the queue decreased in size again.

I also think this is a terrible idea - but I thought I'd toss it out
there to let people see what happens when you put a bunch of dev
infra-minded people in a New York Loft in the summer...

Monty

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core

[Armando Migliaccio]

I think he's got enough +1...but here's mine:

+1

On Thu, Jun 27, 2013 at 3:10 AM, Bob Ball  wrote:

> +1 from me too.
> 
> From: Russell Bryant [rbry...@redhat.com]
> Sent: 26 June 2013 16:09
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
>
> Greetings,
>
> I would like to nominate John Garbutt for the nova-core team.
>
> John has been involved with nova for a long time now.  He's primarily
> known for his great work on the xenapi driver.  However, he has been
> contributing and reviewing in other areas, as well.  Based on my
> experience with him I think he would be a good addition, so it would be
> great to have him on board to help keep up with the review load.
>
> Please respond with +1s or any concerns.
>
> References:
>
>   https://review.openstack.org/#/dashboard/782
>
>   https://review.openstack.org/#/q/reviewer:782,n,z
>
>   https://launchpad.net/~johngarbutt/+specs?role=assignee
>
>   https://launchpad.net/~johngarbutt/+bugs?role=assignee
>
> Thanks,
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Allocation of IPs

[Edgar Magana]

Actually, the implementation for that method in our case will just simple
return an empty value (if that is possible) because I can't tale which IP
address the DHCP will assign.
I could tell the DHCP server which IP assign to the specific MAC but I could
not have that kind of functionality.
After the booting process, I could have a post configuration process being
trigger to get the IP address from the DHCP but not sure about that
approach..

Anyway, Armando point is very interesting.
I think some BPs on IP allocation already cover alternative solutions.

Edgar

From:  Armando Migliaccio 
Reply-To:  OpenStack List 
Date:  Friday, June 28, 2013 2:50 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

I guess the other question is: is this the right approach?

I think your use case may be beneficial to other plugins, so in my view
having a plugin-specific override is not the best fit.

On Fri, Jun 28, 2013 at 2:42 PM, Edgar Magana  wrote:
> Got it!!!  I knew it could be possible..
> 
> Thanks,
> 
> Edgar
> 
> From:  Aaron Rosen 
> Reply-To:  OpenStack List 
> Date:  Friday, June 28, 2013 2:19 PM
> 
> To:  OpenStack List 
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> Gotcha, The part that was confusing was:
> 
>> >Could it be possible to add a flag to disable the allocation for the IP?
>> >If the "no allocation" flag is enabled, all ports will have an empty value
>> for IPs.
> 
> So what you are looking to do is to provide the IP address from the plugin and
> not the db_base class it seems?  In this case all you need to do is implement:
> 
> _allocate_ips_for_port() in your plugin and then that method will be called
> instead of the base class one.
> 
> Aaron
> 
> 
> 
> On Fri, Jun 28, 2013 at 12:48 PM, Edgar Magana  wrote:
>> Aaron,
>> 
>> You are totally right, the point is that I don't want to loose the IPAM info
>> in Neutron because that is the moment when the backend plugin deploys a new
>> DHCP server into the Virtual Networking Infrastruture. So, every time that a
>> user creates a subnet and enables DHCP our plugin deploys a new DHCP service.
>> 
>> I am sure that is me the one missing something!!!   :-)
>> 
>> Thanks,
>> 
>> Edgar
>> 
>> From:  Aaron Rosen 
>> Reply-To:  OpenStack List 
>> Date:  Friday, June 28, 2013 12:07 PM
>> 
>> To:  OpenStack List 
>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> Hi Edgar, 
>> 
>> I'm still not following. In your original question you asked how to you
>> create a port and not allocate an ip address to it at all so that you can
>> leverage a real dhcp server to do that. In order to do that you can create a
>> network without a subnet but then you loose the ipam info in quantum. Or
>> write a script that notifies your dhcp server the mac-ip bindings each
>> instance should have.  Am i missing something here?
>> 
>> Thanks,
>> 
>> Aaron
>> 
>> 
>> On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana  wrote:
>>> Aaron,
>>> 
>>> Because the create create_subnet API is the one that enables/disables the
>>> DHCP:
>>> quantum subnet-create--enable_dhcp False
>>> 
>>> 
>>> 
>>> Besides, the CIDR is actually the information that is sent to the DHCP to
>>> locate IP Addresses.
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> Edgar
>>> 
>>> 
>>> From:  Aaron Rosen 
>>> Reply-To:  OpenStack List 
>>> Date:  Thursday, June 27, 2013 8:59 AM
>>> 
>>> To:  OpenStack List 
>>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>>> 
>>> Hi Edgar, 
>>> 
>>> In this case if you don't associate a subnet with a network you should
>>> achieve that. Why doesn't that work?
>>> 
>>> Thanks, 
>>> 
>>> Aaron
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana  wrote:
 Could it be possible to add a flag to disable the allocation for the IP?
 If the "no allocation" flag is enabled, all ports will have an empty value
 for IPs.
  It will increase the config parameters in quantum, should we try it?
 
 Edgar
 
 From:  Mark McClain 
 Reply-To:  OpenStack List 
 Date:  Thursday, June 20, 2013 1:13 PM
 To:  OpenStack List 
 Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
 
 There's work under way to make IP allocation pluggable. One of the options
 will include not having an allocator for a subnet.
 
 mark
 
 On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
 
> Developers,
> 
> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
> port is created by the following def:
> _allocate_ips_for_port(self, context, network, port):
> 
> If we are using a real DHCP (not the dnsmasq process) that does not accept
> static IP allocation because it only allocates IPs based on its own
> algorithm, how can we tell Networking to not allocate an IP at all?
> I don¹t think that is possible based on the code but I would like to know
> if somebody has gone throug

Re: [openstack-dev] [Networking] Allocation of IPs

[Armando Migliaccio]

I guess the other question is: is this the right approach?

I think your use case may be beneficial to other plugins, so in my view
having a plugin-specific override is not the best fit.

On Fri, Jun 28, 2013 at 2:42 PM, Edgar Magana  wrote:

> Got it!!!  I knew it could be possible..
>
> Thanks,
>
> Edgar
>
> From: Aaron Rosen 
> Reply-To: OpenStack List 
> Date: Friday, June 28, 2013 2:19 PM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>
> Gotcha, The part that was confusing was:
>
> >Could it be possible to add a flag to disable the allocation for the IP?
> >If the "no allocation" flag is enabled, all ports will have an empty
> value for IPs.
>
> So what you are looking to do is to provide the IP address from the plugin
> and not the db_base class it seems?  In this case all you need to do is
> implement:
>
> _allocate_ips_for_port() in your plugin and then that method will be
> called instead of the base class one.
>
> Aaron
>
>
>
> On Fri, Jun 28, 2013 at 12:48 PM, Edgar Magana wrote:
>
>> Aaron,
>>
>> You are totally right, the point is that I don't want to loose the IPAM
>> info in Neutron because that is the moment when the backend plugin deploys
>> a new DHCP server into the Virtual Networking Infrastruture. So, every time
>> that a user creates a subnet and enables DHCP our plugin deploys a new DHCP
>> service.
>>
>> I am sure that is me the one missing something!!!   :-)
>>
>> Thanks,
>>
>> Edgar
>>
>> From: Aaron Rosen 
>> Reply-To: OpenStack List 
>> Date: Friday, June 28, 2013 12:07 PM
>>
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>>
>> Hi Edgar,
>>
>> I'm still not following. In your original question you asked how to you
>> create a port and not allocate an ip address to it at all so that you can
>> leverage a real dhcp server to do that. In order to do that you can create
>> a network without a subnet but then you loose the ipam info in quantum. Or
>> write a script that notifies your dhcp server the mac-ip bindings each
>> instance should have.  Am i missing something here?
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana wrote:
>>
>>> Aaron,
>>>
>>> Because the create create_subnet API is the one that enables/disables
>>> the DHCP:
>>>
>>> quantum subnet-create--enable_dhcp False
>>>
>>>
>>> Besides, the CIDR is actually the information that is sent to the DHCP
>>> to locate IP Addresses.
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Edgar
>>>
>>>
>>> From: Aaron Rosen 
>>> Reply-To: OpenStack List 
>>> Date: Thursday, June 27, 2013 8:59 AM
>>>
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>>>
>>> Hi Edgar,
>>>
>>> In this case if you don't associate a subnet with a network you should
>>> achieve that. Why doesn't that work?
>>>
>>> Thanks,
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana wrote:
>>>
 Could it be possible to add a flag to disable the allocation for the IP?
 If the "no allocation" flag is enabled, all ports will have an empty
 value for IPs.
  It will increase the config parameters in quantum, should we try it?

 Edgar

  From: Mark McClain 
 Reply-To: OpenStack List 
 Date: Thursday, June 20, 2013 1:13 PM
 To: OpenStack List 
 Subject: Re: [openstack-dev] [Networking] Allocation of IPs

 There's work under way to make IP allocation pluggable. One of the
 options will include not having an allocator for a subnet.

 mark

 On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:

 Developers,

 So far in Networking (formerly Quantum) IPs are pre-allocated when a
 new port is created by the following def:
 _allocate_ips_for_port(self, context, network, port):

 If we are using a real DHCP (not the dnsmasq process) that does not
 accept static IP allocation because it only allocates IPs based on its own
 algorithm, how can we tell Networking to not allocate an IP at all?
 I don’t think that is possible based on the code but I would like to
 know if somebody has gone through the same problem and have a workaround
 solution.

 Cheers,

 Edgar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___ OpenStack-dev mailing
 list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>> ___ OpenStack-dev mailing
>>> list OpenStack-dev@lists.openstack.org
>>> http://

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Russell Bryant]

On 06/28/2013 03:44 PM, Boris Pavlovic wrote:
> Russell, 
> 
> I have some crazy Idea, about how to make reviewing more stable. 
> And how to avoid old patches at all. 
> 
> "Old" means that last update was more then N days ago.
> 
> If there are patches that are older then N days:
> we just hide "review" button for all patches except old patches.
> When they are reviewed we return our button back. =)

Heh, yes, that is a crazy idea.

If a critical bug fix or a security patch is posted, we need to be able
to review it ASAP.

Not all patches are equal ... some things take longer because they are
bigger, more complex, or for some other reason harder to review.  In
many cases, not *all* of nova-core is qualified or comfortable with
reviewing a given change.  They should still be able to reivew the
patches appropriate for them.

etc etc...

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Allocation of IPs

[Edgar Magana]

Got it!!!  I knew it could be possible..

Thanks,

Edgar

From:  Aaron Rosen 
Reply-To:  OpenStack List 
Date:  Friday, June 28, 2013 2:19 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

Gotcha, The part that was confusing was:

>Could it be possible to add a flag to disable the allocation for the IP?
>If the "no allocation" flag is enabled, all ports will have an empty value for
IPs.

So what you are looking to do is to provide the IP address from the plugin
and not the db_base class it seems?  In this case all you need to do is
implement: 

_allocate_ips_for_port() in your plugin and then that method will be called
instead of the base class one.

Aaron



On Fri, Jun 28, 2013 at 12:48 PM, Edgar Magana  wrote:
> Aaron,
> 
> You are totally right, the point is that I don't want to loose the IPAM info
> in Neutron because that is the moment when the backend plugin deploys a new
> DHCP server into the Virtual Networking Infrastruture. So, every time that a
> user creates a subnet and enables DHCP our plugin deploys a new DHCP service.
> 
> I am sure that is me the one missing something!!!   :-)
> 
> Thanks,
> 
> Edgar
> 
> From:  Aaron Rosen 
> Reply-To:  OpenStack List 
> Date:  Friday, June 28, 2013 12:07 PM
> 
> To:  OpenStack List 
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> Hi Edgar, 
> 
> I'm still not following. In your original question you asked how to you create
> a port and not allocate an ip address to it at all so that you can leverage a
> real dhcp server to do that. In order to do that you can create a network
> without a subnet but then you loose the ipam info in quantum. Or write a
> script that notifies your dhcp server the mac-ip bindings each instance should
> have.  Am i missing something here?
> 
> Thanks,
> 
> Aaron
> 
> 
> On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana  wrote:
>> Aaron,
>> 
>> Because the create create_subnet API is the one that enables/disables the
>> DHCP:
>> quantum subnet-create--enable_dhcp False
>> 
>> 
>> 
>> Besides, the CIDR is actually the information that is sent to the DHCP to
>> locate IP Addresses.
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> Edgar
>> 
>> 
>> From:  Aaron Rosen 
>> Reply-To:  OpenStack List 
>> Date:  Thursday, June 27, 2013 8:59 AM
>> 
>> To:  OpenStack List 
>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> Hi Edgar, 
>> 
>> In this case if you don't associate a subnet with a network you should
>> achieve that. Why doesn't that work?
>> 
>> Thanks, 
>> 
>> Aaron
>> 
>> 
>> 
>> 
>> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana  wrote:
>>> Could it be possible to add a flag to disable the allocation for the IP?
>>> If the "no allocation" flag is enabled, all ports will have an empty value
>>> for IPs.
>>>  It will increase the config parameters in quantum, should we try it?
>>> 
>>> Edgar
>>> 
>>> From:  Mark McClain 
>>> Reply-To:  OpenStack List 
>>> Date:  Thursday, June 20, 2013 1:13 PM
>>> To:  OpenStack List 
>>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>>> 
>>> There's work under way to make IP allocation pluggable. One of the options
>>> will include not having an allocator for a subnet.
>>> 
>>> mark
>>> 
>>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>>> 
 Developers,
 
 So far in Networking (formerly Quantum) IPs are pre-allocated when a new
 port is created by the following def:
 _allocate_ips_for_port(self, context, network, port):
 
 If we are using a real DHCP (not the dnsmasq process) that does not accept
 static IP allocation because it only allocates IPs based on its own
 algorithm, how can we tell Networking to not allocate an IP at all?
 I don¹t think that is possible based on the code but I would like to know
 if somebody has gone through the same problem and have a workaround
 solution.
 
 Cheers,
 
 Edgar
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> ___ OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/
>>> listinfo/openstack-dev
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> ___ OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> ___ OpenStack-dev mailing list
> Ope

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

[Russell Bryant]

On 06/28/2013 03:46 PM, Andrew Laski wrote:
> On 06/28/13 at 10:01pm, Christopher Yeoh wrote:
>> Hi,
>>
>> The following is a list of API extensions for which there are no plans to
>> port. Please shout if you think any of them needs to be!
>>
>> baremetal_nodes.py
>> os_networks.py
>> networks_associate.py
>> os_tenant_networks.py
>> virtual_interfaces.py
>> createserverext.py
>> floating_ip_dns.py
>> floating_ip_pools.py
>> floating_ips_bulk.py
>> floating_ips.py
>> cloudpipe.py
>> cloudpipe_update.py
>> volumes.py
> 
> For volumes.py, is this everything or just everything except the
> os-volume_attachments portion?  I think we still need that part.

Indeed, we do.  Good catch.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Allocation of IPs

[Aaron Rosen]

Gotcha, The part that was confusing was:

>Could it be possible to add a flag to disable the allocation for the IP?
>If the "no allocation" flag is enabled, all ports will have an empty value
for IPs.

So what you are looking to do is to provide the IP address from the plugin
and not the db_base class it seems?  In this case all you need to do is
implement:

_allocate_ips_for_port() in your plugin and then that method will be called
instead of the base class one.

Aaron



On Fri, Jun 28, 2013 at 12:48 PM, Edgar Magana  wrote:

> Aaron,
>
> You are totally right, the point is that I don't want to loose the IPAM
> info in Neutron because that is the moment when the backend plugin deploys
> a new DHCP server into the Virtual Networking Infrastruture. So, every time
> that a user creates a subnet and enables DHCP our plugin deploys a new DHCP
> service.
>
> I am sure that is me the one missing something!!!   :-)
>
> Thanks,
>
> Edgar
>
> From: Aaron Rosen 
> Reply-To: OpenStack List 
> Date: Friday, June 28, 2013 12:07 PM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>
> Hi Edgar,
>
> I'm still not following. In your original question you asked how to you
> create a port and not allocate an ip address to it at all so that you can
> leverage a real dhcp server to do that. In order to do that you can create
> a network without a subnet but then you loose the ipam info in quantum. Or
> write a script that notifies your dhcp server the mac-ip bindings each
> instance should have.  Am i missing something here?
>
> Thanks,
>
> Aaron
>
>
> On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana wrote:
>
>> Aaron,
>>
>> Because the create create_subnet API is the one that enables/disables the
>> DHCP:
>>
>> quantum subnet-create--enable_dhcp False
>>
>>
>> Besides, the CIDR is actually the information that is sent to the DHCP
>> to locate IP Addresses.
>>
>>
>> Thanks,
>>
>>
>> Edgar
>>
>>
>> From: Aaron Rosen 
>> Reply-To: OpenStack List 
>> Date: Thursday, June 27, 2013 8:59 AM
>>
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>>
>> Hi Edgar,
>>
>> In this case if you don't associate a subnet with a network you should
>> achieve that. Why doesn't that work?
>>
>> Thanks,
>>
>> Aaron
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana wrote:
>>
>>> Could it be possible to add a flag to disable the allocation for the IP?
>>> If the "no allocation" flag is enabled, all ports will have an empty
>>> value for IPs.
>>>  It will increase the config parameters in quantum, should we try it?
>>>
>>> Edgar
>>>
>>> From: Mark McClain 
>>> Reply-To: OpenStack List 
>>> Date: Thursday, June 20, 2013 1:13 PM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>>>
>>> There's work under way to make IP allocation pluggable. One of the
>>> options will include not having an allocator for a subnet.
>>>
>>> mark
>>>
>>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>>>
>>> Developers,
>>>
>>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
>>> port is created by the following def:
>>> _allocate_ips_for_port(self, context, network, port):
>>>
>>> If we are using a real DHCP (not the dnsmasq process) that does not
>>> accept static IP allocation because it only allocates IPs based on its own
>>> algorithm, how can we tell Networking to not allocate an IP at all?
>>> I don’t think that is possible based on the code but I would like to
>>> know if somebody has gone through the same problem and have a workaround
>>> solution.
>>>
>>> Cheers,
>>>
>>> Edgar
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> ___ OpenStack-dev mailing
>>> list OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> ___ OpenStack-dev mailing
>> list OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___ OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__

[openstack-dev] [barbican] Barbican Client Version 0.2

[Arash Ghoreyshi]

Hi all,

The latest version of python-barbicanclient is now available via pip. You can 
get it using: pip install python-barbicanclient

This version includes the new command line interface, keep. Here's its 
documentation: 
https://github.com/cloudkeep/python-barbicanclient/wiki/Command-Line-Client

Also, the client library itself has been expanded. Its documentation can be 
found here: https://github.com/cloudkeep/python-barbicanclient/wiki/Client-Usage

Any feedback is always appreciated!

Thanks,
Arash
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Question about locking

[Ben Nemec]

On 2013-06-26 12:07, Rosa, Andrea (HP Cloud Services) wrote:

Hi all,

What happens if a greenthread, after acquiring a lock  (not external), 
it dies?

For example:
A thread is performing the "do_terminate_instance", it has the lock
and before terminating the process it dies,  what happens at the lock?
Is that released in some way?


That function is using the synchronized decorator, which means that it's 
wrapped by a semaphore context.  As I understand it (and someone correct 
me if I'm wrong), if an error happens and an exception is thrown the 
context would be exited and the semaphore released.  Of course, I 
suppose there are situations where a thread could be terminated without 
being able to do that cleanup, but I suspect most of those cases would 
kill the entire process, making the lock irrelevant (since you specify 
not external).



If  not I think that all other actions for that instance are blocked
waiting for the lock, is that correct?


That is a potential pitfall of synchronization, but I think it shouldn't 
happen in this case.  Are you seeing this behavior?


-Ben

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

[Andrew Laski]

On 06/28/13 at 10:01pm, Christopher Yeoh wrote:

Hi,

The following is a list of API extensions for which there are no plans to
port. Please shout if you think any of them needs to be!

baremetal_nodes.py
os_networks.py
networks_associate.py
os_tenant_networks.py
virtual_interfaces.py
createserverext.py
floating_ip_dns.py
floating_ip_pools.py
floating_ips_bulk.py
floating_ips.py
cloudpipe.py
cloudpipe_update.py
volumes.py


For volumes.py, is this everything or just everything except the 
os-volume_attachments portion?  I think we still need that part.





Also I'd like to propose that after H2 any new API extension submitted HAS
to have a v3 version. That will give us enough time to ensure that the V3
API in Havana can do everything that the V2 one except where we explicitly
don't want to support something.

For developers who have had new API extensions merged in H2 but haven't
submitted a v3 version, I'd appreciate it if you could check the following
etherpad to see if your extension is on the list and put it on there ASAP
if it isn't there already:

https://etherpad.openstack.org/NovaV3ExtensionPortWorkList

I've tried to keep track of new API extensions to make sure we do v3 ports
but may have missed some.

Chris



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Allocation of IPs

[Edgar Magana]

Aaron,

You are totally right, the point is that I don't want to loose the IPAM info
in Neutron because that is the moment when the backend plugin deploys a new
DHCP server into the Virtual Networking Infrastruture. So, every time that a
user creates a subnet and enables DHCP our plugin deploys a new DHCP
service.

I am sure that is me the one missing something!!!   :-)

Thanks,

Edgar

From:  Aaron Rosen 
Reply-To:  OpenStack List 
Date:  Friday, June 28, 2013 12:07 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

Hi Edgar, 

I'm still not following. In your original question you asked how to you
create a port and not allocate an ip address to it at all so that you can
leverage a real dhcp server to do that. In order to do that you can create a
network without a subnet but then you loose the ipam info in quantum. Or
write a script that notifies your dhcp server the mac-ip bindings each
instance should have.  Am i missing something here?

Thanks,

Aaron


On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana  wrote:
> Aaron,
> 
> Because the create create_subnet API is the one that enables/disables the
> DHCP:
> quantum subnet-create--enable_dhcp False
> 
> 
> 
> Besides, the CIDR is actually the information that is sent to the DHCP to
> locate IP Addresses.
> 
> 
> 
> Thanks,
> 
> 
> 
> Edgar
> 
> 
> From:  Aaron Rosen 
> Reply-To:  OpenStack List 
> Date:  Thursday, June 27, 2013 8:59 AM
> 
> To:  OpenStack List 
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> Hi Edgar, 
> 
> In this case if you don't associate a subnet with a network you should achieve
> that. Why doesn't that work?
> 
> Thanks, 
> 
> Aaron
> 
> 
> 
> 
> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana  wrote:
>> Could it be possible to add a flag to disable the allocation for the IP?
>> If the "no allocation" flag is enabled, all ports will have an empty value
>> for IPs.
>>  It will increase the config parameters in quantum, should we try it?
>> 
>> Edgar
>> 
>> From:  Mark McClain 
>> Reply-To:  OpenStack List 
>> Date:  Thursday, June 20, 2013 1:13 PM
>> To:  OpenStack List 
>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> There's work under way to make IP allocation pluggable. One of the options
>> will include not having an allocator for a subnet.
>> 
>> mark
>> 
>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>> 
>>> Developers,
>>> 
>>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
>>> port is created by the following def:
>>> _allocate_ips_for_port(self, context, network, port):
>>> 
>>> If we are using a real DHCP (not the dnsmasq process) that does not accept
>>> static IP allocation because it only allocates IPs based on its own
>>> algorithm, how can we tell Networking to not allocate an IP at all?
>>> I don¹t think that is possible based on the code but I would like to know if
>>> somebody has gone through the same problem and have a workaround solution.
>>> 
>>> Cheers,
>>> 
>>> Edgar
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___ OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> ___ OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___ OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Boris Pavlovic]

Russell,

I have some crazy Idea, about how to make reviewing more stable.
And how to avoid old patches at all.

"Old" means that last update was more then N days ago.

If there are patches that are older then N days:
we just hide "review" button for all patches except old patches.
When they are reviewed we return our button back. =)

Best Regards,
Boris Pavlovic



On Fri, Jun 28, 2013 at 11:33 PM, Matt Joyce wrote:

> review response time matches up to accepted practices in infosec for
> quantifying risk exposure in terms of incident response times.
>
> so this is actually a suggest best practice in other areas.
>
> -matt
>
>
> On Fri, Jun 28, 2013 at 10:30 AM, Russell Bryant wrote:
>
>> On 06/28/2013 12:18 PM, Matt Riedemann wrote:
>> > Hey I made the list!
>> >
>> > _https://review.openstack.org/#/c/25355/_
>> >
>> > Just wanted to point out for nova in longest-waiting reviews based on
>> > first revision:
>> >
>> >
>> > 1.94 days, 12 hours, 49 minutes
>> > - _https://review.openstack.org/25355_ (PowerVM resize and migrate test
>> > cases)
>> >
>> > This one is a bit skewed because it was abandoned due to inactivity and
>> > then I picked it back up by assigning the bug to myself and contributing
>> > to the original review.
>> >
>> > Is there a way to take that into account in the metrics?  Or is this a
>> > process issue, i.e. should I have left this abandoned and pushed up a
>> > new review based on the original?
>>
>> I think what you did is definitely the right thing to do.  The stat is
>> still accurate for how long it is taking to get the patch to completion.
>>  Having some really high numbers here doesn't worry me, because it's
>> reality, and is often out of the control of reviewers.
>>
>> --
>> Russell Bryant
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Matt Joyce]

review response time matches up to accepted practices in infosec for
quantifying risk exposure in terms of incident response times.

so this is actually a suggest best practice in other areas.

-matt


On Fri, Jun 28, 2013 at 10:30 AM, Russell Bryant  wrote:

> On 06/28/2013 12:18 PM, Matt Riedemann wrote:
> > Hey I made the list!
> >
> > _https://review.openstack.org/#/c/25355/_
> >
> > Just wanted to point out for nova in longest-waiting reviews based on
> > first revision:
> >
> >
> > 1.94 days, 12 hours, 49 minutes
> > - _https://review.openstack.org/25355_ (PowerVM resize and migrate test
> > cases)
> >
> > This one is a bit skewed because it was abandoned due to inactivity and
> > then I picked it back up by assigning the bug to myself and contributing
> > to the original review.
> >
> > Is there a way to take that into account in the metrics?  Or is this a
> > process issue, i.e. should I have left this abandoned and pushed up a
> > new review based on the original?
>
> I think what you did is definitely the right thing to do.  The stat is
> still accurate for how long it is taking to get the patch to completion.
>  Having some really high numbers here doesn't worry me, because it's
> reality, and is often out of the control of reviewers.
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] More on inherited domain roles

[Henry Nash]

Hi Adam,

It's a valid debatethe thing I would add is that we should make the way 
group roles are handled consistently with whatever we do for inherited roles.  
Group roles are a kind of inheritance (i.e. because I am a member of Group X, I 
inherit all the role assignments that Group X has.we just don't call it 
"inheritance").  This is, of course, done at token creation time todayand 
will admit that I have just started the implementation of domain inherited 
roles using the same approach.

It seems to me that an efficient DB backend (particularly, when we move to a 
single assignments table in IceHouse) would be able to return all the domain 
inherited roles in one query (in fact you could have a query that got both 
inherited and non-inherited roles in one go I would think) - so not sure if we 
are adding too much to the load of token generation.  Taking the alternative 
approach of actually creating the assignment records at assignment time, I 
worry a bit about the duplication of state (i.e. we must store both the 
inherited assignment as well as the actual generated assignment 
records)more scope for getting out of sync etc.

So right now I still favour the "at token generation time" approach.

Henry



On 28 Jun 2013, at 17:13, Adam Young wrote:

> Since I will be gone next week, and I know you want to move on with this, 
> just wanted to confirm that I am OK with Henry's approach.
> 
> I would like to suggest that we contemplate doing to inheritance mechanism at 
> assignment time as opposed to token creation time as an optimization.  What 
> would this mean?
> 
> Say a domain role-assignement implies a project role assignment.  When a new 
> project is created, we generate the role-assignments for the users that have 
> domain entries explicitly at this point.  
> 
> The objection I assume would be along the lines of "how are you sure you are 
> going to get it right" and "that is going to generate a lot more entries in 
> the database" which are both valid concerns.  However, token creation is far, 
> far more common than changes to role assigments, and we should focus on 
> optimizing for this use case.  In addition, it will remove the need for 
> "effective" role assignments.
> 
> One concern would be with "if we drop the inheritance relationship, what do 
> we do with all those people that have that role already." We would have the 
> choice of removing the   role-assignments then, or of leaving them in 
> place, and having to manually remove them.  We would have no means to 
> distinguish between explicit and implicit role assignments.  I could 
> entertain arguments on either approach, or even an additional parameter 
> specifying what to do upon removal of the domain level assignment.
> 
> 
> I don't see this as "make-or-break" but rather an implementation detail worth 
> considering now.
> 
> This would be consistent with the token revocation approach, where we make 
> the effort to revoke all tokens at the time of the event. 
> 
> 
> 
> On 06/13/2013 09:49 AM, Henry Nash wrote:
>> Thanks Guang  - I have added responses, as well as tried to articulate the 
>> conceptual differences that actually underpin all these approaches.  This is 
>> in the intro in the etherpad, but reproduced below:
>> 
>> Before looking at the possible solutions, it is worth pointing out that the 
>> differences in the various options boil down to how we approach two 
>> conceptual issues:
>> 
>> 1) How should we specify an assignment that applies to more than one entity? 
>>  There are two conceptual approaches:
>> - Use Inheritance, based on some grouping, hopefully one that already exists 
>> (e.g. use the fact that all projects are owned by a domain)
>> - Use a logical expression (e.g. "apply to "*" )
>> The differences in these two concepts gets amplified if we want to be able, 
>> in the future, to further segregate role assignmnets based on some other 
>> subset (e.g. either hierachy of domains, or 'apply to domains matching the 
>> string "army*" )
>> 
>> 2) Should you specify the "scope" of the assignment separately from the 
>> assignment?
>> - Keeping them separate is considered good practice by our experts in this 
>> field, and this can be done by either storing the scope in another entity 
>> (e.g. the role def) or separatly in the assignment call.  
>> - If you don't keep them separate, then obviously it is all lumped into the 
>> assignment call.
>> 
>> The  proposed solutions only differ  fundamentally in how the approach these 
>> concepts (with consequences in the use cases below), the rest is just 
>> semantics.
>> 
>> Henry
>> On 12 Jun 2013, at 22:46, Yee, Guang wrote:
>> 
>>> Added my comments in the etherpad.
>>> 
>>> 
>>> 
>>> I really think role assignment merits its own CRUD. Since there's a new API
>>> to get the role assignments.
>>> 
>>> GET /role_assignments
>>> 
>>> why not just have the complete API set to facilitate role assignments? That
>>> way, we have

Re: [openstack-dev] [Networking] Allocation of IPs

[Aaron Rosen]

Hi Edgar,

I'm still not following. In your original question you asked how to you
create a port and not allocate an ip address to it at all so that you can
leverage a real dhcp server to do that. In order to do that you can create
a network without a subnet but then you loose the ipam info in quantum. Or
write a script that notifies your dhcp server the mac-ip bindings each
instance should have.  Am i missing something here?

Thanks,

Aaron


On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana  wrote:

> Aaron,
>
> Because the create create_subnet API is the one that enables/disables the
> DHCP:
>
> quantum subnet-create--enable_dhcp False
>
>
> Besides, the CIDR is actually the information that is sent to the DHCP
> to locate IP Addresses.
>
>
> Thanks,
>
>
> Edgar
>
>
> From: Aaron Rosen 
> Reply-To: OpenStack List 
> Date: Thursday, June 27, 2013 8:59 AM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>
> Hi Edgar,
>
> In this case if you don't associate a subnet with a network you should
> achieve that. Why doesn't that work?
>
> Thanks,
>
> Aaron
>
>
>
>
> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana wrote:
>
>> Could it be possible to add a flag to disable the allocation for the IP?
>> If the "no allocation" flag is enabled, all ports will have an empty
>> value for IPs.
>>  It will increase the config parameters in quantum, should we try it?
>>
>> Edgar
>>
>> From: Mark McClain 
>> Reply-To: OpenStack List 
>> Date: Thursday, June 20, 2013 1:13 PM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>>
>> There's work under way to make IP allocation pluggable. One of the
>> options will include not having an allocator for a subnet.
>>
>> mark
>>
>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>>
>> Developers,
>>
>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
>> port is created by the following def:
>> _allocate_ips_for_port(self, context, network, port):
>>
>> If we are using a real DHCP (not the dnsmasq process) that does not
>> accept static IP allocation because it only allocates IPs based on its own
>> algorithm, how can we tell Networking to not allocate an IP at all?
>> I don’t think that is possible based on the code but I would like to know
>> if somebody has gone through the same problem and have a workaround
>> solution.
>>
>> Cheers,
>>
>> Edgar
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___ OpenStack-dev mailing
>> list OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___ OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] More on inherited domain roles

[David Chadwick]

Hi Adam

if you do it at role assignment time, I think the newly assigned role 
should be marked as implicit/inherited to differentiate it from an 
explicitly assigned role. In this way, if the inheritance is 
subsequently removed, then the inherited assignment can also be deleted 
at the same time. I dont think it is the correct model to convert an 
inherited role into an explicitly assigned role.


the advantage of doing it with token creation is that the token can 
accurately reflect the current state of affairs wrt inheritance and 
revocation is not needed (since the token will time out).


regards

david

On 28/06/2013 17:13, Adam Young wrote:

Since I will be gone next week, and I know you want to move on with
this, just wanted to confirm that I am OK with Henry's approach.

I would like to suggest that we contemplate doing to inheritance
mechanism at assignment time as opposed to token creation time as an
optimization.  What would this mean?

Say a domain role-assignement implies a project role assignment. When a
new project is created, we generate the role-assignments for the users
that have domain entries explicitly at this point.

The objection I assume would be along the lines of "how are you sure you
are going to get it right" and "that is going to generate a lot more
entries in the database" which are both valid concerns.  However, token
creation is far, far more common than changes to role assigments, and we
should focus on optimizing for this use case.  In addition, it will
remove the need for "effective" role assignments.

One concern would be with "if we drop the inheritance relationship, what
do we do with all those people that have that role already." We would
have the choice of removing the role-assignments then, or of leaving
them in place, and having to manually remove them.  We would have no
means to distinguish between explicit and implicit role assignments.  I
could entertain arguments on either approach, or even an additional
parameter specifying what to do upon removal of the domain level assignment.


I don't see this as "make-or-break" but rather an implementation detail
worth considering now.

This would be consistent with the token revocation approach, where we
make the effort to revoke all tokens at the time of the event.



On 06/13/2013 09:49 AM, Henry Nash wrote:

Thanks Guang  - I have added responses, as well as tried to articulate
the conceptual differences that actually underpin all these
approaches.  This is in the intro in the etherpad, but reproduced below:

Before looking at the possible solutions, it is worth pointing out
that the differences in the various options boil down to how we
approach two conceptual issues:

1) How should we specify an assignment that applies to more than one
entity? There are two conceptual approaches:
- Use Inheritance, based on some grouping, hopefully one that already
exists (e.g. use the fact that all projects are owned by a domain)
- Use a logical expression (e.g. "apply to "*" )
The differences in these two concepts gets amplified if we want to be
able, in the future, to further segregate role assignmnets based on
some other subset (e.g. either hierachy of domains, or 'apply to
domains matching the string "army*" )

2) Should you specify the "scope" of the assignment separately from
the assignment?
- Keeping them separate is considered good practice by our experts in
this field, and this can be done by either storing the scope in
another entity (e.g. the role def) or separatly in the assignment call.
- If you don't keep them separate, then obviously it is all lumped
into the assignment call.

The  proposed solutions only differ  fundamentally in how the approach
these concepts (with consequences in the use cases below), the rest is
just semantics.

Henry
On 12 Jun 2013, at 22:46, Yee, Guang wrote:


Added my comments in the etherpad.



I really think role assignment merits its own CRUD. Since there's a
new API
to get the role assignments.

GET /role_assignments

why not just have the complete API set to facilitate role
assignments? That
way, we have one unified API for role
assignment, as oppose to multiple APIs as exist today.

To get a role assignment:

GET /role-assignments/{role_assignment_id}

To remove a role assignment:

DELETE /role-assignments/{role_assignment_id}

To create a role assignment:

POST /role_assignments

{"role_assignment": {
   "user" {
   "id": user_id
   },
   "role": {
   "id": role_id
   },
   "scope": {
   "domain": {
   "id": domain_id
   },
   "project": {
   "id": project_id
   }
   }
}

Note: "user" and "scope" is similar to the data structure in auth
APIs. i.e.
can be either "id" or "name" + "domain".
If assignment is for a group, just have "group" in there instead of
"user".
For example,

{"role_assignment": {
   "group" {
   "id": group_id
   },
   "role": {
   "id": role_id
   },
   "scope": {
   "domain": {
   "id": domain_id
  

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Russell Bryant]

On 06/28/2013 12:18 PM, Matt Riedemann wrote:
> Hey I made the list!
> 
> _https://review.openstack.org/#/c/25355/_
> 
> Just wanted to point out for nova in longest-waiting reviews based on
> first revision:
> 
> 
> 1.94 days, 12 hours, 49 minutes
> - _https://review.openstack.org/25355_ (PowerVM resize and migrate test
> cases)
> 
> This one is a bit skewed because it was abandoned due to inactivity and
> then I picked it back up by assigning the bug to myself and contributing
> to the original review.
> 
> Is there a way to take that into account in the metrics?  Or is this a
> process issue, i.e. should I have left this abandoned and pushed up a
> new review based on the original?

I think what you did is definitely the right thing to do.  The stat is
still accurate for how long it is taking to get the patch to completion.
 Having some really high numbers here doesn't worry me, because it's
reality, and is often out of the control of reviewers.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking] A consideration about config files and deployment issues

[Jay Pipes]

On 06/28/2013 01:26 PM, Armando Migliaccio wrote:

Folks,

I appreciate that there is a strong awareness within the dev community
to ensure that OpenStack gets easier and easier to be deployed, upgraded
and maintained, however I would like to invite core reviewers to think
(even) harder about the implications that changes to config files may
have for the poor sysadmin guy who has the job of
running OpenStack-based clouds (or packagers for that matter).


or folks writing Chef cookbooks / Puppet modules that create the config 
files from templates! :)


Having just gone through this effort for the OpenStack Network Chef 
cookbook [1], I can say definitively that it was a major pain in the 
butt to templatize that database config section for every single Quantum 
plugin.


My only complaint is that the changes weren't completed before I went 
through the effort ;)



I don't want to pick up on any specific committer/reviewer, but review
[1] got me thinking on how patches that tweak configuration files are
taken somewhat lightly. The particular change in question has not only
implications on how devstack generates these files (and I don't see any
devstack patch counter-part currently in review, or being merged to deal
with the Neutron change - apology if there is but I couldn't find it),
but also implications for Puppet or Chef recipes that rely on config
templates based on what etc folders of every project contain.

Luckily enough the implications in this specific case are innocuous, but
I have personally gotten burnt too many times in the past on this very
issue: config files are changed too often without thinking too hard to
what it means for who needs to maintain instantiations of these files
across multiple releases.

This is not meant to be rant, just a kind reminder :)


Yes, a gentle reminder out to the -operators or -dev mailing list each 
time a config file is changed would be most welcome!


Best,
-jay

[1] http://github.com/stackforge/cookbook-openstack-network


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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Russell Bryant]

On 06/28/2013 08:24 AM, Christopher Yeoh wrote:
> How about time since first revision or -1 applied (but not including -1s
> by Jenkins due to gate flakiness), whichever is shorter. That eliminates
> non trivial rebases which I've found are often required after about 7
> days but doesn't push out the numbers where the submitter is slow in
> updating.

Good idea.  I've added it as a third stat here:

http://russellbryant.net/openstack-stats/all-openreviews.html

Average is just under 7 days.  Nova is about a day below the average.
This probably a bit higher than I'd like to see, but not too far off.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [networking] A consideration about config files and deployment issues

[Armando Migliaccio]

Folks,

I appreciate that there is a strong awareness within the dev community to
ensure that OpenStack gets easier and easier to be deployed, upgraded and
maintained, however I would like to invite core reviewers to think (even)
harder about the implications that changes to config files may have for the
poor sysadmin guy who has the job of running OpenStack-based clouds (or
packagers for that matter).

I don't want to pick up on any specific committer/reviewer, but review [1]
got me thinking on how patches that tweak configuration files are taken
somewhat lightly. The particular change in question has not only
implications on how devstack generates these files (and I don't see any
devstack patch counter-part currently in review, or being merged to deal
with the Neutron change - apology if there is but I couldn't find it), but
also implications for Puppet or Chef recipes that rely on config templates
based on what etc folders of every project contain.

Luckily enough the implications in this specific case are innocuous, but I
have personally gotten burnt too many times in the past on this very issue:
config files are changed too often without thinking too hard to what it
means for who needs to maintain instantiations of these files across
multiple releases.

This is not meant to be rant, just a kind reminder :)

Many thanks,
Armando

[1] https://review.openstack.org/#/c/34515
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

[Rick Jones]

On 06/28/2013 01:55 AM, Rahul Sharma wrote:

Thanks Aaron for your kind help. It worked. Is there any doc which lists
all the possible commands and their usage for quantum? because --help
doesn't help in identifying all the parameters, is there any reference
which one can use to get the complete command syntax?


If you use "quantum help " rather than quantum --help, it will 
give you more detailed help about .  For example:


$ quantum help security-group-rule-create
usage: quantum security-group-rule-create [-h]
  [-f {html,json,shell,table,yaml}]
  [-c COLUMN] [--variable VARIABLE]
  [--prefix PREFIX]
  [--request-format {json,xml}]
  [--tenant-id TENANT_ID]
  [--direction {ingress,egress}]
  [--ethertype ETHERTYPE]
  [--protocol PROTOCOL]
  [--port-range-min PORT_RANGE_MIN]
  [--port-range-max PORT_RANGE_MAX]
  [--remote-ip-prefix 
REMOTE_IP_PREFIX]

  [--remote-group-id SOURCE_GROUP]
  SECURITY_GROUP

Create a security group rule.

positional arguments:
  SECURITY_GROUPSecurity group name or id to add rule.

optional arguments:
  -h, --helpshow this help message and exit
  --request-format {json,xml}
the xml or json request format
  --tenant-id TENANT_ID
the owner tenant ID
  --direction {ingress,egress}
direction of traffic: ingress/egress
  --ethertype ETHERTYPE
IPv4/IPv6
  --protocol PROTOCOL   protocol of packet
  --port-range-min PORT_RANGE_MIN
starting port range
  --port-range-max PORT_RANGE_MAX
ending port range
  --remote-ip-prefix REMOTE_IP_PREFIX
cidr to match on
  --remote-group-id SOURCE_GROUP
remote security group name or id to apply rule

output formatters:
  output formatter options

  -f {html,json,shell,table,yaml}, --format {html,json,shell,table,yaml}
the output format, defaults to table
  -c COLUMN, --column COLUMN
specify the column(s) to include, can be repeated

shell formatter:
  a format a UNIX shell can parse (variable="value")

  --variable VARIABLE   specify the variable(s) to include, can be repeated
  --prefix PREFIX   add a prefix to all variable names

rick jones

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Http library usage by clients

[Flavio Percoco]

On 26/06/13 12:55 -0400, Adam Young wrote:

Glance:
- Uses httplib for communication
- Uses keystoneclient within cli
- Checks that socket is patched before importing eventlet for httplib.



FWIW, we're working on the migration to requests.

Cheers,
FF

--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Matt Riedemann]

Hey I made the list!

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

Just wanted to point out for nova in longest-waiting reviews based on 
first revision:


1.  94 days, 12 hours, 49 minutes - https://review.openstack.org/25355
 (PowerVM resize and migrate test cases)

This one is a bit skewed because it was abandoned due to inactivity and 
then I picked it back up by assigning the bug to myself and contributing 
to the original review.

Is there a way to take that into account in the metrics?  Or is this a 
process issue, i.e. should I have left this abandoned and pushed up a new 
review based on the original?



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States




From:   Russell Bryant 
To: OpenStack Development Mailing List 
, 
Date:   06/27/2013 09:45 PM
Subject:[openstack-dev] [Metrics][Nova] Another take on review 
turnaround  stats



Greetings,

The key metric I have been using for knowing whether we are keeping up
with review requests is the average wait time for getting a review.  In
a previous thread, we set a goal of keeping that under 4 days (at least
by the end of the week, may be higher after a weekend).  This is
calculated using the time that the *latest* patch revision was posted.
We have been keeping up with this (Nova at 3.5 days right now).

I've been getting a lot of complaints this week about review turnaround.
 It's important to me that we're doing this well, but action needs to be
based on real data.

One of the theories was that patches are having to be rebased a bunch,
so they have been waiting longer than the stats say.  True, but by how
much?  The answer is now in the stats:

http://russellbryant.net/openstack-stats/all-openreviews.html

The results are much better than I was afraid of.  On average across all
projects, patches waiting for review have an age of just under 14 days
since they were first posted.  Nova is below average, sitting at an
average of just over 10 days.  That doesn't seem bad at all, to me.

So, if we have a problem, it's not Nova specific, at least.  It's harder
to set a goal for this metric since it's not entirely in the hands of
reviewers like the other one.

Suggestions for additional tweaks welcome.

Thanks,

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] More on inherited domain roles

[Adam Young]

Since I will be gone next week, and I know you want to move on with 
this, just wanted to confirm that I am OK with Henry's approach.


I would like to suggest that we contemplate doing to inheritance 
mechanism at assignment time as opposed to token creation time as an 
optimization.  What would this mean?


Say a domain role-assignement implies a project role assignment. When a 
new project is created, we generate the role-assignments for the users 
that have domain entries explicitly at this point.


The objection I assume would be along the lines of "how are you sure you 
are going to get it right" and "that is going to generate a lot more 
entries in the database" which are both valid concerns.  However, token 
creation is far, far more common than changes to role assigments, and we 
should focus on optimizing for this use case.  In addition, it will 
remove the need for "effective" role assignments.


One concern would be with "if we drop the inheritance relationship, what 
do we do with all those people that have that role already." We would 
have the choice of removing the role-assignments then, or of leaving 
them in place, and having to manually remove them.  We would have no 
means to distinguish between explicit and implicit role assignments.  I 
could entertain arguments on either approach, or even an additional 
parameter specifying what to do upon removal of the domain level assignment.



I don't see this as "make-or-break" but rather an implementation detail 
worth considering now.


This would be consistent with the token revocation approach, where we 
make the effort to revoke all tokens at the time of the event.




On 06/13/2013 09:49 AM, Henry Nash wrote:
Thanks Guang  - I have added responses, as well as tried to articulate 
the conceptual differences that actually underpin all these 
approaches.  This is in the intro in the etherpad, but reproduced below:


Before looking at the possible solutions, it is worth pointing out 
that the differences in the various options boil down to how we 
approach two conceptual issues:


1) How should we specify an assignment that applies to more than one 
entity? There are two conceptual approaches:
- Use Inheritance, based on some grouping, hopefully one that already 
exists (e.g. use the fact that all projects are owned by a domain)

- Use a logical expression (e.g. "apply to "*" )
The differences in these two concepts gets amplified if we want to be 
able, in the future, to further segregate role assignmnets based on 
some other subset (e.g. either hierachy of domains, or 'apply to 
domains matching the string "army*" )


2) Should you specify the "scope" of the assignment separately from 
the assignment?
- Keeping them separate is considered good practice by our experts in 
this field, and this can be done by either storing the scope in 
another entity (e.g. the role def) or separatly in the assignment call.
- If you don't keep them separate, then obviously it is all lumped 
into the assignment call.


The  proposed solutions only differ  fundamentally in how the approach 
these concepts (with consequences in the use cases below), the rest is 
just semantics.


Henry
On 12 Jun 2013, at 22:46, Yee, Guang wrote:


Added my comments in the etherpad.



I really think role assignment merits its own CRUD. Since there's a 
new API

to get the role assignments.

GET /role_assignments

why not just have the complete API set to facilitate role 
assignments? That

way, we have one unified API for role
assignment, as oppose to multiple APIs as exist today.

To get a role assignment:

GET /role-assignments/{role_assignment_id}

To remove a role assignment:

DELETE /role-assignments/{role_assignment_id}

To create a role assignment:

POST /role_assignments

{"role_assignment": {
   "user" {
   "id": user_id
   },
   "role": {
   "id": role_id
   },
   "scope": {
   "domain": {
   "id": domain_id
   },
   "project": {
   "id": project_id
   }
   }
}

Note: "user" and "scope" is similar to the data structure in auth 
APIs. i.e.

can be either "id" or "name" + "domain".
If assignment is for a group, just have "group" in there instead of 
"user".

For example,

{"role_assignment": {
   "group" {
   "id": group_id
   },
   "role": {
   "id": role_id
   },
   "scope": {
   "domain": {
   "id": domain_id
   },
   "project": {
   "id": project_id
   }
   }
}

Upon successful creation, a assignment_ref is returned.

{"role-assignment": {
   "id": role_assignment_id
   "user": {
   "id": user_id
   },
   "role": {
   "id": role_id
   },
   "scope": {
   "domain": {
   "id": domain_id
   },
   "project": {
   "id": project_id
   }
   }
   "links": {
   "self":
"http://localhost:35357/v3/role-assignments/{role_assignment_id} 
"

   }
}

"scope" is basically the combination an

Re: [openstack-dev] [Networking] Allocation of IPs

[Edgar Magana]

Thanks Mark!

Edgar

From:  Mark McClain 
Reply-To:  OpenStack List 
Date:  Monday, June 24, 2013 7:04 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

Here's the blueprintŠ

https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation


On Jun 21, 2013, at 5:34 PM, Edgar Magana  wrote:

> Mark,
> 
> Can you point me to the BP for this feature?
> I want to keep an eye on it.
> 
> Thanks,
> 
> Edgar
> 
> From:  Mark McClain 
> Reply-To:  OpenStack List 
> Date:  Friday, June 21, 2013 12:41 PM
> To:  OpenStack List 
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> There will be a deployment option where you can configure the default IP
> allocator.  Additionally, the allocator will be configurable at subnet
> creation time.
> 
> mark
> 
> 
> On Jun 20, 2013, at 4:51 PM, Edgar Magana  wrote:
> 
>> Could it be possible to add a flag to disable the allocation for the IP?
>> If the "no allocation" flag is enabled, all ports will have an empty value
>> for IPs.
>>  It will increase the config parameters in quantum, should we try it?
>> 
>> Edgar
>> 
>> From:  Mark McClain 
>> Reply-To:  OpenStack List 
>> Date:  Thursday, June 20, 2013 1:13 PM
>> To:  OpenStack List 
>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> There's work under way to make IP allocation pluggable. One of the options
>> will include not having an allocator for a subnet.
>> 
>> mark
>> 
>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>> 
>>> Developers,
>>> 
>>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
>>> port is created by the following def:
>>> _allocate_ips_for_port(self, context, network, port):
>>> 
>>> If we are using a real DHCP (not the dnsmasq process) that does not accept
>>> static IP allocation because it only allocates IPs based on its own
>>> algorithm, how can we tell Networking to not allocate an IP at all?
>>> I don¹t think that is possible based on the code but I would like to know if
>>> somebody has gone through the same problem and have a workaround solution.
>>> 
>>> Cheers,
>>> 
>>> Edgar
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___ OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/openstack-dev
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___ OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___ OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Allocation of IPs

[Edgar Magana]

Aaron,

Because the create create_subnet API is the one that enables/disables the
DHCP:
quantum subnet-create--enable_dhcp False



Besides, the CIDR is actually the information that is sent to the DHCP to
locate IP Addresses.



Thanks,



Edgar


From:  Aaron Rosen 
Reply-To:  OpenStack List 
Date:  Thursday, June 27, 2013 8:59 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

Hi Edgar, 

In this case if you don't associate a subnet with a network you should
achieve that. Why doesn't that work?

Thanks, 

Aaron




On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana  wrote:
> Could it be possible to add a flag to disable the allocation for the IP?
> If the "no allocation" flag is enabled, all ports will have an empty value for
> IPs.
>  It will increase the config parameters in quantum, should we try it?
> 
> Edgar
> 
> From:  Mark McClain 
> Reply-To:  OpenStack List 
> Date:  Thursday, June 20, 2013 1:13 PM
> To:  OpenStack List 
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> There's work under way to make IP allocation pluggable. One of the options
> will include not having an allocator for a subnet.
> 
> mark
> 
> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
> 
>> Developers,
>> 
>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new port
>> is created by the following def:
>> _allocate_ips_for_port(self, context, network, port):
>> 
>> If we are using a real DHCP (not the dnsmasq process) that does not accept
>> static IP allocation because it only allocates IPs based on its own
>> algorithm, how can we tell Networking to not allocate an IP at all?
>> I don¹t think that is possible based on the code but I would like to know if
>> somebody has gone through the same problem and have a workaround solution.
>> 
>> Cheers,
>> 
>> Edgar
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___ OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___ OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Http library usage by clients

[Adam Young]

On 06/27/2013 10:35 AM, Thierry Carrez wrote:

Adam Young wrote:

Right now Keystone provides so called bearer tokens: This means that whoever 
has a token can do whatever the token entitles him to do. If I
manage to get somebody's token I can do whatever this person is able to do.

Right. Tokens are considered secrets for that reason.

To be specific, symmetric shared secrets.




To fix it, the other services that use tokens to:

1. Authenticate the identity
2. Match the name in the token to the  identity that authenticated the 
connection.

If the names match then you can be sure that the user that connected to the 
service and presented a token is the same user that acquired the token from 
keystone in the first place.

That sounds like an extra layer of security rather than a "fix" ?
If you consider "bearer tokens" to be sufficient security, then yes.  
If, on the other hand, bearer tokens are seen as a security risk, then 
it is a fix.





To make this happen we need to add authentication to the connections between 
clients and services.

To be able to do that we need to
1. Enable multiple forms of authentication per client.  The best way to do this 
is to use a common client library, which we have developed in keystoneclient
2. Use the 'requests' libraray for HTTP across all clients
3. Enable running the API servers in Apache HTTPD.  Making Eventlet support 
X509 CLient certs and Kerberos is going to be difficult, and the likelihood of 
introducing a security problem is high.

Devil's advocate says: the key idea behind Keystone was to centralize
authentication, though. Doesn't this extra layer kind of defeat that ?
Why would you need tokens at all, with a strongly-authenticated
connection to the API servers ?
Keystone centralizes both authentication and authorization.  It offloads 
the need to store passwords from all of  the various services to Keystone.


However,  authentication based solely on userid/password has a well 
documented body of known issues.  I am proposing that we use the more 
secure mechanisms for authentication, and limit keystone's role to 
authorization data.





[...]
So this raises a couple of points.
- We need to get Nova, Quantum and Cinder to use keystoneclient.

I'm actually surprised that they don't, so +1 :)


- Eventlet is mostly gone from the clients already. I'm not sure how
many of those http requests would end up actually blocking.

+1


- It would appear that clients have all at some point taken a central
layout approach and with it taken httplib. We probably can't get them
all changed over to requests before we try to add kerberos.

I'm not sure they would be so opposed to the idea. Especially
considering the next point.


- There is already a number of concerns around the way we use https. By
default httplib does not verify https certificates, requests does and
provides global ways of setting the bundle.
https://wiki.openstack.org/wiki/SecureClientConnections already
advocates for the transfer to requests with some interesting examples
like https://bugs.launchpad.net/python-glanceclient/+bug/1079692
(Server's name isn't verified when using https)

We definitely need a more consistent support of https rather than so
many different implementations that fail in so many different ways. FWIW
we'd consider absence of server cert checking in Python client libraries
connections as a vulnerability, so please report as a security bug any
occurrence of that.

Regards,




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Networking] Basic Bug Etiquette

[Maru Newby]

I'd like to reminder all Neutron contributors that if you are not the assignee 
for a bug, you should be consulting the assignee before you consider 
reassigning the bug to yourself or others.  Failing to do so is not only 
disrespectful, but may also result in unnecessary work.  It could be that the 
assignee has been making progress on the problem - code or otherwise - that 
would be duplicated by the new assignee.  Or the assignee could have 
specialized knowledge that makes them best equipped to fix the bug.  In any 
case, please ensure that bugs are not reassigned without the involvement of the 
current assignee.

Thanks for reading,


m.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Sample config file location inconsistency

[Flavio Percoco]

On 25/06/13 11:03 +0800, Zhongyue Luo wrote:

Hi team

I'm currently trying to move the generate_sample.sh script in nova to oslo.

Before pushing the patch to gerrit, I wanted to give the output directory a
default value if it was not stated so I was wondering where projects put their
sample config file at and did this:

find . -name "*.conf*" ! -path "*.tox*" ! -path "*.venv*" | grep etc

results:
./ceilometer/etc/ceilometer/ceilometer.conf.sample
./cinder/etc/cinder/cinder.conf.sample
./nova/etc/nova/nova.conf.sample
./swift/etc/swift.conf-sample
./tempest/etc/tempest.conf.sample
./glance/etc/glance-cache.conf
./quantum/etc/quantum.conf
./keystone/etc/keystone.conf.sample

You can see that ceilometer, cinder, and nova put their sample config files on
./etc/$PROJECTNAME while the others put it on ./etc

So would this inconsistency be a problem?

IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue.

Thoughts?




FWIW, I don't think this is an issue but I also prefer
etc/$PROJECTNAME

Cheers,
FF

--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking

[Flavio Percoco]

On 19/06/13 15:51 +0200, Thierry Carrez wrote:


Thoughts ?


Although it is not an integrated project - not even incubated - we've
been doing this for Marconi as well and it's been quite a pain. Also,
I've been following how Glance's blueprints have evolved and again,
I've noticed how hard it is to keep those fields synced and updated.
So, a big +1 from my side.

Cheers,
FF

--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Http library usage by clients

[Adam Young]

On 06/27/2013 10:45 PM, Simo Sorce wrote:

On Thu, 2013-06-27 at 17:49 -0700, Clint Byrum wrote:

On 2013-06-27 16:28, Jamie Lennox wrote:

On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:

On 27 June 2013 04:55, Adam Young  wrote:

Right now Keystone provides so called bearer tokens: This means that
whoever
has a token can do whatever the token entitles him to do. If I
manage to get somebody's token I can do whatever this person is able
to do.
To fix it, the other services that use tokens to:

1. Authenticate the identity
2. Match the name in the token to the  identity that authenticated
the
connection.

I am confused: HTTP is a message orientated protocol, connection
based
authentication is a terrible antipattern. Do you really mean
'connection' here?

More the HTTPs handshake i guess, the point is to have for example a
client certificate or kerberos identity that is used to connect to the
individual servers.

When a token is generated from keystone we put into the token a
reference to the kerberos or cert that was used to generate the token,
then when this token is used on a server the auth_token middleware
ensures that the same kerberos principal or certificate is used to
make
that connection as made the original. That means even if you get the
token unless you have the cert/kerberos id you can't use it.

The full blueprint is:
https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token


So you need the cert/kerberos ticket to both create and use the token.
So this means you are really trying to solve the problem of us
transmitting whole tokens for each request, making them open to
interception during transmission or theft from backing storage.


If the names match then you can be sure that the user that connected
to the
service and presented a token is the same user that acquired the
token from
keystone in the first place.

That would prevent the use case of 'create a token and hand it off'
which AIUI Heat depends on/will depend on.

Yes it would, but this is where heat would need to make use of the
trusts mechanism that was released with Grizzly, something that i
understand is planned anyway.


Indeed it is. But right now, the most excellent "make an EC2 keypair
and sign stuff with it" scheme is working out pretty well. That scheme
at least eliminates the transmission vulnerability.

Using a private key to sign requests is certainly an option that is
certainly to be considered.


It was  considered.  However, when you get down to the management of 
those keys, and how to sign the messages, it is no less complex than 
dealing with X509 Certificates, and X509 is already implemented.


X509 has a format for authentication information in a separate signed 
document from the initial certificate itself, but deployment of it is 
not very wide spread.  From our perspective, it makes more sense to 
continue to use Keystone tokens for authorization information, and link 
it to a secure Authentication source.  We are giving people the choice 
between X509 and Kerberos out the door, although any other secure 
authentication source would be viable as well.




In order to do that thought it would be easier if all clients would use
the same http library and keystone client so that signing can also be
done mostly transparently to the clients by hooking into the http
library and signing the request before it is sent.

Simo.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Rating engine for BillingStack

[Endre Karlson]

Hi, I would like to get some input on what kind of rating rules engine we
could use for BS.

Basically there are two alternatives as we see it now:
Drools as a service besides the Python components in BS using
https://github.com/droolsjbpm/drools-wb as a UI and interact with it as a
webservice
Python Intellect

Does anyone else have input on the matter?

Endre
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Http library usage by clients

[Chmouel Boudjnah]

On Fri, Jun 28, 2013 at 10:12 AM, Steven Hardy  wrote:
> Obviously long-term a keystone native way to sign requests would be great,
> and could be used by Heat, and e.g Swift which has it's own method for
> generating pre-signed URLs.


fyi: only when you are using the temporary url feature you are
generating pre-signed URL (compared to S3 where it's always I think).

Chmouel.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Nova API extensions NOT to be ported to v3

[Christopher Yeoh]

Hi,

The following is a list of API extensions for which there are no plans to
port. Please shout if you think any of them needs to be!

baremetal_nodes.py
os_networks.py
networks_associate.py
os_tenant_networks.py
virtual_interfaces.py
createserverext.py
floating_ip_dns.py
floating_ip_pools.py
floating_ips_bulk.py
floating_ips.py
cloudpipe.py
cloudpipe_update.py
volumes.py

Also I'd like to propose that after H2 any new API extension submitted HAS
to have a v3 version. That will give us enough time to ensure that the V3
API in Havana can do everything that the V2 one except where we explicitly
don't want to support something.

For developers who have had new API extensions merged in H2 but haven't
submitted a v3 version, I'd appreciate it if you could check the following
etherpad to see if your extension is on the list and put it on there ASAP
if it isn't there already:

https://etherpad.openstack.org/NovaV3ExtensionPortWorkList

I've tried to keep track of new API extensions to make sure we do v3 ports
but may have missed some.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Christopher Yeoh]

On Fri, Jun 28, 2013 at 12:12 PM, Russell Bryant
wrote:The results are much better than I was
afraid of.  On average across
all

> projects, patches waiting for review have an age of just under 14 days
> since they were first posted.  Nova is below average, sitting at an
> average of just over 10 days.  That doesn't seem bad at all, to me.
>
>
FWIW that matches pretty closely with my experience with the v3 api patches
for which there have been a reasonable volume of changesets with pretty
similar review complexity. From submission to merging, if there are no or
only very minor issues with the changeset, then it takes around two weeks.

I think its a very useful stat to have (and to monitor) so people have a
rough idea of how long before a reasonably well polished changeset needs to
be submitted before a deadline. In most cases, except perhaps for fairly
simple bug fixes, I think pushing something just a week before is being
pretty optimistic.


Suggestions for additional tweaks welcome.
>
>
How about time since first revision or -1 applied (but not including -1s by
Jenkins due to gate flakiness), whichever is shorter. That eliminates non
trivial rebases which I've found are often required after about 7 days but
doesn't push out the numbers where the submitter is slow in updating.

Regards,

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Unified logging and Eventlet conflict

[Doug Hellmann]

On Thu, Jun 27, 2013 at 11:35 PM, Adam Young  wrote:

> On 06/27/2013 08:43 AM, Davanum Srinivas wrote:
>
>> Lance, Doug,
>> Looks like eventlet.patcher.is_monkey_**patched(thread) is a reasonable
>> check to switch to to a thread-local implementation.
>>
>
> Doesn't it make more sense to have anything Eventlet based explicitly
> activated?  For Keystone, we have isolated all monkeypatching to be done by
> the process that starts the Keystone server.  Adding an additional call in
> there to activate the thread local storage for greenthreads is reasonable
> from our perspective.


In principle does, but I think that would require more changes. When we get
to the point where other services aren't using eventlet, it might make
sense to change the default (OTOH, we may be able to drop the use of the
locals module altogether at that point, too, I don't know).


>
>
>
>> Doug,
>> did you mean threading.local with WeakValueDictionary?
>>
>
Yes, that looks like it would let us match up the semantics.

Doug


>
>> -- dims
>>
>> On Thu, Jun 27, 2013 at 8:15 AM, Doug Hellmann
>>  wrote:
>>
>>> This isn't something the deployer controls, so I don't know if we want
>>> it to
>>> go into a config setting.
>>>
>>> If we can't detect eventlet being used automatically, we could provide an
>>> initialization function in the locals module so projects could change the
>>> behavior when a process starts. The default mode would need to be
>>> eventlet,
>>> for now, but a thread-local implementation seems like an obvious
>>> alternative. And of course we would need the module to behave as it does
>>> now
>>> if the initialization is not explicitly called.
>>>
>>> Doug
>>>
>>> On Thu, Jun 27, 2013 at 8:03 AM, Davanum Srinivas 
>>> wrote:
>>>
 Lance,

 "is eventlet installed" a strong enough check? given that folks may
 pick up a python install that has eventlet installed w/o realizing it?

 Is there a way to check if the openstack process the code is running
 in is using eventlet or not? or the other choice is a flag in logging
 conf to switch to a non-eventlet implemenation?

 -- dims

 On Wed, Jun 26, 2013 at 8:17 PM, Lance D Bragstad 
 wrote:

> Hey all,
>
> Recently there has been some push to get a unified logging
> implementation
> pulled from Oslo-incubator into Keystone (Blueprint:
>
> https://blueprints.launchpad.**net/keystone/+spec/unified-**
> logging-in-keystone
> ).
> Keystone has been actively working to isolate eventlet code within
> Keystone
> and bringing in the current implementation from Oslo-incubator would go
> against that work, as /oslo-incubator/openstack/**common/log.py
> imports
> /oslo-incubator/openstack/**common/local.py which has a dependency on
> eventlet
>
> (https://github.com/openstack/**oslo-incubator/blob/master/**
> openstack/common/local.py#L22
> )
> and is used for storing references to contexts. I know there has been a
> couple of projects looking to not be dependent on eventlet and thought
> this
> might be a good topic for the mailing list, especially if these changes
> end
> up in Oslo-incubator.
>
> After discussion with a couple of the Keystone members, one option is
> to
> tweak local.py to check if eventlet is even installed (similar to def
> _ensure_subprocess here:
>
> https://github.com/openstack/**python-keystoneclient/blob/**
> master/keystoneclient/common/**cms.py#L11
> )
> and if it isn't then try implementing a different WeakLocal store not
> using
> corolocal.local. Any other ideas on how to approach this are more than
> welcome. Thanks!
>
>
>
> Best Regards,
>
> Lance Bragstad
> Software Engineer - OpenStack
> Cloud Solutions and OpenStack Development
> T/L 553-5409, External 507-253-5409
> ldbra...@us.ibm.com, Bld 015-2/C118
>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>
>

 --
 Davanum Srinivas :: http://davanum.wordpress.com

 __**_
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.**org 
 http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev

>>>
>>>
>>> __**_
>>> OpenStack-dev mailing list
>>> OpenStack-dev@l

Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking

[Thierry Carrez]

Thierry Carrez wrote:
> Thierry Carrez wrote:
>> A script will automatically and regularly align "series goal" with
>> "target milestone", so that the series and milestone views are
>> consistent (if someone sets target milestone to "havana-3" then the
>> series goal will be set to "havana").
> 
> Now if the Launchpad API was exporting the "series goal" property, that
> would be easier... investigating workarounds.

OK, my patch to properly expose "series goal" in the Launchpad API just
went in, so we are unblocked. I now have a script that we can run
regularly that will adjust the "series goal" automatically based on the
content of the "target milestone".

So the plan is, for every project:

1- I'll create a "future" series with "next" and "ongoing" milestones

2- You'll look into blueprints that are in your havana plan
(https://blueprints.launchpad.net/PROJECT/havana) but without a
milestone set, and consider moving them to one of those milestones in
"future" (or set a havana milestone target if appropriate)

3- We'll enable the script, which will clear all havana blueprints that
don't have a milestone target set (see (2))

4- From then on, blueprints proposers will just need to set a target
milestone, and drivers will just need to regularly look at "Undefined"
blueprints and set a priority for them based on how much they care:

- Essential: Would prefer not to release without that feature
- High: Important feature that we should have in the release
- Medium: Optional feature that should still be part of the roadmap
- Low: Optional feature that we should *not* follow on the release radar
(a.k.a. "stop blaming me if it doesn't make it")

We'll review all this plan at the next project/release status meeting
before giving it the final go.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[John Garbutt]

Interesting, thanks for trying that. I think this is the time people
"feel" the most.

It should help set expectations on how long it will take to get your
change into trunk. It seems, on average, to take two weeks.

Hopefully it is useful to spot reviews that are proving tricky to get
in, and they can be given some extra attention.

I agree, its hard to give anyone a goal on this one. We could try
count aggregate time on waiting for a reviewer throughout the life of
the patch, but I am not sure that will be any more useful.

John

On 28 June 2013 03:42, Russell Bryant  wrote:
> Greetings,
>
> The key metric I have been using for knowing whether we are keeping up
> with review requests is the average wait time for getting a review.  In
> a previous thread, we set a goal of keeping that under 4 days (at least
> by the end of the week, may be higher after a weekend).  This is
> calculated using the time that the *latest* patch revision was posted.
> We have been keeping up with this (Nova at 3.5 days right now).
>
> I've been getting a lot of complaints this week about review turnaround.
>  It's important to me that we're doing this well, but action needs to be
> based on real data.
>
> One of the theories was that patches are having to be rebased a bunch,
> so they have been waiting longer than the stats say.  True, but by how
> much?  The answer is now in the stats:
>
> http://russellbryant.net/openstack-stats/all-openreviews.html
>
> The results are much better than I was afraid of.  On average across all
> projects, patches waiting for review have an age of just under 14 days
> since they were first posted.  Nova is below average, sitting at an
> average of just over 10 days.  That doesn't seem bad at all, to me.
>
> So, if we have a problem, it's not Nova specific, at least.  It's harder
> to set a goal for this metric since it's not entirely in the hands of
> reviewers like the other one.
>
> Suggestions for additional tweaks welcome.
>
> Thanks,
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova]Discussion about resize and migrate status separation

[John Garbutt]

I am not sure its worth the extra calls.

Hopefully once we have live-migrate and cold-migrate/resize refactor
done we can add a new single API that better combines the different
approaches, which should remove the confusion.

Thinking about it, that should sove the issue about the different states too.

John

On 28 June 2013 09:18, guohliu  wrote:
> On 06/27/2013 07:05 PM, John Garbutt wrote:
>>
>> I haven't seen any plans to change this.
>>
>> The way I see it, the states make most sense for resize, which is the
>> end-user facing operation.
>>
>> Personally I see migrate as a more admin focused operation.
>> So to help simplify the code, I am OK with slightly confusing states
>> for those users.
>> The exception, I guess, is when users want to "re-balance" their
>> servers between availability zones.
>>
>> With any luck, post refactor, it should be easier to re-visit this,
>> and perhaps add those extra states.
>>
>> John
>>
>> On 27 June 2013 09:14, guohliu  wrote:
>>>
>>> Greetings,
>>>
>>> I apologize if this question was already covered and I missed it, as we
>>> know
>>> the migrate and resize share the same code path as well as instance
>>> status,
>>> notification message etc in current code base, somehow it might confuse
>>> the
>>> user when he/she perform migrate but get VERIFY_RESIZE status, and as far
>>> as
>>> I know this wasn't to be targeted in migrate refactor work, I just
>>> wondering
>>> to know do you think this is a issue? how about to separate migrate and
>>> resize with different instance status and notification message as well as
>>> task status? any comments would be appreciated.
>>>
>>> Best Regards
>>> Guohliu
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> Hi John,
>
> Thanks for your comments, it makes sense to me, the resize is all good, we
> might just need to slightly separate migrate status based on resize code
> logic, but one exception is we might need to add confirm migrate and revert
> migrate in admin action. thoughts?
>
>
> Regards
> Guohliu
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

[Akihiro MOTOKI]

The detail parameters are described in the API reference. It is the best
document to know the parameters'detail at the moment.
http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html

In general options of quantum command can be mapped to API attributes one
to one.

Akihiro


2013年6月28日金曜日 Rahul Sharma rahulsharma...@gmail.com:

> Thanks Aaron for your kind help. It worked. Is there any doc which lists
> all the possible commands and their usage for quantum? because --help
> doesn't help in identifying all the parameters, is there any reference
> which one can use to get the complete command syntax?
>
> -Regards
> Rahul Sharma
>
>
> On Fri, Jun 28, 2013 at 12:45 PM, Aaron Rosen  wrote:
>
>
>
>
> On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma 
> wrote:
>
> Hi Aaron,
>
> Thanks for the CLI. I have a query related to that. I have a multinode
> openstack-deployment. To allow all the ports of VM accessible from outside,
> I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon
> dashboard. Now this rule is pushed to Quantum database as well as Nova
> database.
>
>
> This is only stored in the quantum database. When querying nova for this
> information it will query quantum.
>
>
> root@controller1:~# quantum security-group-rule-list --
> --tenant-id=40a7cd193a794161bfefd62364e64d03
>
>
> +--++---+--+--+--+
> | id   | security_group | direction |
> protocol | remote_ip_prefix | remote_group |
>
> +--++---+--+--+--+
> | 24cd1f88-8b50-45da-822c-e932178aeffd | default| egress
> |  |  |  |
> | 54e72726-61d5-4253-a92f-47a84d0ec882 | default| ingress
> |  |  | default  |
> | 977c7aff-9649-4037-af03-086d5db4955a | default| egress
> |  |  |  |
> *| d3e0d85c-b9c7-4fc3-9009-d14ed085876a | default| ingress   |
> tcp  | 0.0.0.0/0|  |*
> | e0887d63-bee2-4848-acce-c193aa03ef02 | default| ingress
> |  |  | default  |
>
> +--++---+--+--+--+
>
> root@controller1:~# nova --os-username test --os-password test
> --os-tenant-name "test" secgroup-list-rules default
> +-+---+-+---+--+
> | IP Protocol | From Port | To Port | IP Range  | Source Group |
> +-+---+-+---+--+
> | | -1| -1  |   | default  |
> | | -1| -1  |   | default  |
> *| tcp | 1 | 65535   | 0.0.0.0/0 |  |*
> +-+---+-+---+--+
>
> How can I do the same using CLI? Is there any single command which will do
> this task or I need to manually do this from UI? I tried adding rule using
> nova and quantum commands but its giving me error in taking parameters like
> 0.0.0.0/0 or due to something else which is not evident from the error
> message. I am using Grizzly release.
>
>
> quantum security-group-rule-create --protocol tcp --ethertype IPv4
> --port-range-min 1 --port-range-max 65535  --remote-ip-prefix 0.0.0.0/0
>  default
>
> or
>
> nova secgroup-add-rule default tcp 1 65355 0.0.0.0/0
>
>
> Thanks and Regards
>
>

-- 
Akihiro MOTOKI 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

[Rahul Sharma]

Thanks Aaron for your kind help. It worked. Is there any doc which lists
all the possible commands and their usage for quantum? because --help
doesn't help in identifying all the parameters, is there any reference
which one can use to get the complete command syntax?

-Regards
Rahul Sharma


On Fri, Jun 28, 2013 at 12:45 PM, Aaron Rosen  wrote:

>
>
>
> On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma 
> wrote:
>
>> Hi Aaron,
>>
>> Thanks for the CLI. I have a query related to that. I have a multinode
>> openstack-deployment. To allow all the ports of VM accessible from outside,
>> I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon
>> dashboard. Now this rule is pushed to Quantum database as well as Nova
>> database.
>>
>
> This is only stored in the quantum database. When querying nova for this
> information it will query quantum.
>
>
>> root@controller1:~# quantum security-group-rule-list --
>> --tenant-id=40a7cd193a794161bfefd62364e64d03
>>
>>
>> +--++---+--+--+--+
>> | id   | security_group | direction |
>> protocol | remote_ip_prefix | remote_group |
>>
>> +--++---+--+--+--+
>> | 24cd1f88-8b50-45da-822c-e932178aeffd | default| egress
>> |  |  |  |
>> | 54e72726-61d5-4253-a92f-47a84d0ec882 | default| ingress
>> |  |  | default  |
>> | 977c7aff-9649-4037-af03-086d5db4955a | default| egress
>> |  |  |  |
>> *| d3e0d85c-b9c7-4fc3-9009-d14ed085876a | default| ingress   |
>> tcp  | 0.0.0.0/0|  |*
>> | e0887d63-bee2-4848-acce-c193aa03ef02 | default| ingress
>> |  |  | default  |
>>
>> +--++---+--+--+--+
>>
>> root@controller1:~# nova --os-username test --os-password test
>> --os-tenant-name "test" secgroup-list-rules default
>> +-+---+-+---+--+
>> | IP Protocol | From Port | To Port | IP Range  | Source Group |
>> +-+---+-+---+--+
>> | | -1| -1  |   | default  |
>> | | -1| -1  |   | default  |
>> *| tcp | 1 | 65535   | 0.0.0.0/0 |  |*
>> +-+---+-+---+--+
>>
>> How can I do the same using CLI? Is there any single command which will
>> do this task or I need to manually do this from UI? I tried adding rule
>> using nova and quantum commands but its giving me error in taking
>> parameters like 0.0.0.0/0 or due to something else which is not evident
>> from the error message. I am using Grizzly release.
>>
>>
> quantum security-group-rule-create --protocol tcp --ethertype IPv4
> --port-range-min 1 --port-range-max 65535  --remote-ip-prefix 0.0.0.0/0
>  default
>
> or
>
> nova secgroup-add-rule default tcp 1 65355 0.0.0.0/0
>
>
>> Thanks and Regards
>> Rahul Sharma
>>
>>
>> On Thu, Jun 27, 2013 at 10:25 PM, Aaron Rosen  wrote:
>>
>>> Hi Rahul,
>>>
>>> The issue is that you are running as an admin user so it shows all the
>>> security groups for every tenant. If you want to list the security groups
>>> for just one particular tenant you can do this:
>>>
>>>
>>>  quantum security-group-list  -- --tenant-id=
>>>
>>>
>>> Aaron
>>>
>>>
>>>
>>> On Thu, Jun 27, 2013 at 5:54 AM, Rahul Sharma 
>>> wrote:
>>>
 Hi All,

 I have a query regarding the security-groups. Whenever I create a new
 tenant, a default security-group is created for that tenant. Now I want to
 find out which security-group is for which tenant? If I run "quantum
 security-group-list", then it shows me the security-groups is below 
 format:-
 root@controller1:~# quantum security-group-list

 +--+-+-+
 | id   | name|
 description |

 +--+-+-+
 | 429f8e9e-edfc-4173-b599-9d91d9f7cb7d | default |
 default |
 | 47cbba23-6a73-44dc-b7c4-46794ed7aa5a | default |
 default |
 | 5ea93a09-6d96-4688-8005-99f8de4f20d7 | default |
 default |
 | 81cb819c-ffc2-4c26-b390-8e24b11f3443 | default |
 default |
 | 83778bc4-bbd2-4e02-9131-c5d4cf8a9e9b | default |
 default |
 | 9ca14384-00f0-4597-acd4-00bdec1

Re: [openstack-dev] [Nova]Discussion about resize and migrate status separation

[guohliu]

On 06/27/2013 07:05 PM, John Garbutt wrote:

I haven't seen any plans to change this.

The way I see it, the states make most sense for resize, which is the
end-user facing operation.

Personally I see migrate as a more admin focused operation.
So to help simplify the code, I am OK with slightly confusing states
for those users.
The exception, I guess, is when users want to "re-balance" their
servers between availability zones.

With any luck, post refactor, it should be easier to re-visit this,
and perhaps add those extra states.

John

On 27 June 2013 09:14, guohliu  wrote:

Greetings,

I apologize if this question was already covered and I missed it, as we know
the migrate and resize share the same code path as well as instance status,
notification message etc in current code base, somehow it might confuse the
user when he/she perform migrate but get VERIFY_RESIZE status, and as far as
I know this wasn't to be targeted in migrate refactor work, I just wondering
to know do you think this is a issue? how about to separate migrate and
resize with different instance status and notification message as well as
task status? any comments would be appreciated.

Best Regards
Guohliu


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hi John,

Thanks for your comments, it makes sense to me, the resize is all good, 
we might just need to slightly separate migrate status based on resize 
code logic, but one exception is we might need to add confirm migrate 
and revert migrate in admin action. thoughts?


Regards
Guohliu


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Http library usage by clients

[Steven Hardy]

On Thu, Jun 27, 2013 at 05:49:00PM -0700, Clint Byrum wrote:
> On 2013-06-27 16:28, Jamie Lennox wrote:
> >On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:
> >>On 27 June 2013 04:55, Adam Young  wrote:
> >>>Right now Keystone provides so called bearer tokens: This
> >>>means that whoever
> >>>has a token can do whatever the token entitles him to do. If I
> >>>manage to get somebody's token I can do whatever this person
> >>>is able to do.
> >>>To fix it, the other services that use tokens to:
> >>>
> >>>1. Authenticate the identity
> >>>2. Match the name in the token to the  identity that
> >>>authenticated the
> >>>connection.
> >>
> >>I am confused: HTTP is a message orientated protocol, connection
> >>based
> >>authentication is a terrible antipattern. Do you really mean
> >>'connection' here?
> >
> >More the HTTPs handshake i guess, the point is to have for example a
> >client certificate or kerberos identity that is used to connect to the
> >individual servers.
> >
> >When a token is generated from keystone we put into the token a
> >reference to the kerberos or cert that was used to generate the token,
> >then when this token is used on a server the auth_token middleware
> >ensures that the same kerberos principal or certificate is used to
> >make
> >that connection as made the original. That means even if you get the
> >token unless you have the cert/kerberos id you can't use it.
> >
> >The full blueprint is:
> >https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token
> >
> 
> So you need the cert/kerberos ticket to both create and use the
> token. So this means you are really trying to solve the problem of
> us transmitting whole tokens for each request, making them open to
> interception during transmission or theft from backing storage.
> 
> >>>If the names match then you can be sure that the user that
> >>>connected to the
> >>>service and presented a token is the same user that acquired
> >>>the token from
> >>>keystone in the first place.
> >>
> >>That would prevent the use case of 'create a token and hand it off'
> >>which AIUI Heat depends on/will depend on.
> >
> >Yes it would, but this is where heat would need to make use of the
> >trusts mechanism that was released with Grizzly, something that i
> >understand is planned anyway.
> >
> 
> Indeed it is. But right now, the most excellent "make an EC2 keypair
> and sign stuff with it" scheme is working out pretty well. That
> scheme at least eliminates the transmission vulnerability.

We're getting pretty OT here, but since you mention it, I think we just
need a way to generate an ec2 keypair from a trust token, and ideally scope
that token to a specific endpoint.

Obviously long-term a keystone native way to sign requests would be great,
and could be used by Heat, and e.g Swift which has it's own method for
generating pre-signed URLs.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

[Aaron Rosen]

On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma wrote:

> Hi Aaron,
>
> Thanks for the CLI. I have a query related to that. I have a multinode
> openstack-deployment. To allow all the ports of VM accessible from outside,
> I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon
> dashboard. Now this rule is pushed to Quantum database as well as Nova
> database.
>

This is only stored in the quantum database. When querying nova for this
information it will query quantum.


> root@controller1:~# quantum security-group-rule-list --
> --tenant-id=40a7cd193a794161bfefd62364e64d03
>
> +--++---+--+--+--+
> | id   | security_group | direction |
> protocol | remote_ip_prefix | remote_group |
>
> +--++---+--+--+--+
> | 24cd1f88-8b50-45da-822c-e932178aeffd | default| egress
> |  |  |  |
> | 54e72726-61d5-4253-a92f-47a84d0ec882 | default| ingress
> |  |  | default  |
> | 977c7aff-9649-4037-af03-086d5db4955a | default| egress
> |  |  |  |
> *| d3e0d85c-b9c7-4fc3-9009-d14ed085876a | default| ingress   |
> tcp  | 0.0.0.0/0|  |*
> | e0887d63-bee2-4848-acce-c193aa03ef02 | default| ingress
> |  |  | default  |
>
> +--++---+--+--+--+
>
> root@controller1:~# nova --os-username test --os-password test
> --os-tenant-name "test" secgroup-list-rules default
> +-+---+-+---+--+
> | IP Protocol | From Port | To Port | IP Range  | Source Group |
> +-+---+-+---+--+
> | | -1| -1  |   | default  |
> | | -1| -1  |   | default  |
> *| tcp | 1 | 65535   | 0.0.0.0/0 |  |*
> +-+---+-+---+--+
>
> How can I do the same using CLI? Is there any single command which will do
> this task or I need to manually do this from UI? I tried adding rule using
> nova and quantum commands but its giving me error in taking parameters like
> 0.0.0.0/0 or due to something else which is not evident from the error
> message. I am using Grizzly release.
>
>
quantum security-group-rule-create --protocol tcp --ethertype IPv4
--port-range-min 1 --port-range-max 65535  --remote-ip-prefix 0.0.0.0/0
 default

or

nova secgroup-add-rule default tcp 1 65355 0.0.0.0/0


> Thanks and Regards
> Rahul Sharma
>
>
> On Thu, Jun 27, 2013 at 10:25 PM, Aaron Rosen  wrote:
>
>> Hi Rahul,
>>
>> The issue is that you are running as an admin user so it shows all the
>> security groups for every tenant. If you want to list the security groups
>> for just one particular tenant you can do this:
>>
>>
>>  quantum security-group-list  -- --tenant-id=
>>
>>
>> Aaron
>>
>>
>>
>> On Thu, Jun 27, 2013 at 5:54 AM, Rahul Sharma 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have a query regarding the security-groups. Whenever I create a new
>>> tenant, a default security-group is created for that tenant. Now I want to
>>> find out which security-group is for which tenant? If I run "quantum
>>> security-group-list", then it shows me the security-groups is below format:-
>>> root@controller1:~# quantum security-group-list
>>>
>>> +--+-+-+
>>> | id   | name|
>>> description |
>>>
>>> +--+-+-+
>>> | 429f8e9e-edfc-4173-b599-9d91d9f7cb7d | default |
>>> default |
>>> | 47cbba23-6a73-44dc-b7c4-46794ed7aa5a | default |
>>> default |
>>> | 5ea93a09-6d96-4688-8005-99f8de4f20d7 | default |
>>> default |
>>> | 81cb819c-ffc2-4c26-b390-8e24b11f3443 | default |
>>> default |
>>> | 83778bc4-bbd2-4e02-9131-c5d4cf8a9e9b | default |
>>> default |
>>> | 9ca14384-00f0-4597-acd4-00bdec10ab5c | default |
>>> default |
>>> | a0e42478-ff76-4513-a698-7d7b0450a878 | default |
>>> default |
>>> | da2cb126-520e-475b-81f3-5d0d2f05 | default |
>>> default |
>>>
>>> +--+-+-+
>>>
>>> How can I figure out the default security-group to a particular
>>> tenant/user? There is no