[openstack-dev] Questions regarding OpenStack CI tools

[GROSZ, Maty (Maty)]

Hey,

A question regarding OpenStack CI tools….
Does OpenStack CI process use any monitor code cleanliness tool, code coverage 
tool or any monitor memory consumption/leaks tools?
Thanks,

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

[openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms screen in horizon

[ITZIKOWITZ, Noy (Noy)]

Hi,
Following our Tokyo meetings and chats around vitrage and ceilometer, we are 
now working on vitrage blueprints for Mitaka.
One of the blueprints is around ‘active alarms’ screen in the horizon dashboard.
Is there any open blueprint for that, or should I open a new one?
Was this discussed in the past?
Thanks,
Noy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Questions about BP for enable/disable heat-engine

[Ethan Lynn]

Hi,
  I notice that there is a BP for enable/disable heat-engine, 
https://blueprints.launchpad.net/heat/+spec/heat-manage-service-disable-enable 

  This feature is important when maintain heat-engine in HA production, if one 
controller node needs to be replaced, we can disable heat-engine in this node 
and then replace this node.
  I would like to know the reasons why this BP stops working, is there any 
technical issues to implement it? I don’t quite understand the issues raised by 
inc0, any one can explain it? 
  I would like to see this feature come into heat, and I would like to pay some 
effort on it.

Best Regards,
Ethan Lynn



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

[openstack-dev] [Heat] Deprecate heat-keystone-setup

[xuanlangjian]

I would like to deprecate heat-keystone-setup tool in bin folder, because it's 
still using keystone client for execute keystone commands, and I don’t know if 
anyone still needs it. If no one use it, I think it’s better delete it instead 
of maintain it to use openstack client. I would like to know if it’s ok to 
remove it?

Relate bugs:
https://bugs.launchpad.net/heat/+bug/1460884 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" and "dns_name"?

[Miguel Lavalle]

Hi Neil,

You are correct about dns_name and dns_assignment.

Prior to adding this feature to Neutron, all your ports were getting
implicitly what I named "dns_assignment". It was created by the the DHCP
agent and pushed to the dnsmasq instance associated with the port's
network. This implicit  dns_assignment was of the form 'hostname' =
'host-10.65.0.4', 'ip_address' = '10.65.0.4', 'fqdn' =
'host-10-65-0-4.opentacklocal'. It wasn't a dictionary. It was just a
record in the files that the DHCP agent uses to control the behavior of the
dnsmasq instances and it was never seen (for the most part) by the users.
All I did was to make this "dns_assignment" explicit, give it a name as an
attribute in the API, give the user visibility of it and give the user
control of the names associated with it through the API (moving its
generation to the Neutron server as a consequence). This is turn is
allowing me to implement  on the Nova side functionality to assign to ports
associated with an instance the hostname of said instance, per this spec:
https://review.openstack.org/#/c/90150/

Thanks for your interest ion this feature.

Regards

Miguel


On Fri, Nov 6, 2015 at 4:28 AM, Neil Jerram 
wrote:

> Hi Miguel,
>
> I’ve just been looking at this, and have deduced the following summary of
> the new dns_name and dns_assignment fields:
>
> - dns_name is a simple name, like 'vm17'. It is a writable port field, and
> gets combined with a dns_domain that is specified elsewhere.
>

> - dns_assignment is a server-generated read-only field‎, holding a list of
> dicts like {'hostname': 'vm17', 'ip_address': '10.65.0.4', 'fqdn': '
> vm17.datcon.co.uk'}.
>
> Can you confirm whether that's correct?
>
> What is the reason (or requirement) for dns_assignment being able to
> specify hostname and fqdn on a per-IP-address basis?  Does it ever make
> sense for a VM to associate a different hostname with different NICs or IP
> addresses?
>
> Many thanks,
> Neil
>
>
>
> From: Miguel Lavalle [mailto:mig...@mlavalle.com]
> Sent: 14 October 2015 04:22
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][dns]What the meaning of
> "dns_assignment" and "dns_name"?
>
> Zhi Chang,
> Thank you for your questions. We are in the process of integrating Neutron
> and Nova with an external DNS service, using Designate as the reference
> implementation. This integration is being achieved in 3 steps. What you are
> seeing is the result of only the first one. These steps are:
> 1) Internal DNS integration in Neutron, which merged recently:
> https://review.openstack.org/#/c/200952/. As you may know, Neutron has an
> internal DHCP / DNS service based on dnsmasq for each virtual network that
> you create. Previously, whenever you created a port on a given network,
> your port would get a default host name in dnsmasq of the form
> 'host-xx-xx-xx-xx.openstacklocal.", where xx-xx-xx-xx came from the port's
> fixed ip address "xx.xx.xx.xx" and "openstacklocal" is the default domain
> used by Neutron. This name was generated by the dhcp agent. In the above
> mentioned patchset, we are moving the generation of these dns names to the
> Neutron server, with the intent of allowing the user to specify it. In
> order to do that, you need to enable it by defining in neutron.conf the
> 'dns_domain' parameter with a value different to the default
> 'openstacklocal'. Once you do that, you can create or update a port and
> assign a value to its 'dns_name' attribute. Why is this useful? Please read
> on.
>
> 2) External DNS integration in Neutron. The patchset is being worked now:
> https://review.openstack.org/#/c/212213/. The functionality implemented
> here allows Neutron to publish the dns_name associated with a floating ip
> under a domain in an external dns service. We are using Designate as the
> reference implementation, but the idea is that in the future other DNS
> services can be integrated.. Where does the dns name and domain of the
> floating ip come from? It can come from 2 sources. Source number 1 is the
> floating ip itself, because in this patchset we are adding a dns_name and a
> dns_domain attributes to it. If the floating ip doesn't have a dns name and
> domain associated with it, then they can come from source number 2: the
> port that the floating ip is associated with (as explained in point 1,
> ports now can have a dns_name attribute) and the port's network, since this
> patchset adds dns_domain to networks.
> 3) Integration of Nova with Neutron's DNS. I have started the
> implementation of this and over the next few days will push the code to
> Gerrit for first review. When an instance is created, nova will request to
> Neutron the creation of the corresponding port specifying the instance's
> hostname in the port's 'dns_name' attribute (as explained in point 1). If
> the network where that port lives has a dns_domain 

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

