[openstack-dev] [Fuel] Support of deployment history in fake Nailgun

[Julia Aranovich]

Hello everyone,

We [Fuel UI team] are working now on UI implementation of deployment
history [1] and deployment graphs [2] features.

For our development process and covering the features by functional tests,
it is critical to extend fake Nailgun with emulation of a real deployment
execution [3].

Now fake Nailgun provides a history with all the tasks in pending status
for a finished deployment. And we expect to get ready/error tasks as well
with task start and end timestamps.
Emulation of a history of running deployment is also needed.

So, is it possible to support the features in fake Nailgun?

Best regards,
Julia

[1] https://blueprints.launchpad.net/fuel/+spec/ui-deployment-history
[2] https://blueprints.launchpad.net/fuel/+spec/ui-custom-graph
[3] https://bugs.launchpad.net/fuel/+bug/1593757
__
OpenStack Development Mailing 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] Opportunity to contribute in OpenStack

[joehuang]

Hello,



Welcome to OpenStack community!



The Tricircle is to provide an OpenStack API gateway and networking automation 
to allow multiple OpenStack instances, spanning in one site or multiple sites 
or in hybrid cloud, to be managed as a single OpenStack cloud. The project is 
aiming at address the challenge of large scale cloud ( Thinking that one AZ in 
Amazon includes 5+ physcial servers) and disributed edge multi-site 
clouds(thinking that how far your end user is to access the service from the 
cloud).



Are you interested in this challenge problem solving project? we have lots 
things to do:



wiki of Tricircle: https://wiki.openstack.org/wiki/Tricircle,

source code: https://github.com/openstack/tricircle

play: 
https://github.com/openstack/tricircle/blob/master/doc/source/installation.rst

todo list: https://etherpad.openstack.org/p/TricircleToDo



Best Regards

Chaoyi Huang (joehuang)


From: Jainesh Patel [jainesh...@gmail.com]
Sent: 08 July 2016 2:08
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Opportunity to contribute in OpenStack

Hello,

We are a group of students that are currently pursuing our undergraduate degree 
in Computer Science from Pune Institute of Computer Technology(PICT), 
Maharashtra, India. We will be graduating in June 2017 and are currently in our 
final year. For our B.E project, we have selected the domain as Cloud Computing 
and would be very interesting to work on OpenStack.

It will be a great learning opportunity for us to work with OpenStack and in 
turn work with you. We would appreciate if you could steer us towards the 
direction of choosing the right topic and working towards culminating a project 
in the same, which would be helpful for the community.

Following are the few details which include information about us, which would 
help you in making an informed decision:

1) Group Name- TheAtom

2) Group Members:
Shubham Mulay ( shubhammu...@gmail.com )
Faizaan Shaikh ( faizaanshai...@gmail.com )
Jainesh Patel ( jainesh...@gmail.com )

3) We have two mentors working with us, who will be guiding throughout the 
process,
Dhruvesh Rathore ( dhruves...@hotmail.com )
Prerit Auti ( prerita...@gmail.com )

4) Development time : 6 to 7 months from Aug '16 to Feb '17.

We would love to hear from you about any ideas that you see fit for us to 
pursue and which are feasible in the specified time frame. Hoping to hear from 
you soon, and thanking you in anticipation.

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

[openstack-dev] [kolla] Stepping down from core

[Michal Rostecki]

Hi,

I'd like to announce that I'm leaving the Kolla core team and I will not 
work on this project anymore (at least in the near future). I'm fully 
focusing on working in Kubernetes upstream directly. That said, I want 
to thank you for working together!


Cheers,
Michal

__
OpenStack Development Mailing 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][nova-docker] Retiring nova-docker project

[Thierry Carrez]

Matt Riedemann wrote:

[...]
Expand the numbers to 6 months and you'll see only 13 commits.

It's surprisingly high in the user survey (page 39):

https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

So I suspect most users/deployments are just running their own forks.


Why ? Is it completely unusable as it stands ? 13 commits in 6 months 
sounds like enough activity to keep something usable (if it was usable 
in the first place). We have a lot of (official) projects and libraries 
with less activity than that :)


I'm not sure we should be retiring an unofficial project if it's usable, 
doesn't have critical security issues and is used by a number of 
people... Now, if it's unusable and abandoned, that's another story.


--
Thierry Carrez (ttx)

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

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

[Angus Salkeld]

On Fri, Jul 8, 2016 at 10:01 AM Michal Rostecki 
wrote:

> Hi,
>
> I'd like to announce that I'm leaving the Kolla core team and I will not
> work on this project anymore (at least in the near future). I'm fully
> focusing on working in Kubernetes upstream directly. That said, I want
> to thank you for working together!
>

Steve: I must do this too (Michal and I are working together upstream in
kubernetes) I just don't have the time to do any reviews in kolla). Thanks
for encouraging us, the kolla-mesos stuff was fun and I learned a lot.

-Angus


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

Re: [openstack-dev] [kolla][horizon] Out of branch horizon plugins?

[Radomir Dopieralski]

Hi,

sorry for late reply. The whole "openstack_dashboard/local/enabled/"
mechanism was inspired by the mechanisms used commonly in Debian and other
distributions to enable/disable plugins. In short, you shouldn't *copy* the
configuration files to the "enabled" directory -- instead you should keep
them with the plugin, and only symlink them there when you actually want
the plugin to be enabled. There is no need for additional logic in the
plugin checking any environment variables and so on.

On Tue, Jul 5, 2016 at 7:57 PM, Fox, Kevin M  wrote:

