Re: [openstack-dev] [grenade] upgrades vs rootwrap

[Angus Lees]

Ok, thanks for the in-depth explanation.

My take away is that we need to file any rootwrap updates as exceptions for
now (so releasenotes and grenade scripts).

 - Gus

On Mon, 27 Jun 2016 at 21:25 Sean Dague  wrote:

> On 06/26/2016 10:02 PM, Angus Lees wrote:
> > On Fri, 24 Jun 2016 at 20:48 Sean Dague  > > wrote:
> >
> > On 06/24/2016 05:12 AM, Thierry Carrez wrote:
> > > I'm adding Possibility (0): change Grenade so that rootwrap
> > filters from
> > > N+1 are put in place before you upgrade.
> >
> > If you do that as general course what you are saying is that every
> > installer and install process includes overwriting all of rootwrap
> > before every upgrade. Keep in mind we do upstream upgrade as offline,
> > which means that we've fully shut down the cloud. This would remove
> the
> > testing requirement that rootwrap configs were even compatible
> between N
> > and N+1. And you think this is theoretical, you should see the
> patches
> > I've gotten over the years to grenade because people didn't see an
> issue
> > with that at all. :)
> >
> > I do get that people don't like the constraints we've self imposed,
> but
> > we've done that for very good reasons. The #1 complaint from
> operators,
> > for ever, has been the pain and danger of upgrading. That's why we
> are
> > still trademarking new Juno clouds. When you upgrade Apache, you
> don't
> > have to change your config files.
> >
> >
> > In case it got lost, I'm 100% on board with making upgrades safe and
> > straightforward, and I understand that grenade is merely a tool to help
> > us test ourselves against our process and not an enemy to be worked
> > around.  I'm an ops guy proud and true and hate you all for making
> > openstack hard to upgrade in the first place :P
> >
> > Rootwrap configs need to be updated in line with new rootwrap-using code
> > - that's just the way the rootwrap security mechanism works, since the
> > security "trust" flows from the root-installed rootwrap config files.
> >
> > I would like to clarify what our self-imposed upgrade rules are so that
> > I can design code within those constraints, and no-one is answering my
> > question so I'm just getting more confused as this thread progresses...
> >
> > ***
> > What are we trying to impose on ourselves for upgrades for the present
> > and near future (ie: while rootwrap is still a thing)?
> > ***
> >
> > A. Sean says above that we do "offline" upgrades, by which I _think_ he
> > means a host-by-host (or even global?) "turn everything (on the same
> > host/container) off, upgrade all files on disk for that host/container,
> > turn it all back on again".  If this is the model, then we can trivially
> > update rootwrap files during the "upgrade" step, and I don't see any
> > reason why we need to discuss anything further - except how we implement
> > this in grenade.
> >
> > B. We need to support a mix of old + new code running on the same
> > host/container, running against the same config files (presumably
> > because we're updating service-by-service, or want to minimise the
> > service-unavailability during upgrades to literally just a process
> > restart).  So we need to think about how and when we stage config vs
> > code updates, and make sure that any overlap is appropriately allowed
> > for (expand-contract, etc).
> >
> > C. We would like to just never upgrade rootwrap (or other config) files
> > ever again (implying a freeze in as_root command lines, effective ~a
> > year ago).  Any config update is an exception dealt with through
> > case-by-case process and release notes.
> >
> >
> > I feel like the grenade check currently implements (B) with a 6 month
> > lead time on config changes, but the "theory of upgrade" doc and our
> > verbal policy might actually be (C) (see this thread, eg), and Sean
> > above introduced the phrase "offline" which threw me completely into
> > thinking maybe we're aiming for (A).  You can see why I'm looking for
> > clarification  ;)
>
> Ok, there is theory of what we are striving for, and there is what is
> viable to test consistently.
>
> The thing we are shooting for is making the code Continuously
> Deployable. Which means the upgrade process should be "pip install -U
> $foo && $foo-manage db-sync" on the API surfaces and "pip install -U
> $foo; service restart" on everything else.
>
> Logic we can put into the python install process is common logic shared
> by all deployment tools, and we can encode it in there. So all
> installers just get it.
>
> The challenge is there is no facility for config file management in
> python native packaging. Which means that software which *depends* on
> config files for new or even working features now moves from the camp of
> CDable to manual upgrade needed. What you need to do is in releasenotes,
> not in code that's shipped with your software. Release notes are not

Re: [openstack-dev] Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

[Na Zhu]

Hi Cathy,

Thanks your response.
Another question, how to create different port-chains for different 
tenants, and these chains consist of the same port pair group. In my test 
scenario, port-pair-group created by tenant A is not visible for tenant B.




Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Cathy Zhang 
To: Na Zhu/China/IBM@IBMCN, Henry Fourie , 
"OpenStack Development Mailing List (not for usage questions)" 

Cc: Ryan Moats , Kyle Mestery 
, Russell Bryant , Richard Theis 
, Stephen Wong , Vikram 
Choudhary , Farhad Sunavala 
, "John McDowall" 
Date:   2016/06/28 12:29
Subject:RE: Change in openstack/networking-sfc[master]: 
Networking-sfc / OVN Driver



Hi Na,

Please see inline for my reply.

Cathy

-Original Message-
From: Na Zhu (Code Review) [mailto:rev...@openstack.org] 
Sent: Monday, June 27, 2016 8:08 PM
To: Henry Fourie
Cc: Ryan Moats; Na Zhu; Kyle Mestery; Russell Bryant; Richard Theis; 
Stephen Wong; Cathy Zhang; Vikram Choudhary; Farhad Sunavala; John 
McDowall
Subject: Change in openstack/networking-sfc[master]: Networking-sfc / OVN 
Driver

Na Zhu has posted comments on this change.

Change subject: Networking-sfc / OVN Driver 
..


Patch Set 1:

(1 comment)

https://review.openstack.org/#/c/333172/1/doc/source/sfc_ovn_driver.rst
File doc/source/sfc_ovn_driver.rst:

Line 88: +-+   +-+ outport +===+
> Agree that it is better to clarify these points. 
Hi Cathy,
I try to create multiple port-chains with the same port-pair-group, it 
failed. I think it is not allowed to do what you said, right?
(neutron) port-chain-create --flow-classifier fc --port-pair-group pg1 pc1 
Port Pair Group(s) [u'17c9a0a5-a38f-4a75-834e-9aa213cd431f'] in use by 
Port Chain f3af530f-210a-4c51-9a02-f1835d5b1d85.
Neutron server returns request_ids: 
['req-47e6a39b-677a-4ce3-9976-5dfcee0ac47f']
(neutron)

Cathy> when a port pair group is shared by multiple chains, these chains 
should be different, which means these chains should consist of different 
sequences of port pair groups. For example, chain 1 consists of 
 and chain 2 consists of 
"port-pair-group1, port-pair-group3, port-pair-group4>. But if the two 
chains are the same, i.e. they consist of the same sequence of 
port-pair-groups (e.g. the two chains both consist of ), 
then it is not allowed since it does not make sense to create the same 
chain twice. Maybe your test scenario falls into the second case?



-- 
To view, visit https://review.openstack.org/333172
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5c1827dcc81e48983a41120ec08983c571c5b2e9
Gerrit-PatchSet: 1
Gerrit-Project: openstack/networking-sfc
Gerrit-Branch: master
Gerrit-Owner: Louis Fourie 
Gerrit-Reviewer: Farhad Sunavala 
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: John McDowall 
Gerrit-Reviewer: Kyle Mestery 
Gerrit-Reviewer: Louis Fourie 
Gerrit-Reviewer: Na Zhu 
Gerrit-Reviewer: Richard Theis 
Gerrit-Reviewer: Russell Bryant 
Gerrit-Reviewer: Ryan Moats 
Gerrit-Reviewer: Stephen Wong 
Gerrit-Reviewer: cathy 
Gerrit-Reviewer: vikram.choudhary 
Gerrit-HasComments: Yes



__
OpenStack Development Mailing 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] [craton] OneOps CMS demo

[Jim Baker]

Just to correct the UTC time based on the calendar invite I got for this
discussion:

We are meeting at *1600 UTC*, or 9am PDT

At some point, we should just set our calendars to only
use Atlantic/Reykjavik (= UTC) and stop doing the timezone arithmetic :)

On Mon, Jun 27, 2016 at 3:11 PM, sean roberts 
wrote:

> Vitaliy is available 9:00 PDT, 15:00 GMT tomorrow. Let's use webex link
> here
> https://walmart.webex.com/walmart/j.php?MTID=m2e306e0b4a7fec980b21cdc5a02f7815
>
> This is about the option to fork CMS for use in Craton. Everyone join in!
>
>
> --
> ~sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

[Cathy Zhang]

Hi Na,

Please see inline for my reply.

Cathy

-Original Message-
From: Na Zhu (Code Review) [mailto:rev...@openstack.org] 
Sent: Monday, June 27, 2016 8:08 PM
To: Henry Fourie
Cc: Ryan Moats; Na Zhu; Kyle Mestery; Russell Bryant; Richard Theis; Stephen 
Wong; Cathy Zhang; Vikram Choudhary; Farhad Sunavala; John McDowall
Subject: Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

Na Zhu has posted comments on this change.

Change subject: Networking-sfc / OVN Driver 
..


Patch Set 1:

(1 comment)

https://review.openstack.org/#/c/333172/1/doc/source/sfc_ovn_driver.rst
File doc/source/sfc_ovn_driver.rst:

Line 88: +-+   +-+ outport +===+
> Agree that it is better to clarify these points. 
Hi Cathy,
I try to create multiple port-chains with the same port-pair-group, it failed. 
I think it is not allowed to do what you said, right?
(neutron) port-chain-create --flow-classifier fc --port-pair-group pg1 pc1 Port 
Pair Group(s) [u'17c9a0a5-a38f-4a75-834e-9aa213cd431f'] in use by Port Chain 
f3af530f-210a-4c51-9a02-f1835d5b1d85.
Neutron server returns request_ids: ['req-47e6a39b-677a-4ce3-9976-5dfcee0ac47f']
(neutron)

Cathy> when a port pair group is shared by multiple chains, these chains should 
be different, which means these chains should consist of different sequences of 
port pair groups. For example, chain 1 consists of  and chain 2 consists of "port-pair-group1, port-pair-group3, 
port-pair-group4>. But if the two chains are the same, i.e. they consist of the 
same sequence of port-pair-groups (e.g. the two chains both consist of 
), then it is not allowed since it does not make sense to 
create the same chain twice. Maybe your test scenario falls into the second 
case?



-- 
To view, visit https://review.openstack.org/333172
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5c1827dcc81e48983a41120ec08983c571c5b2e9
Gerrit-PatchSet: 1
Gerrit-Project: openstack/networking-sfc
Gerrit-Branch: master
Gerrit-Owner: Louis Fourie 
Gerrit-Reviewer: Farhad Sunavala 
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: John McDowall 
Gerrit-Reviewer: Kyle Mestery 
Gerrit-Reviewer: Louis Fourie 
Gerrit-Reviewer: Na Zhu 
Gerrit-Reviewer: Richard Theis 
Gerrit-Reviewer: Russell Bryant 
Gerrit-Reviewer: Ryan Moats 
Gerrit-Reviewer: Stephen Wong 
Gerrit-Reviewer: cathy 
Gerrit-Reviewer: vikram.choudhary 
Gerrit-HasComments: Yes
__
OpenStack Development Mailing 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] Do we require the 'next' link for paging, always?

[Alex Xu]

Matt, thanks for the email, I +1 on the next page link. Then user needn't
build up link by themself.

I also have one more question after review those pagination patches:

As those pagination proposes change the default sort order. So should we
keep the sort order for old version API?
I think it should be yes. For instance-actions, it should keep the
order sorted by 'create_at' column in old versionAPI. The new version API
will sort the result by 'updated_at' column.
But the question for keypairs and hypervisors, looks like they didn't
specify the sort order explicitly, so I think they should depend on the DB
implementation. Should we keep the old version API unspecified sort order?



2016-06-28 3:07 GMT+08:00 Matt Riedemann :

> There are at least two changes up that add paging support to the API, one
> for hypervisors and one for keypairs. Alex Xu pointed out in one of them
> that they didn't have a 'next' link in the response for paging, which is
> created here for the server/image/flavor view builders:
>
>
> https://github.com/openstack/nova/blob/6e8c84d0cd7651b465cf9bb7ad68a9b24b3658c9/nova/api/openstack/common.py#L448
>
> None of the REST API big-whigs were in channel for me to confirm, but I
> assume we want this in any API that supports paging. Yes?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] ha & upgrade jobs are broken

[Emilien Macchi]

CI is still in bad shape, even if we fixed non-ha job [1].

See https://bugs.launchpad.net/tripleo/+bug/1596758 for the new issue
(ha & upgrade job look broken), it seems related to Pacemaker.
I investigated a little bit (late here) and it seems like a problem
with Pacemaker (/var/log/host_info.txt on controller-1 shows a timeout
when trying to contact the cluster).

If anyone can look during the morning, otherwise I'll continue
tomorrow. Any help is warmly welcome!

Thanks,

[1] https://review.openstack.org/#/c/334555/
-- 
Emilien Macchi

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

Re: [openstack-dev] [tricircle] About registering and loading a plugin

[Vega Cai]

Hi Yipei,

You can also refer to my network type driver implementation:

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

Type driver is registered in setup.cfg and loaded by code.

BR
Zhiyuan

On 27 June 2016 at 21:44, Yipei Niu  wrote:

> Dear all,
>
> Recently, I learn to name a plugin based on the doc
> http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I
> define a new entry_point for the plugin, then it fails. The console prompts
> "stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found,
> looking for 'simple'". After setting a new entry_point with setuptools, why
> stevedore cannot find the driver based on the entry_point?
>
> Best regards,
> Yipei
>
__
OpenStack Development Mailing 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] About registering and loading a plugin

[joehuang]

Hello, Yipei,



You can use entry point inspector to check whether there is some error in the 
plugin registration and loading:



sudo pip install entry_point_inspector

epi group list

epi group show 
epi ep show 



https://pypi.python.org/pypi/entry_point_inspector



If there is some error when loading the plugin, you may find error information 
the show command.



Best Regards

Chaoyi Huang ( joehuang )


From: Yipei Niu [newy...@gmail.com]
Sent: 27 June 2016 21:44
To: OpenStack Development Mailing List (not for usage questions)
Cc: joehuang; Zhiyuan Cai; ski...@redhat.com; 金城 忍
Subject: [tricircle] About registering and loading a plugin

Dear all,

Recently, I learn to name a plugin based on the doc 
http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I define a 
new entry_point for the plugin, then it fails. The console prompts 
"stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found, looking 
for 'simple'". After setting a new entry_point with setuptools, why stevedore 
cannot find the driver based on the entry_point?

Best regards,
Yipei
__
OpenStack Development Mailing 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] Proposal: Architecture Working Group

[darren chan]

It appears this group could assist with the Architecture Design Guide, which is 
undergoing a content restructure. We are looking for more technical 
contributors to provide guidance and contribute information to the guide. Shaun 
O'Meara has written a spec: 
https://specs.openstack.org/openstack/docs-specs/specs/newton/arch-guide-restructure.html.
        
If you are interested in helping out, contact Shilla or me, or feel free to 
join our biweekly Ops Guide/Arch Guide Specialty team meeting. For more 
details, see https://wiki.openstack.org/wiki/Documentation/OpsGuide.

Thanks!


On Saturday, 25 June 2016, 2:50, Clint Byrum  wrote:
 

 Excerpts from Zhipeng Huang's message of 2016-06-24 18:15:30 +0200:
> Hi Clint and Amrith,
> 
> Are you guys already working on the proposal ? Is there any public access
> to see the first draft ?
> 

I've started writing something up, and I hope to submit it for review
next week.

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

[Sam P]

Hi Nalaka,

 FYI.
 In addition to Jay's advice, I recommend you to follow the work of
 openstack Scientific working group
https://wiki.openstack.org/wiki/Scientific_working_group.
 If you have any special project in mind then go for it.
 Otherwise, work of the above WG (working group) would be a grate
place to know what other researchers/scientists/academics do with
openstack.

--- Regards,
Sampath