[Michael Still]

+1

Alex does good work.

Michael

On Sat, Nov 7, 2015 at 2:32 AM, John Garbutt  wrote:

> Hi,
>
> I propose we add Alex Xu[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the API.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1]http://stackalytics.com/?module=nova-group_id=xuhj=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [ironic] Mitaka priorities

[Naohiro Tamura]

Jim, Devananda, and Ironicers

Thanks for your all coordination and efforts to have the fruitful meeting.
I was very glad to see Ironicers in face to face beyond a year finally.

Related to the priority, generally speaking, priority should be based on a
certain vision.
And I had an opportunity to present our vision to the OpenStack community
widely in the summit.

 "Ironic Towards Truly Open and Reliable, Eventually for Mission Critical"
 https://www.youtube.com/watch?v=MpSqDA3jo0I

http://www.slideshare.net/naohirot/ironic-towards-truly-open-and-reliable-eventually-for-mission-critical

I think, however, most of Ironicers were attending to the Ironic work
session which was held in parallel.

So let me ask Ironicers some comment or feedback about the vision I
presented at this time since most of Ironicers are supposed to get back to
work from this week.

Basically I'd like to know what you thought :-)

Thanks.
--
Naohiro Tamura
Fujitsu Limited


On Wed, Nov 4, 2015 at 11:43 PM, Jim Rollenhagen 
wrote:

> Hi folks,
>
> I posted a review to add our Mitaka priorities to our specs repo:
> https://review.openstack.org/#/c/241223/
>
> Ruby made a good point that not everyone was at the summit and she'd
> like buyoff on the patch from all cores before we land it. I tend to
> agree, so I ask that cores that were not in the planning session please
> review this ASAP.
>
> There are some cores that were there and still in Tokyo, so in the
> interest of landing this quickly, I'm okay with moving forward without
> them.
>
> Thanks!
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [designate]question about the lock‏

[LeeKies]

In the service:central, function: synchronized_domain, hold the lock in 
threading.local. 
My question is when I use multithreading or multiprocess, does the 
synchronized_domain take effect ?
Thankskieslee __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Kuryr] - IRC Meetings

[Taku Fukushima]

Hi,

As we discussed in the summit, the time of our IRC meeting would be changed
from 15 UTC on Monday to 3 UTC on Tuesday. However, I think I missed when
this would be applied and it seems it has not been announced clearly in the
text format. Could you give use the accurate date and time when we have the
next meeting to make it sure?

https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track-kuryr

Best regards,
Taku Fukushima

On Tue, Oct 6, 2015 at 11:36 PM, Gal Sagie  wrote:

