date:20160407

Kevin,

Quick question.
Does one OpenStack infrastructure have to be dedicated for one Jacket instance?

Cheers,
Shinobu


On Thu, Mar 24, 2016 at 8:24 PM, Kevin.ZhangSen  wrote:
> Hi Ghanshyam,
>
> Thank you for your sugesstions, and I agree with your opinion that the
> service outside OpenStack is better. In fact I am considering what API
> Jacket will offer. It is better to offer the OpenStack API directly. But
> there will be a question how to modify as little code as possible to keep
> the same API compatibility with OpenStack after OpenStack updates the API
> version. I think this will be an interesting question, but we can try to let
> Jacket offer the OpenStack API.
>
> The reply about other query is below. If there are any questions, please
> tell me. Thank you again.
>
> Best Regards,
> Kevin (Sen Zhang)
>
> At 2016-03-24 11:58:47, "GHANSHYAM MANN"  wrote:
>>Hi Kevin,
>>
>>Its always nice idea as jacket has but not sure how feasible and
>>valuable it would be. For doing API translation and gateway, there are
>>many available and one I remember is Aviator (based on ruby gem) [1],
>>not sure how active it is now.
>>
>>As your idea is more about consuming all differences between different
>>cloud, few query-
>>
>> 1. Different clouds have very much different API model and feature
>>they provides, how  worth it is to provide missing/different features
>>at jacket layer? its then kind of another layer of cloud layer you
>>will end up.
> Kevin: We will provide the commonly used functions to let the users manage
> the different clouds just like one kind of cloud, for example VMs
> management(create/destroy/start/stop/restart/rebuild...) and volume
> management(create/delete/backup/snapshot). About network, there is a
> solution to use neutron to offer network function through the overlay
> virtual network based on the provider clouds’ virtual network. This will be
> another project, not in Jacket.
>> 2. To support that idea through OpenStack standard API, you need to
>>inserting jacket driver all over the components which end up having
>>another layer gets inserted there. Maintainability of that is another
>>issue for each OpenStack components.
> Kevin: I agree with you. Jacket offer OpenStack will be better.
>>IMO, outside layer (from OpenStack ) which can do all these would be
>>nice something which can redirect API services at top level top and do
>>what all conversion, consume difference etc.
>>
>>[1] https://github.com/aviator/aviator
>>
>>Regards
>>Ghanshyam Mann
>>
>>
>>On Wed, Mar 16, 2016 at 9:58 PM, zs  wrote:
>>> Hi Gordon,
>>>
>>> Thank you for your suggestion.
>>>
>>> I think jacket is different from tricircle. Because tricircle focuses on
>>> OpenStack deployment across multiple sites, but jacket focuses on how to
>>> manage the different clouds just like one cloud.  There are some
>>> differences:
>>> 1. Account management and API model: Tricircle faces multiply OpenStack
>>> instances which can share one Keystone and have the same API model, but
>>> jacket will face the different clouds which have the respective service
>>> and
>>> different API model. For example, VMware vCloud Director has no volume
>>> management like OpenStack and AWS, jacket will offer a fake volume
>>> management for this kind of cloud.
>>> 2. Image management: One image just can run in one cloud, jacket need
>>> consider how to solve this problem.
>>> 3. Flavor management: Different clouds have different flavors which can
>>> not
>>> be operated by users. Jacket will face this problem but there will be no
>>> this problem in tricircle.
>>> 4. Legacy resources adoption: Because of the different API modles, it
>>> will
>>> be a huge challenge for jacket.
>>>
>>> I think it is maybe a good solution that jacket works to unify the API
>>> model
>>> for different clouds, and then using tricircle to offer the management of
>>> a
>>> large scale VMs.
>>>
>>> Best Regards,
>>> Kevin (Sen Zhang)
>>>
>>>
>>> At 2016-03-16 19:51:33, "gordon chung"  wrote:


On 16/03/2016 4:03 AM, zs wrote:
> Hi all,
>
> There is a new project "jacket" to manage multiply clouds. The jacket
> wiki is: https://wiki.openstack.org/wiki/Jacket
>   Please review it and give your comments. Thanks.
>
> Best Regards,
>
> Kevin (Sen Zhang)
>
>

i don't know exact details of either project, but i suggest you
collaborate with tricircle project[1] because it seems you are
addressing the same user story (and in a very similar fashion). not sure
if it's a user story for OpenStack itself, but no point duplicating
 efforts.

[1] https://wiki.openstack.org/wiki/Tricircle

cheers,

--
gord

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

[openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

2016-04-07 Thread Akihiro Motoki

Hi Neutrinos,

As the API Lieutenant of Neutron team,
I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
Neutron core reviewer team mainly focuing on the API/DB area.

Hirofumi has been contributing neutron actively in the recent two
releases constantly.
He was involved in key features in API/DB areas in Mitaka such as
tagging support and network availability zones.
I believe his knowledge and involvement will be great addition to our team.
He have been reviewing constantly [1] and I expect he continue to work
for Newton or later.

Existing API/DB core reviews (and other Neutron core reviewers),
please vote +1/-1 for the addition of Hirofumi to the team.

Thanks!
Akihiro


[1] http://stackalytics.com/report/contribution/neutron/90

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

Re: [openstack-dev] [Congress] Issues with Tox testing

2016-04-07 Thread Anusha Ramineni

Hi Bryan,

tox -epy27 doesn't run tempest tests , that is tests mentioned in
https://github.com/openstack/congress/tree/stable/liberty/contrib/tempest
 ,
it runs only unit tests , tests present in
https://github.com/openstack/congress/tree/stable/liberty/congress/tests .

To run tempest tests, you need to manually copy the files to tempest and
run the tests as mentioned in following readme
https://github.com/openstack/congress/blob/stable/liberty/contrib/tempest/README.rst

Mitaka supports tempest plugin, so manually copying tests to tempest can be
avoided if you are using mitaka.

Hope I clarified your question.


Best Regards,
Anusha

On 8 April 2016 at 08:51, Bryan Sullivan  wrote:

> OK, somehow I did not pick up on that, or dropped it along the way of
> developing the script. Thanks for the clarification, also that Tempest is
> not required. I should have clarified that I'm using stable/liberty as the
> base. I will be moving to stable/mitaka soon, as part of the OPNFV Colorado
> release development.
>
> One additional question then - are the tests run by "tox -epy27" the same
> as the tests in the folder
> https://github.com/openstack/congress/tree/stable/liberty/contrib/tempest?
> If not, how are those tests supposed to be run for a non-devstack deploy (I
> see reference to devstack in the readme)?
>
> I see that the folders have been reorganized for mitaka. My question is
> per the goal to include as much of the Congress tests as possible in the
> OPNFV CI/CD process. Not that I expect any to fail, I just want OPNFV to
> leverage the full test suite. If for liberty that's best left as the tests
> run by the tox command, then that's OK.
>
> Thanks,
> Bryan Sullivan
>
> --
> Date: Thu, 7 Apr 2016 17:11:36 -0700
> From: ekcs.openst...@gmail.com
> To: openstack-dev@lists.openstack.org
>
> Subject: Re: [openstack-dev] [Congress] Issues with Tox testing
>
> Thanks for the feedback, Bryan. Glad you got things working!
>
> 1. The instructions asking to install those packages are missing from kilo
> (we’ll fix that), but they have been there since liberty. Was it perhaps
> unclear because the line is too long?
>
>-
>
>Additionally:
>
>$ sudo apt-get install git gcc python-dev libxml2 libxslt1-dev libzip-dev 
> mysql-server python-mysqldb build-essential libssl-dev libffi-dev
>
>
> 2. Tempest should not be required by the tox tests.
>
> Thanks!
>
> From: Bryan Sullivan 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, April 7, 2016 at 4:29 PM
> To: "openstack-dev@lists.openstack.org"  >
> Subject: Re: [openstack-dev] [Congress] Issues with Tox testing
>
> An update: I found that there were two dependencies needed that were not
> clear in the guide at https://github.com/openstack/congress. I also
> installed Tempest which was not referenced before. If these additions are
> correct (they worked for me), they should be added to
> https://github.com/openstack/congress/blob/master/README.rst.
>
> $ sudo apt-get install libffi-dev libssl-dev
> $ cd ~/git
> $ git clone https://github.com/openstack/tempest/
> $ cd tempest
> $ ~/git/congress/bin/pip install -r requirements.txt
> $ ~/git/congress/bin/pip install .
>
> (not sure if both pip commands are needed - I'm not an expert on pip
> install)
>
> After that, "tox -epy27" ran thru fine:
>
> ---
> ---
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy_with_dashes
> 27.623
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy
> 27.212
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_simulate_latency
> 1.325
> congress.tests.dse.test_dse.TestDSE.test_policy_tables
> 1.229
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_select_100matches
> 1.184
> congress.tests.test_congress.TestCongress.test_policy_execute
> 1.127
> congress.tests.test_congress.TestCongress.test_datasource_api_model_execute
> 1.067
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_update_nonrecursive
> 0.967
> congress.tests.dse.test_dse.TestDSE.test_policy_table_publish
> 0.681
> congress.tests.datasources.test_neutron_driver.TestDataSourceDriver.test_poll_subscribe
> 0.671
> __ summary
> ___
>   py27: commands succeeded
>   congratulations :)
>
>
>
> Thanks,
> Bryan Sullivan
>
> --
> From: bls...@hotmail.com
> To: openstack-dev@lists.openstack.org
> Date: Thu, 7 Apr 2016 11:16:48 -0700
> Subject:

Re: [openstack-dev] [Congress] Issues with Tox testing

OK, somehow I did not pick up on that, or dropped it along the way of 
developing the script. Thanks for the clarification, also that Tempest is not 
required. I should have clarified that I'm using stable/liberty as the base. I 
will be moving to stable/mitaka soon, as part of the OPNFV Colorado release 
development.

One additional question then - are the tests run by "tox -epy27" the same as 
the tests in the folder 
https://github.com/openstack/congress/tree/stable/liberty/contrib/tempest? If 
not, how are those tests supposed to be run for a non-devstack deploy (I see 
reference to devstack in the readme)?

I see that the folders have been reorganized for mitaka. My question is per the 
goal to include as much of the Congress tests as possible in the OPNFV CI/CD 
process. Not that I expect any to fail, I just want OPNFV to leverage the full 
test suite. If for liberty that's best left as the tests run by the tox 
command, then that's OK.

Thanks,
Bryan Sullivan

Date: Thu, 7 Apr 2016 17:11:36 -0700
From: ekcs.openst...@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Congress] Issues with Tox testing

Thanks for the feedback, Bryan. Glad you got things working!
1. The instructions asking to install those packages are missing from kilo 
(we’ll fix that), but they have been there since liberty. Was it perhaps 
unclear because the line is too long?Additionally:$ sudo apt-get install git 
gcc python-dev libxml2 libxslt1-dev libzip-dev mysql-server python-mysqldb 
build-essential libssl-dev libffi-dev2. Tempest should not be required by the 
tox tests.
Thanks!
From:  Bryan Sullivan 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)" 

Date:  Thursday, April 7, 2016 at 4:29 PM
To:  "openstack-dev@lists.openstack.org" 
Subject:  Re: [openstack-dev] [Congress] Issues with Tox testing

An update: I found that there were two dependencies needed that were not clear 
in the guide at https://github.com/openstack/congress. I also installed Tempest 
which was not referenced before. If these additions are correct (they worked 
for me), they should be added to 
https://github.com/openstack/congress/blob/master/README.rst.

$ sudo apt-get install libffi-dev libssl-dev
$ cd ~/git
$ git clone https://github.com/openstack/tempest/
$ cd tempest
$ ~/git/congress/bin/pip install -r requirements.txt
$ ~/git/congress/bin/pip install .

(not sure if both pip commands are needed - I'm not an expert on pip install)

After that, "tox -epy27" ran thru fine:

---
  ---
congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy_with_dashes
   27.623
congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy
   27.212
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_simulate_latency
  1.325
congress.tests.dse.test_dse.TestDSE.test_policy_tables  
  1.229
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_select_100matches
 1.184
congress.tests.test_congress.TestCongress.test_policy_execute   
  1.127
congress.tests.test_congress.TestCongress.test_datasource_api_model_execute 
  1.067
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_update_nonrecursive
   0.967
congress.tests.dse.test_dse.TestDSE.test_policy_table_publish   
  0.681
congress.tests.datasources.test_neutron_driver.TestDataSourceDriver.test_poll_subscribe
   0.671
__ summary 
___
  py27: commands succeeded
  congratulations :)


Thanks,
Bryan Sullivan

From: bls...@hotmail.com
To: openstack-dev@lists.openstack.org
Date: Thu, 7 Apr 2016 11:16:48 -0700
Subject: [openstack-dev] [Congress] Issues with Tox testing

Hi Congress team, 

A question for tox testing expert on the Congress team. I'm trying to run the 
tox tests as described at https://github.com/openstack/congress, specifically 
the two commands:

$ sudo pip install 'tox<1.7'

$ tox -epy27 



Due to conflicts with the OS-owned python config, I run these under my 
virtualenv created in the congress repo as:
$ cd ~/git/congress
$ bin/pip  install 'tox<1.7'
$ bin/tox -epy27


But in any event (whether I try to run the tox within the virtualenv or not), I 
get errors such as:
  c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory



What's missing in the setup for running these tests? 



Note that I have all the config needed to run bash/CLI-based test scripts such 
as

Re: [openstack-dev] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

2016-04-07 Thread Hirofumi Ichihara




On 2016/04/08 12:10, Kevin Benton wrote:

Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e

I tried. Let's wait for the result.




On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu > wrote:




> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com
]
> Sent: April-07-16 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> object has no attribute 'strftime'
>
> Hongbin Lu > wrote:
>
> > Hi all,
> > Magnum gate recently broke with error: “AttributeError: 'str'
object
> > has no attribute 'strftime'” (here is a full log [1]). I would
like
> to
> > confirm if there is a recent commit in Neutron that causes the
> breakage.
> > If yes, a quick fix is greatly appreciated.
> >
> > [1]
> > http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-
> magnu
> > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> >
>
> The fix should be: https://review.openstack.org/#/c/302904/

This patch doesn't resolve the problem. I depends on the patch and
re-ran the tests [1], but the tests still failed with the same
error [2].

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

http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-magnum-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027

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

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 29 March 2016 at 20:43, Vikram Choudhary  wrote:

> Hi Armando,
>
> We want to add the support for a new ML2 driver. Can you please guide what
> is the step moving forward?
>
> Thanks
> Vikram
>

Vikram,

Apologies for the late reply, the Mitaka release tasks took precedence and
I did not have the time to fully resume this effort though it's my
intention to come back to it in the next few days. To start with, I resumed
[1,2] to reflect the team decision made in [3]. Now that Newton has
started, and other repos of the same nature are available in openstack.org,
it makes sense to give power back to the individual teams to be fully in
charge of release and backport duties. Some of these projects were already
released as indicated in [4], and I'll work with the openstack release team
to clarify next steps for those that have not.

Thanks,
Armando

[1] https://review.openstack.org/#/c/303026/
[2] https://review.openstack.org/#/c/303039/
[3] https://review.openstack.org/#/c/276461/
[4]
https://github.com/openstack/releases/tree/master/deliverables/_independent



>
>
> On Fri, Mar 4, 2016 at 12:39 AM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Status update on this matter:
>>
>> Russell, Kyle and I had a number of patches out [1], to try and converge
>> on how to better organize Neutron-related efforts. As a result, a number of
>> patches merged and a number of patches are still pending. Because of Mitaka
>> feature freeze, other initiatives too priority.
>>
>> That said, some people rightly wonder what's the latest outcome of the
>> discussion. Bottom line: we are still figuring this out. For now the
>> marching order is unchanged: as far as Mitaka is concerned, things stay as
>> they were, and new submissions for inclusion are still frozen. I aim (with
>> or without the help of the new PTL) to get to a final resolution by or
>> shortly after the Mitaka release [2].
>>
>> Please be patient and stay focussed on delivering a great Mitaka
>> experience!
>>
>> Cheers,
>> Armando
>>
>> [1]
>> https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
>> [2] http://releases.openstack.org/mitaka/schedule.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

2016-04-07 Thread Kevin Benton

Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e

On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu  wrote:

>
>
> > -Original Message-
> > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> > Sent: April-07-16 12:04 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> > object has no attribute 'strftime'
> >
> > Hongbin Lu  wrote:
> >
> > > Hi all,
> > > Magnum gate recently broke with error: “AttributeError: 'str' object
> > > has no attribute 'strftime'” (here is a full log [1]). I would like
> > to
> > > confirm if there is a recent commit in Neutron that causes the
> > breakage.
> > > If yes, a quick fix is greatly appreciated.
> > >
> > > [1]
> > > http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-
> > magnu
> > > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> > >
> >
> > The fix should be: https://review.openstack.org/#/c/302904/
>
> This patch doesn't resolve the problem. I depends on the patch and re-ran
> the tests [1], but the tests still failed with the same error [2].
>
> [1] https://review.openstack.org/#/c/303179/
> [2]
> http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-magnum-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027
>
> >
> > Ihar
> >
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

2016-04-07 Thread Hongbin Lu



> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: April-07-16 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> object has no attribute 'strftime'
> 
> Hongbin Lu  wrote:
> 
> > Hi all,
> > Magnum gate recently broke with error: “AttributeError: 'str' object
> > has no attribute 'strftime'” (here is a full log [1]). I would like
> to
> > confirm if there is a recent commit in Neutron that causes the
> breakage.
> > If yes, a quick fix is greatly appreciated.
> >
> > [1]
> > http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-
> magnu
> > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> >
> 
> The fix should be: https://review.openstack.org/#/c/302904/

This patch doesn't resolve the problem. I depends on the patch and re-ran the 
tests [1], but the tests still failed with the same error [2].

[1] https://review.openstack.org/#/c/303179/
[2] 
http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-magnum-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027

> 
> Ihar
> 
> ___
> ___
> OpenStack Development Mailing 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] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

2016-04-07 Thread Zhenguo Niu

definitely +1

On Fri, Apr 8, 2016 at 12:42 AM, Brad Pokorny 
wrote:

> +1. I think Rob will provide good input for stable.
>
> Thanks,
> Brad
>
> From: Timur Sufiev 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, April 7, 2016 at 4:31 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell
> for Horizon stable core
>
> +1
> Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia :
>
>> Im still not sure if non-cores (i.e. peasants like me) can vote but I
>> will do it anyway :D
>>
>> A big +1 from me.
>>
>> Itxaka
>>
>> On 04/07/2016 12:01 PM, Matthias Runge wrote:
>> > Hello,
>> >
>> > I'm proposing Rob Cresswell to become stable core for Horizon. I
>> > thought, in the past all PTL were in stable team, but this doesn't seem
>> > to be true any more.
>> >
>> > Please chime in with +1/-1
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

2016-04-07 Thread taget


hi hongbin & team.

Thanks for all your supporting, Magnum core team and the community, I am 
very glad to have this opportunity
to join this team. I will try my best to contribute Magnum team and 
OpenStack community.


Thanks
Eli.

On 2016年04月08日 03:35, Hongbin Lu wrote:


Hi all,

Thanks for your feedback. The vote is unanimous. Eli Qiao has been 
added to the core team [1].


[1] https://review.openstack.org/#/admin/groups/473,members

Best regards,

Hongbin



--
Best Regards, Eli Qiao (乔立勇)

__
OpenStack Development Mailing 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][elections] Results of the TC Election

2016-04-07 Thread Anita Kuno

On 04/07/2016 08:51 PM, Tony Breeds wrote:
> On Fri, Apr 08, 2016 at 10:03:11AM +1000, Tony Breeds wrote:
>> Please join me in congratulating the 7 newly elected members of the TC.
>>
>> << REMOVE UNEEDED >
> 
> *sigh*, clearly this was a templating error and no reflection on the fine
> community members and friends that were *not* elected to the TC.
> 
> I apologise unreservedly for any offense I have caused.
> 
> Yours Tony.
> 
> 
> 
> __
> OpenStack Development Mailing 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 picture you being held upside down outside a window in a brick
building as you say/type this.

As one of the UNEEDED, I accept your apology, Tony. :)

Thank you to you and Tristan for completing another fine election
season. Thank you to Spencer Krum for generating the electoral rolls.

Thank you to all candidates who put themselves forward, thank you to all
folks stepping down and congratulations to all members with a seat.

Should be a great session.

Thank you,
Anita.



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

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-07 Thread Tony Breeds

On Fri, Apr 08, 2016 at 10:03:11AM +1000, Tony Breeds wrote:
> Please join me in congratulating the 7 newly elected members of the TC.
> 
> << REMOVE UNEEDED >

*sigh*, clearly this was a templating error and no reflection on the fine
community members and friends that were *not* elected to the TC.

I apologise unreservedly for any offense I have caused.

Yours Tony.

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

[openstack-dev] [tricircle]dynamic pod binding discussion

Hello, team,

As scheduled in the weekly meeting, we will have a meeting to discuss “dynamic 
pod binding” at 
#openstack-tricircle(http://webchat.freenode.net/?channels=openstack-tricircle) 
at UTC 1:00 (Beijing time 9:00am) Apr.8.

The etherpad for discussion is: 
https://etherpad.openstack.org/p/TricircleDynamicPodBinding

The dynamic pod binding is used in the large scale cloud, and asked by 
production public cloud. The use cases could be found in  
https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit?usp=sharing,
 the second use cases.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 李戈 [mailto:lgmcglm...@126.com]
Sent: Tuesday, April 05, 2016 11:41 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle] Hello

Hello Team，
  I am lige, a openstack coder in China UnionPay and glad to join our team.

   thx.



__
OpenStack Development Mailing 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] [Glance] Newton virtual pre-summit sync

2016-04-07 Thread Flavio Percoco

On Apr 7, 2016 2:28 PM, "Nikhil Komawar"  wrote:
>
> Hi Flavio,
>
> Thank you for responding.
>
> Will it be still possible to do this sync on your bridge? I agree, it
> worked pretty well the last time and would save us time on setting up
> something new too.

Hey,

Yes,  we can use my bridge. I'll send an invite soon and open it.

Cheers,
Flavio

>
> On 4/1/16 8:56 AM, Flavio Percoco wrote:
> > On 31/03/16 17:34 -0400, Nikhil Komawar wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> I'm excited to see you all Glancers at the Austin summit and discuss
> >>
> >> more on our project.
> >>
> >>
> >>
> >> Nevertheless, I feel that our summit conversations will have a lot more
> >>
> >> value if we establish some prior-context to the discussions and prepare
> >>
> >> ourselves for some of the sessions. Hence, I would like to call for a
> >>
> >> virtual sync meetup on the week of April 11th.
> >>
> >>
> >>
> >> My initial plan is to have a 4 hour sync on Tuesday April 12th, from
> >>
> >> 1400-1800 UTC (we can decide on the length of the sessions and the
> >>
> >> required breaks later). But sending out this tentative plan to gauge
the
> >>
> >> feasibility and interest.
> >>
> >
> >
> > Happy to join!
> >
> >
> >
> >> Please reply to this thread with your thoughts. If none, looking
forward
> >>
> >> to seeing you at the event.
> >>
> >>
> >>
> >> P.S. based on the number of interested participants we can decide on
the
> >>
> >> tool to be used.
> >>
> >
> >
> >
> >
> > We can use my bluejeans bridge. It work fairly well for the virtual
> > mid-cycle we
> >
> > did a couple of months ago.
> >
> >
> >
> > Flavio
> >
> >
> >
> >
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
>
> Thanks,
> Nikhil
>
>
__
OpenStack Development Mailing 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][elections] Results of the TC Election

2016-04-07 Thread Robert Collins

Congrats everyone!

-Rob

On 8 April 2016 at 12:03, Tony Breeds  wrote:
> Please join me in congratulating the 7 newly elected members of the TC.
>
> << REMOVE UNEEDED >
> * Davanum Srinivas (dims)
> * Flavio Percoco (flaper87)
> * John Garbutt (johnthetubaguy)
> * Matthew Treinish (mtreinish)
> * Mike Perez (thingee)
> * Morgan Fainberg (morgan)/(notmorgan)
> * Thierry Carrez (ttx)
>
> Full results: 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
>
> Thank you to all candidates who stood for election, having a good group of
> candidates helps engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to 
> ensure
> your voice is heard.
>
> Thank you for another great round.
>
> Here's to Newton!
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Congress] Issues with Tox testing

2016-04-07 Thread Eric K

Thanks for the feedback, Bryan. Glad you got things working!

1. The instructions asking to install those packages are missing from kilo
(we¹ll fix that), but they have been there since liberty. Was it perhaps
unclear because the line is too long?
* Additionally:
* $ sudo apt-get install git gcc python-dev libxml2 libxslt1-dev libzip-dev
mysql-server python-mysqldb build-essential libssl-dev libffi-dev
2. Tempest should not be required by the tox tests.

Thanks!

From:  Bryan Sullivan 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Thursday, April 7, 2016 at 4:29 PM
To:  "openstack-dev@lists.openstack.org" 
Subject:  Re: [openstack-dev] [Congress] Issues with Tox testing

> An update: I found that there were two dependencies needed that were not clear
> in the guide at https://github.com/openstack/congress. I also installed
> Tempest which was not referenced before. If these additions are correct (they
> worked for me), they should be added to
> https://github.com/openstack/congress/blob/master/README.rst.
> 
> $ sudo apt-get install libffi-dev libssl-dev
> $ cd ~/git
> $ git clone https://github.com/openstack/tempest/
> $ cd tempest
> $ ~/git/congress/bin/pip install -r requirements.txt
> $ ~/git/congress/bin/pip install .
> 
> (not sure if both pip commands are needed - I'm not an expert on pip install)
> 
> After that, "tox -epy27" ran thru fine:
> 
> --
> -  ---
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_se
> t_policy_with_dashes   27.623
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_se
> t_policy   27.212
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_simulate_latency  1.325
> congress.tests.dse.test_dse.TestDSE.test_policy_tables
> 1.229
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_select_100matches 1.184
> congress.tests.test_congress.TestCongress.test_policy_execute
> 1.127
> congress.tests.test_congress.TestCongress.test_datasource_api_model_execute
> 1.067
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_update_nonrecursive   0.967
> congress.tests.dse.test_dse.TestDSE.test_policy_table_publish
> 0.681
> congress.tests.datasources.test_neutron_driver.TestDataSourceDriver.test_poll_
> subscribe   0.671
> __ summary
> ___
>   py27: commands succeeded
>   congratulations :)
> 
> 
> 
> Thanks,
> Bryan Sullivan
> 
> 
> From: bls...@hotmail.com
> To: openstack-dev@lists.openstack.org
> Date: Thu, 7 Apr 2016 11:16:48 -0700
> Subject: [openstack-dev] [Congress] Issues with Tox testing
> 
> Hi Congress team,
> 
> A question for tox testing expert on the Congress team. I'm trying to run the
> tox tests as described at https://github.com/openstack/congress, specifically
> the two commands:
> 
> $ sudo pip install 'tox<1.7' $ tox -epy27
> 
> 
> 
> Due to conflicts with the OS-owned python config, I run these under my
> virtualenv created in the congress repo as:
> $ cd ~/git/congress
> $ bin/pip  install 'tox<1.7'
> $ bin/tox -epy27
> 
> 
> But in any event (whether I try to run the tox within the virtualenv or not),
> I get errors such as:
>   c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
> 
> 
> 
> What's missing in the setup for running these tests?
> 
> 
> 
> Note that I have all the config needed to run bash/CLI-based test scripts such
> as https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh
> 
> 
> 
> Thanks,
> Bryan Sullivan   
> 
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [all][elections] Results of the TC Election

2016-04-07 Thread Tony Breeds

Please join me in congratulating the 7 newly elected members of the TC.

<< REMOVE UNEEDED >
* Davanum Srinivas (dims)
* Flavio Percoco (flaper87)
* John Garbutt (johnthetubaguy)
* Matthew Treinish (mtreinish)
* Mike Perez (thingee)
* Morgan Fainberg (morgan)/(notmorgan)
* Thierry Carrez (ttx)

Full results: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a

Thank you to all candidates who stood for election, having a good group of
candidates helps engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We need to ensure
your voice is heard.

Thank you for another great round.

Here's to Newton!

Yours Tony.


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

Re: [openstack-dev] [Neutron] Newton blueprints call for action

Folks, thanks to everyone who has replied to the the thread. Much
appreciated it.

I'll reach out individually to figure out next steps and come back here to
provide a status update.

Cheers,
Armando

On 6 April 2016 at 07:17, Brent Eagles  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Armando,
>
> On 05/04/16 01:13 AM, Armando M. wrote:
> > Hi Neutrinos,
> >
> > During today's team meeting [0], we went through the current
> > milestone workload [1].
> >
> > This is mostly made of Mitaka backlog items, amongst which we
> > discussed two blueprints [2, 3]. These two efforts had their spec
> > approved during the Mitaka timeframe, but code lagged behind, and
> > hence got deferred [4].
> >
> > I would like to understand if these need new owners (both assignees
> > and approvers). Code submitted [5,6] has not been touched in a
> > while, and whilst I appreciate people have been busy focussing on
> > Mitaka (myself included), the Newton master branch has been open
> > for a while.
> >
> > With this email I would like to appeal to the people in CC to
> > report back their interest in continuing working on these items in
> > their respective capacities, and/or the wider community, in case
> > new owners need to be identified.
> >
> > I look forward to hearing back, hoping we can find the right
> > resources to resume progress, and bring these important
> > requirements to completion in time for Newton.
> >
> > Many thanks, Armando
>
> As it happens, I've been tasked to work on TripleO as a general
> contributor with a networking focus. For better or worse, the database
> related work was the only thing on my early radar and I will shepherd
> that along as needed, but I won't be able to commit to the larger bits
> of the remaining work.
>
> While we could wait for summit to hand off, I think it would be better
> for someone who is looking to take over ownership of all or some of
> the pieces to sync up with Bence, myself, and Songming ASAP.
>
> Cheers,
>
> Brent
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJXBRpyAAoJEIXWptqvFlBWIHgQAL3e+HjvDXvziee1oLfkz/kT
> DIghPQoqZg+oLJYmezoa4ixzNY53pE/EtkTxCtXrmEfbvwCqNWkgNWqTKm4nGe1J
> Uv1HFpdrUtg9j7bS9bIPRKQKaWr9nkNUJZPL5fjIs467WWQP0e6YbigVgoJQRYXi
> t/o5ZKgRKp8DOW+bqjXvQvM69WXq9iyH7KmjVfbJ2o3NeoFOmPTlXtAunbp33xj4
> 6MuFH4USJZS11x0IgIiaCZHJS+RWfDdxI+4ONCqQ1lYkrLp9wl8XNznQzum60wFU
> jhjJcaRtfdbMHmRd72//QVeIlX9VA6b5q36a/adPxbKrD2XTd4pntJ86dnU0aQFJ
> sriJRk3KlD0IMDMS+rRsKz7EyJJP+9b5zlWCzX0V+1zNlcB6eiowOmo3QUQrFBQT
> O50KS9YC7ef0EMWE6kikxyK8AxZ1Hjcm3eM50mShU+eCI/JPgkHeRQX+Z16RBybj
> xhEBgRIvLS7bH8c6vqjIgmLQ1zxQ3EPR440Zpi0rw3rChP/lugYYQpcjXDfVFWED
> gwe+RQvevj4tJeVjXG662DMuzmjy/cM2nNLZm3AZsaASkR73/M+Qmy53Y22T+T2o
> VVcbOsK2+1Y8JFAVZguUib9pQ/z8DgBKs4+rfWiV4mzBAGwVIxePiNDiQ1kQU/Z0
> 3kUfgrNS0CgmE/nmg05x
> =7kzU
> -END PGP SIGNATURE-
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Issues with Tox testing

Thanks Clark, I found the same thing upon searching the issue, and replied to 
my post with the set of things I had to do to get this working.
Thanks,
Bryan Sullivan

> From: cboy...@sapwetik.org
> To: openstack-dev@lists.openstack.org
> Date: Thu, 7 Apr 2016 12:19:56 -0700
> Subject: Re: [openstack-dev] [Congress] Issues with Tox testing
> 
> On Thu, Apr 7, 2016, at 11:16 AM, Bryan Sullivan wrote:
> > Hi Congress team, 
> > 
> > A question for tox testing expert on the Congress team. I'm trying to run
> > the tox tests as described at https://github.com/openstack/congress,
> > specifically the two commands:
> > 
> > $ sudo pip install 'tox<1.7'
> > 
> > $ tox -epy27 
> > 
> > 
> > 
> > Due to conflicts with the OS-owned python config, I run these under my
> > virtualenv created in the congress repo as:
> > $ cd ~/git/congress
> > $ bin/pip  install 'tox<1.7'
> > $ bin/tox -epy27
> > 
> > 
> > But in any event (whether I try to run the tox within the virtualenv or
> > not), I get errors such as:
> >   c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
> > 
> > 
> > 
> > What's missing in the setup for running these tests? 
> 
> This indicates you do not have the libffi development headers installed
> on your system. On debuntu they come in the libffi-dev package.
> 
> Clark
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Issues with Tox testing