On Tue, Jun 28, 2016 at 1:54 AM, Jay Faulkner  wrote:
> Hi and welcome
>
> https://wiki.openstack.org/wiki/How_To_Contribute will have some information
> on different ways to contribute. If you have a specific project in mind, I'd
> suggest searching on their bugtracker for 'low-hanging-fruit'. Either one of
> those bugs, or any issues/bugs you see in developer documentation are great
> choices for getting started. If you have any trouble, asking in IRC is often
> a quick way to get over a problem, but most of it's documented pretty well
> so make sure to exhaust the docs first.
>
> Good luck + thanks,
> Jay Faulkner
> OSIC
>
> On Jun 27, 2016, at 9:10 AM, Nalaka Rajamanthri 
> wrote:
>
> Hi,
> I am new to the open source community. I would like to contribute to the
> openstack. So I would like to help this project by solving bugs.
>
> Best Regards,
> Nalaka Rajamanthri,
> University of Peradeniya (undergraduate)
> __
> OpenStack Development Mailing 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] [Fuel] Replace OSTF with Rally

[Boris Pavlovic]

Igor,


I wonder what are the benefits of using Rally then? We can run whatever we
> want by means of MCollective or Ansible. Is there something that could help
> us? I don't know, maybe some dashboard integration with per test results or
> running by tests by tag?


Benefits are in the Rally framework, engine and integrated tooling, that
are doing very hard things to provide simple interfaces for writing simple
plugins that are emulating complicated test cases.

The major benefits are next:

*1) Generalization*
1.1) One tool with one reporting system and one output format for all kinds
of testing strategies (functional, load, perf, scale, ...)
1.2) One set of plugins (code) that can be used to generate all kinds of
testing strategies
1.3.) One API for all kinds of testing strategies

*2) Simplicity *
2.1) Plugins are really simple to write, usually requires one method to be
implemented
2.2) Auto discovery: adding plugins == add code in special (or specified)
directory

*3) Reusability & Data Driven approach: *
3.1) Split code (plugins) & tests cases (yaml files)
3.2) Test cases is mixture of different plugins
3.3) Plugins accept arguments

*4) Integrated tooling*
4.1) All results are persisted in Rally DB and you can access it in any
moment
4.2) Results can be exported in different formats (you can write even own
plugins for simplifying integration)
4.3) Detailed HMTL reports with task results overview and trends




Before switching Fuel from ostf to rally, I would like to see feature
> parity comparison. It's very necessary to understand how much work we need
> to spend to rewrite all our tests in rally way.


Totally agree, let's do it.


Best regards,
Boris Pavlovic



On Mon, Jun 27, 2016 at 8:58 AM, Vladimir Kuklin 
wrote:

> +1 to initial suggestion, but I guess we need to have a full feature
> equality (e.g. HA tests for mysql and rabbitmq replication) before
> switching to Rally.
>
> On Mon, Jun 27, 2016 at 6:17 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>> Before switching Fuel from ostf to rally, I would like to see feature
>> parity comparison. It's very necessary to understand how much work we need
>> to spend to rewrite all our tests in rally way.
>>
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Jun 27, 2016 at 4:32 PM, Alexander Kostrikov <
>> akostri...@mirantis.com> wrote:
>>
>>> Hello, everybody!
>>> Hello, Alex!
>>> >I thought Rally was more for benchmarking.  Wouldn't Tempest make more
>>> sense?
>>> Rally is a good tool with nice api/usage/extensibility.
>>> I really liked "up and running tests in 5 minutes" in Rally with clear
>>> picture of what I am doing.
>>> So, I 100% for a Rally as a QA.
>>>
>>> Another note:
>>> We will need to implement some HA tests, probably not in Rally.
>>>
>>> On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin 
>>> wrote:
>>>


 On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky <
 ikalnit...@mirantis.com> wrote:

>
> > On Jun 27, 2016, at 16:23, Alex Schultz 
> wrote:
> >
> > I thought Rally was more for benchmarking.  Wouldn't Tempest make
> more sense?
>
> According to Rally wiki page [1], it seems they have a verification
> layer (Tempest so far). Hm, I wonder does it mean we will need to rewrite
> our scenarios for Tempest?
>
>
 Rally consists of two main components: Rally Task and Rally
 Verification. They are totally separated.
 Task component is fully pluggable and you can run there whatever you
 want in whatever you want way.
 Verification component is hardcoded now. It was designed for
 managing(install, configure) and launching(execute and store results)
 Tempest. But we have a spec to make this component pluggable too.


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



 --
 Best regards,
 Andrey Kurilin.


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


>>>
>>>
>>> --
>>>
>>> Kind Regards,
>>>
>>> Alexandr Kostrikov,
>>>
>>> Mirantis, Inc.
>>>
>>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>>
>>>
>>> Tel.: +7 (495) 640-49-04
>>> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>>>
>>> Skype: akostrikov_mirantis
>>>
>>> E-mail: akostri...@mirantis.com 

Re: [openstack-dev] [constraints] Updating stable branch URL

[Tony Breeds]

On Mon, Jun 27, 2016 at 11:28:47PM +, Jeremy Stanley wrote:

> I want to say there was a reason we were branching the requirements
> repo last, but now I can't remember what it is (or if we even did
> branch it last). Thierry or Doug likely recall but are indisposed
> this week so I suggest waiting until they're around to reply before
> making a decision on this anyway (especially since it's the Release
> Managers who will need to adjust that process if it does merit
> changing).

OK, lets wait and see what they say.

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] [constraints] Updating stable branch URL

[Jeremy Stanley]

On 2016-06-28 09:00:06 +1000 (+1000), Tony Breeds wrote:
[...]
> Or make the first repo process openstack/requirements ; sleep long enough for
> any mirroring to occur and then process the rest?
[...]

I want to say there was a reason we were branching the requirements
repo last, but now I can't remember what it is (or if we even did
branch it last). Thierry or Doug likely recall but are indisposed
this week so I suggest waiting until they're around to reply before
making a decision on this anyway (especially since it's the Release
Managers who will need to adjust that process if it does merit
changing).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [constraints] Updating stable branch URL

[Tony Breeds]

On Mon, Jun 27, 2016 at 05:14:23PM +, Jeremy Stanley wrote:
> On 2016-06-27 15:27:47 +1000 (+1000), Tony Breeds wrote:
> [...]
> > Can't we extend the tools[1] that do that step with the updating
> > of tox.ini?
> 
> The risk there is that you're breaking that new stable branch for
> developers until a similarly-named branch is created for the
> openstack/requirements repository. It could be worked around with
> additional logic to fall back on the master URL if the branch
> doesn't exist, but it's also possible we just document this as a
> shortcoming for the sake of simplicity.

Or make the first repo process openstack/requirements ; sleep long enough for
any mirroring to occur and then process the rest?

The new URL wont take effect until the review to update tox.ini is merged.  I'm
not suggesting forcing it in just facilitating the change with the current
tools/process.

It seem like that narrows to window of breakage?

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] [Cinder] Nominating Scott D'Angelo to Cinder core

[yang, xing]

+2, very well deserved!  Scott will be a great addition to the core team.

Thanks,
Xing


From: Sean McGinnis [sean.mcgin...@gmx.com]
Sent: Monday, June 27, 2016 1:27 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

I would like to nominate Scott D'Angelo to core. Scott has been very
involved in the project for a long time now and is always ready to help
folks out on IRC. His contributions [1] have been very valuable and he
is a thorough reviewer [2].

Please let me know if there are any objects to this within the next
week. If there are none I will switch Scott over by next week, unless
all cores approve prior to then.

Thanks!

Sean McGinnis (smcginnis)

[1] 
https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
[2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt

__
OpenStack Development Mailing 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] [nfv][tacker] Weekly Meeting Agenda - Jun 27, 2016

[Sridhar Ramaswamy]

We are resuming the meeting after last week's break due to OPNFV Summit.

When: 1600 UTC Tuesday

Where: #openstack-meeting

Here is the proposed agenda [1]

   - Announcements
   - Updates from OPNFV Summit
   - VNF-FFG --> VNFM --> networking-sfc interaction
   - Grooming Midcycle Meetup topics
   - Open Discussion


Please chime in if you've anything else to discuss.

[1] https://wiki.openstack.org/wiki/Meetings/Tacker
__
OpenStack Development Mailing 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] [Heat][tripleo] Tripleo holding on to old, bad data

[Adam Young]

On 06/26/2016 07:00 PM, Steve Baker wrote:
Assuming the stack is deleted and nova is showing no servers, you 
likely have ironic nodes which are not in a state which can be scheduled.


Do an ironic node-list, you want Power State: Off, Provisioning State: 
available, Maintenance: False


Yes, we have that.  First thing we checked.  I assume "available" is the 
most important part of that?





On 25/06/16 09:27, Adam Young wrote:
A coworker and I have both had trouble recovering from failed 
overcloud deploys.  I've wiped out whatever data I can, but, even 
with nothing in the Heat Database, doing an


openstack overcloud deploy

seems to be looking for a specific Nova server by UUID:


heat resource-show 93afc25e-1ab2-4773-9949-6906e2f7c115 0

| resource_status_reason | ResourceInError: 
resources[0].resources.Controller: Went to status ERROR due 
t│·
o "Message: No valid host was found. There are not enough hosts 
available., Code: 500" | 
│·

| resource_type  | OS::TripleO::Controller


Inside the Nova log I see:


2016-06-24 21:05:06.973 15551 DEBUG nova.api.openstack.wsgi 
[req-c8a5179c-2adf-45a6-b186-7d7b29cd8f39 
bcd│·fefb36f3ca9a8f3cfa445ab40 
ec662f250a85453cb40054f3aff49b58 - - -] Returning 404 to user: 
Instance 
8f9│·0c961-4609-4c9b-9d62-360a40f88eed 
could not be found. __call__ 
/usr/lib/python2.7/site-packages/nova/api/│·

openstack/wsgi.py:1070


How can I get the undercloud back to a clean state?


__ 


OpenStack Development Mailing 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] [Cinder] Nominating Scott D'Angelo to Cinder core

[Patrick East]

+2, Definitely well deserved!

-Patrick
__
OpenStack Development Mailing 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][qos] Egress minimum bandwidth assurance

[Hirofumi Ichihara]

I think that the implementation is complex for me and maybe reviewer.
Could you propose devref like vlan-aware-vms[1]?

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

Thanks,
Hirofumi

On 2016/06/24 18:10, Alonso Hernandez, Rodolfo wrote:


Hello:

Ichihara, thank you for your answer. It was just a test to find out 
how to setup correctly the egress traffic shaping. I was facing this 
situation and I found the problem: I was using bridges with 
datapath_type = netdev, instead of system. That was the main problem. 
Now I can correctly apply a QoS and a queue, and assign a traffic to 
this queue.


To avoid using veth between bridges, I’m implementing the following 
solution:


-Create a new queue for each min-qos rule applied to a port (the same 
min-qos rule could be applied to several ports, of course).


-Because ovs only shapes traffic in the egress direction (ovs point of 
view):


oCreate a qos policy for each port in br-int in the same network of 
the port to apply the qos; then assign the created queue to this qos 
policy.


oCreate a qos policy for the external port in br-tun, and then assign 
the queue


oCreate a qos policy for the external port for the br-phy in the same 
network, and assign the queue


-In br-int, table 0, enqueue all traffic going into ovs from the port 
with qos policy assigned to the queue created.


With this implementation, you don’t need to use veth and all traffic 
going from the port with the qos policy assigned to other VM or 
external port (physical bridge, tunnel) will be shaped. Of course, 
this implementation is a bit tangled, so please be gentle in the 
code-review.


Regards.

*From:*Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
*Sent:* Tuesday, June 21, 2016 10:27 AM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth 
assurance


On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:

Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a
POC of this feature.

Scenario 1:

3 VM connected to br-int, sending traffic through br-physical to
other host (an external physical machine).

The first VM will have a min BW of 15 Mb. The physical port will
be limited to 20 Mb, so for VM2 and VM3 should be only 5 Mb of
available BW.

Those three VM are using iperf to inject traffic against the
external host.

A) One qos policy and queue is created at VM1 port (with
other_config:{min-rate=1500}). The traffic is not shapped.

B) Another qos policy and queue with this minimum BW is created at
int-phy-patchport. The traffic is not shapped.

C) Another qos policy and queue with this minimum BW is created at
phy-int-phy-patchport. The traffic is not shapped.

D) Another qos policy and queue with this minimum BW is created at
physical port. The traffic is still not shapped.

In OVS all traffic from VM1 is filtered to match the correct qos
and queues at the ports.

It seems that this scenario doesn't expect some scenarios like DVR and 
multiple NIC. I thought that the queue should be set in br-int with 
veth(instead of patch port) between br-int and bt-tun. However, I 
guess that this may occur a issue that traffic cannot turn back in 
br-int. That may happen in Scenario2 case.


Therefore, I think that we should set the queue to physical port but 
we have a problem how do we specify the NIC in some cases(vlan, vxlan, 
DVR mode router and DVR FloatingIP).




Scenario 2:

Similar to scenario 1, but using a fourth VM to act as server. In
this case, traffic only goes through br-int.

A) One qos policy and queue is created at VM1 port (with
other_config:{min-rate=1500}). The traffic is not shapped.

B) Another qos policy and queue with this minimum BW is created at
output port (VM4 server port). The traffic is still not shapped.



I think we cannot manage this case because we doesn't know MAX 
bandwidth of traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to 
other nodes.


Thanks,
Hirofumi


I need some help with this implementation, because I’m running out
of time an ideas!

Thank you in advance.




__

OpenStack Development Mailing 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: 

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

[Jay S. Bryant]

+2

Well deserved!  Scott has been a great resource to the project!

On 06/27/2016 12:27 PM, Sean McGinnis wrote:

I would like to nominate Scott D'Angelo to core. Scott has been very
involved in the project for a long time now and is always ready to help
folks out on IRC. His contributions [1] have been very valuable and he
is a thorough reviewer [2].

Please let me know if there are any objects to this within the next
week. If there are none I will switch Scott over by next week, unless
all cores approve prior to then.

Thanks!

Sean McGinnis (smcginnis)

[1] 
https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
[2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt

__
OpenStack Development Mailing 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] [craton] OneOps CMS demo

[sean roberts]

Vitaliy is available 9:00 PDT, 15:00 GMT tomorrow. Let's use webex link
here
https://walmart.webex.com/walmart/j.php?MTID=m2e306e0b4a7fec980b21cdc5a02f7815

This is about the option to fork CMS for use in Craton. Everyone join in!


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

[openstack-dev] [ironic] next week's meeting is cancelled

[Loo, Ruby]

Hi,

Quite a few people will be away next Monday (July 4), due to a US holiday (and 
other reasons), so we decided to cancel the ironic meeting. The next meeting 
[1] will be on Monday, July 11.

--ruby

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

Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Steven Dake (stdake)]

On 6/27/16, 11:19 AM, "Devananda van der Veen" 
wrote:

>At a quick glance, this sequence diagram matches what I
>envisioned/expected.
>
>I'd like to suggest a few additional steps be called out, however I'm not
>sure
>how to edit this so I'll write them here.
>
>
>As part of the installation of Ironic, and assuming this is done through
>Bifrost, the Actor should configure Bifrost for their particular network
>environment. For instance: what eth device is connected to the IPMI
>network;
>what IP ranges can Bifrost assign to physical servers; and so on.
>
>There are a lot of other options during the install that can be changed,
>but the
>network config is the most important. Full defaults for this roles' config
>options are here:
> 
>https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-i
>ronic-install/defaults/main.yml
>
>and documentation is here:
> 
>https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifrost-i
>ronic-install
>
>
>
>Immediately before "Ironic PXE boots..." step, the Actor must perform an
>action
>to "enroll" hardware (the "deployment targets") in Ironic. This could be
>done in
>several ways: passing a YAML file to Bifrost; using the Ironic CLI; or
>something
>else.
>
>
>"Ironic reports success to the bootstrap operation" is ambiguous. Ironic
>does
>not currently support notifications, so, to learn the status of the
>deployments,
>you will need to poll the Ironic API (eg, "ironic node-list").
>

Great,

Thanks for the feedback.  I'll integrate your changes into the sequence
diagram when I have a free hour or so - whenever that is :)

Regards
-steve

>
>
>Cheers,
>--Devananda
>
>On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:
>> Hey folks,
>> 
>> I created the following sequence diagram to show my thinking on Ironic
>> integration.  I recognize some internals of the recently merged bifrost
>>changes
>> are not represented in this diagram.  I would like to see a bootstrap
>>action do
>> all of the necessary things to bring up BiFrost in a container using
>>Sean's WIP
>> Kolla patch followed by bare metal minimal OS load followed by Kolla
>>dependency
>> software (docker-engine, docker-py, and ntpd) loading and
>>initialization.
>> 
>> This diagram expects ssh keys to be installed on the deployment targets
>>via BiFrost.
>> 
>> https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D
>> 
>> Thoughts welcome, especially from folks in the Ironic community or Sean
>>who is
>> leading this work in Kolla.
>> 
>> Regards,
>> -steve
>> 
>> 
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
>__
>OpenStack Development Mailing 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] [ironic] weekly subteam status report

