[openstack-dev] [vitrage] about aodh alarm notification

[dong . wenjuan]

Hi Vitrages,

Currently there are four aodh alarm notifications we need to handle:
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion'

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info.
When we receive other notifications, we can fill all fields from the 
cache.

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification.
So we need to get_all when vitrage services startup.
As `SnapshotsService` will get all alarms info when it startup.
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other.
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :)

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

[openstack-dev] [neutron] stable/newton 'broken'

[Gary Kotton]

Hi,
The change https://review.openstack.org/#/c/386845/ that landed yesterday has 
caused a breakage in stable/newton. This is due to the fact that the following 
projects do not have stable/newton tags:

-  https://github.com/openstack/tap-as-a-service

-  https://github.com/openstack/networking-l2gw
Can the relevant release teams of the projects above please create the relevant 
tags.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][ptls][tc][goals] acknowledging community goals for Ocata

[joehuang]

Hello, Doug,

The patch for the acknowledgement from Tricircle project was submitted for 
review: https://review.openstack.org/401878

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 23 November 2016 23:24
To: openstack-dev
Subject: Re: [openstack-dev] [all][ptls][tc][goals] acknowledging community 
goals for Ocata

Excerpts from joehuang's message of 2016-11-23 02:37:12 +:
> Hello, Doug,
>
> Tricircle will submit a patch for the "remove-incubated-oslo-code.rst" goal. 
> For Tricircle was just approved last week, need to dig into how to achieve 
> this goal.
>
> Best Regards
> Chaoyi Huang (joehuang)

That sounds good. I know the timing may be a little tight for you. Let
me know if I can help with any of the analysis.

Doug

>
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: 16 November 2016 23:35
> To: openstack-dev
> Subject: [openstack-dev] [all][ptls][tc][goals] acknowledging community goals 
> for Ocata
>
> We still have quite a few teams who have not acknowledged the goal for
> Ocata. Remember, *all* teams are expected to respond, even if there is
> no work to be done. The most important feature of this new process is
> communication, which won't happen if teams don't participate.
>
> Please take a few minutes to review
> http://governance.openstack.org/goals/index.html and
> http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
> then submit a patch to add your planning artifacts to
> openstack/governance/goals/ocata/remove-incubated-oslo-code.rst before
> the deadline tomorrow.
>
> Doug
>

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

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

Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

[Srikanth Vavilapalli]

We have ensured that the both UDP and TCP communication is good between VM1 and 
VM2. Also if you see ceilometer debug output in my initial e-mail, the first 
keystone REST (curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0) from VM2 
to VM1 was successful, it hanged only at the second keystone REST (POST 
http://mysite-ceilometer-6:5000/v2.0/tokens). So communication seems like not a 
problem here.

ubuntu@mysite-ceilometer-7:~$ ping 10.0.4.4
PING 10.0.4.4 (10.0.4.4) 56(84) bytes of data.
64 bytes from 10.0.4.4: icmp_seq=1 ttl=64 time=3.51 ms
64 bytes from 10.0.4.4: icmp_seq=2 ttl=64 time=2.03 ms
64 bytes from 10.0.4.4: icmp_seq=3 ttl=64 time=1.37 ms
^C
--- 10.0.4.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.372/2.307/3.511/0.893 ms


ubuntu@mysite-ceilometer-6:~$ nc -l 1048
Hello
How is the connection?
Good

ubuntu@mysite-ceilometer-7:~$ nc 10.0.4.4 1048
Hello
How is the connection?
Good


-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Wednesday, November 23, 2016 8:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' 
hangs in "Making authentication request to keystone"



On 23/11/16 09:16 PM, Srikanth Vavilapalli wrote:
> Yes, I agree, this issue is not related to ceilometer. We have verified that 
> none of the keystone commands (keystone endpoint-list, keystone catalog, 
> keystone user-list) are working in that VM2, they all stuck in getting the 
> token-get operation (/v2.0/tokens).
>
> If I had to suspect the keystone server setup in my VM1, then the keystone 
> client on VM3 also wouldn't work. So seems something else is going wrong 
> here. The keystone debugs logs also not helping much here...

you could try seeing if you can access vm1 from vm2. i imagine you have some 
networking issues.

>
> On the last part, could you plz point us to any existing wiki pages that 
> describe to migrate away from ceilometer-api? Thanks for ur help...

we have a guide on how to switch to Gnocchi[1]. we don't currently have a guide 
to switch to anything else but you can always just use either udp or http 
publishers and push to your required target... that our just push to 
oslo.messaging topic and have your service consume from it.

[1]
http://docs.openstack.org/developer/ceilometer/install/dbreco.html#moving-from-ceilometer-to-gnocchi

cheers,

--
gord

__
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] [Congress] Magnum_driver

[Tim Hinrichs]

It's hard to debug that remotely.  If you add the requirements.txt file
with the magnum-client to the code you submitted to gerrit, the tests will
run on gerrit, and I can see the errors for myself.  The error message is
pretty clearly saying that the module can't be found.  Not sure what to
recommend here--maybe diff your changes with the one I pushed to gerrit for
you to see what's different?

I think that putting the python-magnumclient into the
/opt/stack/congress/requirements.tx file should work.  Then again, I don't
see python-magnumclient in that long list of installed packages.

Tim


On Wed, Nov 23, 2016 at 12:29 PM Ruben 
wrote:

> Hi everybody,
> I've trying to run the unit test of the magnum_driver.
>
> I make:
> -cd /opt/stack/congress/
> -tox -epy27
>
> but I have error with the import.
> This is the output:
>
> "py27 develop-inst-noop: /opt/stack/congress
> py27 installed:
> alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
> git+
> http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.concurrency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.policy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.6,sphinx-rtd-theme==0.1.9,SQLAlchemy==1.1.3,sqlalchemy-migrate==0.10.0,sqlparse==0.2.2,stevedore==1.18.0,suds-jurko==0.6,Tempita==0.5.2,tenacity==3.3.0,testrepository==0.0.20,testscenarios==0.5.0,testtools==2.2.0,traceback2==1.4.0,unicodecsv==0.14.1,unittest2==1.1.0,urllib3==1.19,warlock==1.2.0,WebOb==1.6.2,wrapt==1.10.8,yaql==1.1.1
> py27
> 

Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

[gordon chung]

On 23/11/16 09:16 PM, Srikanth Vavilapalli wrote:
> Yes, I agree, this issue is not related to ceilometer. We have verified that 
> none of the keystone commands (keystone endpoint-list, keystone catalog, 
> keystone user-list) are working in that VM2, they all stuck in getting the 
> token-get operation (/v2.0/tokens).
>
> If I had to suspect the keystone server setup in my VM1, then the keystone 
> client on VM3 also wouldn't work. So seems something else is going wrong 
> here. The keystone debugs logs also not helping much here...

you could try seeing if you can access vm1 from vm2. i imagine you have 
some networking issues.

>
> On the last part, could you plz point us to any existing wiki pages that 
> describe to migrate away from ceilometer-api? Thanks for ur help...

we have a guide on how to switch to Gnocchi[1]. we don't currently have 
a guide to switch to anything else but you can always just use either 
udp or http publishers and push to your required target... that our just 
push to oslo.messaging topic and have your service consume from it.

[1] 
http://docs.openstack.org/developer/ceilometer/install/dbreco.html#moving-from-ceilometer-to-gnocchi

cheers,

-- 
gord

__
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] [Zun] Zun PTL election

[Hongbin Lu]

Hi all,

The Zun PTL election concluded. I will serve as your PTL until the next 
election. Thanks for your supporting.

Best regards,
Hongbin

From: Hongbin Lu
Sent: November-18-16 6:20 PM
To: 'OpenStack Development Mailing List (not for usage questions)'
Cc: 't...@bakeyournoodle.com'
Subject: RE: [Zun] Zun PTL election

Hi all,

I nominated myself to be the Zun PTL. As the founder of this project, it is my 
honor to work with all of you to build an innovative container service for 
OpenStack. Zun is a new project but already attracted a diverse set of 
contributors. I want to take this chance to thank our talent contributors for 
the great work. I also want to thank the general OpenStack community, in 
particular, a few TC members who helped us to found the project, provided 
suggestions to name the project, allocated resources for us in the Barcelona 
design summit, etc.. I believe we are heading to the right direction and our 
hard work will make OpenStack better in the future.

Best regards,
Hongbin

From: Hongbin Lu
Sent: November-08-16 7:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: 't...@bakeyournoodle.com'
Subject: [Zun] Zun PTL election

Hi all,

As discussed at the last team meeting, the Zun team will have a PTL election. 
Please note the following:
* The electorate for this election are the Foundation individual members that 
are also committers for one of the Zun project teams repositories 
(openstack/zun, openstack/python-zunclient, openstack/zun-ui).
* The electorate is requested to confirm their email address in gerrit, 
review.openstack.org > Settings > Contact Information > Preferred Email, prior 
to November 15, 2016 so that the emailed ballots are mailed to the correct 
email address.
* The election will be scheduled as following:
PTL nomination starts2016-11-15, 00:00 UTC
PTL nomination ends  2016-11-22, 23:45 UTC
PTL elections begins   2016-11-23, 00:00 UTC
PTL elections ends   2016-11-29, 23:45 UTC

After the PTL nomination ends and there are more than one candidates, Tony 
Breeds will hold an election for us (thanks Tony). Please feel free to reply to 
this email if there is any question.

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

Re: [openstack-dev] [tricircle]Questions about Tricircle L2 and L3 implementation

[joehuang]

Hello, Dina,

Currently EVPN L2 networking has not started to design and implemented yet. 
Currently only shared VLAN L2 networking was supported, and is discussing VxLAN 
based L2 networking across OpenStack.

If there are EVPN networking contributors, we can put it into agenda and set 
priority.

Could you help review this patch https://review.openstack.org/#/c/396564/, to 
see if the L2/L3 networking can meet your demand?

Best Regards
Chaoyi Huang ( Joe Huang )

From: dina@orange.com [mailto:dina@orange.com]
Sent: Wednesday, November 23, 2016 7:04 PM
To: joehuang; openstack-dev
Subject: RE: [openstack-dev][tricircle]Questions about Tricircle L2 and L3 
implementation

Hello Chaoyi,

Thanks for your answer.

Related to Route Target parameter (RT) : I referred to the figure displaying 
pods interconnection through an E-VPN L2 network ("Tricircle in a nutshell" 
presentation).

My question is : how are there populated and/or exchanged through the E-VPN 
interconnection ?

Thanks,

Best Regards,

Dina

De : joehuang [mailto:joehu...@huawei.com]
Envoyé : mercredi 23 novembre 2016 04:20
À : SOL Dina IMT/OLN; openstack-dev
Objet : RE: [openstack-dev][tricircle]Questions about Tricircle L2 and L3 
implementation

Hello, Dina,

Thank you for your comments, it'll be good to discuss tricircle related topic 
in openstack-dev so that more people can be involved in if necessary, and keep 
the project transparent. So I copied the reply to  
openstack-dev@lists.openstack.org.