An update: I found that there were two dependencies needed that were not clear 
in the guide at https://github.com/openstack/congress. I also installed Tempest 
which was not referenced before. If these additions are correct (they worked 
for me), they should be added to 
https://github.com/openstack/congress/blob/master/README.rst.

$ sudo apt-get install libffi-dev libssl-dev
$ cd ~/git
$ git clone https://github.com/openstack/tempest/
$ cd tempest
$ ~/git/congress/bin/pip install -r requirements.txt
$ ~/git/congress/bin/pip install .

(not sure if both pip commands are needed - I'm not an expert on pip install)

After that, "tox -epy27" ran thru fine:

---
  ---
congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy_with_dashes
   27.623
congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_set_policy
   27.212
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_simulate_latency
  1.325
congress.tests.dse.test_dse.TestDSE.test_policy_tables  
  1.229
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_select_100matches
 1.184
congress.tests.test_congress.TestCongress.test_policy_execute   
  1.127
congress.tests.test_congress.TestCongress.test_datasource_api_model_execute 
  1.067
congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance.test_update_nonrecursive
   0.967
congress.tests.dse.test_dse.TestDSE.test_policy_table_publish   
  0.681
congress.tests.datasources.test_neutron_driver.TestDataSourceDriver.test_poll_subscribe
   0.671
__ summary 
___
  py27: commands succeeded
  congratulations :)


Thanks,
Bryan Sullivan

From: bls...@hotmail.com
To: openstack-dev@lists.openstack.org
Date: Thu, 7 Apr 2016 11:16:48 -0700
Subject: [openstack-dev] [Congress] Issues with Tox testing




Hi Congress team, 

A question for tox testing expert on the Congress team. I'm trying to run the 
tox tests as described at https://github.com/openstack/congress, specifically 
the two commands:

$ sudo pip install 'tox<1.7'

$ tox -epy27 



Due to conflicts with the OS-owned python config, I run these under my 
virtualenv created in the congress repo as:
$ cd ~/git/congress
$ bin/pip  install 'tox<1.7'
$ bin/tox -epy27


But in any event (whether I try to run the tox within the virtualenv or not), I 
get errors such as:
  c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory



What's missing in the setup for running these tests? 



Note that I have all the config needed to run bash/CLI-based test scripts such 
as https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh 



Thanks,
Bryan Sullivan

__
OpenStack Development Mailing 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] [release][stable][telemetry] ceilometer-powervm 2.0.0 release (mitaka)

We are excited to announce the release of:

ceilometer-powervm 2.0.0: PowerVM Ceilometer Inspector for OpenStack
Ceilometer.

This release is part of the mitaka stable release series.

For more details, please see below.

Changes in ceilometer-powervm 1.0.0rc1..2.0.0
-

2cc735e Update comments to accurately describe actions
c2a7ec7 Include setuptools version
5d5f7ac Fix typos in inspector
dafcfb7 Deprecated tox -downloadcache option removed
a3bc6df Ignoring .idea workdir used by PyCharm IDE
2bb305d Port over pretty_tox.sh from nova-powervm
c44c1e9 Update requirements
bab0d28 Mock pypowervm out of test_inspector
77724ac Update flake8 rules
528675c Do not error if NovaLink not installed
8e1651b Replace deprecated library function os.popen() with subprocess
936773d Change LOG.warn to LOG.warning
c330518 Disable installing pypowervm by default
7f05a97 Add compute monitors config to devstack plugins
f565a2b Add ceilometer-powervm devstack multi-node support
dda22a6 Change pypowervm repo location
a5c8f66 Switch to develop branch for pypowervm
24dfec6 Add base devstack plugins support
21ba3de Add ceilometer-powervm translation domain
a94aad7 Translation changes for drop2
54d9cf1 Translation changes for other languages

Diffstat (except docs and test files)
-

.gitignore |   1 +
README.rst |   4 +-
ceilometer_powervm/compute/virt/powervm/i18n.py|  25 
.../compute/virt/powervm/inspector.py  |  16 +--
.../locale/de/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/de/ceilometer-powervm-log-error.po  |  19 +++
.../locale/de/ceilometer-powervm-log-info.po   |  19 +++
.../locale/de/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/de/ceilometer-powervm.po |  39 +++
.../locale/es/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/es/ceilometer-powervm-log-error.po  |  19 +++
.../locale/es/ceilometer-powervm-log-info.po   |  19 +++
.../locale/es/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/es/ceilometer-powervm.po |  39 +++
.../locale/fr/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/fr/ceilometer-powervm-log-error.po  |  19 +++
.../locale/fr/ceilometer-powervm-log-info.po   |  19 +++
.../locale/fr/ceilometer-powervm-log-warning.po|  29 +
ceilometer_powervm/locale/fr/ceilometer-powervm.po |  39 +++
.../locale/it/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/it/ceilometer-powervm-log-error.po  |  19 +++
.../locale/it/ceilometer-powervm-log-info.po   |  19 +++
.../locale/it/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/it/ceilometer-powervm.po |  39 +++
.../locale/ja/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/ja/ceilometer-powervm-log-error.po  |  19 +++
.../locale/ja/ceilometer-powervm-log-info.po   |  19 +++
.../locale/ja/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/ja/ceilometer-powervm.po |  39 +++
.../locale/ko/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/ko/ceilometer-powervm-log-error.po  |  19 +++
.../locale/ko/ceilometer-powervm-log-info.po   |  19 +++
.../locale/ko/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/ko/ceilometer-powervm.po |  39 +++
.../pt-BR/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/pt-BR/ceilometer-powervm-log-error.po   |  19 +++
.../locale/pt-BR/ceilometer-powervm-log-info.po|  19 +++
.../locale/pt-BR/ceilometer-powervm-log-warning.po |  28 +
.../locale/pt-BR/ceilometer-powervm.po |  39 +++
.../locale/ru/ceilometer-powervm-log-critical.po   |  19 +++
.../locale/ru/ceilometer-powervm-log-error.po  |  19 +++
.../locale/ru/ceilometer-powervm-log-info.po   |  19 +++
.../locale/ru/ceilometer-powervm-log-warning.po|  28 +
ceilometer_powervm/locale/ru/ceilometer-powervm.po |  39 +++
.../zh-Hans/ceilometer-powervm-log-critical.po |  19 +++
.../locale/zh-Hans/ceilometer-powervm-log-error.po |  19 +++
.../locale/zh-Hans/ceilometer-powervm-log-info.po  |  19 +++
.../zh-Hans/ceilometer-powervm-log-warning.po  |  28 +
.../locale/zh-Hans/ceilometer-powervm.po   |  39 +++
.../zh-Hant/ceilometer-powervm-log-critical.po |  19 +++
.../locale/zh-Hant/ceilometer-powervm-log-error.po |  19 +++
.../locale/zh-Hant/ceilometer-powervm-log-info.po  |  19 +++
.../zh-Hant/ceilometer-powervm-log-warning.po  |  28 +
.../locale/zh-Hant/ceilometer-powervm.po   |  39 +++
devstack/README.rst|  27 +
devstack/plugin.sh | 127 +
devstack/powervm-functions.sh  |  55 +
devstack/settings  |  13 +++
requirements.txt

[openstack-dev] [release][stable] nova_powervm 2.0.0 release (mitaka)

We are thrilled to announce the release of:

nova_powervm 2.0.0: PowerVM driver for OpenStack Nova.

This release is part of the mitaka stable release series.

For more details, please see below.

Changes in nova_powervm 2.0.0.0rc1..2.0.0
-

cde3fee Conductor changes to register nova-powervm objects
f1f25e7 Increase SCSI bus scan timeout from 10s to 5min
c55b6ec Enable simplified remote restart by default for the vm

Diffstat (except docs and test files)
-

README.rst   | 25 +++
nova_powervm/cmd/__init__.py |  0
nova_powervm/cmd/conductor.py| 31 
nova_powervm/virt/powervm/mgmt.py|  7 +++---
nova_powervm/virt/powervm/vm.py  |  8 ---
setup.cfg|  2 ++
10 files changed, 136 insertions(+), 16 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] [oslo] oslo.context and name fields

2016-04-07 Thread Ronald Bradford

Sean,

I've taken your WIP https://review.openstack.org/#/c/302744/ a step forward
and its in review now.
I'd value Jamie's input on your proposed from_environ signature change to
see if that does meet his indented goal.

Regards

Ronald



Ronald Bradford

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


On Tue, Apr 5, 2016 at 9:53 PM, Jamie Lennox  wrote:

> from_environ was mine, it's reasonably new and at the time i was blocked
> upon getting a release before pushing it out to services. Since then i've
> been distracted with other things. The intent at the time was exactly this
> to standardize the values on the context object, though in my case i was
> particularly interested with how we could handle authentication plugins.
>
> The problems i hit were specifically around how we could seperate values
> that were relevant to things like policy from values that were relevant for
> RPC etc rather that the big to_dict that is used for everything at the
> moment.
>
> There were a number of problems with this, however nothing that would
> prevent more standardization of the base attributes and using from_environ
> now.
>
>
> On 6 April 2016 at 07:39, Ronald Bradford  wrote:
>
>> I have created a version that use constructor arguments. [5]
>> I will review in more detail across projects the use of keystone
>> middleware to see if we can utilize a constructor environment attribute to
>> simply constructor usage.
>>
>> [5] https://review.openstack.org/301918
>>
>> Ronald Bradford
>>
>> Web Site: http://ronaldbradford.com
>> LinkedIn:  http://www.linkedin.com/in/ronaldbradford
>> Twitter:@RonaldBradford 
>> Skype: RonaldBradford
>> GTalk: Ronald.Bradford
>> IRC: rbradfor
>>
>>
>> On Tue, Apr 5, 2016 at 3:49 PM, Sean Dague  wrote:
>>
>>> Cool. Great.
>>>
>>> In looking at this code a bit more I think we're missing out on some
>>> commonality by the fact that this nice bit of common parsing -
>>>
>>> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161
>>> is actually hidden behind a factory pattern, and not used by anyone in
>>> OpenStack -
>>> http://codesearch.openstack.org/?q=from_environ=nope==
>>>
>>> If instead of standardizing the args to the context constructor, we
>>> could remove a bunch of them and extract that data from a passed
>>> environment during the constructor that should remove a bunch of parsing
>>> code in every project. It would also mean that we could easily add
>>> things like project_name and user_name in, and they would be available
>>> to all consumers.
>>>
>>> -Sean
>>>
>>> On 04/05/2016 03:39 PM, Ronald Bradford wrote:
>>> > Sean,
>>> >
>>> > I cannot speak to historically why there were not there, but I am
>>> > working through the app-agnostic-logging-parameters blueprint [1] right
>>> > now and it's very related to this.  As part of this work I would be
>>> > reviewing attributes that are more commonly used in subclassed context
>>> > objects for inclusion into the base oslo.context class, a step before a
>>> > more kwargs init() approach that many subclassed context object
>>> utilize now.
>>> >
>>> > I am also proposing the standardization of context arguments [2]
>>> > (specifically ids), and names are not mentioned but I would like to
>>> > follow the proposed convention.
>>> >
>>> > However, as you point out in the middleware [3], if the information is
>>> > already available I see no reason not to facilite the base oslo.context
>>> > class to consume this for subsequent use by logging.  FYI the
>>> > get_logging_values() work in [4] is specially to add logging only
>>> values
>>> > and this can be the first use case.
>>> >
>>> > While devstack uses these logging format string options, the defaults
>>> > (which I presume are operator centric do not).  One of my goals of the
>>> > Austin Ops summit it to get to talk with actual operators and find out
>>> > what is really in use.   Regardless, the capacity to choose should be
>>> > available when possible if the information is already identified
>>> without
>>> > subsequent lookup.
>>> >
>>> >
>>> > Ronald
>>> >
>>> >
>>> > [1]
>>> https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
>>> > [2] https://review.openstack.org/#/c/290907/
>>> > [3]
>>> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
>>> > [4] https://review.openstack.org/#/c/274186/
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Apr 5, 2016 at 2:31 PM, Sean Dague >> > > wrote:
>>> >
>>> > I was trying to clean up

[openstack-dev] [release][keystone] keystoneauth1 2.5.0 release (newton)

We are psyched to announce the release of:

keystoneauth1 2.5.0: Authentication Library for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

Changes in keystoneauth1 2.3.0..2.5.0
-

7dd4208 fix OrderedDict mutated during iteration
7d448db Fix for PEP8 violation - D202 (No blank lines allowed after function 
docstring.)
3b8a0c0 Examples for migration from keystoneclient
e57547c Renamed endpoint to interface in docstring
b2cf285 Keystoneauth Authentication Plugin doc typo
ae2e6f4 Allow seeing full token response when debug enabled
e00de92 Update reno for stable/mitaka
8b5c524 Examples for kerberos and saml2 plugins
e066afd Adding authentication compatibility for OpenStackClient
f604a7f Swap the order of username deprecation
f83cee1 Fix exported symbol in identity.v3
9b74f9d Editorial nits for docs
73b1e66 Improve usability of docs
16596c9 Add links to federation plugins
d93fe12 Remove unavailable parameter
ee85077 Generate FederationBaseAuth constructor parameters
8d4cdd6 Update test run instructions
34ecf4b Fix typos and improve formatting in migrating.rst
2e951b7 Updated from global requirements
70d4e3a Updated from global requirements
417f223 Cleanup docstrings
e250f99 Fix docstring in identity.v3.oidc module

Diffstat (except docs and test files)
-

keystoneauth1/access/service_catalog.py|   6 +-
keystoneauth1/adapter.py   |   1 -
keystoneauth1/discover.py  |   1 -
keystoneauth1/extras/_saml2/v3/adfs.py |   3 -
keystoneauth1/extras/_saml2/v3/saml2.py|   1 -
keystoneauth1/fixture/__init__.py  |   9 +-
keystoneauth1/fixture/keystoneauth_betamax.py  |   2 +-
keystoneauth1/identity/__init__.py |  12 ++
keystoneauth1/identity/access.py   |   2 +-
keystoneauth1/identity/base.py |  43 +++
keystoneauth1/identity/generic/base.py |   8 +-
keystoneauth1/identity/v3/__init__.py  |   4 +-
keystoneauth1/identity/v3/base.py  |   5 +-
keystoneauth1/identity/v3/federation.py|  32 ++---
keystoneauth1/identity/v3/k2k.py   |   1 -
keystoneauth1/identity/v3/oidc.py  |  16 +--
keystoneauth1/loading/_plugins/identity/generic.py |   5 +-
keystoneauth1/loading/_plugins/identity/v2.py  |   7 +-
keystoneauth1/loading/_plugins/identity/v3.py  |   5 +-
keystoneauth1/loading/base.py  |   8 +-
keystoneauth1/loading/cli.py   |  15 ++-
keystoneauth1/loading/conf.py  |   8 +-
keystoneauth1/plugin.py|   8 +-
keystoneauth1/session.py   | 143 +++--
keystoneauth1/token_endpoint.py|  10 ++
releasenotes/source/index.rst  |   1 +
releasenotes/source/mitaka.rst |   6 +
test-requirements.txt  |   4 +-
tox.ini|   3 +-
39 files changed, 328 insertions(+), 200 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index ba8eec3..ad06c08 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ mock>=1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0
@@ -14 +14 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=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

[openstack-dev] [TripleO][CI] Ability to reproduce failures

2016-04-07 Thread Gabriele Cerami

Hi,

I'm trying to find an entry point to join the effort in TripleO CI.
I studied the infrastructure and the scripts, but there's still something I'm 
missing.
The last step of studying the complex landscape of TripleO CI and the first to 
start contributing
is being able to reproduce failures in an accessible environment, to start 
debugging issues.
I have not found an easy and stable way to do this. Jobs are certainly gathering
a lot of logs, but that's not enough.

At the moment, I started launching periodic jobs on my local test box using
this script
https://github.com/sshnaidm/various/blob/master/tripleo_repr.sh

It's quite handy, but I'm not sure it's able to produce perfectly compatible 
environments with what's in CI.

Can anyone suggest a way to make jobs reproducible locally? I know it may be 
complicated
to setup an environment through devtest, but may If we can start with just a 
list of steps, 
then it would be easier to put them into a script, hten make it availabe in the 
log in place
of the current reproduce.sh that is not very useful.

thanks for any feedback.

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

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

2016-04-07 Thread bharath

Thanks Paul for info.

Yes i had run the tests locally under VPN-repo.

My analysis:

* VPN test cases were using the neutron client for VPN
services (which no longer supported by neutron).

