Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

On Tue, Mar 29, 2016 at 3:25 PM, joehuang  wrote:
> I think we can do it later.

Yes, it's not priority at the moment. Priority is to find out what's
going on. But honestly it would be time consuming because of below.

> It's still a little bit strange that if nova-network in the Local.conf is 
> disabled at first before devstack installation, the devstack should use 
> Neutron instead, not sure how clean Yipei's environment is.

It may be difficult to completely clean up envirnment without os fresh
installation.

>
> I suggest Yipei to use clean virtual machines running in virtualbox, and 
> follow the readme[1] and pengfei's experience[2] to install Tricircle.

Yes, it would save our life. Of course **backing up configurations**
is 1st, if necessary.

Cheers,
S

>
> [1] https://github.com/openstack/tricircle/blob/master/README.md
> [2] http://shipengfei92.cn/play_tricircle_with_virtualbox
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Tuesday, March 29, 2016 10:48 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Yipei Niu
> Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node 
> configuration
>
> Sorry for interruption.
>
>>> I followed the README.md in github, every thing goes well until I
>>> boot virtual machines with the following command
>
> Point here is that even Yipei was following READM provided by us, setting up 
> the tricircle was failed. [1] It may be required to review it, I think.
>
> [1] https://github.com/openstack/tricircle/blob/master/README.md
>
> Cheers,
> Shinobu
>
>
> On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai  wrote:
>> Hi Yipei,
>>
>> If you want to use neutron, you need to set "nova_api_class" to
>> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
>> network.
>>
>> Related code:
>> https://github.com/openstack/nova/blob/master/nova/network/__init__.py
>> #L47
>>
>> Simply search "Unknown argument: port" which is the error showed in
>> the log in the nova code tree then you can find the above code.
>>
>> Also, if all the services are running but you want to change some of
>> the configuration options, you can just modify the configuration files
>> then restart the services, so you can quickly check if your
>> modification works without restarting devstack.
>>
>> BR
>> Zhiyuan
>>
>> On 29 March 2016 at 08:56, Yipei Niu  wrote:
>>>
>>> Hi, all,
>>>
>>> I checked nova.conf and local.conf both.
>>>
>>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>>> is set as True. I modify the lib/nova so that the devstack can write
>>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However,
>>> after installing devstack with tricircle, the same error still happens as 
>>> before.
>>>
>>> In local.conf, n-net is disabled, which is the same as the sample
>>> file of tricircle.
>>>
>>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>>
>>> Best regards,
>>> Yipei
>>>
>>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
>>> wrote:

 FYI:
 This is the reason is that there is still n-net. [1]

 [1]
 http://docs.openstack.org/openstack-ops/content/nova-network-depreca
 tion.html

 Cheers,
 S

 On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
 > Hi,
 >
 >
 >
 > Agree, it’s quite important not to use Nova-network in devstack.
 > In devstack local.conf, make sure the Neutron service is enabled
 > and Nova-network is disabled.
 >
 >
 >
 > # Use Neutron instead of nova-network
 >
 > disable_service n-net
 >
 > enable_service q-svc
 >
 > enable_service q-svc1
 >
 > enable_service q-dhcp
 >
 > enable_service q-agt
 >
 >
 >
 > And also check the configuration in Nova to use Neutron
 >
 >
 >
 > Best Regards
 >
 > Chaoyi Huang ( Joe Huang )
 >
 >
 >
 > From: Vega Cai [mailto:luckyveg...@gmail.com]
 > Sent: Monday, March 28, 2016 2:55 PM
 > To: Yipei Niu
 > Cc: OpenStack Development Mailing List (not for usage questions);
 > joehuang
 > Subject: Re: [openstack-dev] [tricircle] playing tricircle with
 > two node configuration
 >
 >
 >
 > Hi Yipei,
 >
 >
 >
 > Check "network_api_class" and "use_neutron" options in your nova.conf.
 > It
 > seems that your nova API is not configured to use neutron.
 >
 >
 >
 > BR
 >
 > Zhiyuan
 >
 >
 >
 > On 28 March 2016 at 13:25, Yipei Niu  wrote:
 >
 > Hi, all,
 >
 >
 >
 > After I execute the command "nova boot --flavor 1 --image
 > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
 > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone
 > az1 vm1", there exist some problem with the argument port. In
 > t-ngw.log, I find that the status of port

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[joehuang]

I think we can do it later. It's still a little bit strange that if 
nova-network in the Local.conf is disabled at first before devstack 
installation, the devstack should use Neutron instead, not sure how clean 
Yipei's environment is. 

I suggest Yipei to use clean virtual machines running in virtualbox, and follow 
the readme[1] and pengfei's experience[2] to install Tricircle.

[1] https://github.com/openstack/tricircle/blob/master/README.md
[2] http://shipengfei92.cn/play_tricircle_with_virtualbox

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Tuesday, March 29, 2016 10:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Yipei Niu
Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node 
configuration

Sorry for interruption.

>> I followed the README.md in github, every thing goes well until I 
>> boot virtual machines with the following command

Point here is that even Yipei was following READM provided by us, setting up 
the tricircle was failed. [1] It may be required to review it, I think.

[1] https://github.com/openstack/tricircle/blob/master/README.md

Cheers,
Shinobu


On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai  wrote:
> Hi Yipei,
>
> If you want to use neutron, you need to set "nova_api_class" to 
> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova 
> network.
>
> Related code:
> https://github.com/openstack/nova/blob/master/nova/network/__init__.py
> #L47
>
> Simply search "Unknown argument: port" which is the error showed in 
> the log in the nova code tree then you can find the above code.
>
> Also, if all the services are running but you want to change some of 
> the configuration options, you can just modify the configuration files 
> then restart the services, so you can quickly check if your 
> modification works without restarting devstack.
>
> BR
> Zhiyuan
>
> On 29 March 2016 at 08:56, Yipei Niu  wrote:
>>
>> Hi, all,
>>
>> I checked nova.conf and local.conf both.
>>
>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>> is set as True. I modify the lib/nova so that the devstack can write 
>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However, 
>> after installing devstack with tricircle, the same error still happens as 
>> before.
>>
>> In local.conf, n-net is disabled, which is the same as the sample 
>> file of tricircle.
>>
>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>
>> Best regards,
>> Yipei
>>
>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
>> wrote:
>>>
>>> FYI:
>>> This is the reason is that there is still n-net. [1]
>>>
>>> [1]
>>> http://docs.openstack.org/openstack-ops/content/nova-network-depreca
>>> tion.html
>>>
>>> Cheers,
>>> S
>>>
>>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > Agree, it’s quite important not to use Nova-network in devstack. 
>>> > In devstack local.conf, make sure the Neutron service is enabled 
>>> > and Nova-network is disabled.
>>> >
>>> >
>>> >
>>> > # Use Neutron instead of nova-network
>>> >
>>> > disable_service n-net
>>> >
>>> > enable_service q-svc
>>> >
>>> > enable_service q-svc1
>>> >
>>> > enable_service q-dhcp
>>> >
>>> > enable_service q-agt
>>> >
>>> >
>>> >
>>> > And also check the configuration in Nova to use Neutron
>>> >
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Chaoyi Huang ( Joe Huang )
>>> >
>>> >
>>> >
>>> > From: Vega Cai [mailto:luckyveg...@gmail.com]
>>> > Sent: Monday, March 28, 2016 2:55 PM
>>> > To: Yipei Niu
>>> > Cc: OpenStack Development Mailing List (not for usage questions); 
>>> > joehuang
>>> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with 
>>> > two node configuration
>>> >
>>> >
>>> >
>>> > Hi Yipei,
>>> >
>>> >
>>> >
>>> > Check "network_api_class" and "use_neutron" options in your nova.conf.
>>> > It
>>> > seems that your nova API is not configured to use neutron.
>>> >
>>> >
>>> >
>>> > BR
>>> >
>>> > Zhiyuan
>>> >
>>> >
>>> >
>>> > On 28 March 2016 at 13:25, Yipei Niu  wrote:
>>> >
>>> > Hi, all,
>>> >
>>> >
>>> >
>>> > After I execute the command "nova boot --flavor 1 --image
>>> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
>>> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone 
>>> > az1 vm1", there exist some problem with the argument port. In 
>>> > t-ngw.log, I find that the status of port switches from ACTIVE to 
>>> > DOWN, which is marked as bold below. Is it the reason why I failed 
>>> > to boot a VM?
>>> >
>>> >
>>> >
>>> > 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
>>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin 
>>> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i 
>>> > http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
>>> > python-neutronclient" -H "X-Auth-Token:
>>> > 7cfcfb91173a4920adaf24db7eebd773" -d
>>> > '{"port": {"network_id": "a9059cde-3065-4615-859a

[openstack-dev] [Nova] Is parallel filter scheduler still a problem we should considered?

[Elissa Zhu]

Hi, all.

I was thinking about the parallel filter scheduler problem these days.
Main problem is the selection conflict among multiple filter scheduler 
instances.

Now nova-scheduler can retry when the conflict happened. Someone said it is 
enough in practise to solve this problem, moreover, the conflict only impacts 
when the selected host's resource is exhaused.

So I'd like to have your opinion on this issue.
Thank you!

发自网易邮箱手机版


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

[openstack-dev] [election][TC] TC Candidacy

[Davanum Srinivas]

Fellow Stackers,

I would like to announce my candidacy for the OpenStack Technical Committee
election.

Currently i am employed by Mirantis and take manage a couple teams, one working
primarily on Oslo/RabbitMQ/ZMQ and the other on Keystone. My other job is
contributing upstream where i can including several Oslo projects, Nova,
Requirements and Release team. I have served as PTL for Oslo for the last
two terms and am proud of our accomplishments including getting rid of the
oslo-incubator, building up our test matrix for better backwards compatibility
testing and increasing the number of people invested in different Oslo projects.

We have a lot of challenges including figuring out how to balance
stability/innovation, fostering new talent, target our limited resources
to make OpenStack even better than it is today. I would like to offer some
ideas as part of the technical committee based on my previous experiences
at ASF, a startup, working at Big Blue etc.

While working on Oslo as PTL, gave me a lot of insight into how different
projects go about their work. Being part of the Requirements and Release
team has helped me understand the day-to-day challenges of how we pull in
different directions but still end up moving forward. Spending time looking
at gate issues and setting up CI jobs has given me a lot of appreciation
around how many things there are we could work on and fix. As part of
the technical committee, i am hoping to help with:

- Cross Project issues, increasing collaboration between projects
- Backwards compatibility issues and testing
- Evangelizing great ideas from different projects

Starting with @markmc, @sdague, @dhellmann and a whole of of others i have
received a lot of support and guidance over the years. I would like to
pay it forward for the new set of folks who are coming, learning
our ways and becoming part of our community.

Thanks,
Dims

Review history: https://review.openstack.org/#/q/reviewer:dims-v,n,z
Commit history: https://review.openstack.org/#/q/owner:dims-v,n,z
Stackalytics: http://stackalytics.com/?user_id=dims-v
OpenHUB: https://www.openhub.net/accounts/davanum
Freenode: dims




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

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

Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent

[Kevin Carter]

On 03/28/2016 08:17 PM, Steven Dake (stdake) wrote:
>
>
> On 3/27/16, 2:50 PM, "Matt Riedemann"  wrote:
>
>>
>>
>> On 3/26/2016 11:27 AM, Steven Dake (stdake) wrote:
>>> Hey fellow PTLs and core reviewers of  those projects,
>>>
>>> Kolla at present deploys  the compute kit, and some other services that
>>> folks have added over time including other projects like Ironic, Heat,
>>> Mistral, Murano, Magnum, Manilla, and Swift.
>>>
>>> One of my objectives from my PTL candidacy was to deploy the big tent,
>>> and I  saw how we were not super successful as I planned in Mitaka at
>>> filling out the big tent.
>>>
>>> While the Kolla core team is large, and we can commit to maintaining big
>>> tent projects that are deployed, we are at capacity every milestone of
>>> every cycle implementing new features that the various big tent services
>>> should conform to.  The idea of a plugin architecture for Kolla where
>>> projects could provide their own plugins has been floated, but before we
>>> try that, I'd prefer that the various teams in OpenStack with an
>>> interest in having their projects consumed by Operators involve
>>> themselves in containerizing their projects.
>>>
>>> Again, once the job is done, the Kolla community will continue to
>>> maintain these projects, and we hope you will stay involved in that
>>> process.
>>>
>>> It takes roughly four 4 hour blocks to learn the implementation
>>> architecture of Kolla and probably another 2 4 hour blocks to get a good
>>> understanding of the Kolla deployment workflow.  Some projects (like
>>> Neutron for example) might fit outside this norm because containerizing
>>> them and deploying them is very complex.  But we have already finished
>>> the job on what we believe are the hard projects.
>>>
>>> My ask is that PTLs take responsibility or recruit someone from their
>>> respective community to participate in the implementation of Kolla
>>> deployment for their specific project.
>>>
>>> Only with your help can we make the vision of a deployment system that
>>> can deploy the big tent a reality.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>>
>>> _
>>> _
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Having never looked at Kolla, is there an easy way to see what projects
>> are already done? Like, what would Nova need to do here? Or is it a
>> matter of keeping up with new deployment changes / upgrade impacts, like
>> the newish nova API database?
>>
>> If that's the case, couldn't the puppet/ansible/chef projects be making
>> similar requests from the project development teams?
>>
>> Unless we have incentive to be contributing to Kolla, like say we
>> replaced devstack in our CI setup with it, I'm having a hard time seeing
>> everyone jumping in on this.
>
> Matt,
>
> The compute kit projects are well covered by the current core reviewer
> team.  Hence, we don't really need any help with Nova.  This is more aimed
> at the herd of new server projects in Liberty and Mitaka that want
> deployment options which currently lack them.  There is no way to deploy
> aodh in an automated fashion (for example) (picked because it was first in
> the project list by alphabetical order;)

Just as a point of correction, there is an automated way to deploy AODH 
The AODH project is, and has been, well represented by the 
OpenStack-Ansible community for some time. The role and playbooks were 
created back in Liberty [0] on Oct 7 2015 and has been part of our 
integrated gate since it's acceptance into the core OpenStack-Ansible 
project. Recently the "os_"aodh role has been split out into its own 
repository for use as a stand alone role. The OSA role can be found 
here: [1]

[0] - 
https://github.com/openstack/openstack-ansible-os_aodh/commit/639c11f38b47b0c4fdc7c35c33631a8cf2b19163
[1] - https://github.com/openstack/openstack-ansible-os_aodh

> For example this cycle community folks implemented mistral and manila,
> which were not really top in our priority list.  Yet, the work got done
> and now the core team will look after these projects as well.
>
> As for why puppet/ansible/chef couldn't make the same requests, the answer
> is they could.  Why haven't they?  I can never speak to the motives or
> actions of others, but perhaps they didn't think to try?

While I also can not speak to the intentions of others I will say I've 
never felt the need to burden other communities with deployment code for 
a given service because its generally not part of their development 
workflow. When I've been working on a service and needed things from the 
community developing that service I've reached out to them directly. As 
someone working on deployment code its been been great to get additional 
developer feedback from folks outside of our commu

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

Sorry for interruption.

>> I followed the README.md in github, every thing goes well until I boot 
>> virtual machines with the following command

Point here is that even Yipei was following READM provided by us,
setting up the tricircle was failed. [1] It may be required to review
it, I think.

[1] https://github.com/openstack/tricircle/blob/master/README.md

Cheers,
Shinobu