> Hello Everyone,
>
> Our current IRC meeting time is 15:00 UTC every Monday.
> I have received several requests from US people saying its hard
> for them to attend at this early time.
>
> We want to allow anyone that shows interest in the project to join, so we
> discussed this in yesterday's IRC meeting and decided to run an
> "experiment".
> We will have an additional non-formal IRC meeting next week and the week
> after in a time more suitable for people in that timezone.
>
> If we see there is a good enough interest we will consider conducting
> alternating meetings.
>
> If you are in that area and would like to join our meetings, please
> suggest a time that fits
> you, please still try to make it as early as possible for people from
> Europe.
>
> Thanks
> Gal.
>
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] weekly meeting #58 and next week

[Matt Fischer]

We have a very light schedule if anyone would like to discuss bugs or other
issues, it would be a good time to do so.

On Sat, Nov 7, 2015 at 12:29 PM, Emilien Macchi 
wrote:

> Hello!
>
> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
> in #openstack-meeting-4:
>
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110
>
> I'm off all next week (holidays without IRC, and rare access to
> e-mails...), so mfish will be chair.
>
> During the week, if you have any problem with Puppet CI, you can ping
> degorenko on IRC.
> When I come back, I'll work on 7.0.0 release to create our
> stable/liberty branch.
>
> Thanks and see you soon,
> Emilien
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Questions regarding OpenStack CI tools

[Boris Pavlovic]

Hi Maty,

Usually in python projects are used next thing:
- cover - for unit test coverage
- pep8 + custom hacking rules - to check code styles
- pylint - to check even more code styles


Best regards,
Boris Pavlovic


On Sun, Nov 8, 2015 at 4:41 AM, GROSZ, Maty (Maty) <
maty.gr...@alcatel-lucent.com> wrote:

> Hey,
>
> A question regarding OpenStack CI tools….
> Does OpenStack CI process use any monitor code cleanliness tool, code
> coverage tool or any monitor memory consumption/leaks tools?
> Thanks,
>
> Maty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kuryr] gerrit/git review problem error code 10061

[Baohua Yang]

Hi,
   Anyone recently meet such problem after cloning the latest code from
kuryr?
   Try proxy also, but not solved.

$ git review -s
Problem running 'git remote update gerrit'
Fetching gerrit
FATAL: Unable to connect to relay host, errno=10061
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch gerrit
Traceback (most recent call last):
  File "d:\Python27\lib\runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "d:\Python27\lib\runpy.py", line 72, in _run_code
exec code in run_globals
  File "d:\Python27\Scripts\git-review.exe\__main__.py", line 9, in 
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 1202, in main
set_hooks_commit_msg(remote, hook_file)
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 283, in
set_hooks_commit_msg
run_command_exc(CannotInstallHook, *cmd)
  File "d:\Python27\lib\site-packages\git_review\cmd.py", line 152, in
run_command_exc
raise klazz(rc, output, argv, env)
git_review.cmd.CannotInstallHook: Problems encountered installing
commit-msg hook
The following command failed with exit code 1
"scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg
.git\hooks\commit-msg"
---
FATAL: Unable to connect to relay host, errno=10061
ssh_exchange_identification: Connection closed by remote host


$ git remote show origin
* remote origin
  Fetch URL: git://git.openstack.org/openstack/kuryr
  Push  URL: git://git.openstack.org/openstack/kuryr
  HEAD branch: master
  Remote branch:
master tracked
  Local branch configured for 'git pull':
master merges with remote master
  Local ref configured for 'git push':
master pushes to master (local out of date)


   Thanks!

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

[openstack-dev] [kuryr] Current status of docker python lib supports for libnetwork

[Baohua Yang]

Hi, kuryr guys
I may not attend tmr's IRC meeting, hence make a quick sync here.
One task is to investigate the docker python lib support to libnetwork.
I checked the code here at https://github.com/docker/docker-py.
They do have the network api support in code (in api/network.py), as
 1. create_network
 2. remove_network
 3. inspect_network
 4. connect_container_to_network
 5. disconnect_container_from_network
 Those apis are implemented by calling the rest api directly.
 But those apis are not mentioned in doc yet.
 Thanks!

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

Re: [openstack-dev] [kuryr] gerrit/git review problem error code 10061

[Gareth]

TCP error code 10061: No connection could be made because the target
machine actively refused it.

find this from google, maybe helpful

