Re: [openstack-dev] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/22/16, 7:24 PM, "duon...@vn.fujitsu.com"  wrote:

>Hello Kollish,
>
>I am working on bp ansible-specific-task-become so I need community opinion 
>about Kolla configuration files owner and permissions.
>
>For files in "/var/lib/kolla", it's quite clear that the owner should be 
>'root' as currently.
>
>For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
>/etc/kolla is owned by root and all files in it is 660 (writable by a group).

Just to add a bit of clarity, the rationale for this idea is that a group of 
operators could add themselves to the kolla group on all of the nodes and use 
their specific ssh keys to operate OpenStack.  This is why the group concept in 
unix was invented 50 odd years ago ;)

Regards
-steve

>
>Anybody has idea about this topic?
>
>Best regards,
>
>Ha Quang Duong (Mr.)
>PODC - Fujitsu Vietnam Ltd.
>
>
>__
>OpenStack Development Mailing 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] [Fuel] Need Help in adding multiple External networks in Fuel 9.0

[Chandrasekhar Reddy]

Hi All,

I think this is right platform to ask my question. i will be thankful if
someone can help me in below mentioned use-case.

Here is my cloud setup:

I have 4 Nodes:

Controller Node : 1 No
Compute + Ceph Node : 2 No
Fuel Node : 1 No

My Interfaces are as below :

All 4 Nodes has *3 NIC cards * each.

eth0 : Admin ( PXE), Management (101), Storage (102), Internal (1000-1030)
eth1 : External ( Public )
eth2 : None

I am using *fuel 9.0* and i want to use provider network / Multiple
external networks with fuel. i had vlan networks on *eth1* as below

*eth1 : 192.168.200.0/24  ( Native ),
192.168.201.0/24  ( Trunk, 201 tagged ).
192.168.202.0/24  ( Trunk, 202 tagged )*


How i can add other two networks( 201, 202 ) to my cloud as external
network. appreciate anyone help on this.

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

Re: [openstack-dev] [oslo] support keymirror/valuemirror dict in olso

[Joshua Harlow]

So question I have is how would this work in python?

Any example anywhere?

Reason I am asking is that in the example:

> search_opts = {
>
> 'all_tenants': all_tenants,
>
> 'status': args.status,
>
> 'filter':filter,
>
> …….
>
> }

There is nothing really built-in to python afaik (besides locals or 
vars) that would let u figure out the name of those in any automatic 
manner so I'm not quite sure how u would determine they key names.


-Josh

Husheng (TommyLike, R IT Equipment Dept) wrote:

Hi all,

I have an idea about adding common function which creating an dictionary
with key equal to its values in OSLO. This is inspired by Key mirror in
node js(https://www.npmjs.com/package/keymirror).This is very useful
when we create dictionary like below:

search_opts = {

'all_tenants': all_tenants,

'status': args.status,

'filter':filter,

…….

}

What’s your opinion on this, is this reasonable ,necessary and reachable?

Thanks

TommyLike.Hu

__
OpenStack Development Mailing 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] [meghdwar] use case for meghdwar API - Continuing email discussions (CANCELLED-Meeting 24th Aug)

[prakash RAMCHANDRAN]

  
Hi all,

CANCELLED: Meeting Wednesday 24th August      (14 Hr-15 Hr UTC )   [7AM-8AM PDT]


Follow up on same points with updates aslast meeting.
1 Megdwar Gateway API discussions based on use case
Focus is what APIs needed for minimum use case of two cloudlets on two edges 
running 1 app each and how to move one of the apps from source edge gateway to 
destination edge gateway on compute nodes through those gateways.
APIs - requiredMeghdwar service process will have configuration file for each 
cloudlet at the Edge gateway.Dump (take Snapshot), Create , Read, List, Write, 
Start, Stop - Cloudlets
Reviewed other Catalog modules (application-catalog-ui, murano, murano-agent to 
be tested) on Rackspace
2. What other modules are needed in OpenStack 'meghdwar' Catalog Refer Murano 
(May be we use it) - Our Catalog can be for ASP, CSP,NSP and integrated through 
ESP.
To discuss Binder option for two cloudlets. as for two cloudlets with one app 
in 1 above.   c. Cloudlet Gateway Management  (Gateway Service Management) 
   d. python  Cloudlet  / MEC Gateway Management  4. How do we go about 
priority 
Consider two cloudlet Binders and see if we can use LXD and LXC ;live migration 
as 1st API implementation for Meghdwar.LXD 2.0: Live migration [9/12] | 
Stéphane Graber's website


  
|  
|   |  
LXD 2.0: Live migration [9/12] | Stéphane Graber's website
 Stéphane Graber's website -  |  |

  |

 

Please respond back if you have any other suggestions. Note since the Edge 
Cloud Presentation at OpenStack Meghdwar was not selected, we plan for Bird of 
Feather (BOF) session and if you are interested in joining please add your name 
to the etherpad.OpenStack Etherpad

  
|  
|   |  
OpenStack Etherpad
   |  |

  |

 


Thankspramchan

   __
OpenStack Development Mailing 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] [charms] tests/charmhelpers in venv and use bindep for bzr

[Ryan Beisner]

Hi OpenStack Charmers,

In prep for a move to a global requirements for OpenStack Charms, I'd like
to hit the master branches with a batch of cleanups.  This nets -2300 LoC
in the example Charm repo. ;-)

First, a pre-requisite charm-helpers merge proposal re: missing setup.py
entries for hardening.*:

 - https://code.launchpad.net/~1chb1n/charm-helpers/update-egg/+merge/303630

Then, a PoC example change on the Cinder Charm:

 - https://review.openstack.org/#/q/topic:tests-charmhelpers-venv

I seek review and comment on these prior to proposing the logic across all
of openstack/charm-*.  Note that this example is for "classic" charms.  The
change will look slightly different for "source" layered charms.

TIA!

Cheers,

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

[openstack-dev] [new][horizon] XStatic-smart-table 1.4.13.0 release

[no-reply]

We are ecstatic to announce the release of:

XStatic-smart-table 1.4.13.0: Installed /home/jenkins/workspace
/xstatic-angular-smart-table-announce-
release/.eggs/setuptools_scm-1.11.1-py2.7.egg

XStatic-smart-table ---

smart-table javascript library packaged for setuptools (easy_install)
/ pip.

This package is intended to be used by **any** project that needs
these files.

It intentionally does **not** provide any extra code except some
metadata **nor** has any extra requirements. You MAY use some minimal
support code from the XStatic base package, if you like.

You can find more info about the xstatic packaging way in the package
`XStatic`.

For more details, please see below.

Changes in XStatic-smart-table 1.4.13..1.4.13.0
---

a5ace69 Add basic tox.ini file


Diffstat (except docs and test files)
-

tox.ini | 7 +++
1 file changed, 7 insertions(+)




__
OpenStack Development Mailing 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] [oslo] support keymirror/valuemirror dict in olso

[Husheng (TommyLike, R IT Equipment Dept)]

Hi all,
  I have an idea about adding common function which creating an dictionary 
with key equal to its values in OSLO. This is inspired by Key mirror in node 
js(https://www.npmjs.com/package/keymirror).This is very useful when we create 
dictionary like below:
search_opts = {
'all_tenants': all_tenants,
'status': args.status,
'filter':filter,
 ...
}
What's your opinion on this, is this reasonable ,necessary and reachable?

Thanks
TommyLike.Hu


__
OpenStack Development Mailing 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] Fixing race condition with server groups and affinity policy

[Alex Cantu]

According to [1]:

"""

1) It's possible to hit a similar race condition for server groups with the 
"affinity" policy. Suppose we create a new group and then create two instances 
simultaneously. The scheduler sees an empty group for each, assigns them to 
different compute nodes, and the policy is violated. We should add a check in 
_validate_instance_group_policy() to cover the "affinity" case.


2) It's possible to create two instances simultaneously, have them be scheduled 
to conflicting hosts, both of them detect the problem in 
_validate_instance_group_policy(), both of them get sent back for rescheduling, 
and both of them get assigned to conflicting hosts *again*, resulting in an 
error. In order to fix this I propose that instead of checking against all 
other instances in the group, we only check against instances that were created 
before the current instance.

"""


I've been trying to improve upon Chris' solution here[2], but honestly i'm not 
exactly sure if I'm approaching this correctly. Chris' solution is to only 
consider the older members when validating group policy(ignoring any members 
younger than the instance we are validating), eliminating the possibility for 
the two cases mentioned above. I don't really know enough about the scheduler 
and instance group code to validate the integrity of the solution, hence my 
plea for help here :)


I've attached a git format of my attempt to make the implementation a little 
cleaner. It's the same solution Chris implemented, just moved to the 
setup_hosts() method to avoid creating a new remotable method.
I haven't gotten the tests to pass, i'm having trouble getting the expected 
filters to work.


I'm pretty new to the openstack code base, is there anyway anyone here could 
give me some direction? Is the solution correct? What am I missing? How can I 
fill in the gaps? Is this even still a valid issue?


Thanks!


[1]

https://bugs.launchpad.net/nova/+bug/1423648

[2]

https://review.openstack.org/#/c/164762/
From b6ea4e26d5feac8c57d6eb0619f29c22c1f917ca Mon Sep 17 00:00:00 2001
From: Miguel Alex Cantu 
Date: Wed, 17 Aug 2016 22:32:55 +
Subject: [PATCH] Fix race in server group policy validation

This is a follow up to Chris Friesen's patch here:
https://review.openstack.org/#/c/164762/9

There is a race condition when validating instances being
simultaneously created as part of the same server group.

It's possible to create two instances simultaneously, have them be
scheduled to hosts that would violate the group policy, have both
of them detect the problem in _validate_instance_group_policy(),
both of them get sent back for rescheduling, and both of them get
assigned to conflicting hosts *again*, resulting in an error.

The fix is to modify the validation code to ignore
group members created after the instance being validated.  This
ensures that at least one of the instances will run on the chosen
host, and the other will reschedule and adapt to the first.

The main difference between my change and Chris' change is that
instead of getting instances that are older than an instance given,
the younger instances (instances created before instance_uuid) are
retrieved, and added to the exclude list in get_hosts().

For this to work, I've added a kwarg parameter to get_hosts so
the instance_uuid that is being validated can be passed.

Closes-Bug: #1423648

Signed-off-by: Miguel Alex Cantu 
---
 nova/compute/manager.py|  8 --
 nova/objects/instance_group.py | 39 +-
 nova/tests/unit/objects/test_instance_group.py | 21 ++
 3 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/nova/compute/manager.py b/nova/compute/manager.py
index 2112c33..8b05aee 100644
--- a/nova/compute/manager.py
+++ b/nova/compute/manager.py
@@ -1288,7 +1288,9 @@ class ComputeManager(manager.Manager):
 def _do_validation(context, instance, group_hint):
 group = objects.InstanceGroup.get_by_hint(context, group_hint)
 if 'anti-affinity' in group.policies:
-group_hosts = group.get_hosts(exclude=[instance.uuid])
+group_hosts = group.get_hosts(
+exclude=[instance.uuid],
+**{'instance_uuid': instance.uuid})
 if self.host in group_hosts:
 msg = _("Anti-affinity instance group policy "
 "was violated.")
@@ -1296,7 +1298,9 @@ class ComputeManager(manager.Manager):
 instance_uuid=instance.uuid,
 reason=msg)
 elif 'affinity' in group.policies:
-group_hosts = group.get_hosts(exclude=[instance.uuid])
+group_hosts = group.get_hosts(
+exclude=[instance.uuid],
+**{'instance_uuid': instance.uuid})
 if group_hosts and 

[openstack-dev] [kolla] Kolla configuration files owner and permission

[duon...@vn.fujitsu.com]

Hello Kollish,

I am working on bp ansible-specific-task-become so I need community opinion 
about Kolla configuration files owner and permissions.

For files in "/var/lib/kolla", it's quite clear that the owner should be 'root' 
as currently.

For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
/etc/kolla is owned by root and all files in it is 660 (writable by a group).

Anybody has idea about this topic?

Best regards,

Ha Quang Duong (Mr.)
PODC - Fujitsu Vietnam Ltd.


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

[openstack-dev] [Infra] Meeting Tuesday August 23rd at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

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

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

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

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

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

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [vitrage] entity graph layout

[Yujun Zhang]

I'm considering to use Cytoscape.js [1] to improve the layout for entity
graph view.

Cytoscape.js is a graph theory (a.k.a. network) library for analysis and
visualisation which under active maintenance (latest release 2.7.8 on Aug
18, 2016) [2], while the current library d3-dagre [3] is declared not being
actively developed or maintained.

Meanwhile, I'm building a proof of concept for visualizing the entity graph
with Cytoscape.

Could anybody give a list on the required features for this view? Any
comments are welcome.

[1] http://js.cytoscape.org/
[2] https://github.com/cytoscape/cytoscape.js
[3] https://github.com/cpettitt/dagre-d3


On Mon, Aug 8, 2016 at 2:34 PM Afek, Ifat (Nokia - IL) 
wrote:

> There is no such blueprint at the moment.
> You are more than welcome to add one, in case you have some ideas for
> improvements.
>
> Ifat.
>
> From: Yujun Zhang
> Date: Monday, 8 August 2016 at 09:21
>
>
> Great, it works.
> But it would be better if we could improve the default layout. Is there
> any blueprint in progress?
> --
> Yujun
>
> On Sun, Aug 7, 2016 at 1:09 PM Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com> wrote:
>
>> Hi,
>>
>> It is possible to adjust the layout of the graph. You can double-click on
>> a vertex and it will remain pinned to its place. You can then move the
>> pinned vertices around to adjust the graph layout.
>>
>> Hope it helped, and let us know if you need additional help with your
>> demo.
>>
>> Best Regards,
>> Ifat.
>>
>>
>> From: Yujun Zhang
>> Date: Friday, 5 August 2016 at 09:32
>>
>> Hi, all,
>>
>> I'm building a demo of vitrage. The dynamic entity graph looks
>> interesting.
>>
>> But when more entities are added, things becomes crowded and the links
>> screw over each other. Dragging the items will not help much.
>>
>> Is it possible to adjust the layout so I can get a more regular/stable
>> tree view of the entities?
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Intermittent gate failures

[Armando M.]

On 22 August 2016 at 09:51, Armando M.  wrote:

> Neutrinos,
>
> Since the merge of test [1], a race has surfaced, which leads to failure
> as reported in [2]. A number of Neutron's jobs are affected, and even
> though the failure is only intermittent, it is particularly bad for the
> linux bridge job.
>
> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul will
> be grateful.
>

An update:

We have [1] in the gate queue, and Kevin is going full steam with [2],
which will mitigate the other intermittent issues we're facing in
functional and unit tests. Please bear with us.

Cheers,
Armando

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


>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/327191/
> [2] https://bugs.launchpad.net/neutron/+bug/1615710
> [3] https://review.openstack.org/#/c/358753/
>
__
OpenStack Development Mailing 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] [new][openstack] os-client-config 1.20.1 release (newton)

[no-reply]

We are grateful to announce the release of:

os-client-config 1.20.1: OpenStack Client Configuation Library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-client-config

With package available at:

https://pypi.python.org/pypi/os-client-config

Please report issues through launchpad:

http://bugs.launchpad.net/os-client-config

For more details, please see below.

Changes in os-client-config 1.20.0..1.20.1
--

17f6847 Precedence final solution


Diffstat (except docs and test files)
-

os_client_config/config.py| 220 +-
2 files changed, 200 insertions(+), 56 deletions(-)




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

Re: [openstack-dev] [nova] Hold off on pushing new patches for config option cleanup

[Michael Still]

Its a shame so many are -2'ed. There is a lot there I could have merged
yesterday if it wasn't for that.

Michael

On Mon, Aug 22, 2016 at 9:00 PM, Sean Dague  wrote:

> On 08/22/2016 12:10 AM, Michael Still wrote:
>
>> So, if this is about preserving CI time, then its cool for me to merge
>> these on a US Sunday when the gate is otherwise idle, right?
>>
>
> yes.
>
>
>> Michael
>>
>> On Fri, Aug 19, 2016 at 7:02 AM, Sean Dague > > wrote:
>>
>> On 08/18/2016 04:46 PM, Michael Still wrote:
>> > We're still ok with merging existing ones though?
>>
>> Mostly we'd like to conserve the CI time now. It's about 14.5
>> node-hours
>> to run CI on these patches (probably on about 9 node-hours in the
>> gate).
>> With ~800 nodes every patch represents 1.5% of our CI resources (per
>> hour) to pass through. There are a ton of these patches up there, so
>> even just landing gating ones consumes resources that could go towards
>> other more critical fixes / features.
>>
>> I think the theory is these are fine to merge post freeze / milestone
>> 3,
>> when the CI should have cooled down a bit and there is more head room.
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> --
>> Rackspace Australia
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Upcoming OpenStackClient 3.0 Release (Monday)

[Steve Martinelli]

Yes, known bug, try with version 3.0.1

On Aug 22, 2016 3:46 PM, "Andrey Pavlov"  wrote:

> I have an issue with new openstack client -
>
> openstack client is installed in new virtual env. it version is 3.0.0
> os-client-config!=1.19.0,>=1.13.1 (from osc-lib>=0.4.0->python-
> openstackclient)
>
> I set credentials via environment OS_PROJECT_NAME, OS_USERNAME,
> OS_PASSWORD, OS_AUTH_URL.
>
> and 'openstack --debug image list' gets me an error -
>
> _validate_auth() takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
> line 250, in run
> self.initialize_app(remainder)
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/openstackclient/shell.py", line 154, in initialize_app
> argparse=self.options,
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/os_client_config/config.py", line 1067, in get_one_cloud
> raise e
> TypeError: _validate_auth() takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/osc_lib/shell.py",
> line 135, in run
> ret_val = super(OpenStackShell, self).run(argv)
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
> line 250, in run
> self.initialize_app(remainder)
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/openstackclient/shell.py", line 154, in initialize_app
> argparse=self.options,
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/os_client_config/config.py", line 1067, in get_one_cloud
> raise e
> TypeError: _validate_auth() takes exactly 3 arguments (4 given)
>
> END return value: 1
>
>
> It worked very well with version 2.X
> Is it a known bug?
>
> Regards,
> Andrey.
>
>
>
>
> On Mon, Aug 22, 2016 at 4:08 AM, Dean Troyer  wrote:
>
>> We're excited to pre-announce the release of OSC 3.0.0. The release is
>> expected to be approved by the release team during their working hours on
>> Monday 22 Aug 2016.
>>
>> This is a **huge** release, and we shuffled things around so we've bumped
>> our major version. We tried our darndest to not break anything, and where
>> applicable we deprecated things instead. We have a small number of
>> known, documented breaking changes, which is why we did a major version
>> bump, please keep this in mind when upgrading.
>>
>> We've added a lot of support:
>>   - We now use keystoneauth for all authentication and client sessions: from
>> that we will get support for various federated identity protocols as
>> they are added (saml, openid connect), kerberos, time-base one-time
>> password, any auth plugin in keystoneauth).
>>   - Support for various languages: we fixed some basic unicode issues
>> with OSC, resulting in a much cleaner experience when using non-English
>> languages.  Additional important unicode fixes are being made in cliff
>> and will get picked up automatically by all releases of OSC when those are
>> released.
>>   - Lots of new networking commands and additional options for existing
>> ones.  Too many to list them all here: support for networks, ports,
>> subnets, ip addresses, routers, network RBAC, security group, etc.
>>   - Bulk deletion support for nearly all delete commands: when deleting
>> resources supply as many as you want and we'll try to delete them all,
>> and report on any that failed.
>>   - Under the hood we moved a chuck of the common and low-level bits of
>> OSC into a new `osc-lib` repository to expose them as a documented and
>> stable library API.  This is now all available to OSC plugins without
>> having to depend on OpenStackClient itself.  The osc-lib dependency list is
>> very short, and most of those will already be used by plugins. This also
>> led to a restructuring of the CLI parsing and shell configuration code to
>> remove some duplication and overlap with os-client-config and isolate the
>> remainder in osc-lib.  osc-lib 1.0 has already been released and is now
>> available for use by plugins.
>>
>> The known breaking changes are:
>>   - The `ip floating` commands have been renamed to `floating ip` --
>> check the help output for details.  The old commands are still present but
>> deprecated and no longer appear in help output.
>>   - Finding role assignments for a user or project using the `roles list`
>> command has been deprecated, folks should use `role assignment list` for
>> this operation.
>>
>> The usual patch will be automatically created to bump the
>> upper-constaints of OSC. Where possible, we encourage projects that depend
>> on OSC (puppet, osc-plugins, tripleo, etc) to propose a patch that uses the
>> Depends-On mechanism (depends on the upper-constaints change), to ensure
>> your gate won't break.
>>
>> Thank you to the entire OSC team, we have had a lot of new contributors
>> 

Re: [openstack-dev] [tc] persistently single-vendor projects

[Adam Lawson]

Let me toss out my perspective (FWIW) from a cloud planning perspective as
relates to single-vendor projects:

As an established OpenStack and cloud SDN architect and by extension a
working owner, I do design work for lots of the companies who read this
list. Let me just say that from where I sit, there is rarely a time where I
or any of my colleagues have been able to recommend using an open source
project developed by single vendor driving development for obvious reasons.
Companies usually consider OpenStack because of the open standard, modular
framework and vendor avoidance (not tied to one that is). If part of your
cloud strategy uses a tool developed by one vendor, your entire cloud is
tied to that tool and unfortunately, organizations end up doing this as a
result of politics, partner commitments and/or perceived safety of projects
developed by a familiar entity. Software developed by a single company is a
risk which affects adoption[1]. Who is driving an open source project is a
key consideration by cloud consumers. The biggest exception to this that
I've seen is Ceph given the staying power of RHEL (and/or the perceived
safety in using a product developed by a recognized Linux distro).

I'm glad we're discussing this and I want to re-iterate that project
diversity within the big tent is more important than how each project
integrates into OpenStack's development process. There's a perception that
comes with the association with membership. Projects in the big tent and
the evangelized reasons for they're there are being closely watched by more
than just our community. And cloud planners such as myself and many others
are watching for our own reasons as well.

Just adding that there's a perception that drives adoption by how we
structure and evangelize the Big Tent idea.

Anyway, ; )

[1]
http://www.zdnet.com/article/google-intel-and-mirantis-rewrite-openstacks-life-cycle-management-tool/

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Aug 5, 2016 at 6:26 AM, Zane Bitter  wrote:

> On 04/08/16 23:00, joehuang wrote:
>
>> I think all the problem is caused by the definition "official OpenStack
>> project" for one big-tent project.
>>
>> I understand that each OpenStack vendor wants some differentiation in
>> their solution, while also would
>> like to collaborate with common core projects.
>>
>
> Nobody wants this. We want to build a fully-featured cloud that can run
> the same kinds of apps that users might develop for AWS/Azure/GCE, and we
> want those apps to be portable substantially everywhere. It's all right
> there in the Mission Statement.
>
> If we replace the title "official OpenStack project" to "OpenStack
>> ecosystem player", and make "big-tent"
>> as "ecosystem play yard" ( no close roof ), TCs can put more focus on
>> governance of core projects
>> (current non-big-tent projects), and provide a more open place to grow
>> abundant ecosystem.
>>
>
> You're describing the exact situation we had before the 'big-tent' reform.
>
>
> __
> OpenStack Development Mailing 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] [new][oslo] oslo.messaging 5.9.0 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.messaging 5.9.0: Oslo Messaging API

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.messaging 5.8.0..5.9.0
--

15a64c6 Updated from global requirements
6a41a81 Fix calculating of duration in simulator.py
f61f0c1 [zmq] Redis unavailability is not critical
00cbfc7 [zmq] Discover new publisher proxy
b7717e1 [AMQP 1.0] small fixes to improve timer scalability
34122ee Add warning when credential is not specified for each host
e217cbd Fix the help info format
3109941 Log a warning when connected to a routable message bus
480cd78 [AMQP 1.0] Add link credit configuration options
827a517 [AMQP 1.0] AMQP 1.0 Driver User Guide Document update
1203ec3 AMQP 1.0 Driver Architecture Overview Document
5236e99 Remove the max_send_retries option
b7a6a07 [AMQP 1.0] Cancel response treatment for detached link
3f38e6b Set the default link property to allow message acks
7fe799d Fix a timer leak in the AMQP 1.0 driver
ded8941 [AMQP 1.0] Add configuration parameters for send message deadline
4c0674d Re-factor the AMQP 1.0 addressing semantics
35ea442 [AMQP 1.0] Add acknowledge and requeue handling for incoming message
b1b4cfc Refactor AMQP 1.0 command task to support timers
890ce0e Refactor link management to support link recovery
23f9212 Add the proper branch back to .gitreview


Diffstat (except docs and test files)
-

oslo_messaging/_drivers/amqp1_driver/addressing.py |  287 +
oslo_messaging/_drivers/amqp1_driver/controller.py | 1001 -
.../_drivers/amqp1_driver/drivertasks.py   |  111 --
oslo_messaging/_drivers/amqp1_driver/eventloop.py  |  142 ++-
oslo_messaging/_drivers/amqp1_driver/opts.py   |  163 ++-
.../oslo_messaging_amqp_driver_overview.rst| 1144 
oslo_messaging/_drivers/impl_amqp1.py  |  200 +++-
oslo_messaging/_drivers/impl_rabbit.py |2 +-
.../dealer/zmq_dealer_publisher_proxy.py   |   33 +-
.../zmq_driver/client/zmq_routing_table.py |   60 +-
.../zmq_driver/client/zmq_sockets_manager.py   |2 +-
.../_drivers/zmq_driver/matchmaker/base.py |  173 ---
.../zmq_driver/matchmaker/matchmaker_redis.py  |  204 
.../zmq_driver/matchmaker/zmq_matchmaker_base.py   |  199 
.../zmq_driver/matchmaker/zmq_matchmaker_redis.py  |  267 +
.../server/consumers/zmq_consumer_base.py  |   26 +-
.../server/consumers/zmq_sub_consumer.py   |   21 +-
oslo_messaging/_drivers/zmq_driver/zmq_updater.py  |4 +-
oslo_messaging/conffixture.py  |2 +-
oslo_messaging/opts.py |4 +-
oslo_messaging/transport.py|   22 +-
requirements.txt   |1 +
setup-test-env-zmq-proxy.sh|2 +
setup.cfg  |4 +-
test-requirements.txt  |2 +-
tools/simulator.py |   13 +-
31 files changed, 4330 insertions(+), 1086 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 95e0b29..7397aaf 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -16,0 +17 @@ debtcollector>=1.2.0 # Apache-2.0
+monotonic>=0.6 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index bc197fa..1e3f508 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -41 +41 @@ pyngus>=2.0.0 # Apache-2.0
-bandit>=1.0.1 # Apache-2.0
+bandit>=1.1.0 # Apache-2.0



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