For L2VxLAN, the VNI identifiers will be allocated in central Neutron, and then 
same VNI segment will be used for local Neutron during get_network or get_port 
from Nova, the local plugin in local Neutron will query the network segment 
info. and persist same uuid and VNI in local Neutron. But VxLAN based cross 
Neutron L2 networking has not started yet, the spec has not submitted for 
review yet, currently only VLAN based L2/L3 networking were implemented, 
supported features could be found in the release 
notes:https://github.com/openstack/tricircle/blob/master/releasenotes/notes/initial-release-notes.yaml
 .

 VxLAN L2 networking and VxLAN as the bridge network for L3 networking will 
rely on the patch for "formalize the tunnel termination point by adding it to 
the port binding data model" which is mentioned in "Eliminating L2pop as a 
mechanism driver" 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

Before VxLAN L2 networking and VxLAN as the bridge network for L3 networking, 
this spec is being reviewed, https://review.openstack.org/#/c/396564/, please 
join the review to see whether it can meet your demands, especially for the 
cross Neutron networking models.

What is "RT parameters"?

Tricircle supported L3 networking based on shared VLAN bridge network, you can 
refer to "6.6  L3 Networking across Neutron", but just as what mentioned in the 
release notes,  only VLAN L2 network and shared VLAN as the bridge network for 
L3 networking are supported.

There are todo list for the usage documentation in ocata release, you are 
welcome to join the contribution, no matter documentation or source code or 
review.

Best Regards
Chaoyi Huang (joehuang)

From: dina@orange.com [dina@orange.com]
Sent: 22 November 2016 21:54
To: joehuang
Subject: Questions about Tricircle L2 and L3 implementation
Hello Chaoyi Huang,

I have read Tricirle wiki documentation and some presentations.
May I ask you I have few questions about Tricircle implementation ?
Here there are :

1°) L2 VxLAN
How are choosen VNI identifiers ?
How are choosen RT parameters ? Is a control plane used or all is configured 
within a pool ?

2°) L3
Does Tricircle support L3 interconnection ?
Have you documentation about that ?

Thanks,
Best Regards,

Dina SOL

[logo-Orange]
Dina Sol
Orange/ IMT/ OLN/ WTC/ IEE/ NAVI (Network Automation and Virtualized 
Infrastructure)
Orange Labs
2, avenue Pierre Marzin
22307 Lannion Cedex
tel : 00 33 (0)2 96 07 11 22
dina@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have 

Re: [openstack-dev] [Nova] Stepping back

[Alex Xu]

Yea, thanks for all the help you give, and yes, I learned from you a lot
also. Really sad lost one teacher.

Wish all the best to you!

Thanks
Alex

2016-11-24 9:56 GMT+08:00 Ghanshyam Mann 
:

> Thanks a lot alaski for your incredible contribution in Nova. You were a
> great learning guide and mentor.
> Very best of luck for your new responsibility and hoping to work together
> in community again.
>
> Thanks & Regards,
> gmann
>
>
> > -Original Message-
> > From: Andrew Laski [mailto:and...@lascii.com]
> > Sent: 23 November 2016 01:40
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [Nova] Stepping back
> >
> > I should have sent this weeks ago but I'm a bad person who forgets common
> > courtesy. My employment situation has changed in a way that does not
> > afford me the necessary time to remain a regular contributor to Nova, or
> the
> > broader OpenStack community. So it is with regret that I announce that I
> will
> > no longer be actively involved in the project.
> >
> > Fortunately, for those of you reading this, the Nova community is full of
> > wonderful and talented individuals who have picked up the work that I'm
> not
> > able to continue. Primarily this means parts of the cellsv2 effort, for
> which I
> > am extremely grateful.
> >
> > It has been a true pleasure working with you all these past few years
> and I'm
> > thankful to have had the opportunity. As I've told people many times when
> > they ask me what it's like to work on an open source project like this:
> working
> > on proprietary software exposes you to smart people but you're limited to
> > the small set of people within an organization, working on a project
> like this
> > exposed me to smart people from many companies and many parts of the
> > world. I have learned a lot working with you all. Thanks.
> >
> > I will continue to lurk in #openstack-nova, and try to stay minimally
> involved
> > as time allows, so feel free to ping me there.
> >
> > -Laski
> >
> > __
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

[Srikanth Vavilapalli]

Hi Gordon

Yes, I agree, this issue is not related to ceilometer. We have verified that 
none of the keystone commands (keystone endpoint-list, keystone catalog, 
keystone user-list) are working in that VM2, they all stuck in getting the 
token-get operation (/v2.0/tokens).

If I had to suspect the keystone server setup in my VM1, then the keystone 
client on VM3 also wouldn't work. So seems something else is going wrong here. 
The keystone debugs logs also not helping much here...

On the last part, could you plz point us to any existing wiki pages that 
describe to migrate away from ceilometer-api? Thanks for ur help...

Thanks
Srikanth

-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Wednesday, November 23, 2016 4:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' 
hangs in "Making authentication request to keystone"

i would probably just try to get a token from vm2 and see if that's even 
possible. seems unrelated to ceilometerclient.

that said, i'm going to throw in obligatory: "ceilometer api is deprecated and 
has been unmaintained for over a year. i suggest you switch to another storage 
solution whether that's gnocchi or another time-series service"

On 23/11/16 06:35 PM, Srikanth Vavilapalli wrote:
> Hi
>
> We are facing few issues with keystone access in our setups.
>
> We have a setup which has three VMs. VM1 and VM3 are on same compute host 
> whereas VM2 is on a different compute host.
>
> - VM1 (mysite-ceilometer-6): Running Mitaka Ceilometer service + 
> Keystone (v2) service
> - VM2 (mysite-ceilometer-7): Running Ceilometer client
> - VM3 (mysite-ceilometer-8): Running Ceilometer client
>
> I have the keystone endpoints setup on VM1 as shown below: 'keystone 
> endpoint-list'
> +--+---+--+--+---+--+
> |  id   |   region  |  publicurl   |  
>internalurl  |adminurl   | 
>service_id|
> +--+---+--+--+---+--+
> | 7c56f9e61 | RegionOne | http://mysite-ceilometer-6:5000/v2.0 | 
> http://mysite-ceilometer-6:5000/v2.0 | http://mysite-ceilometer-6:35357/v2.0 
> | 4d871 |
> | adc3ac02f | RegionOne |   http://mysite-ceilometer-6:8777|   
> http://mysite-ceilometer-6:8777|http://mysite-ceilometer-6:8777| 
> 50fb869 |
> +--+---+--+--+---+--+
>
> I have set the following OS variables in both VM2 and VM3:
> OS_USERNAME="admin"
> OS_PASSWORD="password"
> OS_TENANT_NAME="admin"
> OS_AUTH_URL="http://mysite-ceilometer-6:5000/v2.0;
>
> The interesting observation I have made is that I am able to run the 
> ceilometer or keystone commands successfully only from VM3 (which is on the 
> same compute host as VM1) but not from VM2. Attached some of the logs I have 
> collected during this observation. Can any of you help us with identifying 
> what is going wrong here in this setup? Or any pointers on debugging why 
> keystone/tokens REST API is not responding in some scenarios...? Thanks for 
> ur help.
>
> The output from VM3 (mysite-ceilometer-8):
> -
> root@69861113613c:/usr/local/share# ceilometer -d meter-list DEBUG 
> (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H 
> "Accept: application/json" -H "User-Agent: python-keystoneclient"
> INFO (connectionpool) Starting new HTTP connection (1): 
> mysite-ceilometer-6 DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 
> 345 DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token 
> Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) 
> Connection: Keep-Alive Date: Wed, 23 Nov 2016 22:49:28 GMT 
> x-openstack-request-id: req-da4329a5-0374-48de-9a07-229636042f64 
> Content-Type: application/json X-Distribution: Ubuntu RESP BODY: 
> {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z", 
> "media-types": [{"base": "application/json", "type": 
> "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", 
> "links": [{"href": "http://mysite-ceilometer-6:5000/v2.0/;, "rel": 
> "self"}, {"href": "http://docs.openstack.org/;, "type": "text/html", 
> "rel": "describedby"}]}}
>
> DEBUG (v2) Making authentication request to 
> http://mysite-ceilometer-6:5000/v2.0/tokens
> DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293 DEBUG 
> (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H 
> "Accept: 

Re: [openstack-dev] [Nova] Stepping back

[Ghanshyam Mann]

Thanks a lot alaski for your incredible contribution in Nova. You were a great 
learning guide and mentor.
Very best of luck for your new responsibility and hoping to work together in 
community again. 

Thanks & Regards,
gmann


> -Original Message-
> From: Andrew Laski [mailto:and...@lascii.com]
> Sent: 23 November 2016 01:40
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Nova] Stepping back
> 
> I should have sent this weeks ago but I'm a bad person who forgets common
> courtesy. My employment situation has changed in a way that does not
> afford me the necessary time to remain a regular contributor to Nova, or the
> broader OpenStack community. So it is with regret that I announce that I will
> no longer be actively involved in the project.
> 
> Fortunately, for those of you reading this, the Nova community is full of
> wonderful and talented individuals who have picked up the work that I'm not
> able to continue. Primarily this means parts of the cellsv2 effort, for which 
> I
> am extremely grateful.
> 
> It has been a true pleasure working with you all these past few years and I'm
> thankful to have had the opportunity. As I've told people many times when
> they ask me what it's like to work on an open source project like this: 
> working
> on proprietary software exposes you to smart people but you're limited to
> the small set of people within an organization, working on a project like this
> exposed me to smart people from many companies and many parts of the
> world. I have learned a lot working with you all. Thanks.
> 
> I will continue to lurk in #openstack-nova, and try to stay minimally involved
> as time allows, so feel free to ping me there.
> 
> -Laski
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] neutron-lib impact

[Armando M.]

On 23 November 2016 at 16:42, Joshua Harlow  wrote:

> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
> http://status.openstack.org/openstack-health/#/?groupKey=bui
> ld_name=hour=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>

I take the 3 cents, but we already do that :)

http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-neutron-lib-master


> -Josh
>
>
> Boden Russell wrote:
>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>>> Hi neutrinos,
>>>
>>> In the last few hours a couple of changes landed [1,2] that caused a bit
>>> of a jam in the neutron subproject gates, as they overlapped with
>>> another change [3] having impact on the subprojects.
>>>
>>> This is why it is important to communicate during team meetings and/or
>>> ML that patches with potential impact are in flight in our review
>>> pipeline, so that we do our best to coordinate the merge process without
>>> shooting ourselves in the foot.
>>>
>>> To bring this back to sanity, I issued a temporary revert [4], so that
>>> [5] can land undisturbed. After that, a double revert will be applied,
>>> once subprojects have had the opportunity to deal with the aftermath of
>>> the other breaking change [1,2] (e.g. [6,7]).
>>>
>>>  From now on, I'd strongly encourage people proposing/reviewing patches
>>> with potential impact (any impact) to err on the side of caution, and
>>> take the advised steps to ensure such situations don't happen in the
>>> future.
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/397704/
>>> [2] https://review.openstack.org/#/c/397037/
>>> [3] https://review.openstack.org/#/c/386845/
>>> [4] https://review.openstack.org/#/c/401377/
>>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>>> [6] https://review.openstack.org/#/c/401263/
>>> [7] https://review.openstack.org/#/c/401355/
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] neutron-lib impact