On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai  wrote:
> Hi Yipei,
>
> If you want to use neutron, you need to set "nova_api_class" to
> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
> network.
>
> Related code:
> https://github.com/openstack/nova/blob/master/nova/network/__init__.py#L47
>
> Simply search "Unknown argument: port" which is the error showed in the log
> in the nova code tree then you can find the above code.
>
> Also, if all the services are running but you want to change some of the
> configuration options, you can just modify the configuration files then
> restart the services, so you can quickly check if your modification works
> without restarting devstack.
>
> BR
> Zhiyuan
>
> On 29 March 2016 at 08:56, Yipei Niu  wrote:
>>
>> Hi, all,
>>
>> I checked nova.conf and local.conf both.
>>
>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>> is set as True. I modify the lib/nova so that the devstack can write
>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However, after
>> installing devstack with tricircle, the same error still happens as before.
>>
>> In local.conf, n-net is disabled, which is the same as the sample file of
>> tricircle.
>>
>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>
>> Best regards,
>> Yipei
>>
>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
>> wrote:
>>>
>>> FYI:
>>> This is the reason is that there is still n-net. [1]
>>>
>>> [1]
>>> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>>>
>>> Cheers,
>>> S
>>>
>>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > Agree, it’s quite important not to use Nova-network in devstack. In
>>> > devstack
>>> > local.conf, make sure the Neutron service is enabled and Nova-network
>>> > is
>>> > disabled.
>>> >
>>> >
>>> >
>>> > # Use Neutron instead of nova-network
>>> >
>>> > disable_service n-net
>>> >
>>> > enable_service q-svc
>>> >
>>> > enable_service q-svc1
>>> >
>>> > enable_service q-dhcp
>>> >
>>> > enable_service q-agt
>>> >
>>> >
>>> >
>>> > And also check the configuration in Nova to use Neutron
>>> >
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Chaoyi Huang ( Joe Huang )
>>> >
>>> >
>>> >
>>> > From: Vega Cai [mailto:luckyveg...@gmail.com]
>>> > Sent: Monday, March 28, 2016 2:55 PM
>>> > To: Yipei Niu
>>> > Cc: OpenStack Development Mailing List (not for usage questions);
>>> > joehuang
>>> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with two
>>> > node
>>> > configuration
>>> >
>>> >
>>> >
>>> > Hi Yipei,
>>> >
>>> >
>>> >
>>> > Check "network_api_class" and "use_neutron" options in your nova.conf.
>>> > It
>>> > seems that your nova API is not configured to use neutron.
>>> >
>>> >
>>> >
>>> > BR
>>> >
>>> > Zhiyuan
>>> >
>>> >
>>> >
>>> > On 28 March 2016 at 13:25, Yipei Niu  wrote:
>>> >
>>> > Hi, all,
>>> >
>>> >
>>> >
>>> > After I execute the command "nova boot --flavor 1 --image
>>> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
>>> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1
>>> > vm1",
>>> > there exist some problem with the argument port. In t-ngw.log, I find
>>> > that
>>> > the status of port switches from ACTIVE to DOWN, which is marked as
>>> > bold
>>> > below. Is it the reason why I failed to boot a VM?
>>> >
>>> >
>>> >
>>> > 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
>>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>>> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
>>> > http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
>>> > python-neutronclient" -H "X-Auth-Token:
>>> > 7cfcfb91173a4920adaf24db7eebd773" -d
>>> > '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
>>> > "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
>>> >
>>> > /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
>>> >
>>> > 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
>>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>>> > admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
>>> > 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
>>> > 'application/json; charset=UTF-8', 'Content-Length': '384',
>>> > 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
>>> > {"port": {"status": "ACTIVE", "name": "", "admin_state_up": true,
>>> > "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
>>> > "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
>>> 

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Vega Cai]

Hi Yipei,

If you want to use neutron, you need to set "nova_api_class" to
"nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
network.

Related code:
https://github.com/openstack/nova/blob/master/nova/network/__init__.py#L47

Simply search "Unknown argument: port" which is the error showed in the log
in the nova code tree then you can find the above code.

Also, if all the services are running but you want to change some of the
configuration options, you can just modify the configuration files then
restart the services, so you can quickly check if your modification works
without restarting devstack.

BR
Zhiyuan

On 29 March 2016 at 08:56, Yipei Niu  wrote:

> Hi, all,
>
> I checked nova.conf and local.conf both.
>
> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
> is set as True. I modify the lib/nova so that the devstack can write
> "nova_api_class=nova.network.api.API" to nova.conf [1]. However, after
> installing devstack with tricircle, the same error still happens as before.
>
> In local.conf, n-net is disabled, which is the same as the sample file of
> tricircle.
>
> [1] http://docs.openstack.org/developer/nova/sample_config.html
>
> Best regards,
> Yipei
>
> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
> wrote:
>
>> FYI:
>> This is the reason is that there is still n-net. [1]
>>
>> [1]
>> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>>
>> Cheers,
>> S
>>
>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
>> > Hi,
>> >
>> >
>> >
>> > Agree, it’s quite important not to use Nova-network in devstack. In
>> devstack
>> > local.conf, make sure the Neutron service is enabled and Nova-network is
>> > disabled.
>> >
>> >
>> >
>> > # Use Neutron instead of nova-network
>> >
>> > disable_service n-net
>> >
>> > enable_service q-svc
>> >
>> > enable_service q-svc1
>> >
>> > enable_service q-dhcp
>> >
>> > enable_service q-agt
>> >
>> >
>> >
>> > And also check the configuration in Nova to use Neutron
>> >
>> >
>> >
>> > Best Regards
>> >
>> > Chaoyi Huang ( Joe Huang )
>> >
>> >
>> >
>> > From: Vega Cai [mailto:luckyveg...@gmail.com]
>> > Sent: Monday, March 28, 2016 2:55 PM
>> > To: Yipei Niu
>> > Cc: OpenStack Development Mailing List (not for usage questions);
>> joehuang
>> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
>> > configuration
>> >
>> >
>> >
>> > Hi Yipei,
>> >
>> >
>> >
>> > Check "network_api_class" and "use_neutron" options in your nova.conf.
>> It
>> > seems that your nova API is not configured to use neutron.
>> >
>> >
>> >
>> > BR
>> >
>> > Zhiyuan
>> >
>> >
>> >
>> > On 28 March 2016 at 13:25, Yipei Niu  wrote:
>> >
>> > Hi, all,
>> >
>> >
>> >
>> > After I execute the command "nova boot --flavor 1 --image
>> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
>> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1
>> vm1",
>> > there exist some problem with the argument port. In t-ngw.log, I find
>> that
>> > the status of port switches from ACTIVE to DOWN, which is marked as bold
>> > below. Is it the reason why I failed to boot a VM?
>> >
>> >
>> >
>> > 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
>> > http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
>> > python-neutronclient" -H "X-Auth-Token:
>> 7cfcfb91173a4920adaf24db7eebd773" -d
>> > '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
>> > "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
>> >
>> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
>> >
>> > 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>> > admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
>> > 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
>> > 'application/json; charset=UTF-8', 'Content-Length': '384',
>> > 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
>> > {"port": {"status": "ACTIVE", "name": "", "admin_state_up": true,
>> > "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
>> > "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
>> > "fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
>> > "2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}],
>> "id":
>> > "e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
>> > ^[[00;33mfrom (pid=17537) http_log_resp
>> >
>> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
>> >
>> > 2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
>> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
>> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
>> > http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
>> > python-neutronclient" -H "X

Re: [openstack-dev] [election] [tc] TC candidacy

[Monty Taylor]

On 03/28/2016 06:09 PM, joehuang wrote:

Hi, Thierry,

One question about this  ' The transition to the "big tent" governance model is now 
finished, with all the expected projects now officially part of the OpenStack community. The big 
tent is all about community: answering the "are you one of us" question.'.

Does it mean that no more project will be approved to be a big tent project in 
the Newton and Ocata release?


No - I believe that Thierry was trying to say we've finished our 
governance transition so that now we apply the new criteria when we add 
projects to the Big Tent.



Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: Monday, March 28, 2016 11:53 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election] [tc] TC candidacy

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical Committee. For those who 
don't know me yet, my name is Thierry Carrez, I use "ttx" as my IRC nickname. 
I'm currently employed by the OpenStack Foundation as its Director of Engineering, which 
basically means I'm running the team in charge of ensuring the long-term health of the 
upstream OpenStack open source project and its governance. Handling the Technical 
Committee is my primary activity: 6 months ago I left the PTL role for the Release 
Management Team in order to be able to focus as much as possible on the TC.

One year ago I ran for election with the goal of having the TC "step out of the way"[1]. 
The idea was to remove the TC from the critical path of getting things done, and encourage a 
"ask for forgiveness, rather than permission" attitude in our community. I like to think 
we were successful at this. Project teams can now more easily add git repositories as they need 
them, they also end up asserting some tags by themselves, and the TC has generally moved to being 
an appeals board in case of disputes, rather than a procedural barrier in getting things done.

Here are the three priorities for my upcoming mandate, if the electorate 
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with all the expected projects 
now officially part of the OpenStack community. The big tent is all about community: answering the "are 
you one of us" question. Our approach there was to be inclusive and assume good faith, especially as we 
caught up on documenting what we meant by "the OpenStack Way". Over the past year we created the 
Project Team Guide[2], which clearly explains what is expected of official project teams. I think it's time 
for us to look back at all those projects we have in the tent, reach out to those who are lacking, and not 
hesitate to remove the ones that are not following our common community practices from the list of official 
project teams. Demoting a project used to be particularly painful, with costly git repository renames crating 
disruption on the demoted projects. But now that all projects hosted under our infrastructure (official and 
unofficial) use the same namespace, this cost and di

s
ruption are very limited, so cleaning up the big tent is now possible.


2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no good 
answer: Poppy and Tacker. Those resulted in close (and somewhat
arbitrary) votes as each TC member tried to interpret the mission statement words and 
what we stand for. In the case of Poppy, there was the question of whether a service that 
proxies to non-OpenStack commercial services could be considered part of 
"OpenStack", without an open source reference implementation to do end-to-end 
testing against.
In the case of Tacker, there was the question of a service standing on top of other OpenStack 
services to present a domain-specific API tailored to a specific use case or industry. Should that 
still be "OpenStack", or just something that consumes OpenStack ? I'd like the TC to take 
a step back and explore those two questions, without the pressure of a specific project team 
addition. Clarifying the rules may result in some official projects to be demoted to 
"unofficial" status as they would not fit the rules anymore.

3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit"
into wider community feedback / requirements-gathering sessions (that would 
happen at the main Summit) and a specific event for project team members to 
gather in a co-located venue to come up with a plan and organize its execution. 
We still have a long way to go (and not that much time) to discuss the format 
and the timing of this new event, and I expect the Newton membership of the TC 
to help with taking quick decisions there. The next step here will be a 
cross-project workshop at the Desi

Re: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

[Wang, Yalei]

Hi zhi,

Someone is working on full distributed SNAT, like this:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/network-node-is-not-needed-anymore-completed-distributed-virtual-router

/Yalei

From: Zhi Chang [mailto:chang...@unitedstack.com]
Sent: Saturday, March 26, 2016 1:53 PM
To: openstack-dev
Subject: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT 
distributed?

hi all.

I have some questions about NAT in DVR.

In Neutron, we provide two NAT types. One is SNAT, we can associate a 
floating ip to router so that all vms attached this router can connect external 
network. The other NAT types is DNAT, we can connect a vm which associated 
floating ip from external network.

 Question A, Why keep SNAT centralized? We put the SNAT namespace in 
compute node which running DVR l3 agent, don't we?

 Question B, Why keep DNAT distributed? I think we can keep snat namespace 
and fip namespace in one node. Why not keep DNAT and SNAT together?


Thanks
Zhi CHang
__
OpenStack Development Mailing 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] [ptl][kolla][release] Deploying the big tent

[Steven Dake (stdake)]

On 3/27/16, 2:50 PM, "Matt Riedemann"  wrote:

>
>
>On 3/26/2016 11:27 AM, Steven Dake (stdake) wrote:
>> Hey fellow PTLs and core reviewers of  those projects,
>>
>> Kolla at present deploys  the compute kit, and some other services that
>> folks have added over time including other projects like Ironic, Heat,
>> Mistral, Murano, Magnum, Manilla, and Swift.
>>
>> One of my objectives from my PTL candidacy was to deploy the big tent,
>> and I  saw how we were not super successful as I planned in Mitaka at
>> filling out the big tent.
>>
>> While the Kolla core team is large, and we can commit to maintaining big
>> tent projects that are deployed, we are at capacity every milestone of
>> every cycle implementing new features that the various big tent services
>> should conform to.  The idea of a plugin architecture for Kolla where
>> projects could provide their own plugins has been floated, but before we
>> try that, I'd prefer that the various teams in OpenStack with an
>> interest in having their projects consumed by Operators involve
>> themselves in containerizing their projects.
>>
>> Again, once the job is done, the Kolla community will continue to
>> maintain these projects, and we hope you will stay involved in that
>>process.
>>
>> It takes roughly four 4 hour blocks to learn the implementation
>> architecture of Kolla and probably another 2 4 hour blocks to get a good
>> understanding of the Kolla deployment workflow.  Some projects (like
>> Neutron for example) might fit outside this norm because containerizing
>> them and deploying them is very complex.  But we have already finished
>> the job on what we believe are the hard projects.
>>
>> My ask is that PTLs take responsibility or recruit someone from their
>> respective community to participate in the implementation of Kolla
>> deployment for their specific project.
>>
>> Only with your help can we make the vision of a deployment system that
>> can deploy the big tent a reality.
>>
>> Regards
>> -steve
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>Having never looked at Kolla, is there an easy way to see what projects
>are already done? Like, what would Nova need to do here? Or is it a
>matter of keeping up with new deployment changes / upgrade impacts, like
>the newish nova API database?
>
>If that's the case, couldn't the puppet/ansible/chef projects be making
>similar requests from the project development teams?
>
>Unless we have incentive to be contributing to Kolla, like say we
>replaced devstack in our CI setup with it, I'm having a hard time seeing
>everyone jumping in on this.

Matt,

The compute kit projects are well covered by the current core reviewer
team.  Hence, we don't really need any help with Nova.  This is more aimed
at the herd of new server projects in Liberty and Mitaka that want
deployment options which currently lack them.  There is no way to deploy
aodh in an automated fashion (for example) (picked because it was first in
the project list by alphabetical order;)

For example this cycle community folks implemented mistral and manila,
which were not really top in our priority list.  Yet, the work got done
and now the core team will look after these projects as well.

As for why puppet/ansible/chef couldn't make the same requests, the answer
is they could.  Why haven't they?  I can never speak to the motives or
actions of others, but perhaps they didn't think to try?

The incentive to contribute to Kolla is to have your project deployed from
source or from binary in containers with full organized upgrade capability
and full customization.  If that isn't enough incentive, your right, I
don't see people jumping on this.

Regards,
-steve

>
>-- 
>
>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


__
OpenStack Development Mailing 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] [election] [tc] TC candidacy

[joehuang]

Hi, Thierry,

One question about this  ' The transition to the "big tent" governance model is 
now finished, with all the expected projects now officially part of the 
OpenStack community. The big tent is all about community: answering the "are 
you one of us" question.'. 

Does it mean that no more project will be approved to be a big tent project in 
the Newton and Ocata release?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Monday, March 28, 2016 11:53 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [election] [tc] TC candidacy

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical Committee. For 
those who don't know me yet, my name is Thierry Carrez, I use "ttx" as my IRC 
nickname. I'm currently employed by the OpenStack Foundation as its Director of 
Engineering, which basically means I'm running the team in charge of ensuring 
the long-term health of the upstream OpenStack open source project and its 
governance. Handling the Technical Committee is my primary activity: 6 months 
ago I left the PTL role for the Release Management Team in order to be able to 
focus as much as possible on the TC.

One year ago I ran for election with the goal of having the TC "step out of the 
way"[1]. The idea was to remove the TC from the critical path of getting things 
done, and encourage a "ask for forgiveness, rather than permission" attitude in 
our community. I like to think we were successful at this. Project teams can 
now more easily add git repositories as they need them, they also end up 
asserting some tags by themselves, and the TC has generally moved to being an 
appeals board in case of disputes, rather than a procedural barrier in getting 
things done.

Here are the three priorities for my upcoming mandate, if the electorate 
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with all the 
expected projects now officially part of the OpenStack community. The big tent 
is all about community: answering the "are you one of us" question. Our 
approach there was to be inclusive and assume good faith, especially as we 
caught up on documenting what we meant by "the OpenStack Way". Over the past 
year we created the Project Team Guide[2], which clearly explains what is 
expected of official project teams. I think it's time for us to look back at 
all those projects we have in the tent, reach out to those who are lacking, and 
not hesitate to remove the ones that are not following our common community 
practices from the list of official project teams. Demoting a project used to 
be particularly painful, with costly git repository renames crating disruption 
on the demoted projects. But now that all projects hosted under our 
infrastructure (official and unofficial) use the same namespace, this cost and 
disr
 uption are very limited, so cleaning up the big tent is now possible.

2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no good 
answer: Poppy and Tacker. Those resulted in close (and somewhat
arbitrary) votes as each TC member tried to interpret the mission statement 
words and what we stand for. In the case of Poppy, there was the question of 
whether a service that proxies to non-OpenStack commercial services could be 
considered part of "OpenStack", without an open source reference implementation 
to do end-to-end testing against. 
In the case of Tacker, there was the question of a service standing on top of 
other OpenStack services to present a domain-specific API tailored to a 
specific use case or industry. Should that still be "OpenStack", or just 
something that consumes OpenStack ? I'd like the TC to take a step back and 
explore those two questions, without the pressure of a specific project team 
addition. Clarifying the rules may result in some official projects to be 
demoted to "unofficial" status as they would not fit the rules anymore.

3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit" 
into wider community feedback / requirements-gathering sessions (that would 
happen at the main Summit) and a specific event for project team members to 
gather in a co-located venue to come up with a plan and organize its execution. 
We still have a long way to go (and not that much time) to discuss the format 
and the timing of this new event, and I expect the Newton membership of the TC 
to help with taking quick decisions there. The next step here will be a 
cross-project workshop at the Design Summit in Austin to discuss the current 
plan and go deeper in the details.

Those are my three priorities for Newton and Ocata, and this is what I'll push 
the Technical Committee towards if I'm e

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Yipei Niu]

Hi, all,

I checked nova.conf and local.conf both.

In nova.conf, the option "nova_api_class" is missing while "use_neutron" is
set as True. I modify the lib/nova so that the devstack can write
"nova_api_class=nova.network.api.API" to nova.conf [1]. However, after
installing devstack with tricircle, the same error still happens as before.

In local.conf, n-net is disabled, which is the same as the sample file of
tricircle.

[1] http://docs.openstack.org/developer/nova/sample_config.html

Best regards,
Yipei

On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo  wrote:

> FYI:
> This is the reason is that there is still n-net. [1]
>
> [1]
> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>
> Cheers,
> S
>
> On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
> > Hi,
> >
> >
> >
> > Agree, it’s quite important not to use Nova-network in devstack. In
> devstack
> > local.conf, make sure the Neutron service is enabled and Nova-network is
> > disabled.
> >
> >
> >
> > # Use Neutron instead of nova-network
> >
> > disable_service n-net
> >
> > enable_service q-svc
> >
> > enable_service q-svc1
> >
> > enable_service q-dhcp
> >
> > enable_service q-agt
> >
> >
> >
> > And also check the configuration in Nova to use Neutron
> >
> >
> >
> > Best Regards
> >
> > Chaoyi Huang ( Joe Huang )
> >
> >
> >
> > From: Vega Cai [mailto:luckyveg...@gmail.com]
> > Sent: Monday, March 28, 2016 2:55 PM
> > To: Yipei Niu
> > Cc: OpenStack Development Mailing List (not for usage questions);
> joehuang
> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
> > configuration
> >
> >
> >
> > Hi Yipei,
> >
> >
> >
> > Check "network_api_class" and "use_neutron" options in your nova.conf. It
> > seems that your nova API is not configured to use neutron.
> >
> >
> >
> > BR
> >
> > Zhiyuan
> >
> >
> >
> > On 28 March 2016 at 13:25, Yipei Niu  wrote:
> >
> > Hi, all,
> >
> >
> >
> > After I execute the command "nova boot --flavor 1 --image
> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1",
> > there exist some problem with the argument port. In t-ngw.log, I find
> that
> > the status of port switches from ACTIVE to DOWN, which is marked as bold
> > below. Is it the reason why I failed to boot a VM?
> >
> >
> >
> > 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> > http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
> > python-neutronclient" -H "X-Auth-Token:
> 7cfcfb91173a4920adaf24db7eebd773" -d
> > '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
> > "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> >
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> >
> > 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> > admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> > 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> > 'application/json; charset=UTF-8', 'Content-Length': '384',
> > 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
> > {"port": {"status": "ACTIVE", "name": "", "admin_state_up": true,
> > "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
> > "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
> > "fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
> > "2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id":
> > "e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
> > ^[[00;33mfrom (pid=17537) http_log_resp
> >
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
> >
> > 2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> > admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> > http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
> > python-neutronclient" -H "X-Auth-Token:
> 7cfcfb91173a4920adaf24db7eebd773" -d
> > '{"port": {"name": "e27dc15d-188f-4d60-a38c-f48052d6330b",
> "admin_state_up":
> > true, "network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id":
> > "29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09",
> > "fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480",
> > "ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537)
> http_log_req
> >
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> >
> > 2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client
> > [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> > admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> > 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> > 'application/json; charset=UTF-8', 'Co

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Carl Baldwin]

On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric
 wrote:
> Sorry for the slow reply.

And, sorry for mine.  I was distracted with dotting I's and crossing
T's on some other things.  I'm now back to playing around with this.

> I think that both of these can be solved with the existing interface, by 
> expanding the different types of "request" objects. Right now, we have very 
> basic and limited requests: SpecificSubnet, AnySubnet. There is no reason we 
> can't create a subnet request that includes tag (or host or segment) 
> information that can be used by the existing IPAM driver methods. If the tag 
> is an optional refinement, then the request type can subclass the existing 
> AnySubnet request; otherwise, the request would need to be rejected by the 
> driver.

I would argue that expand the requests is changing the interface.  At
least, that is the way I see it.

> Each driver can deliver its own factory for converting create_subnet (etc.) 
> API requests into IPAM request objects. Thus, each driver can decide whether 
> it supports some incoming request type or not. This same mechanism that 
> applies to subnet also applies to IPs.

I'll play around with this.

> One thing we may want to consider, though, is discoverability of these 
> capabilities. We have this now for extensions in general, of course. But in 
> this case, we would want to be able to discover whether or not the IPAM 
> driver supports this functionality, before enabling the use of the routed 
> segments feature. As far as I know, we don't today provide a way to discover 
> whether a particular feature works with a particular plugin or other 
> extension. That is, I don't think we allow extensions to specify that they 
> are dependent on other specific extensions, do we?

We do need to figure this out.  If IPAM doesn't support the feature
then we probably shouldn't allow associating subnets to segments.
That would effectively disable the feature.

Carl

__
OpenStack Development Mailing 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] Segments, subnet types, and IPAM

[Carl Baldwin]

On Fri, Mar 11, 2016 at 10:04 PM, Salvatore Orlando
 wrote:
> On 11 March 2016 at 23:15, Carl Baldwin  wrote:
> I wonder if we could satisfy this requirement with tags - as it seems these
> subnets are anyway operator-owned you should probably not worry about
> regular tenants fiddling with them, and therefore the "helper" subnet needed
> for the fip namespace could just be tagged to the purpose.

We discussed tags at the mid-cycle.  We decided against using them.
One reason is that tags are pretty new and are a moving target.
Another reason I was hesitant is that tags were designed to be user
facing.  As I recall, we didn't want the tags to affect code behavior.
But, maybe I misunderstood that.  We want service types to affect
IPAM, at least.

Brian Haley is going to put up a spec for this service type attribute
work.  Brian, would you mind posting a link to your spec review when
you've posted it?

Carl

__
OpenStack Development Mailing 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] [release][puppet] Puppet OpenStack 8.0.0 release (mitaka)

[Emilien Macchi]

Puppet OpenStack team has the immense pleasure to announce the release
of 24 Puppet modules.

Some highlights and major features:

Keystone:
* Federation with Mellon support
* Support for multiple LDAP backends
* Usage of keystone-manage bootstrap

Neutron:
* Support of LBaaSv2
* More SDN integrations: OpenDayLight, PlugGrid, Midonet
* Use modern parameters for Nova notifications

Nova:
* Manage Nova API database
* Nova cells support with host aggregates
* Remove EC2 support
* Provider to manage security groups and rules

Glance:
* Multi-backend support
* Glare API support

Cinder:
* Block Device backend support
* Allow to deploy Cinder API v3

General features:
* IPv6 deployment support
* CI continues to have more use-cases coverage

New stable modules:
* puppet-mistral
* puppet-zaqar


Detailed Release notes:

http://docs.openstack.org/releasenotes/puppet-aodh
http://docs.openstack.org/releasenotes/puppet-ceilometer
http://docs.openstack.org/releasenotes/puppet-cinder
http://docs.openstack.org/releasenotes/puppet-designate
http://docs.openstack.org/releasenotes/puppet-glance
http://docs.openstack.org/releasenotes/puppet-gnocchi
http://docs.openstack.org/releasenotes/puppet-heat
http://docs.openstack.org/releasenotes/puppet-horizon
http://docs.openstack.org/releasenotes/puppet-ironic
http://docs.openstack.org/releasenotes/puppet-keystone
http://docs.openstack.org/releasenotes/puppet-manila
http://docs.openstack.org/releasenotes/puppet-mistral
http://docs.openstack.org/releasenotes/puppet-murano
http://docs.openstack.org/releasenotes/puppet-neutron
http://docs.openstack.org/releasenotes/puppet-nova
http://docs.openstack.org/releasenotes/puppet-openstack_extras
http://docs.openstack.org/releasenotes/puppet-openstacklib
http://docs.openstack.org/releasenotes/puppet-openstack_spec_helper
http://docs.openstack.org/releasenotes/puppet-sahara
http://docs.openstack.org/releasenotes/puppet-swift
http://docs.openstack.org/releasenotes/puppet-tempest
http://docs.openstack.org/releasenotes/puppet-trove
http://docs.openstack.org/releasenotes/puppet-vswitch
http://docs.openstack.org/releasenotes/puppet-zaqar


Big kudos to the team and also our friends from OpenStack Infra, RDO,
UCA, and Tempest!
-- 
Emilien Macchi on behalf of Puppet OpenStack team

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

[openstack-dev] [docs] [api] Oh Swagger, where art thou?

[Anne Gentle]

Hi all,

This release I’ve been communicating about moving from WADL to Swagger for
the API reference information on developer.openstack.org. What we've
discovered on the journey is that Swagger doesn't match well for our
current API designs (details below), and while we're not completely giving
up on Swagger, we're also recognizing the engineering effort to maintain
and sustain those efforts isn't going to magically appear.

Sean Dague has put together a proof-of-concept with Compute servers
reference documentation to use Sphinx, RST, parameters files, and some
Sphinx extensions to do a near-copy representation of the API reference
page. We've met with the Nova API team, the API working group, and other
interested developers to make sure our ideas are sound, and so far we have
consensus on forging a new path forward. The review patch is here:
https://review.openstack.org/#/c/292420.

I believe we can still find uses for the Swagger migration for some
projects that match the specification really well. We'll keep outputting
the draft Swagger files to http://developer.openstack.org/draft/swagger/
and continue to look for the use case for Swagger. Perhaps it's a
try-it-out connection to TryStack. Maybe some projects will want to build
clients from those files. We know it's useful, but need to focus efforts
for now.

We know that some OpenStack APIs cannot fit Swagger’s model. For example,
Compute, File Storage, Bare Metal, and Block Storage (nova, manila, ironic,
and cinder projects) have microversions enabled for updates to the request
body as we continue to evolve the API definition, and Swagger has no
mechanism to display the changes between microversions for end-users. As
another example, Compute, Block Storage, File Storage, Databases, and
Networks APIs (nova, cinder, manila, trove, and neutron projects) have an
/actions resource that allows multiple differing request bodies.

I'm writing this email to let you all know there's a new plan coming. We
are using pieces of work from the past efforts to get the best outcome for
sustainable, useful API documentation. The API Reference and WADL files
will remain in the api-site repo until we have a new publishing job that we
can use to flip the switch.

We'll be writing a new specification as well as presenting at an upstream
contributor's talk about Swagger as a standard:
https://www.openstack.org/summit/austin-2016/summit-schedule/events/7723
Once we get the publishing pipeline established, look for review proposals
to your project repos to store API docs there rather than in api-site.

We're going to reboot the migration and get off of WADL. Three cheers for
that. If you’d like to work on these efforts, please stay tuned to the
usual mailing list channels and if you are a docs or API working group
liaison, please stay up-to-date with the plans. Review the upcoming
specification, look for API docs patches in your repo, review those, and
keep the efforts moving.

I'll also attend this week's cross-project meeting to be available for any
questions during open discussion.

Thanks,
Anne, who is going to find her copy of the Oh Brother, Where Art Thou
soundtrack now

--
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cross-project] Meeting, Tue March 29 21:00 UTC

[Mike Perez]

Hi everyone!

We will be having a meeting tomorrow Tuesday March 29 21:00 utc in
#openstack-meeting-cp [1].

Cross-project spec liaisons [2] should be ready to discuss these specs that
were mentioned last week on the mailing list:

* Team announcements (horizontal, vertical, diagonal)
* Add centralized configuration options specification
  - https://review.openstack.org/#/c/295543/
* Delimiter - Cross Project Quota Enforcement and Management
  - https://review.openstack.org/#/c/284454/
* Clarify Specifications (thingee)
  - https://review.openstack.org/#/c/295940/
* Open discussion

See you all then!

[1] - 
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
[2] - 
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Cross-Project_Spec_Liaisons

-- 
Mike Perez

__
OpenStack Development Mailing 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] [Fuel] [FFE] Unlock Settings Tab

[Vladimir Kozhukalov]

​Guys, you are awesome. Thank you all very much.​

Vladimir Kozhukalov

On Mon, Mar 28, 2016 at 11:50 PM, Alexey Shtokolov 
wrote:

> Fuelers!
>
> I'm glad to announce that all patches [0] were merged!
>
> Many thanks to all of you who help us to make Fuel more flexible and
> unlimited.
>
> Special thanks to our code and design reviewers: Igor Kalnitsky, Sergii
> Golovatiuk, Vitaly Kramskikh.
>
> And especially to the Team: Bulat Gaifullin, Ilya Kutukov, Vladimir
> Sharshov, Julia Aranovich, Stanislaw Bogatkin, Evgeniy L and Vladimir Kuklin
> My sincerest thanks and appreciation for your great efforts, sleepless
> nights and sense of purpose!
>
> WBR, Alexey Shtokolov
>
> [0] - https://goo.gl/kSwej5
>
> 2016-03-25 21:48 GMT+03:00 Vladimir Kozhukalov :
>
>> Granted. New deadline is 21:00 UTC 03/28/2016.
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov <
>> ashtoko...@mirantis.com> wrote:
>>
>>> Fuelers!
>>>
>>>
>>> We are very close to landing our feature "Unlock Settings Tab". But we
>>> still have a set of reviews [0] to be merged due to several reasons (incl.
>>> the migration to python27-db gates on OpenStack Infra). I would like to
>>> request extra time till Monday to land them.
>>>
>>>
>>> [0] - https://goo.gl/kSwej5
>>>
>>> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko :
>>>
 Thanks for working this out! Confirming that task history remains
 included in the scope of this FFE until the merge deadline, March 24.

 On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
 > Hey Dmitry,
 >
 > I confirm that we agreed on feature design, and you can proceed with
 > granting exception.
 >
 > ,- Igor
 >
 > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
 >  wrote:
 > > Hi Dmitry,
 > >
 > > We've reached the design consensus with Igor today. Could you
 please remove
 > > the conditional status of the FFE request?
 > > As agreed: the merge deadline is March 24.
 > >
 > > --
 > > WBR, Alexey Shtokolov
 > >
 > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <
 dborodae...@mirantis.com>:
 > >>
 > >> Granted. Design consensus deadline for the task history part of
 this
 > >> feature is extended to March 11. This does not change the merge
 deadline
 > >> for other parts of this feature, which is still March 24.
 > >>
 > >> --
 > >> Dmitry Borodaenko
 > >>
 > >>
 > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
 > >> > Dmitry,
 > >> >
 > >> > We are really close to have the consensus, but we need one more
 meeting
 > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
 > >> > decision.
 > >> > All patches [0] are on review. The meeting is scheduled for
 tomorrow
 > >> > (03/11
 > >> > 1:30pm CET).
 > >> > Could you please grant us one more day for it?
 > >> >
 > >> > [0] -
 > >> >
 https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
 > >> >
 > >> > --
 > >> > WBR, Alexey Shtokolov
 > >> >
 > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
 dborodae...@mirantis.com>:
 > >> >
 > >> > > Granted, merge deadline March 24, task history part of the
 feature is
 > >> > > to
 > >> > > be excluded from this exception grant unless a consensus is
 reached by
 > >> > > March 10.
 > >> > >
 > >> > > Relevant part of the meeting log starts at:
 > >> > >
 > >> > >
 > >> > >
 http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
 > >> > >
 > >> > > --
 > >> > > Dmitry Borodaenko
 > >> > >
 > >> > >
 > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh
 wrote:
 > >> > > > Oh, so there is a spec. I was worried that this patch has
 > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message,
 so I
 > >> > > > thought
 > >> > > > there is no spec for it. So the commit message should be
 updated to
 > >> > > > avoid
 > >> > > > such confusion.
 > >> > > >
 > >> > > > It's really good I've seen this spec. There are plans to
 overhaul UI
 > >> > > > data
 > >> > > > format description which we use for cluster and node
 settings to
 > >> > > > solve
 > >> > > some
 > >> > > > issues and implement long-awaited features like nested
 structures,
 > >> > > > so we
 > >> > > > might also want to deprecate our expression language and
 also switch
 > >> > > > to
 > >> > > > YAQL (and thus port YAQL to JS).
 > >> > > >
 > >> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <
 vkuk...@mirantis.com>:
 > >> > > >
 > >> > > > > Vitaly
 > >> > > > >
 > >> > > > > Thanks for bringing this up. Actually the spec has been on
 review
 > >> > > > > for
 > >> > > > >

[openstack-dev] [tacker] Agenda for weekly meeting - Mar 29, 2016

[Sridhar Ramaswamy]

Here is the agenda for tomorrow's tacker meeting.

https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Mar_29.2C_2016

1700 UTC Tuesday / #openstack-meeting-4

   - Announcements
   - Mitaka Release Review
   - Mitaka bugs / blockers
   - Mitaka Docs -
   http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
   - Newton Summit Planning
   - Open Discussion
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum] Agenda for tomorrow team meeting

[Hongbin Lu]

Hi team,

Please review the agenda for our team meeting tomorrow: 
https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-03-29_1600_UTC
 . Please feel free to add items to the agenda if you like.

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

[openstack-dev] (no subject)

[Alexey Shtokolov]

Fuelers!

I'm glad to announce that all patches [0] were merged!

Many thanks to all of you who help us to make Fuel more flexible and
unlimited.

Special thanks to our code and design reviewers: Igor Kalnitsky, Sergii
Golovatiuk, Vitaly Kramskikh.

And especially to the Team: Bulat Gaifullin, Ilya Kutukov, Vladimir
Sharshov, Julia Aranovich, Stanislaw Bogatkin, Evgeniy L and Vladimir Kuklin
My sincerest thanks and appreciation for your great efforts, sleepless
nights and sense of purpose!

WBR, Alexey Shtokolov

[0] - https://goo.gl/kSwej5

2016-03-25 21:48 GMT+03:00 Vladimir Kozhukalov :

> Granted. New deadline is 21:00 UTC 03/28/2016.
>
> Vladimir Kozhukalov
>
> On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov  > wrote:
>
>> Fuelers!
>>
>>
>> We are very close to landing our feature "Unlock Settings Tab". But we
>> still have a set of reviews [0] to be merged due to several reasons (incl.
>> the migration to python27-db gates on OpenStack Infra). I would like to
>> request extra time till Monday to land them.
>>
>>
>> [0] - https://goo.gl/kSwej5
>>
>> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko :
>>
>>> Thanks for working this out! Confirming that task history remains
>>> included in the scope of this FFE until the merge deadline, March 24.
>>>
>>> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
>>> > Hey Dmitry,
>>> >
>>> > I confirm that we agreed on feature design, and you can proceed with
>>> > granting exception.
>>> >
>>> > ,- Igor
>>> >
>>> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
>>> >  wrote:
>>> > > Hi Dmitry,
>>> > >
>>> > > We've reached the design consensus with Igor today. Could you please
>>> remove
>>> > > the conditional status of the FFE request?
>>> > > As agreed: the merge deadline is March 24.
>>> > >
>>> > > --
>>> > > WBR, Alexey Shtokolov
>>> > >
>>> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <
>>> dborodae...@mirantis.com>:
>>> > >>
>>> > >> Granted. Design consensus deadline for the task history part of this
>>> > >> feature is extended to March 11. This does not change the merge
>>> deadline
>>> > >> for other parts of this feature, which is still March 24.
>>> > >>
>>> > >> --
>>> > >> Dmitry Borodaenko
>>> > >>
>>> > >>
>>> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>>> > >> > Dmitry,
>>> > >> >
>>> > >> > We are really close to have the consensus, but we need one more
>>> meeting
>>> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>>> > >> > decision.
>>> > >> > All patches [0] are on review. The meeting is scheduled for
>>> tomorrow
>>> > >> > (03/11
>>> > >> > 1:30pm CET).
>>> > >> > Could you please grant us one more day for it?
>>> > >> >
>>> > >> > [0] -
>>> > >> >
>>> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>>> > >> >
>>> > >> > --
>>> > >> > WBR, Alexey Shtokolov
>>> > >> >
>>> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
>>> dborodae...@mirantis.com>:
>>> > >> >
>>> > >> > > Granted, merge deadline March 24, task history part of the
>>> feature is
>>> > >> > > to
>>> > >> > > be excluded from this exception grant unless a consensus is
>>> reached by
>>> > >> > > March 10.
>>> > >> > >
>>> > >> > > Relevant part of the meeting log starts at:
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>>> > >> > >
>>> > >> > > --
>>> > >> > > Dmitry Borodaenko
>>> > >> > >
>>> > >> > >
>>> > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh
>>> wrote:
>>> > >> > > > Oh, so there is a spec. I was worried that this patch has
>>> > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so
>>> I
>>> > >> > > > thought
>>> > >> > > > there is no spec for it. So the commit message should be
>>> updated to
>>> > >> > > > avoid
>>> > >> > > > such confusion.
>>> > >> > > >
>>> > >> > > > It's really good I've seen this spec. There are plans to
>>> overhaul UI
>>> > >> > > > data
>>> > >> > > > format description which we use for cluster and node settings
>>> to
>>> > >> > > > solve
>>> > >> > > some
>>> > >> > > > issues and implement long-awaited features like nested
>>> structures,
>>> > >> > > > so we
>>> > >> > > > might also want to deprecate our expression language and also
>>> switch
>>> > >> > > > to
>>> > >> > > > YAQL (and thus port YAQL to JS).
>>> > >> > > >
>>> > >> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <
>>> vkuk...@mirantis.com>:
>>> > >> > > >
>>> > >> > > > > Vitaly
>>> > >> > > > >
>>> > >> > > > > Thanks for bringing this up. Actually the spec has been on
>>> review
>>> > >> > > > > for
>>> > >> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
>>> > >> > > > > Essentially,
>>> > >> > > > > this is not introducing new DSL but replacing the existing
>>> one
>>> > >> > > > > with
>>> > >> > > more
>>> > >> > > > > powerful extendable language which is being actively
>>> developed
>>> > >> > > > > within
>>> > 

[openstack-dev] [Fuel] [FFE] Unlock Settings Tab

[Alexey Shtokolov]

Fuelers!

I'm glad to announce that all patches [0] were merged!

Many thanks to all of you who help us to make Fuel more flexible and
unlimited.

Special thanks to our code and design reviewers: Igor Kalnitsky, Sergii
Golovatiuk, Vitaly Kramskikh.

And especially to the Team: Bulat Gaifullin, Ilya Kutukov, Vladimir
Sharshov, Julia Aranovich, Stanislaw Bogatkin, Evgeniy L and Vladimir Kuklin
My sincerest thanks and appreciation for your great efforts, sleepless
nights and sense of purpose!

WBR, Alexey Shtokolov

[0] - https://goo.gl/kSwej5

2016-03-25 21:48 GMT+03:00 Vladimir Kozhukalov :

> Granted. New deadline is 21:00 UTC 03/28/2016.
>
> Vladimir Kozhukalov
>
> On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov  > wrote:
>
>> Fuelers!
>>
>>
>> We are very close to landing our feature "Unlock Settings Tab". But we
>> still have a set of reviews [0] to be merged due to several reasons (incl.
>> the migration to python27-db gates on OpenStack Infra). I would like to
>> request extra time till Monday to land them.
>>
>>
>> [0] - https://goo.gl/kSwej5
>>
>> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko :
>>
>>> Thanks for working this out! Confirming that task history remains
>>> included in the scope of this FFE until the merge deadline, March 24.
>>>
>>> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
>>> > Hey Dmitry,
>>> >
>>> > I confirm that we agreed on feature design, and you can proceed with
>>> > granting exception.
>>> >
>>> > ,- Igor
>>> >
>>> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
>>> >  wrote:
>>> > > Hi Dmitry,
>>> > >
>>> > > We've reached the design consensus with Igor today. Could you please
>>> remove
>>> > > the conditional status of the FFE request?
>>> > > As agreed: the merge deadline is March 24.
>>> > >
>>> > > --
>>> > > WBR, Alexey Shtokolov
>>> > >
>>> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <
>>> dborodae...@mirantis.com>:
>>> > >>
>>> > >> Granted. Design consensus deadline for the task history part of this
>>> > >> feature is extended to March 11. This does not change the merge
>>> deadline
>>> > >> for other parts of this feature, which is still March 24.
>>> > >>
>>> > >> --
>>> > >> Dmitry Borodaenko
>>> > >>
>>> > >>
>>> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>>> > >> > Dmitry,
>>> > >> >
>>> > >> > We are really close to have the consensus, but we need one more
>>> meeting
>>> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>>> > >> > decision.
>>> > >> > All patches [0] are on review. The meeting is scheduled for
>>> tomorrow
>>> > >> > (03/11
>>> > >> > 1:30pm CET).
>>> > >> > Could you please grant us one more day for it?
>>> > >> >
>>> > >> > [0] -
>>> > >> >
>>> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>>> > >> >
>>> > >> > --
>>> > >> > WBR, Alexey Shtokolov
>>> > >> >
>>> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
>>> dborodae...@mirantis.com>:
>>> > >> >
>>> > >> > > Granted, merge deadline March 24, task history part of the
>>> feature is
>>> > >> > > to
>>> > >> > > be excluded from this exception grant unless a consensus is
>>> reached by
>>> > >> > > March 10.
>>> > >> > >
>>> > >> > > Relevant part of the meeting log starts at:
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>>> > >> > >
>>> > >> > > --
>>> > >> > > Dmitry Borodaenko
>>> > >> > >
>>> > >> > >
>>> > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh
>>> wrote:
>>> > >> > > > Oh, so there is a spec. I was worried that this patch has
>>> > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so
>>> I
>>> > >> > > > thought
>>> > >> > > > there is no spec for it. So the commit message should be
>>> updated to
>>> > >> > > > avoid
>>> > >> > > > such confusion.
>>> > >> > > >
>>> > >> > > > It's really good I've seen this spec. There are plans to
>>> overhaul UI
>>> > >> > > > data
>>> > >> > > > format description which we use for cluster and node settings
>>> to
>>> > >> > > > solve
>>> > >> > > some
>>> > >> > > > issues and implement long-awaited features like nested
>>> structures,
>>> > >> > > > so we
>>> > >> > > > might also want to deprecate our expression language and also
>>> switch
>>> > >> > > > to
>>> > >> > > > YAQL (and thus port YAQL to JS).
>>> > >> > > >
>>> > >> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <
>>> vkuk...@mirantis.com>:
>>> > >> > > >
>>> > >> > > > > Vitaly
>>> > >> > > > >
>>> > >> > > > > Thanks for bringing this up. Actually the spec has been on
>>> review
>>> > >> > > > > for
>>> > >> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
>>> > >> > > > > Essentially,
>>> > >> > > > > this is not introducing new DSL but replacing the existing
>>> one
>>> > >> > > > > with
>>> > >> > > more
>>> > >> > > > > powerful extendable language which is being actively
>>> developed
>>> > >> > > > > within
>>> > 

[openstack-dev] [Infra] Meeting Tuesday March 29th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday March 29th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] [release][stable][winstackers] os-win 0.4.0 release (mitaka)

[no-reply]

We are chuffed to announce the release of:

os-win 0.4.0: Windows / Hyper-V library for OpenStack projects.

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-win

Please report issues through launchpad:

http://bugs.launchpad.net/os-win

For more details, please see below.

Changes in os-win 0.3.2..0.4.0
--

9af724a Sets OsWinBaseTestCase as base class for unit tests
3c6f08e Updates the default branch in .gitreview
edc939e Fixes PyMI compatiblity issue
5f7b473 Fixes vmutils take_vm_snapshot method
e61318b Adds check for VLAN and VSID operations
25aa5eb Fix named pipe handler cleanup regression
dc3456b Fixes vmutils get_vm_generation method
c88f49f Improve clusterutils with new pyMI features
74dabea Ensure namedpipe IO workers clean up handles when stopping
21a882c switch to post-versioning
25255d1 Bump version to 0.3.3

Diffstat (except docs and test files)
-

.gitreview |   1 +
.../storage/initiator/test_base_iscsi_utils.py |   4 +-
.../storage/initiator/test_iscsi_wmi_utils.py  |   4 +-
os_win/utils/baseutils.py  |  41 +++-
os_win/utils/compute/clusterutils.py   |  90 ++
os_win/utils/compute/livemigrationutils.py |  29 +++---
os_win/utils/compute/vmutils.py|  71 +++---
os_win/utils/io/ioutils.py |  17 +++-
os_win/utils/io/namedpipe.py   |  39 ++--
os_win/utils/metrics/metricsutils.py   |   2 +-
os_win/utils/network/networkutils.py   |  31 --
os_win/utilsfactory.py |  10 --
setup.cfg  |   1 -
26 files changed, 409 insertions(+), 274 deletions(-)




__
OpenStack Development Mailing 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] FW: [neutron] [Bug 1563028] Re: Routes version 2.3 broke the way we register routes

[Amrith Kumar]

While grep'ing the source tree, I found that Neutron does something similar to 
Trove and may suffer the same fate when upper-constraints.txt allows Routes 2.3 
...

amrith@amrith-work:/opt/stack/neutron$ grep -n -r submap.connect .
./neutron/api/extensions.py:286:submap.connect(path)
./neutron/api/extensions.py:287:
submap.connect("%s.:(format)" % path)
./neutron/api/extensions.py:296:submap.connect(path)
./neutron/api/extensions.py:297:
submap.connect("%s.:(format)" % path)

Heads up!

-amrith

> -Original Message-
> From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of
> OpenStack Infra
> Sent: Monday, March 28, 2016 4:12 PM
> To: Amrith Kumar 
> Subject: [Bug 1563028] Re: Routes version 2.3 broke the way we register
> routes
> 
> Fix proposed to branch: master
> Review: https://review.openstack.org/298419
> 
> ** Changed in: trove
>Status: New => In Progress
> 
> --
> You received this bug notification because you are subscribed to the bug
> report.
> Matching subscriptions: trove-bugs
> https://bugs.launchpad.net/bugs/1563028
> 
> Title:
>   Routes version 2.3 broke the way we register routes
> 
> Status in Trove:
>   In Progress
> 
> Bug description:
>   Routes v2.3 which just came out included this change
> 
> 
> https://github.com/bbangert/routes/commit/0a417004be7e2d950bdcd629ccf24cf9
> f56ef817
> 
>   which changed submap.connect() in a way that broke the way Trove
>   registers routes.
> 
>   We now need to provide a routename and a path as independent
>   arguments.
> 
>   I tried to make sense of the documentation at
>   http://routes.readthedocs.org/en/v2.3/setting_up.html#submappers and
>   got nowhere in a hurry, but reading the code for connect() provided a
>   possible solution.
> 
>   This will likely need to go to stable/mitaka as well.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/trove/+bug/1563028/+subscriptions
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] weekly meeting #76

[Emilien Macchi]

Hi,

We'll have our weekly meeting tomorrow at 3pm UTC on
#openstack-meeting4.

https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack

As usual, free free to bring topics in this etherpad:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160329

We'll also have open discussion for bugs & reviews, so anyone is welcome
to join.
-- 
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] [release][stable][oslo] oslo.messaging 4.6.1 release (mitaka)

[no-reply]

We are tickled pink to announce the release of:

oslo.messaging 4.6.1: Oslo Messaging API

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 4.6.0..4.6.1
--

ceda1f6 Fix Break in Windows platforms

Diffstat (except docs and test files)
-

oslo_messaging/_drivers/impl_rabbit.py | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)




__
OpenStack Development Mailing 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-stable-maint] Stable check of openstack/trove failed

[Amrith Kumar]

Fungi, we're seeing other issues relative to this job, so more to come.

-amrith

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Monday, March 28, 2016 2:05 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Openstack-stable-maint] Stable check of
> openstack/trove failed
> 
> On 2016-03-28 11:52:12 + (+), Amrith Kumar wrote:
> > I ran this manually on stable/mitaka and it succeeded. The errors
> > being reported are "database is locked". Is this something in the
> > infrastructure or do you want me to investigate further?
> 
> It would probably be good to determine whether stable/mitaka changes are
> meeting the same fate in the gate-trove-python27-db job (for example, this
> could be a concurrency/ordering related race which may not always surface
> on everyone's systems).
> --
> Jeremy Stanley
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Dan Prince]

On Wed, 2016-03-23 at 07:54 -0400, Ryan Hallisey wrote:
> *Snip*
> 
> > 
> > Indeed, this has literally none of the benefits of the ideal Heat 
> > deployment enumerated above save one: it may be entirely the wrong
> > tool 
> > in every way for the job it's being asked to do, but at least it
> > is 
> > still well-integrated with the rest of the infrastructure.
> > 
> > Now, at the Mitaka summit we discussed the idea of a 'split
> > stack', 
> > where we have one stack for the infrastructure and a separate one
> > for 
> > the software deployments, so that there is no longer any tight 
> > integration between infrastructure and software. Although it makes
> > me a 
> > bit sad in some ways, I can certainly appreciate the merits of the
> > idea 
> > as well. However, from the argument above we can deduce that if
> > this is 
> > the *only* thing we do then we will end up in the very worst of
> > all 
> > possible worlds: the wrong tool for the job, poorly integrated.
> > Every 
> > single advantage of using Heat to deploy software will have
> > evaporated, 
> > leaving only disadvantages.
> I think Heat is a very powerful tool having done the container
> integration
> into the tripleo-heat-templates I can see its appeal.  Something I
> learned
> from integration, was that Heat is not the best tool for container
> deployment,
> at least right now.  We were able to leverage the work in Kolla, but
> what it
> came down to was that we're not using containers or Kolla to its max
> potential.
> 
> I did an evaluation recently of tripleo and kolla to see what we
> would gain
> if the two were to combine. Let's look at some items on tripleo's
> roadmap.
> Split stack, as mentioned above, would be gained if tripleo were to
> adopt
> Kolla.  Tripleo holds the undercloud and ironic.  Kolla separates
> config
> and deployment.  Therefore, allowing for the decoupling for each
> piece of
> the stack.  Composable roles, this would be the ability to land
> services
> onto separate hosts on demand.  Kolla also already does this [1].
> Finally,
> container integration, this is just a given :).
> 
> In the near term, if tripleo were to adopt Kolla as its overcloud it
> would
> be provided these features and retire heat to setting up the
> baremetal nodes
> and providing those ips to ansible.  This would be great for kolla
> too because
> it would provide baremetal provisioning.
> 
> Ian Main and I are currently working on a POC for this as of last
> week [2].
> It's just a simple heat template :).
> 
> I think further down the road we can evaluate using kubernetes [3].
> For now though,  kolla-anisble is rock solid and is worth using for
> the
> overcloud.

Yeah, well TripleO heat Overclouds are rock solid too. They just aren't
using containers everywhere yet. So lets fix that.

I'm not a fan of replacing the TripleO overcloud configuration with
Kolla. I don't think there is feature parity, the architectures are
different (HA, etc.) and I don't think you could easily pull off an
upgrade from one deployment to the other (going from TripleO Heat
template deployed overcloud to Kolla deployed overcloud).

> 
> Thanks!
> -Ryan
> 
> [1] - https://github.com/openstack/kolla/blob/master/ansible/inventor
> y/multinode
> [2] - https://github.com/rthallisey/kolla-heat-templates
> [3] - https://review.openstack.org/#/c/255450/
> 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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][LBaaS][heat] Removing LBaaS v1 - are weready?

[Zane Bitter]

On 23/03/16 17:44, Fox, Kevin M wrote:

Can someone verify the code in the review is complete enough to do a full 
migration? Any steps missing or not documented?

Is heat going to want to support v1 resources longer then neutron does? Its 
kind of nice to be able to run a newer dashboard/heat against an older 
something else.


More importantly, is there a migration plan for Heat users who have 
existing stacks containing the v1 resources?



Thanks,
Kevin

From: Doug Wiegley [doug...@parksidesoftware.com]
Sent: Wednesday, March 23, 2016 2:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are 
weready?

Migration script has been submitted, v1 is not going anywhere from 
stable/liberty or stable/mitaka, so it’s about to disappear from master.

I’m thinking in this order:

- remove jenkins jobs
- wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
they see this coming before the job breaks)
- remove q-lbaas from devstack, and any references to lbaas v1 in devstack-gate 
or infra defaults.
- remove v1 code from neutron-lbaas

Since newton is now open for commits, this process is going to get started.

Thanks,
doug




On Mar 8, 2016, at 11:36 AM, Eichberger, German  
wrote:

Yes, it’s Database only — though we changed the agent driver in the DB from V1 
to V2 — so if you bring up a V2 with that database it should reschedule all 
your load balancers on the V2 agent driver.

German




On 3/8/16, 3:13 AM, "Samuel Bercovici"  wrote:


So this looks like only a database migration, right?

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com]
Sent: Tuesday, March 08, 2016 12:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok, for what it’s worth we have contributed our migration script: 
https://review.openstack.org/#/c/289595/ — please look at this as a starting 
point and feel free to fix potential problems…

Thanks,
German




On 3/7/16, 11:00 AM, "Samuel Bercovici"  wrote:


As far as I recall, you can specify the VIP in creating the LB so you will end 
up with same IPs.

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com]
Sent: Monday, March 07, 2016 8:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the
database (your steps 1-5) since the 3rd party hardware will just keep
load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health
Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format
file into some scripts which recreate the load balancers with your
provider of choice —

6. Run those scripts

The problem I see is that we will probably end up with different VIPs
so the end user would need to change their IPs…

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici"  wrote:


As for a migration tool.
Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I am 
in favor for the following process:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools,
Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back
over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to
make room to some custom modification for mapping between v1 and v2
models)

What do you think?

-Sam.




-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: Friday, March 04, 2016 2:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok. Thanks for the info.

Kevin

From: Brandon Logan [brandon.lo...@rackspace.com]
Sent: Thursday, March 03, 2016 2:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
v2's pool resource have different attributes.  With the way neutron wsgi works, 
if both v1 and v2 are enabled, it will combine both sets of attributes into the 
same validation schema.

The other problem with v1 and v2 running together was only occurrin

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Dan Prince]

On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote:
> tl;dr Containers represent a massive, and also mandatory,
> opportunity 
> for TripleO. Lets start thinking about ways that we can take maximum 
> advantage to achieve the goals of the project.
> 
> Now that you have the tl;dr I'm going to start from the beginning,
> so 
> settle in and grab yourself a cup of coffee or other poison of your
> choice.
> 
> After working on developing Heat from the very beginning of the
> project 
> in early 2012 and debugging a bunch of TripleO deployments in the
> field, 
> it is my considered opinion that Heat is a poor fit for the
> workloads 
> that TripleO is currently asking of it. To illustrate why, I need to 
> explain what it is that Heat is really designed to do.
> 
> Here's a theoretical example of how I've always imagined Heat
> software 
> deployments would make Heat users' lives better. For simplicity, I'm 
> just going to model two software components, a user-facing service
> that 
> connects to some back-end service:
> 
>    resources:
>  backend_component:
>    type: OS::Heat::SoftwareComponent
>    properties:
>  configs:
>    - tool: script
>  actions:
>    - CREATE
>    - UPDATE
>  config: |
>    PORT=$(get_backend_port || random_port)
>    stop_backend
>    start_backend $DEPLOY_VERSION $PORT $CONFIG
>    addr="$(hostname):$(get_backend_port)"
>    printf '%s' "$addr"
> >${heat_outputs_path}.host_and_port
>    - tool: script
>  actions:
>    - DELETE
>  config: |
> stop_backend
>   inputs:
> - name: DEPLOY_VERSION
> - name: CONFIG
>   outputs:
> - name: host_and_port
> 
>  frontend_component:
>    type: OS::Heat::SoftwareComponent
>    properties:
>  configs:
>    - tool: script
>  actions:
>    - CREATE
>    - UPDATE
>  config: |
>    stop_frontend
>    start_frontend $DEPLOY_VERSION $BACKEND_ADDR $CONFIG
>    - tool: script
>  actions:
>    - DELETE
>  config: |
>    stop_frontend
>  inputs:
>    - name: DEPLOY_VERSION
>    - name: BACKEND_ADDR
>    - name: CONFIG
> 
>  backend:
>    type: OS::Heat::SoftwareDeployment
>    properties:
>  server: {get_resource: backend_server}
>  name: {get_param: backend_version} # Forces upgrade
> replacement
>  actions: [CREATE, UPDATE, DELETE]
>  config: {get_resource: backend_component}
>  input_values:
>    DEPLOY_VERSION: ${get_param: backend_version}
>    CONFIG: ${get_param: backend_config}
> 
>  frontend:
>    type: OS::Heat::SoftwareDeployment
>    properties:
>  server: {get_resource: frontend_server}
>  name: {get_param: frontend_version} # Forces upgrade
> replacement
>  actions: [CREATE, UPDATE, DELETE]
>  config: {get_resource: frontend_component}
>  input_values:
>    DEPLOY_VERSION: ${get_param: frontend_version}
>    BACKEND_ADDR: {get_attr: [backend, host_and_port]}
>    CONFIG: ${get_param: frontend_config}
> 
> 
> This is actually quite a beautiful system, if I may say so:
> 
> - Whenever a version changes, Heat knows to update that component,
> and 
> the components can be updated independently.
> - If the backend in this example restarts on a different port, the 
> frontend is updated to point to the new port.
> - Everything is completely agnostic as to which server it is running
> on. 
> They could be running on the same server or different servers.
> - Everything is integrated with the infrastructure (not only the
> servers 
> you're deploying on and the networks and volumes connected to them,
> but 
> also things like load balancers), so everything is created at the
> right 
> time, in parallel where possible, and any errors are reported all in
> one 
> place.
> - If something requires e.g. a restart after changing another
> component, 
> we can encode that. And if it doesn't, we can encode that too.
> - There's next to no downtime required: if e.g. we upgrade the
> backend, 
> we first deploy a new one listening on a new port, then update the 
> frontend to listen on the new port, then finally shut down the old 
> backend. Again, we can choose when we want this and when we just want
> to 
> update in place and reload.
> - The application doesn't even need to worry about versioning the 
> protocol that its two constituent parts communicate over: as long as
> the 
> backend_version and frontend_version that we pass are always
> compatible, 
> only compatible versions of the two services ever talk to each other.
> - If anything at all fails at any point before, during or 

Re: [openstack-dev] [heat] Issue with validation and preview due to get_attr==None

[Zane Bitter]

On 27/03/16 22:58, Anant Patil wrote:


On 24-Mar-16 20:26, Sergey Kraynev wrote:

Zane, I like you idea. As example we may discuss some steps for it
during summit session (if it need).

Also I have another question, which probably came in your heads a lot

of times:


A few times, but I usually chased it out again quite quickly ;)


Can we somekind improve our existing approach for validation?
we do validation twice - before create and during it.
The one issue, which I also see is:
first validation is a synchronous operation, and It takes a lot of
time, for huge stacks.


If we want to solve this problem then the first thing to do is to 
profile the code and figure out why it's taking so long in the first 
place. The validation code was written without much regard for premature 
optimisation on the assumption that if we ran into problems we would do 
that. It still shouldn't be super CPU-intensive though, so if it is we 
can fix it.


I suspect that will reveal the problem to be too many ReST API calls to 
validate custom constraints. If that's the case then the solution that 
suggests itself is to stop letting individual constraints validate 
themselves and instead having something walk the template and produce a 
list of constraints that can be validated together. So e.g. you'd have 
one "nova list" call to check that the 50 servers we need exist, rather 
than 50+ "nova show" calls to check the same thing.



May be we need to make separate state like
validation for stacks ? and maybe it also allows to solve our current
issue with build-in functions ?


There's definitely some overlap there, but I suspect not so much that 
implementing either one or the other would get us the second one for free.



I too had the same question since long time. I was thinking about two
possible solutions:

(1) Like you said, as of now the stack validation happens before the
response is given to user. This is not feasible for bigger stacks; the
RPC timesout before the stack template is even validated. I think we
should take the request and respond immediately with a stack-id and then
proceed with template validation and stack creation. If the template is
not correct, the stack creation or update fails with template invalid
error. I have been looking for this since long time, but could never work
on it.


Yeah, this is probably a good idea, as long as we can define some 
minimum level of correctness that we require before writing to the 
database. (Specifically, enough that we can always load the stack to 
delete it again :)



(2) Giving freedom to user to skip the validation, if they are sure
about the template, they might want to skip the validation [1].

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


I think that one's pretty problematic in general, but I'm open to some 
more specific formulations of the idea. I commented on the review.


cheers,
Zane.

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

Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Andrey Pavlov]

Thank you Jeremy!

On Mon, Mar 28, 2016 at 9:12 PM, Jeremy Stanley  wrote:
> On 2016-03-28 10:46:27 -0400 (-0400), Davanum Srinivas wrote:
>> y, whoa! Andrey, i just pinged folks on #openstack-infra.
>
> Yes, sorry about that. There's an issue in Gerrit where it can get
> confused and believe repos are corrupt when it fails to read Git
> objects under some circumstances, and that may have befallen the
> ec2-api project. It's the first time we've seen this since the 2.11
> upgrade, as far as I know, and a Gerrit restart was necessary to get
> it to start showing up as usable again. If you happen to spot any
> seemingly related issues, please let the Infra team know.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing 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] [python-openstackclient] I tried it and....

[Boris Pavlovic]

Hi stackers,

Recently I tried openstackclient and it has amazing UX!

Thanks to everybody involved in this!
You are doing great job keep going!


Best regards,
Boris Pavlovic
__
OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Jeremy Stanley]

On 2016-03-28 10:46:27 -0400 (-0400), Davanum Srinivas wrote:
> y, whoa! Andrey, i just pinged folks on #openstack-infra.

Yes, sorry about that. There's an issue in Gerrit where it can get
confused and believe repos are corrupt when it fails to read Git
objects under some circumstances, and that may have befallen the
ec2-api project. It's the first time we've seen this since the 2.11
upgrade, as far as I know, and a Gerrit restart was necessary to get
it to start showing up as usable again. If you happen to spot any
seemingly related issues, please let the Infra team know.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/trove failed

[Jeremy Stanley]

On 2016-03-28 11:52:12 + (+), Amrith Kumar wrote:
> I ran this manually on stable/mitaka and it succeeded. The errors
> being reported are "database is locked". Is this something in the
> infrastructure or do you want me to investigate further?

It would probably be good to determine whether stable/mitaka changes
are meeting the same fate in the gate-trove-python27-db job (for
example, this could be a concurrency/ordering related race which may
not always surface on everyone's systems).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Horizon] How to add plugins from outside horizon tree

[Rob Cresswell (rcresswe)]

http://docs.openstack.org/developer/horizon/tutorials/plugin.html

This should answer most questions about setting up and installing a plugin. 
Hope it helps!

Rob

On 28 Mar 2016, at 18:33, Mohan Kumar 
mailto:nmohankumar1...@gmail.com>> wrote:

Hi Team ,

   Could you please shed light on some steps /configuration/documentation about 
how to add Horizon plugins from outside horizon tree . I can see punch of 
plugins were developed at  " 
http://docs.openstack.org/developer/horizon/plugins.html "  but couldn't able 
to any documentation .

  In my case i need to define Horizon plugin  for  "networking-sfc"  from 
neutron sub-project repo .

Repo path : https://github.com/openstack/networking-sfc

Code Review Link : https://review.openstack.org/#/c/258430/

Thanks.,
Mohankumar.N
__
OpenStack Development Mailing 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] How to add plugins from outside horizon tree

[Mohan Kumar]

Hi Team ,

   Could you please shed light on some steps /configuration/documentation
about how to add Horizon plugins from outside horizon tree . I can see
punch of plugins were developed at  "
http://docs.openstack.org/developer/horizon/plugins.html "  but couldn't
able to any documentation .

  In my case i need to define Horizon plugin  for  "networking-sfc"  from
neutron sub-project repo .

Repo path : https://github.com/openstack/networking-sfc

Code Review Link : https://review.openstack.org/#/c/258430/

Thanks.,
Mohankumar.N
__
OpenStack Development Mailing 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Ronald Bradford]

The only downside I see of these examples are there is no way in the
documentation to determine the release version or cycle.  (i.e. you have to
read the contents in conjunction with the URL).

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 4:20 PM, Jim Rollenhagen 
wrote:

> On Fri, Mar 25, 2016 at 03:20:30PM -0400, Doug Hellmann wrote:
> > Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
> > > On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> > > > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35
> +1000:
> > > > > >> Hi Mike, and sorry I missed you on IRC to discuss this there.
> That said, I think it's great that you took this to the mailing list,
> especially seeing the conversation that has ensued.
> > > > > >>
> > > > > >> More inline ...
> > > > > >>
> > > > > >> On 24/03/16 01:06, Mike Perez wrote:
> > > > > >>> Hey all,
> > > > > >>>
> > > > > >>> I've been talking to a variety of projects about lack of
> install guides. This
> > > > > >>> came from me not having a great experience with trying out
> projects in the big
> > > > > >>> tent.
> > > > > >>>
> > > > > >>> Projects like Manila have proposed install docs [1], but they
> were rejected
> > > > > >>> by the install docs team because it's not in defcore. One of
> Manila's goals of
> > > > > >>> getting these docs accepted is to apply for the operators tag
> > > > > >>> ops:docs:install-guide [2] so that it helps their maturity
> level in the project
> > > > > >>> navigator [3].
> > > > > >>>
> > > > > >>> Adrian Otto expressed to me having the same issue for Magnum.
> I think it's
> > > > > >>> funny that a project that gets keynote time at the OpenStack
> conference can't
> > > > > >>> be in the install docs personally.
> > > > > >>>
> > > > > >>> As seen from the Manila review [1], the install docs team is
> suggesting these
> > > > > >>> to be put in their developer guide.
> > > > > >>
> > > > > >> As Steve pointed out, these now have solid plans to go in. That
> was because both projects opened a conversation with us and we worked with
> them over time to give them the docs they required.
> > > > > >>
> > > > > >>>
> > > > > >>> I don't think this is a great idea. Mainly because they are
> for developers,
> > > > > >>> operators aren't going to be looking in there for install
> information. Also the
> > > > > >>> Developer doc page [4] even states "This page contains
> documentation for Python
> > > > > >>> developers, who work on OpenStack itself".
> > > > > >>
> > > > > >> I agree, but it's a great place to start. In fact, I've just
> merged a change to the Docs Contributor Guide (on the back of a previous
> mailing list conversation) that explicitly states this:
> > > > > >>
> > > > > >>
> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > > >
> > > > > > I think you're missing that most of us are disagreeing that it is
> > > > > > a good place to start. It's fine to have the docs in a repository
> > > > > > managed by the project team. It's not good at all to publish them
> > > > > > under docs.o.o/developer because they are not for developers, and
> > > > > > so it's confusing. This is why we ended up with a different place
> > > > > > for release notes to be published, instead of just adding reno to
> > > > > > the existing developer documentation build, for example.
> > > > > >
> > > > >
> > > > > All docs need to be drafted somewhere. I don't care where that is,
> but make the suggestion of /developer because at least it's accessible
> there, and also because it's managed in the project's own repo. If you want
> to create a different place, or rename /developer to be more inclusive, I
> think that's a great idea.
> > > >
> > > > I think we'll want to add a new location, or publish to a similar
> > > > location to the existing install guide. I found, for example
> > > > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> > > >
> > > > If we take ironic as the example, and assume all OS-types would be
> > > > covered in one manual, we could make that:
> > > >
> > > > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> > > > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> > > > (3) http://docs.openstack.org/install-guide/ironic/
> > > > (4) http://docs.openstack.org/ironic/install-guide/
> > > >
> > > > I like options 3 and 4. To keep things simple for the project teams,
> > > > I think we want to skip including the release series in the base
> > > > URL.  As the instructions change, projects may need to create
> > > > separate sub-sections of their guide for each series, but they
>

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Dean Troyer]

On Sun, Mar 27, 2016 at 9:44 AM, Duncan Thomas 
wrote:

> I think it is worth fixing the client to actually match the API, yes. The
> client seems to be determined not to actually match the API in lots of
> ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666
>

OSC is opinionated about what its CLI commands should look like, and one of
the strongest opinions is that they need to be consistent everywhere
possible.  To do otherwise is to continue the user-hostile CLI environment
we have provided our consumers.  It is more important for OSC to be
consistent within itself than to be consistent with other projects.

REST APIs rarely make good user interfaces, otherwise we'd all use curl as
our CLI.  They are also rarely designed to be end-user friendly.

dt

-- 

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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Dean Troyer]

On Mon, Mar 28, 2016 at 4:29 AM, Duncan Thomas 
wrote:

> Because it leads to false assumptions, and code that breaks when something
> breaks those assumptions (e.g. somebody creates a volume with no name on
> horizon and breaks all the users of openstackclient that expects one
> because their client suggested it was mandatory
>

The only place in OSC I can find that _requires_ a name and not allow an ID
is the create commands, and as noted elsewhere, "" is a valid name in the
CLI.  In most cases we make no checks on the contents of name/ID fields and
rely on the REST API/server backend to handle problems there as required.

If you know of anything in OSC that does break due to empty name fields,
that is a bug and I'd love to know about it.

dt

-- 

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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Dean Troyer]

On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez  wrote:

> On 00:40 Mar 28, Jordan Pittier wrote:
> > I am going to play the devil's advocate here but why can"t
> > python-openstackclient have its own opinion on the matter ? This CLI
> seems
> > to be for humans and humans love names/labels/tags and find UUIDS hard to
> > remember. Advanced users who want anonymous volumes can always hit the
> API
> > directly with curl or whatever SDK.
>
> I suppose it could, however, names are not unique.
>

Names are not unique in much of OpenStack.  When ambiguity exists, we exit
with an error.

Also, this works to produce a volume with no name should you absolutely
require it:

openstack volume create --size 10 ""


dt
-- 

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

Re: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a regression, why?

[Moshe Levi]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Thursday, March 24, 2016 3:35 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a
> regression, why?
> 
> We have another mitaka-rc-potential bug [1] due to a regression when
> detaching SR-IOV interfaces in the libvirt driver.
> 
> There were two NFV CIs that ran on the original change [2].
> 
> Both failed with the same devstack setup error [3][4].
> 
> So it sucks that we have a regression, it sucks that no one watched for those 
> CI
> results before approving the change, and it really sucks in this case since 
> it was
> specifically reported from mellanox for sriov which failed in [4]. But it 
> happens.
> 
> What I'd like to know is, have the CI problems been fixed? There is a change 
> up
> to fix the regression [5] and this time the Mellanox CI check is passing [6]. 
> The
> Intel NFV CI hasn't reported, but with the mellanox one also testing the 
> suspend
> scenario, it's probably good enough.
Patch-Set 6  of patch [2] passed in Mellanox CI  see 
http://144.76.193.39/ci-artifacts/262341/6/Nova-ML2-Sriov/testr_results.html.gz 
I am not sure why patch-set 7 failed. At first I thought it was because of that 
in  PS 6 we install oslo.utils==3.4.0 and in PS7 oslo.utils==3.5.0
but I could not find a difference that can be related to  this:
2016-02-16 05:05:42.164 7182 ERROR nova   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in 
import_class
2016-02-16 05:05:42.164 7182 ERROR nova __import__(mod_str)
2016-02-16 05:05:42.164 7182 ERROR nova ValueError: Empty module name

Putting that a side,  the Mellanox CI in nova is currently running and passing 
so the SR-IOV for Ethernet is not broken.
The fix in [5] is for our SR-IOV InfiniBand solution. At the moment we only 
test it in neutron (SR-IOV InfiniBand solution) and 
the reason for that is that we don't have many physical server to run the CI  
for nova and neutron. 

> 
> [1] https://bugs.launchpad.net/nova/+bug/1560860
> [2] https://review.openstack.org/#/c/262341/
> [3]
> http://intel-openstack-ci-logs.ovh/compute-
> ci/refs/changes/41/262341/7/compute-nfv-
> flavors/20160215_232057/screen/n-sch.log.gz
> [4]
> http://144.76.193.39/ci-artifacts/262341/7/Nova-ML2-Sriov/logs/n-sch.log.gz
> [5] https://review.openstack.org/#/c/296305/
> [6]
> http://144.76.193.39/ci-artifacts/296305/1/Nova-ML2-
> Sriov/testr_results.html.gz
> 
> --
> 
> 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

__
OpenStack Development Mailing 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] Austin Design Summit track layout

[Matt Riedemann]

On 3/28/2016 5:28 AM, Thierry Carrez wrote:

Hi everyone,

Please find attached in PDF the proposed layout for the various tracks
at the Design Summit in Austin. I tried to take into account all the
talk conflicts and the constraints that you communicated, although as
always there is no perfect solution.

Let me know if you see major issues with it. It's difficult to make
changes at this stage as they quickly cascade into breaking all sorts of
constraints, but we may still be able to accommodate some.

Eagle eyes readers will see that there are a number of fishbowl slots in
green (on Thursday early morning and end of afternoon). If your team is
interested in them (and that does not trigger a conflict), let me know
and we'll try to give them out.

Once the layout is official, I'll proceed to publish it on the official
event schedule. Then as each project team comes up with session titles
and content, we'll gradually push those to the official schedule. The
goal is to have all the content finalized for mid-April.

Thanks all!



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



I see one problem. The single stable team fishbowl session is scheduled 
for the last slot on Thursday (5pm). The conflict I have with that is 
the nova team does it's priority/scheduling talk in the last session on 
the last day for design summit fishbowl sessions (non-meetup style).


I'm wondering if we could move the stable session to 4:10 on Thursday. I 
don't see any infra/QA sessions happening at that time, which is the 
cross-project people we need for the stable session.


Alternatively we could maybe move the nova priorities/scheduling session 
to 4:10 on Thursday, or bump that to the Friday meetup style.


--

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] [kolla] Gift from the OpenStack foundation

[Steven Dake (stdake)]

From: Ian Cordasco mailto:sigmaviru...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, March 28, 2016 at 6:04 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Gift from the OpenStack foundation


On Mar 28, 2016 4:51 AM, "Thierry Carrez" 
mailto:thie...@openstack.org>> wrote:
>
> Steven Dake (stdake) wrote:
>>
>> [...]
>>
>> If you have been in the past or currently are a core reviewer in the
>> Kolla project and won't make summit, the foundation (or HP, not sure
>> which) has a gift of nominal value for each of you. [...]
>
>
> All I can say is that it's not the Foundation... The Foundation does not 
> special-case core reviewers. Instead, we work hard at limiting the benefits 
> associated with core reviewing so that people do not pursue becoming one for 
> the wrong reasons.

This seems inappropriate, much like HP's core reviewer party at the summit. I'm 
glad you confirmed this isn't the foundation's work.

Ian,
My apologies for inappropriately crediting the gift to the foundation.  I 
thought the foundation was aware this was happening for core reviewers - but 
that appears not to be the case.

In any regard, its not like the core reviewer party at ODS which is a blowout 
party with great food and great drinks and might violate some companies gift 
policies and many people's view of what is appropriate in an open organization. 
 Instead it is equivalent to a sticker (although it is not a sticker) that 
projects provide as gifts to people interested in their projects.

Regards
-steve


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

[openstack-dev] [TripleO] stable/mitaka branches cut

[James Slagle]

I've created stable/mitaka branches for the following TripleO projects
from the shown hashes:

tripleo-heat-templates c6249a1af273886fa326563dbc696af8fb561caa
instack-undercloud 44981413fb5ed1aec0fad966a4dcbea58d3c94c0
python-tripleoclient f7ef875df42952df4b7a7182e677ce949e15caa5
tripleo-common d52d04b0547565ad1d65afd8327f6e37e794c92a
tripleo-puppet-elements f94ee64947ec34213ae6b60577ea8565f5957c4c

These hashes match those that were used from a successful CI run using
the RDO mitaka repo at
http://trunk.rdoproject.org/centos7-mitaka/0d/da/0dda40dfe7da431df3e6d29e8347c8085a814cf0_245ab22b/

The repo is from yesterday, March 27th, and nothing new has merged
since it passed, so the hashes actually mass latest on master as of
the time of this email.

I've also bumped the major versions and pushed a tag to the master
branches as well:

tripleo-heat-templates 2.0.0
instack-undercloud 4.0.0
python-tripleoclient 2.0.0
tripleo-common 2.0.0
tripleo-puppet-elements 2.0.0

I'm working on a tripleo-ci patch for a periodic mitaka job as well.

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] [vitrage] Vitrage demo

[Afek, Ifat (Nokia - IL)]

Hi,

I uploaded a new Vitrage demo, which shows deduced alarms, deduced states and 
root cause analysis:
https://www.youtube.com/watch?v=vqlOKTmYR4c

Let me know if you have any comments or questions.

Thanks,
Ifat.

__
OpenStack Development Mailing 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] [searchlight] Add Nova Keypair Plugin

[Sampath, Lakshmi]

Hi Hiroyuki,

For this plugin what data are you indexing in Elasticsearch. I mean what do you 
expect users to search on and retrieve? Are you trying to index the public keys?
Talking directly to DB is not advisable, but before that we need to discuss 
what data is being indexed and the security implication of it (RBAC) to users 
who can/cannot access it.

I would suggest start a spec in openstack/searchlight-specs under newton for 
reviewing/feedback.
https://github.com/openstack/searchlight-specs.git


Thanks
Lakshmi.

From: Hiroyuki Eguchi [mailto:h-egu...@az.jp.nec.com]
Sent: Sunday, March 27, 2016 10:26 PM
To: OpenStack Development Mailing List (not for usage questions) 
‎[openstack-dev@lists.openstack.org]‎ 
Subject: [openstack-dev] [searchlight] Add Nova Keypair Plugin

Hi.

I am developing this plugin.
https://blueprints.launchpad.net/searchlight/+spec/nova-keypair-plugin

However I faced the problem that a admin user can not retrieve a keypair 
information created by another user.
So it is impossible to sync the keypair between OpenStack DB and Elasticsearch, 
unless connect to OpenStack DB directly.
Is there any suggestions to resolve it ?

thanks.
__
OpenStack Development Mailing 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] [release][stable][cinder] os-brick 1.2.0 release (mitaka)

[no-reply]

We are pumped to announce the release of:

os-brick 1.2.0: OpenStack Cinder brick library for managing local
volume attaches

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-brick

With package available at:

https://pypi.python.org/pypi/os-brick

Please report issues through launchpad:

http://bugs.launchpad.net/os-brick

For more details, please see below.

Changes in os-brick 1.1.0..1.2.0


01c7614 Updated from global requirements
2f95fe5 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 81b35a4..cfde43e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ eventlet!=0.18.3,>=0.18.2 # MIT
-oslo.concurrency>=2.3.0 # Apache-2.0
+oslo.concurrency>=3.5.0 # Apache-2.0



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

Re: [openstack-dev] [tc] Non-candidacy

[Jay Pipes]

On 03/28/2016 12:17 PM, Thierry Carrez wrote:

Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-03-25 14:05:44 -0400:

Hi all,

Thanks for all the fish. But it's time for me to move over and let some
new voices contribute to the OpenStack Technical Committee.

I will continue to be a proponent for the viewpoint that OpenStack
should be considered a toolkit of small, focused services and utilities,
upon which great products can be built that expose cloud computing to
ever-broader markets.

I'll just be a proponent of this view from outside the TC.

All the best, and thanks again for the opportunity to serve this past
year.

-jay



Thanks for your service, Jay. I've always appreciated your deliberate
and considered approach to our discussions, even (especially?) in
the small number of cases where we didn't agree.


I still hope you will show up and participate in the TC meeting when
something you care about is being discussed ! As mentioned in my
candidacy, we need to have that "limits of the tent" discussion soon :)


I will indeed. :)

-jay

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

Re: [openstack-dev] [tc] Non-candidacy

[Thierry Carrez]

Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-03-25 14:05:44 -0400:

Hi all,

Thanks for all the fish. But it's time for me to move over and let some
new voices contribute to the OpenStack Technical Committee.

I will continue to be a proponent for the viewpoint that OpenStack
should be considered a toolkit of small, focused services and utilities,
upon which great products can be built that expose cloud computing to
ever-broader markets.

I'll just be a proponent of this view from outside the TC.

All the best, and thanks again for the opportunity to serve this past year.

-jay



Thanks for your service, Jay. I've always appreciated your deliberate
and considered approach to our discussions, even (especially?) in
the small number of cases where we didn't agree.


I still hope you will show up and participate in the TC meeting when 
something you care about is being discussed ! As mentioned in my 
candidacy, we need to have that "limits of the tent" discussion soon :)


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] Gift from the OpenStack foundation

[Steven Dake (stdake)]

On 3/28/16, 2:49 AM, "Thierry Carrez"  wrote:

>Steven Dake (stdake) wrote:
>> [...]
>> If you have been in the past or currently are a core reviewer in the
>> Kolla project and won't make summit, the foundation (or HP, not sure
>> which) has a gift of nominal value for each of you. [...]
>
>All I can say is that it's not the Foundation... The Foundation does not
>special-case core reviewers. Instead, we work hard at limiting the
>benefits associated with core reviewing so that people do not pursue
>becoming one for the wrong reasons.

Thierry,

Thanks for clearing that up.  The gift is minor in nature - very minor -
equivalent to a sticker that projects give to people that are interested
in their projects.

Regards
-steve

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


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

Re: [openstack-dev] [nova][novaclient] Responses for Deletion Events

[Dean Troyer]

On Sun, Mar 27, 2016 at 7:56 PM, Matt Riedemann 
wrote:
>
> The novaclient CLI is supposed to be more or less deprecated (for awhile
> now), but because of a lack of microversion support in the openstackclient
> CLI we've continued making changes to novaclient CLI.
>

We're climbing that particular hill now...


> In this case, we could just say we're not fixing it for novaclient and if
> you want it, add the behavior to openstackclient. That team probably has
> guidelines (at least in Dean's head) around how verbose a delete operation
> should be.
>

These sorts of things are getting extracted from my (and others') heads
into the devref docs.  With the default logging settings we have no output
for delete commands unless an error has occurred.

dt

-- 

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

[openstack-dev] [election] [tc] TC candidacy

[Thierry Carrez]

(This was also submitted as https://review.openstack.org/#/c/298294)

Hi everyone,

I'd like to submit my candidacy for reelection on the Technical 
Committee. For those who don't know me yet, my name is Thierry Carrez, I 
use "ttx" as my IRC nickname. I'm currently employed by the OpenStack 
Foundation as its Director of Engineering, which basically means I'm 
running the team in charge of ensuring the long-term health of the 
upstream OpenStack open source project and its governance. Handling the 
Technical Committee is my primary activity: 6 months ago I left the PTL 
role for the Release Management Team in order to be able to focus as 
much as possible on the TC.


One year ago I ran for election with the goal of having the TC "step out 
of the way"[1]. The idea was to remove the TC from the critical path of 
getting things done, and encourage a "ask for forgiveness, rather than 
permission" attitude in our community. I like to think we were 
successful at this. Project teams can now more easily add git 
repositories as they need them, they also end up asserting some tags by 
themselves, and the TC has generally moved to being an appeals board in 
case of disputes, rather than a procedural barrier in getting things done.


Here are the three priorities for my upcoming mandate, if the electorate
chooses to reelect me to the TC:

1/ Cleaning up the big tent

The transition to the "big tent" governance model is now finished, with 
all the expected projects now officially part of the OpenStack 
community. The big tent is all about community: answering the "are you 
one of us" question. Our approach there was to be inclusive and assume 
good faith, especially as we caught up on documenting what we meant by 
"the OpenStack Way". Over the past year we created the Project Team 
Guide[2], which clearly explains what is expected of official project 
teams. I think it's time for us to look back at all those projects we 
have in the tent, reach out to those who are lacking, and not hesitate 
to remove the ones that are not following our common community practices 
from the list of official project teams. Demoting a project used to be 
particularly painful, with costly git repository renames crating 
disruption on the demoted projects. But now that all projects hosted 
under our infrastructure (official and unofficial) use the same 
namespace, this cost and disruption are very limited, so cleaning up the 
big tent is now possible.


2/ Defining the limits of the big tent

The TC recently had two project team applications for which we had no 
good answer: Poppy and Tacker. Those resulted in close (and somewhat 
arbitrary) votes as each TC member tried to interpret the mission 
statement words and what we stand for. In the case of Poppy, there was 
the question of whether a service that proxies to non-OpenStack 
commercial services could be considered part of "OpenStack", without an 
open source reference implementation to do end-to-end testing against. 
In the case of Tacker, there was the question of a service standing on 
top of other OpenStack services to present a domain-specific API 
tailored to a specific use case or industry. Should that still be 
"OpenStack", or just something that consumes OpenStack ? I'd like the TC 
to take a step back and explore those two questions, without the 
pressure of a specific project team addition. Clarifying the rules may 
result in some official projects to be demoted to "unofficial" status as 
they would not fit the rules anymore.


3/ Launching the new separated event for project team members

We recently started the discussion[3] on splitting the "design summit" 
into wider community feedback / requirements-gathering sessions (that 
would happen at the main Summit) and a specific event for project team 
members to gather in a co-located venue to come up with a plan and 
organize its execution. We still have a long way to go (and not that 
much time) to discuss the format and the timing of this new event, and I 
expect the Newton membership of the TC to help with taking quick 
decisions there. The next step here will be a cross-project workshop at 
the Design Summit in Austin to discuss the current plan and go deeper in 
the details.


Those are my three priorities for Newton and Ocata, and this is what 
I'll push the Technical Committee towards if I'm elected.


Thank you all for your consideration !

[1] http://ttx.re/stepping-out-of-the-way.html
[2] http://docs.openstack.org/project-team-guide/
[3] http://ttx.re/splitting-out-design-summit.html

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] [tc] Non-candidacy

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2016-03-25 14:05:44 -0400:
> Hi all,
> 
> Thanks for all the fish. But it's time for me to move over and let some 
> new voices contribute to the OpenStack Technical Committee.
> 
> I will continue to be a proponent for the viewpoint that OpenStack 
> should be considered a toolkit of small, focused services and utilities, 
> upon which great products can be built that expose cloud computing to 
> ever-broader markets.
> 
> I'll just be a proponent of this view from outside the TC.
> 
> All the best, and thanks again for the opportunity to serve this past year.
> 
> -jay
> 

Thanks for your service, Jay. I've always appreciated your deliberate
and considered approach to our discussions, even (especially?) in
the small number of cases where we didn't agree.

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] [release][packaging] Mitaka packaged on gentoo

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2016-03-27 19:35:38 -0500:
> 
> On 3/27/2016 7:18 PM, Matthew Thode wrote:
> > On 03/27/2016 04:53 PM, Matt Riedemann wrote:
> >>
> >>
> >> On 3/25/2016 11:15 PM, Matthew Thode wrote:
> >>> I've finished packaging mitaka on Gentoo, won't be marked stable for
> >>> about a month.  The version packaged is based off of the stable/mitaka
> >>> branch (noted by the version being 2016.1.).  I haven't found where
> >>> an upgrade guide is being worked on (if anywhere), so that would help in
> >>> testing if anyone knows where it is.
> >>>
> >>>
> >>>
> >>> __
> >>>
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >> There are mitaka install guides, if that helps, e.g.:
> >>
> >> http://docs.openstack.org/mitaka/install-guide-ubuntu/
> >>
> >> Otherwise the upgrade impact sections of the release notes for the
> >> projects are probably the next thing to be checking. For nova, the
> >> mitaka release notes are here:
> >>
> >> http://docs.openstack.org/releasenotes/nova/mitaka.html
> >>
> >
> > Are the release notes being gathered into one document for this release?
> >   I might be misremembering but I think Liberty had that.
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> Nope, it's big tent fun and the cats herd themselves now. The release 
> notes are published for each project in 
> http://docs.openstack.org/releasenotes/ and that's also including new 
> releases for stable/liberty.

When https://review.openstack.org/#/c/297840/ is merged (and any
stragglers are updated), we will have links to all of the release notes
projects on http://releases.openstack.org/mitaka/index.html

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] [kloudbuster] authorization failed problem

[Alec Hothan (ahothan)]

Can you describe what you mean by "do not have a cinder service"?
Can you provide the output of "keystone service-list"?

We'd have to know a bit more about what you have been doing:
how did you install your openstack, how did you install kloudbuster, which 
kloudbuster qcow2 image version did you use, who did you run kloudbuster (cli 
or REST or web UI), what config file have you been using, complete log of the 
run (including backtrace)...

But the key is - you should really have a fully working openstack deployment 
before using kloudbuster. Nobody has never tried so far to use kloudbuster 
without such basic service as cinder working.

Thanks

  Alec



From: Akshay Kumar Sanghai 
mailto:akshaykumarsang...@gmail.com>>
Date: Monday, March 28, 2016 at 6:51 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
Alec Hothan mailto:ahot...@cisco.com>>
Cc: "Yichen Wang (yicwang)" mailto:yicw...@cisco.com>>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Alec,
Thanks for the help. I ran into another problem. At present I do not have a 
cinder service. So ,when i am trying to run kloudbuster, I am getting this 
error:
"EndpointNotFound: publicURL endpoint for volumev2 service not found"
Is it possible to run the scale test (creation of VMs, router, network) without 
having a cinder service? Any option that can be used so that kloudbuster can 
run without cinder.

Thanks,
Akshay

On Wed, Mar 23, 2016 at 9:05 PM, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:
Hi Akshay

The URL you are using is a private address (http://192.168.138.51:5000/v2.0) 
and is likely the reason it does not work.
If you run the kloudbuster App in the cloud, this app needs to have access to 
the cloud under test.
So even if you can access 192.168.138.51 from your local browser (which runs on 
your workstation or laptop) it may not be accessible from a VM that runs in 
your cloud.
For that to work you need to get an URL that is reachable from the VM.

In some cases where the cloud under test is local, it is easier to just run 
kloudbuster locally as well (from the same place where you can ping 
192.168.138.51).
You can either use a local VM to run the kloudbuster image (vagrant, virtual 
box...) or just simpler, install kloudbuster locally using git clone or pip 
install (see the installation instructions in the doc 
http://kloudbuster.readthedocs.org/en/latest/).

Regards,

   Alec


__
OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Andrey Pavlov]

Ian, yes.
this is one of visible problems...

Regards,
Andrey.

On Mon, Mar 28, 2016 at 5:39 PM, Ian Cordasco  wrote:
>
>
> -Original Message-
> From: Andrey Pavlov 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: March 28, 2016 at 09:34:54
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API 
> project in gerrit?
>
>> But why I can't see the project in the gerrit.openstack.org?
>
> I'm not seeing any reviews on Gerrit either: 
> https://review.openstack.org/#/q/project:openstack/ec2-api+AND+(status:merged+OR+status:open)
>
> I think this is what you're asking about, right Andrey?
> --
> Ian Cordasco
>



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Davanum Srinivas]

y, whoa! Andrey, i just pinged folks on #openstack-infra.

On Mon, Mar 28, 2016 at 10:39 AM, Ian Cordasco  wrote:
>
>
> -Original Message-
> From: Andrey Pavlov 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: March 28, 2016 at 09:34:54
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API 
> project in gerrit?
>
>> But why I can't see the project in the gerrit.openstack.org?
>
> I'm not seeing any reviews on Gerrit either: 
> https://review.openstack.org/#/q/project:openstack/ec2-api+AND+(status:merged+OR+status:open)
>
> I think this is what you're asking about, right Andrey?
> --
> Ian Cordasco
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Ian Cordasco]

 

-Original Message-
From: Andrey Pavlov 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: March 28, 2016 at 09:34:54
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API 
project in gerrit?

> But why I can't see the project in the gerrit.openstack.org?

I'm not seeing any reviews on Gerrit either: 
https://review.openstack.org/#/q/project:openstack/ec2-api+AND+(status:merged+OR+status:open)

I think this is what you're asking about, right Andrey?
--  
Ian Cordasco


__
OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Andrey Pavlov]

But why I can't see the project in the gerrit.openstack.org?

On Mon, Mar 28, 2016 at 5:19 PM, Davanum Srinivas  wrote:
> it's there : http://git.openstack.org/cgit/openstack/ec2-api/
>
> -- Dims
>
> On Mon, Mar 28, 2016 at 10:12 AM, Andrey Pavlov  wrote:
>> Hello,
>>
>> Today I found that our EC2-API project has disappeared from gerrit...
>> Yesterday it was accessible...
>>
>> It is still present on github.com/openstack/ec2-api
>> Configuration is still present in project-config repository.
>> I can't find any changes in governance project related to ec2-api project.
>>
>> Can anyone say me what happened with our EC2-API project?
>>
>> --
>> Kind regards,
>> Andrey Pavlov.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Davanum Srinivas]

it's there : http://git.openstack.org/cgit/openstack/ec2-api/

-- Dims

On Mon, Mar 28, 2016 at 10:12 AM, Andrey Pavlov  wrote:
> Hello,
>
> Today I found that our EC2-API project has disappeared from gerrit...
> Yesterday it was accessible...
>
> It is still present on github.com/openstack/ec2-api
> Configuration is still present in project-config repository.
> I can't find any changes in governance project related to ec2-api project.
>
> Can anyone say me what happened with our EC2-API project?
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

[openstack-dev] [Kuryr] - IRC Meeting canceled today

[Gal Sagie]

Hello all,

Since there is a number of members that cant attend the IRC meeting today
we will
cancel it.

Sorry for the late announcement.

I have updated the agenda for the meeting, lets postpone the same agenda
for the meeting next week.

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

[openstack-dev] [Infra][ec2-api] What happened with EC2-API project in gerrit?

[Andrey Pavlov]

Hello,

Today I found that our EC2-API project has disappeared from gerrit...
Yesterday it was accessible...

It is still present on github.com/openstack/ec2-api
Configuration is still present in project-config repository.
I can't find any changes in governance project related to ec2-api project.

Can anyone say me what happened with our EC2-API project?

-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing 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] [kloudbuster] authorization failed problem

[Akshay Kumar Sanghai]

Hi Alec,
Thanks for the help. I ran into another problem. At present I do not have a
cinder service. So ,when i am trying to run kloudbuster, I am getting this
error:
"EndpointNotFound: publicURL endpoint for volumev2 service not found"
Is it possible to run the scale test (creation of VMs, router, network)
without having a cinder service? Any option that can be used so that
kloudbuster can run without cinder.

Thanks,
Akshay

On Wed, Mar 23, 2016 at 9:05 PM, Alec Hothan (ahothan) 
wrote:

> Hi Akshay
>
> The URL you are using is a private address (
> http://192.168.138.51:5000/v2.0) and is likely the reason it does not
> work.
> If you run the kloudbuster App in the cloud, this app needs to have access
> to the cloud under test.
> So even if you can access 192.168.138.51 from your local browser (which
> runs on your workstation or laptop) it may not be accessible from a VM that
> runs in your cloud.
> For that to work you need to get an URL that is reachable from the VM.
>
> In some cases where the cloud under test is local, it is easier to just
> run kloudbuster locally as well (from the same place where you can ping
> 192.168.138.51).
> You can either use a local VM to run the kloudbuster image (vagrant,
> virtual box...) or just simpler, install kloudbuster locally using git
> clone or pip install (see the installation instructions in the doc
> http://kloudbuster.readthedocs.org/en/latest/).
>
> Regards,
>
>Alec
>
>
>
>
> From: Akshay Kumar Sanghai 
> Reply-To: "openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, March 23, 2016 at 6:59 AM
> To: "Yichen Wang (yicwang)" , "
> openstack-dev@lists.openstack.org" 
> Subject: [openstack-dev] [kloudbuster] authorization failed problem
>
> Hi,
>
> I am trying to use cloudbuster for the scale testing of openstack setup.
>
> I have a openstack setup with 1 controller, 1 network and 2 compute node.
> I am trying to use to use kloudbuster for scale testing of the setup. I
> created one VM with kloudbuster image. I accessed the web UI and clicked on
> "stage". This is the log:
> :23,206 WARNING No public key is found or specified to instantiate VMs.
> You will not be able to access the VMs spawned by KloudBuster.
> 2016-03-22 14:01:30,464 WARNING Traceback (most recent call last):
>   File \"/kb_test/kloudbuster/kb_server/kb_server/controllers/api_kb.py\",
> line 58, in kb_stage_thread_handler
> if kb_session.kloudbuster.check_and_upload_images():
>   File
> \"/kb_test/kloudbuster/kb_server/kb_server/controllers/../../../kloudbuster/kloudbuster.py\",
> line 283, in check_and_upload_images
> keystone_list = [create_keystone_client(self.server_cred)[0],
>   File
> \"/kb_test/kloudbuster/kb_server/kb_server/controllers/../../../kloudbuster/kloudbuster.py\",
> line 54, in create_keystone_client
> return (keystoneclient.Client(endpoint_type='publicURL', **creds),
> creds['auth_url'])
>   File
> \"/usr/local/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py\",
> line 166, in __init__
> self.authenticate()
>   File \"/usr/local/lib/python2.7/dist-packages/keystoneclient/utils.py\",
> line 337, in inner
> return func(*args, **kwargs)
>   File
> \"/usr/local/lib/python2.7/dist-packages/keystoneclient/httpclient.py\",
> line 589, in authenticate
> resp = self.get_raw_token_from_identity_service(**kwargs)
>   File
> \"/usr/local/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py\",
> line 210, in get_raw_token_from_identity_service
> _(\"Authorization Failed: %s\") % e)
> AuthorizationFailure: Authorization Failed: Unable to establish connection
> to http://192.168.138.51:5000/v2.0/tokens
>
> I used a rest client to find whether v2.0/tokens is working or not, it was
> working. I got the token . This is the openrc file I used:
> export OS_PROJECT_DOMAIN_ID=default
> export OS_USER_DOMAIN_ID=default
> #export OS_IMAGE_API_VERSION=2
> export OS_AUTH_URL=http://192.168.138.51:5000/v2.0
> export OS_TENANT_NAME=admin
> #export OS_PROJECT_NAME=admin
> export OS_USERNAME=admin
> export OS_PASSWORD=sanghai
> export OS_REGION_NAME=RegionOne
>
> Please suggest a solution and let me know if I missed some details.
>
> Thanks,
> Akshay
>
>
> __
> OpenStack Development Mailing 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] Gift from the OpenStack foundation

[Ian Cordasco]

On Mar 28, 2016 4:51 AM, "Thierry Carrez"  wrote:
>
> Steven Dake (stdake) wrote:
>>
>> [...]
>>
>> If you have been in the past or currently are a core reviewer in the
>> Kolla project and won't make summit, the foundation (or HP, not sure
>> which) has a gift of nominal value for each of you. [...]
>
>
> All I can say is that it's not the Foundation... The Foundation does not
special-case core reviewers. Instead, we work hard at limiting the benefits
associated with core reviewing so that people do not pursue becoming one
for the wrong reasons.

This seems inappropriate, much like HP's core reviewer party at the summit.
I'm glad you confirmed this isn't the foundation's work.
__
OpenStack Development Mailing 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-stable-maint] Stable check of openstack/trove failed

[Amrith Kumar]

I ran this manually on stable/mitaka and it succeeded. The errors being 
reported are "database is locked". Is this something in the infrastructure or 
do you want me to investigate further?

-amrith

> -Original Message-
> From: A mailing list for the OpenStack Stable Branch test reports.
> [mailto:openstack-stable-ma...@lists.openstack.org]
> Sent: Monday, March 28, 2016 2:44 AM
> To: openstack-stable-ma...@lists.openstack.org
> Subject: [Openstack-stable-maint] Stable check of openstack/trove failed
> 
> Build failed.
> 
> - periodic-trove-docs-kilo http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-kilo/4ad7c83/ : SUCCESS in 4m 53s
> - periodic-trove-python27-db-kilo http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-kilo/6bb9fd1/ : SUCCESS in 4m 11s
> - periodic-trove-docs-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-liberty/7de5d94/ : SUCCESS in 3m 23s
> - periodic-trove-python27-db-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-liberty/4c9a901/ : SUCCESS in 9m 12s
> - periodic-trove-docs-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-mitaka/ba4f9c4/ : SUCCESS in 10m 07s
> - periodic-trove-python27-db-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-mitaka/70f3eff/ : FAILURE in 17m 07s
> 
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

__
OpenStack Development Mailing 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] [containers][horizon][magnum-ui] - Stable version for Liberty?

[Shuu Mutou]

Hi Marcos and Adrian,

Since Magnum-UI has a lot of new angularized feature in master branch, next 
release of Magnum-UI is not suitable for backporting to stable/liberty.


Adrian,

Could you cut the release as 1.0.0rc2, for freeze strings, at following git 
hash?

c3494b3fce6d46de5a761f77ec1b01a2f2abf5ab

https://github.com/openstack/magnum-ui/commit/a6e326d72d957d7f64c5297fb1869d7b0bb05b3a


Best regards,

Shu Muto


__
OpenStack Development Mailing 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] Austin Design Summit track layout

[Thierry Carrez]

Hi everyone,

Please find attached in PDF the proposed layout for the various tracks 
at the Design Summit in Austin. I tried to take into account all the 
talk conflicts and the constraints that you communicated, although as 
always there is no perfect solution.


Let me know if you see major issues with it. It's difficult to make 
changes at this stage as they quickly cascade into breaking all sorts of 
constraints, but we may still be able to accommodate some.


Eagle eyes readers will see that there are a number of fishbowl slots in 
green (on Thursday early morning and end of afternoon). If your team is 
interested in them (and that does not trigger a conflict), let me know 
and we'll try to give them out.


Once the layout is official, I'll proceed to publish it on the official 
event schedule. Then as each project team comes up with session titles 
and content, we'll gradually push those to the official schedule. The 
goal is to have all the content finalized for mid-April.


Thanks all!

--
Thierry Carrez (ttx)


DesignSummitAustin.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing 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] [mistral] Cancelling team meeting - 03/28/2016

[Renat Akhmerov]

Hi,

I suggest we cancel today’s team meeting in favor of pre-release activities 
(bugs, release notes etc.). Find us at #openstack-mistral IRC channel, if 
needed.

Thanks

Renat Akhmerov
@ Mirantis Inc.




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

Re: [openstack-dev] [oslo][messaging][zmq][performance]

[Oleksii Zamiatin]

As I can see, this solution is generally applicable, but I’m not sure we need 
all it’s features with e.g. rabbitmq as it also has it’s own means of 
authentication and support for ssl. For zmq it is one of recommended backends.

> On Mar 25, 2016, at 18:39, Joshua Harlow  wrote:
> 
> Out of curiosity for this, is it a generally applicable solution that could 
> also be used for the other in(secure) messaging issues that have been talked 
> about in:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90082
> 
> On 03/25/2016 05:28 AM, Oleksii Zamiatin wrote:
>> 6. Support encryption for messages (libsodium etc.)
> 
> __
> OpenStack Development Mailing 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] Gift from the OpenStack foundation

[Thierry Carrez]

Steven Dake (stdake) wrote:

[...]
If you have been in the past or currently are a core reviewer in the
Kolla project and won't make summit, the foundation (or HP, not sure
which) has a gift of nominal value for each of you. [...]


All I can say is that it's not the Foundation... The Foundation does not 
special-case core reviewers. Instead, we work hard at limiting the 
benefits associated with core reviewing so that people do not pursue 
becoming one for the wrong reasons.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] [kite][barbican] Notice to retire kite and python-kiteclient projects

[Thierry Carrez]

Ronald Bradford wrote:

From the initial ML discussion [1], the following are instructions to
retire a project [2].
The kite and python_kiteclient projects are moving to a non maintained
status.


The very first step would be to remove them from the list of official 
projects (by editing reference/projects.yaml in the openstack/governance 
repository), since the official project team it's attached to is not 
maintaining it.


We should only retire the project if we think nobody will ever again 
work on it, which is a slightly different discussion.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Duncan Thomas]

Because it leads to false assumptions, and code that breaks when something
breaks those assumptions (e.g. somebody creates a volume with no name on
horizon and breaks all the users of openstackclient that expects one
because their client suggested it was mandatory

On 28 March 2016 at 01:40, Jordan Pittier 
wrote:

> I am going to play the devil's advocate here but why can"t
> python-openstackclient have its own opinion on the matter ? This CLI seems
> to be for humans and humans love names/labels/tags and find UUIDS hard to
> remember. Advanced users who want anonymous volumes can always hit the API
> directly with curl or whatever SDK.
>
> On Sun, Mar 27, 2016 at 4:44 PM, Duncan Thomas 
> wrote:
>
>> I think it is worth fixing the client to actually match the API, yes. The
>> client seems to be determined not to actually match the API in lots of
>> ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666
>>
>> On 24 March 2016 at 19:08, Ivan Kolodyazhny  wrote:
>>
>>> Hi team,
>>>
>>> From the Cinder point of view, both volumes, snapshots and backups APIs
>>> do not require name param. But python-openstackclient requires name param
>>> for these entities.
>>>
>>> I'm going to fix this inconsistency with patch [1]. Unfortunately, it's
>>> a bit more than changing required params to not required. We have to change
>>> CLI signatures. E.g. for create a volume: from [2].
>>>
>>> Is it acceptable? What is the right way to do such changes for OpenStack
>>> Client?
>>>
>>>
>>> [1] https://review.openstack.org/#/c/294146/
>>> [2] http://paste.openstack.org/show/491771/
>>> [3] http://paste.openstack.org/show/491772/
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
-- 
Duncan Thomas
__
OpenStack Development Mailing 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] playing tricircle with two node configuration

[Shinobu Kinjo]

FYI:
This is the reason is that there is still n-net. [1]

[1] 
http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html

Cheers,
S

On Mon, Mar 28, 2016 at 5:08 PM, joehuang  wrote:
> Hi,
>
>
>
> Agree, it’s quite important not to use Nova-network in devstack. In devstack
> local.conf, make sure the Neutron service is enabled and Nova-network is
> disabled.
>
>
>
> # Use Neutron instead of nova-network
>
> disable_service n-net
>
> enable_service q-svc
>
> enable_service q-svc1
>
> enable_service q-dhcp
>
> enable_service q-agt
>
>
>
> And also check the configuration in Nova to use Neutron
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> From: Vega Cai [mailto:luckyveg...@gmail.com]
> Sent: Monday, March 28, 2016 2:55 PM
> To: Yipei Niu
> Cc: OpenStack Development Mailing List (not for usage questions); joehuang
> Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
> configuration
>
>
>
> Hi Yipei,
>
>
>
> Check "network_api_class" and "use_neutron" options in your nova.conf. It
> seems that your nova API is not configured to use neutron.
>
>
>
> BR
>
> Zhiyuan
>
>
>
> On 28 March 2016 at 13:25, Yipei Niu  wrote:
>
> Hi, all,
>
>
>
> After I execute the command "nova boot --flavor 1 --image
> c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
> net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1",
> there exist some problem with the argument port. In t-ngw.log, I find that
> the status of port switches from ACTIVE to DOWN, which is marked as bold
> below. Is it the reason why I failed to boot a VM?
>
>
>
> 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773" -d
> '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
> "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
>
> 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '384',
> 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
> {"port": {"status": "ACTIVE", "name": "", "admin_state_up": true,
> "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
> "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
> "fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
> "2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id":
> "e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
> ^[[00;33mfrom (pid=17537) http_log_resp
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
>
> 2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773" -d
> '{"port": {"name": "e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up":
> true, "network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id":
> "29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09",
> "fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480",
> "ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
>
> 2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '808',
> 'X-Openstack-Request-Id': 'req-d286f85c-bc4b-4d7c-9915-666fe13b48b5'}
> {"port": {"status": "DOWN", "binding:host_id": "", "allowed_address_pairs":
> [], "dns_assignment": [{"hostname": "host-10-0-8-5", "ip_address":
> "10.0.8.5", "fqdn": "host-10-0-8-5.openstacklocal."}], "device_owner": "",
> "binding:profile": {}, "port_security_enabled": true, "fixed_ips":
> [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480", "ip_address":
> "10.0.8.5"}], "id": "0bbf77a4-c4e4-43ad-89a0-e55f053ef4da",
> "security_groups": ["16f02958-2a4f-4f58-b560-b9fa76be1b0c"], "device_id":
> "", "name": "e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true,
> "network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "dns_name": "",
> "binding:vif_details": {}, "binding:vnic_type": "normal",
> "binding:vif_type": "unbou

Re: [openstack-dev] [Neutron] BGP support

[Gary Kotton]

Hi,
Thanks for the clarification. I still feel like there may be some overlap here.
Thanks
Gary

From: Irena Berezovsky mailto:irenab@gmail.com>>
Date: Monday, March 28, 2016 at 11:16 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
Gary Kotton mailto:gkot...@vmware.com>>
Subject: Re: [openstack-dev] [Neutron] BGP support

Hi Gary,
The new L2GW spec is [1] comes to enable inter-cloud connection to stretch the 
network between the local and the remote clouds using tunnels between border 
VTEP devices.
VTEP can be populated manually with remote MAC (optionally) IP entries.
BGP support is a bit orthogonal or may I say complementary.

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

On Mon, Mar 28, 2016 at 9:36 AM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
In the M cycle BGP support was added in tree. I have seen specs in the L2 GW 
project for this support too. Are we planning to consolidate the efforts? Will 
the BGP code be moved from the Neutron git to the L2-GW project? Will a new 
project be created?
Sorry, a little in the dark here and it would be nice if someone could please 
provide some clarity here. It would be a pity that there were competing efforts 
and my take would be that the Neutron code would be the single source of truth 
(until we decide otherwise).
I think that the L2-GW project would be a very good place for that service code 
to reside. It can also have MPLS etc. support. So it may be a natural fit.
Thanks
Gary

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


__
OpenStack Development Mailing 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] playing tricircle with two node configuration

[joehuang]

Hi,

Agree, it’s quite important not to use Nova-network in devstack. In devstack 
local.conf, make sure the Neutron service is enabled and Nova-network is 
disabled.

# Use Neutron instead of nova-network
disable_service n-net
enable_service q-svc
enable_service q-svc1
enable_service q-dhcp
enable_service q-agt

And also check the configuration in Nova to use Neutron

Best Regards
Chaoyi Huang ( Joe Huang )

From: Vega Cai [mailto:luckyveg...@gmail.com]
Sent: Monday, March 28, 2016 2:55 PM
To: Yipei Niu
Cc: OpenStack Development Mailing List (not for usage questions); joehuang
Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node 
configuration

Hi Yipei,

Check "network_api_class" and "use_neutron" options in your nova.conf. It seems 
that your nova API is not configured to use neutron.

BR
Zhiyuan

On 28 March 2016 at 13:25, Yipei Niu 
mailto:newy...@gmail.com>> wrote:
Hi, all,

After I execute the command "nova boot --flavor 1 --image 
c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic 
net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1", there 
exist some problem with the argument port. In t-ngw.log, I find that the status 
of port switches from ACTIVE to DOWN, which is marked as bold below. Is it the 
reason why I failed to boot a VM?

2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client 
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin 
admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i 
http://192.168.56.101:9696//v2.0/ports.json
 -X POST -H "User-Agent: python-neutronclient" -H "X-Auth-Token: 
7cfcfb91173a4920adaf24db7eebd773" -d '{"port": {"network_id": 
"a9059cde-3065-4615-859a-facd6aa66b76", "admin_state_up": true}}'^[[00m 
^[[00;33mfrom (pid=17537) http_log_req 
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client 
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin 
admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016 03:49:44 
GMT', 'Connection': 'keep-alive', 'Content-Type': 'application/json; 
charset=UTF-8', 'Content-Length': '384', 'X-Openstack-Request-Id': 
'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'} {"port": {"status": "ACTIVE", 
"name": "", "admin_state_up": true, "network_id": 
"a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id": 
"29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address": 
"fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id": 
"2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id": 
"e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m ^[[00;33mfrom 
(pid=17537) http_log_resp 
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client 
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin 
admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i 
http://192.168.56.101:20001//v2.0/ports.json
 -X POST -H "User-Agent: python-neutronclient" -H "X-Auth-Token: 
7cfcfb91173a4920adaf24db7eebd773" -d '{"port": {"name": 
"e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true, "network_id": 
"25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id": 
"29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09", 
"fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480", 
"ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req 
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client 
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin 
admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016 03:49:44 
GMT', 'Connection': 'keep-alive', 'Content-Type': 'application/json; 
charset=UTF-8', 'Content-Length': '808', 'X-Openstack-Request-Id': 
'req-d286f85c-bc4b-4d7c-9915-666fe13b48b5'} {"port": {"status": "DOWN", 
"binding:host_id": "", "allowed_address_pairs": [], "dns_assignment": 
[{"hostname": "host-10-0-8-5", "ip_address": "10.0.8.5", "fqdn": 
"host-10-0-8-5.openstacklocal."}], "device_owner": "", "binding:profile": {}, 
"port_security_enabled": true, "fixed_ips": [{"subnet_id": 
"fd1abd0d-9398-4848-a3cf-57858868a480", "ip_address": "10.0.8.5"}], "id": 
"0bbf77a4-c4e4-43ad-89a0-e55f053ef4da", "security_groups": 
["16f02958-2a4f-4f58-b560-b9fa76be1b0c"], "device_id": "", "name": 
"e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true, "network_id": 
"25ebd3c0-ae47-4e77-be35-16d815bffe5c", "dns_name": "", "binding:vif_details": 
{}, "binding:vnic_type": "normal", "binding:vif_type": "unbound", "tenant_id": 
"29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09"}}^[[00m 
^[[00;33mfrom (pid=17537) http_log_resp 
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
2016-03-28 11:49:44.810 ^[[00;36mINFO eventlet.wsgi.se

Re: [openstack-dev] [Neutron] BGP support

[Irena Berezovsky]

Hi Gary,
The new L2GW spec is [1] comes to enable inter-cloud connection to stretch
the network between the local and the remote clouds using tunnels between
border VTEP devices.
VTEP can be populated manually with remote MAC (optionally) IP entries.
BGP support is a bit orthogonal or may I say complementary.

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

On Mon, Mar 28, 2016 at 9:36 AM, Gary Kotton  wrote:

> Hi,
> In the M cycle BGP support was added in tree. I have seen specs in the L2
> GW project for this support too. Are we planning to consolidate the
> efforts? Will the BGP code be moved from the Neutron git to the L2-GW
> project? Will a new project be created?
> Sorry, a little in the dark here and it would be nice if someone could
> please provide some clarity here. It would be a pity that there were
> competing efforts and my take would be that the Neutron code would be the
> single source of truth (until we decide otherwise).
> I think that the L2-GW project would be a very good place for that service
> code to reside. It can also have MPLS etc. support. So it may be a natural
> fit.
> Thanks
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] BGP support

[Vikram Choudhary]

Hi Gary,

Could you please provide the spec details..

Thanks
Vikram

On Mon, Mar 28, 2016 at 1:27 PM, Gary Kotton  wrote:

> Thanks for the pointers. Any reason why this is not part of the L2 gateway
> effort? I think that could be a natural place for this. The project name
> may be a bit misleading, but at the end of the day the Neutron tenant will
> have network connectivity irrespective if a neutron network is realized in
> a number of different places that are connected either via MPLS or BGP or
> any other protocol.
> I think that creating another project is just fragmenting things even more
> …
>
> From: Hirofumi Ichihara 
> Reply-To: OpenStack List 
> Date: Monday, March 28, 2016 at 10:50 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] BGP support
>
> Hi Gary,
>
> You can look at the discussion in here[1, 2]
>
> [1]: https://bugs.launchpad.net/neutron/+bug/1560003
> [2]: https://review.openstack.org/#/c/268726
>
> Thanks,
> Hirofumi
>
> On 2016/03/28 15:36, Gary Kotton wrote:
>
> Hi,
> In the M cycle BGP support was added in tree. I have seen specs in the L2
> GW project for this support too. Are we planning to consolidate the
> efforts? Will the BGP code be moved from the Neutron git to the L2-GW
> project? Will a new project be created?
> Sorry, a little in the dark here and it would be nice if someone could
> please provide some clarity here. It would be a pity that there were
> competing efforts and my take would be that the Neutron code would be the
> single source of truth (until we decide otherwise).
> I think that the L2-GW project would be a very good place for that service
> code to reside. It can also have MPLS etc. support. So it may be a natural
> fit.
> Thanks
> Gary
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] BGP support

[Gary Kotton]

Thanks for the pointers. Any reason why this is not part of the L2 gateway 
effort? I think that could be a natural place for this. The project name may be 
a bit misleading, but at the end of the day the Neutron tenant will have 
network connectivity irrespective if a neutron network is realized in a number 
of different places that are connected either via MPLS or BGP or any other 
protocol.
I think that creating another project is just fragmenting things even more …

From: Hirofumi Ichihara 
mailto:ichihara.hirof...@lab.ntt.co.jp>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, March 28, 2016 at 10:50 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] BGP support

Hi Gary,

You can look at the discussion in here[1, 2]

[1]: https://bugs.launchpad.net/neutron/+bug/1560003
[2]: https://review.openstack.org/#/c/268726

Thanks,
Hirofumi

On 2016/03/28 15:36, Gary Kotton wrote:
Hi,
In the M cycle BGP support was added in tree. I have seen specs in the L2 GW 
project for this support too. Are we planning to consolidate the efforts? Will 
the BGP code be moved from the Neutron git to the L2-GW project? Will a new 
project be created?
Sorry, a little in the dark here and it would be nice if someone could please 
provide some clarity here. It would be a pity that there were competing efforts 
and my take would be that the Neutron code would be the single source of truth 
(until we decide otherwise).
I think that the L2-GW project would be a very good place for that service code 
to reside. It can also have MPLS etc. support. So it may be a natural fit.
Thanks
Gary



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] BGP support

[Hirofumi Ichihara]

Hi Gary,

You can look at the discussion in here[1, 2]

[1]: https://bugs.launchpad.net/neutron/+bug/1560003
[2]: https://review.openstack.org/#/c/268726

Thanks,
Hirofumi

On 2016/03/28 15:36, Gary Kotton wrote:

Hi,
In the M cycle BGP support was added in tree. I have seen specs in the 
L2 GW project for this support too. Are we planning to consolidate the 
efforts? Will the BGP code be moved from the Neutron git to the L2-GW 
project? Will a new project be created?
Sorry, a little in the dark here and it would be nice if someone could 
please provide some clarity here. It would be a pity that there were 
competing efforts and my take would be that the Neutron code would be 
the single source of truth (until we decide otherwise).
I think that the L2-GW project would be a very good place for that 
service code to reside. It can also have MPLS etc. support. So it may 
be a natural fit.

Thanks
Gary


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


__
OpenStack Development Mailing 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]Is it necessary to commit a patch for clearing all deleted members in instance_group_memebers table?

[han . rong3]

https://review.openstack.org/#/c/289392/
 
I want to soft delete member in instance_group_members, when this instance 
is soft delete.
 
But, after this mofication, there is some code which is not comfortable.
https://review.openstack.org/#/c/289392/1/nova/api/openstack/compute/server_groups.py
 
Is it necessary to commit a patch for clearing all deleted members in 
instance_group_memebers table?

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing 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] playing tricircle with two node configuration

[Vega Cai]

Hi Yipei,

Check "network_api_class" and "use_neutron" options in your nova.conf. It
seems that your nova API is not configured to use neutron.

BR
Zhiyuan

On 28 March 2016 at 13:25, Yipei Niu  wrote:

> Hi, all,
>
> After I execute the command "nova boot --flavor 1 --image
> c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
> net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1",
> there exist some problem with the argument port. In t-ngw.log, I find that
> the status of port switches from ACTIVE to DOWN, which is marked as bold
> below. Is it the reason why I failed to boot a VM?
>
> 2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
> -d '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
> "admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> 2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '384',
> 'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
> {"port": {*"status": "ACTIVE"*, "name": "", "admin_state_up": true,
> "network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
> "29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
> "fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
> "2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id":
> "e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
> ^[[00;33mfrom (pid=17537) http_log_resp
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
> 2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
> http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
> python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
> -d '{"port": {"name": "e27dc15d-188f-4d60-a38c-f48052d6330b",
> "admin_state_up": true, "network_id":
> "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id":
> "29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09",
> "fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480",
> "ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
> 2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
> 03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
> 'application/json; charset=UTF-8', 'Content-Length': '808',
> 'X-Openstack-Request-Id': 'req-d286f85c-bc4b-4d7c-9915-666fe13b48b5'}
> {"port": {*"status": "DOWN"*, "binding:host_id": "",
> "allowed_address_pairs": [], "dns_assignment": [{"hostname":
> "host-10-0-8-5", "ip_address": "10.0.8.5", "fqdn":
> "host-10-0-8-5.openstacklocal."}], "device_owner": "", "binding:profile":
> {}, "port_security_enabled": true, "fixed_ips": [{"subnet_id":
> "fd1abd0d-9398-4848-a3cf-57858868a480", "ip_address": "10.0.8.5"}], "id":
> "0bbf77a4-c4e4-43ad-89a0-e55f053ef4da", "security_groups":
> ["16f02958-2a4f-4f58-b560-b9fa76be1b0c"], "device_id": "", "name":
> "e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true,
> "network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "dns_name": "",
> "binding:vif_details": {}, "binding:vnic_type": "normal",
> "binding:vif_type": "unbound", "tenant_id":
> "29a524d386754a94850277afea1e569f", "mac_address":
> "fa:16:3e:11:bd:09"}}^[[00m ^[[00;33mfrom (pid=17537) http_log_resp
> /usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
> 2016-03-28 11:49:44.810 ^[[00;36mINFO eventlet.wsgi.server
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;36m] ^[[01;35m^[[00;36mTraceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line
> 454, in handle_one_response
> result = self.application(self.environ, start_response)
>   File
> "/usr/local/lib/python2.7/dist-packages/pecan/middleware/recursive.py",
> line 56, in __call__
> return self.application(environ, start_response)
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
> __call__
> resp = self.call_func(req, *args, **self.kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
> call_func
> retur