Re: [openstack-dev] [puppet] magnum module - fixes/improvements for Mitaka release

[Michal Adamczyk]

Hi All,



On Fri, May 13, 2016 at 12:28 PM, Michal Adamczyk 
wrote:

> On Fri, May 13, 2016 at 9:42 AM, Michal Adamczyk 
> wrote:
>
>>
>>
>> On Thu, May 12, 2016 at 2:14 PM, Michal Adamczyk 
>> wrote:
>>
>>>
>>> On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu 
>>> wrote:
>>>


 > -Original Message-
 > From: Emilien Macchi [mailto:emil...@redhat.com]
 > Sent: May-11-16 9:44 AM
 > To: OpenStack Development Mailing List (not for usage questions)
 > Subject: Re: [openstack-dev] [puppet] magnum module -
 > fixes/improvements for Mitaka release
 >
 > On Wed, May 11, 2016 at 9:22 AM, Michal Adamczyk 
 > wrote:
 > > Hi,
 > >
 > > I am working on some fixes/improvements to puppet magnum module:
 > > https://review.openstack.org/#/c/313293/
 >
 > reviewed & commented. Almost good, excellent work here!
 >

>>>
>>> Thanks, another patch-set has been committed today.
>>>
>>>
 > > I have found some issues while creating a bays with magnum
 > > (https://bugs.launchpad.net/magnum/+bug/1575524) and I still need
 to
 > > address few things:
 > >
 > >  - getting ID of the domain and user used to create trust (see my
 > > patch set
 > > 10 commit info). I have added domain class like in heat
 > >
 > https://review.openstack.org/#/c/313293/10/manifests/
 keystone/domain.p
 > > p but the requirements is to get domain and user id, not a name.
 > >With names module fails to create trust...
 > >
 > >   Do you know if there is simple way to get user/domain ID via
 > > existing keystone module?
 >
 > We already had this issue in the paste, with neutron.conf that needed
 > the tenant id from nova service, to manage notifications.
 > It was a bug and it was fixed very early.
 > Using ID in production deployments is:
 > * hard to deploy, you need some magic that deploy the resource and get
 > the id to write it somewhere
 > * not flexible: everytime the resource change, the ID change and you
 > need to update conf
 >
 > So please fix Magnum to allow to use names (or maybe it's in Keystone,
 > I haven't looked).
 > Otherwise, you'll need to write a provider that will get the ID for
 you,
 > look this example:
 > https://github.com/openstack/puppet-
 > tempest/blob/master/lib/puppet/provider/tempest_
 glance_id_setter/openst
 > ack.rb

 No problem from me. Please file a bug for that.
>>>
>>>
>>> Should I rise a bug for that or it's already done?
>>>
>>
>> Bug created: https://bugs.launchpad.net/puppet-magnum/+bug/1581372
>>
>>
> Hi,

As the above bug has been fixed how we can merge it to Mitaka and
RDO/Ubuntu? Or we don't do it for Mitaka and leave it as it is now...

>
 >
 > >  - as magnum requires lbaas and in Mitaka v2 is supported according
 > to
 > > the docs
 > > http://docs.openstack.org/mitaka/networking-guide/adv-config-
 > lbaas.htm
 > > l we should add to neutron module or integration class directly the
 > > following
 > > changes:
 > >
 > >  class { '::neutron::agents::lbaas':
 > > interface_driver => $driver,
 > > debug=> true,
 > > enable_v1=> false,
 > > enable_v2=> true,
 > >   }
 > >
 > >   neutron_config { 'service_providers/service_provider':
 > > value =>
 > >
 > 'LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.
 plugin_driver.Hap
 > roxyOnHostPluginDriver:default';
 > >   }
 > >
 >
 > Good to know, we recently did some work to stabilize puppet-neutron so
 > we can deploy LBaaS v2, mjblack worked on it, maybe we can have a
 > status about it here.

 FYI, Magnum is using LBaaS v1. There is a blueprint [1] to migrate to
 v2, but the blueprint is not finished yet.

 [1] https://blueprints.launchpad.net/magnum/+spec/magnum-
 lbaasv2-support
>>>
>>>
>>> This indicates that we have to wait till this is finished for magnum and
>>> my error:
>>> ERROR: HEAT-E99001 Service neutron is not available for resource type
>>> OS::Neutron::HealthMonitor, reason: Service endpoint not in service
>>> catalog.\n']
>>> might be related to the fact I have lbaasv2 enabled, correct? Magnum
>>> won't work with Mitaka release as we don't have lbaasv1 there :/
>>>
>>> So we wait for mjblack status about lbaasv2 switch for puppet-neutron.
>>>
>>> Any update from mjblack or does this topic of lbaasv2 died? I have
created a bug for it  https://bugs.launchpad.net/bugs/1583024 but appears
that it was closed without any explanation.


 >
 > > - add a parameter to api.pp or creates a new class with this
 > parameter
 > > to manage certificate manager entry inside [certificates] section of
 > > 

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

[Duncan Thomas]

What is the logic for that? It's a massive duplication of effort, and it
leads to defacto forks and inconsistencies between clouds - exactly what
the OpenStack mission is against.

Many/most of the clouds actually in production are already out of upstream
stable policy. The more convergence we can get on what happens after that
the better. There are zero advantages I can see to each vendor going it
alone.

On 22 Aug 2016 19:31,  wrote:

> Sorry if touch 3rd rail.
>
> But should backport bug fixes to older releases be done in distros and not
> upstream?
>
> -Original Message-
> From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
> Sent: Tuesday, August 09, 2016 12:34 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable
> policy for drivers
>
> On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
> > Duncan Thomas wrote:
> >
> >> On 8 August 2016 at 21:12, Matthew Treinish
> >> wrote:
> >> Ignoring all that, this is also contrary to how we perform testing in
> >> OpenStack.
> >> We don't turn off entire classes of testing we have so we can land
> >> patches, that's just a recipe for disaster.
> >>
> >> But is it more of a disaster (for the consumers) than zero testing,
> >> zero review, scattered around the internet
> >> if-you're-lucky-with-a-good-wind you'll maybe get the right patch
> >> set? Because that's where we are right now, and vendors, distributors
> >> and the cinder core team are all saying it's a disaster.
> >
> > If consumers rely on upstream releases, then they are expected to
> > migrate to newer releases after EOL, not switch to a random branch on
> > the internet. If they rely on some commercial product, then they
> > usually have an extended period of support and certification for their
> > drivers, so it’s not a problem for them.
> >
> > Ihar
> This is entirely unrealistic. Force customers to upgrade. Good luck
> explaining to a bank that in order to get their cinder driver fix in, they
> have to upgrade their entire OpenStack deployment. Real world customers
> simply will balk at this all day long.
>
> Walt
> >
> > __
> > 
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Upcoming OpenStackClient 3.0 Release (Monday)

[Andrey Pavlov]

I have an issue with new openstack client -

openstack client is installed in new virtual env. it version is 3.0.0
os-client-config!=1.19.0,>=1.13.1 (from
osc-lib>=0.4.0->python-openstackclient)

I set credentials via environment OS_PROJECT_NAME, OS_USERNAME,
OS_PASSWORD, OS_AUTH_URL.

and 'openstack --debug image list' gets me an error -

_validate_auth() takes exactly 3 arguments (4 given)
Traceback (most recent call last):
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
line 250, in run
self.initialize_app(remainder)
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/openstackclient/shell.py",
line 154, in initialize_app
argparse=self.options,
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/os_client_config/config.py",
line 1067, in get_one_cloud
raise e
TypeError: _validate_auth() takes exactly 3 arguments (4 given)
Traceback (most recent call last):
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/osc_lib/shell.py",
line 135, in run
ret_val = super(OpenStackShell, self).run(argv)
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
line 250, in run
self.initialize_app(remainder)
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/openstackclient/shell.py",
line 154, in initialize_app
argparse=self.options,
  File
"/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/os_client_config/config.py",
line 1067, in get_one_cloud
raise e
TypeError: _validate_auth() takes exactly 3 arguments (4 given)

END return value: 1


It worked very well with version 2.X
Is it a known bug?

Regards,
Andrey.




On Mon, Aug 22, 2016 at 4:08 AM, Dean Troyer  wrote:

> We're excited to pre-announce the release of OSC 3.0.0. The release is
> expected to be approved by the release team during their working hours on
> Monday 22 Aug 2016.
>
> This is a **huge** release, and we shuffled things around so we've bumped
> our major version. We tried our darndest to not break anything, and where
> applicable we deprecated things instead. We have a small number of known,
> documented breaking changes, which is why we did a major version bump,
> please keep this in mind when upgrading.
>
> We've added a lot of support:
>   - We now use keystoneauth for all authentication and client sessions: from
> that we will get support for various federated identity protocols as they
> are added (saml, openid connect), kerberos, time-base one-time password,
> any auth plugin in keystoneauth).
>   - Support for various languages: we fixed some basic unicode issues
> with OSC, resulting in a much cleaner experience when using non-English
> languages.  Additional important unicode fixes are being made in cliff
> and will get picked up automatically by all releases of OSC when those are
> released.
>   - Lots of new networking commands and additional options for existing
> ones.  Too many to list them all here: support for networks, ports,
> subnets, ip addresses, routers, network RBAC, security group, etc.
>   - Bulk deletion support for nearly all delete commands: when deleting
> resources supply as many as you want and we'll try to delete them all,
> and report on any that failed.
>   - Under the hood we moved a chuck of the common and low-level bits of
> OSC into a new `osc-lib` repository to expose them as a documented and
> stable library API.  This is now all available to OSC plugins without
> having to depend on OpenStackClient itself.  The osc-lib dependency list is
> very short, and most of those will already be used by plugins. This also
> led to a restructuring of the CLI parsing and shell configuration code to
> remove some duplication and overlap with os-client-config and isolate the
> remainder in osc-lib.  osc-lib 1.0 has already been released and is now
> available for use by plugins.
>
> The known breaking changes are:
>   - The `ip floating` commands have been renamed to `floating ip` -- check
> the help output for details.  The old commands are still present but
> deprecated and no longer appear in help output.
>   - Finding role assignments for a user or project using the `roles list`
> command has been deprecated, folks should use `role assignment list` for
> this operation.
>
> The usual patch will be automatically created to bump the upper-constaints
> of OSC. Where possible, we encourage projects that depend on OSC (puppet,
> osc-plugins, tripleo, etc) to propose a patch that uses the Depends-On
> mechanism (depends on the upper-constaints change), to ensure your gate
> won't break.
>
> Thank you to the entire OSC team, we have had a lot of new contributors
> this year, many of them working hard on the Networking commands.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Kurt Taylor]

In my opinion, we have to be careful about the "supported" label. Saying
that third-party tested drivers are community supported implies a
commitment that may have not been intended.

Personally, I see no problem with leaving everything just as planned.
Drivers that are in tree are either tested upstream in infra, or they are
tested against the third-party requirements that we defined. We have
communicated the plan to move drivers out of tree for more than a release.
And, I am absolutely against shipping a driver that has not been tested,
regardless of if it was previously in tree or not, regardless of the
deprecation policy.

Nova takes an even harder position on this by simply stating that if a
driver is not tested in upstream infra, it is unsupported, regardless of
where the driver lives or how good (or not) the third-party system testing
it has done their job.

kurt (krtaylor)

On Mon, Aug 22, 2016 at 1:48 PM, Loo, Ruby  wrote:

> Hi,
>
>
>
> I admit, I didn't read the entire thread [0], but did read the summary
> [1]. I like this, except that I'm not sure about #3. What's the rationale
> of adding a new config option 'enable_unsupported_drivers' that defaults to
> False. Versus not having it, and "just" logging a warning if they are
> loading an unsupported (in-tree) driver?
>
>
>
> If I understand this...
>
>
>
> If we have 'enable_unsupported_drivers': since it defaults to False, the
> conductor will fail on startup, if an unsupported driver is in the
> enabled_drivers config. (The conductor will emit a warning in the logs, or
> maybe it won't?) The operator (if they haven't changed it), will now change
> it to True if they want to use any unsupported drivers. The conductor will
> start up and emit a warning in the logs.
>
>
>
> If we don't have an enable_unsupported_drivers config, will the conductor
> start up and emit a warning in the logs?
>
>
>
> I was also wondering, where is the value for the 'supported' flag for each
> driver going to be kept? Hard-coded in the driver code?
>
>
>
> --ruby
>
>
>
>
>
> On 2016-08-19, 10:15 AM, "Jim Rollenhagen"  wrote:
>
>
>
> Hi Ironickers,
>
>
>
> There was a big thread here[0] about Cinder, driver removal, and standard
>
> deprecation policy. If you haven't read through it yet, please do before
>
> continuing here. :)
>
>
>
> The outcome of that thread is summarized well here.[1]
>
>
>
> I know that I previously had a different opinion on this, but I think we
>
> should go roughly the same route, for the sake of the users.
>
>
>
> 1) A ``supported`` flag for each driver that is True if and only if the
> driver
>
>is tested in infra or third-party CI (and meets our third party CI
>
>requirements).
>
> 2) If the supported flag is False for a driver, deprecation is implied (and
>
>a warning is emitted at load time). A driver may be removed per standard
>
>deprecation policies, with turning the supported flag False to start the
>
>clock.
>
> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>
>drivers marked supported=False. If a driver is in enabled_drivers, has
>
>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>
>will fail to start. Setting enable_unsupported_drivers=True will allow
>
>ironic-conductor to start with warnings emitted.
>
>
>
> It is important to note that (3) does still technically break the standard
>
> deprecation policy (old config may not work with new version of ironic).
>
> However, this is a much softer landing than the original plan. FWIW, I do
>
> expect (but not hope!) this part will be somewhat contentious.
>
>
>
> I'd like to hear thoughts and get consensus on this from the rest of the
>
> ironic community, so please do reply whether you agree or disagree.
>
>
>
> I'm happy to do the work required (update spec, code patches, doc updates)
>
> when we do come to agreement.
>
>
>
> // jim
>
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101428.html
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101898.html
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

[Znoinski, Waldemar]

I’ll have a look.

From: Timofei Durakov [mailto:tdura...@mirantis.com]
Sent: Monday, August 22, 2016 8:03 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

Hi everyone,

got a question on that Intel NFV CI: has statistics for stable branches been 
checked either?
I have a patch to stable/liberty [1] that failed on all Intel NFV CI jobs 2 
times in a row. Who could help me to figure out the root cause for that?

Thanks in advance,
Timofey.

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

On Mon, Aug 8, 2016 at 6:27 PM, Ptacek, MichalX 
> wrote:
Change deployed,
Thanks for your comments,

Michal

-Original Message-
From: Markus Zoeller 
[mailto:mzoel...@linux.vnet.ibm.com]
Sent: Monday, August 08, 2016 3:15 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

On 03.08.2016 22:02, Znoinski, Waldemar wrote:
> Thanks
> Much appreciated
>
> Making use of the opportunity here... what's the next big thing a CI
> (like one testing NFV) should be doing? (multinode or there's
> something else more important?)

Two tiny nits on the comment the CI is giving a change:

"Build failed (check pipeline). To recheck leave a comment with
intel-nfv-ci recheck. For more info go to
https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI.;

1) Could you put the recheck command in quotation? Like:
   To recheck leave a comment with 'intel-nfv-ci recheck'.
2) The link to the wiki seems to be wrong (hyphen vs. underscore):
   https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI

--
Regards, Markus Zoeller (markus_z)

>  >-Original Message-
>  >From: Matt Riedemann 
> [mailto:mrie...@linux.vnet.ibm.com]
>  >Sent: Wednesday, August 3, 2016 8:28 PM
>  >To: 
> openstack-dev@lists.openstack.org
>  >Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting
> permission  >  >On 8/3/2016 8:18 AM, Znoinski, Waldemar wrote:
>  >> [WZ] Hi Matt, do we need, a Gerrit-style, +2 on that from someone?
>  >> Infra Team doesn't keep these settings in their puppet/config
> files on git -  >all the Gerrit changes are done via Gerrit GUI so
> they rely on Cores to add CIs  >to the appropriate ci group, nova-ci in this 
> case.
>  >>
>  >>
>  >
>  >Sorry, I wasn't sure what the next step here was, I guess it was the
> nova-ci  >membership change, which is done now:
>  >
>  >https://review.openstack.org/#/admin/groups/511,members
>  >
>  >--
>  >
>  >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
> --
> 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
>




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
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-dev] [ironic] ideas for Ocata summit sessions

[Loo, Ruby]

Hi,

Start getting those ironic juices flowing! We've got an etherpad [1] ready to 
capture your ideas for the Ocata summit sessions. As discussed in today's 
meeting [2], in next Monday's ironic meeting [3] we will decide on the number 
of fishbowl and workroom sessions, and the ideas submitted by then will help 
inform our decision.

Thanks,
--ruby

[1] https://etherpad.openstack.org/p/ironic-ocata-summit
[2] 
http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-08-22-17.00.log.html#17:20:20
[3] 
https://wiki.openstack.org/wiki/Meetings/Ironic#Weekly_Ironic_Project_Team_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

[openstack-dev] [ironic] weekly subteam status report

[Loo, Ruby]

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 15 Aug 2016 and 22 Aug 2016)
- Ironic: 223 bugs (-9) + 211 wishlist items (+12). 26 new (-10), 164 in 
progress (+4), 1 critical (+1), 34 high (+1) and 16 incomplete (-3)
- Inspector: 9 bugs + 20 wishlist items. 0 new, 9 in progress, 0 critical, 1 
high (-1) and 2 incomplete
- Nova bugs with Ironic tag: 11. 0 new, 0 critical, 0 high
- a critical bug:
  - IPA for stable/liberty unit tests fail with AssertionError: InspectionError 
not raised by extension_manager
  - https://bugs.launchpad.net/ironic-python-agent/+bug/1611528
  - Patch proposed to use constraints: https://review.openstack.org/#/c/353124/
  - mat128 has volunteered to fix the Dockerfile issue. Proposing patch to 
master and then getting it backported to stable releases.

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- portgroups patches still in review
- patch for security groups for provisioning network coming this week

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
- No updates from dtantsur

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Boot from Volume specification has received minor updates in the last week, 
reviews required: https://review.openstack.org/#/c/294995/
- Substrate volume connection information changes still in review.

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- a spec update is proposed (thanks TheJulia): 
https://review.openstack.org/357262

OpenStackClient plugin for ironic (dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- 'openstack baremetal create' merged
- a few commands are still on review
- chassis https://review.openstack.org/345815
- a few commands need fixing and/or rebasing:
- port list https://review.openstack.org/346722
- port delete https://review.openstack.org/346075
- driver https://review.openstack.org/350050
- outstanding patches: 
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bug/1526479
- there are some more node-related commands that have not been coded yet (rloo 
did a diff last week)
- e.g. validate

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- August 22, 2016
- Base patch updated
- https://review.openstack.org/#/c/298461
- Previously had 2 +2s, but 1 was removed. Needs re-review after update 
this morning.

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- "mask secrets in API responses" generated some debate, still not merged
- https://review.openstack.org/#/c/326768/

Active node creation (TheJulia)
===
* trello: https://trello.com/c/BwA91osf/22-active-node-creation
- Proposed tempest changes have received feedback.  New revision should be 
expected Monday.

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- documentation: needs review (got +2)  https://review.openstack.org/#/c/293872/
- nova patch: needs review https://review.openstack.org/#/c/328157/

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- 2 patches for review in ironic-lib (https://review.openstack.org/#/c/348953/ 
https://review.openstack.org/#/c/358000/). But currently stuck in a problem 
where oslo_utils.specs_matcher.match() does not handle spaces, which is needed 
for backward compat in Ironic

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- The grenade job is voting on ironic-inspector now \o/
- Now we only need upgrade documentation to claim assert:supports-upgrade 
tag
- volunteers needed for ^^^
- Still working on migrating our bash-based gate to tempest
- tempest job for the client: https://review.openstack.org/358663

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

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

Re: [openstack-dev] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Matt,

originally this started as an experiment - try to collect information about
OpenStack scalability and performance and publish it to the community - and
we started this experiment under Rally (OpenStack Benchmarking) umbrella,
that's having its documentation space under docs.openstack.org/developer/*
section. If this experiment will be met OK by OpenStack community (and more
specifically, by OpenStack documentation team), I believe eventually it can
be moved under more appropriate documentation space.

Cheers,
Dina

On Mon, Aug 22, 2016 at 4:59 AM, Matt Kassawara 
wrote:

> Why isn't this content in the openstack-manuals repository?
>
> On Sun, Aug 21, 2016 at 4:38 PM, Kaustubh Kelkar  > wrote:
>
>> I might have missed it entirely, but I wasn't able to find virtual
>> resources used by the instances. IMO, it'd be great if one could see
>> instance flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
>> ratios from host's perspective.
>>
>>
>> Thanks,
>> Kaustubh
>> --
>> *From:* Dina Belova 
>> *Sent:* Friday, August 19, 2016 12:37 PM
>> *To:* OpenStack Development Mailing List; openstack-operators
>> *Subject:* [Openstack-operators] [Performance][Documentation] Please
>> take a look on OpenStack perofmance-docs
>>
>> Folks,
>>
>> During previous weeks we merged lots of OpenStack performance-related
>> test plans and test results to the performance-docs
>>  and your
>> feedback (as usually) is very appreciated. I hope you can find something
>> interesting for you here and share your opinion on what's going on
>> regarding our performance researches.
>>
>>
>> Thanks in advance!
>>
>> Cheers,
>> Dina
>>
>> --
>> *Dina Belova*
>> *Senior Software Engineer*
>> Mirantis, Inc.
>> 525 Almanor Avenue, 4th Floor
>> Sunnyvale, CA 94085
>>
>> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
>> *
>> www.mirantis.com
>> 
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>


-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.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

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

[Iury Gregory]

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

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
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] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Kaustubh,

thanks for the comment. Usually if testing scenario require VM booting, its
flavor is set in the Rally scenario configuration (e.g. here

or
here
),
but I will check where this information is missed right now. AFAIK default
OpenStack flavors were used for testing purposes (tiny, small, medium) with
no customizations. As for overcommit ratios, this information needs to be
added, thank you for noticing.

Cheers,
Dina

On Sun, Aug 21, 2016 at 3:38 PM, Kaustubh Kelkar 
wrote:

> I might have missed it entirely, but I wasn't able to find virtual
> resources used by the instances. IMO, it'd be great if one could see
> instance flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
> ratios from host's perspective.
>
>
> Thanks,
> Kaustubh
> --
> *From:* Dina Belova 
> *Sent:* Friday, August 19, 2016 12:37 PM
> *To:* OpenStack Development Mailing List; openstack-operators
> *Subject:* [Openstack-operators] [Performance][Documentation] Please take
> a look on OpenStack perofmance-docs
>
> Folks,
>
> During previous weeks we merged lots of OpenStack performance-related test
> plans and test results to the performance-docs
>  and your feedback
> (as usually) is very appreciated. I hope you can find something interesting
> for you here and share your opinion on what's going on regarding our
> performance researches.
>
>
> Thanks in advance!
>
> Cheers,
> Dina
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
> *
> www.mirantis.com
> 
>



-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.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] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Ok, let's keep current (16:00 UTC) time slot for tomorrow meeting, until
we'll find a better option.

Cheers,
Dina

On Mon, Aug 22, 2016 at 9:05 AM, Augie Mena III  wrote:

> Hi Dina/Adrien,
>
> Not a great slot here in Austin (that would be noon).  Would prefer a
> 30-minute slot at 15:30 UTC or 18:00 UTC, but I realize it's hard to find
> one to accommodate everyone.
>
> Thanks.
>
> Regards,
> Augie
>
>
>
>
>
> From:Dina Belova 
> To:lebre.adr...@free.fr, Joshua Harlow ,
> Augie Mena III/Austin/IBM@IBMUS
> Cc:OpenStack Development Mailing List  openstack.org>, openstack-operators  openstack.org>
> Date:08/22/2016 10:51 AM
> Subject:Re: [Performance][Meeting time] Possible meeting time
> change: feedback appreciated
> --
>
>
>
> Adrien,
>
> this looks good to me. Let's see what Joshua and Augie will think about it.
>
> Cheers,
> Dina
>
> On Mon, Aug 22, 2016 at 7:44 AM, <*lebre.adr...@free.fr*
> > wrote:
> Hi Dina,
>
> 17:30 UTC means 19:30 in France (Summer time).
> Considering that the meeting lasts in average 30/45 min, it would be great
> if we could find a trade off a bit sooner. What's about 17:00 UTC ?
>
> Thanks,
> Adrien
>
> - Mail original -
> > De: "Dina Belova" <*dbel...@mirantis.com* >
> > À: "OpenStack Development Mailing List" <
> *openstack-dev@lists.openstack.org* >,
> "openstack-operators"
> > <*openstack-operat...@lists.openstack.org*
> >
> > Envoyé: Jeudi 18 Août 2016 21:35:48
> > Objet: [Performance][Meeting time] Possible meeting time change:
> feedback appreciated
> >
> >
> > Hey, OpenStackers!
> >
> >
> > recently I've got lots comments about current time our Performance
> > Team meetings are held on. Right now we're having them 16:00 UTC on
> > Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
> > time slot is not that much comfortable for some of the US folks due
> > to internal daily meetings.
> >
> >
> > The question is: can we move our weekly meeting to 17:30 UTC (10:30
> > PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
> > collect more feedback.
> >
> >
> > Please leave your comments.
> >
> >
> > Cheers,
> > Dina
> >
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dina Belova Senior Software Engineer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Mirantis, Inc.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 525 Almanor Avenue, 4th Floor
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sunnyvale, CA 94085 Phone: 650-772-8418
> > Email: *dbel...@mirantis.com* 
> > *www.mirantis.com* 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418>Email: **dbel...@mirantis.com*
> 
> *www.mirantis.com* 
> 
>
>
>


-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.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] [nova] [infra] Intel NFV CI voting permission