[Kevin Benton]

The issue we had is different than breaking changes in neutron-lib. The
issue we are running into now is bumps in the road when we are removing
deprecated things from Neutron that other projects are still using even
though they should be using the neutron-lib version instead.

On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
wrote:

> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
> http://status.openstack.org/openstack-health/#/?groupKey=bui
> ld_name=hour=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>
> -Josh
>
>
> Boden Russell wrote:
>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>>> Hi neutrinos,
>>>
>>> In the last few hours a couple of changes landed [1,2] that caused a bit
>>> of a jam in the neutron subproject gates, as they overlapped with
>>> another change [3] having impact on the subprojects.
>>>
>>> This is why it is important to communicate during team meetings and/or
>>> ML that patches with potential impact are in flight in our review
>>> pipeline, so that we do our best to coordinate the merge process without
>>> shooting ourselves in the foot.
>>>
>>> To bring this back to sanity, I issued a temporary revert [4], so that
>>> [5] can land undisturbed. After that, a double revert will be applied,
>>> once subprojects have had the opportunity to deal with the aftermath of
>>> the other breaking change [1,2] (e.g. [6,7]).
>>>
>>>  From now on, I'd strongly encourage people proposing/reviewing patches
>>> with potential impact (any impact) to err on the side of caution, and
>>> take the advised steps to ensure such situations don't happen in the
>>> future.
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/397704/
>>> [2] https://review.openstack.org/#/c/397037/
>>> [3] https://review.openstack.org/#/c/386845/
>>> [4] https://review.openstack.org/#/c/401377/
>>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>>> [6] https://review.openstack.org/#/c/401263/
>>> [7] https://review.openstack.org/#/c/401355/
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] neutron-lib impact

[Joshua Harlow]

A suggestion would also to setup something like the following:

https://wiki.openstack.org/wiki/Oslo#Periodic

Get the users of neutron lib being tested against the latest neutron lib 
(at least nightly) and seeing if they will be borked by a new neutron 
lib merge...


http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-oslo

Overall be careful with the APIs u expose and plan out how u will shift 
users from the old API to the new API (without destroying the world 
during that transition).


My 3 cents :-P

-Josh

Boden Russell wrote:

I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc [1] if you haven't
already.

In particular the 'Phase 4: Consume' section [2] provides some tips on
how we see this workflow playing out.

Thanks

[1]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
[2]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume


On 11/23/16 12:39 PM, Armando M. wrote:

Hi neutrinos,

In the last few hours a couple of changes landed [1,2] that caused a bit
of a jam in the neutron subproject gates, as they overlapped with
another change [3] having impact on the subprojects.

This is why it is important to communicate during team meetings and/or
ML that patches with potential impact are in flight in our review
pipeline, so that we do our best to coordinate the merge process without
shooting ourselves in the foot.

To bring this back to sanity, I issued a temporary revert [4], so that
[5] can land undisturbed. After that, a double revert will be applied,
once subprojects have had the opportunity to deal with the aftermath of
the other breaking change [1,2] (e.g. [6,7]).

 From now on, I'd strongly encourage people proposing/reviewing patches
with potential impact (any impact) to err on the side of caution, and
take the advised steps to ensure such situations don't happen in the future.

Thanks,
Armando