On Mon, Nov 9, 2015 at 10:42 AM, Iury Gregory  wrote:
> Not sure if this can help you,
> Verify if your public key is in your gerrit account.
>
> Another thing you can try is to update your openstack account to foundation
> member, I had a similar error a while a go.
>
>
> 2015-11-08 23:13 GMT-03:00 Baohua Yang :
>>
>> Hi,
>>Anyone recently meet such problem after cloning the latest code from
>> kuryr?
>>Try proxy also, but not solved.
>>
>> $ git review -s
>> Problem running 'git remote update gerrit'
>> Fetching gerrit
>> FATAL: Unable to connect to relay host, errno=10061
>> ssh_exchange_identification: Connection closed by remote host
>> fatal: Could not read from remote repository.
>>
>> Please make sure you have the correct access rights
>> and the repository exists.
>> error: Could not fetch gerrit
>> Traceback (most recent call last):
>>   File "d:\Python27\lib\runpy.py", line 162, in _run_module_as_main
>> "__main__", fname, loader, pkg_name)
>>   File "d:\Python27\lib\runpy.py", line 72, in _run_code
>> exec code in run_globals
>>   File "d:\Python27\Scripts\git-review.exe\__main__.py", line 9, in
>> 
>>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 1202, in
>> main
>> set_hooks_commit_msg(remote, hook_file)
>>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 283, in
>> set_hooks_commit_msg
>> run_command_exc(CannotInstallHook, *cmd)
>>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 152, in
>> run_command_exc
>> raise klazz(rc, output, argv, env)
>> git_review.cmd.CannotInstallHook: Problems encountered installing
>> commit-msg hook
>> The following command failed with exit code 1
>> "scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg
>> .git\hooks\commit-msg"
>> ---
>> FATAL: Unable to connect to relay host, errno=10061
>> ssh_exchange_identification: Connection closed by remote host
>>
>>
>> $ git remote show origin
>> * remote origin
>>   Fetch URL: git://git.openstack.org/openstack/kuryr
>>   Push  URL: git://git.openstack.org/openstack/kuryr
>>   HEAD branch: master
>>   Remote branch:
>> master tracked
>>   Local branch configured for 'git pull':
>> master merges with remote master
>>   Local ref configured for 'git push':
>> master pushes to master (local out of date)
>>
>>
>>Thanks!
>>
>> --
>> Best wishes!
>> Baohua
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
>
> ~
> Att[]'s
> Iury Gregory Melo Ferreira
> Master student in Computer Science at UFCG
> E-mail:  iurygreg...@gmail.com
> ~
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

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

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

[Michael Still]

+1... Sylvain is an excellent reviewer.

On Sat, Nov 7, 2015 at 2:32 AM, John Garbutt  wrote:

> Hi,
>
> I propose we add Sylvain Bauza[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the Scheduler.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1]
> http://stackalytics.com/?module=nova-group_id=sylvain-bauza=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

[Tony Breeds]

On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>  4. Create a capabilitioes API of some description, that can be queried so 
> that
> consumers (horizon) can known

Thanks everyone for the input.  I'm going to go with the simple first step that
Sean described as it seesm liek the right long term direstion but it's also
doable this cycle.

Yours Tony.


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

Re: [openstack-dev] [kuryr] gerrit/git review problem error code 10061

[Iury Gregory]

Not sure if this can help you,
Verify if your public key is in your gerrit account.

Another thing you can try is to update your openstack account to foundation
member, I had a similar error a while a go.


2015-11-08 23:13 GMT-03:00 Baohua Yang :

> Hi,
>Anyone recently meet such problem after cloning the latest code from
> kuryr?
>Try proxy also, but not solved.
>
> $ git review -s
> Problem running 'git remote update gerrit'
> Fetching gerrit
> FATAL: Unable to connect to relay host, errno=10061
> ssh_exchange_identification: Connection closed by remote host
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> error: Could not fetch gerrit
> Traceback (most recent call last):
>   File "d:\Python27\lib\runpy.py", line 162, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
>   File "d:\Python27\lib\runpy.py", line 72, in _run_code
> exec code in run_globals
>   File "d:\Python27\Scripts\git-review.exe\__main__.py", line 9, in
> 
>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 1202, in
> main
> set_hooks_commit_msg(remote, hook_file)
>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 283, in
> set_hooks_commit_msg
> run_command_exc(CannotInstallHook, *cmd)
>   File "d:\Python27\lib\site-packages\git_review\cmd.py", line 152, in
> run_command_exc
> raise klazz(rc, output, argv, env)
> git_review.cmd.CannotInstallHook: Problems encountered installing
> commit-msg hook
> The following command failed with exit code 1
> "scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg
> .git\hooks\commit-msg"
> ---
> FATAL: Unable to connect to relay host, errno=10061
> ssh_exchange_identification: Connection closed by remote host
>
>
> $ git remote show origin
> * remote origin
>   Fetch URL: git://git.openstack.org/openstack/kuryr
>   Push  URL: git://git.openstack.org/openstack/kuryr
>   HEAD branch: master
>   Remote branch:
> master tracked
>   Local branch configured for 'git pull':
> master merges with remote master
>   Local ref configured for 'git push':
> master pushes to master (local out of date)
>
>
>Thanks!
>
> --
> Best wishes!
> Baohua
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [rpm-packaging] core reviewers nomination