[Timofei Durakov]

Hi everyone,

got a question on that Intel NFV CI: has statistics for stable branches
been checked either?
I have a patch to stable/liberty [1] that failed on all Intel NFV CI jobs 2
times in a row. Who could help me to figure out the root cause for that?

Thanks in advance,
Timofey.

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

On Mon, Aug 8, 2016 at 6:27 PM, Ptacek, MichalX 
wrote:

> Change deployed,
> Thanks for your comments,
>
> Michal
>
> -Original Message-
> From: Markus Zoeller [mailto:mzoel...@linux.vnet.ibm.com]
> Sent: Monday, August 08, 2016 3:15 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission
>
> On 03.08.2016 22:02, Znoinski, Waldemar wrote:
> > Thanks
> > Much appreciated
> >
> > Making use of the opportunity here... what's the next big thing a CI
> > (like one testing NFV) should be doing? (multinode or there's
> > something else more important?)
>
> Two tiny nits on the comment the CI is giving a change:
>
> "Build failed (check pipeline). To recheck leave a comment with
> intel-nfv-ci recheck. For more info go to
> https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI.;
>
> 1) Could you put the recheck command in quotation? Like:
>To recheck leave a comment with 'intel-nfv-ci recheck'.
> 2) The link to the wiki seems to be wrong (hyphen vs. underscore):
>https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
>
> --
> Regards, Markus Zoeller (markus_z)
>
> >  >-Original Message-
> >  >From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >  >Sent: Wednesday, August 3, 2016 8:28 PM
> >  >To: openstack-dev@lists.openstack.org
> >  >Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting
> > permission  >  >On 8/3/2016 8:18 AM, Znoinski, Waldemar wrote:
> >  >> [WZ] Hi Matt, do we need, a Gerrit-style, +2 on that from someone?
> >  >> Infra Team doesn't keep these settings in their puppet/config
> > files on git -  >all the Gerrit changes are done via Gerrit GUI so
> > they rely on Cores to add CIs  >to the appropriate ci group, nova-ci in
> this case.
> >  >>
> >  >>
> >  >
> >  >Sorry, I wasn't sure what the next step here was, I guess it was the
> > nova-ci  >membership change, which is done now:
> >  >
> >  >https://review.openstack.org/#/admin/groups/511,members
> >  >
> >  >--
> >  >
> >  >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
> > --
> > 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
> >
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Devananda van der Veen]

I like this approach more than the current "you're in or you're out".

+1

--deva

On Mon, Aug 22, 2016 at 7:02 AM Vladyslav Drok  wrote:

> +1 from me then :)
>
> On Mon, Aug 22, 2016 at 4:52 PM, Jim Rollenhagen 
> wrote:
>
>> On Mon, Aug 22, 2016 at 8:01 AM, Vladyslav Drok 
>> wrote:
>> > On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen <
>> j...@jimrollenhagen.com>
>> > wrote:
>> >>
>> >> Hi Ironickers,
>> >>
>> >> There was a big thread here[0] about Cinder, driver removal, and
>> standard
>> >> deprecation policy. If you haven't read through it yet, please do
>> before
>> >> continuing here. :)
>> >>
>> >> The outcome of that thread is summarized well here.[1]
>> >>
>> >> I know that I previously had a different opinion on this, but I think
>> we
>> >> should go roughly the same route, for the sake of the users.
>> >>
>> >> 1) A ``supported`` flag for each driver that is True if and only if the
>> >> driver
>> >>is tested in infra or third-party CI (and meets our third party CI
>> >>requirements).
>> >> 2) If the supported flag is False for a driver, deprecation is implied
>> >> (and
>> >>a warning is emitted at load time). A driver may be removed per
>> >> standard
>> >>deprecation policies, with turning the supported flag False to start
>> >> the
>> >>clock.
>> >> 3) Add a ``enable_unsupported_drivers`` config option that allows
>> enabling
>> >>drivers marked supported=False. If a driver is in enabled_drivers,
>> has
>> >>supported=False, and enable_unsupported_drivers=False,
>> ironic-conductor
>> >>will fail to start. Setting enable_unsupported_drivers=True will
>> allow
>> >>ironic-conductor to start with warnings emitted.
>> >
>> >
>> > Just for clarity, its default value is False?
>>
>> Sorry, I meant to add that. Yes, default for
>> enable_unsupported_drivers is False.
>>
>> // jim
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Driver removal policies - should we make it softer?

[Loo, Ruby]

Hi,

I admit, I didn't read the entire thread [0], but did read the summary [1]. I 
like this, except that I'm not sure about #3. What's the rationale of adding a 
new config option 'enable_unsupported_drivers' that defaults to False. Versus 
not having it, and "just" logging a warning if they are loading an unsupported 
(in-tree) driver?

If I understand this...

If we have 'enable_unsupported_drivers': since it defaults to False, the 
conductor will fail on startup, if an unsupported driver is in the 
enabled_drivers config. (The conductor will emit a warning in the logs, or 
maybe it won't?) The operator (if they haven't changed it), will now change it 
to True if they want to use any unsupported drivers. The conductor will start 
up and emit a warning in the logs.

If we don't have an enable_unsupported_drivers config, will the conductor start 
up and emit a warning in the logs?

I was also wondering, where is the value for the 'supported' flag for each 
driver going to be kept? Hard-coded in the driver code?

--ruby


On 2016-08-19, 10:15 AM, "Jim Rollenhagen" 
> wrote:

Hi Ironickers,

There was a big thread here[0] about Cinder, driver removal, and standard
deprecation policy. If you haven't read through it yet, please do before
continuing here. :)

The outcome of that thread is summarized well here.[1]

I know that I previously had a different opinion on this, but I think we
should go roughly the same route, for the sake of the users.

1) A ``supported`` flag for each driver that is True if and only if the driver
   is tested in infra or third-party CI (and meets our third party CI
   requirements).
2) If the supported flag is False for a driver, deprecation is implied (and
   a warning is emitted at load time). A driver may be removed per standard
   deprecation policies, with turning the supported flag False to start the
   clock.
3) Add a ``enable_unsupported_drivers`` config option that allows enabling
   drivers marked supported=False. If a driver is in enabled_drivers, has
   supported=False, and enable_unsupported_drivers=False, ironic-conductor
   will fail to start. Setting enable_unsupported_drivers=True will allow
   ironic-conductor to start with warnings emitted.

It is important to note that (3) does still technically break the standard
deprecation policy (old config may not work with new version of ironic).
However, this is a much softer landing than the original plan. FWIW, I do
expect (but not hope!) this part will be somewhat contentious.

I'd like to hear thoughts and get consensus on this from the rest of the
ironic community, so please do reply whether you agree or disagree.

I'm happy to do the work required (update spec, code patches, doc updates)
when we do come to agreement.

// jim

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101428.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101898.html

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



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

Re: [openstack-dev] [Group-based-policy] Question on GBP installation

[Sumit Naiksatam]

Hi Yuki,

Thanks for your email. We are currently in the process of updating the
packages, and will update this webpage once that happens.

Thanks,
~Sumit.


On Mon, Aug 22, 2016 at 2:17 AM, Yuki Miyahara  wrote:
> Hi GBP Team,
>
> Now I'm trying to install OpenStack (Liberty) with GBP on RHEL7.2[1],
> but I can't find following packages from
> https://www.rdoproject.org/repos/rdo-release.rpm.
>  - openstack-neutron-gbp
>  - python-gbpclient
>  - openstack-dashboard-gbp
>
> Do you know where it is?
>
> [1] https://www.rdoproject.org/networking/neutron-gbp/
>
> Regards,
> Yuki Miyahara
>
> __
> OpenStack Development Mailing 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] [lbaas][flavor]Using flavor framework in Mitaka

[Ahana Ghosh]

Hi,

We have a few questions regarding using flavor support in Mitaka-

* We are trying to setup 3 flavors which can be used by LBaaS users 
during Loadbalancer creation. All of the 3 flavours will point to the same 
provider/driver. The driver should be able to understand which flavour was used 
for loadbalancer creation. Can this be done?

* Unfortunately I am stuck in the first step itself. I have enabled 
"flavour" extension in neutron.conf. As an admin I am unable to create & list 
flavours. I am getting a 404 error when I do "" command. Could someone 
please help me resolve this issue?

* If the same flavour is being supported by different service 
providers, will the tenant be unaware about which service provider is providing 
LBAAS service as the admin uses a scheduling algorithm to use LBAAS service 
provided by different service providers for a single flavour?

* What is the difference between a flavor and a flavor profile?

Regards,
Ahana


__
OpenStack Development Mailing 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] Easier way of trying TripleO

[Dan Prince]

On Fri, 2016-08-19 at 15:31 -0400, Dan Prince wrote:
> On Tue, 2013-11-19 at 16:40 -0500, James Slagle wrote:
> > 
> > I'd like to propose an idea around a simplified and complimentary
> > version of
> > devtest that makes it easier for someone to get started and try
> > TripleO.  
> > 
> > The goal being to get people using TripleO as a way to experience
> > the
> > deployment of OpenStack, and not necessarily a way to get an
> > experience of a
> > useable OpenStack cloud itself.
> > 
> > To that end, we could:
> > 
> > 1) Provide an undercloud vm image so that you could effectively
> > skip
> > the entire
> >    seed setup.
> 
> The question here for me is what are you proposing to use to create
> this image? Is it something that could live in tripleo-puppet-
> elements
> like we manage the overcloud package dependencies? Or is it more than
> this? I'd like to not have to build another alternate tool to help
> manage this.
> 
> What if instead of an undercloud image we just created the undercloud
> locally out of containers? Similar to what I've recently proposed
> with
> the heat all-in-one installer here: https://dprince.github.io/tripleo
> -o
> nward-dark-owl.html we could leverage the containers composable
> service
> work for the overcloud in t-h-t and get containers support in the
> undercloud for free.
> 
> If you still want to run an undercloud VM you could configure things
> that way locally, or provide an image with containers in it I guess
> too.
> 
> I'm fine supporting an easier developer case for TripleO but I'd like
> to ultimately have less duplication across the maintenance of the
> Undercloud and Overcloud as part of our solutions for these things
> too.
> 
> Dan

I had a good laugh when James pinged me about this on IRC this morning.

I must have sorted my openstack-dev folder incorrectly... for whatever
reason this message came to my attention on Friday evening so I decided
it worth a reply.

So a bit of mismatched context here... probably best to have a laugh and move 
along. :)

Dan



> 
> > 
> > 2) Provide pre-built downloadable images for the overcloud and
> > deployment
> >    kernel and ramdisk.
> > 3) Instructions on how to use these images to deploy a running
> >    overcloud.
> > 
> > Images could be provided for Ubuntu and Fedora, since both those
> > work
> > fairly
> > well today.
> > 
> > The instructions would look something like:
> > 
> > 1) Download all the images.
> > 2) Perform initial host setup.  This would be much smaller than
> > what
> > is
> >    required for devtest and off the top of my head would mostly be:
> >    - openvswitch bridge setup
> >    - libvirt configuration
> >    - ssh configuration (for the baremetal virtual power driver)
> > 3) Start the undercloud vm.  It would need to be bootstrapped with
> > an
> > initial
> >    static json file for the heat metadata, same as the seed works
> > today.
> > 4) Any last mile manual configuration, such as nova.conf edits for
> > the virtual
> >    power driver user.
> > 6) Use tuskar+horizon (running on the undercloud)  to deploy the
> > overcloud.
> > 7) Overcloud configuration (don't see this being much different
> > than
> > what is
> >    there today).
> > 
> > All the openstack clients, heat templates, etc., are on the
> > undercloud vm, and
> > that's where they're used from, as opposed to from the host
> > (results
> > in less stuff
> > to install/configure on the host).
> > 
> > We could also provide instructions on how to configure the
> > undercloud
> > vm to
> > provision baremetal.  I assume this would be possible, given the
> > correct
> > bridged networking setup.
> > 
> > It could make sense to use an all in one overcloud for this as
> > well,
> > given it's
> > going for simplification.
> > 
> > Obviously, this approach implies some image management on the
> > community's part,
> > and I think we'd document and use all the existing tools (dib,
> > elements) to
> > build images, etc.
> > 
> > Thoughts on this approach?  
> > 
> > --
> > -- James Slagle
> > --
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Neutron] Intermittent gate failures

[Armando M.]

Neutrinos,

Since the merge of test [1], a race has surfaced, which leads to failure as
reported in [2]. A number of Neutron's jobs are affected, and even though
the failure is only intermittent, it is particularly bad for the linux
bridge job.

If I can ask you to hold your +2/+W until [3] puts the fire out, zuul will
be grateful.

Thanks,
Armando

[1] https://review.openstack.org/#/c/327191/
[2] https://bugs.launchpad.net/neutron/+bug/1615710
[3] https://review.openstack.org/#/c/358753/
__
OpenStack Development Mailing 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] [stable] [all] Changing stable policy for drivers

[Arkady_Kanevsky]

Sorry if touch 3rd rail.
But should backport bug fixes to older releases be done in distros and not 
upstream?