> I wrote the app-catalog-ui plugin. I was going to bring this up but hadn't
> gotten to it yet. Thanks for bringing it up.
>
> We do package it up in an rpm, so if its installed with the rest of the
> packages it should just work. The horizon compress/collect rpm hook does
> the right thing already. It does cause it to be enabled though, so I was
> thinking, maybe we make a docker environment variable ENABLED_PLUGINS that
> contains a list of plugins to be enabled?
>
> The value of ENABLED_PLUGINS could be written into
> /etc/openstack-dashboard/local-settings.d and the plugins could enable
> themselves based on it?
>
> I'd rather have the horizon container be bigger then needed and have all
> the plugins test/ready to go as needed instead of trying to slide the
> plugins in myself. Its kind of a pain.
>
> Thanks,
> Kevin
> --
> *From:* Dave Walker [em...@daviey.com]
> *Sent:* Sunday, July 03, 2016 1:15 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [kolla][horizon] Out of branch horizon plugins?
>
> Hi,
>
> Whilst writing a Kolla plugin, I noticed some issues with the way Horizon
> is configured in Kolla.
>
> Horizon is increasingly embracing a plugin architecture with UI's and
> Dashboards being maintained outside of Horizon's tree.
>
> These can be found with the type:horizon-plugin tag in
> openstack/governance [0], with 16 projects at current.
>
> This isn't really addressed in Kolla, and is a little awkward to integrate
> as the horizon docker image is pure horizon.
>
> Some projects have a tools/register_plugin.sh which performs the grunt
> work, where as others require a workflow similar to:
>
> cp /path/to/projects/new/panel openstack_dashboard/local/enabled/
> cp /path/to/local/defualt/settings
> openstack_dashboard/local/local_settings.d/
> cp /path/to/*policy.json openstack_dashboard/conf/
> # compress if environment wants it
> ./manage.py collectstatic
> ./manage.py compress
>
> (Separately, it would be nice if this was standardised.. but not the topic
> of this thread)
>
> It would seem logical to pack all of these into the horizon docker image,
> and add a symlink into dashboard/local/enabled via ansible, policy.json and
> default settings with some conditionals if enabled_$service... but this
> will make the horizon docker image larger and more complicated.
>
> What are your thoughts?
>
> [0]
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> --
> Kind Regards,
> Dave Walker
>
> __
> OpenStack Development Mailing 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][nova-docker] Retiring nova-docker project

[Daniel P. Berrange]

On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
> Matt Riedemann wrote:
> > [...]
> > Expand the numbers to 6 months and you'll see only 13 commits.
> > 
> > It's surprisingly high in the user survey (page 39):
> > 
> > https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf
> > 
> > So I suspect most users/deployments are just running their own forks.
> 
> Why ? Is it completely unusable as it stands ? 13 commits in 6 months sounds
> like enough activity to keep something usable (if it was usable in the first
> place). We have a lot of (official) projects and libraries with less
> activity than that :)
> 
> I'm not sure we should be retiring an unofficial project if it's usable,
> doesn't have critical security issues and is used by a number of people...
> Now, if it's unusable and abandoned, that's another story.

Nova explicitly provides *zero* stable APIs for out of tree drivers to
use. Changes to Nova internals will reliably break out of tree drivers
at least once during a development cycle, often more. So you really do
need someone committed to updating out of tree drivers to cope with the
fact that they're using an explicitly unstable API. We actively intend
to keep breaking out of tree drivers as often as suits Nova's best
interests.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components

[Stéphane Albert]

Hi,

On Fri, Jul 08, 2016 at 10:39:57AM +0800, 吕冬兵 wrote:
> Hi Stéphane,
> 
> I got what you mean, I’m sure that CloudKitty can rating by event, but
> I have some other puzzles. Let me generally describe the arch of
> Bilean first
> 
> [events] <—> [rating] <—> [billing]
> 
> When event coming from notification, bilean engine will rating the
> resource according policy and rule. A rule reference to a kind of
> resource(instance, volumes e.g), and a policy consists of several
> rules, different user can use different billing policy). After that
> engine will update user’s rate. Bilean doesn’t have period task to do
> billing work, but triggered by events and period task to do health
> check for users (daily task now). When user’s balance is almost used
> up, bilean engine will notify user.
We don't have the same semantics in CloudKitty but it's pretty similar
in the way rating rules processing is done, except that we don't work on
an user basis but tenant/project basis. We want to change this
limitation and enable the cloud admin to apply rating rules on whatever
level he wants. We'll be happy to have you implement this in CloudKitty.
About your health check, we've got an API on top of the storage and a
way to generate report, you can easily get the current total for a
specific user (1 API call). You can implement this with a simple cron
querying the API with the user_id, and checking if the number is past
your set threshold. It's not directly in the code because it's not our
main goal. Plus it's easily done, the amount of code to create a tool
doing this is minimal:

- Load CloudKitty's SDK
- Request total for an user
- Check threshold
- Custom alarming code

> So you see, Bilean is a closed-loop billing solution, what I mean
> trigger-based billing is not just rating by events, the main thing is
> billing. Does CloudKitty do billing too? And how? If not or has
> different solution about that, force to combine them will make it
> neither fish nor fowl.
We don't do billing per se, but we implement a way to crunch OpenStack
data to get sensible numbers (cost). Billing is out of the scope since
it requires knowledge of the local laws, such as VAT, accounting, etc.
There is a lot of billing solutions out there, and most companies
already have one. It looks like you want to do alarming based on
resource consumption, having a cost if enough.

As far as I understand your use case, I don't see why you need to
reimplement components. There is event support in Ceilometer, if you
need to access events directly you can subscribe to them. CloudKitty is
responsible of rating, Gnocchi of metrics storage. The only tricky part
is the alarming one which if I understand correctly is just a matter of
a few lines of Python code. Or even better an Aodh alarm based on
Gnocchi metrics which is the result of CloudKitty's computation.

If I missed or misunderstood something, feel free to correct me.

I would like to find a way to collaborate on this use case without
scattering efforts on similar projects.

Cheers,
Stéphane

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

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

[Mooney, Sean K]

From: Armando M. [mailto:arma...@gmail.com]
Sent: Tuesday, June 14, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][ovs] The way we deal with MTU



On 13 June 2016 at 22:22, Terry Wilson 
mailto:twil...@redhat.com>> wrote:
> So basically, as long as we try to plug ports with different MTUs into the 
> same bridge, we are utilizing a bug in Open vSwitch, that may break us any 
> time.
>
> I guess our alternatives are:
> - either redesign bridge setup for openvswitch to e.g. maintain a bridge per 
> network;
> - or talk to ovs folks on whether they may support that for us.
>
> I understand the former option is too scary. It opens lots of questions, 
> including upgrade impact since it will obviously introduce a dataplane 
> downtime. That would be a huge shift in paradigm, probably too huge to 
> swallow. The latter option may not fly with vswitch folks. Any better ideas?

I know I've heard from people who'd like to be able to support both
DPDK and non-DPDK workloads on the same node. The current
implementation with a single br-int (and thus datapath) makes that
impossible to pull of with good performance. So there may be other
reasons to consider introducing multiple isolated bridges: MTUs,
datapath_types, etc.

[Mooney, Sean K]
I just noticed this now but I just wanted to share some of the rational as to 
why we explicitly do not support running both datapaths on the same host today.
We experiment with using both datapaths during the juno cycle when we were 
frist upstreaming support for ovs-dpdk.
To efficiently enable both data paths we determined that you would have to 
duplicate all bridges  for each data path otherwise there is a significant 
performance
Penalty that degrades the performance of both datapaths.

The only way to interconnect bridge of different data paths in ovs is to use 
veth pairs. Even in the case of the kernel datapath the use
Of veth pairs is a significant performance hit compared to patchports.  Adding 
a veth interface to the dpdk datapath is very costly from
A dpdk perpective to rx/tx packets as it take significantly more cpu cycles to 
process packet from veth interfaces then dpdk interfaces.

What we determined at the time was to make this configuration work effectively 
you would have to have 2 copies of every bridge  and
Either modify the existing agent significantly or run two copies of the ovs 
agent on the same host.  If you use two agents on the same host
With two configfiles specifying different bridge names e.g. br-int and 
br-int-dpdk  br-tun,br-tun-dpdk and br-ex br-ex-dpdk it should be possible to 
support today.

You might need to make minor changes to the agent and server to ensure the 
agents are both reported separately in the db and
You would need to provide some mechanism to request the use of kernel vhost or 
vhost-user. Unfortunately there is no construct currently in
Neutron that can be used directly for that and also the nova scheduler does not 
currently have any idea regarding the vif-types or networking backend supported 
on each
Compute host.

The scheduler side could be addressed by reusing the resource provider 
framework that jay pipes is working on. In essence each compute node would be a 
provider of vif-types.
When you boot a vm you would also pass a desired vif-type and when nova is 
scheduling it will fileter to only host of that type. When nova asks neutron to 
bind the
Port it would pass the requested vif-type to neutron which would then use it 
for the port binding. Ian wells and I proposed a mechanism for this over the 
last few cycles that
Should be possible to intergrate cleanly with os-vif when nova and neutron have 
both adopted its uses.
https://review.openstack.org/#/c/190917/7/specs/mitaka/approved/nova-neutron-binding-negotiation.rst

while requesting a vif type is somewhat of a leaky abstraction it does not mean 
that you will know what the neutron backend is.
A vhost-user interface for example could be ovs-dpdk or vpp or snabb swtich or 
ovs-fastpath. So while it is leaking the capability
To provide a vhost-user interface it does not leak the implantation which still 
maintains some level of abstraction and flexablity
For an operator. For a tenant other then performance they cannot detect if they 
are using vhost-user or kernel-vhost in any way since they
All they see is a virtiio-net interface in either case.

if there is interest in supporting both datapaths concurrently and people are 
open to having multiple copies of the ovs l2, and possible l3/dhcp agents on 
the same host
then I would be happy to help with that effort but the added complexity and 
operator overhead of managing two copies of the neutron agents on each host is 
why we
have not tried to enable this configuration  to date.


Incidentally this is something that Nova is already capable of handling (ie. 
wiring VM's in different bridges) thanks to [1], and with some minor additions 
as bein

Re: [openstack-dev] [Fuel] It is impossible to queue UpdateDnsmasqTask

[Aleksandr Didenko]

Hi,

well, we have only one DHCP server that serves multiple clusters. Actions
with those multiple clusters may affect DHCP server configuration. So
queueing tasks that change DHCP server configuration seems like a
reasonable way to fix the problem. So options 2 and 3 are much better than
1 or 4.

Regards,
Alex

On Thu, Jul 7, 2016 at 10:59 AM, Georgy Kibardin 
wrote:

> Continuing speaking to myself :)
>
> Option 4 implies that we generate puppet manifest with a set of admin
> networks instead of writing it into hiera. So, we get a two step task
> which, first, generates manifest with unique name and, second, calls puppet
> to apply it.
> However, theres still a problem with this approach. When we almost
> simultaneously delete environments A and B (and A goes a bit earlier)
> astute acknowledges two UpdateDnsmasqTask tasks for execution, however, it
> cannot guarantee that puppet for UpdateDnsmasqTask for env A will be
> executed earlier than for env B. This would lead to incorrect list of admin
> networks by the end of environment deletion.
>
> So the option 4 just doesn't work.
>
> On Wed, Jul 6, 2016 at 11:41 AM, Georgy Kibardin 
> wrote:
>
>> Bulat is suggesting to move with 4. He suggest to merge all actions of
>> UpdateDnsmasqTask into one puppet task. There are three actions: syncing
>> admin network list to heira, dhcp ranges update and cobbler sync. The
>> problem I see with this approach is that current implementation does not
>> suppose passing any additional data to "puppet apply". Cobbler sync seems
>> to be a reasonable part of updating dhcp ranges config.
>>
>> Best,
>> Georgy
>>
>> On Thu, Jun 16, 2016 at 7:25 PM, Georgy Kibardin 
>> wrote:
>>
>>> Hi All,
>>>
>>> Currently we can only run one instance of subj. at time. An attempt to
>>> run second one causes an exception. This behaviour at least may cause a
>>> cluster to stuck forever in "removing" state (reproduces here
>>> https://bugs.launchpad.net/fuel/+bug/1544493) or just produce
>>> incomprehensible "task already running" message. So we need to address the
>>> problem somehow. I see the following ways to fix it:
>>>
>>> 1. Just put the cluster into "error" state which would allow user to
>>> remove it later.
>>>   pros: simple and fixes the problem at hand (#1544493)
>>>   cons: it would be hard to detect "come againg later" situation; quite
>>> a lame behavior: why don't you "come again later" yourself.
>>>
>>> 2. Implement generic queueing in nailgun.
>>> pros: quite simple
>>> cons: it doesn't look like nailgun responsibility
>>>
>>> 3. Implement generic queueing in astute.
>>>pros: this behaviour makes sense for astute.
>>>cons: the implementation would be quite complex, we need to
>>> synchronize execution between separate worker processes.
>>>
>>> 4. Split the task so that each part would work with particular cluster.
>>>pros: we don't extend our execution model
>>>cons: untrivial implementation; no guarantee that we are always able
>>> to split master node tasks on per cluster basis.
>>>
>>> Best,
>>> Georgy
>>>
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova][SR-IOV][pci-passthrough] Reporting pci devices in hypervisor-show

[Murray, Paul (HP Cloud)]

Hi All,

At the moment I am not aware of a nova api call that provides information about 
the pci devices on a host. The most obvious place to put this would be in 
hypervisor-show. I wonder if anyone has made an attempt at this already or if 
there are any reasons for not adding pci information there?

Assuming pci device information was put in hypervisor-show I would be 
interested in how people think it would be presented. There are different types 
of pci device and things like virtual functions and parent device 
relationships. The information should include the allocation status.

If hypervisor-show is not the place for this I would be interested in 
suggestions on where it should go.

Paul

__
OpenStack Development Mailing 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][nova-docker] Retiring nova-docker project

[Amrith Kumar]

Does it make sense that this conversation about the merits of nova-docker be 
had before the retirement is actually initiated. It seems odd that in the face 
of empirical evidence of actual use (user survey) we merely hypothesize that 
people are likely using their own forks and therefore it is fine to retire this 
project.

As ttx indicates there is nothing wrong with a project with low activity. That 
said, if the issue is that nova-docker is not actively maintained and broken, 
then what it needs is contributors not retirement.

-amrith

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Friday, July 08, 2016 5:03 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
> project
> 
> On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
> > Matt Riedemann wrote:
> > > [...]
> > > Expand the numbers to 6 months and you'll see only 13 commits.
> > >
> > > It's surprisingly high in the user survey (page 39):
> > >
> > > https://www.openstack.org/assets/survey/April-2016-User-Survey-
> Report.pdf
> > >
> > > So I suspect most users/deployments are just running their own forks.
> >
> > Why ? Is it completely unusable as it stands ? 13 commits in 6 months
> sounds
> > like enough activity to keep something usable (if it was usable in the
> first
> > place). We have a lot of (official) projects and libraries with less
> > activity than that :)
> >
> > I'm not sure we should be retiring an unofficial project if it's usable,
> > doesn't have critical security issues and is used by a number of
> people...
> > Now, if it's unusable and abandoned, that's another story.
> 
> Nova explicitly provides *zero* stable APIs for out of tree drivers to
> use. Changes to Nova internals will reliably break out of tree drivers
> at least once during a development cycle, often more. So you really do
> need someone committed to updating out of tree drivers to cope with the
> fact that they're using an explicitly unstable API. We actively intend
> to keep breaking out of tree drivers as often as suits Nova's best
> interests.
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Martin André]

On Fri, Jul 8, 2016 at 10:44 AM, Angus Salkeld  wrote:
>
> On Fri, Jul 8, 2016 at 10:01 AM Michal Rostecki 
> wrote:
>>
>> Hi,
>>
>> I'd like to announce that I'm leaving the Kolla core team and I will not
>> work on this project anymore (at least in the near future). I'm fully
>> focusing on working in Kubernetes upstream directly. That said, I want
>> to thank you for working together!
>
>
> Steve: I must do this too (Michal and I are working together upstream in
> kubernetes) I just don't have the time to do any reviews in kolla). Thanks
> for encouraging us, the kolla-mesos stuff was fun and I learned a lot.

/me sadface

Thank you both for all the hard work on kolla-mesos and kolla in
general. Enjoy you new kubernetes adventures.

Martin

> -Angus
>
>>
>>
>> Cheers,
>> Michal
>>
>> __
>> OpenStack Development Mailing 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] [nova][nova-docker] Retiring nova-docker project

[Davanum Srinivas]

Amrith,

A year and few months is sufficient notice:
http://markmail.org/message/geijiljch4yxfcvq

I really really want this to go away. Every time this comes up,
example it came up in Austin too, a few people raise their hands and
then do not show up. (Not saying you will do the same!).

-- Dims

On Fri, Jul 8, 2016 at 7:10 AM, Amrith Kumar  wrote:
> Does it make sense that this conversation about the merits of nova-docker be 
> had before the retirement is actually initiated. It seems odd that in the 
> face of empirical evidence of actual use (user survey) we merely hypothesize 
> that people are likely using their own forks and therefore it is fine to 
> retire this project.
>
> As ttx indicates there is nothing wrong with a project with low activity. 
> That said, if the issue is that nova-docker is not actively maintained and 
> broken, then what it needs is contributors not retirement.
>
> -amrith
>
>> -Original Message-
>> From: Daniel P. Berrange [mailto:berra...@redhat.com]
>> Sent: Friday, July 08, 2016 5:03 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
>> project
>>
>> On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
>> > Matt Riedemann wrote:
>> > > [...]
>> > > Expand the numbers to 6 months and you'll see only 13 commits.
>> > >
>> > > It's surprisingly high in the user survey (page 39):
>> > >
>> > > https://www.openstack.org/assets/survey/April-2016-User-Survey-
>> Report.pdf
>> > >
>> > > So I suspect most users/deployments are just running their own forks.
>> >
>> > Why ? Is it completely unusable as it stands ? 13 commits in 6 months
>> sounds
>> > like enough activity to keep something usable (if it was usable in the
>> first
>> > place). We have a lot of (official) projects and libraries with less
>> > activity than that :)
>> >
>> > I'm not sure we should be retiring an unofficial project if it's usable,
>> > doesn't have critical security issues and is used by a number of
>> people...
>> > Now, if it's unusable and abandoned, that's another story.
>>
>> Nova explicitly provides *zero* stable APIs for out of tree drivers to
>> use. Changes to Nova internals will reliably break out of tree drivers
>> at least once during a development cycle, often more. So you really do
>> need someone committed to updating out of tree drivers to cope with the
>> fact that they're using an explicitly unstable API. We actively intend
>> to keep breaking out of tree drivers as often as suits Nova's best
>> interests.
>>
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
>> :|
>> |: http://libvirt.org  -o- http://virt-manager.org
>> :|
>> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
>> :|
>> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
>> :|
>>
>> __
>> OpenStack Development Mailing 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



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

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

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

[Alonso Hernandez, Rodolfo]

Hello:

I’m working in the egress minimum bandwidth assurance qos policy rule.

I made a POC using the following architecture:

-  Every time a new rule is created and assigned to a port:

o   A new queue is created in OVS.

o   Create/update the qos policy (OVS database) in all other ports in br-int 
(assigned to the same vlan), br-tun and br-phy, updating the queue value.

o   Set the queue id to the incoming traffic to the OVS.

-  Every time rule is updated:

o   The values are updated in the ovs database.

-  Every time a rule is unassigned to a port:

o   The queue is removed from the qos policies. (OVS database)

o   The OVS rule to set the queue id is removed.

The problem is, based on the neutron extensions API, I can’t make any updates 
in other ports affected by this rule. That means, for example: if I create a 
new port, this port must have also a qos assigned (OVS database) using the 
existing queue. But because the Neutron qos rule doesn’t apply to this port, no 
qos agent function is called and this port is not correctly configured.

Any good idea to solve this problem?

Maybe the idea of creating veth ports could be easy (although the performance 
could be reduced).

Now I’m in a deadpoint.

Regards.


From: Alonso Hernandez, Rodolfo [mailto:rodolfo.alonso.hernan...@intel.com]
Sent: Friday, June 24, 2016 10:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

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

Hello:

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

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

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

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

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

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

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

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

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

Regards.


From: Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
Sent: Tuesday, June 21, 2016 10:27 AM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance


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

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

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

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.
It seems that this scenario doesn't expect some scenarios like DVR and multiple 
NIC. I thought that the queue should be set in br-int with veth(instead of 
patch port) between br-int and bt-tun. However, I guess that this may occur a 
issue that traffic cannot turn back in br-int. That may happen in Scenario2 
case.

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



Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-int.
A) One qo

Re: [openstack-dev] [puppet] Request to add puppet-dpdk module

[Emilien Macchi]

On Fri, Jul 8, 2016 at 2:33 AM, Saravanan KR  wrote:
> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk
> related changes including puppet. We considered both (puppet-vswitch
> and networking-ovs-dpdk).
>
> And we had chat with Emilien about this. His suggestion is to have it
> as a separate project to make the modules cleaner like 'puppet-dpdk'.

Right, either way would work for me with a slight preference for 1):
1) Try to re-use openstack/puppet-vswitch to add dpdk bits (could be fast)
2) Move your module to Puppet OpenStack tent (lot of process)

Looking at the code:
https://github.com/krsacme/puppet-dpdk/blob/master/manifests/config.pp

I honestly thing option 1) is simpler for everyone. You could add a
vswitch::dpdk class in puppet-vswitch with your bits, and that's it.

What do you think?

> Regards,
> Saravanan KR
>
> [1] https://github.com/openstack/networking-ovs-dpdk
>
> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:
>>
>>
>> On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:
>>>
>>> Hello,
>>>
>>> We are working on blueprint [1] to integrate DPDK with tripleo. In the
>>> process, we are planning to add a new puppet module "puppet-dpdk" for the
>>> required puppet changes.
>>>
>>> The initial version of the repository is at github [2]. Note that the
>>> changes are
>>> not
>>> complete yet. It is in progress.
>>>
>>> Please let us know your views on including this new module.
>>>
>>> Regards,
>>> Saravanan KR
>>>
>>> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
>>> [2] https://github.com/krsacme/puppet-dpdk
>>
>>
>> I took a quick look at Emilien's request.  In general, including this
>> functionality in the puppet openstack project makes sense to me.
>>
>> It looks like this is installing and configuring openvswitch-dpdk.  Have you
>> considered integrating DPDK awareness into the existing puppet-vswitch that
>> configures openvswitch?  Why is a separate puppet-dpdk needed?
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>



-- 
Emilien Macchi

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

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Amrith Kumar]

Did not realize that; I withdraw my request. You are correct; 12 months+ is 
fair warning.

-amrith

P.S. I volunteered (in Ann Arbor) to work with you and contribute to 
nova-docker but I guess that's now moot; it'd have been fun :)

> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: Friday, July 08, 2016 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
> project
> 
> Amrith,
> 
> A year and few months is sufficient notice:
> http://markmail.org/message/geijiljch4yxfcvq
> 
> I really really want this to go away. Every time this comes up,
> example it came up in Austin too, a few people raise their hands and
> then do not show up. (Not saying you will do the same!).
> 
> -- Dims
> 
> On Fri, Jul 8, 2016 at 7:10 AM, Amrith Kumar  wrote:
> > Does it make sense that this conversation about the merits of nova-
> docker be had before the retirement is actually initiated. It seems odd
> that in the face of empirical evidence of actual use (user survey) we
> merely hypothesize that people are likely using their own forks and
> therefore it is fine to retire this project.
> >
> > As ttx indicates there is nothing wrong with a project with low
> activity. That said, if the issue is that nova-docker is not actively
> maintained and broken, then what it needs is contributors not retirement.
> >
> > -amrith
> >
> >> -Original Message-
> >> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> >> Sent: Friday, July 08, 2016 5:03 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
> >> project
> >>
> >> On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
> >> > Matt Riedemann wrote:
> >> > > [...]
> >> > > Expand the numbers to 6 months and you'll see only 13 commits.
> >> > >
> >> > > It's surprisingly high in the user survey (page 39):
> >> > >
> >> > > https://www.openstack.org/assets/survey/April-2016-User-Survey-
> >> Report.pdf
> >> > >
> >> > > So I suspect most users/deployments are just running their own
> forks.
> >> >
> >> > Why ? Is it completely unusable as it stands ? 13 commits in 6 months
> >> sounds
> >> > like enough activity to keep something usable (if it was usable in
> the
> >> first
> >> > place). We have a lot of (official) projects and libraries with less
> >> > activity than that :)
> >> >
> >> > I'm not sure we should be retiring an unofficial project if it's
> usable,
> >> > doesn't have critical security issues and is used by a number of
> >> people...
> >> > Now, if it's unusable and abandoned, that's another story.
> >>
> >> Nova explicitly provides *zero* stable APIs for out of tree drivers to
> >> use. Changes to Nova internals will reliably break out of tree drivers
> >> at least once during a development cycle, often more. So you really do
> >> need someone committed to updating out of tree drivers to cope with the
> >> fact that they're using an explicitly unstable API. We actively intend
> >> to keep breaking out of tree drivers as often as suits Nova's best
> >> interests.
> >>
> >> Regards,
> >> Daniel
> >> --
> >> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/
> >> :|
> >> |: http://libvirt.org  -o- http://virt-
> manager.org
> >> :|
> >> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/
> >> :|
> >> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-
> vnc
> >> :|
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Request to add puppet-dpdk module

[Saravanan KR]

Thanks Emilien. I definitely agree with the preference for (1). It is
simpler in choosing either vswitch::ovs or vswitch::dpdk for the
deployment.

Regards,
Saravanan KR

On Fri, Jul 8, 2016 at 5:15 PM, Emilien Macchi  wrote:
> On Fri, Jul 8, 2016 at 2:33 AM, Saravanan KR  wrote:
>> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk
>> related changes including puppet. We considered both (puppet-vswitch
>> and networking-ovs-dpdk).
>>
>> And we had chat with Emilien about this. His suggestion is to have it
>> as a separate project to make the modules cleaner like 'puppet-dpdk'.
>
> Right, either way would work for me with a slight preference for 1):
> 1) Try to re-use openstack/puppet-vswitch to add dpdk bits (could be fast)
> 2) Move your module to Puppet OpenStack tent (lot of process)
>
> Looking at the code:
> https://github.com/krsacme/puppet-dpdk/blob/master/manifests/config.pp
>
> I honestly thing option 1) is simpler for everyone. You could add a
> vswitch::dpdk class in puppet-vswitch with your bits, and that's it.
>
> What do you think?
>
>> Regards,
>> Saravanan KR
>>
>> [1] https://github.com/openstack/networking-ovs-dpdk
>>
>> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:
>>>
>>>
>>> On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:

 Hello,

 We are working on blueprint [1] to integrate DPDK with tripleo. In the
 process, we are planning to add a new puppet module "puppet-dpdk" for the
 required puppet changes.

 The initial version of the repository is at github [2]. Note that the
 changes are
 not
 complete yet. It is in progress.

 Please let us know your views on including this new module.

 Regards,
 Saravanan KR

 [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
 [2] https://github.com/krsacme/puppet-dpdk
>>>
>>>
>>> I took a quick look at Emilien's request.  In general, including this
>>> functionality in the puppet openstack project makes sense to me.
>>>
>>> It looks like this is installing and configuring openvswitch-dpdk.  Have you
>>> considered integrating DPDK awareness into the existing puppet-vswitch that
>>> configures openvswitch?  Why is a separate puppet-dpdk needed?
>>>
>>> --
>>> Russell Bryant
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>
>
>
> --
> Emilien Macchi

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

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Ed Leafe]

On Jul 7, 2016, at 11:37 PM, Joshua Harlow  wrote:

> Then can we get 
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2514finally
>  adjusted to be what it really is... instead of what it really isn't...

I would be in favor of updating that statement.


-- Ed Leafe






__
OpenStack Development Mailing 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] Request to add puppet-dpdk module

[Emilien Macchi]

On Fri, Jul 8, 2016 at 8:18 AM, Saravanan KR  wrote:
> Thanks Emilien. I definitely agree with the preference for (1). It is
> simpler in choosing either vswitch::ovs or vswitch::dpdk for the
> deployment.

Cool, /me looking forward to see the patch, I'll help you to get it merged asap.

> Regards,
> Saravanan KR
>
> On Fri, Jul 8, 2016 at 5:15 PM, Emilien Macchi  wrote:
>> On Fri, Jul 8, 2016 at 2:33 AM, Saravanan KR  wrote:
>>> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk
>>> related changes including puppet. We considered both (puppet-vswitch
>>> and networking-ovs-dpdk).
>>>
>>> And we had chat with Emilien about this. His suggestion is to have it
>>> as a separate project to make the modules cleaner like 'puppet-dpdk'.
>>
>> Right, either way would work for me with a slight preference for 1):
>> 1) Try to re-use openstack/puppet-vswitch to add dpdk bits (could be fast)
>> 2) Move your module to Puppet OpenStack tent (lot of process)
>>
>> Looking at the code:
>> https://github.com/krsacme/puppet-dpdk/blob/master/manifests/config.pp
>>
>> I honestly thing option 1) is simpler for everyone. You could add a
>> vswitch::dpdk class in puppet-vswitch with your bits, and that's it.
>>
>> What do you think?
>>
>>> Regards,
>>> Saravanan KR
>>>
>>> [1] https://github.com/openstack/networking-ovs-dpdk
>>>
>>> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:


 On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:
>
> Hello,
>
> We are working on blueprint [1] to integrate DPDK with tripleo. In the
> process, we are planning to add a new puppet module "puppet-dpdk" for the
> required puppet changes.
>
> The initial version of the repository is at github [2]. Note that the
> changes are
> not
> complete yet. It is in progress.
>
> Please let us know your views on including this new module.
>
> Regards,
> Saravanan KR
>
> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
> [2] https://github.com/krsacme/puppet-dpdk


 I took a quick look at Emilien's request.  In general, including this
 functionality in the puppet openstack project makes sense to me.

 It looks like this is installing and configuring openvswitch-dpdk.  Have 
 you
 considered integrating DPDK awareness into the existing puppet-vswitch that
 configures openvswitch?  Why is a separate puppet-dpdk needed?

 --
 Russell Bryant

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

>>
>>
>>
>> --
>> Emilien Macchi



-- 
Emilien Macchi

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

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

[Ryan Hallisey]

Angus and Michal,

Thanks for your hard work! I hope our paths will cross again in the future.

Good luck!
Ryan

- Original Message -
From: "Martin André" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, July 8, 2016 7:34:27 AM
Subject: Re: [openstack-dev] [kolla] Stepping down from core

On Fri, Jul 8, 2016 at 10:44 AM, Angus Salkeld  wrote:
>
> On Fri, Jul 8, 2016 at 10:01 AM Michal Rostecki 
> wrote:
>>
>> Hi,
>>
>> I'd like to announce that I'm leaving the Kolla core team and I will not
>> work on this project anymore (at least in the near future). I'm fully
>> focusing on working in Kubernetes upstream directly. That said, I want
>> to thank you for working together!
>
>
> Steve: I must do this too (Michal and I are working together upstream in
> kubernetes) I just don't have the time to do any reviews in kolla). Thanks
> for encouraging us, the kolla-mesos stuff was fun and I learned a lot.

/me sadface

Thank you both for all the hard work on kolla-mesos and kolla in
general. Enjoy you new kubernetes adventures.

Martin

> -Angus
>
>>
>>
>> Cheers,
>> Michal
>>
>> __
>> OpenStack Development Mailing 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] [nova][nova-docker] Retiring nova-docker project

[Tim Bell]

Given the inconsistency between the user survey and the apparent 
utilization/maintenance, I’d recommend checking on the openstack-operators list 
to see if this would be a major issue.

Tim

On 08/07/16 13:54, "Amrith Kumar"  wrote:

Did not realize that; I withdraw my request. You are correct; 12 months+ is 
fair warning.

-amrith

P.S. I volunteered (in Ann Arbor) to work with you and contribute to 
nova-docker but I guess that's now moot; it'd have been fun :)

> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: Friday, July 08, 2016 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
> project
> 
> Amrith,
> 
> A year and few months is sufficient notice:
> http://markmail.org/message/geijiljch4yxfcvq
> 
> I really really want this to go away. Every time this comes up,
> example it came up in Austin too, a few people raise their hands and
> then do not show up. (Not saying you will do the same!).
> 
> -- Dims
> 
> On Fri, Jul 8, 2016 at 7:10 AM, Amrith Kumar  wrote:
> > Does it make sense that this conversation about the merits of nova-
> docker be had before the retirement is actually initiated. It seems odd
> that in the face of empirical evidence of actual use (user survey) we
> merely hypothesize that people are likely using their own forks and
> therefore it is fine to retire this project.
> >
> > As ttx indicates there is nothing wrong with a project with low
> activity. That said, if the issue is that nova-docker is not actively
> maintained and broken, then what it needs is contributors not retirement.
> >
> > -amrith
> >
> >> -Original Message-
> >> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> >> Sent: Friday, July 08, 2016 5:03 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
> >> project
> >>
> >> On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
> >> > Matt Riedemann wrote:
> >> > > [...]
> >> > > Expand the numbers to 6 months and you'll see only 13 commits.
> >> > >
> >> > > It's surprisingly high in the user survey (page 39):
> >> > >
> >> > > https://www.openstack.org/assets/survey/April-2016-User-Survey-
> >> Report.pdf
> >> > >
> >> > > So I suspect most users/deployments are just running their own
> forks.
> >> >
> >> > Why ? Is it completely unusable as it stands ? 13 commits in 6 months
> >> sounds
> >> > like enough activity to keep something usable (if it was usable in
> the
> >> first
> >> > place). We have a lot of (official) projects and libraries with less
> >> > activity than that :)
> >> >
> >> > I'm not sure we should be retiring an unofficial project if it's
> usable,
> >> > doesn't have critical security issues and is used by a number of
> >> people...
> >> > Now, if it's unusable and abandoned, that's another story.
> >>
> >> Nova explicitly provides *zero* stable APIs for out of tree drivers to
> >> use. Changes to Nova internals will reliably break out of tree drivers
> >> at least once during a development cycle, often more. So you really do
> >> need someone committed to updating out of tree drivers to cope with the
> >> fact that they're using an explicitly unstable API. We actively intend
> >> to keep breaking out of tree drivers as often as suits Nova's best
> >> interests.
> >>
> >> Regards,
> >> Daniel
> >> --
> >> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/
> >> :|
> >> |: http://libvirt.org  -o- http://virt-
> manager.org
> >> :|
> >> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/
> >> :|
> >> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-
> vnc
> >> :|
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [puppet][networking-ovs-dpdk] Request to add puppet-dpdk module

[Mooney, Sean K]

Is there a reason that you are starting a new project instead of contributing to
The networking-ovs-dpdk puppet module?

Networking-ovs-dpdk was created to host both the integration code with neutron 
and then deployment tool
Support for deploying ovs with dpdk for differnet tools.

Currently we support devstack and we have developed a puppet module.
The puppet module was developed with the express intention of integrating it 
with 
Fuel, packstack and trippleo at a later date. It was created to be a reusable 
module for
Other tools to use and build on top of.

I will be working on kolla support upstream in kolla this cycle with 
networking-ovs-dpdk providing
Source install support in addition the binary install support that will be 
submitted to kolla.

A fule plugin(developed in opnfv) was planned to be added to this repo but that 
has now been
Abandoned as support is been added to fuel core instead.

If there is a good technical reason for a separate repo then that is ok but 
otherwise it
Seams wasteful to start another project to develop a puppet module to install 
ovs with dpdk.

Are there any featues missing form netoworking-ovs-dpdk puppet module that you 
require?
it should be noted that we will be adding support for binary installs from 
package manages
and persistent installs (auto loading kernel driver, persistent binding of 
nics) this cycle but if you have
any other feature gaps we would be happy to hear about them.

Regards
Sean.
 



> -Original Message-
> From: Saravanan KR [mailto:skram...@redhat.com]
> Sent: Friday, July 08, 2016 8:33 AM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Cc: Emilien Macchi ; Jaganathan Palanisamy
> ; Vijay Chundury 
> Subject: Re: [openstack-dev] [puppet] Request to add puppet-dpdk module
> 
> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk related
> changes including puppet. We considered both (puppet-vswitch and networking-
> ovs-dpdk).
> 
> And we had chat with Emilien about this. His suggestion is to have it as a 
> separate
> project to make the modules cleaner like 'puppet-dpdk'.
> 
> Regards,
> Saravanan KR
> 
> [1] https://github.com/openstack/networking-ovs-dpdk
> 
> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:
> >
> >
> > On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:
> >>
> >> Hello,
> >>
> >> We are working on blueprint [1] to integrate DPDK with tripleo. In
> >> the process, we are planning to add a new puppet module "puppet-dpdk"
> >> for the required puppet changes.
> >>
> >> The initial version of the repository is at github [2]. Note that the
> >> changes are not complete yet. It is in progress.
> >>
> >> Please let us know your views on including this new module.
> >>
> >> Regards,
> >> Saravanan KR
> >>
> >> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
> >> [2] https://github.com/krsacme/puppet-dpdk
> >
> >
> > I took a quick look at Emilien's request.  In general, including this
> > functionality in the puppet openstack project makes sense to me.
> >
> > It looks like this is installing and configuring openvswitch-dpdk.
> > Have you considered integrating DPDK awareness into the existing
> > puppet-vswitch that configures openvswitch?  Why is a separate puppet-dpdk
> needed?
> >
> > --
> > Russell Bryant
> >
> >
> __
> 
> >  OpenStack Development Mailing 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] Hangzhou Bug Smash ended

[Liyongle (Fred)]

Hi all,

The 4th China OpenStack Bug Smash just ended in Hangzhou, China. 141 bugs were 
fixed and 50 of them have been merged. The rest will be merged in the coming 
weeks. 

Thanks to all who support us locally and remotely. See you in next Bug Smash in 
Shenzhen, China. 

Best Regards

Fred (李永乐)

-Original Message-
From: Liyongle (Fred) 
Sent: 2016年7月5日 23:13
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: [openstack-dev] Hangzhou Bug Smash will be held from July 6 to 8

Hi OpenStackers,

The 4th China OpenStack Bug Smash will start on July 6 in Hangzhou, Beijing 
Time. Please find this bug smash home page at [1], and the bugs list in [2].

[1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Newton-Hangzhou
[2] https://etherpad.openstack.org/p/hackathon4_all_list

Fred (李永乐)

-Original Message-
From: Liyongle (Fred) 
Sent: 2016年6月30日 23:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Hangzhou Bug Smash will be held from July 6 to 8

Hi OpenStackers,

The 4th China OpenStack Bug Smash, hosted by CESI, Huawei, and intel, will be 
held in Hangzhou, China from July 6 to 8 (Beijing time), from 01:00 July 6 to 
6:00 July 8 UTC. And the target to get bugs fixed before the milestone newton-2 
 [1].

Around 50 stackers will fix the bugs in nova, cinder, neutron, magnum, 
ceilometer, heat, ironic, smaug, freezer, oslo, murano and kolla. You are 
appreciated to provide any support, or work remotely with the team. 

Please find this bug smash home page at [2], and the bugs list in [3] (under 
preparation). 

[1] http://releases.openstack.org/newton/schedule.html
[2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Newton-Hangzhou
[3] https://etherpad.openstack.org/p/hackathon4_all_list

Best Regards

Fred (李永乐)

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

Re: [openstack-dev] [puppet][networking-ovs-dpdk] Request to add puppet-dpdk module

[Emilien Macchi]

On Fri, Jul 8, 2016 at 9:29 AM, Mooney, Sean K  wrote:
> Is there a reason that you are starting a new project instead of contributing 
> to
> The networking-ovs-dpdk puppet module?
>
> Networking-ovs-dpdk was created to host both the integration code with 
> neutron and then deployment tool
> Support for deploying ovs with dpdk for differnet tools.

That is the wrong way to do imho.

Puppet modules, Ansible playbooks, Chef cookbooks, etc. Are external
to the repository because they run their own CI and libraries, etc.
Moving our the Puppet code is an excellent idea and follows OpenStack
conventions:
http://governance.openstack.org/reference/projects/puppet-openstack.html

Where we have one Puppet module per component.
In the case of dpdk, I would even suggest to not create a new project
and add the 20 lines of code (yeah, all this discussion for 20 lines
of code [1]) into openstack/puppet-vswitch.

[1] https://github.com/krsacme/puppet-dpdk/blob/master/manifests/config.pp


Let me know if you need help for the move,
Thanks.

> Currently we support devstack and we have developed a puppet module.
> The puppet module was developed with the express intention of integrating it 
> with
> Fuel, packstack and trippleo at a later date. It was created to be a reusable 
> module for
> Other tools to use and build on top of.
>
> I will be working on kolla support upstream in kolla this cycle with 
> networking-ovs-dpdk providing
> Source install support in addition the binary install support that will be 
> submitted to kolla.
>
> A fule plugin(developed in opnfv) was planned to be added to this repo but 
> that has now been
> Abandoned as support is been added to fuel core instead.
>
> If there is a good technical reason for a separate repo then that is ok but 
> otherwise it
> Seams wasteful to start another project to develop a puppet module to install 
> ovs with dpdk.
>
> Are there any featues missing form netoworking-ovs-dpdk puppet module that 
> you require?
> it should be noted that we will be adding support for binary installs from 
> package manages
> and persistent installs (auto loading kernel driver, persistent binding of 
> nics) this cycle but if you have
> any other feature gaps we would be happy to hear about them.
>
> Regards
> Sean.
>
>
>
>
>> -Original Message-
>> From: Saravanan KR [mailto:skram...@redhat.com]
>> Sent: Friday, July 08, 2016 8:33 AM
>> To: OpenStack Development Mailing List (not for usage questions) > d...@lists.openstack.org>
>> Cc: Emilien Macchi ; Jaganathan Palanisamy
>> ; Vijay Chundury 
>> Subject: Re: [openstack-dev] [puppet] Request to add puppet-dpdk module
>>
>> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk related
>> changes including puppet. We considered both (puppet-vswitch and networking-
>> ovs-dpdk).
>>
>> And we had chat with Emilien about this. His suggestion is to have it as a 
>> separate
>> project to make the modules cleaner like 'puppet-dpdk'.
>>
>> Regards,
>> Saravanan KR
>>
>> [1] https://github.com/openstack/networking-ovs-dpdk
>>
>> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:
>> >
>> >
>> > On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:
>> >>
>> >> Hello,
>> >>
>> >> We are working on blueprint [1] to integrate DPDK with tripleo. In
>> >> the process, we are planning to add a new puppet module "puppet-dpdk"
>> >> for the required puppet changes.
>> >>
>> >> The initial version of the repository is at github [2]. Note that the
>> >> changes are not complete yet. It is in progress.
>> >>
>> >> Please let us know your views on including this new module.
>> >>
>> >> Regards,
>> >> Saravanan KR
>> >>
>> >> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
>> >> [2] https://github.com/krsacme/puppet-dpdk
>> >
>> >
>> > I took a quick look at Emilien's request.  In general, including this
>> > functionality in the puppet openstack project makes sense to me.
>> >
>> > It looks like this is installing and configuring openvswitch-dpdk.
>> > Have you considered integrating DPDK awareness into the existing
>> > puppet-vswitch that configures openvswitch?  Why is a separate puppet-dpdk
>> needed?
>> >
>> > --
>> > Russell Bryant
>> >
>> >
>> __
>> 
>> >  OpenStack Development Mailing 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

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

[Davanum Srinivas]

Tim,

I've initiated conversation a couple of times more than a year ago.

http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7129
http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7006

Thanks,
Dims


On Fri, Jul 8, 2016 at 9:10 AM, Tim Bell  wrote:
> Given the inconsistency between the user survey and the apparent 
> utilization/maintenance, I’d recommend checking on the openstack-operators 
> list to see if this would be a major issue.
>
> Tim
>
> On 08/07/16 13:54, "Amrith Kumar"  wrote:
>
> Did not realize that; I withdraw my request. You are correct; 12 months+ is 
> fair warning.
>
> -amrith
>
> P.S. I volunteered (in Ann Arbor) to work with you and contribute to 
> nova-docker but I guess that's now moot; it'd have been fun :)
>
>> -Original Message-
>> From: Davanum Srinivas [mailto:dava...@gmail.com]
>> Sent: Friday, July 08, 2016 7:32 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
>> project
>>
>> Amrith,
>>
>> A year and few months is sufficient notice:
>> http://markmail.org/message/geijiljch4yxfcvq
>>
>> I really really want this to go away. Every time this comes up,
>> example it came up in Austin too, a few people raise their hands and
>> then do not show up. (Not saying you will do the same!).
>>
>> -- Dims
>>
>> On Fri, Jul 8, 2016 at 7:10 AM, Amrith Kumar  wrote:
>> > Does it make sense that this conversation about the merits of nova-
>> docker be had before the retirement is actually initiated. It seems odd
>> that in the face of empirical evidence of actual use (user survey) we
>> merely hypothesize that people are likely using their own forks and
>> therefore it is fine to retire this project.
>> >
>> > As ttx indicates there is nothing wrong with a project with low
>> activity. That said, if the issue is that nova-docker is not actively
>> maintained and broken, then what it needs is contributors not retirement.
>> >
>> > -amrith
>> >
>> >> -Original Message-
>> >> From: Daniel P. Berrange [mailto:berra...@redhat.com]
>> >> Sent: Friday, July 08, 2016 5:03 AM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> 
>> >> Subject: Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker
>> >> project
>> >>
>> >> On Fri, Jul 08, 2016 at 10:11:59AM +0200, Thierry Carrez wrote:
>> >> > Matt Riedemann wrote:
>> >> > > [...]
>> >> > > Expand the numbers to 6 months and you'll see only 13 commits.
>> >> > >
>> >> > > It's surprisingly high in the user survey (page 39):
>> >> > >
>> >> > > https://www.openstack.org/assets/survey/April-2016-User-Survey-
>> >> Report.pdf
>> >> > >
>> >> > > So I suspect most users/deployments are just running their own
>> forks.
>> >> >
>> >> > Why ? Is it completely unusable as it stands ? 13 commits in 6 months
>> >> sounds
>> >> > like enough activity to keep something usable (if it was usable in
>> the
>> >> first
>> >> > place). We have a lot of (official) projects and libraries with less
>> >> > activity than that :)
>> >> >
>> >> > I'm not sure we should be retiring an unofficial project if it's
>> usable,
>> >> > doesn't have critical security issues and is used by a number of
>> >> people...
>> >> > Now, if it's unusable and abandoned, that's another story.
>> >>
>> >> Nova explicitly provides *zero* stable APIs for out of tree drivers to
>> >> use. Changes to Nova internals will reliably break out of tree drivers
>> >> at least once during a development cycle, often more. So you really do
>> >> need someone committed to updating out of tree drivers to cope with the
>> >> fact that they're using an explicitly unstable API. We actively intend
>> >> to keep breaking out of tree drivers as often as suits Nova's best
>> >> interests.
>> >>
>> >> Regards,
>> >> Daniel
>> >> --
>> >> |: http://berrange.com  -o-
>> http://www.flickr.com/photos/dberrange/
>> >> :|
>> >> |: http://libvirt.org  -o- http://virt-
>> manager.org
>> >> :|
>> >> |: http://autobuild.org   -o-
>> http://search.cpan.org/~danberr/
>> >> :|
>> >> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-
>> vnc
>> >> :|
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing 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
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 

[openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[ChangBo Guo]

Hi ALL,

I have been working a bug [1] about option value interpolation in
oslo.config[2], in short, option value interpolation can't handle password
containing special characters from environment variable and I  proposed a
fix of provide way to forbid option value interpolation explicitly[3].

copy of Doug Hellmann's coments:

"The problem is that the end user who is setting the value of the option
cannot control whether the option will do interpolation or not. So the
programmer who defines the option has to make that choice, and then we
can't change it because that would break existing deployments. The result
is that end users won't know for any given option whether interpolation
works or not, and if not why (did they do something wrong, or is it not
supported).

I've set -2 on this patch because I think it's a bad approach. I see 2
other ways we could solve the problem you describe (and I agree that it's
an issue we should help with).

1. We could have an option that turns off interpolation globally, and let
the user control that by setting the flag in their configuration file. I'm
not sure I like this, but it does give you what you're looking for at the
risk of breaking applications that are relying on interpolation, like the
nova example.

2. We could disable interpolation when we get values from environment
variables. That would be a big behavioral change, so we would need to think
about how to roll it out carefully. For example, do we provide a helper
function to give to application developers who are setting default values
to environment variables so the variable value can be escaped to avoid
interpolation? Or do we build it into the Opt class somehow? I think I like
the helper function approach but we should give it more thought."
I would like to collect more suggestions to decide the direction to fix
similar bug. Any thoughts ?

[1]https://bugs.launchpad.net/oslo.config/+bug/1577731
[2]
http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
[3]https://review.openstack.org/#/c/338668/


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] v2 API workgroup meeting begins July 12

[Jim Rollenhagen]

Hey all,

I had an action item from the midcycle to kickstart a workgroup for the
v2 API. I've set up a meeting for that on Tuesdays at 1800 UTC in
#openstack-meeting-3:

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

All who are interested are welcome to join.

By the way, we wouldn't mind some help from the general API working
group, so if one of y'all has time to join us, that would be great. :)

Thanks!

// 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] [neutron][linux bridge]

[Édouard Thuleau]

Hi,

I'm not close to Neutron's discussions but do you think to have a look at
pyroute2 [1]?
"Pyroute2 is a pure Python netlink and Linux network configuration library.
It requires only Python stdlib, no 3rd party libraries."
Which permits to create bridge and adding interfaces easily [2] (but not
only...).

[1] https://github.com/svinota/pyroute2
[2]
https://github.com/svinota/pyroute2/blob/a76d2efd8966ec5b6cc713dc5d909b5cd070a9a8/benchmark/ipdb.py#L16

On Fri, Jul 8, 2016 at 8:05 AM, Brandon Logan 
wrote:

> pybrctl repo is at: https://github.com/udragon/pybrctl
> It is in pypi.
>
> Looks like a wrapper around the shell brctl commands.  I don't think it
> would buy us anything more than what moving neutron's current
> implementation of doing brctl commands to neutron-lib would do.  In
> fact, it might end up costing more.  That's just my very uninformed
> opinion though.
>
> Thanks,
> Brandon
>
> On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote:
> > Hi,
> >
> > There is work in progress for pure python driven linux network
> > configuration. I think most
> > of work will be done with this patch https://review.openstack.org/#/c
> > /155631/ . The only
> > thing left after this will be linux bridge configuration, Which I
> > would like to discuss with
> > community. There are two ways at the moment I can think to do that
> > implementation,
> > First, use pybrctl which may need some changes in library itself in
> > order for full support.
> > It will clean up the code from neutron. But looking pybrctl code
> > which is just executing
> > Shell commands, another solution which Brandon Logan discussed is
> > move the existing
> > Code for executing those commands to neutron-lib, which I think is
> > better solution. I would
> > like to have views of community, especially people working neutron-
> > lib about moving
> > python code for executing brctl commands to neutron-lib.
> >
> >
> > Thanks and Regards !
> > Manjeet Singh Bhatia
> __
> OpenStack Development Mailing 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] [puppet][networking-ovs-dpdk] Request to add puppet-dpdk module

[Saravanan KR]

Just to add a point, we are *still* working on dpdk. And this is not
the final code. It may grow a little. We are looking in to adaption
networking-ovs-dpdk puppet code into the agreeable format as
vswitch::dpdk. We would be glad to work with Sean in this process.

Regards,
Saravanan KR

On Fri, Jul 8, 2016 at 7:20 PM, Emilien Macchi  wrote:
> On Fri, Jul 8, 2016 at 9:29 AM, Mooney, Sean K  
> wrote:
>> Is there a reason that you are starting a new project instead of 
>> contributing to
>> The networking-ovs-dpdk puppet module?
>>
>> Networking-ovs-dpdk was created to host both the integration code with 
>> neutron and then deployment tool
>> Support for deploying ovs with dpdk for differnet tools.
>
> That is the wrong way to do imho.
>
> Puppet modules, Ansible playbooks, Chef cookbooks, etc. Are external
> to the repository because they run their own CI and libraries, etc.
> Moving our the Puppet code is an excellent idea and follows OpenStack
> conventions:
> http://governance.openstack.org/reference/projects/puppet-openstack.html
>
> Where we have one Puppet module per component.
> In the case of dpdk, I would even suggest to not create a new project
> and add the 20 lines of code (yeah, all this discussion for 20 lines
> of code [1]) into openstack/puppet-vswitch.
>
> [1] https://github.com/krsacme/puppet-dpdk/blob/master/manifests/config.pp
>
>
> Let me know if you need help for the move,
> Thanks.
>
>> Currently we support devstack and we have developed a puppet module.
>> The puppet module was developed with the express intention of integrating it 
>> with
>> Fuel, packstack and trippleo at a later date. It was created to be a 
>> reusable module for
>> Other tools to use and build on top of.
>>
>> I will be working on kolla support upstream in kolla this cycle with 
>> networking-ovs-dpdk providing
>> Source install support in addition the binary install support that will be 
>> submitted to kolla.
>>
>> A fule plugin(developed in opnfv) was planned to be added to this repo but 
>> that has now been
>> Abandoned as support is been added to fuel core instead.
>>
>> If there is a good technical reason for a separate repo then that is ok but 
>> otherwise it
>> Seams wasteful to start another project to develop a puppet module to 
>> install ovs with dpdk.
>>
>> Are there any featues missing form netoworking-ovs-dpdk puppet module that 
>> you require?
>> it should be noted that we will be adding support for binary installs from 
>> package manages
>> and persistent installs (auto loading kernel driver, persistent binding of 
>> nics) this cycle but if you have
>> any other feature gaps we would be happy to hear about them.
>>
>> Regards
>> Sean.
>>
>>
>>
>>
>>> -Original Message-
>>> From: Saravanan KR [mailto:skram...@redhat.com]
>>> Sent: Friday, July 08, 2016 8:33 AM
>>> To: OpenStack Development Mailing List (not for usage questions) >> d...@lists.openstack.org>
>>> Cc: Emilien Macchi ; Jaganathan Palanisamy
>>> ; Vijay Chundury 
>>> Subject: Re: [openstack-dev] [puppet] Request to add puppet-dpdk module
>>>
>>> Also, there is a repository networking-ovs-dpdk[1] for all the dpdk related
>>> changes including puppet. We considered both (puppet-vswitch and networking-
>>> ovs-dpdk).
>>>
>>> And we had chat with Emilien about this. His suggestion is to have it as a 
>>> separate
>>> project to make the modules cleaner like 'puppet-dpdk'.
>>>
>>> Regards,
>>> Saravanan KR
>>>
>>> [1] https://github.com/openstack/networking-ovs-dpdk
>>>
>>> On Fri, Jul 8, 2016 at 2:36 AM, Russell Bryant  wrote:
>>> >
>>> >
>>> > On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> We are working on blueprint [1] to integrate DPDK with tripleo. In
>>> >> the process, we are planning to add a new puppet module "puppet-dpdk"
>>> >> for the required puppet changes.
>>> >>
>>> >> The initial version of the repository is at github [2]. Note that the
>>> >> changes are not complete yet. It is in progress.
>>> >>
>>> >> Please let us know your views on including this new module.
>>> >>
>>> >> Regards,
>>> >> Saravanan KR
>>> >>
>>> >> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
>>> >> [2] https://github.com/krsacme/puppet-dpdk
>>> >
>>> >
>>> > I took a quick look at Emilien's request.  In general, including this
>>> > functionality in the puppet openstack project makes sense to me.
>>> >
>>> > It looks like this is installing and configuring openvswitch-dpdk.
>>> > Have you considered integrating DPDK awareness into the existing
>>> > puppet-vswitch that configures openvswitch?  Why is a separate puppet-dpdk
>>> needed?
>>> >
>>> > --
>>> > Russell Bryant
>>> >
>>> >
>>> __
>>> 
>>> >  OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinf

Re: [openstack-dev] [OpenStack-Ansible] Splitting out generic testing components

[Truman, Travis]

Nice work Andy. I'm strongly in favor of getting the central test repo into 
Gerrit for broader reviews and once done, getting one or two patches up with 
roles making use of it.

- Travis Truman

From: Andy McCrae mailto:andy.mcc...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, June 3, 2016 at 11:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [OpenStack-Ansible] Splitting out generic testing 
components

TL;DR We're doing a PoC to split out common testing plays/vars into a generic 
repository, for the purposes of making in-role testing more uniform and 
generic. Looking for feedback, comments, informal reviews, ideas etc! 
https://github.com/andymcc/openstack-ansible-testing-core (Includes a simple 
README)


We now have a lot of duplication after moving to a single role per repository 
structure with specific testing per role. For example, almost all repositories 
require Galera/Rabbit/Keystone in order to deploy testing successfully. This 
has led to a scenario where each repository essentially carries the same 
deployment code.


Aims:
- The primary aim of extracting the testing infrastructure into a single 
repository is to reduce the cases where a simple change is needed, which 
dominoes, causing a patch to each of 15 repositories. Instead, a change to the 
uniform testing repository would resolve the issue for all other repository's 
testing.
- In the future, we are looking to deploy scenario testing. For example, we may 
want to test glance with a swift backend, or keystone with memcache. If the 
testing play to deploy swift is already in a uniform repository, the changes 
required to get glance testing enabled for that use case would be minimal.
- This allows new projects to consume existing structure/playbooks to deploy 
common components and vars, which should simplify the manner in which new 
openstack-ansible projects set up their testing.


Steps taken so far:
- The deployment plays for each project have been split out into the separate 
testing role.
- Each role only carries a specific "Test project" play.
- The test playbooks have been made generic so it uses the inventory specified 
per repository (defining what hosts/roles there are).
- The test-vars have been put in the testing-repository and moved out of the 
generic role.
- An override file has been created for each project and included using "-e" 
(the highest precedence) but at present, of the 4 projects converted the 
maximum number of overrides used is 2, so these overrides are minimal.
- Adjustments to tox.ini and var files references have been made to use the new 
repository.


Further work to look into:
- It may be worth looking into making the tox.ini more generic, if we were to 
make a sweeping change that impacts on tox.ini we would still need to do 
changes to each repository. (I am not sure on how feasible this is though)


Raised concerns:
- This creates a situation where a change may require me to make a change to 
the central testing repository before changing the role repository. For 
example, in order to get the generic testing for a keystone change I would have 
to change the testing repository in advance, and then change the keystone 
repository. Or override the var, adjust the testing repo and then remove the 
keystone override.
- Changes to the testing-repo can cause all other repo tests (aside from the 
overarching openstack-ansible repository) from breaking.


Where to find the PoC, what next?

The repository can be found here: 
https://github.com/andymcc/openstack-ansible-testing-core

This is a proof of concept so in no way is it considered complete or perfect, 
we are asking for more eyes on this; test it, let us know what you like/do not 
like/want changed/additional ideas to improve.

Thanks!

Andy
irc: andymccr
__
OpenStack Development Mailing 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] [ironic] Input types for scheduler filters

[Miles Gould]

On 07/07/16 17:43, Miles Gould wrote:

Further evidence that this isn't the intended behaviour: if you remove
all the calls to str(), then the original tests still pass, but the
' e' (substring matching) one doesn't.


I've now proposed this as a patch: 
https://review.openstack.org/#/c/339576/ Please review!


Miles

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

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Daniel P. Berrange]

On Fri, Jul 08, 2016 at 10:14:20PM +0800, ChangBo Guo wrote:
> Hi ALL,
> 
> I have been working a bug [1] about option value interpolation in
> oslo.config[2], in short, option value interpolation can't handle password
> containing special characters from environment variable and I  proposed a
> fix of provide way to forbid option value interpolation explicitly[3].
> 
> copy of Doug Hellmann's coments:
> 
> "The problem is that the end user who is setting the value of the option
> cannot control whether the option will do interpolation or not. So the
> programmer who defines the option has to make that choice, and then we
> can't change it because that would break existing deployments. The result
> is that end users won't know for any given option whether interpolation
> works or not, and if not why (did they do something wrong, or is it not
> supported).
> 
> I've set -2 on this patch because I think it's a bad approach. I see 2
> other ways we could solve the problem you describe (and I agree that it's
> an issue we should help with).
> 
> 1. We could have an option that turns off interpolation globally, and let
> the user control that by setting the flag in their configuration file. I'm
> not sure I like this, but it does give you what you're looking for at the
> risk of breaking applications that are relying on interpolation, like the
> nova example.
> 
> 2. We could disable interpolation when we get values from environment
> variables. That would be a big behavioral change, so we would need to think
> about how to roll it out carefully. For example, do we provide a helper
> function to give to application developers who are setting default values
> to environment variables so the variable value can be escaped to avoid
> interpolation? Or do we build it into the Opt class somehow? I think I like
> the helper function approach but we should give it more thought."
> I would like to collect more suggestions to decide the direction to fix
> similar bug. Any thoughts ?

I don't see a compelling need to change oslo behaviour wrt interpolation
at all, given all the option suggested here break copatibility in some
manner or another.

The curernt behaviour should just have its error reporting fixed, so that
it explicitly tells the user that the env var it tried to interpolate
contains invalid characters, instead of printing the incomprehensible
stack trace.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

[openstack-dev] [third-party] [ci] Upcoming changes to Nodepool for Zuul v3

[Asselin, Ramy]

All,

If you haven't already, it's recommended to pin nodepool to the 0.3.0 tag and 
not use master.
If you're using the puppet-openstackci solution, you can update your puppet 
hiera file as shown here: https://review.openstack.org/293112
Re-run puppet and restart nodepool.

Ramy 

-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: Thursday, July 07, 2016 6:21 PM
To: openstack-in...@lists.openstack.org
Subject: [OpenStack-Infra] Upcoming changes to Nodepool for Zuul v3

Hey all!

tl;dr - nodepool 0.3.0 tagged, you should pin

Longer version:

As you are probably aware, we've been working towards Zuul v3 for a while. 
Hopefully you're as excited about that as we are.

We're about to start working in earnest on changes to nodepool in support of 
that. One of our goals with Zuul v3 is to make nodepool supportable in a CD 
manner for people who are not us. In support of that, we may break a few things 
over the next month or two.

So that it's not a steady stream of things you should pay attention to - we've 
cut a tag:

0.3.0

of what's running in production right now. If your tolerance for potentially 
breaking change is low, we strongly recommend pinning your install to it.

We will still be running CD from master the whole time - but we are also paying 
constant attention when we're landing things.

Once this next iteration is ready, we'll send out another announcement that 
master is in shape for consuming CD-style.

Thanks!
Monty

___
OpenStack-Infra mailing list
openstack-in...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

__
OpenStack Development Mailing 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][docs]: Undercloud install fails with unavailability of oslo::cache

[Ben Nemec]

On 07/08/2016 12:58 AM, Paddu Krishnan (padkrish) wrote:
>> Hello,
>> I am trying to install TripleO in a VM environment. It’s a basic install.
>> I am following the instructions in
>>  
>> http://docs.openstack.org/developer/tripleo-docs/installation/installation.html.
>>  I
>> am following the instructions for the stable branch.
>>
>> Installing the undercloud (“openstack undercloud install”) failed with
>> the below logs. Inspite of me giving the repo as
>> liberty,  
>> /usr/share/tripleo-image-elements/rdo-release/environment.d/10-rdo-release-name.bash
>> was set to kilo. I modified it to liberty.
>>
>> I also made changes in
>>  /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py
>> to point to liberty as mentioned
>> in https://bugzilla.redhat.com/show_bug.cgi?id=1304395.

You should not make any code changes to install Liberty.  I just tried
it and it worked fine with the current code.

>>
>> I did not get any errors in the previous commands. From the error, I
>> can only guess all the puppet modules (oslo::cache?) were not
>> completely installed. Any tips on overcoming this would be great.
>>
>> ——-
>> dib-run-parts Tue Jul  5 16:15:01 EDT 2016 Running
>> /usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
>> + set -o pipefail
>> + set +e
>> + puppet apply --detailed-exitcodes
>> /etc/puppet/manifests/puppet-stack-config.pp
>> Error: Resource type oslo::cache doesn't exist on node instack.localdomain
>> Error: Resource type oslo::cache doesn't exist on node instack.localdomain
>> + rc=1
>> + set -e
>> + echo 'puppet apply exited with exit code 1'
>> puppet apply exited with exit code 1
>> + '[' 1 '!=' 2 -a 1 '!=' 0 ']'
>> + exit 1
>> [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] during configure
>> phase. [Command '['dib-run-parts',
>> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
>> status 1]
>>
>> [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] Aborting...
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>> line 815, in install
>> _run_orc(instack_env)
>>   File
>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>> line 699, in _run_orc
>> _run_live_command(args, instack_env, 'os-refresh-config')
>>   File
>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>> line 370, in _run_live_command
>> raise RuntimeError('%s failed. See log for details.' % name)
>> RuntimeError: os-refresh-config failed. See log for details.
>> Command 'instack-install-undercloud' returned non-zero exit status 1
>>
>> 
>>
>> I also manually tried to install the oslo packages, that didn’t help
>> either.
>>
>> As suggested by shardy, I also tried the “tripleo.sh  —repo-setup”.
>> Still the same error. 

What is the output of `cat /etc/yum.repos.d/delorean*` ?  You may have
conflicting repos if you used both the doc repo setup and the tripleo.sh
one.  Deleting /etc/yum.repos.d/delorean* and re-running tripleo.sh
--repo-setup may help (don't forget to export STABLE_RELEASE=liberty first).

For the moment I would ignore the documentation on repo setup and image
building and use tripleo.sh for those parts.  Both those sections are
different from what we CI and I believe both are probably broken right
now.  I'm trying to fix this divergence, but progress is slow so far. :-(

>>
> From yum list:
> 
> ———-
> python-oslo-cache.noarch 0.7.0-1.el7
> delorean-liberty-testing   
> python-oslo-cache-doc.noarch
> 0.7.1-0.20160624191250.4f1f8a1.el7.centos
> python2-oslo-cache.noarch0.7.1-0.20160624191250.4f1f8a1.el7.centos
> python2-oslo-cache-tests.noarch  0.7.1-0.20160624191250.4f1f8a1.el7.centos
> ——
>> Thanks,
>> Paddu
>> 
> 
> 
> 
> __
> OpenStack Development Mailing 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 Developm

[openstack-dev] [ironic] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Dmitry Tantsur]

I've noticed that Dell CI has the same problem: it uses "recheck Dell" 
causing the whole check pipeline to rerun.


On 06/29/2016 02:23 AM, Villalovos, John L wrote:




-Original Message-
From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
Sent: Tuesday, June 28, 2016 17:00
To: OpenStack Development Mailing List (not for usage questions)
Cc: ufcg-oneview...@lsd.ufcg.edu.br
Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
recheck command

Hi Jay,

Sorry about that. The comment should be "recheck oneview" to test again.
I'll patch the failure message with instructions, thanks for the warning.


I'm not sure "recheck oneview" is a good command because it will kick off the 
master recheck. I would suggest something that will not trigger the normal jobs to 
recheck.

"retest oneview"??  Hopefully there is some standard for 3rd Party CI to use.

And yes, please do put in the message the command to do a job recheck.

John
__
OpenStack Development Mailing 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] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Jeremy Stanley]

On 2016-07-08 17:10:04 +0200 (+0200), Dmitry Tantsur wrote:
> I've noticed that Dell CI has the same problem: it uses "recheck Dell"
> causing the whole check pipeline to rerun.

Back when third party CI systems started adding rechecking
capability, this was seen as a convenience that developers could
request fresh results simultaneously from all CI systems (official
and third-party) by just leaving a single comment. It's sort of an
anti-pattern that jobs and CI systems would be broken so frequently
that you need to recheck them individually rather than en masse, to
the point where rechecking syntax gets redesigned to make that
action easier instead.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

[Neil Jerram]

Hi Armando,

Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
me (or anyone) any new rights for neutron-lib changes.  It appears to be
preparatory to a planned expansion of neutron-lib-core - but looking at
[5], the membership doesn't include me, or folk from many stadium
projects.  So, did I misunderstand who this thread is addressed to?  Or is
the planned expansion still to happen?

Thanks,
Neil


[5] https://review.openstack.org/#/admin/groups/1187,members

On Wed, Jun 29, 2016 at 8:07 PM Armando M.  wrote:

> Hi Neutrinos,
>
> As some of you may have noticed, since the merge of [1] you have now +2
> rights on neutron-lib changes. Please make yourself familiar with review
> guidelines [2]: in general, code that targets the library should go through
> a much greater level of scrutiny and should be targeted if and only if it
> serves the purpose of reuse across the Stadium, and the decoupling of
> Neutron from its consumer projects.
>
> Please, also bear in mind that since [3] is in effect, I'll be working
> over the next few days to implement some of the steps outlined in the plan,
> and that involves consolidating APIs and move them over to neutron-lib.
> Akihiro started the effort of moving the API documentation [4] over
> neutron-lib, and we'll continue towards the consolidation effort.
>
> Please become more involved, and consider neutron-lib as one of the
> projects you take the time of reviewing on a day to day basis.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/335250/
> [2] http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
> [3]
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
> [4] http://developer.openstack.org/api-ref/networking/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Ben Nemec]

On 07/08/2016 09:14 AM, ChangBo Guo wrote:
> Hi ALL,
> 
> I have been working a bug [1] about option value interpolation in
> oslo.config[2], in short, option value interpolation can't handle
> password containing special characters from environment variable and I 
> proposed a fix of provide way to forbid option value interpolation
> explicitly[3]. 
> 
> copy of Doug Hellmann's coments:
> 
> "The problem is that the end user who is setting the value of the option
> cannot control whether the option will do interpolation or not. So the
> programmer who defines the option has to make that choice, and then we
> can't change it because that would break existing deployments. The
> result is that end users won't know for any given option whether
> interpolation works or not, and if not why (did they do something wrong,
> or is it not supported).
> 
> I've set -2 on this patch because I think it's a bad approach. I see 2
> other ways we could solve the problem you describe (and I agree that
> it's an issue we should help with).
> 
> 1. We could have an option that turns off interpolation globally, and
> let the user control that by setting the flag in their configuration
> file. I'm not sure I like this, but it does give you what you're looking
> for at the risk of breaking applications that are relying on
> interpolation, like the nova example.

This feels like a big hammer for a relatively small edge case, and as
you note it doesn't handle the case where you want to use interpolation,
but have an environment variable default that breaks when interpolated.

> 
> 2. We could disable interpolation when we get values from environment
> variables. That would be a big behavioral change, so we would need to
> think about how to roll it out carefully. For example, do we provide a
> helper function to give to application developers who are setting
> default values to environment variables so the variable value can be
> escaped to avoid interpolation? Or do we build it into the Opt class
> somehow? I think I like the helper function approach but we should give
> it more thought."

One possibility would be an "env_default" (or something) parameter to
Opt that would read the env var, escape it as necessary, and set the opt
default to the escaped value.  Then we could recommend that people stop
using os.environ for setting defaults this way.  Using default and
env_default at the same time would raise an exception.

So the shaker example would look like:

cfg.StrOpt('os-password', metavar='',
   env_default='OS_PASSWORD',
   sample_default='',
   help='Authentication password, defaults to env[OS_PASSWORD].')

It does require that developers DTRT when pulling defaults from the env,
but IMHO that's better than a backwards incompatible change or requiring
that users DTRT, which seem to be the alternatives here.

I suppose it would break anyone who happened to be using interpolation
of a default from the env, but I feel like that's unlikely and a much
less common case than "my password has a $ character in it".

> 
> I would like to collect more suggestions to decide the direction to fix
> similar bug. Any thoughts ?
> 
> [1]https://bugs.launchpad.net/oslo.config/+bug/1577731
> [2]http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
> [3]https://review.openstack.org/#/c/338668/
> 
> 
> -- 
> ChangBo Guo(gcb)
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Doug Hellmann]

Excerpts from Daniel P. Berrange's message of 2016-07-08 15:25:16 +0100:
> On Fri, Jul 08, 2016 at 10:14:20PM +0800, ChangBo Guo wrote:
> > Hi ALL,
> > 
> > I have been working a bug [1] about option value interpolation in
> > oslo.config[2], in short, option value interpolation can't handle password
> > containing special characters from environment variable and I  proposed a
> > fix of provide way to forbid option value interpolation explicitly[3].
> > 
> > copy of Doug Hellmann's coments:
> > 
> > "The problem is that the end user who is setting the value of the option
> > cannot control whether the option will do interpolation or not. So the
> > programmer who defines the option has to make that choice, and then we
> > can't change it because that would break existing deployments. The result
> > is that end users won't know for any given option whether interpolation
> > works or not, and if not why (did they do something wrong, or is it not
> > supported).
> > 
> > I've set -2 on this patch because I think it's a bad approach. I see 2
> > other ways we could solve the problem you describe (and I agree that it's
> > an issue we should help with).
> > 
> > 1. We could have an option that turns off interpolation globally, and let
> > the user control that by setting the flag in their configuration file. I'm
> > not sure I like this, but it does give you what you're looking for at the
> > risk of breaking applications that are relying on interpolation, like the
> > nova example.
> > 
> > 2. We could disable interpolation when we get values from environment
> > variables. That would be a big behavioral change, so we would need to think
> > about how to roll it out carefully. For example, do we provide a helper
> > function to give to application developers who are setting default values
> > to environment variables so the variable value can be escaped to avoid
> > interpolation? Or do we build it into the Opt class somehow? I think I like
> > the helper function approach but we should give it more thought."
> > I would like to collect more suggestions to decide the direction to fix
> > similar bug. Any thoughts ?
> 
> I don't see a compelling need to change oslo behaviour wrt interpolation
> at all, given all the option suggested here break copatibility in some
> manner or another.
> 
> The curernt behaviour should just have its error reporting fixed, so that
> it explicitly tells the user that the env var it tried to interpolate
> contains invalid characters, instead of printing the incomprehensible
> stack trace.
> 
> 
> Regards,
> Daniel

Sure, the bug should be fixed. I was also trying to find a way to
address the usability issue ChangBo pointed out in the commit message,
which is that defaults being pulled from environment variables need to
be treated carefully. In some cases the values should be escaped but in
others they shouldn't, and the same environment variable is being used
in all cases.

Doug

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

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2016-07-08 10:24:54 -0500:
> On 07/08/2016 09:14 AM, ChangBo Guo wrote:
> > Hi ALL,
> > 
> > I have been working a bug [1] about option value interpolation in
> > oslo.config[2], in short, option value interpolation can't handle
> > password containing special characters from environment variable and I 
> > proposed a fix of provide way to forbid option value interpolation
> > explicitly[3]. 
> > 
> > copy of Doug Hellmann's coments:
> > 
> > "The problem is that the end user who is setting the value of the option
> > cannot control whether the option will do interpolation or not. So the
> > programmer who defines the option has to make that choice, and then we
> > can't change it because that would break existing deployments. The
> > result is that end users won't know for any given option whether
> > interpolation works or not, and if not why (did they do something wrong,
> > or is it not supported).
> > 
> > I've set -2 on this patch because I think it's a bad approach. I see 2
> > other ways we could solve the problem you describe (and I agree that
> > it's an issue we should help with).
> > 
> > 1. We could have an option that turns off interpolation globally, and
> > let the user control that by setting the flag in their configuration
> > file. I'm not sure I like this, but it does give you what you're looking
> > for at the risk of breaking applications that are relying on
> > interpolation, like the nova example.
> 
> This feels like a big hammer for a relatively small edge case, and as
> you note it doesn't handle the case where you want to use interpolation,
> but have an environment variable default that breaks when interpolated.
> 
> > 
> > 2. We could disable interpolation when we get values from environment
> > variables. That would be a big behavioral change, so we would need to
> > think about how to roll it out carefully. For example, do we provide a
> > helper function to give to application developers who are setting
> > default values to environment variables so the variable value can be
> > escaped to avoid interpolation? Or do we build it into the Opt class
> > somehow? I think I like the helper function approach but we should give
> > it more thought."
> 
> One possibility would be an "env_default" (or something) parameter to
> Opt that would read the env var, escape it as necessary, and set the opt
> default to the escaped value.  Then we could recommend that people stop
> using os.environ for setting defaults this way.  Using default and
> env_default at the same time would raise an exception.

That sounds a lot like my helper function example, but builds the
concept of taking a default from an environment variable into Opt.

> 
> So the shaker example would look like:
> 
> cfg.StrOpt('os-password', metavar='',
>env_default='OS_PASSWORD',
>sample_default='',
>help='Authentication password, defaults to env[OS_PASSWORD].')
> 
> It does require that developers DTRT when pulling defaults from the env,
> but IMHO that's better than a backwards incompatible change or requiring
> that users DTRT, which seem to be the alternatives here.
> 
> I suppose it would break anyone who happened to be using interpolation
> of a default from the env, but I feel like that's unlikely and a much
> less common case than "my password has a $ character in it".

That's also my assumption. I think this has come up before, especially
since a lot of the password generators out there like to use characters
the parser considers "special."

Doug

> 
> > 
> > I would like to collect more suggestions to decide the direction to fix
> > similar bug. Any thoughts ?
> > 
> > [1]https://bugs.launchpad.net/oslo.config/+bug/1577731
> > [2]http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
> > [3]https://review.openstack.org/#/c/338668/
> > 
> > 
> > -- 
> > ChangBo Guo(gcb)
> > 
> > 
> > __
> > OpenStack Development Mailing 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][SR-IOV][pci-passthrough] Reporting pci devices in hypervisor-show

[Beliveau, Ludovic]

I see a lot of values in having something like this for inventory purposes and 
troubleshooting.

IMHO the information should be provided in two ways.

1. Show PCI pools status per compute.  Currently the pools only have 
information about how many devices are allocated in a pool ("count").  We 
should also derive from the pci_devices db table the number of PCI devices that 
are available per pool (not just the number of allocated).  This information 
could be included in the hypervisor-show (or a new REST API if this is found to 
be too noisy).

2. More detailed information about each individual PCI devices (like you are 
suggesting: parent device relationships, etc.).  This could be in a separate 
REST API call.

We could even think about a third option where we could be showing global PCI 
pools information for a whole region.

For discussions purposes, here's what pci_stats for a compute looks like today:
{"count": 1, "numa_node": 0, "vendor_id": "8086", "product_id": "10fb", "tags": 
{"dev_type": "type-PF", "physical_network": "default"}}, 
"nova_object.namespace": "nova"}
{"count": 3, "numa_node": 0, "vendor_id": "8086", "product_id": "10ed", "tags": 
{"dev_type": "type-VF", "physical_network": "default"}}, 
"nova_object.namespace": "nova"}]}, "nova_object.namespace": "nova"}

Is there an intention to write a blueprint for this feature ?  If there are 
interests, I don't mind working on it.

/ludovic


On 07/08/2016 07:11 AM, Murray, Paul (HP Cloud) wrote:
Hi All,

At the moment I am not aware of a nova api call that provides information about 
the pci devices on a host. The most obvious place to put this would be in 
hypervisor-show. I wonder if anyone has made an attempt at this already or if 
there are any reasons for not adding pci information there?

Assuming pci device information was put in hypervisor-show I would be 
interested in how people think it would be presented. There are different types 
of pci device and things like virtual functions and parent device 
relationships. The information should include the allocation status.

If hypervisor-show is not the place for this I would be interested in 
suggestions on where it should go.

Paul


__
OpenStack Development Mailing 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] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Rajini_Ram]

Dell - Internal Use - Confidential
Sorry I wasn't aware that this is causing the whole pipeline to rerun. Will 
change it to "retest Dell"

-Rajini

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Friday, July 08, 2016 10:10 AM
To: openstack-dev@lists.openstack.org
Cc: Ram, Rajini
Subject: [openstack-dev] [ironic] Dell recheck command issue (was: UFCG OneView 
CI comments missing recheck command)

I've noticed that Dell CI has the same problem: it uses "recheck Dell"
causing the whole check pipeline to rerun.

On 06/29/2016 02:23 AM, Villalovos, John L wrote:
>
>
>> -Original Message-
>> From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>> Sent: Tuesday, June 28, 2016 17:00
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments
>> missing recheck command
>>
>> Hi Jay,
>>
>> Sorry about that. The comment should be "recheck oneview" to test again.
>> I'll patch the failure message with instructions, thanks for the warning.
>
> I'm not sure "recheck oneview" is a good command because it will kick off the 
> master recheck. I would suggest something that will not trigger the normal 
> jobs to recheck.
>
> "retest oneview"?? Hopefully there is some standard for 3rd Party CI to use.
>
> And yes, please do put in the message the command to do a job recheck.
>
> John
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

[Armando M.]

On 8 July 2016 at 08:22, Neil Jerram  wrote:

> Hi Armando,
>
> Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
> me (or anyone) any new rights for neutron-lib changes.  It appears to be
> preparatory to a planned expansion of neutron-lib-core - but looking at
> [5], the membership doesn't include me, or folk from many stadium
> projects.  So, did I misunderstand who this thread is addressed to?  Or is
> the planned expansion still to happen?
>
> Thanks,
> Neil
>
>
> [5] https://review.openstack.org/#/admin/groups/1187,members
>

Right now this is limited to the core maintainers of repos that spun out of
Neutron. We'll extend rights to other teams over time as soon as we
complete the Stadium transition plan.


>
> On Wed, Jun 29, 2016 at 8:07 PM Armando M.  wrote:
>
>> Hi Neutrinos,
>>
>> As some of you may have noticed, since the merge of [1] you have now +2
>> rights on neutron-lib changes. Please make yourself familiar with review
>> guidelines [2]: in general, code that targets the library should go through
>> a much greater level of scrutiny and should be targeted if and only if it
>> serves the purpose of reuse across the Stadium, and the decoupling of
>> Neutron from its consumer projects.
>>
>> Please, also bear in mind that since [3] is in effect, I'll be working
>> over the next few days to implement some of the steps outlined in the plan,
>> and that involves consolidating APIs and move them over to neutron-lib.
>> Akihiro started the effort of moving the API documentation [4] over
>> neutron-lib, and we'll continue towards the consolidation effort.
>>
>> Please become more involved, and consider neutron-lib as one of the
>> projects you take the time of reviewing on a day to day basis.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/335250/
>> [2]
>> http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
>> [3]
>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
>> [4] http://developer.openstack.org/api-ref/networking/
>> __
>> OpenStack Development Mailing 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] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Mikhail Medvedev]

On Fri, Jul 8, 2016 at 10:10 AM, Dmitry Tantsur  wrote:
> I've noticed that Dell CI has the same problem: it uses "recheck Dell"
> causing the whole check pipeline to rerun.

There is a doc patch that added selective recheck syntax in addition
to standard recheck [1]: it asks third-party CIs to support both
"recheck" and ": recheck". There is also [2] to revert that
patch.

Whether or not the patch would get reverted, it would be nice if there
is a recommended way to only recheck a particular third-party CI. Can
selective recheck be abused to beat an unstable CI into submission?
Yes. And it also has valid use cases, e.g. rechecking a CI failing due
an obvious one-time fluke.

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

> On 06/29/2016 02:23 AM, Villalovos, John L wrote:
>>
>>
>>
>>> -Original Message-
>>> From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>>> Sent: Tuesday, June 28, 2016 17:00
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
>>> recheck command
>>>
>>> Hi Jay,
>>>
>>> Sorry about that. The comment should be "recheck oneview" to test again.
>>> I'll patch the failure message with instructions, thanks for the warning.
>>
>>
>> I'm not sure "recheck oneview" is a good command because it will kick off
>> the master recheck. I would suggest something that will not trigger the
>> normal jobs to recheck.
>>
>> "retest oneview"??  Hopefully there is some standard for 3rd Party CI to
>> use.
>>
>> And yes, please do put in the message the command to do a job recheck.
>>
>> John
>> __
>> OpenStack Development Mailing 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

--
Mikhail Medvedev
IBM

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

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

[Neil Jerram]

Cool - thanks for clarifying that!

   Neil


On Fri, Jul 8, 2016 at 5:20 PM Armando M.  wrote:

> On 8 July 2016 at 08:22, Neil Jerram  wrote:
>
>> Hi Armando,
>>
>> Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
>> me (or anyone) any new rights for neutron-lib changes.  It appears to be
>> preparatory to a planned expansion of neutron-lib-core - but looking at
>> [5], the membership doesn't include me, or folk from many stadium
>> projects.  So, did I misunderstand who this thread is addressed to?  Or is
>> the planned expansion still to happen?
>>
>> Thanks,
>> Neil
>>
>>
>> [5] https://review.openstack.org/#/admin/groups/1187,members
>>
>
> Right now this is limited to the core maintainers of repos that spun out
> of Neutron. We'll extend rights to other teams over time as soon as we
> complete the Stadium transition plan.
>
>
>>
>> On Wed, Jun 29, 2016 at 8:07 PM Armando M.  wrote:
>>
>>> Hi Neutrinos,
>>>
>>> As some of you may have noticed, since the merge of [1] you have now +2
>>> rights on neutron-lib changes. Please make yourself familiar with review
>>> guidelines [2]: in general, code that targets the library should go through
>>> a much greater level of scrutiny and should be targeted if and only if it
>>> serves the purpose of reuse across the Stadium, and the decoupling of
>>> Neutron from its consumer projects.
>>>
>>> Please, also bear in mind that since [3] is in effect, I'll be working
>>> over the next few days to implement some of the steps outlined in the plan,
>>> and that involves consolidating APIs and move them over to neutron-lib.
>>> Akihiro started the effort of moving the API documentation [4] over
>>> neutron-lib, and we'll continue towards the consolidation effort.
>>>
>>> Please become more involved, and consider neutron-lib as one of the
>>> projects you take the time of reviewing on a day to day basis.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/335250/
>>> [2]
>>> http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
>>> [3]
>>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
>>> [4] http://developer.openstack.org/api-ref/networking/
>>>
>>> __
>>> OpenStack Development Mailing 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] [ironic] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Sam Betts (sambetts)]

Please  can we not reinvent our own standard for this, as mentioned in the 
other thread on this topic, there is an OpenStack standard for third party CI 
recheck commands that can be found in the third party CI docs: 
http://docs.openstack.org/infra/system-config/third_party.html#requirements

Third party Cis should respond to comments in the following formats:

recheck

 recheck
(Where  is replaced with the name of your third party CI.)

Sam

On 08/07/2016 17:16, "rajini_...@dell.com" 
mailto:rajini_...@dell.com>> wrote:


Dell - Internal Use - Confidential
Sorry I wasn't aware that this is causing the whole pipeline to rerun. Will 
change it to "retest Dell"

-Rajini

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Friday, July 08, 2016 10:10 AM
To: openstack-dev@lists.openstack.org
Cc: Ram, Rajini
Subject: [openstack-dev] [ironic] Dell recheck command issue (was: UFCG OneView 
CI comments missing recheck command)

I've noticed that Dell CI has the same problem: it uses "recheck Dell"
causing the whole check pipeline to rerun.

On 06/29/2016 02:23 AM, Villalovos, John L wrote:
>
>
>> -Original Message-
>> From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>> Sent: Tuesday, June 28, 2016 17:00
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments
>> missing recheck command
>>
>> Hi Jay,
>>
>> Sorry about that. The comment should be "recheck oneview" to test again.
>> I'll patch the failure message with instructions, thanks for the warning.
>
> I'm not sure "recheck oneview" is a good command because it will kick off the 
> master recheck. I would suggest something that will not trigger the normal 
> jobs to recheck.
>
> "retest oneview"?? Hopefully there is some standard for 3rd Party CI to use.
>
> And yes, please do put in the message the command to do a job recheck.
>
> John
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][scheduler] Next meeting: Monday, July 11 at 1400 UTC

[Ed Leafe]

The next meeting of the Nova Scheduler subteam will be Monday, July 11 at 
1400UTC in the #openstack-meeting-alt channel.
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160711T14

The agenda is here:
https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting

If you have anything specific to discuss, please update the agenda as soon as 
possible so that others may review before the meeting.


-- Ed Leafe






__
OpenStack Development Mailing 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][docs]: Undercloud install fails with unavailability of oslo::cache

[Paddu Krishnan (padkrish)]

Thanks a lot for the reply. Pls see inline..

On 7/8/16, 7:47 AM, "Ben Nemec"  wrote:

>On 07/08/2016 12:58 AM, Paddu Krishnan (padkrish) wrote:
>>> Hello,
>>> I am trying to install TripleO in a VM environment. It¹s a basic
>>>install.
>>> I am following the instructions in
>>>  
>>>http://docs.openstack.org/developer/tripleo-docs/installation/installati
>>>on.html. I
>>> am following the instructions for the stable branch.
>>>
>>> Installing the undercloud (³openstack undercloud install²) failed with
>>> the below logs. Inspite of me giving the repo as
>>> liberty,  
>>>/usr/share/tripleo-image-elements/rdo-release/environment.d/10-rdo-relea
>>>se-name.bash
>>> was set to kilo. I modified it to liberty.
>>>
>>> I also made changes in
>>>  /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py
>>> to point to liberty as mentioned
>>> in https://bugzilla.redhat.com/show_bug.cgi?id=1304395.
>
>You should not make any code changes to install Liberty.  I just tried
>it and it worked fine with the current code.

#padkrish# I did not do this earlier. Then I found
/usr/share/tripleo-image-elements/rdo-release/environment.d/10-rdo-release-
name.bash and  
/usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py in
the undercloud VM had Kilo instead of liberty. I am going to try few more
suggestions. If it doesn¹t work, I will start from scratch in building the
undercloud VM and share the logs.
 
>
>>>
>>> I did not get any errors in the previous commands. From the error, I
>>> can only guess all the puppet modules (oslo::cache?) were not
>>> completely installed. Any tips on overcoming this would be great.
>>>
>>> ‹‹-
>>> dib-run-parts Tue Jul  5 16:15:01 EDT 2016 Running
>>> /usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
>>> + set -o pipefail
>>> + set +e
>>> + puppet apply --detailed-exitcodes
>>> /etc/puppet/manifests/puppet-stack-config.pp
>>> Error: Resource type oslo::cache doesn't exist on node
>>>instack.localdomain
>>> Error: Resource type oslo::cache doesn't exist on node
>>>instack.localdomain
>>> + rc=1
>>> + set -e
>>> + echo 'puppet apply exited with exit code 1'
>>> puppet apply exited with exit code 1
>>> + '[' 1 '!=' 2 -a 1 '!=' 0 ']'
>>> + exit 1
>>> [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] during configure
>>> phase. [Command '['dib-run-parts',
>>> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
>>> status 1]
>>>
>>> [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] Aborting...
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File
>>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>>> line 815, in install
>>> _run_orc(instack_env)
>>>   File
>>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>>> line 699, in _run_orc
>>> _run_live_command(args, instack_env, 'os-refresh-config')
>>>   File
>>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
>>> line 370, in _run_live_command
>>> raise RuntimeError('%s failed. See log for details.' % name)
>>> RuntimeError: os-refresh-config failed. See log for details.
>>> Command 'instack-install-undercloud' returned non-zero exit status 1
>>>
>>> 
>>>
>>> I also manually tried to install the oslo packages, that didn¹t help
>>> either.
>>>
>>> As suggested by shardy, I also tried the ³tripleo.sh  ‹repo-setup².
>>> Still the same error.
>
>What is the output of `cat /etc/yum.repos.d/delorean*` ?  You may have
>conflicting repos if you used both the doc repo setup and the tripleo.sh
>one.  Deleting /etc/yum.repos.d/delorean* and re-running tripleo.sh
>--repo-setup may help (don't forget to export STABLE_RELEASE=liberty
>first).

#padkrish# Just tried your suggestion and unfortunately that didn¹t help
either :(. Here it is:
 


Thanks again,
Paddu


>
>For the moment I would ignore the documentation on repo setup and image
>building and use tripleo.sh for those parts.  Both those sections are
>different from what we CI and I believe both are probably broken right
>now.  I'm trying to fix this divergence, but progress is slow so far. :-(
>
>>>
>> From yum list:
>> 
>> ‹‹‹-
>> python-oslo-cache.noarch 0.7.0-1.el7
>> delorean-liberty-testing
>> python-oslo-cache-doc.noarch
>> 0.7.1-0.20160624191250.4f1f8a1.el7.centos
>> python2-oslo-cache.noarch
>>0.7.1-0.20160624191250.4f1f8a1.el7.centos
>> python2-oslo-cache-tests.noarch
>>0.7.1-0.20160624191250.4f1f8a1.el7.centos
>> ‹‹
>>> Thanks,
>>> Paddu
>>> 
>>>>>ion.html>>>installation.html>>>allation/installation.html>>>docs/installation/installation.html>

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

[Steven Dake (stdake)]

Michal and Angus,

Thanks a bunch for stepping down gracefully as your personal interests
have changed to focus on k8s upstream.  We were glad to have you and will
be happy to have you on our team in the future if things change for you.

Regards,
-steve

On 7/8/16, 1:01 AM, "Michal Rostecki"  wrote:

>Hi,
>
>I'd like to announce that I'm leaving the Kolla core team and I will not
>work on this project anymore (at least in the near future). I'm fully
>focusing on working in Kubernetes upstream directly. That said, I want
>to thank you for working together!
>
>Cheers,
>Michal
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Ben Nemec]

On 07/08/2016 10:58 AM, Doug Hellmann wrote:
> Excerpts from Ben Nemec's message of 2016-07-08 10:24:54 -0500:
>> On 07/08/2016 09:14 AM, ChangBo Guo wrote:
>>> Hi ALL,
>>>
>>> I have been working a bug [1] about option value interpolation in
>>> oslo.config[2], in short, option value interpolation can't handle
>>> password containing special characters from environment variable and I 
>>> proposed a fix of provide way to forbid option value interpolation
>>> explicitly[3]. 
>>>
>>> copy of Doug Hellmann's coments:
>>>
>>> "The problem is that the end user who is setting the value of the option
>>> cannot control whether the option will do interpolation or not. So the
>>> programmer who defines the option has to make that choice, and then we
>>> can't change it because that would break existing deployments. The
>>> result is that end users won't know for any given option whether
>>> interpolation works or not, and if not why (did they do something wrong,
>>> or is it not supported).
>>>
>>> I've set -2 on this patch because I think it's a bad approach. I see 2
>>> other ways we could solve the problem you describe (and I agree that
>>> it's an issue we should help with).
>>>
>>> 1. We could have an option that turns off interpolation globally, and
>>> let the user control that by setting the flag in their configuration
>>> file. I'm not sure I like this, but it does give you what you're looking
>>> for at the risk of breaking applications that are relying on
>>> interpolation, like the nova example.
>>
>> This feels like a big hammer for a relatively small edge case, and as
>> you note it doesn't handle the case where you want to use interpolation,
>> but have an environment variable default that breaks when interpolated.
>>
>>>
>>> 2. We could disable interpolation when we get values from environment
>>> variables. That would be a big behavioral change, so we would need to
>>> think about how to roll it out carefully. For example, do we provide a
>>> helper function to give to application developers who are setting
>>> default values to environment variables so the variable value can be
>>> escaped to avoid interpolation? Or do we build it into the Opt class
>>> somehow? I think I like the helper function approach but we should give
>>> it more thought."
>>
>> One possibility would be an "env_default" (or something) parameter to
>> Opt that would read the env var, escape it as necessary, and set the opt
>> default to the escaped value.  Then we could recommend that people stop
>> using os.environ for setting defaults this way.  Using default and
>> env_default at the same time would raise an exception.
> 
> That sounds a lot like my helper function example, but builds the
> concept of taking a default from an environment variable into Opt.

Yeah, I was mostly +1'ing that suggestion and then brainstorming how to
integrate it into the opt definition.  This seemed like the simplest way
to do it, but the benefit of a separate helper function would be if
there are other places we might want to do the same thing besides just
the Opt constructor.  I could see someone wanting to set a None default
and then conditionally set the default to an environment variable in
their code, so maybe standalone would be better.

> 
>>
>> So the shaker example would look like:
>>
>> cfg.StrOpt('os-password', metavar='',
>>env_default='OS_PASSWORD',
>>sample_default='',
>>help='Authentication password, defaults to env[OS_PASSWORD].')
>>
>> It does require that developers DTRT when pulling defaults from the env,
>> but IMHO that's better than a backwards incompatible change or requiring
>> that users DTRT, which seem to be the alternatives here.
>>
>> I suppose it would break anyone who happened to be using interpolation
>> of a default from the env, but I feel like that's unlikely and a much
>> less common case than "my password has a $ character in it".
> 
> That's also my assumption. I think this has come up before, especially
> since a lot of the password generators out there like to use characters
> the parser considers "special."
> 
> Doug
> 
>>
>>>
>>> I would like to collect more suggestions to decide the direction to fix
>>> similar bug. Any thoughts ?
>>>
>>> [1]https://bugs.launchpad.net/oslo.config/+bug/1577731
>>> [2]http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
>>> [3]https://review.openstack.org/#/c/338668/
>>>
>>>
>>> -- 
>>> ChangBo Guo(gcb)
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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?s

[openstack-dev] [Zun][Higgins] Request initial feedback for the design spec

[Hongbin Lu]

Hi all,

Because I cannot attend the team meeting next week, I would leave a message 
here: I am working on a spec to define the high-level design of the Zun service.

https://etherpad.openstack.org/p/zun-containers-service-design-spec

I would encourage everyone to participant on this efforts to sharp our project. 
Please feel free to edit or leave comments on the etherpad. Your feedback is 
greatly appreciated.

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

Re: [openstack-dev] [Nova][SR-IOV][pci-passthrough] Reporting pci devices in hypervisor-show

[Jay Pipes]

On 07/08/2016 12:10 PM, Beliveau, Ludovic wrote:

I see a lot of values in having something like this for inventory
purposes and troubleshooting.

IMHO the information should be provided in two ways.

1. Show PCI pools status per compute.  Currently the pools only have
information about how many devices are allocated in a pool ("count").
We should also derive from the pci_devices db table the number of PCI
devices that are available per pool (not just the number of allocated).
This information could be included in the hypervisor-show (or a new REST
API if this is found to be too noisy).

2. More detailed information about each individual PCI devices (like you
are suggesting: parent device relationships, etc.).  This could be in a
separate REST API call.

We could even think about a third option where we could be showing
global PCI pools information for a whole region.

For discussions purposes, here's what pci_stats for a compute looks like
today:
{"count": 1, "numa_node": 0, "vendor_id": "8086", "product_id": "10fb",
"tags": {"dev_type": "type-PF", "physical_network": "default"}},
"nova_object.namespace": "nova"}
{"count": 3, "numa_node": 0, "vendor_id": "8086", "product_id": "10ed",
"tags": {"dev_type": "type-VF", "physical_network": "default"}},
"nova_object.namespace": "nova"}]}, "nova_object.namespace": "nova"}

Is there an intention to write a blueprint for this feature ?  If there
are interests, I don't mind working on it.


Personally, I hate the PCI device pool code and the whole concept of 
storing this aggregate "pool" information in the database (where it can 
easily become out of sync with the underlying PCI device records).


In fact, I hate it so much I created a spec/blueprint about it:

http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/pci-stats-generate.html

-jay


On 07/08/2016 07:11 AM, Murray, Paul (HP Cloud) wrote:


Hi All,

At the moment I am not aware of a nova api call that provides
information about the pci devices on a host. The most obvious place to
put this would be in hypervisor-show. I wonder if anyone has made an
attempt at this already or if there are any reasons for not adding pci
information there?

Assuming pci device information was put in hypervisor-show I would be
interested in how people think it would be presented. There are
different types of pci device and things like virtual functions and
parent device relationships. The information should include the
allocation status.

If hypervisor-show is not the place for this I would be interested in
suggestions on where it should go.

Paul





__
OpenStack Development Mailing 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] The future of OpenStack documentation

[Matt Kassawara]

Currently, OpenStack provides central documentation (primarily in the
openstack-manuals repository) for operators and users. The single location
and consistent structure eases audiences of various technical expertise
into OpenStack, typically operators and users rather than developers.
Although I'm not a fan of the word "product", increasingly less technical
audiences are learning about OpenStack and tend to compare it with other
cloud infrastructure products. Such audiences expect a coherent, relatively
mature product to easily evaluate, usually via proof-of-concept. Upon
deciding to implement OpenStack, the central documentation attempts to
gracefully lead them toward a production deployment that meets or exceeds
requirements and expectations.

However, since I began contributing to OpenStack documentation around the
Havana release, I am seeing many projects, particularly core projects,
trending toward more independence from other projects including central
documentation. For operator and user documentation, a couple of projects
contribute to the central documentation repository, some projects
contribute to their own repositories, and an alarmingly large number of
projects simply do not contribute such documentation and assume that all
audiences involve developers. These differences lead to an increasingly
negative overall experience for the audiences that OpenStack needs to
increase adoption/growth and maintain the existing deployment base.

As a contributor to central documentation and one or more other projects
including neutron, I see the problems from both sides and don't
particularly blame either party for them. Some politics, some technical,
some a lack of resources, and some just a general misunderstanding about
documentation. However, I think we need to develop a solution that works
for both parties and ultimately benefits our audiences.

One potential solution essentially involves moving operator and user
documentation into project repositories (similar to developer
documentation) and using infrastructure to coherently present it on
docs.openstack.org which achieves the following goals:

1) Project developers can contribute documentation and code in the same
patch, thus avoiding two different review queues and reviewers with
different motivations and guidelines.
2) Project developers can either work directly or via liaison with one or
more documentation team members to improve documentation components during
development or after merging technically accurate content.
3) Rather than attempting to document all projects with little (if any)
assistance from those projects, the primary role of the documentation team
becomes managing overall organization/presentation of documentation and
assisting projects with their contributions.

We're seeing decent adoption of moving API documentation into project
repositories, so I want to initiate some discussion about moving additional
documentation (or other options) prior to mid-cycles (including ops) and
the next summit.

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

Re: [openstack-dev] [all][oslo] Disable option value interpolation in oslo.config

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2016-07-08 13:27:04 -0500:
> On 07/08/2016 10:58 AM, Doug Hellmann wrote:
> > Excerpts from Ben Nemec's message of 2016-07-08 10:24:54 -0500:
> >> On 07/08/2016 09:14 AM, ChangBo Guo wrote:
> >>> Hi ALL,
> >>>
> >>> I have been working a bug [1] about option value interpolation in
> >>> oslo.config[2], in short, option value interpolation can't handle
> >>> password containing special characters from environment variable and I 
> >>> proposed a fix of provide way to forbid option value interpolation
> >>> explicitly[3]. 
> >>>
> >>> copy of Doug Hellmann's coments:
> >>>
> >>> "The problem is that the end user who is setting the value of the option
> >>> cannot control whether the option will do interpolation or not. So the
> >>> programmer who defines the option has to make that choice, and then we
> >>> can't change it because that would break existing deployments. The
> >>> result is that end users won't know for any given option whether
> >>> interpolation works or not, and if not why (did they do something wrong,
> >>> or is it not supported).
> >>>
> >>> I've set -2 on this patch because I think it's a bad approach. I see 2
> >>> other ways we could solve the problem you describe (and I agree that
> >>> it's an issue we should help with).
> >>>
> >>> 1. We could have an option that turns off interpolation globally, and
> >>> let the user control that by setting the flag in their configuration
> >>> file. I'm not sure I like this, but it does give you what you're looking
> >>> for at the risk of breaking applications that are relying on
> >>> interpolation, like the nova example.
> >>
> >> This feels like a big hammer for a relatively small edge case, and as
> >> you note it doesn't handle the case where you want to use interpolation,
> >> but have an environment variable default that breaks when interpolated.
> >>
> >>>
> >>> 2. We could disable interpolation when we get values from environment
> >>> variables. That would be a big behavioral change, so we would need to
> >>> think about how to roll it out carefully. For example, do we provide a
> >>> helper function to give to application developers who are setting
> >>> default values to environment variables so the variable value can be
> >>> escaped to avoid interpolation? Or do we build it into the Opt class
> >>> somehow? I think I like the helper function approach but we should give
> >>> it more thought."
> >>
> >> One possibility would be an "env_default" (or something) parameter to
> >> Opt that would read the env var, escape it as necessary, and set the opt
> >> default to the escaped value.  Then we could recommend that people stop
> >> using os.environ for setting defaults this way.  Using default and
> >> env_default at the same time would raise an exception.
> > 
> > That sounds a lot like my helper function example, but builds the
> > concept of taking a default from an environment variable into Opt.
> 
> Yeah, I was mostly +1'ing that suggestion and then brainstorming how to
> integrate it into the opt definition.  This seemed like the simplest way
> to do it, but the benefit of a separate helper function would be if
> there are other places we might want to do the same thing besides just
> the Opt constructor.  I could see someone wanting to set a None default
> and then conditionally set the default to an environment variable in
> their code, so maybe standalone would be better.

On the other hand, if we build "get a default from an environment
variable" into Opt, we can include that information in the help and
sample config output.

If we make the escaping function public, and then also use it to
implement the "environment_variable" behavior in Opt, that would give us
the best of both solutions.

Doug

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

Re: [openstack-dev] [neutron][linux bridge]

[Sławek Kapłoński]

Hello,

What about tc_lib.py and function to set bandwidth limits which
linuxbridge agent is currently using?

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Thu, 07 Jul 2016, Bhatia, Manjeet S wrote:

> Hi,
> 
> There is work in progress for pure python driven linux network configuration. 
> I think most
> of work will be done with this patch https://review.openstack.org/#/c/155631/ 
> . The only
> thing left after this will be linux bridge configuration, Which I would like 
> to discuss with
> community. There are two ways at the moment I can think to do that 
> implementation,
> First, use pybrctl which may need some changes in library itself in order for 
> full support.
> It will clean up the code from neutron. But looking pybrctl code which is 
> just executing
> Shell commands, another solution which Brandon Logan discussed is move the 
> existing
> Code for executing those commands to neutron-lib, which I think is better 
> solution. I would
> like to have views of community, especially people working neutron-lib about 
> moving
> python code for executing brctl commands to neutron-lib.
> 
> 
> Thanks and Regards !
> Manjeet Singh Bhatia

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



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