[Loo, Ruby]

Hi,

We are upbeat to present this week's subteam report for Ironic. As usual, this 
is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 13 June 2016)
- Ironic: 207 bugs (-6) + 191 wishlist items (+9). 12 new (-3), 140 in progress 
(-7), 0 critical, 32 high (-2) and 26 incomplete (+5)
- Inspector: 7 bugs (-1) + 20 wishlist items (+1). 0 new, 5 in progress (-2), 0 
critical, 1 high (-1) and 1 incomplete (+1)
- Nova bugs with Ironic tag: 14. 0 new, 0 critical, 0 high

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- Switch to ipmitool gate is stalling, as the jobs are not showing the desired 
reliability
- We also need to start running ipmitool gates on IPA

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Information storage specification approved.
- Boot from volume specification to be updated early this week.

Agent top-level API promotion (dtantsur)

* trello: 
https://trello.com/c/37YuKIB8/28-promote-agent-vendor-passthru-to-core-api
- some patches are up, some of them are ready for review: 
https://review.openstack.org/#/q/topic:bug/1570841

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- The spec is merged \o/


Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- The spec is merged \o/

OpenStackClient plugin for ironic (thrash, dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- Merged node provision state operations and support for maintenance mode

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- https://review.openstack.org/#/c/298461/ hasn't been getting many reviews, 
needs a rebase. Expect to be rebased by end of day (CDT) today.

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- Spec needs reviews: https://review.openstack.org/#/c/327437/
- Code is up, pending spec approval: 
https://review.openstack.org/#/q/status:open+branch:master+topic:add-ironic-policy

Software metrics (JayF, alineb)
===
* trello: https://trello.com/c/XtPGyHcP/18-software-metrics
- Blocked on reviews: ironic-lib code up with no negative feedback since 
6/8(thanks dmitry): https://review.openstack.org/#/c/301526/
- all other patches irrelevant until this one lands + is released

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- spec: not approved yet, but have gotten +2 by Ruby 
https://review.openstack.org/#/c/319505/ (landed this morning) thanks!
- Thank you for your reviewing in Midcycle!
- Before driver composition, we will implement 2 drivers in the short 
term.
- A path to socat binary will not be necessary.
- code:
- nova: needs review https://review.openstack.org/#/c/328157/
- Nova non-priority feature freeze is June 30.
- ironic:
- console_utils: needs review https://review.openstack.org/#/c/328168/
- IPMITool driver: needs review https://review.openstack.org/#/c/293873/
- CI: We cannot implement CI tests because virtualbmc doesn't have console.
- Can be added https://bugs.launchpad.net/virtualbmc/+bug/1596624

Rolling upgrades and grenade-partial (lintan)
=
* trello: https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-partial
- jlvillial, sambetts, TheJulia and mat128
- Trying to get multinode to work with simple tempest run
- Progress here 
https://etherpad.openstack.org/p/ironic-newton-grenade-whiteboard
- Patch is proposed to run a multinode job as experimental in the gate: 
https://review.openstack.org/332490

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- patch proposed to move operators processing under ironic-lib: 
https://review.openstack.org/#/c/334431/

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- https://review.openstack.org/#/c/171878/ has some negative feedback, needs 
more reviews. Expect to respond to feedback today/tomorrow.

Inspector (dtansur)
===
- Grenade work is ongoing; current patch stack:
- https://review.openstack.org/#/c/327667/
- 

[openstack-dev] [ironic] mid cycle feedback

[Loo, Ruby]

Hi,

Now that we've all had a chance to recover from the mid-cycle last week and 
while it is still fresh in your minds (or am I too late?), I was wondering 
whether you had any feedback about the mid-cycle. What worked for you, what 
didn't. I am especially interested in knowing what can be improved for future 
mid cycles, or what you got out of the mid-cycle that might help us improve our 
processes or whatever.

For those that were unable to attend but wanted to, what could be done to help 
you attend next time? Or to help you get up-to-speed on what happened (although 
I have to say, Mathieu's summary [1] was excellent.)

One thing that didn't work out well was the conferencing number not working 
sometimes, so folks that couldn't call in via SIP were unable to call in.

Now that I think of it, maybe during the next mid-cycle, we could add ideas to 
the etherpad as to what could be done to improve things in the future.

--ruby

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098060.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

Re: [openstack-dev] [ironic] Ironic Newton midcycle sprint summary

[Loo, Ruby]

Thanks Mathieu, that is a great summary! It is much easier than trying to 
figure that out from the etherpad [1] notes.

--ruby

[1] https://etherpad.openstack.org/p/ironic-newton-midcycle



On 2016-06-23, 3:08 PM, "Mathieu Mitchell" 
> wrote:

Dear group,

Please enjoy this midcycle sprint summary. You might have to put your
Markdown glasses on for proper formatting :)


The midcycle sprint lasted three days. It was virtually held over
Infra's conference system and IRC. The event was split in two different
time slots. The first slot, from 15:00 to 20:00 UTC, was by far the most
popular. A lot of topics were covered by the participants. The second
slot, from 00:00 to 04:00 UTC, was much less popular, having a whooping
peak participant count of four.


June 20 2016 15:00 to 20:00 UTC
---

Most of the group was present for this session. Missing were Devananda
van der Veen (devananda) and Jay Faulkner (JayF). We decided to create
an agenda for the upcoming sessions and reserve topics of interest to
our missing members for the days where they would be present. Also,
Ukraine was observing a national holiday, so some of our Ukrainian
members were absent, too.

The session started with an overview of our Newton priorities. This was
done using the new Ironic Newton Priorities Trello board [1].

[1] https://trello.com/b/ROTxmGIc/ironic-newton-priorities


### Ironic-Neutron integration

The first topic to be covered was the Ironic-Neutron integration. At the
time of discussing that topic, most patches needed rebasing. However,
the group still agreed on the following game plan:

   * Merge the devstack parts ASAP
   * Split portgroups support to the end of the patch chain so they can
merge later. (done: Vladyslav Drok (vdrok) quickly posted a new revision
for [1] and created [2]).
   * Merge everything but portgroups in server-side Ironic
   * Merge client patches in
   * Merge "Ironic: change flat network provider to 'flat'" in nova [3]
   * Finish portgroups
   * Merge "Replace vif_portgroup_id with vif_port_id" [4] (merged
already, thanks Dmitry)

[1] https://review.openstack.org/#/c/206244/
[2] https://review.openstack.org/#/c/332177/
[3] https://review.openstack.org/#/c/297895/
[4] https://review.openstack.org/#/c/325197/


### Security groups for Bare metal deployments

Sukhdev Singh (Sukhdev) reports that full security group support will be
available for bare metal deployments by leveraging the Neutron integration.

> There is minor work that is needed in the Ironic driver. Most of the
ML2 drivers already know how to deal with Security Groups. Hence, this
becomes a slam dunk - huge reward with little work.


### Future networking work

Up for review is the spec for VLAN-aware baremetal instances [1] by Sam
Betts (sambetts). It has received comments and a few reviews, but more
eyes would help get this through :)

Attach and detach are becoming first class citizens [2] and will be
defined in network drivers, allowing for different vendors to implement
their own logic. This will also support post-boot network attach/detach.
Also, keep an eye open for network-aware scheduling in Nova.

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


### Driver composition

Big topic that has been in progress for officially more than a year
(first patch set is dated June 4th, 2015!). We are finally reaching
consensus. Most people are okay with the spec, the only pain point was
using the `driver` vs `hardware_type` field. Since hardware_type was
introduced before dynamic driver had default interfaces, most of the
group agreed to dropping it and simply keeping the `driver` field.

Dmitry Tantsur (dtantsur) quickly posted a few new patch sets and the
spec [1] is currently awaiting workflow.

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


### Serial console spec

Up for review is the Nova-compatible serial console support [1]. The
group had a few questions but none of the authors were present in the room.

One interesting question was whether this should depend on the driver
composition spec. The answer was that, given the limited scope of the
serial console in current deployments, simply one or two new drivers
could be added to the matrix, instead of duplicating all current
drivers, preventing this from requiring the driver composition.

Everyone interested posted questions directly in the review for the
authors to answer. Another point of interest was the full path to the
socat binary, and the code behaving differently based finding "socat" in
said string.

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


June 21 2016 00:00 to 04:00 UTC
---

A small number of participants assisted the session.

An informal discussion took place and the following topics were discussed:

* Merge conflicts and their cause
* Feature enabling
* v2 API
* Multi-node devstack deployments

The session ended 

Re: [openstack-dev] [tripleo] glance backend: replace swift by file in CI

[Emilien Macchi]

On Mon, Jun 27, 2016 at 3:46 PM, Clay Gerrard  wrote:
> There's probably some minimal gain in cross compatibility testing to
> sticking with the status quo.  The Swift API is old and stable, but I
> believe there was some bug in recent history where some return value in
> swiftclient changed from a iterable to a generator or something and some
> aggressive non-duck type checking broke something somewhere
>
> I find that bug reports sorta interesting, the reported memory pressure
> there doesn't make sense.  Maybe there's some non-
> essential middleware configured on that proxy that's causing the workers to
> bloat up like that?

Swift proxy pipeline:
pipeline = catch_errors healthcheck cache ratelimit bulk tempurl
formpost authtoken keystone staticweb proxy-logging proxy-server

Thanks for your help,

> -clayg
>
> On Mon, Jun 27, 2016 at 12:30 PM, Emilien Macchi  wrote:
>>
>> Hi,
>>
>> Today we're re-investigating a CI failure that we had multiple times [1]:
>> Swift memory usage grows until it is OOM-killed.
>>
>> The perimeter of this thread is about our CI and not production
>> environments.
>> Indeed, our CI is running limited resources while production
>> environments should not hit this problem.
>>
>> After some investigation on #ŧripleo, we found out this scenario was
>> happening almost every time since recently:
>>
>> * undercloud is deployed, glance and swift are running. Glance is
>> configured with Swift backend to store images.
>> * tripleo CI upload overcloud image into Glance, image is successfully
>> uploaded.
>> * when overcloud starts deploying, some nodes randomly fail to deploy
>> because the undercloud OOM-kills swift-proxy-server that is still
>> sending the ovecloud image requested by Glance API. Swift fails,
>> Glance fails, overcloud deployment fails with a "No valid hosts
>> found".
>>
>> It's likely due to performances issues in our CI, and there is nothing
>> we can do but adding more resources or reducing the number of
>> environments, something we won't do at this time, because our recent
>> improvements in our CI (more ram, SSD, etc).
>>
>> As a first iteration, I propose [2] that we stop using Swift as a
>> backend for Glance. Indeed, our undercloud is currently single-node, I
>> see zero value of using Swift to store the overcloud image.
>> If there is a value, then we can add the option to whether or not
>> using it (and set it to False in our CI to use file backend, which
>> won't lead to OOM).
>>
>> Note: on the overcloud: we currently support file, swift and rbd
>> backends, that you can easily select during your deployment.
>>
>> [1] https://bugs.launchpad.net/tripleo/+bug/1595916
>> [2] https://review.openstack.org/#/c/334555/
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo] glance backend: replace swift by file in CI

[Clay Gerrard]

There's probably some minimal gain in cross compatibility testing to
sticking with the status quo.  The Swift API is old and stable, but I
believe there was some bug in recent history where some return value in
swiftclient changed from a iterable to a generator or something and some
aggressive non-duck type checking broke something somewhere

I find that bug reports sorta interesting, the reported memory pressure
there doesn't make sense.  Maybe there's some non-
essential middleware configured on that proxy that's causing the workers to
bloat up like that?

-clayg

On Mon, Jun 27, 2016 at 12:30 PM, Emilien Macchi  wrote:

> Hi,
>
> Today we're re-investigating a CI failure that we had multiple times [1]:
> Swift memory usage grows until it is OOM-killed.
>
> The perimeter of this thread is about our CI and not production
> environments.
> Indeed, our CI is running limited resources while production
> environments should not hit this problem.
>
> After some investigation on #ŧripleo, we found out this scenario was
> happening almost every time since recently:
>
> * undercloud is deployed, glance and swift are running. Glance is
> configured with Swift backend to store images.
> * tripleo CI upload overcloud image into Glance, image is successfully
> uploaded.
> * when overcloud starts deploying, some nodes randomly fail to deploy
> because the undercloud OOM-kills swift-proxy-server that is still
> sending the ovecloud image requested by Glance API. Swift fails,
> Glance fails, overcloud deployment fails with a "No valid hosts
> found".
>
> It's likely due to performances issues in our CI, and there is nothing
> we can do but adding more resources or reducing the number of
> environments, something we won't do at this time, because our recent
> improvements in our CI (more ram, SSD, etc).
>
> As a first iteration, I propose [2] that we stop using Swift as a
> backend for Glance. Indeed, our undercloud is currently single-node, I
> see zero value of using Swift to store the overcloud image.
> If there is a value, then we can add the option to whether or not
> using it (and set it to False in our CI to use file backend, which
> won't lead to OOM).
>
> Note: on the overcloud: we currently support file, swift and rbd
> backends, that you can easily select during your deployment.
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1595916
> [2] https://review.openstack.org/#/c/334555/
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] npm lint and test problems in gate

[Jeremy Stanley]

On 2016-06-24 22:08:40 + (+), Jeremy Stanley wrote:
[...]
> the gate-horizon-npm-run-test job uses that same configuration
> (just passing a different {command}) and we're still seeing
> failures registered for it even now.
[...]

Just following up since I got a few more minutes to poke at this
after discussing in IRC: I have confirmed the stats we have in
graphite seem to match what's recorded by logstash, and dug up
three example failure logs from today.

http://logs.openstack.org/00/334300/1/check/gate-horizon-npm-run-test/469ff89/console.html

http://logs.openstack.org/03/320203/9/check/gate-horizon-npm-run-test/e71f803/console.html

http://logs.openstack.org/28/333628/5/check/gate-horizon-npm-run-test/5ae2085/console.html

However, there's (thankfully) a consistent explanation. Take a look
at the timestamp gaps between the penultimate and ultimate lines of
each log... timeouts! So I agree the issue seems to be lack of
errexit in the npm-run builder. The old failures observed for
gate-horizon-npm-run-lint are probably similarly explained as
timeout issues we've just been lucky enough not to hit in the past
week or so. Unfortunately those failures fall just outside our
elasticsearch retention window so confirming that would be a very
time-intensive exercise at this point.
-- 
Jeremy Stanley

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

[openstack-dev] [tripleo] glance backend: replace swift by file in CI

[Emilien Macchi]

Hi,

Today we're re-investigating a CI failure that we had multiple times [1]:
Swift memory usage grows until it is OOM-killed.

The perimeter of this thread is about our CI and not production environments.
Indeed, our CI is running limited resources while production
environments should not hit this problem.

After some investigation on #ŧripleo, we found out this scenario was
happening almost every time since recently:

* undercloud is deployed, glance and swift are running. Glance is
configured with Swift backend to store images.
* tripleo CI upload overcloud image into Glance, image is successfully uploaded.
* when overcloud starts deploying, some nodes randomly fail to deploy
because the undercloud OOM-kills swift-proxy-server that is still
sending the ovecloud image requested by Glance API. Swift fails,
Glance fails, overcloud deployment fails with a "No valid hosts
found".

It's likely due to performances issues in our CI, and there is nothing
we can do but adding more resources or reducing the number of
environments, something we won't do at this time, because our recent
improvements in our CI (more ram, SSD, etc).

As a first iteration, I propose [2] that we stop using Swift as a
backend for Glance. Indeed, our undercloud is currently single-node, I
see zero value of using Swift to store the overcloud image.
If there is a value, then we can add the option to whether or not
using it (and set it to False in our CI to use file backend, which
won't lead to OOM).

Note: on the overcloud: we currently support file, swift and rbd
backends, that you can easily select during your deployment.

[1] https://bugs.launchpad.net/tripleo/+bug/1595916
[2] https://review.openstack.org/#/c/334555/
-- 
Emilien Macchi

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

[openstack-dev] [nova] Do we require the 'next' link for paging, always?

[Matt Riedemann]

There are at least two changes up that add paging support to the API, 
one for hypervisors and one for keypairs. Alex Xu pointed out in one of 
them that they didn't have a 'next' link in the response for paging, 
which is created here for the server/image/flavor view builders:


https://github.com/openstack/nova/blob/6e8c84d0cd7651b465cf9bb7ad68a9b24b3658c9/nova/api/openstack/common.py#L448

None of the REST API big-whigs were in channel for me to confirm, but I 
assume we want this in any API that supports paging. Yes?


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Jay Faulkner]

Is this spec still alive? I'm working on the spec for Ironic integration of 
Keystone policy, and like some of the items in the draft, but obviously they 
aren't binding and I can't really reference them unless the spec merges or at 
least shows progress towards merging.

Thanks,
Jay Faulkner
OSIC

On Jan 31, 2016, at 6:15 PM, Adam Young 
> wrote:

On 01/30/2016 08:24 PM, Henry Nash wrote:

On 30 Jan 2016, at 21:55, Adam Young 
<ayo...@redhat.com> wrote:

On 01/30/2016 04:14 PM, Henry Nash wrote:
Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples of when 
there is more than one (target) scope check, e.g.: an API that might operate on 
an object that maybe global, domain or project specific - in which case you 
need to “match up with scope checks with the object in question”, for example 
for a given API:

If cloud admin, allow the API
If domain admin and the object is domain or project specific, then allow the API
If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m not clear 
how the “scope check in code” will work in this kind of situation.
I originally favored an approach that a user would need to get a token scoped 
to a resource in order to affect change on that resource, and admin users could 
get tokens scoped to anything,  but I know that makes things harder for 
Administrators trying to fix broken deployments. So I backed off on that 
approach.

I think the right answer would be that the role check would set some value to 
indicate it was an admin override.  So long as the check does not need the 
actual object from the database, t can perform whatever logic we like.

The policy check deep in the code can be as strict or permissive as it desires. 
 If there is a need to re-check the role for an admin check there, policy can 
still do so.  A role check that passes at the Middleware level can still be 
blocked at the in-code level.

"If domain admin and the object is domain or project specific, then allow the 
API" is trh tricky one, but I don't think we even have a solution for that now. 
 Domain1->p1->p2->p3 type hierarchies don't allow operations on p3 with a token 
scoped to Domain1.

So we do actually support things like that, e.g. (from the domain specific role 
additions):

”identity:some_api": role:admin and project_domain_id:%(target.role.domain_id)s 
   (which means I’m project admin and the domain specific role I am going to 
manipulate is specific to my domain)

….and although we don’t have this in our standard policy, you could also write

”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s
(which means I’m domain admin and I can do some operation on any project in my 
domain)

Yeah, we do some things like this in the Keystone policy file, but not in 
remote services, yet, and it would only work for Domain of the project, not for 
any arbitrary project in the chain under Domain1:  roles on p1 or P2 would have 
to be inherited in order to affect any change on resources in 3.



I think that in those cases, I would still favor the user getting a token from 
Keystone scoped to p3, and use the inherited-role-assignment approach.



Henry

On 30 Jan 2016, at 17:44, Adam Young 
> wrote:

I'd like to bring people's attention to a Cross Project spec that has the 
potential to really strengthen the security story for OpenStack in a scalable 
way.

"A common policy scenario across all projects" 
 
https://review.openstack.org/#/c/245629/

The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not real humans
{service_type}_admin :  identity_admin, compute_admin, 
network_admin etc.
{service_type}_{api_resource}_manager: identity_user_manager,
   compute_server_manager, 
network_subnet_manager
observer :  read only access
{service_type}_observer  : identity_observer, image_observer


Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph 
Matthews just took it to the next level.  It is worth a read.

I think this is the way to go.  There might be details on how to get there, but 
the granularity is about right.
If we go with that approach, we might want to rethink about how we enforce 
policy.  Specifically, I think we should split the policy enforcement up into 
two stages:

1.  Role check.  This only needs to know the service and the api resource.  As 
such, it could happen in 

Re: [openstack-dev] [ironic] Gate troubleshooting howto

[Jay Faulkner]

The date that has the strongest consensus appears to be Wednesday, July 13, at 
1500 UTC. I'll send out more details about how to connect and watch later.

If you were one of the people who will be unable to attend, I'll ensure this is 
recorded, and if we get enough folks interested even with the recording, I can 
do another live session. 

Thanks,
Jay Faulkner
OSIC


> On Jun 23, 2016, at 5:16 PM, Jay Faulkner  wrote:
> 
> I dropped this Friday as an option based on the results. If you're interested 
> this will still be happening, but in mid-July.
> 
> Thanks,
> Jay Faulkner
> OSIC
> 
> 
>> On Jun 22, 2016, at 12:39 PM, Jay Faulkner  wrote:
>> 
>> There was a request at the mid-cycle for a presentation on
>> troubleshooting Ironic gate failures. I'd be willing to share some of my
>> knowledge about this to interested folks.
>> 
>> I've created a doodle with a few possible times; note that one option is
>> this Friday, but the others are in mid-July, as I'll be moving over the
>> gap of time; so I can do before or after the move.
>> 
>> Please vote here: http://doodle.com/poll/44whfnwkkm4vcgn4
>> 
>> 
>> Thanks,
>> Jay Faulkner
>> OSIC
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing 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] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Devananda van der Veen]

At a quick glance, this sequence diagram matches what I envisioned/expected.

I'd like to suggest a few additional steps be called out, however I'm not sure
how to edit this so I'll write them here.


As part of the installation of Ironic, and assuming this is done through
Bifrost, the Actor should configure Bifrost for their particular network
environment. For instance: what eth device is connected to the IPMI network;
what IP ranges can Bifrost assign to physical servers; and so on.

There are a lot of other options during the install that can be changed, but the
network config is the most important. Full defaults for this roles' config
options are here:
 
https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/defaults/main.yml

and documentation is here:
 
https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifrost-ironic-install



Immediately before "Ironic PXE boots..." step, the Actor must perform an action
to "enroll" hardware (the "deployment targets") in Ironic. This could be done in
several ways: passing a YAML file to Bifrost; using the Ironic CLI; or something
else.


"Ironic reports success to the bootstrap operation" is ambiguous. Ironic does
not currently support notifications, so, to learn the status of the deployments,
you will need to poll the Ironic API (eg, "ironic node-list").



Cheers,
--Devananda

On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:
> Hey folks,
> 
> I created the following sequence diagram to show my thinking on Ironic
> integration.  I recognize some internals of the recently merged bifrost 
> changes
> are not represented in this diagram.  I would like to see a bootstrap action 
> do
> all of the necessary things to bring up BiFrost in a container using Sean's 
> WIP
> Kolla patch followed by bare metal minimal OS load followed by Kolla 
> dependency
> software (docker-engine, docker-py, and ntpd) loading and initialization.
> 
> This diagram expects ssh keys to be installed on the deployment targets via 
> BiFrost.
> 
> https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D
> 
> Thoughts welcome, especially from folks in the Ironic community or Sean who is
> leading this work in Kolla.
> 
> Regards,
> -steve
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

[Sean McGinnis]

I would like to nominate Scott D'Angelo to core. Scott has been very
involved in the project for a long time now and is always ready to help
folks out on IRC. His contributions [1] have been very valuable and he
is a thorough reviewer [2].

Please let me know if there are any objects to this within the next
week. If there are none I will switch Scott over by next week, unless
all cores approve prior to then.

Thanks!

Sean McGinnis (smcginnis)

[1] 
https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
[2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt

__
OpenStack Development Mailing 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] [constraints] Updating stable branch URL

[Jeremy Stanley]

On 2016-06-27 15:27:47 +1000 (+1000), Tony Breeds wrote:
[...]
> Can't we extend the tools[1] that do that step with the updating
> of tox.ini?

The risk there is that you're breaking that new stable branch for
developers until a similarly-named branch is created for the
openstack/requirements repository. It could be worked around with
additional logic to fall back on the master URL if the branch
doesn't exist, but it's also possible we just document this as a
shortcoming for the sake of simplicity.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Fuel] Merge IRC channels

[Jeremy Stanley]

On 2016-06-27 13:08:03 +0300 (+0300), Vladimir Kozhukalov wrote:
[...]
> As for renaming #fuel into #openstack-fuel I think it makes little sense
> and not necessary, since some (even core) OpenStack projects don't use
> 'openstack' prefix.
[...]

About the only thing the openstack- prefix gets you is that the
Infra team has some control over that channel namespace in Freenode,
so that if all your channel founders disappear we can work with
Freenode staff to regain control of the channel on your behalf.
However, this can also be accomplished by granting our
openstackinfra account founder permissions[1] and adding your
channel to our accessbot config[2].

[1] http://docs.openstack.org/infra/system-config/irc.html#access
[2] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/accessbot/channels.yaml
-- 
Jeremy Stanley

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

Re: [openstack-dev] Introduction

[Jay Faulkner]

Hi and welcome

https://wiki.openstack.org/wiki/How_To_Contribute will have some information on 
different ways to contribute. If you have a specific project in mind, I'd 
suggest searching on their bugtracker for 'low-hanging-fruit'. Either one of 
those bugs, or any issues/bugs you see in developer documentation are great 
choices for getting started. If you have any trouble, asking in IRC is often a 
quick way to get over a problem, but most of it's documented pretty well so 
make sure to exhaust the docs first.

Good luck + thanks,
Jay Faulkner
OSIC

On Jun 27, 2016, at 9:10 AM, Nalaka Rajamanthri 
> wrote:

Hi,
I am new to the open source community. I would like to contribute to the 
openstack. So I would like to help this project by solving bugs.

Best Regards,
Nalaka Rajamanthri,
University of Peradeniya (undergraduate)
__
OpenStack Development Mailing 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] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

[Matt Fischer]

We upgraded our dev environment last week to Keystone stable/mitaka. Since
then we're unable to show or set quotas on projects of which the admin is
not a member. Looking at the cinder code, it seems that cinder is pulling a
project list and attempting to determine a hierarchy.  On Liberty Keystone,
projects seem to lack parents:

https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'},
name=admin, parent_id=None, subtree=None>

In Mitaka, it seems that projects are children of the default domain:

http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'},
name=admin, parent_id=default, subtree=None>

In Liberty since all projects were parentless, the authorize_* code blocks
were skipped since both conditionals were false:

https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191

But now in Mitaka, the code is run, and it fails out since the projects are
"brothers", both with the parent of the default domain, but not
hierarchically related.

Previously it was a useful ability for us to be able to (as admins) set and
view  quotas for cinder projects. Now we need to scope into the user's
project to even be able to view their quotas, much less change them. This
seems broken, but I'm not sure where the issue is or why the keystone
behavior changed. Is this the expected behavior?
__
OpenStack Development Mailing 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] Introduction

[Nalaka Rajamanthri]

Hi,
I am new to the open source community. I would like to contribute to
the openstack.
So I would like to help this project by solving bugs.

Best Regards,
Nalaka Rajamanthri,
University of Peradeniya (undergraduate)
__
OpenStack Development Mailing 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] [murano][release] Changing murano-agent release model to cycle-with-intermediary

[Kirill Zaitsev]

Hello team,

Currently murano-agent has 'cycle-with-milestones' release model, i.e. the same 
as murano and murano-dashboard. 
At the same time the project does not really receive a lot of updates to 
justify such model. In fact it is developed a lot like our python-muranoclient 
is and we intend it to be backward compatible.
I’ve pushed a change for review [1], but would like to get some opinions before 
giving it a go

P.S. going to add this to agenda for our next community meeting, but feel free 
to comment here or in the review.


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


-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Vladimir Kuklin]

+1 to initial suggestion, but I guess we need to have a full feature
equality (e.g. HA tests for mysql and rabbitmq replication) before
switching to Rally.

On Mon, Jun 27, 2016 at 6:17 PM, Sergii Golovatiuk  wrote:

> Hi,
>
> Before switching Fuel from ostf to rally, I would like to see feature
> parity comparison. It's very necessary to understand how much work we need
> to spend to rewrite all our tests in rally way.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jun 27, 2016 at 4:32 PM, Alexander Kostrikov <
> akostri...@mirantis.com> wrote:
>
>> Hello, everybody!
>> Hello, Alex!
>> >I thought Rally was more for benchmarking.  Wouldn't Tempest make more
>> sense?
>> Rally is a good tool with nice api/usage/extensibility.
>> I really liked "up and running tests in 5 minutes" in Rally with clear
>> picture of what I am doing.
>> So, I 100% for a Rally as a QA.
>>
>> Another note:
>> We will need to implement some HA tests, probably not in Rally.
>>
>> On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky >> > wrote:
>>>

 > On Jun 27, 2016, at 16:23, Alex Schultz 
 wrote:
 >
 > I thought Rally was more for benchmarking.  Wouldn't Tempest make
 more sense?

 According to Rally wiki page [1], it seems they have a verification
 layer (Tempest so far). Hm, I wonder does it mean we will need to rewrite
 our scenarios for Tempest?


>>> Rally consists of two main components: Rally Task and Rally
>>> Verification. They are totally separated.
>>> Task component is fully pluggable and you can run there whatever you
>>> want in whatever you want way.
>>> Verification component is hardcoded now. It was designed for
>>> managing(install, configure) and launching(execute and store results)
>>> Tempest. But we have a spec to make this component pluggable too.
>>>
>>>
 - igor


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

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

>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey Kurilin.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>
>> Kind Regards,
>>
>> Alexandr Kostrikov,
>>
>> Mirantis, Inc.
>>
>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>
>>
>> Tel.: +7 (495) 640-49-04
>> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>>
>> Skype: akostrikov_mirantis
>>
>> E-mail: akostri...@mirantis.com 
>>
>> *www.mirantis.com *
>> *www.mirantis.ru *
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
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] [Fuel] Failed to build the bootstrap image

[Maksim Malchuk]

Maybe the problem because you create the CentOS bootstrap which is
deprecated now.
If You really need the CentOS bootstrap, need to look into the mentioned
log file for this issue.


On Mon, Jun 27, 2016 at 6:33 PM, Alioune  wrote:

> Thanks for your response,
>
> I've created and activated a new centOS bootstrap as suggested Sergi.
> Now the fuel-slave tries to boot from network but it fails at step TFTP
> http://10.20.0.2/cobbler/boot (unable to locate configuration file ).
> The bootstrap zip was generated in
> /tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
> can not retreive the config files of the bootstrap.
> Are there additional config to do on the master side ?
> Regards
>
>  fuel-bootstrap list
>
> +--+--++
> | uuid | label
>| status |
>
> +--+--++
> | a721103c-8693-4c58-985d-3f8223bdbc88 |
> a721103c-8693-4c58-985d-3f8223bdbc88 | active |
> | centos   | deprecated
> ||
>
> +--+--++
>
> On 27 June 2016 at 16:58, Sergii Golovatiuk 
> wrote:
>
>> Hi,
>>
>> I would suggest to build image from CLI using [0]. That will give more
>> details to you.
>>
>> [0]
>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk 
>> wrote:
>>
>>> Hi,
>>>
>>> The error about an internet connection is the only common case. You
>>> should check the actual error in the log file
>>> /var/log/fuel-bootstrap-image-build.log.
>>> You can also share this file with us via any public service
>>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>>
>>> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk 
>>> wrote:
>>>
 Hi,

 The error about an internet connection is the only common case. You
 should check the actual error in the log file
 /var/log/fuel-bootstrap-image-build.log.
 You can also share this file with us via any public service
 (GoogleDrive, DropBox, etc) and we will check it for you.


 On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:

> hi all,
>
> I'm trying to install fuel in VirtualBox, the fuel master is correctly
> running but I'm receiving the this error on the fuel GUI:
>
> WARNING: Failed to build the bootstrap image, see
> /var/log/fuel-bootstrap-image-build.log for details.
> Perhaps your Internet connection is broken. Please fix the problem and
> run `fuel-bootstrap build --activate`.
> While you don't activate any bootstrap - new nodes cannot be
> discovered and added to cluster.
> For more information please visit
> https://docs.mirantis.com/openstack/fuel/fuel-master/
>
> The fuel server has access to internet even though it could not find
> depots during install, I ran "yum update" and reboot but I still get this
> error.
> I configured a fuel-slave server boot from network attached to the
> fuel-master but the process failed also.
> Any help please to solve this ?
>
> Regards,
>
>
> __
> OpenStack Development Mailing 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,
 Maksim Malchuk,
 Senior DevOps Engineer,
 MOS: Product Engineering,
 Mirantis, Inc
 

>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Maksim Malchuk,
>>> Senior DevOps Engineer,
>>> MOS: Product Engineering,
>>> Mirantis, Inc
>>> 
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing 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,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

__

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

[Alioune]

Thanks for your response,

I've created and activated a new centOS bootstrap as suggested Sergi.
Now the fuel-slave tries to boot from network but it fails at step TFTP
http://10.20.0.2/cobbler/boot (unable to locate configuration file ).
The bootstrap zip was generated in
/tmp/a721103c-8693-4c58-985d-3f8223bdbc88.tar.gz, it seems that the slave
can not retreive the config files of the bootstrap.
Are there additional config to do on the master side ?
Regards

 fuel-bootstrap list
+--+--++
| uuid | label
   | status |
+--+--++
| a721103c-8693-4c58-985d-3f8223bdbc88 |
a721103c-8693-4c58-985d-3f8223bdbc88 | active |
| centos   | deprecated
  ||
+--+--++

On 27 June 2016 at 16:58, Sergii Golovatiuk 
wrote:

> Hi,
>
> I would suggest to build image from CLI using [0]. That will give more
> details to you.
>
> [0]
> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk 
> wrote:
>
>> Hi,
>>
>> The error about an internet connection is the only common case. You
>> should check the actual error in the log file
>> /var/log/fuel-bootstrap-image-build.log.
>> You can also share this file with us via any public service (GoogleDrive,
>> DropBox, etc) and we will check it for you.
>>
>> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk 
>> wrote:
>>
>>> Hi,
>>>
>>> The error about an internet connection is the only common case. You
>>> should check the actual error in the log file
>>> /var/log/fuel-bootstrap-image-build.log.
>>> You can also share this file with us via any public service
>>> (GoogleDrive, DropBox, etc) and we will check it for you.
>>>
>>>
>>> On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:
>>>
 hi all,

 I'm trying to install fuel in VirtualBox, the fuel master is correctly
 running but I'm receiving the this error on the fuel GUI:

 WARNING: Failed to build the bootstrap image, see
 /var/log/fuel-bootstrap-image-build.log for details.
 Perhaps your Internet connection is broken. Please fix the problem and
 run `fuel-bootstrap build --activate`.
 While you don't activate any bootstrap - new nodes cannot be discovered
 and added to cluster.
 For more information please visit
 https://docs.mirantis.com/openstack/fuel/fuel-master/

 The fuel server has access to internet even though it could not find
 depots during install, I ran "yum update" and reboot but I still get this
 error.
 I configured a fuel-slave server boot from network attached to the
 fuel-master but the process failed also.
 Any help please to solve this ?

 Regards,


 __
 OpenStack Development Mailing 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,
>>> Maksim Malchuk,
>>> Senior DevOps Engineer,
>>> MOS: Product Engineering,
>>> Mirantis, Inc
>>> 
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Maksim Malchuk,
>> Senior DevOps Engineer,
>> MOS: Product Engineering,
>> Mirantis, Inc
>> 
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] [Fuel] Replace OSTF with Rally

[Sergii Golovatiuk]

Hi,

Before switching Fuel from ostf to rally, I would like to see feature
parity comparison. It's very necessary to understand how much work we need
to spend to rewrite all our tests in rally way.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jun 27, 2016 at 4:32 PM, Alexander Kostrikov <
akostri...@mirantis.com> wrote:

> Hello, everybody!
> Hello, Alex!
> >I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
> Rally is a good tool with nice api/usage/extensibility.
> I really liked "up and running tests in 5 minutes" in Rally with clear
> picture of what I am doing.
> So, I 100% for a Rally as a QA.
>
> Another note:
> We will need to implement some HA tests, probably not in Rally.
>
> On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin 
> wrote:
>
>>
>>
>> On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky 
>> wrote:
>>
>>>
>>> > On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
>>> >
>>> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
>>> sense?
>>>
>>> According to Rally wiki page [1], it seems they have a verification
>>> layer (Tempest so far). Hm, I wonder does it mean we will need to rewrite
>>> our scenarios for Tempest?
>>>
>>>
>> Rally consists of two main components: Rally Task and Rally Verification.
>> They are totally separated.
>> Task component is fully pluggable and you can run there whatever you want
>> in whatever you want way.
>> Verification component is hardcoded now. It was designed for
>> managing(install, configure) and launching(execute and store results)
>> Tempest. But we have a spec to make this component pluggable too.
>>
>>
>>> - igor
>>>
>>>
>>> [1] https://wiki.openstack.org/wiki/Rally
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Kind Regards,
>
> Alexandr Kostrikov,
>
> Mirantis, Inc.
>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>
>
> Tel.: +7 (495) 640-49-04
> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>
> Skype: akostrikov_mirantis
>
> E-mail: akostri...@mirantis.com 
>
> *www.mirantis.com *
> *www.mirantis.ru *
>
> __
> OpenStack Development Mailing 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] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

[Matthew Mosesohn]

+1. Maksim is an excellent reviewer.

On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz  wrote:
> +1
>
> On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya 
> wrote:
>>
>> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
>> > I am very sorry for sending without subject. I am adding subject to
>> > voting and my +1
>>
>> +1 from my side!
>>
>> >
>> > --
>> > Best regards,
>> > Sergii Golovatiuk,
>> > Skype #golserge
>> > IRC #holser
>> >
>> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk
>> > > wrote:
>> >
>> > Hi,
>> >
>> > I would like to nominate Maksim Malchuk to Fuel-Library Core team.
>> > He’s been doing a great job so far [0]. He’s #2 reviewer and #2
>> > contributor with 28 commits for last 90 days [1][2].
>> >
>> > Fuelers, please vote with +1/-1 for approval/objection. Voting will
>> > be open until July of 4th. This will go forward after voting is
>> > closed if there are no objections.
>> >
>> > Overall contribution:
>> > [0] http://stackalytics.com/?user_id=mmalchuk
>> > Fuel library contribution for last 90 days:
>> > [1]
>> > http://stackalytics.com/report/contribution/fuel-library/90
>> > http://stackalytics.com/report/users/mmalchuk
>> > List of reviews:
>> > [2]
>> > https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
>> > --
>> > Best regards,
>> > Sergii Golovatiuk,
>> > Skype #golserge
>> > IRC #holser
>> >
>> >
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> __
>> OpenStack Development Mailing 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] [murano][murano-apps] FQNs of murano apps/classes

[Kirill Zaitsev]

TL,DR version: 
Murano team is using io.murano namespace for murano Core Library, it should not 
be used for apps; We’ve updated our murano apps to use org.openstack and/or 
com.mirantis where applicable [1]. If you’re developing a murano app — please 
pick a relevant namespace.

Long Version:
In MuranoPL packages and classes have FQNs, Fully Qualified Names. This is done 
to allow developers of apps distinguish between different implementations of 
the same thing. For example we might have a VM-based MySQL [2] and a 
docker-based MySQL classes [3]. The idea of FQNs is quite similar to the idea 
of namespaces from Java, for example.

Until very recently we(murano-team) have been using ‘io.murano’ prefix for all 
of our apps. Originally this namespace was designed to contain only ‘core’ 
murano classes, but then we’ve added a couple of apps, and a couple more and 
eventually we’ve been using the namespace all over. This lead to app developers 
from outside the core murano team to copy this practice and use ‘io.murano’ 
prefix in their own apps (Since all the apps start with ‘io.murano’ one would 
make a logical solution, that he should also start his/her app with 
‘io.murano’). This defeats the idea of having multiple independent 
implementations with different FQN, so we’re updating our apps to remove this 
prefix. It will probably take some time to update apps on app.openstack.org, 
but apps in murano-apps have already been updated accordingly.

The same idea applies to murano plugins, that extend core library with new 
functionality. This work is described in corresponding spec [4] (it’s quite 
short, so if you’re writing a murano-plugin, please give it a read) and will be 
implemented by this commit [5]. The goal here is also to remove 
‘io.murano.extensions’ from the class names of the plugins. Old names are 
deprecated, but would be supported.

So, if you’re developing a murano app, please don’t use 'io.murano' as the 
prefix for your app’s FQN, but rather choose a more appropriate one. 
'org.openstack' might be a good choice. And if your company plans to invest 
into supporting the app — it might be a good idea to put it’s name there.


[1] 
https://review.openstack.org/#/q/status:merged+project:openstack/murano-apps+branch:master+topic:bp/fix-fqn-usage
 
[2] 
https://git.openstack.org/cgit/openstack/murano-apps/tree/MySQL/package/manifest.yaml#n15
[3] 
https://git.openstack.org/cgit/openstack/murano-apps/tree/Docker/Applications/MySQL/package/manifest.yaml#n15
[4] 
https://specs.openstack.org/openstack/murano-specs/specs/newton/approved/plugin-fqn-rename.html
[5] https://review.openstack.org/#/c/332875/

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
OpenStack Development Mailing 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] - Nominate Maksim Malchuk to Fuel Library Core

[Alex Schultz]

+1

On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya 
wrote:

> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
> > I am very sorry for sending without subject. I am adding subject to
> > voting and my +1
>
> +1 from my side!
>
> >
> > --
> > Best regards,
> > Sergii Golovatiuk,
> > Skype #golserge
> > IRC #holser
> >
> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk
> > > wrote:
> >
> > Hi,
> >
> > I would like to nominate Maksim Malchuk to Fuel-Library Core team.
> > He’s been doing a great job so far [0]. He’s #2 reviewer and #2
> > contributor with 28 commits for last 90 days [1][2].
> >
> > Fuelers, please vote with +1/-1 for approval/objection. Voting will
> > be open until July of 4th. This will go forward after voting is
> > closed if there are no objections.
> >
> > Overall contribution:
> > [0] http://stackalytics.com/?user_id=mmalchuk
> > Fuel library contribution for last 90 days:
> > [1] 
> http://stackalytics.com/report/contribution/fuel-library/90
> > http://stackalytics.com/report/users/mmalchuk
> > List of reviews:
> > [2]
> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
> > --
> > Best regards,
> > Sergii Golovatiuk,
> > Skype #golserge
> > IRC #holser
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

[Bogdan Dobrelya]

On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
> I am very sorry for sending without subject. I am adding subject to
> voting and my +1

+1 from my side!

> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk
> > wrote:
> 
> Hi,
> 
> I would like to nominate Maksim Malchuk to Fuel-Library Core team.
> He’s been doing a great job so far [0]. He’s #2 reviewer and #2
> contributor with 28 commits for last 90 days [1][2]. 
> 
> Fuelers, please vote with +1/-1 for approval/objection. Voting will
> be open until July of 4th. This will go forward after voting is
> closed if there are no objections.  
> 
> Overall contribution:
> [0] http://stackalytics.com/?user_id=mmalchuk
> Fuel library contribution for last 90 days:
> [1] 
> http://stackalytics.com/report/contribution/fuel-library/90
> http://stackalytics.com/report/users/mmalchuk
> List of reviews:
> [2] 
> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

[Sergii Golovatiuk]

I am very sorry for sending without subject. I am adding subject to voting
and my +1

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk  wrote:

> Hi,
>
> I would like to nominate Maksim Malchuk to Fuel-Library Core team. He’s
> been doing a great job so far [0]. He’s #2 reviewer and #2 contributor with
> 28 commits for last 90 days [1][2].
>
> Fuelers, please vote with +1/-1 for approval/objection. Voting will be
> open until July of 4th. This will go forward after voting is closed if
> there are no objections.
>
> Overall contribution:
> [0] http://stackalytics.com/?user_id=mmalchuk
> Fuel library contribution for last 90 days:
> [1]  
> http://stackalytics.com/report/contribution/fuel-library/90
> http://stackalytics.com/report/users/mmalchuk
> List of reviews:
> [2]
> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
__
OpenStack Development Mailing 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] - Nominate Maksim Malchuk to Fuel Library Core

[Aleksandr Didenko]

Hi,

+1 from me.

Regards,
Alex

On Mon, Jun 27, 2016 at 4:54 PM, Sergii Golovatiuk  wrote:

> I am very sorry for sending without subject. I am adding subject to voting
> and my +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>> I would like to nominate Maksim Malchuk to Fuel-Library Core team. He’s
>> been doing a great job so far [0]. He’s #2 reviewer and #2 contributor with
>> 28 commits for last 90 days [1][2].
>>
>> Fuelers, please vote with +1/-1 for approval/objection. Voting will be
>> open until July of 4th. This will go forward after voting is closed if
>> there are no objections.
>>
>> Overall contribution:
>> [0] http://stackalytics.com/?user_id=mmalchuk
>> Fuel library contribution for last 90 days:
>> [1]  
>> http://stackalytics.com/report/contribution/fuel-library/90
>> http://stackalytics.com/report/users/mmalchuk
>> List of reviews:
>> [2]
>> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>
>
> __
> OpenStack Development Mailing 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] [Fuel] Failed to build the bootstrap image

[Sergii Golovatiuk]

Hi,

I would suggest to build image from CLI using [0]. That will give more
details to you.

[0]
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jun 27, 2016 at 3:20 PM, Maksim Malchuk 
wrote:

> Hi,
>
> The error about an internet connection is the only common case. You should
> check the actual error in the log file /var/log/fuel-bootstrap-image-
> build.log.
> You can also share this file with us via any public service (GoogleDrive,
> DropBox, etc) and we will check it for you.
>
> On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk 
> wrote:
>
>> Hi,
>>
>> The error about an internet connection is the only common case. You
>> should check the actual error in the log file
>> /var/log/fuel-bootstrap-image-build.log.
>> You can also share this file with us via any public service (GoogleDrive,
>> DropBox, etc) and we will check it for you.
>>
>>
>> On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:
>>
>>> hi all,
>>>
>>> I'm trying to install fuel in VirtualBox, the fuel master is correctly
>>> running but I'm receiving the this error on the fuel GUI:
>>>
>>> WARNING: Failed to build the bootstrap image, see
>>> /var/log/fuel-bootstrap-image-build.log for details.
>>> Perhaps your Internet connection is broken. Please fix the problem and
>>> run `fuel-bootstrap build --activate`.
>>> While you don't activate any bootstrap - new nodes cannot be discovered
>>> and added to cluster.
>>> For more information please visit
>>> https://docs.mirantis.com/openstack/fuel/fuel-master/
>>>
>>> The fuel server has access to internet even though it could not find
>>> depots during install, I ran "yum update" and reboot but I still get this
>>> error.
>>> I configured a fuel-slave server boot from network attached to the
>>> fuel-master but the process failed also.
>>> Any help please to solve this ?
>>>
>>> Regards,
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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,
>> Maksim Malchuk,
>> Senior DevOps Engineer,
>> MOS: Product Engineering,
>> Mirantis, Inc
>> 
>>
>
>
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] (no subject)

[Sergii Golovatiuk]

Hi,

I would like to nominate Maksim Malchuk to Fuel-Library Core team. He’s
been doing a great job so far [0]. He’s #2 reviewer and #2 contributor with
28 commits for last 90 days [1][2].

Fuelers, please vote with +1/-1 for approval/objection. Voting will be open
until July of 4th. This will go forward after voting is closed if there are
no objections.

Overall contribution:
[0] http://stackalytics.com/?user_id=mmalchuk
Fuel library contribution for last 90 days:
[1]  
http://stackalytics.com/report/contribution/fuel-library/90
http://stackalytics.com/report/users/mmalchuk
List of reviews:
[2]
https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.06.28 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160628T17

__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Alexander Kostrikov]

Hello, everybody!
Hello, Alex!
>I thought Rally was more for benchmarking.  Wouldn't Tempest make more
sense?
Rally is a good tool with nice api/usage/extensibility.
I really liked "up and running tests in 5 minutes" in Rally with clear
picture of what I am doing.
So, I 100% for a Rally as a QA.

Another note:
We will need to implement some HA tests, probably not in Rally.

On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin 
wrote:

>
>
> On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky 
> wrote:
>
>>
>> > On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
>> >
>> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
>> sense?
>>
>> According to Rally wiki page [1], it seems they have a verification layer
>> (Tempest so far). Hm, I wonder does it mean we will need to rewrite our
>> scenarios for Tempest?
>>
>>
> Rally consists of two main components: Rally Task and Rally Verification.
> They are totally separated.
> Task component is fully pluggable and you can run there whatever you want
> in whatever you want way.
> Verification component is hardcoded now. It was designed for
> managing(install, configure) and launching(execute and store results)
> Tempest. But we have a spec to make this component pluggable too.
>
>
>> - igor
>>
>>
>> [1] https://wiki.openstack.org/wiki/Rally
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Kind Regards,

Alexandr Kostrikov,

Mirantis, Inc.

35b/3, Vorontsovskaya St., 109147, Moscow, Russia


Tel.: +7 (495) 640-49-04
Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>

Skype: akostrikov_mirantis

E-mail: akostri...@mirantis.com 

*www.mirantis.com *
*www.mirantis.ru *
__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Igor Kalnitsky]

> On Jun 27, 2016, at 16:57, Andrey Kurilin  wrote:
> 
> Rally consists of two main components: Rally Task and Rally Verification. 
> They are totally separated.
> Task component is fully pluggable and you can run there whatever you want in 
> whatever you want way.

Andrey, thanks for explanation!

I wonder what are the benefits of using Rally then? We can run whatever we want 
by means of MCollective or Ansible. Is there something that could help us? I 
don't know, maybe some dashboard integration with per test results or running 
by tests by tag?

Besides, we don't run some tests if deployed configuration doesn't assume it. 
For instance, no need to run ceilometer test (and even show one) if we deploy 
env without it. Is it possible to achieve it with Rally?

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

Re: [openstack-dev] [nova] Need help to review patches porting Nova (unit tests) to Python 3

[Matt Riedemann]

On 6/27/2016 7:56 AM, Victor Stinner wrote:

Hi,

I'm working on a new Python 3 patches to port the "last" Nova unit
tests. For example, my current patch serie ports 1,107 more unit tests
(76% => 84%). Changes should be "quite simple" but I need your help to
review them! My serie of 10 patches starts at:
https://review.openstack.org/#/c/332701/

Please review also other Python 3 changes:
https://review.openstack.org/#/q/topic:bp/nova-python3-newton+status:open
("topic:bp/nova-python3-newton status:open")

If you need more information on Python 3, the reference is the wiki page:
https://wiki.openstack.org/wiki/Python3

Or come talk on the #openstack-python3 channel!

Victor

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



Keep in mind that Thursday 6/30 is the nova non-priority blueprint 
feature freeze (end of day really). So the majority of review focus this 
week should be on non-priority blueprints.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

[Andrey Kurilin]

On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky 
wrote:

>
> > On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
> >
> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
> According to Rally wiki page [1], it seems they have a verification layer
> (Tempest so far). Hm, I wonder does it mean we will need to rewrite our
> scenarios for Tempest?
>
>
Rally consists of two main components: Rally Task and Rally Verification.
They are totally separated.
Task component is fully pluggable and you can run there whatever you want
in whatever you want way.
Verification component is hardcoded now. It was designed for
managing(install, configure) and launching(execute and store results)
Tempest. But we have a spec to make this component pluggable too.


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



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

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

[Vladimir Kozhukalov]

As far as I understand, Rally is pluggable and one can implement any
scenario we need in pure Python (totally out of Tempest). See for example
[1].


[1] http://rally.readthedocs.io/en/latest/plugins/scenario_plugin.html

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky 
wrote:

>
> > On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
> >
> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
> According to Rally wiki page [1], it seems they have a verification layer
> (Tempest so far). Hm, I wonder does it mean we will need to rewrite our
> scenarios for Tempest?
>
> - igor
>
>
> [1] https://wiki.openstack.org/wiki/Rally
> __
> OpenStack Development Mailing 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] [Fuel] Replace OSTF with Rally

[Igor Kalnitsky]

> On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
> 
> I thought Rally was more for benchmarking.  Wouldn't Tempest make more sense? 
>  

According to Rally wiki page [1], it seems they have a verification layer 
(Tempest so far). Hm, I wonder does it mean we will need to rewrite our 
scenarios for Tempest? 

- igor


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

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

[Dougal Matthews]

On 27 June 2016 at 14:30, Alexey Khivin  wrote:

> Hello, Moshe
>
> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
> tool!
>
> But suddenly I was said that the expression
> [1,2].join([3], true, [$1, $2])
> evaluated to [[1,3]] on the yaqluator
>
> A the same time this expression evaluated right when I using raw yaql
> interpreter.
>
> Could we fix this issue?
>
> By the way, don't you want to make yaqluator opensource? If you would
> transfer yaqluator to Openstack Foundation, then  community will be able to
> fix such kind of bugs
>

It looks like it is open source, there is a link in the footer:
https://github.com/ALU-CloudBand/yaqluator


>
> Thank you!
> Best regards, Alexey Khivin
>
>
>
> __
> OpenStack Development Mailing 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] [tricircle] About registering and loading a plugin

[Yipei Niu]

Dear all,

Recently, I learn to name a plugin based on the doc
http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I
define a new entry_point for the plugin, then it fails. The console prompts
"stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found,
looking for 'simple'". After setting a new entry_point with setuptools, why
stevedore cannot find the driver based on the entry_point?

Best regards,
Yipei
__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Andrey Kurilin]

Hi!

On Mon, Jun 27, 2016 at 4:23 PM, Alex Schultz  wrote:

>
>
> On Mon, Jun 27, 2016 at 7:10 AM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite
>> popular project and as far as I know it has all necessary features
>> (including dashboard). We only need to implement testing scenarios.
>>
>> In particular the suggestion is as follows
>>
>> 1) Implement necessary testing scenarios to achieve feature parity with
>> Fuel-ostf (including those which test Fuel HA features).
>> 2) Prepare necessary rpm/deb packages (Rally itself + scenarios)
>> 3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf.
>> 4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer
>> Fuel users to rely on Rally user interface (both CLI and dashboard).
>>
>> What do you think? Are there any volunteers to implement this?
>>
>>
> I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
>
Rally is not only about benchmarking, it provides a flexible interface
which allows to do whatever you want:)


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


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

[openstack-dev] [mistral] [murano] [yaql] yaqluator bug

[Alexey Khivin]

Hello, Moshe

Tomorrow I discovered yaqluator.com for myself! Thanks for the useful tool!

But suddenly I was said that the expression
[1,2].join([3], true, [$1, $2])
evaluated to [[1,3]] on the yaqluator

A the same time this expression evaluated right when I using raw yaql
interpreter.

Could we fix this issue?

By the way, don't you want to make yaqluator opensource? If you would
transfer yaqluator to Openstack Foundation, then  community will be able to
fix such kind of bugs

Thank you!
Best regards, Alexey Khivin
__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Alex Schultz]

On Mon, Jun 27, 2016 at 7:10 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite
> popular project and as far as I know it has all necessary features
> (including dashboard). We only need to implement testing scenarios.
>
> In particular the suggestion is as follows
>
> 1) Implement necessary testing scenarios to achieve feature parity with
> Fuel-ostf (including those which test Fuel HA features).
> 2) Prepare necessary rpm/deb packages (Rally itself + scenarios)
> 3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf.
> 4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer
> Fuel users to rely on Rally user interface (both CLI and dashboard).
>
> What do you think? Are there any volunteers to implement this?
>
>
I thought Rally was more for benchmarking.  Wouldn't Tempest make more
sense?

-Alex


>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing 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] [Fuel] Failed to build the bootstrap image

[Maksim Malchuk]

Hi,

The error about an internet connection is the only common case. You should
check the actual error in the log file /var/log/fuel-bootstrap-image-
build.log.
You can also share this file with us via any public service (GoogleDrive,
DropBox, etc) and we will check it for you.

On Mon, Jun 27, 2016 at 4:08 PM, Maksim Malchuk 
wrote:

> Hi,
>
> The error about an internet connection is the only common case. You should
> check the actual error in the log file /var/log/fuel-bootstrap-image-
> build.log.
> You can also share this file with us via any public service (GoogleDrive,
> DropBox, etc) and we will check it for you.
>
>
> On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:
>
>> hi all,
>>
>> I'm trying to install fuel in VirtualBox, the fuel master is correctly
>> running but I'm receiving the this error on the fuel GUI:
>>
>> WARNING: Failed to build the bootstrap image, see
>> /var/log/fuel-bootstrap-image-build.log for details.
>> Perhaps your Internet connection is broken. Please fix the problem and
>> run `fuel-bootstrap build --activate`.
>> While you don't activate any bootstrap - new nodes cannot be discovered
>> and added to cluster.
>> For more information please visit
>> https://docs.mirantis.com/openstack/fuel/fuel-master/
>>
>> The fuel server has access to internet even though it could not find
>> depots during install, I ran "yum update" and reboot but I still get this
>> error.
>> I configured a fuel-slave server boot from network attached to the
>> fuel-master but the process failed also.
>> Any help please to solve this ?
>>
>> Regards,
>>
>> __
>> OpenStack Development Mailing 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,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> 
>



-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

[openstack-dev] [Fuel] Replace OSTF with Rally

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite popular
project and as far as I know it has all necessary features (including
dashboard). We only need to implement testing scenarios.

In particular the suggestion is as follows

1) Implement necessary testing scenarios to achieve feature parity with
Fuel-ostf (including those which test Fuel HA features).
2) Prepare necessary rpm/deb packages (Rally itself + scenarios)
3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf.
4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer
Fuel users to rely on Rally user interface (both CLI and dashboard).

What do you think? Are there any volunteers to implement this?


Vladimir Kozhukalov
__
OpenStack Development Mailing 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] Failed to build the bootstrap image

[Maksim Malchuk]

Hi,

The error about an internet connection is the only common case. You should
check the actual error in the log file /var/log/fuel-bootstrap-image-
build.log.
You can also share this file with us via any public service (GoogleDrive,
DropBox, etc) and we will check it for you.


On Mon, Jun 27, 2016 at 1:43 PM, Alioune  wrote:

> hi all,
>
> I'm trying to install fuel in VirtualBox, the fuel master is correctly
> running but I'm receiving the this error on the fuel GUI:
>
> WARNING: Failed to build the bootstrap image, see
> /var/log/fuel-bootstrap-image-build.log for details.
> Perhaps your Internet connection is broken. Please fix the problem and run
> `fuel-bootstrap build --activate`.
> While you don't activate any bootstrap - new nodes cannot be discovered
> and added to cluster.
> For more information please visit
> https://docs.mirantis.com/openstack/fuel/fuel-master/
>
> The fuel server has access to internet even though it could not find
> depots during install, I ran "yum update" and reboot but I still get this
> error.
> I configured a fuel-slave server boot from network attached to the
> fuel-master but the process failed also.
> Any help please to solve this ?
>
> Regards,
>
> __
> OpenStack Development Mailing 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,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

Re: [openstack-dev] [mistral] Cancelling team meeting today - 06/27/2016

[Dougal Matthews]

Last week the topic of timeslot came up, would it be good to start that
discussion?

Maybe we can have a vote on slots, and since we would need the PTL to
attend it
would be best to start with a list of times that work for you.

Or, if most people are happy with the current time, we can just stick with
that!

Cheers,
Dougal


On 27 June 2016 at 13:52, Renat Akhmerov  wrote:

> Hi,
>
> We’re cancelling today’s meeting since some key members won’t be there.
> See you next time.
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing 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] [mistal] Mistral logo ideas?

[Dougal Matthews]

On 27 June 2016 at 07:45, Renat Akhmerov  wrote:

>
> > Ideally it would be nice to have something that matches the meaning of
> the
> > name. Maybe we can combine wind with one of the other ideas.
> >
> > I like the idea of the logo being a stylized wind turbine. Perhaps it
> could be
> > a turbine with a gust of wind. Then we can show that Mistral harnesses
> the
> > power of the wind :-)
>
> Yeah, I’m just wondering how it would look like :)
>
>
Yeah, for this idea we probably need somebody with artistic skills far
superior
to anything I could manage. We are getting quite a few good ideas now
anyway!


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

[openstack-dev] [nova] Need help to review patches porting Nova (unit tests) to Python 3

[Victor Stinner]

Hi,

I'm working on a new Python 3 patches to port the "last" Nova unit 
tests. For example, my current patch serie ports 1,107 more unit tests 
(76% => 84%). Changes should be "quite simple" but I need your help to 
review them! My serie of 10 patches starts at:

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

Please review also other Python 3 changes:
https://review.openstack.org/#/q/topic:bp/nova-python3-newton+status:open
("topic:bp/nova-python3-newton status:open")

If you need more information on Python 3, the reference is the wiki page:
https://wiki.openstack.org/wiki/Python3

Or come talk on the #openstack-python3 channel!

Victor

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

[openstack-dev] [mistral] Cancelling team meeting today - 06/27/2016

[Renat Akhmerov]

Hi,

We’re cancelling today’s meeting since some key members won’t be there. See you 
next time.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [puppet] weekly meeting #86

[Emilien Macchi]

Hi,

If you have any topic for our meeting tomorrow, please add them on the etherpad:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160628

See you tomorrow,

On Tue, Jun 21, 2016 at 10:59 AM, Emilien Macchi  wrote:
> Meeting cancelled, no topics this week.
>
> See you next week!
>
> On Mon, Jun 20, 2016 at 9:44 AM, Emilien Macchi  wrote:
>> Hi Puppeteers!
>>
>> We'll have our weekly meeting tomorrow at 3pm UTC on
>> #openstack-meeting-4.
>>
>> Here's a first agenda:
>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160621
>>
>> Feel free to add more topics, and any outstanding bug and patch.
>>
>> See you tomorrow!
>> Thanks,
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [stable][all] proactive backports

[Ihar Hrachyshka]

Hi all,

stable maintenance team seeks feedback on the proactive backports approach that 
was adopted by Neutron in Mitaka and is to be considered for wider 
experimentation by other interested projects: 
https://review.openstack.org/#/c/322273/

This email is to seek reviews on the patch describing the approach, as well as 
to hear from projects other than Neutron on whether the idea is applicable to 
them, and if not, what can be improved/generalized to make it so. It would 
definitely be cool to hear about actual attempts to follow the procedure, if 
there are brave folks in the community.

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

Re: [openstack-dev] [Fuel] Failed to build the bootstrap image

[Sergii Golovatiuk]

Hi,

You may try to build bootstrap from CLI using [1]. It will produce more
output for detailed investigation.


[1]
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/bootstrap/bootstrap_builder.html

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jun 27, 2016 at 12:43 PM, Alioune  wrote:

> hi all,
>
> I'm trying to install fuel in VirtualBox, the fuel master is correctly
> running but I'm receiving the this error on the fuel GUI:
>
> WARNING: Failed to build the bootstrap image, see
> /var/log/fuel-bootstrap-image-build.log for details.
> Perhaps your Internet connection is broken. Please fix the problem and run
> `fuel-bootstrap build --activate`.
> While you don't activate any bootstrap - new nodes cannot be discovered
> and added to cluster.
> For more information please visit
> https://docs.mirantis.com/openstack/fuel/fuel-master/
>
> The fuel server has access to internet even though it could not find
> depots during install, I ran "yum update" and reboot but I still get this
> error.
> I configured a fuel-slave server boot from network attached to the
> fuel-master but the process failed also.
> Any help please to solve this ?
>
> Regards,
>
> __
> OpenStack Development Mailing 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] Designate issue

[Hayes, Graham]

On 27/06/2016 12:24, sonali.pra...@accenture.com wrote:
> Hi team,
>
>
>
> I have a doubt ..can we have designate and mysql in two different nodes??
>
> And even the rabbitmq
>
> Will they communicate with each other like the normal openstack components.

Hi Sonali,

Yes, Designate can talk to MySQL and RabbitMQ on different nodes.
We use the standard openstack libraries to talk to both MySQL and RMQ,
so as long as the Designate nodes have network access, they can use
them.

Thanks,

Graham

> Regards,
>
> Sonali
>
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
> Where allowed by local law, electronic communications with Accenture and
> its affiliates, including e-mail and instant messaging (including
> content), may be scanned by our systems for the purposes of information
> security and assessment of internal compliance with Accenture policy.
> __
>
> www.accenture.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] [grenade] upgrades vs rootwrap

[Sean Dague]

On 06/26/2016 10:02 PM, Angus Lees wrote:
> On Fri, 24 Jun 2016 at 20:48 Sean Dague  > wrote:
> 
> On 06/24/2016 05:12 AM, Thierry Carrez wrote:
> > I'm adding Possibility (0): change Grenade so that rootwrap
> filters from
> > N+1 are put in place before you upgrade.
> 
> If you do that as general course what you are saying is that every
> installer and install process includes overwriting all of rootwrap
> before every upgrade. Keep in mind we do upstream upgrade as offline,
> which means that we've fully shut down the cloud. This would remove the
> testing requirement that rootwrap configs were even compatible between N
> and N+1. And you think this is theoretical, you should see the patches
> I've gotten over the years to grenade because people didn't see an issue
> with that at all. :)
> 
> I do get that people don't like the constraints we've self imposed, but
> we've done that for very good reasons. The #1 complaint from operators,
> for ever, has been the pain and danger of upgrading. That's why we are
> still trademarking new Juno clouds. When you upgrade Apache, you don't
> have to change your config files.
> 
> 
> In case it got lost, I'm 100% on board with making upgrades safe and
> straightforward, and I understand that grenade is merely a tool to help
> us test ourselves against our process and not an enemy to be worked
> around.  I'm an ops guy proud and true and hate you all for making
> openstack hard to upgrade in the first place :P
> 
> Rootwrap configs need to be updated in line with new rootwrap-using code
> - that's just the way the rootwrap security mechanism works, since the
> security "trust" flows from the root-installed rootwrap config files.
> 
> I would like to clarify what our self-imposed upgrade rules are so that
> I can design code within those constraints, and no-one is answering my
> question so I'm just getting more confused as this thread progresses...
> 
> ***
> What are we trying to impose on ourselves for upgrades for the present
> and near future (ie: while rootwrap is still a thing)?
> ***
> 
> A. Sean says above that we do "offline" upgrades, by which I _think_ he
> means a host-by-host (or even global?) "turn everything (on the same
> host/container) off, upgrade all files on disk for that host/container,
> turn it all back on again".  If this is the model, then we can trivially
> update rootwrap files during the "upgrade" step, and I don't see any
> reason why we need to discuss anything further - except how we implement
> this in grenade.
> 
> B. We need to support a mix of old + new code running on the same
> host/container, running against the same config files (presumably
> because we're updating service-by-service, or want to minimise the
> service-unavailability during upgrades to literally just a process
> restart).  So we need to think about how and when we stage config vs
> code updates, and make sure that any overlap is appropriately allowed
> for (expand-contract, etc).
> 
> C. We would like to just never upgrade rootwrap (or other config) files
> ever again (implying a freeze in as_root command lines, effective ~a
> year ago).  Any config update is an exception dealt with through
> case-by-case process and release notes.
> 
> 
> I feel like the grenade check currently implements (B) with a 6 month
> lead time on config changes, but the "theory of upgrade" doc and our
> verbal policy might actually be (C) (see this thread, eg), and Sean
> above introduced the phrase "offline" which threw me completely into
> thinking maybe we're aiming for (A).  You can see why I'm looking for
> clarification  ;)

Ok, there is theory of what we are striving for, and there is what is
viable to test consistently.

The thing we are shooting for is making the code Continuously
Deployable. Which means the upgrade process should be "pip install -U
$foo && $foo-manage db-sync" on the API surfaces and "pip install -U
$foo; service restart" on everything else.

Logic we can put into the python install process is common logic shared
by all deployment tools, and we can encode it in there. So all
installers just get it.

The challenge is there is no facility for config file management in
python native packaging. Which means that software which *depends* on
config files for new or even working features now moves from the camp of
CDable to manual upgrade needed. What you need to do is in releasenotes,
not in code that's shipped with your software. Release notes are not
scriptable.

So, we've said, doing that has to be the exception and not the rule.
It's also the same reasoning behind our deprecation phase for all config
options. Things move from working (in N), to working with warnings (in
N+1), to not working (in N+2). Which allows people to CD across this
boundary, and do config file fixing in their Config Management tools
*post* upgrade.

Our testing, like all testing, 

[openstack-dev] Designate issue

[sonali.prasad]

Hi team,

I have a doubt ..can we have designate and mysql in two different nodes??
And even the rabbitmq
Will they communicate with each other like the normal openstack components.

Regards,
Sonali



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.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] Openstack Neutron lbaas question

[Ihar Hrachyshka]

> On 23 Jun 2016, at 18:06, Doug Wiegley  wrote:
> 
> Hi,
> 
> LBaaS is installed automatically if neutron is present.

Doug,

I am not sure what you mean by that. Do you suggest that all distributions 
install lbaas through neutron package dependencies? Because if that’s the 
suggestion, it does not hold for at least RDO/OSP based packages.

*aas are not required to be installed with neutron. They may be installed by 
users specifically interested in those additional components.

Am I missing something?

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] [Fuel] Failed to build the bootstrap image

[Alioune]

hi all,

I'm trying to install fuel in VirtualBox, the fuel master is correctly
running but I'm receiving the this error on the fuel GUI:

WARNING: Failed to build the bootstrap image, see
/var/log/fuel-bootstrap-image-build.log for details.
Perhaps your Internet connection is broken. Please fix the problem and run
`fuel-bootstrap build --activate`.
While you don't activate any bootstrap - new nodes cannot be discovered and
added to cluster.
For more information please visit
https://docs.mirantis.com/openstack/fuel/fuel-master/

The fuel server has access to internet even though it could not find depots
during install, I ran "yum update" and reboot but I still get this error.
I configured a fuel-slave server boot from network attached to the
fuel-master but the process failed also.
Any help please to solve this ?

Regards,
__
OpenStack Development Mailing 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][general] Multiple implementation of /usr/bin/foo stored at the same location, leading to conflicts

[Ihar Hrachyshka]

> On 22 Jun 2016, at 17:55, Thomas Goirand  wrote:
> 
> On 06/22/2016 02:33 PM, Haïkel wrote:
>> Yes, RDO faced the very same issue:
>> https://github.com/rdo-packages/neutron-fwaas-distgit/blob/rpm-master/openstack-neutron-fwaas.spec#L115
>> 
>> My understanding was that neutron folks were looking for a solution,
>> but we ship this workaround for now a month.
>> 
>> Regards,
>> H
> 
> FYI, neutron-fwaas isn't the only thing that has the problem. Also,
> networking-sfc has the issue (with /usr/bin/neutron-openvswitch-agent).
> Which is why I thought it was a good idea to raise the awareness through
> a thread on this list, rather than just filing a bug.
> 
> And BTW, here's the bug for networking-sfc:
> https://bugs.launchpad.net/networking-sfc/+bug/1595211

For SFC, the proper solution would be to get rid of their agent completely:

https://bugs.launchpad.net/networking-sfc/+bug/1586024

That will take time though, so if that’s something breaking flow for packagers, 
SFC project should probably rename their agent for now:

https://review.openstack.org/334398

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] UpgradeImpact flag vs 'upgrade' in reno

[Akihiro Motoki]

Do we need to use both UpgradeImpact flag in commit messages and
'upgrade' section in reno?

Many projects now use reno and reno has 'upgrade' section to inform
operators/users of upgrade impact changes.
I wonder we still need to use UpgradeImpact flag in commit messages.

Akihiro

__
OpenStack Development Mailing 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] Deprecation of fuel-mirror tool

[Vladimir Kozhukalov]

Fuel-mirror python module itself will be removed from fuel-mirror
repository, but perestroika is to be there until Packetary is able to
substitute perestroika totally (work is now in progress).

Just a reminder: According to our plan Packetary is to cover the whole
rpm/deb domain including building deb/rpm packages and repositories.
Sincing these repos over multiple locations as well as tracking repository
snapshots will be a matter of Trsync project (Fuel infra team project).

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 11:38 AM, Igor Kalnitsky 
wrote:

> Vladimir,
>
> Thanks for driving this! What about fuel-mirror itself? Does it mean it's
> deprecated? If so, what will happen to perestroika scripts inside it [1]?
> It seems strange that fuel-mirror contains them.
>
> Thanks,
> Igor
>
> [1] https://github.com/openstack/fuel-mirror/tree/master/perestroika
>
>
> > On Jun 23, 2016, at 13:31, Vladimir Kozhukalov 
> wrote:
> >
> > Dear colleagues.
> >
> > I'd like to announce that fuel-mirror tool is not going to be a part of
> Fuel any more. Its functionality is to build/clone rpm/deb repos and modify
> Fuel releases repository lists (metadata).
> >
> > Since Fuel 10.0 it is recommended to use other available tools for
> managing local deb/rpm repositories.
> >
> > Packetary is a good example [0]. Packetary is ideal if one needs to
> create a partial mirror of a deb/rpm repository, i.e. mirror that contains
> not all available packages but only a subset of packages. To create full
> mirror it is better to use debmirror or rsync or any other tools that are
> available.
> >
> > To modify releases repository lists one can use commands which are to
> available by default on the Fuel admin node since Newton.
> >
> > # list of available releases
> > fuel2 release list
> > # list of repositories for a release
> > fuel2 release repos list 
> > # save list of repositories for a release in yaml format
> > fuel2 release repos list  -f yaml | tee repos.yaml
> > # modify list of repositories
> > vim repos.yaml
> > # update list of repositories for a release from yaml file
> > fuel2 release repos update  -f repos.yaml
> >
> > They are provided by python-fuelclient [1] package and were introduced
> by this [2] patch.
> >
> >
> > [0] https://wiki.openstack.org/wiki/Packetary
> > [1] https://github.com/openstack/python-fuelclient
> > [2] https://review.openstack.org/#/c/326435/
> >
> >
> > Vladimir Kozhukalov
> >
> __
> > OpenStack Development Mailing 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] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Thanks everyone for your opinions.

All #fuel-* channels have been notified as deprecated. Now #fuel is our
official and the only channel (updated https://wiki.openstack.org/wiki/IRC).
As for renaming #fuel into #openstack-fuel I think it makes little sense
and not necessary, since some (even core) OpenStack projects don't use
'openstack' prefix. Besides, many Fuel users already got used to #fuel and
deprecating it would introduce extra efforts and inconveniencies.

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 11:42 AM, Igor Kalnitsky 
wrote:

> > On Jun 25, 2016, at 12:39, Roman Prykhodchenko  wrote:
> >
> > Since Fuel is a part of OpenStack now, should we rename #fuel to
> #openstack-fuel?
> >
> > - romcheg
>
> +1. Let's be consistent in naming convention with most Big Tent projects.
>
> - igor
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs

[Vikas Choudhary]

On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq  wrote:

> Vikas,
>
> Thanks for starting this. Where would you classify the Segmentation
> (VLANID etc) allocation engine. Currently, the libnetwork plugin is tied to
> the api and talks to Neutron, how would libnetwork and api part interact?
>
> As per my current understanding, it should be present be part of
Kuryr-controller(server) running on cluster master node. My proposal is to
move all neutron api calling part to kuryr-controller and let libnetwork
plugin make request to kuryr-controller.


> Fawad Khaliq
>
>
> On Fri, Jun 24, 2016 at 9:45 AM, Vikas Choudhary <
> choudharyvika...@gmail.com> wrote:
>
>> Hi Team,
>>
>> As already discussed with some of teammates over irc and internally,
>> thought of bringing discussionto ml for more opinions:
>>
>> My idea on repo structure is something similar to this:
>>
>> kuryr
>> └── controller
>> │   ├── api (running on controller node(cluster master or openstack
>> controller node), talking to other services(neutron))
>> │   │
>> │   ├── kubernetes-controller
>> │   │   │
>> │   │   └── watcher (for network related services making api calls)
>> │   │
>> │   │___any_other_coe_controller_capable_of_watching_events
>> │
>> │
>> │
>> │___driver
>>  │common (traffic tagging utilities and binding)
>>  │
>>  │kubernetes(cni)
>>  │
>>  │libnetwork(network and ipam driver)(for network related
>> services making api calls)
>>  │
>>  │ any_other_driver(calling api for nw related services if
>> watcher not supported)
>>
>>
>> Thoughts?
>>
>>
>> -Vikas
>>
>>
>>
>>
>> -- Forwarded message --
>> From: Vikas Choudhary 
>> Date: Thu, Jun 23, 2016 at 2:54 PM
>> Subject: Re: Kuryr Refactoring into common library and kuryr-libnetwork +
>> Nested_VMs
>> To: Antoni Segura Puimedon 
>>
>>
>> @Toni, Can you please explain a bit on how the roles regarding
>>  vlan/segmentation id allocation, tagging ang untagging containers' traffic
>> are divided among entities you mentioned.
>>
>> In my understanding, in k8s case, API_watcher has resource translators
>> and these will be talking to neutron for port creation and ip allocation.
>> Then why for k8s case, neutron talking utilities are present in common lib.
>> Or in other words, which neutron apis will be used from common lib?
>>
>> -Vikas
>>
>> On Thu, Jun 23, 2016 at 2:22 PM, Antoni Segura Puimedon <
>> t...@midokura.com> wrote:
>>
>>>
>>>
>>> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky 
>>> wrote:
>>>
 Hi guys,
 Just minor suggestion from my side. Please link all the refactoring
 patches to the same launchpad bp/topic so it will be easy to trace the
 relevant work.

 Vikas, Gal,let me know if you need so help.

 BR,
 Irena

 On Thu, Jun 23, 2016 at 7:58 AM, Vikas Choudhary <
 choudharyvika...@gmail.com> wrote:

> Hi Gal,
>
> Greeting of the day!!!
>
> I have trying reaching you over irc unsuccessfully since last two
> days. So finally thought of dropping an email.
>
> Since you have taken up the task of moving code to kuryr-libnetwork
> and I also have started working on refactoring/changes for nested-vm, 
> seems
> there is some overlap. Therefore wanted to coordinate following two tasks:
>
> 1. Writing a common(COE agnostic) library , "Kuryr_api" or some other
> similar name, responsible for handling requests from kuryr-libnetwork and
> making requests to other OpenStack services.
>
> 2. Modify current kuryr controllers.py to make calls to common
> "Kuryr_api" and not to OpenStack services directly.
>

>>> My idea was to leave:
>>>
>>> https://github.com/openstack/kuryr
>>>
>>> with a single package
>>>
>>> kuryr
>>> └── lib
>>> ├── binding
>>> │   └── __init__.py
>>> └── __init__.py
>>>
>>>
>>>  that would contain just a library with the common  bits like the
>>> controller, the binding, and utils to talk to neutron.
>>>
>>> Then, the other repos like openstack/kuryr-libnetwork and
>>> openstack/kuryr-kubernetes would have a package like the following:
>>>
>>> kuryr
>>> └── kubernetes
>>> ├── cni
>>> │   └── __init__.py
>>> ├── __init__.py
>>> └── watcher
>>> └── __init__.py
>>>
>>> This way, all would be inside the namespace Python package kuryr (read
>>> the first and second answers to
>>> http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python
>>>
>>>
>>>
>>>
> Shall i start working on both of these or you are already working on
> either one? Please suggest.
>
>
> -Vikas
>
>
>

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

[openstack-dev] Adieu

[Bharath Kumar Gubbala]

Hello All,

Finally the moment has arrived to say goodbye, which is never easy, especially 
when you have been part of the BROCADE family.It has been a fantastic journey 
and a great learning experience where I have enjoyed every moment and I 
appreciate having had the opportunity to work with each of you with whom I have 
interacted.


Sincere thanks to Alex and all my colleagues for their support and guidance to 
excel in my career.I am also very thankful to the Openstack and VRouter Team 
members who were always there to guide me throughout the journey. And a very 
Big "Thank You" to all my friends with whom I have spent the wonderful moments, 
that would last a lifetime.

Even though I will miss you all, I am looking forward to this new challenge and 
to start a new phase in my career. I wish you all the very best in life. I am 
reachable at my personal email bharathkumar.e...@gmail.com and Contact number 
+919632892989.


It was a pleasure knowing each and every one of you. In case I have 
unintentionally hurt any one, please forgive me. Needless to say, please stay 
in touch.

Thanks & Best Regards,

G Bharath Kumar
__
OpenStack Development Mailing 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][qos] QoS for floatingip

[zhi]

Hi, all.

As far as I know, currently networking QoS aims to "qvo" devices which
attached to the internal ovs bridge.

I think we need a solution to control floatingip's rate limit. Do we
have any plan
to implement rate limit for floatingip? I think that we can use TC to
implement it.

Hope for your reply ;-)



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

Re: [openstack-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs

[Fawad Khaliq]

Vikas,

Thanks for starting this. Where would you classify the Segmentation (VLANID
etc) allocation engine. Currently, the libnetwork plugin is tied to the api
and talks to Neutron, how would libnetwork and api part interact?

Fawad Khaliq


On Fri, Jun 24, 2016 at 9:45 AM, Vikas Choudhary  wrote:

> Hi Team,
>
> As already discussed with some of teammates over irc and internally,
> thought of bringing discussionto ml for more opinions:
>
> My idea on repo structure is something similar to this:
>
> kuryr
> └── controller
> │   ├── api (running on controller node(cluster master or openstack
> controller node), talking to other services(neutron))
> │   │
> │   ├── kubernetes-controller
> │   │   │
> │   │   └── watcher (for network related services making api calls)
> │   │
> │   │___any_other_coe_controller_capable_of_watching_events
> │
> │
> │
> │___driver
>  │common (traffic tagging utilities and binding)
>  │
>  │kubernetes(cni)
>  │
>  │libnetwork(network and ipam driver)(for network related
> services making api calls)
>  │
>  │ any_other_driver(calling api for nw related services if
> watcher not supported)
>
>
> Thoughts?
>
>
> -Vikas
>
>
>
>
> -- Forwarded message --
> From: Vikas Choudhary 
> Date: Thu, Jun 23, 2016 at 2:54 PM
> Subject: Re: Kuryr Refactoring into common library and kuryr-libnetwork +
> Nested_VMs
> To: Antoni Segura Puimedon 
>
>
> @Toni, Can you please explain a bit on how the roles regarding
>  vlan/segmentation id allocation, tagging ang untagging containers' traffic
> are divided among entities you mentioned.
>
> In my understanding, in k8s case, API_watcher has resource translators and
> these will be talking to neutron for port creation and ip allocation. Then
> why for k8s case, neutron talking utilities are present in common lib. Or
> in other words, which neutron apis will be used from common lib?
>
> -Vikas
>
> On Thu, Jun 23, 2016 at 2:22 PM, Antoni Segura Puimedon  > wrote:
>
>>
>>
>> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky 
>> wrote:
>>
>>> Hi guys,
>>> Just minor suggestion from my side. Please link all the refactoring
>>> patches to the same launchpad bp/topic so it will be easy to trace the
>>> relevant work.
>>>
>>> Vikas, Gal,let me know if you need so help.
>>>
>>> BR,
>>> Irena
>>>
>>> On Thu, Jun 23, 2016 at 7:58 AM, Vikas Choudhary <
>>> choudharyvika...@gmail.com> wrote:
>>>
 Hi Gal,

 Greeting of the day!!!

 I have trying reaching you over irc unsuccessfully since last two days.
 So finally thought of dropping an email.

 Since you have taken up the task of moving code to kuryr-libnetwork and
 I also have started working on refactoring/changes for nested-vm, seems
 there is some overlap. Therefore wanted to coordinate following two tasks:

 1. Writing a common(COE agnostic) library , "Kuryr_api" or some other
 similar name, responsible for handling requests from kuryr-libnetwork and
 making requests to other OpenStack services.

 2. Modify current kuryr controllers.py to make calls to common
 "Kuryr_api" and not to OpenStack services directly.

>>>
>> My idea was to leave:
>>
>> https://github.com/openstack/kuryr
>>
>> with a single package
>>
>> kuryr
>> └── lib
>> ├── binding
>> │   └── __init__.py
>> └── __init__.py
>>
>>
>>  that would contain just a library with the common  bits like the
>> controller, the binding, and utils to talk to neutron.
>>
>> Then, the other repos like openstack/kuryr-libnetwork and
>> openstack/kuryr-kubernetes would have a package like the following:
>>
>> kuryr
>> └── kubernetes
>> ├── cni
>> │   └── __init__.py
>> ├── __init__.py
>> └── watcher
>> └── __init__.py
>>
>> This way, all would be inside the namespace Python package kuryr (read
>> the first and second answers to
>> http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python
>>
>>
>>
>>
 Shall i start working on both of these or you are already working on
 either one? Please suggest.


 -Vikas



>>>
>>
>
>
> __
> OpenStack Development Mailing 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] [Fuel] Merge IRC channels

[Igor Kalnitsky]

> On Jun 25, 2016, at 12:39, Roman Prykhodchenko  wrote:
> 
> Since Fuel is a part of OpenStack now, should we rename #fuel to 
> #openstack-fuel?
> 
> - romcheg

+1. Let's be consistent in naming convention with most Big Tent projects.

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

Re: [openstack-dev] [Fuel] Deprecation of fuel-mirror tool

[Igor Kalnitsky]

Vladimir,

Thanks for driving this! What about fuel-mirror itself? Does it mean it's 
deprecated? If so, what will happen to perestroika scripts inside it [1]? It 
seems strange that fuel-mirror contains them.

Thanks,
Igor

[1] https://github.com/openstack/fuel-mirror/tree/master/perestroika


> On Jun 23, 2016, at 13:31, Vladimir Kozhukalov  
> wrote:
> 
> Dear colleagues.
> 
> I'd like to announce that fuel-mirror tool is not going to be a part of Fuel 
> any more. Its functionality is to build/clone rpm/deb repos and modify Fuel 
> releases repository lists (metadata). 
> 
> Since Fuel 10.0 it is recommended to use other available tools for managing 
> local deb/rpm repositories. 
> 
> Packetary is a good example [0]. Packetary is ideal if one needs to create a 
> partial mirror of a deb/rpm repository, i.e. mirror that contains not all 
> available packages but only a subset of packages. To create full mirror it is 
> better to use debmirror or rsync or any other tools that are available.
> 
> To modify releases repository lists one can use commands which are to 
> available by default on the Fuel admin node since Newton.
> 
> # list of available releases
> fuel2 release list
> # list of repositories for a release
> fuel2 release repos list 
> # save list of repositories for a release in yaml format
> fuel2 release repos list  -f yaml | tee repos.yaml
> # modify list of repositories
> vim repos.yaml
> # update list of repositories for a release from yaml file 
> fuel2 release repos update  -f repos.yaml
> 
> They are provided by python-fuelclient [1] package and were introduced by 
> this [2] patch. 
> 
> 
> [0] https://wiki.openstack.org/wiki/Packetary 
> [1] https://github.com/openstack/python-fuelclient
> [2] https://review.openstack.org/#/c/326435/
> 
> 
> Vladimir Kozhukalov
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

[Thomas Goirand]

On 06/24/2016 12:13 PM, Amrith Kumar wrote:
>> -Original Message-
>> From: Doug Hellmann [mailto:d...@doughellmann.com]
>> Sent: Thursday, June 23, 2016 5:16 PM
>> To: openstack-dev 
>> Subject: Re: [openstack-dev] [all] Status of the OpenStack port to Python 3
>>
> [... snip ...]
>>
>> Let's see what PTLs have to say about planning, but I think if not
>> Ocata then we'd want to set one for the P release. We're running
>> out of supported lifetime for Python 2.7.
>>
>> Doug
>>
> 
> Doug, I believe py27 will be supported till end of 2020 but distribution
> vendors (os people) are not yet deploying py3 as the default.

*I* am not (in Debian) doing Py3 by default because there's no
functional test yet. As soon as there is, and I can prove that Debian
packages can work with Py3, I'll flip the switch.

> Could someone share the best information on when we may see Python3
> be the default from the various os distribution providers.

In Debian, we're suppose to deprecate Py3 in Stretch (aka: Debian 9, the
next stable, currently testing), and remove support for Py3 in Buster
(aka: Debian 10). From my stand point, the sooner we switch to Py3 the
better.

On 06/24/2016 05:43 PM, Doug Hellmann wrote:
> Some of the distros are starting to split the version of python
> they use for their operating system tools from the packages
> applications use, so the "default" version of Python isn't necessarily
> what we care about

Exactly! What counts isn't what interpreter (ie: Py2 or Py3) is the
default implementation for /usr/bin/python. What counts is what we
decide to use for as shebang for let's say /usr/bin/trove-conductor.
That, I can switch to Py3 whenever I decide.

On 06/24/2016 12:13 PM, Amrith Kumar wrote:
> The date of 2020 for EOS leads me to believe that we're good until about
> the U or V release (assuming two per year) but I don't believe that's
> the correct way to plan for this, yes?

That would be significantly too late from a distribution vendor
perspective. For Debian, we will have Stretch frozen early next year, so
Buster may be frozen in 2019, but we may remove Py2 before that. So,
IMO, it'd be reasonable to at least deprecate Py2 support for the "Q"
release of OpenStack (that's the first release of 2018). So, altogether,
it would make a lot of sense to make sure everything is working
correctly with Py3 for the O or P release of OpenStack, so we have
enough time to make sure everything is in order.

Therefore, the current goal of having everything (including functional
tests) Py3 ready for the O release is completely realistic, so we can
have all functional tests gating on Py3 for the P release.

On 06/24/2016 05:10 PM, Clint Byrum wrote:
> Fedora, Ubuntu, and Gentoo are already defaulting to python3 for all
> of their OS tools, so you can have a fully functioning system without
> python2.

Debian doesn't have Python in its default install (ie: if you
debootstrap a system without additional packages, Python isn't there).
Our own tooling are in the way of being ported, and even most are indeed
already Py3 by default (python3-debian is a good example).

On 06/24/2016 10:25 AM, Daniel P. Berrange wrote:
> Please lets not derail discussions about completing Py3 support by
> opening up the can of worms wrt dropping Py2.

The point I was trying to make is that the foreseeable drop of Py2
should be a great incentive to quickly finish the work on Py3, so we can
use features only seen on Py3. And indeed, dropping Py2 can only happen
after everything fully runs on Py3, including in distros and deployments.

Cheers,

Thomas Goirand (zigo)


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

[openstack-dev] [nova][scheduler] More test results for the "eventually consistent host state" prototype

[Cheng, Yingxin]

Hi,

According to the feedback [1] from Austin design summit, I prepared my 
environment with pre-loaded computes and finished a new round of performance 
profiling using the tool [7]. I also updated the prototype [2] to simplify the 
implementation in compute-node side, which makes the implementation closer to 
the design described in the spec [6].

This set of results are more comprehensive, it includes the analysis of 
“eventually consistent host states” prototype [2], default filter scheduler, 
and the caching scheduler. They are tested with various scenarios in 
1000-compute-node environment, with real controller services, real rabbit-MQ 
and real MySQL database. The new set of experiments contains 55 repeatable 
results [3]. Don’t be afraid about the verbose data, I’ve dug out the 
conclusions.

To better understand what’s happening during scheduling in different scenarios, 
all of them are visualized in the doc [4]. They are complementary to what I had 
presented in the Austin design summit, the 7th page of the ppt [5].

Note that the “pre-load scenario” allows only 49 new instances to be launched 
in the 1000-node environment. It means when 50 requests are sent, there should 
be 1 and only 1 failed request if the scheduler decision is accurate.


Detailed analysis with illustration [4]: 
https://docs.google.com/document/d/1qFNROdJxj4m1lXe250DW3XAAY02QHmlTm1N2nEHVVPg/edit?usp=sharing
 
==
In all test cases, nova is dispatching 50 instant requests to 1000 compute 
nodes. The aiming is to compare the behavior of 3 types of schedulers, with 
preloaded or empty-loaded scenarios, and with 1 or 2 scheduler services. So 
that’s 3*2*2=12 set of experiments, each set is tested multiple times. 

In scenario S1(i.e. 1 scheduler with empty loaded compute nodes), we can see 
from A2 very clearly that the entire boot process of filter scheduler is 
suffering from nova-scheduler service. Filter scheduler has a very slow speed 
to consume those 50 requests, causing all the requests being blocked before 
scheduler service in the yellow area. The ROOT CAUSE of it is the 
“cache-refresh” step before filtering (i.e. 
`nova.scheduler.filter_scheduler.FilterScheduler._get_all_host_states`). I’ve 
discussed this bottleneck in details in the Austin summit session “Dive into 
nova scheduler performance: where is the bottleneck” [8]. This is also proved 
by caching scheduler because it excludes the “cache-refresh” bottleneck and 
only uses in-memory filtering. By simply excluding “cache-refresh”, the 
performance benefits are huge: the query time is reduced by 87%, and the 
overall throughput (i.e. the delivered requests per second in this cloud) is 
multiplied by 8.24, see A3 for illustration. The “eventually consistent host 
states” prototype also excludes this bottleneck and takes a more meticulous way 
to synchronize scheduler caches. It is slightly slower than caching scheduler, 
because there is an overhead to apply incremental updates from compute nodes. 
The query time is reduced by 79% and the overall throughput is multiplied by 
5.63 in average in S1.

In preload scenario S2, we can see all 3 types of scheduler are faster than 
their empty loaded scenario. That’s because the filters can now prune the hosts 
from 1000 to only 49, so the last few filters don’t need to process 1000 host 
states, they can be much faster. But filter scheduler (B2) cannot be benefit 
much from faster filtering, because its bottleneck is still in “cache refresh”. 
However, it means different for caching scheduler and the prototype, because 
their performance heavily depend on in-memory filtering. For caching scheduler 
(B3), the query time is reduced by 81% and the overall throughput is multiplied 
by 7.52 compared with filter scheduler. And for the prototype (B1), the query 
time is reduced by 83% and the throughput is multiplied by 7.92 in average. 
Also, all those scheduler decisions are accurate, because their first decisions 
are all correct without any retries in preload scenario, and only 1 of 50 
requests is failed due to “no valid host” error.

In scenario S3 with 2 scheduler services and empty-loaded compute nodes, the 
overall schedule bandwidths are all multiplied by 2 internally. Filter 
scheduler (C2) has a major improvement, because its scheduler bandwidth is 
multiplied. But the other two types don’t have similar improvement, because 
their bottleneck is now in nova-api service instead. It is a wrong decision to 
add more schedulers when the actual bottleneck is happening elsewhere. And 
worse, multiple schedulers will introduce more race conditions as well as other 
overhead. However, the performance of caching scheduler (C3) and the prototype 
(C1) are still much better, the query time is reduced by 65% and the overall 
through is multiplied by 3.67 in average.

In preload scenario S4 with 2 schedulers, the race condition is surfaced 
because there’re only 49 slots in 1000 hosts in the cloud, and they will all 

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Na Zhu]

Hi MartinX,

I think you can move p2 to net1 and p3 to net4, or you can put p1, p2, p3 
and p4 in the same network.



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Cathy Zhang 
To: "OpenStack Development Mailing List (not for usage questions)" 
, "martinx.bans...@intel.com" 

Date:   2016/06/22 02:36
Subject:Re: [openstack-dev] networking-sfc: unable to use SFC (ovs 
driver) with multiple networks



Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Thursday, June 16, 2016 4:49 AM
To: 'openstack-dev@lists.openstack.org'
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) 
with multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be 
separated from the remaining virtual network topology or if it should be 
connected to it.

E.g. consider the following topology, where SFC and its networks net2 and 
net3 (one for ingress port, one for egress port) are connected to the 
tenants networks. I know that all three instances can share one network 
but a use case I am trying to implement requires that every instance has 
it's separated network and there is a different network for ingress and 
egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 
(4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- 
net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group 
and flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded 
back through the p3 port to the ROUTER.  The router finds out that there 
are packets with source address 1.1.1.1 coming from port where is should 
not (the router expects those packets from the net1 interface), they don't 
pass the reverse path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the 
sfc to work without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, 
and add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks 
respectivelly and don't connect them anyhow to the ROUTER nor the rest of 
the topology, the OVS is able to send the traffic to the p2 port on the 
ingress side. However, on the egress side the packet is routed to the 
ROUTER3 which drops it as it doesn't have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland 
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare 
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the 
sole use of the intended recipient(s). Any review or distribution by 
others is strictly prohibited. If you are not the intended recipient, 
please contact the sender and delete all copies.


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

- Message from Cathy Zhang  on Wed, 15 Jun 
2016 00:58:33 + -
To:
"OpenStack Development Mailing List (not for usage questions)" 

Re: [openstack-dev] [mistal] Mistral logo ideas?

[Renat Akhmerov]

> On 27 Jun 2016, at 08:14, hie...@vn.fujitsu.com wrote:
> 
> Hi folks,
> 
> Maybe smth simple like that: http://prntscr.com/blhcyq 

This is pretty cool IMO :)

I personally like Michal’s idea too. 

As far as relationship with french battleship Mistral I would avoid it. Yeah, 
it may be funny but I’d like not to have any associations with any 
political/military stuff.

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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] [mistal] Mistral logo ideas?

[Renat Akhmerov]

> Ideally it would be nice to have something that matches the meaning of the 
> name. Maybe we can combine wind with one of the other ideas.
> 
> I like the idea of the logo being a stylized wind turbine. Perhaps it could be
> a turbine with a gust of wind. Then we can show that Mistral harnesses the 
> power of the wind :-)

Yeah, I’m just wondering how it would look like :)

Renat Akhmerov
@Nokia



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