-Original Message-
From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
Sent: Tuesday, August 09, 2016 12:34 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for 
drivers

On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
> Duncan Thomas wrote:
>
>> On 8 August 2016 at 21:12, Matthew Treinish
>> wrote:
>> Ignoring all that, this is also contrary to how we perform testing in
>> OpenStack.
>> We don't turn off entire classes of testing we have so we can land
>> patches, that's just a recipe for disaster.
>>
>> But is it more of a disaster (for the consumers) than zero testing,
>> zero review, scattered around the internet
>> if-you're-lucky-with-a-good-wind you'll maybe get the right patch
>> set? Because that's where we are right now, and vendors, distributors
>> and the cinder core team are all saying it's a disaster.
>
> If consumers rely on upstream releases, then they are expected to
> migrate to newer releases after EOL, not switch to a random branch on
> the internet. If they rely on some commercial product, then they
> usually have an extended period of support and certification for their
> drivers, so it's not a problem for them.
>
> Ihar
This is entirely unrealistic. Force customers to upgrade. Good luck
explaining to a bank that in order to get their cinder driver fix in, they have 
to upgrade their entire OpenStack deployment. Real world customers simply will 
balk at this all day long.

Walt
>
> __
> 
>
> OpenStack Development Mailing 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] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Adrien,

this looks good to me. Let's see what Joshua and Augie will think about it.

Cheers,
Dina

On Mon, Aug 22, 2016 at 7:44 AM,  wrote:

> Hi Dina,
>
> 17:30 UTC means 19:30 in France (Summer time).
> Considering that the meeting lasts in average 30/45 min, it would be great
> if we could find a trade off a bit sooner. What's about 17:00 UTC ?
>
> Thanks,
> Adrien
>
> - Mail original -
> > De: "Dina Belova" 
> > À: "OpenStack Development Mailing List"  openstack.org>, "openstack-operators"
> > 
> > Envoyé: Jeudi 18 Août 2016 21:35:48
> > Objet: [Performance][Meeting time] Possible meeting time change:
> feedback appreciated
> >
> >
> > Hey, OpenStackers!
> >
> >
> > recently I've got lots comments about current time our Performance
> > Team meetings are held on. Right now we're having them 16:00 UTC on
> > Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
> > time slot is not that much comfortable for some of the US folks due
> > to internal daily meetings.
> >
> >
> > The question is: can we move our weekly meeting to 17:30 UTC (10:30
> > PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
> > collect more feedback.
> >
> >
> > Please leave your comments.
> >
> >
> > Cheers,
> > Dina
> >
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dina Belova Senior Software Engineer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Mirantis, Inc.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 525 Almanor Avenue, 4th Floor
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sunnyvale, CA 94085 Phone: 650-772-8418
> > Email: dbel...@mirantis.com
> > www.mirantis.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>



-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.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] [nova][keystone] auth for new metadata plugins

[Rob Crittenden]

Adam Young wrote:

On 08/15/2016 05:10 PM, Rob Crittenden wrote:

Review https://review.openstack.org/#/c/317739/ added a new dynamic
metadata handler to nova. The basic jist is that rather than serving
metadata statically, it can be done dyamically, so that certain values
aren't provided until they are needed, mostly for security purposes
(like credentials to enroll in an AD domain). The metadata is
configured as URLs to a REST service.

Very little is passed into the REST call, mostly UUIDs of the
instance, image, etc. to ensure a stable API. What this means though
is that the REST service may need to make calls into nova or glance to
get information, like looking up the image metadata in glance.

Currently the dynamic metadata handler _can_ generate auth headers if
an authenticated request is made to it, but consider that a common use
case is fetching metadata from within an instance using something like:

% curl http://169.254.169.254/openstack/2016-10-06/vendor_data2.json

This will come into the nova metadata service unauthenticated.

So a few questions:

1. Is it possible to configure paste (I'm a relative newbie) both
authenticated and unauthenticated requests are accepted such that IF
an authenticated request comes it, those credentials can be used,
otherwise fall back to something else?



Only if they are on different URLs, I think.  Its auth_token middleware
for all services but Keystone.  Keystone, the rles are similar, but the
implementation is a little different.


Ok. I'm fine with the unauthenticated path if the service we can just 
create a separate service user for it.



2. If an unauthenticated request comes in, how best to obtain a token
to use? Is it best to create a service user for the REST services
(perhaps several), use a shared user, something else?



No unauthenticated requests, please.  If the call is to Keystone, we
could use the X509 Tokenless approach, but if the call comes from the
new server, you won't have a cert by the time you need to make the call,
will you?


Not sure which cert you're referring too but yeah, the metadata service 
is unauthenticated. The requests can come in from the instance which has 
no credentials (via http://169.254.169.254/).



Shared service users are probably your best bet.  We can limit the roles
that they get.  What are these calls you need to make?


To glance for image metadata, Keystone for project information and nova 
for instance information. The REST call passes in various UUIDs for 
these so they need to be dereferenced. There is no guarantee that these 
would be called in all cases but it is a possibility.


rob



I guess if config_drive is True then this isn't really a problem as
the metadata will be there in the instance already.

thanks

rob

__

OpenStack Development Mailing 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] [api] Example HTTP status codes for review

[Anne Gentle]

Hi all,
To give projects a head start and a path to copy/paste to success, I've got
a sample HTTP status code YAML file that you can use with the os-api-ref
Sphinx extension to make nicely-styled HTML tables. Please take a look at
https://review.openstack.org/#/c/351835/

The idea here isn't to force projects to use a common description for
status codes but rather to give the current 25 OpenStack REST APIs a common
starting point for consistency. Read the update to the docs to gain an
understanding of its use: https://review.openstack.org/#/c/351794/

Thanks,
Anne

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

Re: [openstack-dev] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[lebre . adrien]

Hi Dina, 

17:30 UTC means 19:30 in France (Summer time). 
Considering that the meeting lasts in average 30/45 min, it would be great if 
we could find a trade off a bit sooner. What's about 17:00 UTC ?

Thanks,
Adrien

- Mail original -
> De: "Dina Belova" 
> À: "OpenStack Development Mailing List" , 
> "openstack-operators"
> 
> Envoyé: Jeudi 18 Août 2016 21:35:48
> Objet: [Performance][Meeting time] Possible meeting time change: feedback 
> appreciated
> 
> 
> Hey, OpenStackers!
> 
> 
> recently I've got lots comments about current time our Performance
> Team meetings are held on. Right now we're having them 16:00 UTC on
> Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
> time slot is not that much comfortable for some of the US folks due
> to internal daily meetings.
> 
> 
> The question is: can we move our weekly meeting to 17:30 UTC (10:30
> PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
> collect more feedback.
> 
> 
> Please leave your comments.
> 
> 
> Cheers,
> Dina
> 
> 
> --
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Dina Belova Senior Software Engineer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Mirantis, Inc.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 525 Almanor Avenue, 4th Floor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sunnyvale, CA 94085 Phone: 650-772-8418
> Email: dbel...@mirantis.com
> www.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

[openstack-dev] [all] Generating python API signature + diff reports

[Boden Russell]

Do any projects have an interest in generating python API signature
reports capable of showing "what's new/changed/removed" in a release
(ex: [2])? If so, read on.


We recently developed a tool in neutron-lib [1] capable of inspecting +
generating python API signature and diff reports.

Its current high-level features include:
- Inspecting python source without installing any dependencies.
- Generating python API signature reports in a JSON format. For example [3].
- Diffing python two JSON API signature reports; showing what's
new/removed/changed/unchanged. For example [2].
- Showing python API signature reports in a user-friendly format.
- Filtering (blacklist) inspection and report output using regex patterns.

We're currently using the tool to generate a "what's new" report for
neutron-lib releases, but hope to incorporate it into the actual release
notes longer term.

In its current form, the implementation a prototype living as a
neutron-lib tool.
However, if other projects may have an interest in such tool I'd
consider spinning the tool off into it's own repo and spending some time
solidifying the implementation.

I'll gauge interest based on feedback here, and/or find me on
#openstack-neutron as 'boden'.


[1] https://github.com/openstack/neutron-lib/blob/master/tools/pyir.py
[2] http://paste.openstack.org/show/562199/
[3] http://paste.openstack.org/show/562200/

__
OpenStack Development Mailing 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] Driver removal policies - should we make it softer?

[Vladyslav Drok]

+1 from me then :)

On Mon, Aug 22, 2016 at 4:52 PM, Jim Rollenhagen 
wrote:

> On Mon, Aug 22, 2016 at 8:01 AM, Vladyslav Drok 
> wrote:
> > On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen  >
> > wrote:
> >>
> >> Hi Ironickers,
> >>
> >> There was a big thread here[0] about Cinder, driver removal, and
> standard
> >> deprecation policy. If you haven't read through it yet, please do before
> >> continuing here. :)
> >>
> >> The outcome of that thread is summarized well here.[1]
> >>
> >> I know that I previously had a different opinion on this, but I think we
> >> should go roughly the same route, for the sake of the users.
> >>
> >> 1) A ``supported`` flag for each driver that is True if and only if the
> >> driver
> >>is tested in infra or third-party CI (and meets our third party CI
> >>requirements).
> >> 2) If the supported flag is False for a driver, deprecation is implied
> >> (and
> >>a warning is emitted at load time). A driver may be removed per
> >> standard
> >>deprecation policies, with turning the supported flag False to start
> >> the
> >>clock.
> >> 3) Add a ``enable_unsupported_drivers`` config option that allows
> enabling
> >>drivers marked supported=False. If a driver is in enabled_drivers,
> has
> >>supported=False, and enable_unsupported_drivers=False,
> ironic-conductor
> >>will fail to start. Setting enable_unsupported_drivers=True will
> allow
> >>ironic-conductor to start with warnings emitted.
> >
> >
> > Just for clarity, its default value is False?
>
> Sorry, I meant to add that. Yes, default for
> enable_unsupported_drivers is False.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [LBaaS][Octavia] Health manager does not create standby amphora VM

[Michael Johnson]

Hi Koteswara,

This is not normal behavior, but there was a reported bug that was recent fixed.

Please see: https://bugs.launchpad.net/octavia/+bug/1577963

If you are still seeing an issue after using a patched version, please
open a bug for the issue.

Michael

On Mon, Aug 22, 2016 at 6:10 AM, Kelam, Koteswara Rao
 wrote:
> Hi All,
>
>
>
> I followed these steps and health manager does not create standby amphora VM
> in step 6. Is this a defect or working as per design?
>
>
>
> 0. Spare pool =2
>
> 1. Create LB
> 2. Two amphora VMs got created ( One is active , second is standby )
> 3. Shutdown the Active amphora VM
> 4. Standby takes control and becomes ACTIVE
> 5. Shutdown VM gets deleted in house keeping cycle.
> 6. Health manager not creating standby amphora VM.
> 7. Now only one Active amphora VM is available.
> 8. Shutdown the present active Amphora VM.
> 9. No Amphora VM is taking since there is no standby VM created in stpe 6.
>
>
>
> Regards,
>
> Koteswara
>
>
>
>
> __
> OpenStack Development Mailing 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] [ironic] Driver removal policies - should we make it softer?

[Jim Rollenhagen]

On Mon, Aug 22, 2016 at 8:01 AM, Vladyslav Drok  wrote:
> On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen 
> wrote:
>>
>> Hi Ironickers,
>>
>> There was a big thread here[0] about Cinder, driver removal, and standard
>> deprecation policy. If you haven't read through it yet, please do before
>> continuing here. :)
>>
>> The outcome of that thread is summarized well here.[1]
>>
>> I know that I previously had a different opinion on this, but I think we
>> should go roughly the same route, for the sake of the users.
>>
>> 1) A ``supported`` flag for each driver that is True if and only if the
>> driver
>>is tested in infra or third-party CI (and meets our third party CI
>>requirements).
>> 2) If the supported flag is False for a driver, deprecation is implied
>> (and
>>a warning is emitted at load time). A driver may be removed per
>> standard
>>deprecation policies, with turning the supported flag False to start
>> the
>>clock.
>> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>>drivers marked supported=False. If a driver is in enabled_drivers, has
>>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>>will fail to start. Setting enable_unsupported_drivers=True will allow
>>ironic-conductor to start with warnings emitted.
>
>
> Just for clarity, its default value is False?

Sorry, I meant to add that. Yes, default for
enable_unsupported_drivers is False.

// jim

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

Re: [openstack-dev] [TripleO] Improving Swift deployments with TripleO

[Christian Schwede]

On 04.08.16 15:39, Giulio Fidente wrote:
> On 08/04/2016 01:26 PM, Christian Schwede wrote:
>> On 04.08.16 10:27, Giulio Fidente wrote:
>>> On 08/02/2016 09:36 PM, Christian Schwede wrote:
 Hello everyone,
>>>
>>> thanks Christian,
>>>
 I'd like to improve the Swift deployments done by TripleO. There are a
 few problems today when deployed with the current defaults:

 1. Adding new nodes (or replacing existing nodes) is not possible,
 because the rings are built locally on each host and a new node doesn't
 know about the "history" of the rings. Therefore rings might become
 different on the nodes, and that results in an unusable state
 eventually.