Thats why its throwing
"tempest.lib.exceptions.NotFound: Object not found"

* In the case of FW , there were using router client directly
instead of neutron client.

I will check with madhusudhan for additional info.

Madhu,
Let me know if you have info on "tox api" support.
If it is an known issue, i can take it up and complete fix

Thanks,
bharath

On Friday 08 April 2016 01:00 AM, Paul Michali wrote:

Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved
to the VPN repo, but I don't know if a job was ever created for this
so that the tests actually run. You may want to check with the author
who moved the tests (madhusudan-kandadai) under commit 3cae934a, to
see if the CI job was ever created. It is possible that it was never
completed.

Likewise, I don't know if support was added to tox.ini for the api
test. I've never run the test, granted I've been away from VPN for a
while and only involved intermittently since Liberty, so I may be a
bit out of touch.

Regards,

PCM

On Thu, Apr 7, 2016 at 2:23 PM bharath > wrote:

Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1

==> In this commit messages it says it kindof expected failure.

Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing 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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=

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

[openstack-dev] [Neutron] Drivers team cancelled

Hi Neutrinos,

Too many firefights this week and I personally didn't have much time to
spend on reviewing RFEs etc. If you guys want to have it, please go ahead
but I won't be able to join.

Cheers,
Armando
__
OpenStack Development Mailing 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] Drivers team cancelled

Hi Neutrinos,

Too many firefights this week and I personally didn't have much time to
spend on reviewing RFEs etc. If you guys want to have it, please go ahead
but I won't be able to join.

Cheers,
Armando
__
OpenStack Development Mailing 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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

2016-04-07 Thread Hongbin Lu

Hi all,
Thanks for your feedback. The vote is unanimous. Eli Qiao has been added to the 
core team [1].

[1] https://review.openstack.org/#/admin/groups/473,members

Best regards,
Hongbin

From: Vilobh Meshram [mailto:vilobhmeshram.openst...@gmail.com]
Sent: April-04-16 10:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core 
reviewer team

+1

On Sat, Apr 2, 2016 at 7:24 AM, Kai Qiang Wu 
> wrote:

+ 1 for Eli :)

Thanks

Best Wishes,

Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle!

[Inactive hide details for Hongbin Lu ---01/04/2016 02:20:17 am---Hi all, Eli 
Qiao has been consistently contributed to Magnum f]Hongbin Lu ---01/04/2016 
02:20:17 am---Hi all, Eli Qiao has been consistently contributed to Magnum for 
a while. His contribution started f

From: Hongbin Lu >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 01/04/2016 02:20 am
Subject: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer 
team

Hi all,

Eli Qiao has been consistently contributed to Magnum for a while. His 
contribution started from about 10 months ago. Along the way, he implemented 
several important blueprints and fixed a lot of bugs. His contribution covers 
various aspects (i.e. APIs, conductor, unit/functional tests, all the COE 
templates, etc.), which shows that he has a good understanding of almost every 
pieces of the system. The feature set he contributed to is proven to be 
beneficial to the project. For example, the gate testing framework he heavily 
contributed to is what we rely on every days. His code reviews are also 
consistent and useful.

I am happy to propose Eli Qiao to be a core reviewer of Magnum team. According 
to the OpenStack Governance process [1], we require a minimum of 4 +1 votes 
within a 1 week voting window (consider this proposal as a +1 vote from me). A 
vote of -1 is a veto. If we cannot get enough votes or there is a veto vote 
prior to the end of the voting window, Eli is not able to join the core team 
and needs to wait 30 days to reapply.

The voting is open until Thursday April 7st.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

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 Development Mailing 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][vpnaas] VPNaaS tox api failure

2016-04-07 Thread Paul Michali

Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved to
the VPN repo, but I don't know if a job was ever created for this so that
the tests actually run. You may want to check with the author who moved the
tests (madhusudan-kandadai) under commit 3cae934a, to see if the CI job was
ever created. It is possible that it was never completed.

Likewise, I don't know if support was added to tox.ini for the api test.
I've never run the test, granted I've been away from VPN for a while and
only involved intermittently since Liberty, so I may be a bit out of touch.

Regards,

PCM

On Thu, Apr 7, 2016 at 2:23 PM bharath  wrote:

>
> Hi,
>
> While running "tox -e api" i hitting " tempest.lib.NotFound" Error.
>
> Is it a known issue ? failures expected?
>
> https://review.openstack.org/#/c/291949/1  ==> In this commit messages it
> says it kindof expected failure.
>
> Can someone provide some clarification on this
>
> Thanks,
> bharath
> __
> OpenStack Development Mailing 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] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

2016-04-07 Thread McLellan, Steven

Hi,

I think Brad's spot on. See inline, but short version - the special case
is only required if the KS catalog returns v2.0 endpoints.

On 4/7/16, 1:39 PM, "Brad Pokorny"  wrote:

>Hi Brian,
>
>Copying to the general list, as this is something I've wondered about, and
>others probably are as well.
>
>Please see below. I'm not an expert on this topic, but I've looked at it a
>little bit.
>
>On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:
>
>>Hi there -
>>
>>I'm reaching out to ask for some clarification on what the difference is
>>between adminURL and internalURL as it pertains to the keystoneclient ‹
>>specifically in api/keystone.py
>>(http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard
>>/
>>a
>>pi/keystone.py#n163) whereby if the user is logged in as an admin, the
>>api
>>will specify 'adminURL' as the endpoint type.
>>
>>We have a scenario where our admin interface and internal interface are
>>on
>>2 separate networks, and therefore the adminURL is not accessible by
>>Horizon. 
>
>I think the original intent of having separate URL types was this exact
>purpose - having them on different networks/ports that can be locked down
>to protect admin operations. This was briefly mentioned in a recent ML
>post: 
>http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+or
>d
>er:date-backward=1
>
>It sounds like operations were locked down for the v2 identity API, but
>maybe not for v3 (which I'm assuming is what you're using).
>
>>When using the openstack CLI, we can specify the endpoint type as
>>internal and do not see any perceived reduction in functionality as an
>>admin user. 
>
>If everything can be done via the CLI with the internal URL anyway, then
>what's the point of protecting the admin URL on a separate network? Sounds
>like this is what your question below is getting at.
>
>>Are there certain functions that can only be accessed through
>>the adminURL?
>
>This is what I'm not sure of.



Note that the endpoint used will be the one the keystone catalog returns,
not whatever's configured in local_settings, but under v2.0, if instead of
using the admin port on 35357 you use port 5000 you'll get 404s from some
identity management functions:

# V3
curl -H"x-auth-token: $token"
http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6
{"user": {"id": "719319cc0f9d47b9b9ce512b77ae5da6", "enabled": true,
"domain_id": "default", "links": {"self":
"http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6"},
"name": "admin"}}


# V2.0
curl -H"x-auth-token: $token"
http://192.168.235.128:5000/v2.0/users/719319cc0f9d47b9b9ce512b77ae5da6
{"error": {"message": "The resource could not be found.", "code": 404,
"title": "Not Found"}}


If the catalog returns v3, this special case isn't needed; if it's v2.0,
it is.




>
>> 
>>
>>For our use case, we think we can workaround this by adding a new config
>>setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
>>'internalURL' in local_settings.py:
>>
>># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use
>>in
>>the
>># case that the default admin interface in the Keystone service catalog
>># is not accessible by Horizon. Use this setting when Horizon cannot
>># access the identity endpoint at the default 'adminURL' and set it to
>># 'internalURL'.
>>#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
>>
>>
>>then in api/keystone.py we can change
>>
>>endpoint_type = 'adminURL'
>>
>>to
>>
>>endpoint_type = getattr(settings,
>>'IDENTITY_ADMIN_ENDPOINT_TYPE',
>>'adminURL')
>>
>>which will use 'adminURL' as the default, but allow user customizable
>>endpoint type for identity
>>
>>
>>Does this seem even remotely useful upstream? Let me know...
>
>I would think if the internal URL can do everything the admin URL can do,
>and if that's how things are supposed to remain long term, there's no
>reason to have internal and admin on separate networks.
>
>>
>>Thanks!
>>
>>Brian Tully
>>Software Engineer
>>HPE
>>
>>
>

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

Re: [openstack-dev] [Congress] Issues with Tox testing

2016-04-07 Thread Clark Boylan

On Thu, Apr 7, 2016, at 11:16 AM, Bryan Sullivan wrote:
> Hi Congress team, 
> 
> A question for tox testing expert on the Congress team. I'm trying to run
> the tox tests as described at https://github.com/openstack/congress,
> specifically the two commands:
> 
> $ sudo pip install 'tox<1.7'
> 
> $ tox -epy27 
> 
> 
> 
> Due to conflicts with the OS-owned python config, I run these under my
> virtualenv created in the congress repo as:
> $ cd ~/git/congress
> $ bin/pip  install 'tox<1.7'
> $ bin/tox -epy27
> 
> 
> But in any event (whether I try to run the tox within the virtualenv or
> not), I get errors such as:
>   c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
> 
> 
> 
> What's missing in the setup for running these tests? 

This indicates you do not have the libffi development headers installed
on your system. On debuntu they come in the libffi-dev package.

Clark

__
OpenStack Development Mailing 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][app-catalog] Discussions in Austin

2016-04-07 Thread Christopher Aedo

Greetings Horizon team!  We'd like to find time at the design summit
to cover a few of the things that impact both Horizon and the
Community App Catalog.  I think many of these topics will be of
interest to other teams working on plugins using angular as well.  If
you've already got these on your agenda for conversations in Austin,
please let me know (especially if they're already covered under a
broader topic).

The main points we'd like to spend time discussing in Austin are:
* Need to understand what integration testing framework will look like
for angular
* Sharing widgets via xstatic
* Horizon plugins that depend on extra xstatic packages.
* Can/will Horizon provide some of the widget pop up functions as
angular modules instead of us poking around at the internals? This
simplifies testing and multiversion support.
* Long term direction for Community App Catalog UI dialog integration
(roadmap for native inclusion)

I'll be able to attend the next weekly meeting (5/13) if you want to
discuss anything in detail, or else drop by #openstack-app-catalog on
IRC any other time.  Thanks!

-Christopher

__
OpenStack Development Mailing 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] [Glance] Newton virtual pre-summit sync

2016-04-07 Thread Nikhil Komawar

Hi Flavio,

Thank you for responding.

Will it be still possible to do this sync on your bridge? I agree, it
worked pretty well the last time and would save us time on setting up
something new too.

On 4/1/16 8:56 AM, Flavio Percoco wrote:
> On 31/03/16 17:34 -0400, Nikhil Komawar wrote:
>
>> Hi all,
>>
>>
>>
>> I'm excited to see you all Glancers at the Austin summit and discuss
>>
>> more on our project.
>>
>>
>>
>> Nevertheless, I feel that our summit conversations will have a lot more
>>
>> value if we establish some prior-context to the discussions and prepare
>>
>> ourselves for some of the sessions. Hence, I would like to call for a
>>
>> virtual sync meetup on the week of April 11th.
>>
>>
>>
>> My initial plan is to have a 4 hour sync on Tuesday April 12th, from
>>
>> 1400-1800 UTC (we can decide on the length of the sessions and the
>>
>> required breaks later). But sending out this tentative plan to gauge the
>>
>> feasibility and interest.
>>
>
>
> Happy to join!
>
>
>
>> Please reply to this thread with your thoughts. If none, looking forward
>>
>> to seeing you at the event.
>>
>>
>>
>> P.S. based on the number of interested participants we can decide on the
>>
>> tool to be used.
>>
>
>
>
>
> We can use my bluejeans bridge. It work fairly well for the virtual
> mid-cycle we
>
> did a couple of months ago.
>
>
>
> Flavio
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Thanks,
Nikhil



__
OpenStack Development Mailing 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] [Glance] Newton virtual pre-summit sync

2016-04-07 Thread Nikhil Komawar

Hi all,

Thank you to those who have responded.

As there were no objections, we will go with the proposed plan:

We will have virtual sync related to Glance summit topics on, Tuesday
April 12th from 1400 to ~1800 UTC. You can ask for the access to the
conferencing tool on IRC (#openstack-glance) a little bit before 1400
UTC on Tuesday. If we figure out there are no authN issues with sharing
the info on ML email, we may give the info earlier in that case.

We will use the etherpad [1] to take notes on the topics.

The tentative/flexible schedule is as follows:

1. Setup, bandwidth testing, etc. etc. (1400-1415)
2. rosmaita and hemanthm: Proposals #14 & #15 (2 long proposal 30 mins)
(1415-1445)
3. flaper87: Proposals #1, #11, #12, #13 (4 small-medium proposal 30
mins) (1445-1515)
4. mfedosin: Proposal #3, #4 (1 long, 1 medium proposal 30 mins) (1515-1545)
5. Break 15 mins (1545-1600)
6. mclaren, rosmaita, nikhil: Proposal #8, #16 (90 mins) (1600-1730)
7. nikhil: wind up on remaining proposal, feedback on setting the final
summit schedule (1730-q.s.)

Please note, the event will tentatively be over ~1800UTC but in past
we've run over. We need to finalize the schedule next week and I want to
finalize the summit schedule on Tues, April 12th to avoid last minute
rush and help others do sanity checking, figure out conflicts, give last
minute suggestions, etc. So, if you have a meeting later please leave
some notes before the sync starts (see the bottom of the etherpad [1]
for the same).

If you're scheduled for a slot to speak during the event and have other
constraints, let me know by tomorrow so that we can figure out alternate
plans or modify the schedule a bit. During the event, I will be giving a
reminder to wind up the discussion ~5 mins before your allocated time is
over, in order to help move the schedule smoothly. Please be prepared on
your topics so that we can finish the discussions on time.

Let me know if there are questions.

[1] https://etherpad.openstack.org/p/newton-glance-summit-planning

On 3/31/16 5:34 PM, Nikhil Komawar wrote:
> Hi all,
>
> I'm excited to see you all Glancers at the Austin summit and discuss
> more on our project.
>
> Nevertheless, I feel that our summit conversations will have a lot more
> value if we establish some prior-context to the discussions and prepare
> ourselves for some of the sessions. Hence, I would like to call for a
> virtual sync meetup on the week of April 11th.
>
> My initial plan is to have a 4 hour sync on Tuesday April 12th, from
> 1400-1800 UTC (we can decide on the length of the sessions and the
> required breaks later). But sending out this tentative plan to gauge the
> feasibility and interest.
>
> Please reply to this thread with your thoughts. If none, looking forward
> to seeing you at the event.
>
> P.S. based on the number of interested participants we can decide on the
> tool to be used.
>

-- 

Thanks,
Nikhil

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

[openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

2016-04-07 Thread Brad Pokorny

Hi Brian,

Copying to the general list, as this is something I've wondered about, and
others probably are as well.

Please see below. I'm not an expert on this topic, but I've looked at it a
little bit.

On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:

>Hi there -
>
>I'm reaching out to ask for some clarification on what the difference is
>between adminURL and internalURL as it pertains to the keystoneclient ‹
>specifically in api/keystone.py
>(http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/
>a
>pi/keystone.py#n163) whereby if the user is logged in as an admin, the api
>will specify 'adminURL' as the endpoint type.
>
>We have a scenario where our admin interface and internal interface are on
>2 separate networks, and therefore the adminURL is not accessible by
>Horizon. 

I think the original intent of having separate URL types was this exact
purpose - having them on different networks/ports that can be locked down
to protect admin operations. This was briefly mentioned in a recent ML
post: 
http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
er:date-backward=1

It sounds like operations were locked down for the v2 identity API, but
maybe not for v3 (which I'm assuming is what you're using).

>When using the openstack CLI, we can specify the endpoint type as
>internal and do not see any perceived reduction in functionality as an
>admin user. 

If everything can be done via the CLI with the internal URL anyway, then
what's the point of protecting the admin URL on a separate network? Sounds
like this is what your question below is getting at.

>Are there certain functions that can only be accessed through
>the adminURL?

This is what I'm not sure of.

> 
>
>For our use case, we think we can workaround this by adding a new config
>setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
>'internalURL' in local_settings.py:
>
># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in
>the
># case that the default admin interface in the Keystone service catalog
># is not accessible by Horizon. Use this setting when Horizon cannot
># access the identity endpoint at the default 'adminURL' and set it to
># 'internalURL'.
>#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
>
>
>then in api/keystone.py we can change
>
>endpoint_type = 'adminURL'
>
>to
>
>endpoint_type = getattr(settings,
>'IDENTITY_ADMIN_ENDPOINT_TYPE',
>'adminURL')
>
>which will use 'adminURL' as the default, but allow user customizable
>endpoint type for identity
>
>
>Does this seem even remotely useful upstream? Let me know...

I would think if the internal URL can do everything the admin URL can do,
and if that's how things are supposed to remain long term, there's no
reason to have internal and admin on separate networks.

>
>Thanks!
>
>Brian Tully
>Software Engineer
>HPE
>
>

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

[openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

2016-04-07 Thread bharath



Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1  ==> In this commit messages 
it says it kindof expected failure.


Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing 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] [Congress] Issues with Tox testing

Hi Congress team, 

A question for tox testing expert on the Congress team. I'm trying to run the 
tox tests as described at https://github.com/openstack/congress, specifically 
the two commands:

$ sudo pip install 'tox<1.7'

$ tox -epy27 



Due to conflicts with the OS-owned python config, I run these under my 
virtualenv created in the congress repo as:
$ cd ~/git/congress
$ bin/pip  install 'tox<1.7'
$ bin/tox -epy27


But in any event (whether I try to run the tox within the virtualenv or not), I 
get errors such as:
  c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory



What's missing in the setup for running these tests? 



Note that I have all the config needed to run bash/CLI-based test scripts such 
as https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh 



Thanks,
Bryan Sullivan__
OpenStack Development Mailing 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] Mitaka stable packaged for RDO

2016-04-07 Thread Haïkel

Hi,

the RDO community has packages available for Mitaka Stable in its
testing repositories.
Official RDO release will be announced after we validate this release
with our CI.

Regards,
H.

__
OpenStack Development Mailing 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][api] Recently accepted API-WG guidelines