[1] https://review.openstack.org/#/c/397704/
[2] https://review.openstack.org/#/c/397037/
[3] https://review.openstack.org/#/c/386845/
[4] https://review.openstack.org/#/c/401377/
[5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
[6] https://review.openstack.org/#/c/401263/
[7] https://review.openstack.org/#/c/401355/


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



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


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

Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

[gordon chung]

i would probably just try to get a token from vm2 and see if that's even 
possible. seems unrelated to ceilometerclient.

that said, i'm going to throw in obligatory: "ceilometer api is 
deprecated and has been unmaintained for over a year. i suggest you 
switch to another storage solution whether that's gnocchi or another 
time-series service"

On 23/11/16 06:35 PM, Srikanth Vavilapalli wrote:
> Hi
>
> We are facing few issues with keystone access in our setups.
>
> We have a setup which has three VMs. VM1 and VM3 are on same compute host 
> whereas VM2 is on a different compute host.
>
> - VM1 (mysite-ceilometer-6): Running Mitaka Ceilometer service + Keystone 
> (v2) service
> - VM2 (mysite-ceilometer-7): Running Ceilometer client
> - VM3 (mysite-ceilometer-8): Running Ceilometer client
>
> I have the keystone endpoints setup on VM1 as shown below: 'keystone 
> endpoint-list'
> +--+---+--+--+---+--+
> |  id   |   region  |  publicurl   |  
>internalurl  |adminurl   | 
>service_id|
> +--+---+--+--+---+--+
> | 7c56f9e61 | RegionOne | http://mysite-ceilometer-6:5000/v2.0 | 
> http://mysite-ceilometer-6:5000/v2.0 | http://mysite-ceilometer-6:35357/v2.0 
> | 4d871 |
> | adc3ac02f | RegionOne |   http://mysite-ceilometer-6:8777|   
> http://mysite-ceilometer-6:8777|http://mysite-ceilometer-6:8777| 
> 50fb869 |
> +--+---+--+--+---+--+
>
> I have set the following OS variables in both VM2 and VM3:
> OS_USERNAME="admin"
> OS_PASSWORD="password"
> OS_TENANT_NAME="admin"
> OS_AUTH_URL="http://mysite-ceilometer-6:5000/v2.0;
>
> The interesting observation I have made is that I am able to run the 
> ceilometer or keystone commands successfully only from VM3 (which is on the 
> same compute host as VM1) but not from VM2. Attached some of the logs I have 
> collected during this observation. Can any of you help us with identifying 
> what is going wrong here in this setup? Or any pointers on debugging why 
> keystone/tokens REST API is not responding in some scenarios...? Thanks for 
> ur help.
>
> The output from VM3 (mysite-ceilometer-8):
> -
> root@69861113613c:/usr/local/share# ceilometer -d meter-list
> DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 
> -H "Accept: application/json" -H "User-Agent: python-keystoneclient"
> INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
> DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
> DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token 
> Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: 
> Keep-Alive Date: Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id: 
> req-da4329a5-0374-48de-9a07-229636042f64 Content-Type: application/json 
> X-Distribution: Ubuntu
> RESP BODY: {"version": {"status": "stable", "updated": 
> "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": 
> "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
> [{"href": "http://mysite-ceilometer-6:5000/v2.0/;, "rel": "self"}, {"href": 
> "http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}
>
> DEBUG (v2) Making authentication request to 
> http://mysite-ceilometer-6:5000/v2.0/tokens
> DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293
> DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 
> -H "Accept: application/json" -H "User-Agent: python-keystoneclient"
> INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
> DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
> DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token 
> Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: 
> Keep-Alive Date: Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id: 
> req-491da351-24c1-4b4d-9558-b6d66a280c35 Content-Type: application/json 
> X-Distribution: Ubuntu
> RESP BODY: {"version": {"status": "stable", "updated": 
> "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": 
> "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
> [{"href": "http://mysite-ceilometer-6:5000/v2.0/;, "rel": "self"}, {"href": 
> "http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}
>
> DEBUG (v2) Making authentication request to 
> 

Re: [openstack-dev] [charms] layer/source charm project-config changes

[Ryan Beisner]

Following review initial review and corresponding mods, this is ready for
re-review.
Cheers,
Ryan

On Mon, Nov 21, 2016 at 2:16 PM, Ryan Beisner 
wrote:

> Good day OpenStack Charmers,
>
> Project-config change proposed, ready for review:
> https://review.openstack.org/#/c/399299/
>
> To address bug:
> https://launchpad.net/bugs/1642981
>
> Which is preventing landing of even trivial changes in the source/layer
> repos:
> https://review.openstack.org/#/q/topic:update-readme+owner:%
> 22Ryan+Beisner%22+status:open
>
> Please do have a very close look at what I'm redefining here.
>
> Thanks in advance!
>
> Ryan
>
__
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] [Congress] Magnum_driver

[Ruben]

Hi Tim,
I already have 'pyhton-magnumclient' in the requirements.txt file, but I still 
have the error.

This is the /opt/stack/congress/requirements.txt file:

"# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.

Babel>=2.3.4 # BSD
eventlet!=0.18.3,>=0.18.2 # MIT
PuLP>=1.4.1 # MIT
keystoneauth1>=2.14.0 # Apache-2.0
keystonemiddleware!=4.5.0,>=4.2.0 # Apache-2.0
Paste # MIT
PasteDeploy>=1.5.0 # MIT
pbr>=1.6 # Apache-2.0
python-keystoneclient>=3.6.0 # Apache-2.0
python-heatclient>=1.5.0 # Apache-2.0
python-magnumclient
python-muranoclient>=0.8.2 # Apache-2.0
python-novaclient!=2.33.0,>=2.29.0 # Apache-2.0
python-neutronclient>=5.1.0 # Apache-2.0
python-ceilometerclient>=2.5.0 # Apache-2.0
python-cinderclient!=1.7.0,!=1.7.1,>=1.6.0 # Apache-2.0
python-swiftclient>=2.2.0 # Apache-2.0
python-ironicclient>=1.6.0 # Apache-2.0
alembic>=0.8.4 # MIT
python-dateutil>=2.4.2 # BSD
python-glanceclient>=2.5.0 # Apache-2.0
Routes!=2.0,!=2.1,!=2.3.0,>=1.12.3;python_version=='2.7' # MIT
Routes!=2.0,!=2.3.0,>=1.12.3;python_version!='2.7' # MIT
six>=1.9.0 # MIT
oslo.concurrency>=3.8.0 # Apache-2.0
oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
oslo.context>=2.9.0 # Apache-2.0
oslo.db!=4.13.1,!=4.13.2,>=4.11.0 # Apache-2.0
oslo.messaging>=5.2.0 # Apache-2.0
oslo.policy>=1.15.0 # Apache-2.0
oslo.serialization>=1.10.0 # Apache-2.0
oslo.service>=1.10.0 # Apache-2.0
oslo.utils>=3.18.0 # Apache-2.0
oslo.middleware>=3.0.0 # Apache-2.0
oslo.vmware>=2.11.0 # Apache-2.0
oslo.log>=3.11.0 # Apache-2.0
WebOb>=1.6.0 # MIT"

- Original Message -
From: "Tim Hinrichs" 
To: "Ruben" , 
openstack-dev@lists.openstack.org
Cc: "timothy l hinrichs" 
Sent: Wednesday, November 23, 2016 11:44:40 PM
Subject: Re: [Congress] Magnum_driver

Ruben,

All the software that gets imported by your code needs to be listed in
requirements.txt so that when tox runs, it installs that software.  When I
did some debugging for you I made the necessary change, so if you add that
back into your change, that error should disappear.

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

Tim


On Wed, Nov 23, 2016 at 12:29 PM Ruben 
wrote:

> Hi everybody,
> I've trying to run the unit test of the magnum_driver.
>
> I make:
> -cd /opt/stack/congress/
> -tox -epy27
>
> but I have error with the import.
> This is the output:
>
> "py27 develop-inst-noop: /opt/stack/congress
> py27 installed:
> alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
> git+
> http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.concurrency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.po
 
licy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,sno
 

[openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

[Srikanth Vavilapalli]

Hi

We are facing few issues with keystone access in our setups.

We have a setup which has three VMs. VM1 and VM3 are on same compute host 
whereas VM2 is on a different compute host.

- VM1 (mysite-ceilometer-6): Running Mitaka Ceilometer service + Keystone (v2) 
service
- VM2 (mysite-ceilometer-7): Running Ceilometer client
- VM3 (mysite-ceilometer-8): Running Ceilometer client

I have the keystone endpoints setup on VM1 as shown below: 'keystone 
endpoint-list'
+--+---+--+--+---+--+
|  id   |   region  |  publicurl   |
 internalurl  |adminurl   | 
   service_id|
+--+---+--+--+---+--+
| 7c56f9e61 | RegionOne | http://mysite-ceilometer-6:5000/v2.0 | 
http://mysite-ceilometer-6:5000/v2.0 | http://mysite-ceilometer-6:35357/v2.0 | 
4d871 |
| adc3ac02f | RegionOne |   http://mysite-ceilometer-6:8777|   
http://mysite-ceilometer-6:8777|http://mysite-ceilometer-6:8777| 
50fb869 |
+--+---+--+--+---+--+

I have set the following OS variables in both VM2 and VM3:
OS_USERNAME="admin"
OS_PASSWORD="password"
OS_TENANT_NAME="admin"
OS_AUTH_URL="http://mysite-ceilometer-6:5000/v2.0;

The interesting observation I have made is that I am able to run the ceilometer 
or keystone commands successfully only from VM3 (which is on the same compute 
host as VM1) but not from VM2. Attached some of the logs I have collected 
during this observation. Can any of you help us with identifying what is going 
wrong here in this setup? Or any pointers on debugging why keystone/tokens REST 
API is not responding in some scenarios...? Thanks for ur help.

The output from VM3 (mysite-ceilometer-8):
-
root@69861113613c:/usr/local/share# ceilometer -d meter-list
DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H 
"Accept: application/json" -H "User-Agent: python-keystoneclient"
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token Keep-Alive: 
timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date: 
Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id: 
req-da4329a5-0374-48de-9a07-229636042f64 Content-Type: application/json 
X-Distribution: Ubuntu
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
[{"href": "http://mysite-ceilometer-6:5000/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}

DEBUG (v2) Making authentication request to 
http://mysite-ceilometer-6:5000/v2.0/tokens
DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293
DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H 
"Accept: application/json" -H "User-Agent: python-keystoneclient"
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token Keep-Alive: 
timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date: 
Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id: 
req-491da351-24c1-4b4d-9558-b6d66a280c35 Content-Type: application/json 
X-Distribution: Ubuntu
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
[{"href": "http://mysite-ceilometer-6:5000/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}

DEBUG (v2) Making authentication request to 
http://mysite-ceilometer-6:5000/v2.0/tokens
DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293
DEBUG (client) REQ: curl -g -i -X 'GET' 
'http://mysite-ceilometer-6:8777/v2/meters' -H 'User-Agent: 
ceilometerclient.openstack.common.apiclient' -H 'X-Auth-Token: {SHA1}a9'
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2/meters HTTP/1.1" 200 2
DEBUG (client) RESP: [200] {'Date': 'Wed, 23 Nov 2016 22:49:29 GMT', 
'Content-Length': '2', 'Content-Type': 'application/json; charset=UTF-8', 

[openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

[Zane Bitter]

We discussed $SUBJECT at the summit as one of the main performance 
problems that people are running into when trying to create very large 
autoscaling groups, as projects like Sahara, Magnum, TripleO, OpenShift 
are wont to do. Of course, as we all know, validation happens 
synchronously, so it's prone to causing RPC timeouts that mean a hard 
failure of the parent stack.


First the good news - I just committed this patch:

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

which should mean from now on that resources with identical definitions 
will not all be validated, and instead we'll just validate one 
representative one. In theory this should mean that autoscaling groups 
should now validate in constant rather than linear time. If anyone from 
one of the affected projects is able to confirm this, then I'd be happy 
to backport the patch to stable/newton. It really is very simple.


The bad news here is for users of ResourceGroups with %index% 
substitution (*cough*TripleO*cough*) - this makes each resource 
definition unique, so it won't benefit from this fix. (Adding this to my 
mental list of reasons why index substitution is bad.)



I also investigated another issue, which is that since the fix for 
https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe 
we are validating nested stacks multiple times (specifically, m times, 
where m is the stack's depth in the tree):


  root childgrandchild

  create
   -> validate --> validate --> validate
   -> Resource.create ===> create
-> validate --> validate
-> Resource.create ===> create
 -> validate

The only good news here is that ResourceGroup is smart enough to make 
sure that it generates a nested stack with at most 1 resource to 
validate when validate() is called. (However, when the nested stack is 
created, and thus validated, it is of course full-sized.) Autoscaling 
groups make no such allowances, but the patch above should actually have 
the same effect. (We can't get rid of the special case for ResourceGroup 
though, because of index substitution.)


An obvious fix would be to disable validation - or, more specifically, 
validation of _resources_ - on create/update for stacks that have a 
non-null owner_id (i.e. nested stacks), so that we had something like:


  root childgrandchild

  create
   -> validate --> validate --> validate
   -> Resource.create ===> create
-> Resource.create ===> create

That would eliminate the duplication/triplication/multiplication of 
validation. It would also mean that we'd cut out the expensive part of 
ResourceGroup validation with index substitution, leaving only the cheap 
part.


One downside is that in the ResourceGroup/index substitution case we'd 
be creating resources whose definitions hadn't _ever_ been validated. I 
_think_ that's safe, in the sense that you'd just hear about errors 
later, as opposed to everything falling over in a heap, but it's 
difficult to be certain. Hearing about problems late is also not ideal 
(since it may cause otherwise-healthy siblings to be cancelled), but I 
would guess that heavy users like TripleO developers would say that it's 
worth the tradeoff.


However, one other thing about this bothers me. The part of validation 
that we're keeping:


   -> validate --> validate --> validate

involves loading all of the nested stacks in memory at once (i.e. the 
thing we were not supposed to be doing any more in Kilo, in favour of 
farming nested stacks out over RPC.) As we discovered when we found out 
we were doing the same thing with outputs[1], this is a bit like hanging 
out a giant "Kick Me" sign for the OOM Killer.


That's mitigated quite a lot by my patch though... we'll load the whole 
autoscaling group stack in memory, but if its members are themselves 
nested stacks we'll load only one of them. So the scaling tendencies 
will hopefully be dominated by the complexity of your templates more 
than than the size of your deployment. ResourceGroup is in a better 
position, because its nested stack will actually have only one member, 
so the size shouldn't affect memory consumption at all during validation.


Some options:
1) Chalk it up to an acceptable tradeoff
2) Add a single-member special case for autoscaling group validation
3) Farm out the nested validation over RPC
4) Both (2) & (3)
5) Some totally different arrangement of how nested stacks are validated

Discuss.

cheers,
Zane.

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

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

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

Ruben,

All the software that gets imported by your code needs to be listed in
requirements.txt so that when tox runs, it installs that software.  When I
did some debugging for you I made the necessary change, so if you add that
back into your change, that error should disappear.

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

Tim


On Wed, Nov 23, 2016 at 12:29 PM Ruben 
wrote:

> Hi everybody,
> I've trying to run the unit test of the magnum_driver.
>
> I make:
> -cd /opt/stack/congress/
> -tox -epy27
>
> but I have error with the import.
> This is the output:
>
> "py27 develop-inst-noop: /opt/stack/congress
> py27 installed:
> alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
> git+
> http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.concurrency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.policy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.6,sphinx-rtd-theme==0.1.9,SQLAlchemy==1.1.3,sqlalchemy-migrate==0.10.0,sqlparse==0.2.2,stevedore==1.18.0,suds-jurko==0.6,Tempita==0.5.2,tenacity==3.3.0,testrepository==0.0.20,testscenarios==0.5.0,testtools==2.2.0,traceback2==1.4.0,unicodecsv==0.14.1,unittest2==1.1.0,urllib3==1.19,warlock==1.2.0,WebOb==1.6.2,wrapt==1.10.8,yaql==1.1.1
> py27
> 

Re: [openstack-dev] [Neutron] Transition to Ubuntu Xenial in the gate

[Armando M.]

On 10 November 2016 at 17:36, Armando M.  wrote:

> Hi Neutrinos,
>
> Some of you may be aware of our CI jobs have been transitioning to Xenial.
> There are a few jobs still left and taking into account mail [1] we need to
> accelerate the process a bit, especially for those jobs that affect our
> gate queue or are voting.
>
> Ajo put together [2], I also added a provisional 'xenial' launchpad bug
> tag [3] to track fixes required to get us in tip-top shape.
>
> Please help out as you can.
>
> Cheers,
> Armando
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/106906.html
> [2] https://etherpad.openstack.org/p/moving-neutron-jobs-to-xenial
> [3] https://bugs.launchpad.net/neutron/+bugs?field.tag=xenial
>

During the past few weeks lots of progress has been made, we're nearly
completed the transition to xenial as far as the neutron queues go (with
functional and fullstack trailing slightly behind). I have a pending patch
to switch neutron-lib's jobs to xenial [1].

The other untouched surface is python-neutronclient, which I'll be tackling
next. I would invite subprojects maintainers to take a look at their infra
settings to ensure that the switch to xenial won't bite them when it comes.
There's plenty of examples in [2] to learn how to switch.

Cheers,
Armando

[1] https://review.openstack.org/#/c/397401/
[2] https://etherpad.openstack.org/p/moving-neutron-jobs-to-xenial
__
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] [architecture] Arch-WG Meeting Cancelled this week

[Clint Byrum]

The Arch-WG meeting (APAC friendly timeslot) will be cancelled this week,
as most of our regulars (most notably, me) will not be available.

We'll be back next week, also at our new time one hour later for the
Euro-Friendly slot to help avoid dinner time for UTC+1 folks.

__
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] neutron-lib impact

[Boden Russell]

I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc [1] if you haven't
already.

In particular the 'Phase 4: Consume' section [2] provides some tips on
how we see this workflow playing out.

Thanks

[1]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
[2]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume


On 11/23/16 12:39 PM, Armando M. wrote:
> Hi neutrinos,
> 
> In the last few hours a couple of changes landed [1,2] that caused a bit
> of a jam in the neutron subproject gates, as they overlapped with
> another change [3] having impact on the subprojects.
> 
> This is why it is important to communicate during team meetings and/or
> ML that patches with potential impact are in flight in our review
> pipeline, so that we do our best to coordinate the merge process without
> shooting ourselves in the foot.
> 
> To bring this back to sanity, I issued a temporary revert [4], so that
> [5] can land undisturbed. After that, a double revert will be applied,
> once subprojects have had the opportunity to deal with the aftermath of
> the other breaking change [1,2] (e.g. [6,7]).
> 
> From now on, I'd strongly encourage people proposing/reviewing patches
> with potential impact (any impact) to err on the side of caution, and
> take the advised steps to ensure such situations don't happen in the future.
> 
> Thanks,
> Armando
> 
> [1] https://review.openstack.org/#/c/397704/
> [2] https://review.openstack.org/#/c/397037/
> [3] https://review.openstack.org/#/c/386845/
> [4] https://review.openstack.org/#/c/401377/
> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
> [6] https://review.openstack.org/#/c/401263/
> [7] https://review.openstack.org/#/c/401355/
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

[Giulio Fidente]

hi Emilien,

thanks for putting some thought into this. We have a similar problem to 
test RGW which was only added in Newton.


On 11/23/2016 03:02 AM, Emilien Macchi wrote:

== Context

In Newton we added new multinode jobs called "scenarios".
The challenged we tried to solve was "how to test the maximum of
services without overloading the nodes that run tests".

Each scenarios deploys a set of services, which allows us to
horizontally scale the number of scenarios to increase the service
testing coverage.
See the result here:
https://github.com/openstack-infra/tripleo-ci#service-testing-matrix

To implement this model, we took example of Puppet OpenStack CI:
https://github.com/openstack/puppet-openstack-integration#description
We even tried to keep consistent the services/scenarios relations, so
it's consistent and easier to maintain.

Everything was fine until we had to add new services during Ocata cycles.
Because tripleo-ci repository is not branched, adding Barbican service
in the TripleO environment for scenario002 would break Newton CI jobs.
During my vacations, the team created a new scenario, scenario004,
that deploys Barbican and that is only run for Ocata jobs.
I don't think we should proceed this way, and let me explain why.

== Problem

How to scale the number of services that we test without increasing
the number of scenarios and therefore the complexity of maintaining
them on long-term.


== Solutions

The list is not exhaustive, feel free to add more.

1) Re-use experience from Puppet OpenStack CI and have environments
that are in a branched repository.
environments.
In Puppet OpenStack CI, the repository that deploys environments
(puppet-openstack-integration) is branched. So if puppet-barbican is
ready to be tested in Ocata, we'll patch
puppet-openstack-integration/master to start testing it and it won't
break stable jobs.
Like this, we were successfully able to maintain a fair number of
scenarios and keep our coverage increasing over each cycle.

I see 2 sub-options here:

a) Move CI environments and pingtest into
tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
is branched and we could add a README to explain these files are used
in CI and we don't guarantee they would work outside TripleO CI tools.
b) Branch tripleo-ci repository. Personally I don't like this solution
because a lot of patches in this repo are not related to OpenStack
versions, which means we would need to backport most of the things
from master.


I'd +1 this idea. It sounds like we could make the scenarios generic 
enough to be usable also outside CI? Maybe they can serve as samples?

--
Giulio Fidente
GPG KEY: 08D733BA

__
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 TripleO Newton install [TripleO] [OpenStack-docs]

[Ben Nemec]

On 11/23/2016 10:45 AM, Julie Pichon wrote:

Hi Kent,

On 23 November 2016 at 16:08, Gordon, Kent
 wrote:

Does documentation exist for a TripleO Newton install ?

I have looked at both

http://docs.openstack.org/developer/tripleo-docs/index.html

http://tripleo.org/


I believe these are the correct places to look at. There was a pending
patch to add the Newton information at [1] which just merged, I'd
expect the documentation pages to reflect the change shortly.

Hope this helps,

Julie

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


It's live now.  If we missed anything let us know.








I see that the repo’s suggested are for Liberty or Mitaka.



I have found one reference to upgrading to Newton.  I only found this link
via google.  It does not seem to via menu system.

http://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html

but it still references Mitaka repo’s.





Kent S. Gordon

DMTS, NNO

email: kent.gor...@verizonwireless.com desk: (682)831-3601  cell:
(817)905-6518






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



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



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

[openstack-dev] [Horizon][Keystone] No Horizon/Keystone cross-project meeting this week

[Richard Jones]

Hi folks,

Since so many key people are away on vacation, we'll skip this week's
meeting (November 24th).


 Richard

__
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] [Congress] Magnum_driver

[Ruben]

Hi everybody,
I've trying to run the unit test of the magnum_driver.

I make:
-cd /opt/stack/congress/
-tox -epy27

but I have error with the import.
This is the output:

"py27 develop-inst-noop: /opt/stack/congress
py27 installed: 
alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
 
git+http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.con
 
currency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.policy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.
 
8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.6,sphinx-rtd-theme==0.1.9,SQLAlchemy==1.1.3,sqlalchemy-migrate==0.10.0,sqlparse==0.2.2,stevedore==1.18.0,suds-jurko==0.6,Tempita==0.5.2,tenacity==3.3.0,testrepository==0.0.20,testscenarios==0.5.0,testtools==2.2.0,traceback2==1.4.0,unicodecsv==0.14.1,unittest2==1.1.0,urllib3==1.19,warlock==1.2.0,WebOb==1.6.2,wrapt==1.10.8,yaql==1.1.1
py27 runtests: PYTHONHASHSEED='4235171505'
py27 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py27 runtests: commands[1] | python setup.py testr --slowest --testr-args=
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ ./congress/tests --list 
--- import errors ---
Failed to import test module: congress.tests.datasources.test_magnum_driver
Traceback (most recent call last):
  File 
"/opt/stack/congress/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/congress/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "congress/tests/datasources/test_magnum_driver.py", line 18, in 
from congress.datasources import magnum_driver
  File "congress/datasources/magnum_driver.py", line 16, in 
from magnumclient import client as magnum_client
ImportError: No module named magnumclient
Non-zero exit code (2) from test listing.
error: testr failed (3)
ERROR: InvocationError: '/opt/stack/congress/.tox/py27/bin/python setup.py 
testr --slowest --testr-args='
__
 summary 
__
ERROR:   py27: commands failed"


Pep8 is ok.
What should I do to solve the error above?

Anyway I've errors with the translators..
I've add the code to review.

Ruben


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

[openstack-dev] [neutron] neutron-lib impact

[Armando M.]

Hi neutrinos,

In the last few hours a couple of changes landed [1,2] that caused a bit of
a jam in the neutron subproject gates, as they overlapped with another
change [3] having impact on the subprojects.

This is why it is important to communicate during team meetings and/or ML
that patches with potential impact are in flight in our review pipeline, so
that we do our best to coordinate the merge process without shooting
ourselves in the foot.

To bring this back to sanity, I issued a temporary revert [4], so that [5]
can land undisturbed. After that, a double revert will be applied, once
subprojects have had the opportunity to deal with the aftermath of the
other breaking change [1,2] (e.g. [6,7]).

>From now on, I'd strongly encourage people proposing/reviewing patches with
potential impact (any impact) to err on the side of caution, and take the
advised steps to ensure such situations don't happen in the future.

Thanks,
Armando

[1] https://review.openstack.org/#/c/397704/
[2] https://review.openstack.org/#/c/397037/
[3] https://review.openstack.org/#/c/386845/
[4] https://review.openstack.org/#/c/401377/
[5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
[6] https://review.openstack.org/#/c/401263/
[7] https://review.openstack.org/#/c/401355/
__
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] [networking-sfc] #networking-sfc IRC channel

[Cathy Zhang]

Hi Igor,

Good idea. I will get this #networking-sfc channel registered. 

Thanks,
Cathy

-Original Message-
From: Ravi Sekhar Reddy Konda [mailto:ravisekhar.ko...@oracle.com] 
Sent: Wednesday, November 23, 2016 7:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1


Thanks,
Ravi Sekhar
- Original Message -
From: bcafa...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 23, 2016 7:18:53 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar  wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor 
>  wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to 
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and 
>> will stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> _
>> _ 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
>



--
Bernard Cafarelli

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

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

[openstack-dev] [all][ptls] A request: using the cross-project release goals process for openstack wide change

[Amrith Kumar]

In the last week I've been dealing with two [1][2] cross project efforts
that I believe would have been great candidates for the cross-project goals
process. I think the cross project goals process is lightweight, and it is a
closed-loop process which ensures that we don't have escapes. The use of the
mailing list to communicate these has proved to be problematic in the past
given the sheer volume of mail on the mailing list and the fact that it is
hard to establish server side filters, or for that matter client side
filters to try and only see the emails that are likely of interest without
any possibility that emails that are important get filtered out.

 

So, what's my request . If you see something like this which you believe is
a cross-project, OpenStack wide effort being discussed on the mailing list,
please:

 

(a)Add [all] to the subject line if it isn't already there, and

(b)   Suggest to the sender that they should consider using the
cross-project release goals process.

 

Thanks,

 

-amrith

 

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html

[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086272.html

 



smime.p7s
Description: S/MIME cryptographic 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] centralized calendar for reoccurring tasks

[Matthew Thode]

On 11/23/2016 04:57 AM, Tony Breeds wrote:
> On Wed, Nov 23, 2016 at 04:39:30AM -0600, Matthew Thode wrote:
>> Does Openstack (infra) have a centralized calendar that teams could used
>> for reoccurring tasks/bugs?  Something like this would be useful for
>> things ranging from reminders for meetings (for which I think there may
>> be a calendar) to project 'cleanup' tasks.
> 
> We have one for meetings [1]  And we're making one for "cross project" items 
> in
> [2].
> 
> I don't know of any OpenStack wide ones.
> 
> Yours Tony.
> 
> [1] http://eavesdrop.openstack.org/irc-meetings.ical
> [2] https://releases.openstack.org/ocata/schedule.html
> 

Perhaps I'm thinking of per project calendars then.

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Henry Fourie]

Igor
+1

-Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Wednesday, November 23, 2016 3:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

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

[openstack-dev] [keystone] 2016-11-23 policy meeting summary

[Lance Bragstad]

We had a useful discussion today [0]. I attempted to summarize the meeting
in the etherpad [1], crossed off things we accomplished, and documented our
action items to complete by next week, which I'll echo below:

*ACTION ITEM:* group to review https://review.openstack.org/#/c/391624/ and
continue discussion there
*ACTION ITEM:*  group to get familiar with oslo.policy PoC for AF (
https://review.openstack.org/#/c/237521/)

We had two action items carry over from last week that I rolled over to
next week's agenda:

*ACTION ITEM:* the entire group to think about what people expect from
authorization policy

   - Do we expect to solve policy for application running on OpenStack?


   - I personally don't think this is the problem we're currently solving
   for


   - Do we only expect to solve policy operations across OpenStack services?

*ACTION ITEM:* the entire group to get familiar with OpenStack congress

   - Docs: https://wiki.openstack.org/wiki/Congress


Thanks and see everyone next week. Have a safe and happy Thanksgiving!

[0]
http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-11-23-16.01.log.html
[1] https://etherpad.openstack.org/p/keystone-policy-meeting
__
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] Team meeting is cancelled for Thursday 11/24

[Jay Pipes]

On 11/23/2016 10:53 AM, Matt Riedemann wrote:

By the time the nova meeting rolls around I'll be crying because of (1)
my beloved MN Vikings losing to the lowly Lions and (2) eating too much
and feeling ashamed.

At least with (1) I'm not Jay who is a Browns fan. They are the worst. :)


They are indeed.


See you all next week.


Yep, have a happy Thanksgiving if you're in the U.S. :)

Best,
-jay

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

[openstack-dev] [third-party][ci] Cancel Tue 17:00 UTC biweekly third-party CI working group meeting

[Mikhail Medvedev]

Hi All,

Recently there was not much attendance and activity during biweekly third-party
CI working group meetings on Tuesdays 17:00 UTC [1]. During the last meeting
[2] it was discussed that it is a good time to free up the meeting slot in case
other teams want to use it. I have created the patch [3] to do so.

When we have something to discuss, I suggest we attend another third-party
meeting slot on Mondays 15:00 UTC (also [1]). That meeting did not see much
attendance lately either, so I think it should be ok to share the slot. There
is still an #openstack-third-party-ci channel that is being logged and we can
use for ad-hoc discussions.

[1] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[2] 
http://eavesdrop.openstack.org/meetings/third_party/2016/third_party.2016-11-15-17.00.log.html
[3] 
https://review.openstack.org/#q,I70a5e7a0f5267d2a4e69d5a10ffb00d8c95ebc6d,n,z

---
Mikhail Medvedev (mmedvede)
IBM

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

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Julie Pichon]

On 23 November 2016 at 12:34, Emilien Macchi  wrote:
> 14 positive votes, I guess that's enough ;-)
> Congratulations, Julie!
>
> (added to tripleo-core in Gerrit)

Thanks, everyone!

Julie

>
> On Wed, Nov 23, 2016 at 6:15 AM, Jiri Tomasek  wrote:
>>
>>
>> On 22.11.2016 18:01, Dougal Matthews wrote:
>>
>> Hi all,
>>
>> I would like to propose we add Julie (jpich) to the TripleO core team for
>> python-tripleoclient and tripleo-common. This nomination is based partially
>> on review stats[1] and also my experience with her reviews and
>> contributions.
>>
>> Julie has consistently provided thoughtful and detailed reviews since the
>> start of the Newton cycle. She has made a number of contributions which
>> improve the CLI and has been extremely helpful with other tasks that don't
>> often get enough attention (backports, bug triaging/reporting and improving
>> our processes[2]).
>>
>> I think she will be a valuable addition to the review team
>>
>> Dougal
>>
>>
>> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
>> [2]: https://review.openstack.org/#/c/352852/
>>
>>
>> __
>> 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
>>
>> +1!
>>
>> -- Jirka
>>
>> __
>> 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
>>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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 TripleO Newton install [TripleO] [OpenStack-docs]

[Julie Pichon]

Hi Kent,

On 23 November 2016 at 16:08, Gordon, Kent
 wrote:
> Does documentation exist for a TripleO Newton install ?
>
> I have looked at both
>
> http://docs.openstack.org/developer/tripleo-docs/index.html
>
> http://tripleo.org/

I believe these are the correct places to look at. There was a pending
patch to add the Newton information at [1] which just merged, I'd
expect the documentation pages to reflect the change shortly.

Hope this helps,

Julie

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


>
>
>
> I see that the repo’s suggested are for Liberty or Mitaka.
>
>
>
> I have found one reference to upgrading to Newton.  I only found this link
> via google.  It does not seem to via menu system.
>
> http://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html
>
> but it still references Mitaka repo’s.
>
>
>
>
>
> Kent S. Gordon
>
> DMTS, NNO
>
> email: kent.gor...@verizonwireless.com desk: (682)831-3601  cell:
> (817)905-6518
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron][tacker] Trunk ports in Tacker?

[Armando M.]

On 23 November 2016 at 01:47, zhi  wrote:

> Hi, all
>
> Recently I did some research about trunk port in neutron by following
> document[1]. By creating a trunk port, I can use this port ( aka " parent
> port " ) to create a VM. So I can add or remove subports on this "parent
> port" which used by the VM I created.
>
> I want to know how Tacker can use " trunk port ". In Tacker, I can create
> a VNFD template which contains network infos like
> "
> VL1:
>   type: tosca.nodes.nfv.VL
>   properties:
> network_name: net_mgmt
> vendor: Tacker
> "
> So I can use this template to create VNFs with specific network info(
> naming net_mgmt ). Finally VNFs own its normal ports in neutron. So my
> question is:
>
> Can I use trunk ports in Tacker?
>
> I read some document about VLAN transparent in Neutron. In my thought, I
> can create a vlan transparent network in Neutron and using this network in
> VNFD template. At last, every VNF's
> port is " trunk port " and I can add or remove subports on it. Am I right?
>
> In Newton, I enabled the vlan-transparent in neutron server and try to
> create a vlan transparent network. But I failed. I got the error message
> is: " Backend does not support VLAN Transparency ".
>
> VLAN transparent doesn't support in Newton now?
>

VLAN transparency is backend dependent. OVS, if that's the one you were
using, does not support it.


>
>
> Thanks
> Zhi Chang
>
> [1]: https://wiki.openstack.org/wiki/Neutron/TrunkPort
>
> __
> 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] Openstack TripleO Newton install [TripleO] [OpenStack-docs]

[Gordon, Kent]

Does documentation exist for a TripleO Newton install ?

I have looked at both
http://docs.openstack.org/developer/tripleo-docs/index.html

http://tripleo.org/

I see that the repo's suggested are for Liberty or Mitaka.

I have found one reference to upgrading to Newton.  I only found this link via 
google.  It does not seem to via menu system.
http://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html
but it still references Mitaka repo's.


Kent S. Gordon
DMTS, NNO
email: kent.gor...@verizonwireless.com 
desk: (682)831-3601  cell: (817)905-6518


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

Re: [openstack-dev] [tripleo] POC patch for using tripleo-repos for repo setup

[Ben Nemec]

On 11/22/2016 08:18 PM, Emilien Macchi wrote:

Even if I was part of those who approved this feature, I still have
some comments, inline:

On Tue, Nov 22, 2016 at 1:30 PM, Alex Schultz  wrote:

On Tue, Nov 22, 2016 at 11:06 AM, Ben Nemec  wrote:



On 11/21/2016 05:26 PM, Alex Schultz wrote:


On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec  wrote:


Hi,

I have a POC patch[1] up to demonstrate the use of the tripleo-repos tool
[2] as a replacement for most of tripleo.sh --repo-setup.  It has now
passed
all of the CI jobs so I wanted to solicit some feedback.

There are a few changes related to repo naming because the tool names
repo
files based on the repo name rather than always calling them something
generic like delorean.repo.  I think it's less confusing to have the
delorean-newton repo file named delorean-newton.repo, but I'm open to
discussion on that.

If no one has any major objections to how the tool looks/works right now,
I'll proceed with the work to get it imported into the openstack
namespace
as part of TripleO.  We can always iterate on it after import too, of
course, so this isn't a speak now or forever hold your peace situation.
:-)



Why a python standalone application for the management of specifically
(and only?) tripleo repositories.  It seems we should be trying to
leverage existing tooling and not hiding the problem behind a python
app.  It's not that I enjoy the current method described in the spec
(3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
write 586 lines of python and tests might be the wrong approach.
Would it be better to just devote some time to rpm generation for
these and deliver it in discrete RPMs?  'yum install
http://tripleo.org/repos-current.rpm' seems way more straight forward.



That's essentially trading "curl ..." for "yum install ..." in the docs.
The repo rpm would have to be part of the delorean build so you'd still have
to be pointing people at a delorean repo.  It would also still require code
changes somewhere to handle the mixed current/current-tripleo setup that we
run for development and test. Given how specific to tripleo that is I'm not
sure how much sense it makes to implement it elsewhere.



I'm asking because essentially we're delivering basically static repo
files.  Which should really be done via RPM. Upgrades and cleanups are
already well established practices between RPMs.  I'm not seeing the
reasoning why a python app.  I thought about this further and I'm not
sure why this should be done on the client side via an app rather than
at repository build/promotion time.  As long as we're including the
repo rpm, we can always create simple 302 redirects from a webserver
to get the latest version.  I don't see why we should introduce a
client tool for this when the action is really on the repository
packaging side.   This seems odd doing system configuration via a
python script rather than a configuration management tool like
ansible, puppet or even just packaging.


There are also optional ceph and opstool repos and at least ceph needs to
match the version of OpenStack being installed.  Sure, you could just
document all that logic, but then the logic has to be reimplemented in CI
anyway so you end up with code to maintain either way.  At least with one
tool the logic is shared between the user and dev/test paths, which is one
of the primary motivations behind it.  Pretty much every place that we have
divergence between what users do and what developers do becomes a pain point
for users because developers only fix the things they actually use.



Yes we should not have a different path for dev/test vs operational
deployments, but I'm not convinced we need to add a custom python tool
to handle this only for tripleo.  There are already established
patterns of repository rpm delivery and installation via existing
tools.  What are we getting from this tool that can't already be done?


That is true, here are some of them:
- centos-release-ceph-(hammer|jewel) rpm that deploys repos.
- since we are moving TripleO CI to use tripleo-quickstart, we could
handle repository with Ansible, directly in the roles.


This is exactly what I'm trying to avoid here.  I want us to be using 
the same thing for repo management in CI and dev and real user 
environments.  Unless we're making quickstart the new API for TripleO 
this basically defeats the whole purpose of redoing the repo setup IMHO.





There are other benefits too - the tool cleans up old repos so you don't
have to worry about accidentally being left with a stray repo file that
could cause problems.  You can also install the repos to a non-system path
so you can make use of them without actually installing them on the host
system.  I'm not entirely clear on the use case for that, but it's something
that comes up from time to time.



If it's an rpm, the upgrades should cleanup after themselves.  Do we
have 

Re: [openstack-dev] [keystone] Stepping down from keystone core

[Henry Nash]

Echoing the comments of others. - thanks for all your hard work and expertise.

Henry
> On 23 Nov 2016, at 15:05, Lance Bragstad  wrote:
> 
> Thanks for all your hard work, Marek. It's been a pleasure working with you. 
> Best of luck and hopefully our paths cross in the future!
> 
> On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli  > wrote:
> Marek, thanks for everything you've done in Keystone. It was loads of fun to 
> develop some of the early federation work with you back in the Icehouse 
> release! Good luck in whatever the future holds for you! 
> 
> On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis  > wrote:
> Hi,
> 
> Due to my current responsibilities I cannot serve as keystone core anymore. I 
> also feel I should make some space for others who will surely bring new 
> quality to the OpenStack Identity Program.
> 
> It's been a great journey, I surely learned a lot and improved both my 
> technical and soft skills. I can only hope my contributions and reviews have 
> been useful and made OpenStack a little bit better.
> 
> I wish you all the best in the future.
> 
> With kind regards,
> Marek Denis
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [keystone] Pike PTL

[Henry Nash]

Steve,

It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy 
taking some time back!

Henry
> On 21 Nov 2016, at 19:38, Steve Martinelli  wrote:
> 
> one of these days i'll learn how to spell :)
> 
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli  > wrote:
> Keystoners, 
> 
> I do not intend to run for the PTL position of the Pike development cycle. 
> I'm sending this out early so I can work with folks interested in the role, 
> If you intend to run for PTL in Pike and are interested in learning the ropes 
> (or just want to hear more about what the role means) then shoot me an email.
> 
> It's been an unforgettable ride. Being PTL a is very rewarding experience, I 
> encourage anyone interested to put your name forward. I'm not going away from 
> OpenStack, I just think three terms as PTL has been enough. It'll be nice to 
> have my evenings back :) 
> 
> To *all* the keystone contributors (cores and non-cores), thank you for all 
> your time and commitment. More importantly thank you for putting up with my 
> many questions, pings, pokes and -1s. Each of you are amazing and together 
> you make an awesome team. It has been an absolute pleasure to serve as PTL, 
> thank you for letting me do so.
> 
> stevemar
> 
> 
> 
> 
> Thanks for the idea Lana [1]
> [1] 
> http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack 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] Team meeting is cancelled for Thursday 11/24

[Matt Riedemann]

By the time the nova meeting rolls around I'll be crying because of (1) 
my beloved MN Vikings losing to the lowly Lions and (2) eating too much 
and feeling ashamed.


At least with (1) I'm not Jay who is a Browns fan. They are the worst. :)

See you all next week.

--

Thanks,

Matt Riedemann


__
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] [acceleration]Team Biweekly Meeting 2016.11.23 agenda

[Zhipeng Huang]

Hi team,

Thanks for the discussion and please find the minutes here
https://wiki.openstack.org/wiki/Cyborg/MeetingLogs

On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang 
wrote:

> Forward here again in case you have not registered to openstack-dev
> mailinglist
>
> -- Forwarded message --
> From: Zhipeng Huang 
> Date: Wed, Nov 23, 2016 at 8:34 PM
> Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
>
> Hi Team,
>
> Please find the meeting logistics and agendas at
> https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [kolla] [Infra] Kolla-ansible is available

[Paul Belanger]

On Tue, Nov 15, 2016 at 06:28:19PM +, Jeremy Stanley wrote:
> On 2016-11-15 12:20:35 -0600 (-0600), Michał Jastrzębski wrote:
> > I think we could use git submodule in kolla-ansible to download kolla.
> > That would help us deal with gates in kolla-ansible short term.
> > Thoughts?
> 
> The Infra team has _strongly_ recommended against employing Git
> submodules within repos hosted on our Gerrit instance in the past,
> for a number of reasons.
> 
> If your primary concern is about making sure you integration test
> kolla-ansible with kolla, using zuul-cloner to retrieve
> corresponding refs for them in your jobs will provide a much more
> complete picture of both. Your proposed submodule would only allow
> you to test proposed changes for kolla-ansible against merged
> changes in kolla, making it easier to break kolla-ansible when
> merging incompatible changes to kolla and also robbing you of the
> ability to rely on cross-repo change dependencies between both
> repos.
> -- 
> Jeremy Stanley

I cannot agree more with this statement, and recommend working with
openstack-infra per Jeremy's suggestions.

__
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] [networking-sfc] #networking-sfc IRC channel

[Ravi Sekhar Reddy Konda]

+1


Thanks,
Ravi Sekhar
- Original Message -
From: bcafa...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 23, 2016 7:18:53 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar  wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor
>  wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and will
>> stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> __
>> 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
>



-- 
Bernard Cafarelli

__
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] [kolla] Kolla-ansible is available

[Jeffrey Zhang]

​​
​​
does
​
anyone
​ ​
has
an idea to leverage zuul's cross project testing[0] for kolla and
kolla-ansibe
gate?
​


Here is a use case:

when implementing A service, we need

* add dockerfile in kolla project
* add ansible role in kolla-ansible project

there are in the different project. assume that gate can test service A in
kolla and
kolla-ansible
​
*
how could we archive this before the dockerfile part is not merged?
*
and do not merge all these two patches until
the
patch
es
are both green?

I think cross project testing should be helpful. But after reading it more
times,
I am still confused with the second table.

>
> Change Project Zuul Ref. Description
> 1 acme master/Z1 acme master + change 1
> 2 acme master/Z2 acme master + change 1
> 2 plugin stable/Z2 plugin stable + change 2
> 3 acme master/Z3 acme master + change 1
> 3 plugin stable/Z3 plugin stable + change 2
> 3 plugin master/Z3 plugin master + change 3


How above is generated? Will it generate 6 jobs to run? and how kolla can
leverage it?

[0] http://docs.openstack.org/infra/zuul/gating.html#cross-project-testing

On Thu, Nov 17, 2016 at 2:53 AM, Michał Jastrzębski 
wrote:

> So I can see value of moving configs to kolla itself, but that would
> require significant ansible-fu to get it properly separated, I'd
> suggest separating this discussion from general announcement. If
> someone is willing to make effort of clean separation of configs from
> ansible, let's discuss how to do it technically.
>
> On 16 November 2016 at 12:39, Fox, Kevin M  wrote:
> > I think some kolla-kubernetes folks will still want to use kolla
> genconfig.
> >
> > Not sure it really does need the ansible dependency though. if the dep is
> > removed, it may be better to put it in the kolla repo then the
> kolla-ansible
> > repo.
> >
> > Thanks,
> > Kevin
> > 
> > From: Jeffrey Zhang [zhang.lei@gmail.com]
> > Sent: Tuesday, November 15, 2016 11:55 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [kolla] Kolla-ansible is available
> >
> >
> > On Wed, Nov 16, 2016 at 9:10 AM, Fox, Kevin M 
> wrote:
> >>
> >> whats the plan for genconfig? its based on ansible right now, but may
> fit
> >> better as a non ansible specific tool?
> >
> >
> > the core issue is: k8s depends on the ansible configuration file.
> > now Kolla is split. how the kolla-k8s generate the configuration file?
> if it
> > still re-use the ansible configuration file. we do not need any change.
> >
> >
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [all][ptls][tc][goals] acknowledging community goals for Ocata

[Doug Hellmann]

Excerpts from joehuang's message of 2016-11-23 02:37:12 +:
> Hello, Doug,
> 
> Tricircle will submit a patch for the "remove-incubated-oslo-code.rst" goal. 
> For Tricircle was just approved last week, need to dig into how to achieve 
> this goal.
> 
> Best Regards
> Chaoyi Huang (joehuang)

That sounds good. I know the timing may be a little tight for you. Let
me know if I can help with any of the analysis.

Doug

> 
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: 16 November 2016 23:35
> To: openstack-dev
> Subject: [openstack-dev] [all][ptls][tc][goals] acknowledging community goals 
> for Ocata
> 
> We still have quite a few teams who have not acknowledged the goal for
> Ocata. Remember, *all* teams are expected to respond, even if there is
> no work to be done. The most important feature of this new process is
> communication, which won't happen if teams don't participate.
> 
> Please take a few minutes to review
> http://governance.openstack.org/goals/index.html and
> http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
> then submit a patch to add your planning artifacts to
> openstack/governance/goals/ocata/remove-incubated-oslo-code.rst before
> the deadline tomorrow.
> 
> Doug
> 

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

Re: [openstack-dev] [keystone] Stepping down from keystone core

[Lance Bragstad]

Thanks for all your hard work, Marek. It's been a pleasure working with
you. Best of luck and hopefully our paths cross in the future!

On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli 
wrote:

> Marek, thanks for everything you've done in Keystone. It was loads of fun
> to develop some of the early federation work with you back in the Icehouse
> release! Good luck in whatever the future holds for you!
>
> On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis  com> wrote:
>
>> Hi,
>>
>> Due to my current responsibilities I cannot serve as keystone core
>> anymore. I also feel I should make some space for others who will surely
>> bring new quality to the OpenStack Identity Program.
>>
>> It's been a great journey, I surely learned a lot and improved both my
>> technical and soft skills. I can only hope my contributions and reviews
>> have been useful and made OpenStack a little bit better.
>>
>> I wish you all the best in the future.
>>
>> With kind regards,
>> Marek Denis
>>
>
>
> __
> 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] [networking-sfc] #networking-sfc IRC channel

[Bernard Cafarelli]

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar  wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor
>  wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and will
>> stay online to keep it open.
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>>
>> __
>> 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
>



-- 
Bernard Cafarelli

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

[openstack-dev] [Cinder] Today's meeting cancelled

[Sean McGinnis]

Hey everyone,

Due to flight delays and a very light agenda, today's Cinder meeting is
cancelled. Meetings will resume next week.

The main thing I wanted to mention today for all cores (and those willing
to do the reviews), please try to spend a little time on driver reviews.
Our new driver deadline is coming up quick. There are maybe one or two
that were close to ready last I looked, but there were a few that definitely
needed some feedback.

Thanks! Enjoy the US holiday break.

Sean


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

Re: [openstack-dev] [mistral] Meeting Time

[Deja, Dawid]

On Tue, 2016-11-22 at 16:29 +, Dougal Matthews wrote:
> 
> 
> On 22 November 2016 at 11:11, Deja, Dawid 
> wrote:
> > Dougla, Renat
> > 
> > If we want to have another meeting that would suit mostly New
> > Zeland
> > and US, can we move current meeting time to slightly earlier, so it
> > fits India better (and also may be more comfortable for people in
> > Europe)?
> 
> That should be fine with me. How much earlier would it need to be?

I would not say that I 'need' it to be earlier. That was just a thought
so we can make it easier for folks from India to participate.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Florian Fuchs]

- Original Message -
> From: "Dougal Matthews" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, November 22, 2016 6:01:49 PM
> Subject: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core
> 
> Hi all,
> 
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
> 
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
> 
> I think she will be a valuable addition to the review team
> 
> Dougal

+1!

Florian

> 
> 
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
> 
> __
> 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] Fwd: [acceleration]Team Biweekly Meeting 2016.11.23 agenda

[Zhipeng Huang]

Forward here again in case you have not registered to openstack-dev
mailinglist

-- Forwarded message --
From: Zhipeng Huang 
Date: Wed, Nov 23, 2016 at 8:34 PM
Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>


Hi Team,

Please find the meeting logistics and agendas at https://wiki.openstack.org/
wiki/Meetings/CyborgTeamMeeting

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Emilien Macchi]

14 positive votes, I guess that's enough ;-)
Congratulations, Julie!

(added to tripleo-core in Gerrit)

On Wed, Nov 23, 2016 at 6:15 AM, Jiri Tomasek  wrote:
>
>
> On 22.11.2016 18:01, Dougal Matthews wrote:
>
> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team
>
> Dougal
>
>
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
>
> __
> 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
>
> +1!
>
> -- Jirka
>
> __
> 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
>



-- 
Emilien Macchi

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

[openstack-dev] [acceleration]Team Biweekly Meeting 2016.11.23 agenda

[Zhipeng Huang]

Hi Team,

Please find the meeting logistics and agendas at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [networking-sfc] #networking-sfc IRC channel

[Mohan Kumar]

Yes , It will be good

Thanks.,
Mohankumar.N

On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi networking-sfc’s leaders, devs and users,
>
>
>
> What do you think about having an IRC channel dedicated to
> networking-sfc’s discussions and sync?
>
>
>
> For the time being  I have joined #networking-sfc @ freenode, and will
> stay online to keep it open.
>
>
>
> Best regards,
>
> Igor.
>
>
>
> __
> 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] [networking-sfc] #networking-sfc IRC channel

[Vikram Choudhary]

+1 for networking-sfc!

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: 23 November 2016 16:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

__
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] [networking-sfc] #networking-sfc IRC channel

[Duarte Cardoso, Igor]

Hi networking-sfc's leaders, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

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

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Jiri Tomasek]

On 22.11.2016 18:01, Dougal Matthews wrote:

Hi all,

I would like to propose we add Julie (jpich) to the TripleO core team 
for python-tripleoclient and tripleo-common. This nomination is based 
partially on review stats[1] and also my experience with her reviews 
and contributions.


Julie has consistently provided thoughtful and detailed reviews since 
the start of the Newton cycle. She has made a number of contributions 
which improve the CLI and has been extremely helpful with other tasks 
that don't often get enough attention (backports, bug 
triaging/reporting and improving our processes[2]).


I think she will be a valuable addition to the review team

Dougal


[1]: http://stackalytics.com/report/contribution/tripleo-group/90
[2]: https://review.openstack.org/#/c/352852/


__
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

+1!

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

[openstack-dev] [kolla] Notes on Ansible fact gathering

[Paul Bourke]

There is some concerns internally around Ansible fact gathering, and how 
it relates to adding / removing individual nodes in Kolla. As I've spent 
a fair bit of time in this area I decided to send some info around both 
for anyone confused about this in the future and also to tease out any 
ways we might be able to do this better.


Here is some info on how Ansible fact gathering works, and how it 
relates to decisions around adding / removing single nodes.


Many roles need to know info about other nodes in the cluster. This is 
true regardless of whether they are being deployed individually or as 
part of a larger deploy. As Ansible is a push based tool, the only way 
they can get this information is to ssh to those nodes and gather that 
info in the form of 'facts'.


Ideally, Ansible would only touch (i.e. run fact gathering) on nodes 
referenced inside it's play[2]. However, it is not smart enough to do 
this, and so each node a play cares about must be listed explicitly up 
front in the playbook. In the past this has being a maintenance burden, 
as any time a new role was added that for example, needed to know about 
the IP addresses of all rabbitmq servers, care had to be taken to also 
list that group of nodes under that new play. If this wasn't done 
correctly, it lead to the commonly reported "'dict object' has no 
attribute u'ansible_eth0'".


After discussion and research it was determined by Kolla[0][1] that the 
most reliable and pragmatic way to solve this was to gather facts about 
all nodes up front, once. In the case of a full deploy, this will 
essentially happen anyway. For the single node case however, it's not 
ideal as it may visit more nodes than needed. It's still my belief that 
this is the least error prone solution 'out of the box'. In the cases 
where users have 500 control nodes and want to add five more 
sequentially (the value of doing more than one sequentially is still not 
clear to me), we could look into turning on fact caching. Given the fact 
gathering in my experience is reasonably fast however, combined with 
Ansible ssh pipelining, I'm not sure how much this would even gain.


-Paul

[0] https://review.openstack.org/#/c/376524/
[1] https://review.openstack.org/#/c/398313/
[2] 
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova/templates/nova.conf.j2#L64


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

Re: [openstack-dev] [tricircle]Questions about Tricircle L2 and L3 implementation

[dina.sol]

Hello Chaoyi,

Thanks for your answer.

Related to Route Target parameter (RT) : I referred to the figure displaying 
pods interconnection through an E-VPN L2 network ("Tricircle in a nutshell" 
presentation).

My question is : how are there populated and/or exchanged through the E-VPN 
interconnection ?

Thanks,

Best Regards,

Dina

De : joehuang [mailto:joehu...@huawei.com]
Envoyé : mercredi 23 novembre 2016 04:20
À : SOL Dina IMT/OLN; openstack-dev
Objet : RE: [openstack-dev][tricircle]Questions about Tricircle L2 and L3 
implementation

Hello, Dina,

Thank you for your comments, it'll be good to discuss tricircle related topic 
in openstack-dev so that more people can be involved in if necessary, and keep 
the project transparent. So I copied the reply to  
openstack-dev@lists.openstack.org.

For L2VxLAN, the VNI identifiers will be allocated in central Neutron, and then 
same VNI segment will be used for local Neutron during get_network or get_port 
from Nova, the local plugin in local Neutron will query the network segment 
info. and persist same uuid and VNI in local Neutron. But VxLAN based cross 
Neutron L2 networking has not started yet, the spec has not submitted for 
review yet, currently only VLAN based L2/L3 networking were implemented, 
supported features could be found in the release 
notes:https://github.com/openstack/tricircle/blob/master/releasenotes/notes/initial-release-notes.yaml
 .

 VxLAN L2 networking and VxLAN as the bridge network for L3 networking will 
rely on the patch for "formalize the tunnel termination point by adding it to 
the port binding data model" which is mentioned in "Eliminating L2pop as a 
mechanism driver" 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

Before VxLAN L2 networking and VxLAN as the bridge network for L3 networking, 
this spec is being reviewed, https://review.openstack.org/#/c/396564/, please 
join the review to see whether it can meet your demands, especially for the 
cross Neutron networking models.

What is "RT parameters"?

Tricircle supported L3 networking based on shared VLAN bridge network, you can 
refer to "6.6  L3 Networking across Neutron", but just as what mentioned in the 
release notes,  only VLAN L2 network and shared VLAN as the bridge network for 
L3 networking are supported.

There are todo list for the usage documentation in ocata release, you are 
welcome to join the contribution, no matter documentation or source code or 
review.

Best Regards
Chaoyi Huang (joehuang)

From: dina@orange.com [dina@orange.com]
Sent: 22 November 2016 21:54
To: joehuang
Subject: Questions about Tricircle L2 and L3 implementation
Hello Chaoyi Huang,

I have read Tricirle wiki documentation and some presentations.
May I ask you I have few questions about Tricircle implementation ?
Here there are :

1°) L2 VxLAN
How are choosen VNI identifiers ?
How are choosen RT parameters ? Is a control plane used or all is configured 
within a pool ?

2°) L3
Does Tricircle support L3 interconnection ?
Have you documentation about that ?

Thanks,
Best Regards,

Dina SOL

[logo-Orange]
Dina Sol
Orange/ IMT/ OLN/ WTC/ IEE/ NAVI (Network Automation and Virtualized 
Infrastructure)
Orange Labs
2, avenue Pierre Marzin
22307 Lannion Cedex
tel : 00 33 (0)2 96 07 11 22
dina@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles 

Re: [openstack-dev] centralized calendar for reoccurring tasks

[Tony Breeds]

On Wed, Nov 23, 2016 at 04:39:30AM -0600, Matthew Thode wrote:
> Does Openstack (infra) have a centralized calendar that teams could used
> for reoccurring tasks/bugs?  Something like this would be useful for
> things ranging from reminders for meetings (for which I think there may
> be a calendar) to project 'cleanup' tasks.

We have one for meetings [1]  And we're making one for "cross project" items in
[2].

I don't know of any OpenStack wide ones.

Yours Tony.

[1] http://eavesdrop.openstack.org/irc-meetings.ical
[2] https://releases.openstack.org/ocata/schedule.html


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

[openstack-dev] centralized calendar for reoccurring tasks

[Matthew Thode]

Does Openstack (infra) have a centralized calendar that teams could used
for reoccurring tasks/bugs?  Something like this would be useful for
things ranging from reminders for meetings (for which I think there may
be a calendar) to project 'cleanup' tasks.

I specifically recognized the usefulness for something like this for
audits the requirements team wishes to do to ensure no duplicate /
unmaintained libraries are used.

-- 
-- Matthew Thode (prometheanfire)



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

[openstack-dev] [neutron][tacker] Trunk ports in Tacker?

[zhi]

Hi, all

Recently I did some research about trunk port in neutron by following
document[1]. By creating a trunk port, I can use this port ( aka " parent
port " ) to create a VM. So I can add or remove subports on this "parent
port" which used by the VM I created.

I want to know how Tacker can use " trunk port ". In Tacker, I can create a
VNFD template which contains network infos like
"
VL1:
  type: tosca.nodes.nfv.VL
  properties:
network_name: net_mgmt
vendor: Tacker
"
So I can use this template to create VNFs with specific network info(
naming net_mgmt ). Finally VNFs own its normal ports in neutron. So my
question is:

Can I use trunk ports in Tacker?

I read some document about VLAN transparent in Neutron. In my thought, I
can create a vlan transparent network in Neutron and using this network in
VNFD template. At last, every VNF's
port is " trunk port " and I can add or remove subports on it. Am I right?

In Newton, I enabled the vlan-transparent in neutron server and try to
create a vlan transparent network. But I failed. I got the error message
is: " Backend does not support VLAN Transparency ".

VLAN transparent doesn't support in Newton now?


Thanks
Zhi Chang

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

Re: [openstack-dev] [all] [Rally] broken jobs

[Renat Akhmerov]

Great news! Thanks for reacting timely.

Renat Akhmerov
@Nokia

> On 23 Nov 2016, at 14:25, Andrey Kurilin  wrote:
> 
> Finally, fixes are merged and our jobs work now.
> 
> On Tue, Nov 22, 2016 at 3:01 PM, Andrey Kurilin  > wrote:
> Hi Renat,
> 
> As soon as one [1][2] changes will be merged, everything should be unblocked.
> 
> [1] - https://review.openstack.org/#/c/399752 
> 
> [2] - https://review.openstack.org/#/c/400183 
> 
> 
> 
> On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov  > wrote:
> Andrey, thanks for reporting this. Any estimations on how long it will take 
> to fix it?
> 
> Renat Akhmerov
> @Nokia
> 
>> On 19 Nov 2016, at 02:23, Andrey Kurilin > > wrote:
>> 
>> yse, I think you are right.
>> 
>> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung > > wrote:
>> this seems related to fact we use datetime type in mysql which requires
>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
>> required mysql.
>> 
>> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
>> > Hi stackers,
>> >
>> > I hate to report such things, but most of rally jobs are broken now due
>> > to uncompatibility aodh service with ubuntu-trusty nodes.
>> >
>> > If you find failed rally jobs with
>> > http://paste.openstack.org/show/589707/ 
>> >  in devstacklogs, recheck will
>> > not help.
>> >
>> > I'm working on two changes now for Rally jobs which should unblock and
>> > fix gates:
>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time 
>> > ago.
>> > - Disable telemetry services in those jobs which do not need them.
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Kurilin.
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> > 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> > 
>> >
>> 
>> --
>> gord
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Andrey Kurilin.
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> 
> -- 
> Best regards,
> Andrey Kurilin.
> 
> 
> 
> -- 
> Best regards,
> Andrey Kurilin.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
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