[Thomas Bechtold]

On Mon, 2015-11-02 at 23:23 +0900, Haïkel wrote:
> I'd like to propose new candidates for RPM packaging core reviewers:
> Alan Pevec
> Jakub Ruzicka
> 
> Both are involved in downstream RDO project and this group creation.
> Alan is part of the stable release team and Jakub has been working on
> our tooling since the beginning.
> Having them onboard as core reviewers would help accelerate the
> bootstrap of the project.
> 
> RPM packaging core, please vote with +/- 1.

+1

Cheers,

Tom


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

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 02:42:20PM -0500, Sean Dague wrote:

> The upstream strategy has been make upgrades unexciting, and then folks
> can move forward easily.
> 
> I would really like to unpack what those various reasons are that people
> are trapped. Because figuring out why they feel that way is important
> data in what needs to be done better on upgrade support and testing.

I wish I could give you a list of n things but I can't.  Some are internal to
our offereing and not relevant to the community.  The rest are really just the
things we already know about and we're making incremental imporvements on.

Yours Tony.


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

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 10:12:21AM -0800, Clint Byrum wrote:

> The argument in the original post, I think, is that we should not
> stand in the way of the vendors continuing to collaborate on stable
> maintenance in the upstream context after the EOL date. We already have
> distro vendors doing work in the stable branches, but at EOL we push
> them off to their respective distro-specific homes.

That is indeed a better summary than I started with.