>>>
>>> one of the ideas for this was to use a tempurl in the undercloud swift
>>> where to upload the rings built by a single overcloud node, not by the
>>> undercloud
>>>
>>> so I proposed a new heat resource which would permit us to create a
>>> swift tempurl in the undercloud during the deployment
>>>
>>> https://review.openstack.org/#/c/350707/
>>>
>>> if we build the rings on the undercloud we can ignore this and use a
>>> mistral action instead, as pointed by Steven
>>>
>>> the good thing about building rings in the overcloud is that it doesn't
>>> force us to have a static node mapping for each and every deployment but
>>> it makes hard to cope with heterogeneous environments
>>
>> That's true. However - we still need to collect the device data from all
>> the nodes from the undercloud, push it to at least one overcloud mode,
>> build/update the rings there, push it to the undercloud Swift and use
>> that on all overcloud nodes. Or not?
> 
> sure, let's build on the undercloud, when automated with mistral it
> shouldn't make a big difference for the user
> 
>> I was also thinking more about the static node mapping and how to avoid
>> this. Could we add a host alias using the node UUIDs? That would never
>> change, it's available from the introspection data and therefore could
>> be used in the rings.
>>
>> http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_specific_hieradata.html#collecting-the-node-uuid
>>
> 
> right, this is the mechanism I wanted to use to proviude per-node disk
> maps, it's how it works for ceph disks as well

I looked into this further and proposed a patch upstream:

https://review.openstack.org/358643

This worked fine in my tests, an example /etc/hosts looks like this:

http://paste.openstack.org/show/562206/

And based on that patch we could build the Swift rings even if the nodes
are down and never been deployed, because the system uuid will never
change and is unique. I updated my tripleo-swift-ring-tool and just run
a successful deployment with the patch (also using the merged patches
from Giulio).

Let me know what you think about it - I think with that patch we could
integrate the tripleo-swift-ring-tool.

-- Christian

 2. The rings are only using a single device, and it seems that this is
 just a directory and not a mountpoint with a real device. Therefore
 data
 is stored on the root device - even if you have 100TB disk space in the
 background. If not fixed manually your root device will run out of
 space
 eventually.
>>>
>>> for the disks instead I am thinking to add a create_resources wrapper in
>>> puppet-swift:
>>>
>>> https://review.openstack.org/#/c/350790
>>> https://review.openstack.org/#/c/350840/
>>>
>>> so that we can pass via hieradata per-node swift::storage::disks maps
>>>
>>> we have a mechanism to push per-node hieradata based on the system uuid,
>>> we could extend the tool to capture the nodes (system) uuid and generate
>>> per-node maps
>>
>> Awesome, thanks Giulio!
>>
>> I will test that today. So the tool could generate the mapping
>> automatically, and we don't need to filter puppet facts on the nodes
>> itself. Nice!   
> 
> and we could re-use the same tool to generate the ceph::osds disk maps
> as well :)
> 


__
OpenStack Development Mailing 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] [new][glance] glance_store 0.18.0 release (newton)

[no-reply]

We are high-spirited to announce the release of:

glance_store 0.18.0: OpenStack Image Service Store Library

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/glance_store

Please report issues through launchpad:

http://bugs.launchpad.net/glance-store

For more details, please see below.

Changes in glance_store 0.17.0..0.18.0
--

6263547 Fix header passed to requests
9753355 Updated from global requirements


Diffstat (except docs and test files)
-

glance_store/_drivers/vmware_datastore.py|  2 +-
test-requirements.txt|  2 +-
3 files changed, 11 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index fb230fc..80ee9b0 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -20 +20 @@ os-testr>=0.7.0 # Apache-2.0
-bandit>=1.0.1 # Apache-2.0
+bandit>=1.1.0 # Apache-2.0



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

[openstack-dev] [new][openstack] os-client-config 1.20.0 release (newton)

[no-reply]

We are high-spirited to announce the release of:

os-client-config 1.20.0: OpenStack Client Configuation Library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-client-config

With package available at:

https://pypi.python.org/pypi/os-client-config

Please report issues through launchpad:

http://bugs.launchpad.net/os-client-config

For more details, please see below.

Changes in os-client-config 1.19.1..1.20.0
--

9d757b3 Add support for configuring split-stack networks
a6840f6 Pop domain-id from the config if we infer values
600a638 Update Internap information


Diffstat (except docs and test files)
-

os_client_config/cloud_config.py   | 24 
os_client_config/config.py |  9 +
os_client_config/vendors/internap.json |  5 +++--
7 files changed, 73 insertions(+), 7 deletions(-)




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

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Vladyslav Drok]

On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen 
wrote:

> Hi Ironickers,
>
> There was a big thread here[0] about Cinder, driver removal, and standard
> deprecation policy. If you haven't read through it yet, please do before
> continuing here. :)
>
> The outcome of that thread is summarized well here.[1]
>
> I know that I previously had a different opinion on this, but I think we
> should go roughly the same route, for the sake of the users.
>
> 1) A ``supported`` flag for each driver that is True if and only if the
> driver
>is tested in infra or third-party CI (and meets our third party CI
>requirements).
> 2) If the supported flag is False for a driver, deprecation is implied (and
>a warning is emitted at load time). A driver may be removed per standard
>deprecation policies, with turning the supported flag False to start the
>clock.
> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>drivers marked supported=False. If a driver is in enabled_drivers, has
>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>will fail to start. Setting enable_unsupported_drivers=True will allow
>ironic-conductor to start with warnings emitted.
>

Just for clarity, its default value is False?


>
> It is important to note that (3) does still technically break the standard
> deprecation policy (old config may not work with new version of ironic).
> However, this is a much softer landing than the original plan. FWIW, I do
> expect (but not hope!) this part will be somewhat contentious.
>
> I'd like to hear thoughts and get consensus on this from the rest of the
> ironic community, so please do reply whether you agree or disagree.
>
> I'm happy to do the work required (update spec, code patches, doc updates)
> when we do come to agreement.
>
> // jim
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101428.html
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101898.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Matt Kassawara]

Why isn't this content in the openstack-manuals repository?

On Sun, Aug 21, 2016 at 4:38 PM, Kaustubh Kelkar 
wrote:

> I might have missed it entirely, but I wasn't able to find virtual
> resources used by the instances. IMO, it'd be great if one could see
> instance flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
> ratios from host's perspective.
>
>
> Thanks,
> Kaustubh
> --
> *From:* Dina Belova 
> *Sent:* Friday, August 19, 2016 12:37 PM
> *To:* OpenStack Development Mailing List; openstack-operators
> *Subject:* [Openstack-operators] [Performance][Documentation] Please take
> a look on OpenStack perofmance-docs
>
> Folks,
>
> During previous weeks we merged lots of OpenStack performance-related test
> plans and test results to the performance-docs
>  and your feedback
> (as usually) is very appreciated. I hope you can find something interesting
> for you here and share your opinion on what's going on regarding our
> performance researches.
>
>
> Thanks in advance!
>
> Cheers,
> Dina
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
> *
> www.mirantis.com
> 
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing 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] [LBaaS][Octavia] Health manager does not create standby amphora VM

[Kelam, Koteswara Rao]

Hi All,

I followed these steps and health manager does not create standby amphora VM in 
step 6. Is this a defect or working as per design?

0. Spare pool =2
1. Create LB
2. Two amphora VMs got created ( One is active , second is standby )
3. Shutdown the Active amphora VM
4. Standby takes control and becomes ACTIVE
5. Shutdown VM gets deleted in house keeping cycle.
6. Health manager not creating standby amphora VM.
7. Now only one Active amphora VM is available.
8. Shutdown the present active Amphora VM.
9. No Amphora VM is taking since there is no standby VM created in stpe 6.

Regards,
Koteswara

__
OpenStack Development Mailing 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] Hold off on pushing new patches for config option cleanup

[Sean Dague]

On 08/22/2016 12:10 AM, Michael Still wrote:

So, if this is about preserving CI time, then its cool for me to merge
these on a US Sunday when the gate is otherwise idle, right?


yes.



Michael

On Fri, Aug 19, 2016 at 7:02 AM, Sean Dague > wrote:

On 08/18/2016 04:46 PM, Michael Still wrote:
> We're still ok with merging existing ones though?

Mostly we'd like to conserve the CI time now. It's about 14.5 node-hours
to run CI on these patches (probably on about 9 node-hours in the gate).
With ~800 nodes every patch represents 1.5% of our CI resources (per
hour) to pass through. There are a ton of these patches up there, so
even just landing gating ones consumes resources that could go towards
other more critical fixes / features.

I think the theory is these are fine to merge post freeze / milestone 3,
when the CI should have cooled down a bit and there is more head room.

-Sean

--
Sean Dague
http://dague.net

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

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





--
Rackspace Australia


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




--
Sean Dague
http://dague.net

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

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Sam Betts (sambetts)]

On 19/08/2016 18:44, "Villalovos, John L" 
wrote:

>> -Original Message-
>> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
>> Sent: Friday, August 19, 2016 7:15 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: [openstack-dev] [ironic] Driver removal policies - should we
>>make it
>> softer?
>> 
>> Hi Ironickers,
>> 
>> There was a big thread here[0] about Cinder, driver removal, and
>>standard
>> deprecation policy. If you haven't read through it yet, please do before
>> continuing here. :)
>> 
>> The outcome of that thread is summarized well here.[1]
>> 
>> I know that I previously had a different opinion on this, but I think we
>> should go roughly the same route, for the sake of the users.
>> 
>> 1) A ``supported`` flag for each driver that is True if and only if the
>>driver
>>is tested in infra or third-party CI (and meets our third party CI
>>requirements).
>> 2) If the supported flag is False for a driver, deprecation is implied
>>(and
>>a warning is emitted at load time). A driver may be removed per
>>standard
>>deprecation policies, with turning the supported flag False to start
>>the
>>clock.
>> 3) Add a ``enable_unsupported_drivers`` config option that allows
>>enabling
>>drivers marked supported=False. If a driver is in enabled_drivers,
>>has
>>supported=False, and enable_unsupported_drivers=False, ironic-
>> conductor
>>will fail to start. Setting enable_unsupported_drivers=True will
>>allow
>>ironic-conductor to start with warnings emitted.
>> 
>> It is important to note that (3) does still technically break the
>>standard
>> deprecation policy (old config may not work with new version of ironic).
>> However, this is a much softer landing than the original plan. FWIW, I
>>do
>> expect (but not hope!) this part will be somewhat contentious.
>> 
>> I'd like to hear thoughts and get consensus on this from the rest of the
>> ironic community, so please do reply whether you agree or disagree.
>> 
>> I'm happy to do the work required (update spec, code patches, doc
>>updates)
>> when we do come to agreement.
>> 
>> // jim
>> 
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
>> August/101428.html
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
>> August/101898.html
>
>Thanks Jim. This proposal makes sense to me. So put me into the agree
>camp.

+1 from me too

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


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

Re: [openstack-dev] [NOVA] How boot an instance on specific compute with provider-network: physnet1

[Leehom Li (feli5)]

With tags we can boot instances to a specified host aggregate.
But in case when we need boot instances to a specified host, available zone is 
a good approach.
Otherwise, we need to provide tagged flavors for each host. In real use I think 
it's quite impossible.

Best regards,
Leehom Li


From: Fawaz Mohammed 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, August 22, 2016 at 4:43 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [NOVA] How boot an instance on specific compute 
with provider-network: physnet1


Cloud admin can add the necessary tags in the tenant flavors.

On Aug 22, 2016 12:00 AM, "Jay Pipes" 
> wrote:
On 08/21/2016 03:24 PM, Fawaz Mohammed wrote:
I belive utilizing host aggregate is better than availability zone in
this case.

Users don't know anything about host aggregates. They are a cloud-admin-only 
way of grouping like compute resources together and the end user doesn't have 
any way of specifying a particular host aggregate when launching an instance.

Best,
-jay

On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)" 

>> wrote:

Hi, All

I used to use below command to boot an instance with a specified IP
address to a
Specified compute node.

nova boot
--image  \
--flavor  \
--nic net-id=,v4-fixed-ip= \
--availability-zone :




May it helps.

leehom

On 8/17/16, 11:53 PM, "Géza Gémes" 

>> wrote:

>On 08/17/2016 05:38 PM, Rick Jones wrote:
>> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
>>> Hi All,
>>>
>>> I have two computes
>>>
>>> Compute node 1:
>>> 1. physnet3:br-eth0
>>>
>>> 2. physnet2: br-eth2
>>>
>>> Compute node 2:
>>> 1. physnet3:br-eth0
>>> 2. physnet1:br-eth1
>>> 3. physnet2:br-eth2
>>>
>>> When I boot an instance with a network of provider-network physnet1,
>>> nova is scheduling it on compute1 but there is no physnet1 on
compute1
>>> and it fails.
>>>
>>> Is there any mechanism/way to choose correct compute with correct
>>> provider-network?
>>
>> Well, the --availability-zone option can be given a host name
>> separated from an optional actual availability zone identifier by a
>> colon:
>>
>> nova boot .. --availability-zone :hostname ...
>>
>> But specifying a specific host rather than just an availability zone
>> requires the project to have forced_host (or is it force_host?)
>> capabilities.  You could, perhaps, define the two computes to be
>> separate availability zones to work around that.
>>
>> rick jones
>>
>>
>>
>>_
>>_
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

>
>Hi,
>
>Does it help if you boot your VMs, with pre-created neutron ports,
>rather than a neutron network? I think nova is supposed to bind
then and
>failing that it shall rescedule the VM (up to the configured
re-schedule
>attempts (3 by default)). I think this is an area, where e.g. one
of the
>physnet would relate to an SRIOV PF the PciDeviceFilter would be
able to
>select the right host from beginning.
>
>Cheers,
>
>Geza
>
>
>__
>OpenStack Development Mailing 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] [Fuel] Ocata design summit planning

[Vladimir Kozhukalov]

Dear colleagues,

We are two months from Ocata summit. Let's start planning topics we would
like to discuss during design sessions. Here is etherpad [1]. Please put
your topics under backlog section and we will disscuss later which of them
will be brought out to design sessions.

[1] https://etherpad.openstack.org/p/fuel-ocata-summit-planning


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] mod_wsgi: what services are people using with it?

[Kairat Kushaev]

Just small note about mod_wsgi for Glance,
You need mod_wsgi v.4.4.0 or older to work with Glance in daemon mode.
Otherwise, glance should fail when uploading images.

Best regards,
Kairat Kushaev

On Sat, Aug 20, 2016 at 4:00 AM, Nick Papadonis 
wrote:

>
>
> On Fri, Aug 19, 2016 at 5:34 PM, John Dickinson  wrote:
>
>>
>>
>> On 17 Aug 2016, at 15:27, Nick Papadonis wrote:
>>
>> > comments
>> >
>> > On Wed, Aug 17, 2016 at 4:53 PM, Matthew Thode <
>> prometheanf...@gentoo.org>
>> > wrote:
>> >
>> >> On 08/17/2016 03:52 PM, Nick Papadonis wrote:
>> >>
>> >>> Thanks for the quick response!
>> >>>
>> >>> Glance worked for me in Mitaka.  I had to specify 'chunked transfers'
>> >>> and increase the size limit to 5GB.  I had to pull some of the WSGI
>> >>> source from glance and alter it slightly to call from Apache.
>> >>>
>> >>> I saw that Nova claims mod_wsgi is 'experimental'.  Interested in it's
>> >>> really experimental or folks use it in production.
>> >>>
>> >>> Nick
>> >>
>> >> ya, cinder is experimental too (at least in my usage) as I'm using
>> >> python3 as well :D  For me it's a case of having to test the packages I
>> >> build.
>> >>
>> >>
>> > I converted Cinder to mod_wsgi because from what I recall, I found that
>> SSL
>> > support was removed from the Eventlet server.  Swift endpoint outputs a
>> log
>> > warning that Eventlet SSL is only for testing purposes, which is another
>> > reason why I turned to mod_wsgi for that.
>>
>> FWIW, most prod Swift deployments I know of use HAProxy or stud to
>> terminate TLS before forwarding the http stream to a proxy endpoint (local
>> or remote). Especially when combined with a server that has AES-NI, this
>> gives good performance.
>
>
> Thanks.  I'd be interested if anyone has done a performance comparison of
> HAProxy vs mod_wsgi to terminate.
>
> __
> OpenStack Development Mailing 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] [Group-based-policy] Question on GBP installation

[Yuki Miyahara]

Hi GBP Team,

Now I'm trying to install OpenStack (Liberty) with GBP on RHEL7.2[1],
but I can't find following packages from
https://www.rdoproject.org/repos/rdo-release.rpm.
 - openstack-neutron-gbp
 - python-gbpclient
 - openstack-dashboard-gbp

Do you know where it is?

[1] https://www.rdoproject.org/networking/neutron-gbp/

Regards,
Yuki Miyahara

__
OpenStack Development Mailing 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] How boot an instance on specific compute with provider-network: physnet1

[Fawaz Mohammed]

Cloud admin can add the necessary tags in the tenant flavors.

On Aug 22, 2016 12:00 AM, "Jay Pipes"  wrote:

> On 08/21/2016 03:24 PM, Fawaz Mohammed wrote:
>
>> I belive utilizing host aggregate is better than availability zone in
>> this case.
>>
>
> Users don't know anything about host aggregates. They are a
> cloud-admin-only way of grouping like compute resources together and the
> end user doesn't have any way of specifying a particular host aggregate
> when launching an instance.
>
> Best,
> -jay
>
> On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)" > > wrote:
>>
>> Hi, All
>>
>> I used to use below command to boot an instance with a specified IP
>> address to a
>> Specified compute node.
>>
>> nova boot
>> --image  \
>> --flavor  \
>> --nic net-id=,v4-fixed-ip= \
>> --availability-zone :
>> 
>>
>>
>>
>> May it helps.
>>
>> leehom
>>
>> On 8/17/16, 11:53 PM, "Géza Gémes" > > wrote:
>>
>> >On 08/17/2016 05:38 PM, Rick Jones wrote:
>> >> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
>> >>> Hi All,
>> >>>
>> >>> I have two computes
>> >>>
>> >>> Compute node 1:
>> >>> 1. physnet3:br-eth0
>> >>>
>> >>> 2. physnet2: br-eth2
>> >>>
>> >>> Compute node 2:
>> >>> 1. physnet3:br-eth0
>> >>> 2. physnet1:br-eth1
>> >>> 3. physnet2:br-eth2
>> >>>
>> >>> When I boot an instance with a network of provider-network
>> physnet1,
>> >>> nova is scheduling it on compute1 but there is no physnet1 on
>> compute1
>> >>> and it fails.
>> >>>
>> >>> Is there any mechanism/way to choose correct compute with correct
>> >>> provider-network?
>> >>
>> >> Well, the --availability-zone option can be given a host name
>> >> separated from an optional actual availability zone identifier by a
>> >> colon:
>> >>
>> >> nova boot .. --availability-zone :hostname ...
>> >>
>> >> But specifying a specific host rather than just an availability
>> zone
>> >> requires the project to have forced_host (or is it force_host?)
>> >> capabilities.  You could, perhaps, define the two computes to be
>> >> separate availability zones to work around that.
>> >>
>> >> rick jones
>> >>
>> >>
>> >>
>> >>__
>> ___
>> >>_
>> >>
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> >
>> >Hi,
>> >
>> >Does it help if you boot your VMs, with pre-created neutron ports,
>> >rather than a neutron network? I think nova is supposed to bind
>> then and
>> >failing that it shall rescedule the VM (up to the configured
>> re-schedule
>> >attempts (3 by default)). I think this is an area, where e.g. one
>> of the
>> >physnet would relate to an SRIOV PF the PciDeviceFilter would be
>> able to
>> >select the right host from beginning.
>> >
>> >Cheers,
>> >
>> >Geza
>> >
>> >
>> >___
>> ___
>> >OpenStack Development Mailing 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

[openstack-dev] ?????? [devstack] How to start all OpenStack servicesafter restarting system?

[wk]

my scripts, runs ok:


/usr/bin/python /usr/bin/glance-registry 
--config-file=/etc/glance/glance-registry.conf &> glance-registry.log &  
/usr/bin/python /usr//bin/glance-api --config-file=/etc/glance/glance-api.conf 
&> glance-api.log &  
/usr/bin/python /usr/bin/nova-conductor &> nova-conductor.log &  
sg libvirtd /usr/bin/nova-compute --config-file /etc/nova/nova.conf &> 
nova-compute.log &  
/usr/bin/python /usr/bin/nova-compute --config-file /etc/nova/nova.conf &> 
nova-compute.log &  
/usr/bin/python /usr/bin/nova-cert &> nova-cert.log &  
/usr/bin/python /usr/bin/nova-network --config-file /etc/nova/nova.conf &> 
nova-network.log &  
/usr/bin/python /usr/bin/nova-scheduler --config-file /etc/nova/nova.conf &> 
nova-scheduler.log &  
/usr/bin/python /usr/bin/nova-novncproxy --config-file /etc/nova/nova.conf 
--web /opt/stack/noVNC &> nova-novncproxy.log &  
/usr/bin/python /usr/bin/nova-xvpvncproxy --config-file /etc/nova/nova.conf &> 
nova-xvpvncproxy.log &  
/usr/bin/python /usr/bin/nova-consoleauth &> nova-consoleauth.log &  
/usr/bin/python /usr/bin/nova-objectstore &> nova-objectstore.log &  
/usr/bin/python /usr/bin/cinder-api --config-file /etc/cinder/cinder.conf &> 
cinder-api.log &  
/usr/bin/python /usr/bin/cinder-scheduler --config-file /etc/cinder/cinder.conf 
&> cinder-scheduler.log &  
/usr/bin/python /usr/bin/cinder-volume --config-file /etc/cinder/cinder.conf &> 
cinder-volume.log &  
/usr/bin/python /usr/bin/nova-api &> nova-api.log &  
/usr/bin/python /opt/stack/keystone/bin/keystone-all --config-file 
/etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug 
&> keystone-all.log &  
/usr/sbin/httpd -D FOREGROUND &> httpd.log &  
/bin/sh /usr/bin/mysqld_safe --basedir=/usr &> mysqld_safe.log &  
/usr/sbin/rabbitmq-server &> rabbitmq-server.log &


/usr/bin/python /usr/bin/ceilometer &> ceilometer.log &
#start dashboard
systemctl start httpd





--  --
??: "zhi";;
: 2016??8??18??(??) 5:33
??: "OpenStack Development Mailing List (not for usage 
questions)"; 

: [openstack-dev] [devstack] How to start all OpenStack servicesafter 
restarting system?



hi, all.

Currently, there is no "rejoin-stack.sh" script in devstack. 


 It will clear all resources and create all resources if I rerun 
"./stack.sh" after restarting system. 


 So,  how to start all OpenStack services after restarting system quickly?




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

Re: [openstack-dev] [TripleO][UI] Port number for frontend app

[Erno Kuvaja]

On Mon, Aug 22, 2016 at 7:08 AM, Honza Pokorny  wrote:
> Hello folks,
>
> We've been using port 3000 for the GUI during development and testing.
> Now that we're working on packaging and shipping our code, we're
> wondering if port 3000 is still the best choice.
>
> Would 3000 conflict with any other services?  Is there a better option?
>
> Thanks
>
> Honza Pokorny
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Based on 
http://docs.openstack.org/mitaka/config-reference/firewalls-default-ports.html
3000 should be unused so far. IANA has assigned 3000 and there is
widespread use colliding with it as well, but neither looks like
something that would collide in Undercloud:

hbci   3000tcpHBCI
[Kurt_Haubner][Kurt_Haubner]
hbci   3000udpHBCI
[Kurt_Haubner][Kurt_Haubner]
remoteware-cl  3000tcpRemoteWare Client
[Tim_Farley]  [Tim_Farley]

This entry records
an unassigned but widespread use
remoteware-cl  3000udpRemoteWare Client
[Tim_Farley]  [Tim_Farley]

This entry records
an unassigned but widespread use

So by the quick look the 3000 is likely as bad choice as any
unassigned for it by IANA one.

- Erno

__
OpenStack Development Mailing 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][UI] Port number for frontend app

[Matthias Runge]

On 22/08/16 08:08, Honza Pokorny wrote:
> Hello folks,
> 
> We've been using port 3000 for the GUI during development and testing.
> Now that we're working on packaging and shipping our code, we're
> wondering if port 3000 is still the best choice.
> 
> Would 3000 conflict with any other services?  Is there a better option?

grafana from opstools uses the same port[1]

That being said, I wonder if someone would install both services on the
same node.



[1]
https://github.com/centos-opstools/opstools-doc/blob/master/performance-monitoring.txt#L70


Matthias
-- 
Matthias Runge 

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

__
OpenStack Development Mailing 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] Update port status to error from l2 agent

[Hirofumi Ichihara]

The use-case is similar to the spec[1].

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

On 2016/08/22 15:48, Edan David wrote:


Hi all,

It seems today that the ml2 rpc API only supports reporting that a 
port is up\down,


There may be situations when the l2 agent can fail,

For example SR-IOV agent can report failure when configuring a port on 
the wrong physnet.


In these cases we should how would one report port failed status with 
the rpc messages?


Should we add a new rpc call?

Also it’s not clear to me why the documentation in the 
plugins/ml2/rpc.py file


States that the method ‘update_device_down’  function is: “Device no 
longer exists on agent”, when it stets the port status to down in 
admin_state_down.




__
OpenStack Development Mailing 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] [neutron] Update port status to error from l2 agent

[Edan David]

Hi all,

It seems today that the ml2 rpc API only supports reporting that a port is 
up\down,
There may be situations when the l2 agent can fail,
For example SR-IOV agent can report failure when configuring a port on the 
wrong physnet.
In these cases we should how would one report port failed status with the rpc 
messages?
Should we add a new rpc call?
Also it's not clear to me why the documentation in the plugins/ml2/rpc.py file
States that the method 'update_device_down'  function is: "Device no longer 
exists on agent", when it stets the port status to down in admin_state_down.

__
OpenStack Development Mailing 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][UI] Port number for frontend app

[Honza Pokorny]

Hello folks,

We've been using port 3000 for the GUI during development and testing.
Now that we're working on packaging and shipping our code, we're
wondering if port 3000 is still the best choice.

Would 3000 conflict with any other services?  Is there a better option?

Thanks

Honza Pokorny

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