2016-04-07 Thread michael mccune


hello all,

this is a friendly update about guidelines that the API working group 
has recently accepted:


1. version discover guideline for API microversions
https://review.openstack.org/243429

2. client interaction guideline for API microversions
https://review.openstack.org/243414

3. versioning guideline for API microversions
https://review.openstack.org/243041

4. unexpected attribute guideline
https://review.openstack.org/260292


additionally, we have updated our process slightly to better reflect 
ownership of merges.

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

thanks,
mike

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

2016-04-07 Thread Flavio Percoco


On 07/04/16 12:24 +, Amrith Kumar wrote:

The trove failure is [1], same as described in email yesterday[2].

We have a gracious volunteer who offered to help with stable management 
changes, and I've emailed him a request to have this and some other changes 
proposed into other stable branches. That request is below:


You had offered to help with stable maintenance in Trove so here are some
specific requests I have for you.


That'd be me! I'm on it! :)

Flavio


1.  Would you please review and (if you agree, approve) the following 
changes:
a.  https://review.openstack.org/#/c/301726/
b.  https://review.openstack.org/#/c/301722/
2.  Would you please review bugs marked for Mitaka, Liberty and Kilo and 
help
with the backports to these branches, specifically:
a.  Once https://review.openstack.org/#/c/39/ merges in master,
  it should also go to Mitaka
b.  Once https://review.openstack.org/#/c/300253/ merges in master,
  it should also go to Mitaka
c.  The stable team has accepted the idea of backporting
  https://bugs.launchpad.net/trove/kilo/+bug/1437179 to kilo


Thanks,

-amrith


[1] https://bugs.launchpad.net/trove/kilo/+bug/1437179
[2] http://openstack.markmail.org/thread/djzcbbh6thebdcgi



-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.
[mailto:openstack-stable-ma...@lists.openstack.org]
Sent: Thursday, April 07, 2016 2:27 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/a7fccf2/ : SUCCESS in 2m 24s
- periodic-trove-python27-db-kilo http://logs.openstack.org/periodic-
stable/periodic-trove-python27-db-kilo/db5941c/ : FAILURE in 3m 09s
- periodic-trove-docs-liberty http://logs.openstack.org/periodic-
stable/periodic-trove-docs-liberty/136852b/ : SUCCESS in 2m 16s
- periodic-trove-python27-db-liberty http://logs.openstack.org/periodic-
stable/periodic-trove-python27-db-liberty/47de4f1/ : SUCCESS in 8m 30s
- periodic-trove-docs-mitaka http://logs.openstack.org/periodic-
stable/periodic-trove-docs-mitaka/160d735/ : SUCCESS in 2m 33s
- periodic-trove-python27-db-mitaka http://logs.openstack.org/periodic-
stable/periodic-trove-python27-db-mitaka/0f3e3dd/ : SUCCESS in 12m 51s

___
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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

2016-04-07 Thread Brad Pokorny

+1. I think Rob will provide good input for stable.

Thanks,
Brad

From: Timur Sufiev >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, April 7, 2016 at 4:31 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for 
Horizon stable core

+1
Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia 
>:
Im still not sure if non-cores (i.e. peasants like me) can vote but I
will do it anyway :D

A big +1 from me.

Itxaka

On 04/07/2016 12:01 PM, Matthias Runge wrote:
> Hello,
>
> I'm proposing Rob Cresswell to become stable core for Horizon. I
> thought, in the past all PTL were in stable team, but this doesn't seem
> to be true any more.
>
> Please chime in with +1/-1
>

__
OpenStack Development Mailing 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] FreeIPA integration

2016-04-07 Thread Fox, Kevin M

Yeah, the console can be used as a building block to solve it. I'm just saying 
we should formalize the plumbing enough that it can be relied upon by everyone, 
instead of asking everyone to reinvent the wheel. Thats partially what the 
spec's about.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Thursday, April 07, 2016 6:33 AM
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration

Excerpts from Adam Young's message of 2016-04-05 19:02:58 -0700:
> On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
> > Yeah, and they just deprecated vendor data plugins too, which
> > eliminates my other workaround. :/
> >
> > We need to really discuss this problem at the summit and get a viable
> > path forward. Its just getting worse. :/
> >
> > Thanks,
> > Kevin
> > 
> > *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> > *Sent:* Tuesday, April 05, 2016 5:16 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
> >
> >
> >
> > On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M  > > wrote:
> >
> > This sounds suspiciously like, "how do you get a secret to the
> > instance to get a secret from the secret store" issue :)
> >
> > Yeah, sounds pretty familiar. We were using the nova hooks mechanism
> > for this means, but it was deprecated recently. So bummer :/
> >
> >
> > Nova instance user spec again?
> >
> > Thanks,
> > Kevin
> >
>
> Yep, and we need a solution.  I think the right solution is a keypair
> generated on the instance, public key posted by the instace to the
> hypervisor and stored with the instance data in the database.  I wrote
> that to the mailing list earlier today.
>

If you log your public SSH host key to the console, this already
happens. No need for hypervisor magic, just scrape your console.

__
OpenStack Development Mailing 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] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

2016-04-07 Thread Ihar Hrachyshka


Hongbin Lu  wrote:


Hi all,
Magnum gate recently broke with error: “AttributeError: 'str' object has  
no attribute 'strftime'” (here is a full log [1]). I would like to  
confirm if there is a recent commit in Neutron that causes the breakage.  
If yes, a quick fix is greatly appreciated.


[1]  
http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-magnum-api/ea0d4ba/logs/screen-q-lbaas.txt.gz




The fix should be: https://review.openstack.org/#/c/302904/

Ihar

__
OpenStack Development Mailing 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][neutron] AttributeError: 'str' object has no attribute 'strftime'

2016-04-07 Thread Hongbin Lu

Hi all,
Magnum gate recently broke with error: "AttributeError: 'str' object has no 
attribute 'strftime'" (here is a full log [1]). I would like to confirm if 
there is a recent commit in Neutron that causes the breakage. If yes, a quick 
fix is greatly appreciated.

[1] 
http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-magnum-api/ea0d4ba/logs/screen-q-lbaas.txt.gz

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

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Aleksandr Didenko

Alex, we can do this (and I hope we'll do) after we fix
https://bugs.launchpad.net/fuel/+bug/1567367

Regards,
Alex

On Thu, Apr 7, 2016 at 5:04 PM, Alex Schultz  wrote:

>
> On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> thanks to Dima, we now have ROLE annotations in noop tests [0]. I've
>> updated all the noop rspec tests that we currently have and added
>> appropriate role annotation [1]. So after this patch is merged, we no
>> longer need to put any new fixtures into dozens of rspec files in order to
>> enable it.
>> Please make sure to update ROLE annotations if you introduce new roles
>> (deployment groups) or change task-to-roles assignments in *tasks.yaml
>> files. Core reviewers, please don't forget to check this as well ;)
>>
>>
> Is there a reason we can't leverage the existing definitions in the
> tasks.yaml files for this?  It seems like requiring people to provide this
> information might lead to cases where it's gets out of sync. Shouldn't we
> use the task files as the source of truth for the roles?
>
> -Alex
>
>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/300649
>> [1] https://review.openstack.org/302313
>>
>> On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko > > wrote:
>>
>>> Hi folks,
>>>
>>> we've merged all the changes related to fixtures update [0] and bugfix
>>> to unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in
>>> tests not related to your patch, then please rebase.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
>>> [1] https://review.openstack.org/301107
>>> [2] https://ci.fuel-infra.org/job/fuellib_noop_tests/
>>>
>>> On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin 
>>> wrote:
>>>
 Hi Alex

 +1 to your proposal - this is long-awaited change.

 On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> One more thing about spec to fixture mapping [0]. What if instead of:
>
> # RUN: (hiera1) (facts1)
>
> we'll use
>
> # RUN: (roles_array1) (facts1)
>
> ?
>
> We don't need to duplicate complicated task graph calculations to
> understand which task to execute, because we don't care about tasks
> ordering and dependencies in noop tests. All we need is to map rspec task
> tests to astute.yaml fixtures. And it could be done via roles.
>
> Regards,
> Alex
>
> [0]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>
>
> On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hi.
>>
>>   As you may know, we're still using some very old astute.yaml
>> fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides 
>> that,
>> we have problems with fixture-to-rspec mapping [1]. So we've started to
>> work on those problems [2].
>>
>>   So please be aware of upcoming changes in noop rspec fixtures and
>> tests. If you see, that some important fixtures are missing (thus not
>> covered by tests) please let me know in this email thread or via
>> IRC/email/slack.
>>
>>   Also, we should stop updating astute.yaml fixtures manually and
>> start using some kind of automation approach instead [3][4]. I propose to
>> use [5] script until we find a better solution. So if you want to add 
>> some
>> new astute.yaml fixture for noop tests, please propose a patch to this
>> script instead of uploading yaml file.
>>
>> Currently the following is missing in the new set of fixtures for
>> fuel-9.0:
>> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
>> properly enable it via nailgun, any help is much appreciated)
>> - selective ssl fixtures - since configuration data is not serialized
>> from nailgun, I think that we should move this into 'hiera/override' 
>> along
>> with implementation of new hiera overrides tests workflow [6]
>> - vmware related fixtures
>>
>> Please feel free to share your ideas/comments on this topic.
>>
>> Thanks,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1535339
>> [1]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
>> [3]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
>> [4]
>> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
>> [5]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
>> [6] https://bugs.launchpad.net/fuel/+bug/1564919
>>
>
>
>
>

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Alex Schultz

On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko 
wrote:

> Hi,
>
> thanks to Dima, we now have ROLE annotations in noop tests [0]. I've
> updated all the noop rspec tests that we currently have and added
> appropriate role annotation [1]. So after this patch is merged, we no
> longer need to put any new fixtures into dozens of rspec files in order to
> enable it.
> Please make sure to update ROLE annotations if you introduce new roles
> (deployment groups) or change task-to-roles assignments in *tasks.yaml
> files. Core reviewers, please don't forget to check this as well ;)
>
>
Is there a reason we can't leverage the existing definitions in the
tasks.yaml files for this?  It seems like requiring people to provide this
information might lead to cases where it's gets out of sync. Shouldn't we
use the task files as the source of truth for the roles?

-Alex


> Regards,
> Alex
>
> [0] https://review.openstack.org/300649
> [1] https://review.openstack.org/302313
>
> On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko 
> wrote:
>
>> Hi folks,
>>
>> we've merged all the changes related to fixtures update [0] and bugfix to
>> unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in tests
>> not related to your patch, then please rebase.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
>> [1] https://review.openstack.org/301107
>> [2] https://ci.fuel-infra.org/job/fuellib_noop_tests/
>>
>> On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Hi Alex
>>>
>>> +1 to your proposal - this is long-awaited change.
>>>
>>> On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko >> > wrote:
>>>
 One more thing about spec to fixture mapping [0]. What if instead of:

 # RUN: (hiera1) (facts1)

 we'll use

 # RUN: (roles_array1) (facts1)

 ?

 We don't need to duplicate complicated task graph calculations to
 understand which task to execute, because we don't care about tasks
 ordering and dependencies in noop tests. All we need is to map rspec task
 tests to astute.yaml fixtures. And it could be done via roles.

 Regards,
 Alex

 [0]
 https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations


 On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> Hi.
>
>   As you may know, we're still using some very old astute.yaml
> fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that,
> we have problems with fixture-to-rspec mapping [1]. So we've started to
> work on those problems [2].
>
>   So please be aware of upcoming changes in noop rspec fixtures and
> tests. If you see, that some important fixtures are missing (thus not
> covered by tests) please let me know in this email thread or via
> IRC/email/slack.
>
>   Also, we should stop updating astute.yaml fixtures manually and
> start using some kind of automation approach instead [3][4]. I propose to
> use [5] script until we find a better solution. So if you want to add some
> new astute.yaml fixture for noop tests, please propose a patch to this
> script instead of uploading yaml file.
>
> Currently the following is missing in the new set of fixtures for
> fuel-9.0:
> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
> properly enable it via nailgun, any help is much appreciated)
> - selective ssl fixtures - since configuration data is not serialized
> from nailgun, I think that we should move this into 'hiera/override' along
> with implementation of new hiera overrides tests workflow [6]
> - vmware related fixtures
>
> Please feel free to share your ideas/comments on this topic.
>
> Thanks,
> Alex
>
> [0] https://bugs.launchpad.net/fuel/+bug/1535339
> [1]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
> [3]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
> [4]
> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
> [5]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
> [6] https://bugs.launchpad.net/fuel/+bug/1564919
>



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


>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>>

[openstack-dev] [TripleO] [CI] Tempest configuration in Tripleo CI jobs

2016-04-07 Thread Sagi Shnaidman

Hi, all

I'd like to discuss the topic about how do we configure tempest in CI jobs
for TripleO.
I have currently two patches:
support for tempest: https://review.openstack.org/#/c/295844/
actually run of tests: https://review.openstack.org/#/c/297038/

Right now there is no upstream tool to configure tempest, so everybody use
their own tools. However it's planned and David Mellado is working on it
AFAIK.
Till then everybody use their own tools for tempest configuration.
I'd review two of them:
1) Puppet configurations that is used in puppet modules CI
2) Using configure_tempest.py script from
https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py

Unfortunately there is no ready puppet module or script, that configures
tempest, you need to create your own.

On other hand the config_tempest.py script provides full configuration,
support for tempest-deployer-input.conf and possibility to add any config
options in the command line when running it:

python config_tempest.py \
--out etc/tempest.conf \
--debug \
--create \
--deployer-input ~/tempest-deployer-input.conf \
identity.uri $OS_AUTH_URL \
compute.allow_tenant_isolation true \
identity.admin_password $OS_PASSWORD \
compute.build_timeout 500 \
compute.image_ssh_user cirros

Also it uploads images, creates necessary roles, etc. The only thing it
requires - existence of public network.
So finally all tempest configuration from scratch will be like:

CONFIGURE_TEMPEST_DIR="$(ls
/usr/share/openstack-tempest-*/tools/configure-tempest-directory)"
$CONFIGURE_TEMPEST_DIR
neutron net-create nova --shared --router:external=True
--provider:network_type flat --provider:physical_network datacentre;
neutron subnet-create --name ext-subnet --allocation-pool
start=$FLOATING_IP_START,end=$FLOATING_IP_END --disable-dhcp --gateway
$EXTERNAL_NETWORK_GATEWAY nova $FLOATING_IP_CIDR;
python tempest/tools/install_venv.py
python config_tempest.py \
--out etc/tempest.conf \
--debug \
--create \
--deployer-input ~/tempest-deployer-input.conf \
identity.uri $OS_AUTH_URL \
compute.allow_tenant_isolation true \
identity.admin_password $OS_PASSWORD \
compute.build_timeout 500 \
compute.image_ssh_user cirros
testr init; testr run

In my patch [1] I have proposed it with little changes to TripleO CI repo
[2]

Like I wrote before there is an option to use puppet for this, I spent a
time to investigate how to do it and would like share the results with your
in order to compare it with config_tempest.py approach.

First of all it's surprising that puppet-tempest actually doesn't know to
do almost anything. All it knows - it's to set IDs of public network (but
not router) and images. That's all. All the rest you need to configure
manually.
Then comes another problem - you can use it only on overcloud controller
node, where are all service configurations and hiera data. Most of values
are taken directly from /etc/{service}/service.conf files, so doing it on
undercloud you will configure undercloud itself (instead of overcloud)

So first of all you need to upload this manifest to controller node of
overcloud.
Let's write this puppet manifest, I wrote everything in one file for saving
a time, but of course it should be a module with usual puppet module
structure: module_name/manifests/init.pp with module_name class.

Manual configurations:

class testt::config {
  $os_username = 'admin'
  $os_tenant_name = hiera(keystone::roles::admin::admin_tenant)
  $os_password = hiera(admin_password)
  $os_auth_url = hiera(keystone::endpoint::public_url)
  $keystone_auth_uri = regsubst($os_auth_url, '/v2.0', '')
  $floating_range   = "192.0.2.0/24"
  $gateway_ip   = "192.0.2.1"
  $floating_pool= 'start=192.0.2.50,end=192.0.2.99'
  $fixed_range  = '10.0.0.0/24'
  $router_name  = 'router1'
  $ca_bundle_cert_path = '/etc/ssl/certs/ca-bundle.crt'
  $cert_path   =
'/etc/pki/ca-trust/source/anchors/puppet_openstack.pem'
  $update_ca_certs_cmd = '/usr/bin/update-ca-trust force-enable &&
/usr/bin/update-ca-trust extract'
  $host_url = regsubst($keystone_auth_uri, ':5000', '')
}

Most of data is taken from hiera on the controller host. (/etc/hieradata)
Then we start actually the tempest configuration. Surprisingly it doesn't
have resource type to work with flavors, so all its configuration is done
by "exec"s. We run puppet with bash to run bash within a puppet, what gives
pretty big overhead.

class testt::provision {
  include testt::config

  $os_auth_options = "--os-username ${config::os_username} --os-password
${config::os_password} --os-tenant-name ${config::os_tenant_name}
--os-auth-url ${config::os_auth_url}/v2.0"

  exec { 'manage_m1.nano_nova_flavor':
path => '/usr/bin:/bin:/usr/sbin:/sbin',
provider => shell,
command  => "nova ${os_auth_options} flavor-delete m1.nano ||: ; nova

[openstack-dev] [nova] Instance Snapshot Capability Extended

2016-04-07 Thread Ayenson, Michael D.

Hi All,

I have proposed a blueprint 
(https://blueprints.launchpad.net/nova/+spec/instance-memory-snapshot) and nova 
spec (https://review.openstack.org/#/c/295415/) to improve the current snapshot 
capability. In the past this topic has been introduced and several times it has 
been left behind. Is there any interest in this topic in any capacity or is 
there a reason why this hasn't been extended before?


__
OpenStack Development Mailing 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] Mitaka packaged on Gentoo.

2016-04-07 Thread Matthew Thode

While we have had 2016.1. packages (ebuilds that track the
stable/mitaka branches) and it has already seen deployment I'm now happy
to announce that now that the tarballs are up we also have ebuilds based
on the tags/tarballs.

-- 
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [Nova] RFC Host Maintenance

2016-04-07 Thread Qiming Teng

The only gap based on my limited understanding is that nova is not
emitting events compute host state changes. This knowledge is still kept
inside nova as some service states. If that info is posted to oslo
messaging, a lot of usage scenarios can be enabled and we can avoid too
much churns to nova itself.

Regards,
  Qiming


__
OpenStack Development Mailing 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][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Aleksandr Didenko

Hi,

thanks to Dima, we now have ROLE annotations in noop tests [0]. I've
updated all the noop rspec tests that we currently have and added
appropriate role annotation [1]. So after this patch is merged, we no
longer need to put any new fixtures into dozens of rspec files in order to
enable it.
Please make sure to update ROLE annotations if you introduce new roles
(deployment groups) or change task-to-roles assignments in *tasks.yaml
files. Core reviewers, please don't forget to check this as well ;)

Regards,
Alex

[0] https://review.openstack.org/300649
[1] https://review.openstack.org/302313

On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko 
wrote:

> Hi folks,
>
> we've merged all the changes related to fixtures update [0] and bugfix to
> unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in tests
> not related to your patch, then please rebase.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
> [1] https://review.openstack.org/301107
> [2] https://ci.fuel-infra.org/job/fuellib_noop_tests/
>
> On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin 
> wrote:
>
>> Hi Alex
>>
>> +1 to your proposal - this is long-awaited change.
>>
>> On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko 
>> wrote:
>>
>>> One more thing about spec to fixture mapping [0]. What if instead of:
>>>
>>> # RUN: (hiera1) (facts1)
>>>
>>> we'll use
>>>
>>> # RUN: (roles_array1) (facts1)
>>>
>>> ?
>>>
>>> We don't need to duplicate complicated task graph calculations to
>>> understand which task to execute, because we don't care about tasks
>>> ordering and dependencies in noop tests. All we need is to map rspec task
>>> tests to astute.yaml fixtures. And it could be done via roles.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0]
>>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>>>
>>>
>>> On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko >> > wrote:
>>>
 Hi.

   As you may know, we're still using some very old astute.yaml fixtures
 (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
 problems with fixture-to-rspec mapping [1]. So we've started to work on
 those problems [2].

   So please be aware of upcoming changes in noop rspec fixtures and
 tests. If you see, that some important fixtures are missing (thus not
 covered by tests) please let me know in this email thread or via
 IRC/email/slack.

   Also, we should stop updating astute.yaml fixtures manually and start
 using some kind of automation approach instead [3][4]. I propose to use [5]
 script until we find a better solution. So if you want to add some new
 astute.yaml fixture for noop tests, please propose a patch to this script
 instead of uploading yaml file.

 Currently the following is missing in the new set of fixtures for
 fuel-9.0:
 - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
 properly enable it via nailgun, any help is much appreciated)
 - selective ssl fixtures - since configuration data is not serialized
 from nailgun, I think that we should move this into 'hiera/override' along
 with implementation of new hiera overrides tests workflow [6]
 - vmware related fixtures

 Please feel free to share your ideas/comments on this topic.

 Thanks,
 Alex

 [0] https://bugs.launchpad.net/fuel/+bug/1535339
 [1]
 https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
 [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
 [3]
 https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
 [4]
 https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
 [5]
 https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
 [6] https://bugs.launchpad.net/fuel/+bug/1564919

>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.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] [TripleO] FreeIPA integration

2016-04-07 Thread Clint Byrum

Excerpts from Adam Young's message of 2016-04-05 19:02:58 -0700:
> On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
> > Yeah, and they just deprecated vendor data plugins too, which 
> > eliminates my other workaround. :/
> >
> > We need to really discuss this problem at the summit and get a viable 
> > path forward. Its just getting worse. :/
> >
> > Thanks,
> > Kevin
> > 
> > *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> > *Sent:* Tuesday, April 05, 2016 5:16 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
> >
> >
> >
> > On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M  > > wrote:
> >
> > This sounds suspiciously like, "how do you get a secret to the
> > instance to get a secret from the secret store" issue :)
> >
> > Yeah, sounds pretty familiar. We were using the nova hooks mechanism 
> > for this means, but it was deprecated recently. So bummer :/
> >
> >
> > Nova instance user spec again?
> >
> > Thanks,
> > Kevin
> >
> 
> Yep, and we need a solution.  I think the right solution is a keypair 
> generated on the instance, public key posted by the instace to the 
> hypervisor and stored with the instance data in the database.  I wrote 
> that to the mailing list earlier today.
> 

If you log your public SSH host key to the console, this already
happens. No need for hypervisor magic, just scrape your console.

__
OpenStack Development Mailing 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][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

2016-04-07 Thread Lance Bragstad

In response to point 2.2, the progress with Fernet in the last year has
exposed performance pain points in keystone. Finding sensible solutions for
those issues is crucial in order for people to adopt Fernet. In Mitaka we
had a lot of discussion that resulted in landing several performance
related patches.

As of today, we're already focusing on scalability, performance, and
simplicity. I'm afraid a project split would only delay the work we're
doing right now.

On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg 
wrote:

>
>
> On Wed, Apr 6, 2016 at 6:29 PM, David Stanek  wrote:
>
>>
>> On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic 
>> wrote:
>>
>>>
>>> 2) This will reduce scope of Keystone, which means 2 things
>>> 2.1) Smaller code base that has less issues and is simpler for testing
>>> 2.2) Keystone team would be able to concentrate more on fixing
>>> perf/scalability issues of authorization, which is crucial at the moment
>>> for large clouds.
>>>
>>
>> I'm not sure that this is entirely true. If we truly just split up the
>> project, meaning we don't remove functionality, then we'd have the same
>> number of bugs and work. It would just be split across two projects.
>>
>> I think the current momentum to get out of the authn business is still
>> our best bet. As Steve mentioned this is ongoing work.
>>
>> -- David
>>
>>
> What everyone else said... but add in the need then to either pass the
> AuthN over to the Assignment/AuthZ api or bake it in (via apache module?)
> and we are basically where we are now.
>
> Steve alluded to splitting out the authentication bit (but not to a new
> service), the idea there is to make it so AuthN is not part of the CRUD
> interface of the server. All being said, AuthN and AuthZ are going to be
> hard to split into two separate services and with exception of the
> unfounded "scope" benefit, we already can handle most of what you've
> proposed with zero changes to Keystone.
>
> Cheers,
> --Morgan
>
>
> __
> OpenStack Development Mailing 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] [trove][stable] [Openstack-stable-maint] Stable check of openstack/trove failed

2016-04-07 Thread Amrith Kumar

The trove failure is [1], same as described in email yesterday[2].

We have a gracious volunteer who offered to help with stable management 
changes, and I've emailed him a request to have this and some other changes 
proposed into other stable branches. That request is below:

> You had offered to help with stable maintenance in Trove so here are some 
> specific requests I have for you.
>
> 1.Would you please review and (if you agree, approve) the following 
> changes:
>   a.  https://review.openstack.org/#/c/301726/
>   b.  https://review.openstack.org/#/c/301722/
> 2.Would you please review bugs marked for Mitaka, Liberty and Kilo and 
> help 
> with the backports to these branches, specifically:
>   a.  Once https://review.openstack.org/#/c/39/ merges in master, 
>   it should also go to Mitaka
>   b.  Once https://review.openstack.org/#/c/300253/ merges in master, 
>   it should also go to Mitaka
>   c.  The stable team has accepted the idea of backporting 
>   https://bugs.launchpad.net/trove/kilo/+bug/1437179 to kilo

Thanks,

-amrith


[1] https://bugs.launchpad.net/trove/kilo/+bug/1437179
[2] http://openstack.markmail.org/thread/djzcbbh6thebdcgi


> -Original Message-
> From: A mailing list for the OpenStack Stable Branch test reports.
> [mailto:openstack-stable-ma...@lists.openstack.org]
> Sent: Thursday, April 07, 2016 2:27 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/a7fccf2/ : SUCCESS in 2m 24s
> - periodic-trove-python27-db-kilo http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-kilo/db5941c/ : FAILURE in 3m 09s
> - periodic-trove-docs-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-liberty/136852b/ : SUCCESS in 2m 16s
> - periodic-trove-python27-db-liberty http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-liberty/47de4f1/ : SUCCESS in 8m 30s
> - periodic-trove-docs-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-docs-mitaka/160d735/ : SUCCESS in 2m 33s
> - periodic-trove-python27-db-mitaka http://logs.openstack.org/periodic-
> stable/periodic-trove-python27-db-mitaka/0f3e3dd/ : SUCCESS in 12m 51s
> 
> ___
> 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] Launch of an instance from a bootable volume fails on Xen env

2016-04-07 Thread Eugen Block


Hi,


did you file a bug for Horizon about this?


I did file a bug for nova about this, but I wasn't sure where to put it.


Zitat von Matthias Runge :


On 24/03/16 12:03, Eugen Block wrote:

Hi,


Has this been resolved?  Is anyone working on this issue?


I had traced down the effect and found a possible solution, see
https://bugs.launchpad.net/nova/+bug/1560965

If you're just trying to start via Horizon, changing
/srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py
ought to fix this for you:

---cut here---
control1:/srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows
# diff -u5 create_instance.py.dist create_instance.py
--- create_instance.py.dist 2016-03-18 10:40:51.123942306 +0100
+++ create_instance.py  2016-03-24 11:49:00.404537704 +0100
@@ -119,11 +119,11 @@



Eugen, did you file a bug for Horizon about this? I would think, that
should be examined carefully.

--
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

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




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


__
OpenStack Development Mailing 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][stable] proposing Rob Cresswell for Horizon stable core

2016-04-07 Thread Timur Sufiev

+1
Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia :

> Im still not sure if non-cores (i.e. peasants like me) can vote but I
> will do it anyway :D
>
> A big +1 from me.
>
> Itxaka
>
> On 04/07/2016 12:01 PM, Matthias Runge wrote:
> > Hello,
> >
> > I'm proposing Rob Cresswell to become stable core for Horizon. I
> > thought, in the past all PTL were in stable team, but this doesn't seem
> > to be true any more.
> >
> > Please chime in with +1/-1
> >
>
> __
> OpenStack Development Mailing 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] RFC Host Maintenance

2016-04-07 Thread Juvonen, Tomi (Nokia - FI/Espoo)

Thanks Sean,

I totally understand your comment and this logic might really be somewhere 
else, not to overload Nova with all kind of things and the level of exposing 
you suggested might then be enough.

Anyhow I am also asking more user or operator perspectives to get more use 
cases. Surely if building this mostly externally (to Nova) those could also be 
added later.

Br,
Tomi

> -Original Message-
> From: EXT Sean Dague [mailto:s...@dague.net]
> Sent: Thursday, April 07, 2016 1:36 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance
> 
> On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote:
> > Hi Nova, Ops, stackers,
> >
> > I am trying to figure out different use cases and requirements there
> > would be for host maintenance and would like to get feedback and
> > transfer all this to spec and discussion what could and should land for
> > Nova or other places.
> >
> > As working in OPNFV Doctor project that has the Telco perspective about
> > related requirements, I started to draft a spec based on something
> > smaller that would be nice to have in Nova and less complicated to have
> > it in single cycle. Anyhow the feedback from Nova API team was to look
> > this as a whole and gather more. This is why asking this here and not
> > just trough spec, to get input for requirements and use cases with wider
> > audience. Here is the draft spec proposing first just maintenance window
> > to be added:
> > _https://review.openstack.org/296995/_
> >
> > Here is link to OPNFV Doctor requirements:
> > _http://artifacts.opnfv.org/doctor/docs/requirements/02-
> use_cases.html#nvfi-maintenance_
> > _http://artifacts.opnfv.org/doctor/docs/requirements/03-
> architecture.html#nfvi-maintenance_
> > _http://artifacts.opnfv.org/doctor/docs/requirements/05-
> implementation.html#nfvi-maintenance_
> >
> > Here is what I could transfer as use cases, but would ask feedback to
> > get more:
> >
> > As admin I want to set maintenance period for certain host.
> >
> > As admin I want to know when host is ready to actions to be done by admin
> > during the maintenance. Meaning physical resources are emptied.
> >
> > As owner of a server I want to prepare for maintenance to minimize
> downtime,
> > keep capacity on needed level and switch HA service to server not
> > affected by
> > maintenance.
> >
> > As owner of a server I want to know when my servers will be down because
> of
> > host maintenance as it might be servers are not moved to another host.
> >
> > As owner of a server I want to know if host is to be totally removed, so
> > instead of keeping my servers on host during maintenance, I want to move
> > them
> > to somewhere else.
> >
> > As owner of a server I want to send acknowledgement to be ready for host
> > maintenance and I want to state if servers are to be moved or kept on
> host.
> > Removal and creating of server is in owner's control already. Optionally
> > server
> > Configuration data could hold information about automatic actions to be
> > done
> > when host is going down unexpectedly or in controlled manner. Also
> > actions at
> > the same if down permanently or only temporarily. Still this needs
> > acknowledgement from server owner as he needs time for application level
> > controlled HA service switchover.
> 
> While I definitely understand the value of these in a deployement, I'm a
> bit concerned of baking all this structured data into Nova itself. As it
> effectively means putting some degree of a ticket management system in
> Nova that's specific to a workflow you've decided on here. Baked in
> workflow is hard to change when the needs of an industry do.
> 
> My counter proposal on your spec was to provide a free form field
> associated with maintenance mode which could contain a url linking to
> the details. This could be a jira ticket, or a REST url for some other
> service. This would actually be much like how we handle images in Nova,
> with a url to glance to find more info.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing 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] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

2016-04-07 Thread Itxaka Serrano Garcia

Im still not sure if non-cores (i.e. peasants like me) can vote but I 
will do it anyway :D


A big +1 from me.

Itxaka

On 04/07/2016 12:01 PM, Matthias Runge wrote:

Hello,

I'm proposing Rob Cresswell to become stable core for Horizon. I
thought, in the past all PTL were in stable team, but this doesn't seem
to be true any more.

Please chime in with +1/-1



__
OpenStack Development Mailing 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] RFC Host Maintenance

2016-04-07 Thread Sean Dague

On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote:
> Hi Nova, Ops, stackers,
>  
> I am trying to figure out different use cases and requirements there
> would be for host maintenance and would like to get feedback and
> transfer all this to spec and discussion what could and should land for
> Nova or other places.
>  
> As working in OPNFV Doctor project that has the Telco perspective about
> related requirements, I started to draft a spec based on something
> smaller that would be nice to have in Nova and less complicated to have
> it in single cycle. Anyhow the feedback from Nova API team was to look
> this as a whole and gather more. This is why asking this here and not
> just trough spec, to get input for requirements and use cases with wider
> audience. Here is the draft spec proposing first just maintenance window
> to be added:
> _https://review.openstack.org/296995/_
>  
> Here is link to OPNFV Doctor requirements:
> _http://artifacts.opnfv.org/doctor/docs/requirements/02-use_cases.html#nvfi-maintenance_
> _http://artifacts.opnfv.org/doctor/docs/requirements/03-architecture.html#nfvi-maintenance_
> _http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html#nfvi-maintenance_
>  
> Here is what I could transfer as use cases, but would ask feedback to
> get more:
>  
> As admin I want to set maintenance period for certain host.
>  
> As admin I want to know when host is ready to actions to be done by admin
> during the maintenance. Meaning physical resources are emptied.
>  
> As owner of a server I want to prepare for maintenance to minimize downtime,
> keep capacity on needed level and switch HA service to server not
> affected by
> maintenance.
>  
> As owner of a server I want to know when my servers will be down because of
> host maintenance as it might be servers are not moved to another host.
>  
> As owner of a server I want to know if host is to be totally removed, so
> instead of keeping my servers on host during maintenance, I want to move
> them
> to somewhere else.
>  
> As owner of a server I want to send acknowledgement to be ready for host
> maintenance and I want to state if servers are to be moved or kept on host.
> Removal and creating of server is in owner's control already. Optionally
> server
> Configuration data could hold information about automatic actions to be
> done
> when host is going down unexpectedly or in controlled manner. Also
> actions at
> the same if down permanently or only temporarily. Still this needs
> acknowledgement from server owner as he needs time for application level
> controlled HA service switchover.

While I definitely understand the value of these in a deployement, I'm a
bit concerned of baking all this structured data into Nova itself. As it
effectively means putting some degree of a ticket management system in
Nova that's specific to a workflow you've decided on here. Baked in
workflow is hard to change when the needs of an industry do.

My counter proposal on your spec was to provide a free form field
associated with maintenance mode which could contain a url linking to
the details. This could be a jira ticket, or a REST url for some other
service. This would actually be much like how we handle images in Nova,
with a url to glance to find more info.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][stable] proposing Rob Cresswell for Horizon stable core

2016-04-07 Thread Matthias Runge

Hello,

I'm proposing Rob Cresswell to become stable core for Horizon. I
thought, in the past all PTL were in stable team, but this doesn't seem
to be true any more.

Please chime in with +1/-1

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

__
OpenStack Development Mailing 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] Component Leads Elections

2016-04-07 Thread Vladimir Kozhukalov

Dear colleagues,

Looks like we have consensus (lazy, but still consensus)
on this topic: we don't need this role CL exposed to Fuel
project. I have prepared a change [1] for our team structure
policy.

My suggestion is to make Fuel is an aggregator
of independent components. Component teams could have their
formal or informal leads (i.e. component PTL) if needed
but it is irrelevant to Fuel as a whole.

As far as Fuel features usually require coordinated changes
in multiple components, we need all Fuel specs to be reviewed
by engineers from different backgrounds.

"Avengers" approach (described above) has been rejected
by Openstack Infra team, but we can use more traditional
core group approach. I.e. Fuel-specs core team is responsible for
reviewing and merging specs and in the proposed patch [1]
it is explicitly written down that each spec must be
approved by at least Puppet, UI, REST SMEs.
It is also a responsibility of Fuel-specs core group
to involve other SMEs if needed.

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



Vladimir Kozhukalov

On Thu, Mar 31, 2016 at 6:47 PM, Serg Melikyan 
wrote:

> Hi fuelers,
>
> only few hours left until period of self-nomination will be closed, but so
> far we don't have neither consensus regarding how to proceed further nor
> candidates.
>
> I've increased period of self-nomination for another week (until April 7,
> 23:59 UTC) and expect to have decision about how we are going to proceed
> further if no one nominate himself or candidates for each of the three
> projects.
>
> I propose to start with defining steps that we are going to take if no one
> nominate himself by April 7 and move forward with separate discussion
> regarding governance.
>
> P.S. I strongly believe that declaring Component Leads role as obsolete
> require agreement among all members of Fuel team, which may take quite a
> lot of time. I think we should propose change-request to existing spec with
> governance [0], and have decision by end of Newton cycle.
>
> References:
> [0]
> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
>
> On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L  wrote:
>
>> Hi,
>>
>> I'm not sure if it's a right place to continue this discussion, but if
>> there are doubts that such role is needed, we should not wait for another
>> half a year to drop it.
>>
>> Also I'm not sure if a single engineer (or two engineers) can handle
>> majority of upcoming patches + specs + meetings around features. Sergii and
>> Igor put a lot of efforts to make it work, but does it really scale?
>>
>> I think it would be better to offload more responsibilities to core
>> groups, and if core team (of specific project) wants to see formal or
>> informal leader, let them decide.
>>
>> I would be really interested to see feedback from current component leads.
>>
>> Thanks,
>>
>>
>> On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dmitry,
>>>
>>> "No need to rush" does not mean we should postpone
>>> team structure changes until Ocata. IMO, CL role
>>> (when it is exposed to Fuel) contradicts to our
>>> modularization activities. Fuel should be an aggregator
>>> of components. What if we decide to use Ironic or
>>> Neutron as Fuel components? Should we chose also
>>> Ironic CL? NO! Ironic is an independent
>>> project with its own PTL.
>>>
>>> I agree with Mike that we could remove this CL
>>> role in a month if have consensus. But does it
>>> make any sense to chose CLs now and then
>>> immediately remove this role? Probably, it is better
>>> to make a decision right now. I'd really like to
>>> see here in this ML thread opinions of our current
>>> CLs and other people.
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
>>> dborodae...@mirantis.com> wrote:
>>>
 On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
 > > I think this call is too late to change a structure for now. I
 suggest
 > > that we always respect the policy we've accepted, and follow it.
 > >
 > > If Component Leads role is under a question, then I'd continue the
 > > discussion, hear opinion of current component leads, and give this
 a time
 > > to be discussed. I'd have nothing against removing this role in a
 month
 > > from now if we reach a consensus on this topic - no need to wait
 for the
 > > cycle end.
 >
 > Sure, there is no need to rush. I'd also like to see current CL
 opinions.

 Considering that, while there's an ongoing discussion on how to change
 Fuel team structure for Ocata, there's also an apparent consensus that
 we still want to have component leads for Newton, I'd like to call once
 again for volunteers to self-nominate for component leads of
 fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
 nomination period is over, and no

[openstack-dev] [Cinder] About snapshot Rollback?

2016-04-07 Thread Chenzongliang

Dear Cruz:

 Thanks for you kind support, I will review the previous spec according 
to the following links.  May be more user scenario we should considered,such as 
backup,create volume from snapshot,consistency group and etc,we will spend some 
time to gather
the user's scenarios and determin what to do next step.

Sincerely,
zongliang chen

发件人: Erlon Cruz [mailto:sombra...@gmail.com]
发送时间: 2016年4月5日 2:50
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Zhangli (ISSP); Shenhong (C)
主题: Re: [openstack-dev] [Cinder] About snapshot Rollback?

Hi Chen,

Not sure if I got you right but I brought this topic in #openstack-cinder some 
days ago. The idea is to be able to rollback a snapshot in Cinder. Today what 
is possible to do is to create a volume from a snapshot. From the user point of 
view, this is not ideal, as there are several cases, if not the majority of, 
that the purpose of the snapshot is to revert to a desired state, and not keep 
the original volume. For some backends, keeping the original volume means space 
consumption. This space problem becomes bold when we think about consistency 
groups. For consistency groups, some backends might have to copy an entire 
filesystem for each snapshot, consuming space and time. So, I think it would be 
desired to have the ability to revert snapshots.

I know there have been efforts in the past[1] to implement that, but for some 
reason the work was stopped. If you want to retake the effort please create a 
spec[2]  sol everybody can provide feedback.

Erlon


[1] 
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
[2] https://github.com/openstack/cinder-specs

On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang 
> wrote:
Hi all:
We are condering add a fucntion rollback_snapshot when we use backup. In 
the end user's scenario. If a vm fails, we hope that we can use snapshot to to 
recovery the volume's data.
Beacuse it can quickly recovery our vm. But if we use the remote data to 
recovery. We will spend more time.
But i'm not sure if the data was recoveried from the backend. whether the 
host need to rescan the volumes? At the same time. If a volume have been 
extended, whether it can be roolback?

   I want to know whether the topic have been discussed or have other 
recommendations to us?

   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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [rally]rally-mysql-py27-unit FAILURE

2016-04-07 Thread Roman Vasilets

Hi, don't panic=) Looks like it is not you fault. I'm watching out for your
patch.

Best regards, Roman Vasilets.

On Thu, Apr 7, 2016 at 10:51 AM, Wu, Liming 
wrote:

> Hi
>
>   I have push a simple patch to rally,  but " Mirantis Rally CI check" was
> not passed.
>   " rally-mysql-py27-unit FAILURE" was occurred. I don't know why. Who I
> Help me. Thx.
>
>   https://review.openstack.org/#/c/302097/
>
>
>   Best regards
>
>   wuliming
>
>
>
>
> __
> OpenStack Development Mailing 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] [kloudbuster] authorization failed problem

2016-04-07 Thread Akshay Kumar Sanghai

Thanks Yichen and Alec.
Yichen, It was what I was looking for. I started with Rally , but faced
problem with defining the number of router per tenant and traffic
generation. Then, I found that there is a new project Kloudbuster. I faced
some issues , but with your help , I succeeded in running it.
One suggestion: I think Rally developers  are also trying for the traffic
generation. So just make sure, we don't have two things for the same work
under the openstack umbrella.
One Request:  I have not contributed to any project till now. I am
interested in contributing to the Kloudbuster project. Please suggest how
to start and help me in getting up to speed.

Regards,
Akshay

On Wed, Apr 6, 2016 at 1:44 PM, Yichen Wang (yicwang) 
wrote:

> Hi, Akshay,
>
>
>
> Just curious, how do you find KloudBuster so far? Does it do its job and
> fit your needs? J
>
>
>
> Thanks very much!
>
>
>
> Regards,
>
> Yichen
>
>
>
> *From:* Alec Hothan (ahothan)
> *Sent:* Tuesday, April 5, 2016 9:54 AM
> *To:* Akshay Kumar Sanghai ; Yichen Wang
> (yicwang) 
> *Cc:* OpenStack List 
>
> *Subject:* Re: [openstack-dev] [kloudbuster] authorization failed problem
>
>
>
>
>
> Akshay,
>
>
>
> Note that version 6 is now released so please use the official image from
> the OpenStack App Catalog and update your code to latest.
>
> The doc has also been updated, you might want to have a look at the new
> arch section and gallery - those should help you with the questions you had
> below regarding the scale test staging and traffic flows.
>
> http://kloudbuster.readthedocs.org/en/latest/index.html
>
>
>
> Thanks
>
>
>
>Alec
>
>
>
>
>
> *From: *Akshay Kumar Sanghai 
> *Date: *Wednesday, March 30, 2016 at 11:11 AM
> *To: *"Yichen Wang (yicwang)" 
> *Cc: *Alec Hothan , OpenStack List <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kloudbuster] authorization failed problem
>
>
>
> Hi Yichen,
>
> Thanks a lot . I will try with v6 and reach out to you for further help.
>
>
>
> Regards,
>
> Akshay
>
>
>
> On Wed, Mar 30, 2016 at 11:35 PM, Yichen Wang (yicwang) 
> wrote:
>
> Hi, Akshay,
>
>
>
> From the log you attached, the good news is you got KloudBuster installed
> and running fine! The problem is the image you are using (v5) is outdated
> for the latest KloudBuster main code. J
>
>
>
> Normally for every version of KloudBuster, it needs certain version of
> image to support the full functionality. In the case when new feature is
> brought in, we tag the main code with a new version, and bump up the image
> version. Like from v5 to v6, we added the capability to support storage
> testing on cinder volume and ephemeral disks as well. We are right in our
> time for publishing the v6 image to the OpenStack App Catalog, which may
> take another day or two. This is why you are seeing the connection to the
> redis agent in KB-Proxy is failing…
>
>
>
> In order to unblock you, here is the RC image of v6 we are using right
> now, replace it in your cloud and KloudBuster should be good to go:
>
> https://cisco.box.com/s/xelzx15swjra5qr0ieafyxnbyucnnsa0
>
>
>
> Now back to your question.
>
> -Does the server side means the cloud generating the traffic and client
> side means the the cloud on which connections are established? Can you
> please elaborate on client, server and proxy?
>
> [Yichen] It is the other way around. Server is running nginx, and client
> is running the traffic generator (wrk2). It is like the way we normally
> understand. Since there might be lots of servers and clients in the same
> cloud, so KB-Proxy is an additional VM that runs in the clients side to
> orchestrate all client VMs to generate traffic, collect the results from
> each VM, and send them back to the main KloudBuster for processing.
> KB-Proxy is the where the redis server is sitting, and acts as the proxy
> node to connect all internal VMs to the external network. This is why a
> floating IP is needed for the proxy node.
>
>
>
> -while running the kloudbuster, I saw "setting up redis connection". Can
> you please expain to which connection is established and why? Is it
> KB_PROXY?
>
> [Yichen] As I explained above, KB-Proxy is the bridge between internal VM
> and external world (like the host you are running KloudBuster from).
> “Setting up redis connection” means the KloudBuster is trying to connect to
> the redis server on the KB-Proxy node. You may see some retries because it
> does take some time for the VM to be up running.
>
>
>
> Thanks very much!
>
>
>
> Regards,
>
> Yichen
>
>
>
> *From:* Akshay Kumar Sanghai [mailto:akshaykumarsang...@gmail.com]
> *Sent:* Wednesday, March 30, 2016 7:31 AM
> *To:* Alec Hothan (ahothan) 
> *Cc:* OpenStack List ; Yichen Wang
> (yicwang) 
>
>
>

[openstack-dev] [release][release] reno 1.6.2 release

We are pleased to announce the release of:

reno 1.6.2: RElease NOtes manager

With source available at:

http://git.openstack.org/cgit/openstack/reno

Please report issues through launchpad:

http://bugs.launchpad.net/reno

For more details, please see below.

Changes in reno 1.6.1..1.6.2


11a2b7a default to collapsing pre-releases in sphinxext

Diffstat (except docs and test files)
-

reno/sphinxext.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)




__
OpenStack Development Mailing 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] Sorry for the recent flurry of announce emails

2016-04-07 Thread Doug Hellmann

Hi!

We are sorry for the recent flurry of announce emails. We are preparing
for the final Mitaka release and an error in the build script led to
prematurely sending erroneous release announcements.

While the version numbers are correct, those announcements contain only
partial release notes (usually only mentioning post-RC1 changes). A more
complete Mitaka announcement is going to be sent in the coming hours,
once we finalize the mitaka release notes.

Thanks for your understanding and patience,
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] [Tricircle] Original Blueprint

All clear.

Cheers,
Shinobu

On Thu, Apr 7, 2016 at 5:21 PM, joehuang  wrote:
> Yes, of course.
>
> And in Newton release, we want to use BP + spec for review and approve for 
> new features, just like https://review.openstack.org/#/c/282180/.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 4:16 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Tricircle] Original Blueprint
>
> Hi Chaoyi,
>
> Just to clarify more.
>
> On Thu, Apr 7, 2016 at 5:02 PM, joehuang  wrote:
>> Hi, Shinobu,
>>
>> Thanks for your review. Just replied in the google doc, that the table is 
>> the latest design, not old one, and some fields need to be implemented in 
>> new patches.
>
> I'm now expecting that *blueprint* is always master; meaning that anyone who 
> would contribute to the Tricircle need to refer, follow *blueprint*.
>
> Is it same of what you are thinking of?
>
> Cheers,
> Shinobu
>
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Thursday, April 07, 2016 12:44 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Tricircle] Original Blueprint
>>
>> Hi Chaoyi,
>>
>> In blueprint you described for PoC, there are information of tables. [1] 
>> They seem to out-to-date.
>>
>> Do you think that those information need to be up-to-date in your blueprint?
>> If it's not necessary, it's better to move those information to different 
>> sheet or put some comment like "Won't be updated", I think.
>>
>> [1]
>> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l
>> 2zNqMEd3g
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>>  OpenStack Development Mailing 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
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] Original Blueprint

Yes, of course. 

And in Newton release, we want to use BP + spec for review and approve for new 
features, just like https://review.openstack.org/#/c/282180/.

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Thursday, April 07, 2016 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Tricircle] Original Blueprint

Hi Chaoyi,

Just to clarify more.

On Thu, Apr 7, 2016 at 5:02 PM, joehuang  wrote:
> Hi, Shinobu,
>
> Thanks for your review. Just replied in the google doc, that the table is the 
> latest design, not old one, and some fields need to be implemented in new 
> patches.

I'm now expecting that *blueprint* is always master; meaning that anyone who 
would contribute to the Tricircle need to refer, follow *blueprint*.

Is it same of what you are thinking of?

Cheers,
Shinobu

>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 12:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] Original Blueprint
>
> Hi Chaoyi,
>
> In blueprint you described for PoC, there are information of tables. [1] They 
> seem to out-to-date.
>
> Do you think that those information need to be up-to-date in your blueprint?
> If it's not necessary, it's better to move those information to different 
> sheet or put some comment like "Won't be updated", I think.
>
> [1] 
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l
> 2zNqMEd3g
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
>  OpenStack Development Mailing 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



--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] Original Blueprint

Hi Chaoyi,

Just to clarify more.

On Thu, Apr 7, 2016 at 5:02 PM, joehuang  wrote:
> Hi, Shinobu,
>
> Thanks for your review. Just replied in the google doc, that the table is the 
> latest design, not old one, and some fields need to be implemented in new 
> patches.

I'm now expecting that *blueprint* is always master; meaning that
anyone who would contribute to the Tricircle need to refer, follow
*blueprint*.

Is it same of what you are thinking of?

Cheers,
Shinobu

>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 12:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] Original Blueprint
>
> Hi Chaoyi,
>
> In blueprint you described for PoC, there are information of tables. [1] They 
> seem to out-to-date.
>
> Do you think that those information need to be up-to-date in your blueprint?
> If it's not necessary, it's better to move those information to different 
> sheet or put some comment like "Won't be updated", I think.
>
> [1] 
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] UUID Mapping

Hi Chaoyi,

Thank you for your reply.
All clear.

Cheers,
Shinobu

On Thu, Apr 7, 2016 at 5:00 PM, joehuang  wrote:
> Hi, Shinobu,
>
> This part has been deleted just few minutes ago. No UUID mapping in stateless 
> design, but a resource routing table is used there, but read the "7.2 
> Resource Routing Table".
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 2:35 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] UUID Mapping
>
> Hi Team,
>
> Can we elaborate on uuid mapping more?
> As described in blueprint, it's expected to be a solution for one of 
> challenges.
>
>> The object UUID in the top layer is different from the UUIDs in the bottom 
>> layers.
>
> There should theoretical logic, mechanism. But I've not been able to find any 
> docs about that.
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] UUID Mapping

Hi, Shinobu,

This part has been deleted just few minutes ago. No UUID mapping in stateless 
design, but a resource routing table is used there, but read the "7.2 Resource 
Routing Table".

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Thursday, April 07, 2016 2:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Tricircle] UUID Mapping

Hi Team,

Can we elaborate on uuid mapping more?
As described in blueprint, it's expected to be a solution for one of challenges.

> The object UUID in the top layer is different from the UUIDs in the bottom 
> layers.

There should theoretical logic, mechanism. But I've not been able to find any 
docs about that.

Cheers,
Shinobu

--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] Original Blueprint

Hi, Shinobu,

Thanks for your review. Just replied in the google doc, that the table is the 
latest design, not old one, and some fields need to be implemented in new 
patches.

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Thursday, April 07, 2016 12:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Tricircle] Original Blueprint

Hi Chaoyi,

In blueprint you described for PoC, there are information of tables. [1] They 
seem to out-to-date.

Do you think that those information need to be up-to-date in your blueprint?
If it's not necessary, it's better to move those information to different sheet 
or put some comment like "Won't be updated", I think.

[1] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g

Cheers,
Shinobu

--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] OVS flow modification performance

2016-04-07 Thread IWAMOTO Toshihiro

At Thu, 07 Apr 2016 16:33:02 +0900,
IWAMOTO Toshihiro wrote:
> 
> At Mon, 18 Jan 2016 12:12:28 +0900,
> IWAMOTO Toshihiro wrote:
> > 
> > I'm sending out this mail to share the finding and discuss how to
> > improve with those interested in neutron ovs performance.
> > 
> > TL;DR: The native of_interface code, which has been merged recently
> > and isn't default, seems to consume less CPU time but gives a mixed
> > result.  I'm looking into this for improvement.
> 
> I went on to look at implementation details of eventlet etc, but it
> turned out to be fairly simple.  The OVS agent in the
> of_interface=native mode waits for a openflow connection from
> ovs-vswitchd, which can take up to 5 seconds.
> 
> Please look at the attached graph.
> The x-axis is time from agent restarts, the y-axis is numbers of ports
> processed (in treat_devices and bind_devices).  Each port is counted
> twice; the first slope is treat_devices and the second is
> bind_devices.  The native of_interface needs some more time on
> start-up, but bind_devices is about 2x faster.
> 
> The data was collected with 160 VMs with the devstack default settings.

And if you wonder how other services are doing meanwhile, here is a
bonus chart.

The ovs agent was restarted 3 times with of_interface=native, then 3
times with of_interface=ovs-ofctl.

As the test machine has 16 CPUs, 6.25% CPU usage can mean a single
threaded process is CPU bound.

Frankly, the OVS agent would have little rooms for improvement than
other services.  Also, it might be fun to draw similar charts for
other types of workloads.

__
OpenStack Development Mailing 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] [rally]rally-mysql-py27-unit FAILURE

2016-04-07 Thread Wu, Liming

Hi

  I have push a simple patch to rally,  but " Mirantis Rally CI check" was not 
passed.
  " rally-mysql-py27-unit FAILURE" was occurred. I don't know why. Who I Help 
me. Thx.

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


  Best regards

  wuliming




__
OpenStack Development Mailing 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] Launch of an instance from a bootable volume fails on Xen env

2016-04-07 Thread Matthias Runge

On 24/03/16 12:03, Eugen Block wrote:
> Hi,
> 
>> Has this been resolved?  Is anyone working on this issue?
> 
> I had traced down the effect and found a possible solution, see
> https://bugs.launchpad.net/nova/+bug/1560965
> 
> If you're just trying to start via Horizon, changing
> /srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py
> ought to fix this for you:
> 
> ---cut here---
> control1:/srv/www/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows
> # diff -u5 create_instance.py.dist create_instance.py
> --- create_instance.py.dist 2016-03-18 10:40:51.123942306 +0100
> +++ create_instance.py  2016-03-24 11:49:00.404537704 +0100
> @@ -119,11 +119,11 @@


Eugen, did you file a bug for Horizon about this? I would think, that
should be examined carefully.

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

__
OpenStack Development Mailing 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] OVS flow modification performance

2016-04-07 Thread IWAMOTO Toshihiro

At Mon, 18 Jan 2016 12:12:28 +0900,
IWAMOTO Toshihiro wrote:
> 
> I'm sending out this mail to share the finding and discuss how to
> improve with those interested in neutron ovs performance.
> 
> TL;DR: The native of_interface code, which has been merged recently
> and isn't default, seems to consume less CPU time but gives a mixed
> result.  I'm looking into this for improvement.

I went on to look at implementation details of eventlet etc, but it
turned out to be fairly simple.  The OVS agent in the
of_interface=native mode waits for a openflow connection from
ovs-vswitchd, which can take up to 5 seconds.

Please look at the attached graph.
The x-axis is time from agent restarts, the y-axis is numbers of ports
processed (in treat_devices and bind_devices).  Each port is counted
twice; the first slope is treat_devices and the second is
bind_devices.  The native of_interface needs some more time on
start-up, but bind_devices is about 2x faster.

The data was collected with 160 VMs with the devstack default settings.

> * Introduction
> 
> With an ML2+ovs Neutron configuration, openflow rule modification
> happens often and is somewhat a heavy operation as it involves
> exec() of the ovs-ofctl command.
> 
> The native of_interface driver doesn't use the ovs-ofctl command and
> should have less performance impact on the system.  This document
> tries to confirm this hypothesis.
> 
> 
> * Method
> 
> In order to focus on openflow rule operation time and avoid noise from
> other operations (VM boot-up, etc.), neutron-openvswitch-agent was
> restarted and the time it took to reconfigure the flows was measured.
> 
> 1. Use devstack to start a test environment.  As debug logs generate
>considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
> 2. Apply https://review.openstack.org/#/c/267905/ to enable
>measurement of flow reconfiguration times.
> 3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
>flows.  If you have >16G RAM, more could be booted.
> 4. Stop neutron-openvswitch-agent and restart with --run-once arg.
>Use time, oprofile, and python's cProfile (use --profile arg) to
>collect data.
> 
> * Results
> 
> Execution time (averages of 3 runs):
> 
> native 28.3s user 2.9s sys 0.4s
> ovs-ofctl  25.7s user 2.2s sys 0.3s
> 
> ovs-ofctl runs faster and seems to use less CPU, but the above doesn't
> count in execution time of ovs-ofctl.

With 160 VMs and debug=false for the OVS agent and the neutron-server,

Execution time (averages and SDs of 10 runs):

native 56.4+-3.4s  user 8.7+-0.1s   sys 0.82+-0.04s
ovs-ofctl  55.9+-1.0s  user 6.9+-0.08s  sys 0.67+-0.05s

To exclude the openflow connection waits,
times between log outputs of "Loaded agent extensions" and
"Configuration for devices up completed" is also compared:

native 48.2+-0.49s
ovs-ofctl  53.2+-0.99s

The native of_interface is the clear winner.

> Oprofile data collected by running "operf -s -t" contain the
> information.
> 
> With of_interface=native config, "opreport tgid:" shows:
> 
>samples|  %|
> --
> 87408 100.000 python2.7
>   CPU_CLK_UNHALT...|
> samples|  %|
>   --
>   69160 79.1232 python2.7
>8416  9.6284 vmlinux-3.13.0-24-generic
> 
> and "opreport --merge tgid" doesn't show ovs-ofctl.
> 
> With of_interface=ovs-ofctl, "opreport tgid:" shows:
> 
>samples|  %|
> --
> 62771 100.000 python2.7
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 49418 78.7274 python2.7
>  6483 10.3280 vmlinux-3.13.0-24-generic
> 
> and  "opreport --merge tgid" shows CPU consumption by ovs-ofctl 
> 
> 35774  3.5979 ovs-ofctl
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 28219 78.8813 vmlinux-3.13.0-24-generic
>  3487  9.7473 ld-2.19.so
>  2301  6.4320 ovs-ofctl
> 
> Comparing 87408 (native python) with 62771+35774, the native
> of_interface uses 0.4s less CPU time overall.
> 
> * Conclusion and future steps
> 
> The native of_interface uses slightly less CPU time but takes longer
> time to complete a flow reconfiguration after an agent restart.
> 
> As an OVS agent accounts for only 1/10th of total CPU usage during a
> flow reconfiguration (data not shown), there may be other areas for
> improvement.
> 
> The cProfile Python module gives more fine grained data, but no
> apparent performance bottleneck was found.  The data show more
> eventlet context switches with the native of_interface, which is due
> to how the native of_interface is written.  I'm looking into for
> improving CPU usage and latency.



of_int-comparison.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for

[openstack-dev] [Nova] RFC Host Maintenance

2016-04-07 Thread Juvonen, Tomi (Nokia - FI/Espoo)

Hi Nova, Ops, stackers,

I am trying to figure out different use cases and requirements there would be
for host maintenance and would like to get feedback and transfer all this to
spec and discussion what could and should land for Nova or other places.

As working in OPNFV Doctor project that has the Telco perspective about related
requirements, I started to draft a spec based on something smaller that would
be nice to have in Nova and less complicated to have it in single cycle. Anyhow
the feedback from Nova API team was to look this as a whole and gather more.
This is why asking this here and not just trough spec, to get input for
requirements and use cases with wider audience. Here is the draft spec
proposing first just maintenance window to be added:
https://review.openstack.org/296995/

Here is link to OPNFV Doctor requirements:
http://artifacts.opnfv.org/doctor/docs/requirements/02-use_cases.html#nvfi-maintenance
http://artifacts.opnfv.org/doctor/docs/requirements/03-architecture.html#nfvi-maintenance
http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html#nfvi-maintenance

Here is what I could transfer as use cases, but would ask feedback to get more:

As admin I want to set maintenance period for certain host.

As admin I want to know when host is ready to actions to be done by admin
during the maintenance. Meaning physical resources are emptied.

As owner of a server I want to prepare for maintenance to minimize downtime,
keep capacity on needed level and switch HA service to server not affected by
maintenance.

As owner of a server I want to know when my servers will be down because of
host maintenance as it might be servers are not moved to another host.

As owner of a server I want to know if host is to be totally removed, so
instead of keeping my servers on host during maintenance, I want to move them
to somewhere else.

As owner of a server I want to send acknowledgement to be ready for host
maintenance and I want to state if servers are to be moved or kept on host.
Removal and creating of server is in owner's control already. Optionally server
Configuration data could hold information about automatic actions to be done
when host is going down unexpectedly or in controlled manner. Also actions at
the same if down permanently or only temporarily. Still this needs
acknowledgement from server owner as he needs time for application level
controlled HA service switchover.

Br,
Tomi

Re: [openstack-dev] [osc] Meeting time preferences for OSC team

2016-04-07 Thread Sheel Rana Insaan

Dear All,

Thanks for sharing preffered time.

Common votes seems for below time options

E.4 - Thursday at 1600 UTC in #openstack-meeting (IRC webclient)
O.3 - Thursday at 1900 UTC in #openstack-meeting (IRC webclient)

Lets discuss and finalize this time in today's meeting at 1900 UTC in
#openstack-meeting .

Best Regards,
Sheel Rana

*From:* Richard Theis [mailto:rth...@us.ibm.com ]
*Sent:* Tuesday, April 5, 2016 9:14 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* [openstack-dev] [osc] Meeting time preferences for OSC team



Here are my preferences:

1. even week: E.1 or E.4
2. odd week: O.3

Thanks,
Richard

> Dear All,
>
> This is regarding deciding meeting time for OSC team to facilitate
> appropriate time for APAC guys.
> We are planning to have meeting on alternate weeks for this purpose.
>
> Some of the suggestions are:
>
> *E.1* Every two weeks (on even weeks) on Thursday at 1300 UTC in
> #openstack-meeting (IRC webclient)
> *E.2* Every two weeks (on even weeks) on Tuesday at 1500 UTC in
> #openstack-meeting (IRC webclient)
> *E.3* Every two weeks (on even weeks) on Friday at 1500 UTC in
> #openstack-meeting-4 (IRC webclient)
> *E.4* Every two weeks (on even weeks) on Thursday at 1600 UTC in
> #openstack-meeting (IRC webclient)
>
> *O.1* Every two weeks (on odd weeks) on Tuesday at 1400 UTC in
> #openstack-meeting-4 (IRC webclient)
> *O.2* Every two weeks (on odd weeks) on Wednesday at 1400 UTC in
> #openstack-meeting-3 (IRC webclient)
> *O.3* Every two weeks (on odd/even weeks) on Thursday at 1900 UTC in
> #openstack-meeting (IRC webclient)  -- our regular meeting time
>
> Kindly share your preffered time(select only one for each even/odd weeks
> and share in your response in below format).
>
> 1. even week: *E.1/E.2/E.3/E.4*/  ?
> 2. odd week:  *O.1/O.2/O.3*  ?
>
> (response sample):
> 1. even week: *E.2*
> 2. odd week: *O.3*
>
> Best Regards,
> Sheel Rana
__
OpenStack Development Mailing 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] [Tricircle] UUID Mapping