I have a half formed idea that creates a state between the current EOL (where
we delete the branches) to what we have today (where we have full CI/VMT/Release
management.

There is a massive ammount of trust involved in that simple statement and I 
don't
underestimate that.

This would provide a place where interested vendors can work together.
We could disable grenade in juno which isn't awesome but removes the gotta land
patch in juno, kilo and liberty to unblock the master gate.
We could reduce the VMT impact by nominating a point of contact for juno and
granting that person access to the embargoed bugs.  Similarly we could
trust/delegate a certain about of the release management to that team (I say
team but so far we've only got one volunteer)

We can't ignore the fact that fixing things in Juno *may* still require fixes
in Kilo (and later releases) esp. given the mess that is requirements in
stable/juno
 
> As much as I'd like everyone to get on the CD train, I think it might
> make sense to enable the vendors to not diverge, but instead let them
> show up with people and commitment and say "Hey we're going to keep
> Juno/Mitaka/etc alive!".
> 
> So perhaps what would make sense is defining a process by which they can
> make that happen.
> 
> Note that it's not just backporters though. It's infra resources too.

Sure.  CI and Python 2.6 I have a little understanding of.  I guess I can
extrapolate the additional burden on {system,project}-config.  I willingly
admit I don't have a detailed feel for what I'm asking here.

Yours Tony.


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

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 06:42:05PM +, Jeremy Stanley wrote:
> On 2015-11-06 10:12:21 -0800 (-0800), Clint Byrum wrote:
> [...]
> > Note that it's not just backporters though. It's infra resources too.
> 
> Aye, there's the rub. We don't just EOL these branches for fun or
> because we hate old things or because ooh shiny squirrel. We EOL
> them at a cadence where the community has demonstrated it loses its
> ability to keep them healthy and testable (evaluated based on
> performance over recent prior cycles because we have to warn
> downstreams well in advance as to when they should expect upstream
> support to cease).

Sure and Juno is in bad shape, as Matt will attest but I think it can be fixed
;P
 
> Downstream maintainers regularly claim they will step up their
> assistance upstream to keep stable branches alive if only we'll
> extend the lifespan on them, so we tried that with Icehouse and,
> based on our experience there, scaled back the lifespan of Juno
> again accordingly. Keep in mind that extending support of stable
> branches necessarily implies supporting a larger _number_ of stable
> branches in parallel. If we switched from 12 months after release to
> 18 then we're maintaining at least 3 stable branches at any point in
> time. If we extend it to 24 months then that's 4 stable branches.

Yes I agree and frankly I'm disappointed that the support I received in Tokyo
hasn't arrived on this thread (yet).  As to the number of stable branches,
I'm nervous about this.  I don't really want an additional period of
life-support for Juno to mandate a similar commitment for Kilo.

I realise it's a slippery slope.
 
> To those who suggest solving this by claiming one is a LTS release
> every couple years, you're implying a vastly different upgrade model
> than we have now. If we declare Juno is a LTS and leave it supported
> another 12 months, then 6 months from now when we EOL stable/kilo
> we'll be telling deployers that they have to upgrade from supported
> stable/juno through unsupported stable/kilo to supported
> stable/icehouse before running stable/mitaka. Or else you're saying
> you intend to fix the current inability of our projects to skip
> intermediate releases entirely during upgrades (a great idea, and so
> I'm thrilled by those of you who intend to make it a reality, we can
> revisit the LTS discussion once you finish that).

I carefully *didn't* suggest and OpenStack LTS :)

Yours Tony.


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

Re: [openstack-dev] Questions regarding OpenStack CI tools

[GROSZ, Maty (Maty)]

Thank you, Boris.

From: Boris Pavlovic
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Monday, November 9, 2015 at 02:26
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] Questions regarding OpenStack CI tools

Hi Maty,

Usually in python projects are used next thing:
- cover - for unit test coverage
- pep8 + custom hacking rules - to check code styles
- pylint - to check even more code styles


Best regards,
Boris Pavlovic


On Sun, Nov 8, 2015 at 4:41 AM, GROSZ, Maty (Maty) 
> wrote:
Hey,

A question regarding OpenStack CI tools….
Does OpenStackCI process use any monitor code cleanliness tool, code coverage 
tool or any monitor memory consumption/leaks tools?
Thanks,

Maty

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


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

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

[Ken'ichi Ohmichi]

+1 for Alex. He is helping us in long term :-)


2015-11-07 0:32 GMT+09:00 John Garbutt :
> Hi,
>
> I propose we add Alex Xu[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the API.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1]http://stackalytics.com/?module=nova-group_id=xuhj=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

[Ken'ichi Ohmichi]

+1 for Sylvain :-)

2015-11-07 0:32 GMT+09:00 John Garbutt :
> Hi,
>
> I propose we add Sylvain Bauza[1] to nova-core.
>
> Over the last few cycles he has consistently been doing great work,
> including some quality reviews, particularly around the Scheduler.
>
> Please respond with comments, +1s, or objections within one week.
>
> Many thanks,
> John
>
> [1] 
> http://stackalytics.com/?module=nova-group_id=sylvain-bauza=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Tony Breeds]

On Fri, Nov 06, 2015 at 09:20:08AM -0600, Matt Riedemann wrote:

> It also extends the life and number of tests that need to be run against
> things in Tempest, which already runs several dozen jobs per change proposed
> today (since Tempest is branchless).

Okay this is something that I hadn't thought of before, and none of the people
I spoke to have mentioned.  That is somethign I dont' even have a half-formed
"answer" for.
 
> At this point stable/juno is pretty much a goner, IMO. The last few months
> of activity that I've been involved in have been dealing with requirements
> capping issues, which as we've seen you fix one issue to unwedge a project
> and with the g-r syncs we end up breaking 2 other projects, and the cycle
> never ends.

Yeah the requirements wack-a-mole or tangled-web-of-onions.  I feel like we're
always one review away from sorting it out :)
 
> This is not as problematic in stable/kilo because we've done a better job of
> isolating versions in g-r from the start, but things won't get really good
> until stable/liberty when we've got upper-constraints in action.

Also we're doing better with upgrades in newwer releases so in general things
are looking up :D
 
> So I'm optimistic that we can keep stable/kilo around and working longer
> than what we've normally done in the past, but I don't hold out much hope
> for stable/juno at this point given it's current state.
 
Yours Tony.


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

Re: [openstack-dev] [nova][api]

[Tony Breeds]

On Fri, Nov 06, 2015 at 12:30:19PM +, John Garbutt wrote:

> Ideally, I would like us to fill out that pagination part first.

It seems the person leading this within the API-WG is AWOL so ...
 
> If we can't get global agreement quickly, we should at least get a
> Nova API wide standard pattern.

I've love to raise my hand to do this but 

> Am I missing something here?

How long do we leave the specs that started this in limbo?

I don't really want to make life harder for anyone it just struck me that we
had some interest here and now and we could run with that.

Yours Tony.


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

[openstack-dev] [nova][cinder] About rebuilding volume-backed instances.

[Zhenyu Zheng]

Hi All,

Currently, we have strong demands about "rebuilding"(or actions like
rebuilding) volume-backed instances. As in production deployment, volume
backed instance is widely used. Users have the demands of performing the
rebuild(recovery) action for root device while maintain instance UUID sorts
of information, many users also wants to keep the volume uuid unchanged.

Nova side doesn't support using Rebuild API directly for volume backed
instances (the volume will not change). And Nova side also doesn't support
detaching root device, that means we cannot performing volume
backup/restore from cinder side, because those actions needs the volume in
"available" status.

Now there are couple of patches proposed in nova trying to fix this problem:
[1] https://review.openstack.org/#/c/201458/
[2] https://review.openstack.org/#/c/221732/
[3] https://review.openstack.org/#/c/223887/

[1] and [2] are trying to expose the API of detaching root devices, [3] is
trying to fix it in the current Rebuild API. But yet none of them got much
attention.

As we now have strong demand on performing the "rebuilding" action for
volume-backed instances, and yet there is not any clear information about
 it. I wonder is there any plans of how to support it in Nova and Cinder?

Yours,

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

Re: [openstack-dev] [neutron] Stepping Down from Neutron Core Responsibilities

[Somanchi Trinath]

Hi-

Congratulations for the support and excellent contributions.

-
Trinath

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Thursday, November 05, 2015 5:58 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [neutron] Stepping Down from Neutron Core 
Responsibilities

Dear Colleagues,

I have been part of this community from the very beginning when in Santa Clara, 
CA back in 2011 a bunch of we crazy people decided to work on this networking 
project.
Neutron has become is a very unique piece of code and it requires an approval 
team that will always be on the top of everything, this is why I would like to 
communicate you that I decided to step down as Neutron Core.

These are not breaking news for many of you because I shared this thought 
during the summit in Tokyo and now it is a commitment. I want to let you know 
that I learnt a lot from you and I hope my comments and reviews never offended 
you.

I will be around of course. I will continue my work on code reviews and 
coordination on the Networking Guide.

Thank you all for your support and good feedback,

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

Re: [openstack-dev] [nova][cinder] About rebuilding volume-backed instances.

[Clint Byrum]

Excerpts from Zhenyu Zheng's message of 2015-11-08 23:04:59 -0800:
> Hi All,
> 
> Currently, we have strong demands about "rebuilding"(or actions like
> rebuilding) volume-backed instances. As in production deployment, volume
> backed instance is widely used. Users have the demands of performing the
> rebuild(recovery) action for root device while maintain instance UUID sorts
> of information, many users also wants to keep the volume uuid unchanged.
> 
> Nova side doesn't support using Rebuild API directly for volume backed
> instances (the volume will not change). And Nova side also doesn't support
> detaching root device, that means we cannot performing volume
> backup/restore from cinder side, because those actions needs the volume in
> "available" status.
> 
> Now there are couple of patches proposed in nova trying to fix this problem:
> [1] https://review.openstack.org/#/c/201458/
> [2] https://review.openstack.org/#/c/221732/
> [3] https://review.openstack.org/#/c/223887/
> 
> [1] and [2] are trying to expose the API of detaching root devices, [3] is
> trying to fix it in the current Rebuild API. But yet none of them got much
> attention.
> 
> As we now have strong demand on performing the "rebuilding" action for
> volume-backed instances, and yet there is not any clear information about
>  it. I wonder is there any plans of how to support it in Nova and Cinder?
> 

This seems entirely misguided by the users.

Why not just boot a new instance on a new volume with the same image?
Names can be the same.. UUID's should never be anything except a physical
handle.

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

Re: [openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms screen in horizon

[Rob Cresswell (rcresswe)]

This blueprint is being revived by a new assignee I believe: 
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page

Rob

From: "ITZIKOWITZ, Noy (Noy)" 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Sunday, 8 November 2015 14:03
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms 
screen in horizon

Hi,
Following our Tokyo meetings and chats around vitrage and ceilometer, we are 
now working on vitrage blueprints for Mitaka.
One of the blueprints is around ‘active alarms’ screen in the horizon dashboard.
Is there any open blueprint for that, or should I open a new one?
Was this discussed in the past?
Thanks,
Noy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [devstack] package dependency installs after recent clean-ups

[Ian Wienand]

devstack maintainers, et al.

If your CI is failing with missing packages (xml bindings failing to
build, postgres bindings, etc), it may be due to some of the issues
covered below.

I believe some of the recent changes around letting pip build wheels
and cleaning up some of the package dependencies have revealed that
devstack is not quite installing build pre-reqs as we thought it was.

[1] fixes things so we actually install the packages listed in
"general"

[2] is a further cleanup of the "devlib" packages, which are no longer
installed since we removed tools/build_wheels.sh

I believe a combination of what was removed in [3] and [2] was hiding
the missing installs from [1].  Thus we can clean up some of the
dependencies via [4].

Stacked on that are some less important further clean-ups

Reviews appreciated, because it seems to have broken some CI, see [5]

-i

[1] https://review.openstack.org/242891
[2] https://review.openstack.org/242894
[3] https://review.openstack.org/242895
[4] https://review.openstack.org/242895
[5] https://review.openstack.org/242536

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

Re: [openstack-dev] [release] new change management tools and processes for stable/liberty and mitaka

[Lingxian Kong]

On Wed, Nov 4, 2015 at 3:46 AM, Doug Hellmann  wrote:
> 1. We need one patch to the master branch of the project to add the
>instructions for publishing the notes as part of the project
>sphinx documentation build.  An example patch for Glance is in
>[2].
>

Hi, Doug,

I am gonna do this in Mistral project, but I wonder how
releasenotes/source/conf.py is generated? since I found there are some
contents specific to Glance.


-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Gary Kotton]

I think that id we can move to a versioned object model model then it will be 
better. Having random json blobs passed around is going to cause problems.

From: "Armando M." >
Reply-To: OpenStack List 
>
Date: Wednesday, November 4, 2015 at 11:38 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db 
tables



On 4 November 2015 at 13:21, Shraddha Pandhe 
> wrote:
Hi Salvatore,

Thanks for the feedback. I agree with you that arbitrary JSON blobs will make 
IPAM much more powerful. Some other projects already do things like this.

e.g. In Ironic, node has driver_info, which is JSON. it also has an 'extras' 
arbitrary JSON field. This allows us to put any information in there that we 
think is important for us.

I personally feel that relying on json blobs is not only dangerously affecting 
portability, but it causes us to bloat the business logic, and forcing us to be 
doing less efficient when querying/filtering data.

Most importantly though, I feel it's like abdicating our responsibility to do a 
good design job. Ultimately, we should be able to identify how to model these 
extensions you're thinking of both conceptually and logically.

I couldn't care less if other projects use it, but we ended up using in Neutron 
too, and since I lost this battle time and time again, all I am left with is 
this rant :)



Hoping to get some positive feedback from API and DB lieutenants too.


On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando 
> wrote:
Arbitrary blobs are a powerful tools to circumvent limitations of an API, as 
well as other constraints which might be imposed for versioning or portability 
purposes.
The parameters that should end up in such blob are typically specific for the 
target IPAM driver (to an extent they might even identify a specific driver to 
use), and therefore an API consumer who knows what backend is performing IPAM 
can surely leverage it.

Therefore this would make a lot of sense, assuming API portability and not 
leaking backend details are not a concern.
The Neutron team API & DB lieutenants will be able to provide more input on 
this regard.

In this case other approaches such as a vendor specific extension are not a 
solution - assuming your granularity level is the allocation pool; indeed 
allocation pools are not first-class neutron resources, and it is not therefore 
possible to have APIs which associate vendor specific properties to allocation 
pools.

Salvatore

On 4 November 2015 at 21:46, Shraddha Pandhe 
> wrote:
Hi folks,

I have a small question/suggestion about IPAM.

With IPAM, we are allowing users to have their own IPAM drivers so that they 
can manage IP allocation. The problem is, the new ipam tables in the database 
have the same columns as the old tables. So, as a user, if I want to have my 
own logic for ip allocation, I can't actually get any help from the database. 
Whereas, if we had an arbitrary json blob in the ipam tables, I could put any 
useful information/tags there, that can help me for allocation.

Does this make sense?

e.g. If I want to create multiple allocation pools in a subnet and use them for 
different purposes, I would need some sort of tag for each allocation pool for 
identification. Right now, there is no scope for doing something like that.

Any thoughts? If there are any other way to solve the problem, please let me 
know




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



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



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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: