Re: [openstack-dev] I love csv output in openstackclient, please never removed it

[Daniel Comnea]

thanks for sharing, useful indeed.



On Fri, Oct 2, 2015 at 8:51 PM, Ricardo Carrillo Cruz <
ricardo.carrillo.c...@gmail.com> wrote:

> Erm, yeah, I hear your pain with processing output with awk.
>
> Having the option to output CSV is cool :-).
> Thanks for sharing.
>
> Cheers
>
> 2015-10-02 21:49 GMT+02:00 Thomas Goirand :
>
>> Hi,
>>
>> I saw the csv output format of openstackclient going and coming back.
>> Please leave it in, it's super useful, especially when you combine it
>> with "q-text-as-data". Just try to apt-get install q-text-as-data" and
>> try by yourself:
>>
>> openstack endpoint list --long -f csv | \
>> q -d , -H 'SELECT ID FROM - WHERE `Service Name`="cinder"'
>>
>> This is so much better than any awk hacks to get IDs... :)
>> I just wanted to share, hoping it could be useful to someone.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] - deprecation of max_fixed_ips_per_port

[Kevin Benton]

Hi,

There is an option in Neutron called max_fixed_ips_per_port that limits the
number of IP addresses that can be assigned to each port. It doesn't appear
to have a clear use case since we prevent users from setting IPs on ports
attached to networks they don't own (shared networks). I have filed a
bug[1] to deprecate it for removal in N.

If you have a use case for max_fixed_ips_per_port that I am missing, please
provide feedback on the bug report.


1. https://bugs.launchpad.net/neutron/+bug/1502356

Cheers
-- 
Kevin Benton
__
OpenStack Development Mailing 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] Fwd: [nova] live migration in Mitaka

[Pavel Boldin]

> Now the next challenge is with Ubuntu packages, only python-libvirt
> 1.2.15 is available in Ubuntu Willy. :-/
>
> Just create a PPA and build 1.2.17 from the git sources by copying the
`debian` directory from the package.

I can do it for you over the weekend if you want it.

Pavel
__
OpenStack Development Mailing 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] Fwd: [nova] live migration in Mitaka

[Mathieu Gagné]

On 2015-10-02 4:18 PM, Pavel Boldin wrote:
> 
> You have to pass device names from /dev/, e.g., if a VM has
> ephemeral disk
> attached at /dev/vdb you need to pass in 'vdb'. Format expected by
> migrate_disks is ",...".
> 
> 
> This is the format expected by the `virsh' utility and will not work in
> Python.
> 
> The libvirt-python has now support for passing lists to a parameter [1].
> 
> [1]
> http://libvirt.org/git/?p=libvirt-python.git;a=commit;h=9896626b8277e2ffba1523d2111c96b08fb799e8
>  

Thanks for the info. I was banging my head against the wall, trying to
understand why it didn't accept my list of strings.

Now the next challenge is with Ubuntu packages, only python-libvirt
1.2.15 is available in Ubuntu Willy. :-/

-- 
Mathieu

__
OpenStack Development Mailing 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] Fwd: [nova] live migration in Mitaka

[Pavel Boldin]

Resending, forgot to subscribe.



> You have to pass device names from /dev/, e.g., if a VM has ephemeral disk
> attached at /dev/vdb you need to pass in 'vdb'. Format expected by
> migrate_disks is ",...".
>

This is the format expected by the `virsh' utility and will not work in
Python.

The libvirt-python has now support for passing lists to a parameter [1].

[1]
http://libvirt.org/git/?p=libvirt-python.git;a=commit;h=9896626b8277e2ffba1523d2111c96b08fb799e8


Pavel
__
OpenStack Development Mailing 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] I love csv output in openstackclient, please never removed it

[Ricardo Carrillo Cruz]

Erm, yeah, I hear your pain with processing output with awk.

Having the option to output CSV is cool :-).
Thanks for sharing.

Cheers

2015-10-02 21:49 GMT+02:00 Thomas Goirand :

> Hi,
>
> I saw the csv output format of openstackclient going and coming back.
> Please leave it in, it's super useful, especially when you combine it
> with "q-text-as-data". Just try to apt-get install q-text-as-data" and
> try by yourself:
>
> openstack endpoint list --long -f csv | \
> q -d , -H 'SELECT ID FROM - WHERE `Service Name`="cinder"'
>
> This is so much better than any awk hacks to get IDs... :)
> I just wanted to share, hoping it could be useful to someone.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] What to do when a controller runs out of space

[Alex Schultz]

Hey All,

So I was working on Bug 1493520 which is about what happens when a
controller runs out of space. For this I came up with a solution[1] to
leverage pacemaker to migrate services away from the controller when
it runs out of space.  This works great for rabbitmq/mysql where if
they run out of space "Bad Things Happen"™. But there is a problem
that I didn't realize until QA got ahold of it. We run services
(neutron-server,heat,nova-api,etc) on our controllers that are not
managed via corosync so they still run and will attempt to serve
requests via the haproxy that was conveniently moved off of the bad
controller node.

So my question is, what should we do in this case? Should we be
managing the start/stop of these services via Pacemaker? We would get
additional benefits of having these services restarted if they crash
and they would get stopped when the node health goes red like the rest
of the services.  But this will add additional complexity if anyone
want to extract these services off of the controller to run on their
own.

Another solution would be to try and figure out some haproxy solution
for the node.  I'm not sure if haproxy has the concept of a node
health check like some other load-balancing solutions do. If it did,
we could just create a node health check that would down all the
services with a single check that could query the cluster health
status.

Thoughts?

Thanks,
-Alex


[0] https://bugs.launchpad.net/fuel/+bug/1493520
[1] https://review.openstack.org/#/c/226062/

__
OpenStack Development Mailing 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] I love csv output in openstackclient, please never removed it

[Thomas Goirand]

Hi,

I saw the csv output format of openstackclient going and coming back.
Please leave it in, it's super useful, especially when you combine it
with "q-text-as-data". Just try to apt-get install q-text-as-data" and
try by yourself:

openstack endpoint list --long -f csv | \
q -d , -H 'SELECT ID FROM - WHERE `Service Name`="cinder"'

This is so much better than any awk hacks to get IDs... :)
I just wanted to share, hoping it could be useful to someone.

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Ben Pfaff]

On Fri, Oct 02, 2015 at 10:07:32PM +0300, Gal Sagie wrote:
> If you are not familiar with Kuryr you can read my blog post about it here
> [1].
> Basically we already have a working demo integrating with Neutron and we
> are going to show
> it in OpenStack Tokyo (probably in the keynotes and in a specific Kuryr
> session).
> 
> For the OVN part, there are some areas that i want to work on:

Since it sounds like you're targeting a lot for Tokyo later this month,
I guess I can learn more then.  Thanks!

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

[openstack-dev] [openstack-ansible] Security spec status update

[Major Hayden]

Hello there,

A couple of people were asking me about the status of the security spec[1] for 
openstack-ansible.  Here are a few quick updates as of today:

  * We've moved away from considering CIS temporarily due to licensing and 
terms of use issues
  * We're currently adapting the RHEL 6 STIG[2] for Ubuntu 14.04
  * There's are lots of tasks coming together in a temporary repository[3]
  * Documentation is up on ReadTheDocs[4] (temporarily)

At this point, we have 181 controls left to evaluate (out of 264[5]).  Feel 
free to hop into #openstack-ansible and ask any questions you have about the 
work.

[1] 
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html
[2] http://iase.disa.mil/stigs/Pages/index.aspx
[3] https://github.com/rackerlabs/openstack-ansible-security
[4] http://openstack-ansible-security.readthedocs.org/en/latest/
[5] https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/

--
Major Hayden

__
OpenStack Development Mailing 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] New cycle started. What are you up to, folks?

[Gal Sagie]

Hi Ben,

If you are not familiar with Kuryr you can read my blog post about it here
[1].
Basically we already have a working demo integrating with Neutron and we
are going to show
it in OpenStack Tokyo (probably in the keynotes and in a specific Kuryr
session).

For the OVN part, there are some areas that i want to work on:

1) Exposing the ability in OVN to configure nested containers inside a VM
(thru a formal Neutron API)
(Which is also going to be used for the Magnum-Kuryr Integration as
this deployment is the main
 use case for Magnum)
2) Provide generic VIF binding layer for OVS (which can be used by OVN as
well) - This is already work in progress and will
be ready by the summit
3) Provide containerised OVN plugin image (Compatible with OpenStack Kolla
and Ansible) for deployment
4) VLAN allocation mechanism (for the nested containers)
5) As OVN mature, expose some of its features/applications, for example a
Distributed Load Balancer
can be used to replace Kubernetes services default LB implementation
(leveraging Neutron LBaaS API).
(And other Neutron features as they are implemented, for example
Neutron ports DNS resolution by name,
 tags to resources for pre-allocation of networks/ports for containers
and so on..)

If there are any people that want to join this effort from the OVN team,
you are always welcome.
I think this joint effort in the community is much better then every
project re-implementing this or
implementing specific Docker/Kubernetes integrations by their own.

[1]
http://galsagie.github.io/sdn/openstack/docker/kuryr/neutron/2015/08/24/kuryr-part1/

On Fri, Oct 2, 2015 at 3:50 PM, Ben Pfaff  wrote:

> On Fri, Oct 02, 2015 at 08:19:47AM +0300, Gal Sagie wrote:
> > *OVN*
> >
> >1) OVN integration with Kuryr
>
> Can you say anything more about what that entails?
>
> Thanks,
>
> Ben.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [infra] Some jobs erroneously passing today

[Jeremy Stanley]

On 2015-10-02 17:16:30 + (+), Jeremy Stanley wrote:
> A bug was introduced into jenkins-job-builder earlier today which
> caused some select jobs to always pass. The regression has been
> identified, reverted and all affected jobs updated, but any changes
> should be rechecked to get accurate results if they ran one or more
> of the following jobs between 04:15 and 17:15 UTC:
[...]

Due to cache-related issues some of these jobs were not correctly
updated, but have now been confirmed corrected as of 19:00 UTC.
Apologies for the false start.
-- 
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 + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 10/02/2015 02:26 PM, Murali R wrote:
> Hi Russell,
> 
> Thank you these are really good. Had a quick question. When you create a
> logical switch in your first script (line 23) - at what point is it
> associated with br-int ? Is it on line 45? So I can create any switch
> and when I associated logical port it associates logical switch ? Or is
> there a different way we can associate logical-phy switches? I was
> looking to get the logical associations during startup initialization.

To clarify, I believe you're talking about the first script from the
tutorial [1], which is:

  https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh

Most of that script is all configuring logical topology.  OVN does
nothing to the network until ovn-controller sees a port appear on br-int
that maps to a logical port.  This mapping is done by setting the
"iface-id" to the name of the logical port.

Once ovn-controller has mapped a port on br-int to a logical port, it
can configure the switch appropriately for that port.

Does that make sense?

[1] https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md

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

Re: [openstack-dev] [Fuel] backporting before merging to master

[Dmitry Borodaenko]

Thanks Matt for raising this topic once again, I strongly agree with
you, I've even added the following wording to our backports policy back
in March to address the same problem:

  "For a bug targeted for stable release series, cherry-pick the fix
  commit onto the stable/x.x branch for each series it is targeted for,
  *after* the fix was merged to master (creating backports prematurely
  leads to possible inconsistency between master and stable/x.x versions
  of the same commit)."

[0] 
https://wiki.openstack.org/w/index.php?title=Fuel%2FHow_to_contribute&diff=75254&oldid=74351

At the same time I agree with Dmitry, we should not abuse the -2 code
review vote, and leave it for indicating that the commit should not be
merged even if updated (in case of backports, indicating that the code
change is too disruptive to be allowed in a stable branch).

I think we can deal with this on a case by case basis.

If you are a core reviewer looking at a commit to a stable branch, and
the master version of the commit is not yet merged, just quote the above
fragment from the policy in your -1 comment (unless other reviewers
already done that) and move on.

If you notice someone repeating this mistake more than once, reach out
to them in private and point them at the wiki and at this thread, and
explain that this kind of behaviour is harmful in that it pollutes
review queue and distracts reviewers.

Thanks,

-- 
Dmitry Borodaenko


On Fri, Oct 02, 2015 at 02:56:50PM +0300, Dmitry Pyzhov wrote:
> I'm not sure if core reviewers should be so harsh. But the guideline seems
> to be very useful. Guys, please don't create backports too early.
> 
> On Fri, Oct 2, 2015 at 2:00 PM, Matthew Mosesohn 
> wrote:
> 
> > Hi Fuelers,
> >
> > I would like to address a concern I have with backporting policy. I'm sure
> > all of you know that we should always land patches to master before it
> > reaches stable/X.X branch. What you are not aware of probably is that many
> > people are making cherry picks well in advance of gathering reviews and
> > getting the patch landed in master. Some argue that it "saves time waiting
> > on CI", but in reality it's quite the opposite. Adding a cherry pick before
> > merging master causes the following workflow to take place:
> > 1 - Propose to master and to stable/7.0
> > 2 - CI runs on 2 patches
> > 3 - Reviewer A comments on master patch
> > 4 - owner adjusts both patches and runs CI
> > 5 - Reviewer B comments on stable patch
> > 6 - owner adjusts both patches and runs CI
> > (repeat 3-6 in varying degrees until enough patches are gathered)
> > 7 - rebase stable/7.0 patch again... wait for CI again
> >
> > This doubles the burden on CI and complicates the overall review process
> > where we are accepting feedback for the initial solution on two (nearly)
> > identical patches. What's worse is it's possible that the two solutions
> > merged won't be identical and introduce potential regressions.
> >
> > I propose we avoid raising any stable/X.X patches before a patch is
> > _merged_ into master to avoid this scenario. Additionally, if a core sees
> > that this is happening, he or she should mark it -2 and discourage
> > submission of new patchsets.
> >
> > I welcome your thoughts and feedback.
> >
> > Best Regards,
> > Matthew Mosesohn
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

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


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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Murali R]

Hi Russell,

Thank you these are really good. Had a quick question. When you create a
logical switch in your first script (line 23) - at what point is it
associated with br-int ? Is it on line 45? So I can create any switch and
when I associated logical port it associates logical switch ? Or is there a
different way we can associate logical-phy switches? I was looking to get
the logical associations during startup initialization.

On Fri, Oct 2, 2015 at 8:27 AM, Russell Bryant  wrote:

> On 09/27/2015 04:18 PM, Russell Bryant wrote:
> > On 09/27/2015 06:50 AM, Kevin Benton wrote:
> >> Assuming it implements the normal provider networks API, you just
> >> specify the segmentation_id when you create the network.
> >>
> >> neutron net-create NET_NAME --provider:network_type vlan
> >> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG
> >
> > Yes, the OVN plugin will implement the normal provider networks API.
> > It's a WIP.
> >
> > My first goal was to just implement support for "--provider:network_type
> > flat" end to end.  I have the OVN side merged and now I'm working on the
> > Neutron plugin piece.  Once that's done, I'll go back add add VLAN
> > support, which shouldn't be very difficult at that point.  I'm aiming to
> > have all of that done by the Tokyo summit (among other things).
>
> Just as a brief follow-up here, I finished the VLAN provider network
> support for OVN here:
>
>
> https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5
>
> I also wrote an OVN tutorial this week.  Examples 4 and 5 cover how
> provider networks are modeled in OVN.
>
> https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
>
> I have the Neutron API patch posted here:
>
> https://review.openstack.org/#/c/228573/
>
> I did the patch before I finished the VLAN support.  Adding the VLAN bit
> will be a trivial update, though.
>
> --
> 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-dev] [Congress] Usecase VM related questions

[Shiv Haris]

Tim,

Answers to your questions while I was away:

>Do you think docker images would be significantly smaller than the VM?
>If not, I don't see a good reason to move to docker.

Yes it will be smaller because we will not be shipping the OS image

>BTW—I tried the ssh, and it worked great.
Cool

>is it going to be easy to deal with multiple use cases on a single VM?
>for example, if we create servers, networks, etc. for use case 1, will there 
>be conflicts when we setup use case 2?
>Do we have a script that can undo the changes from use_case 1 before setting 
>up use case 2?
Unfortunately there is no easy way to cleanup and keep the same OS instance. I 
recommend the steps in the 00_restart_openstack.sh as the way to get a clean 
start for the next congress use case.

-Shiv



__
OpenStack Development Mailing 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] New cycle started. What are you up to, folks?

[Miguel Angel Ajo]

Moshe Levi wrote:

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com]
Sent: Thursday, October 01, 2015 6:42 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [neutron] New cycle started. What are you up
to, folks?

On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:

On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins

wrote:

On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:

- more changes with less infra tinkering! neutron devs should not
need

to go to infra projects so often to make an impact;

-- make our little neat DevStack plugin used for qos and sr-iov
only a

huge pile of bash code that is currently stored in DevStack and is
proudly called neutron-legacy now; and make the latter obsolete and
eventually removed from DevStack;

We may need to discuss this. I am currently doing a refactor of the
Neutron DevStack integration in

https://review.openstack.org/168438

If I understand your message correctly, I disagree that we should be
moving all the DevStack support for Neutron out of DevStack and
making it a plugin. All that does is move the mess from one corner
of the room, to another corner.



I would actually be in favor of cleaning up the mess AND moving it
into neutron. If it's in Neutron, we control our own destiny with
regards to landing patches which affect DevStack and ultimately our
gate jobs. To me, that's a huge win-win. Thus, cleanup first, then move to

Neutron.

Frankly we have a bad track record in DevStack, if we are to make an
argument about controlling our own destiny. Neutron-lib is in a sad state of
affairs because we haven't had the discipline to keep things simple.

In fact, I think the whole genesis of the Neutron plugin for DevStack is a great
example of how controlling our own destiny has started to grow the mess.
Yes, we needed it to gate the QoS code. But now things are starting to get
added.

https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa26
1b8686072d9b448e8


I think the decision  should be based on where is the core code located.
So if SR-IOV, OVS ,Linux Bridge, Qos are still in the neutron core the neutron 
devstack plugin
should know how to install them. If we will decide to move them to different 
repos the
their devstack part should be moved as well.

That is correct. Eventually, we should either:

1) Move all neutron devstack code into a plugin
2) Or move the QoS bits back into devstack.

The decision to make QoS part of the core was because we're extending 
core resources, and our final aim
is to make it available to all plugins ( here's where the final core 
resource extension manager that Ihar

pointed out comes in place.)



The trend is now that people are going to throw things into the Neutron
DevStack plugin to get their doo-dad up and running, because making a new
repo is harder than creating a patch (which maybe shows are repo creation
process needs streamlining). I was originally for making Neutron DevStack
plugins that exist in their own repos,
Sincerely, Sean, IMHO it doesn't make any sense to create a repository 
uniquely for a devstack plugin

to enable a feature which is in the main repository. That's also broken.

Would you ask for a separate devstack plugin for l3  too?


instead of putting them in the Neutron
tree. At least that makes things small, manageable, and straight forward. Yes,
it makes for more plugin lines in your DevStack configuration, but at least you
know what each one does, instead of being an agglomeration.

If we are not careful, the Neutron DevStack plugin will grow into the big mess
that neutron-legacy is.


It's a good opportunity to refactor as we move, if "1" is a good 
strategy, otherwise, and if you think

neutron-legacy is a mess, let's work on cleaning it up while at "2".



Finally, Look at how many configuration knobs we have, and how there is a
tendency to introduce new ones, instead of using local.conf to inject
configuration into Neutron and the associated components. This ends up
making it very complicated for someone to actually run Neutron in their
DevStack, and I think a lot of people would give up and just run Nova-
Network, which I will note is *still the default*.


Hmm, I'm not sure I follow, so, if people need to tweak localrc in 
extremis, that's even going

to be more painful from the user/developer perspective.



We need to keep our ties strong with other projects, and improve them in
some cases. I think culturally, if we start trying to move things into our 
corner
of the sandbox because working with other groups is hard, we send bad
signals to others. This will eventually come back to bite us.

/rant

--
Sean M. Collins



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

[openstack-dev] [infra] Some jobs erroneously passing today

[Jeremy Stanley]

A bug was introduced into jenkins-job-builder earlier today which
caused some select jobs to always pass. The regression has been
identified, reverted and all affected jobs updated, but any changes
should be rechecked to get accurate results if they ran one or more
of the following jobs between 04:15 and 17:15 UTC:

api-site-tox-doc-publishdocs
api-site-tox-doc-publishlang
devstack-publish-docs
gate-anchor-tox-bandit
gate-api-site-tox-checkdeletions
gate-api-site-tox-checklang
gate-api-site-tox-checklinks
gate-api-site-tox-checkniceness
gate-api-site-tox-checksyntax
gate-api-site-tox-doc-publish-checkbuild
gate-barbican-tox-bandit
gate-cliff-tox-neutronclient-tip
gate-cliff-tox-openstackclient-tip
gate-cloud-init-tox-py27-coverage
gate-cloud-init-tox-py34-coverage
gate-defcore-tox-doc8
gate-devstack-bashate
gate-devstack-plugin-amqp1-bashate
gate-devstack-plugin-bdd-bashate
gate-devstack-plugin-glusterfs-bashate
gate-devstack-plugin-hdfs-bashate
gate-devstack-plugin-sheepdog-bashate
gate-devstack-plugin-zmq-bashate
gate-devstack-publish-docs
gate-drbd-devstack-bashate
gate-elastic-recheck-tox-queries
gate-generate-specs-site
gate-gnocchi-bashate
gate-grenade-publish-docs
gate-ha-guide-tox-checkdeletions
gate-ha-guide-tox-checklang
gate-ha-guide-tox-checklinks
gate-ha-guide-tox-checkniceness
gate-ha-guide-tox-checksyntax
gate-ha-guide-tox-doc-publish-checkbuild
gate-heat-coe-templates-tox-lint
gate-horizon-jshint
gate-horizon-tox-py27dj18
gate-infra-docs-index
gate-irc-meetings-tox-ical
gate-ironic-inspector-tox-func
gate-keystone-tox-bandit
gate-keystonemiddleware-tox-bandit
gate-kolla-bashate
gate-kolla-tox-validate-contents
gate-magnum-tox-bandit
gate-manila-image-elements-tox-buildimage
gate-manila-tox-genconfig
gate-mistral-tox-unit-postgresql
gate-neutron-pypy-constraints
gate-neutron-python27-constraints
gate-neutron-python34-constraints
gate-nova-pip-missing-reqs
gate-nova-tox-functional
gate-openstack-ansible-bashate
gate-openstack-manuals-tox-checkdeletions
gate-openstack-manuals-tox-checklang
gate-openstack-manuals-tox-checklinks
gate-openstack-manuals-tox-checkniceness
gate-openstack-manuals-tox-checksyntax
gate-openstack-manuals-tox-doc-publish-checkbuild
gate-operations-guide-tox-checkdeletions
gate-operations-guide-tox-checklang
gate-operations-guide-tox-checklinks
gate-operations-guide-tox-checkniceness
gate-operations-guide-tox-checksyntax
gate-operations-guide-tox-doc-publish-checkbuild
gate-oslo-cookiecutter-tox-cookiecutter
gate-oslo.db-tox-mysql-python
gate-oslo.db-tox-sqla_08
gate-oslo.db-tox-sqla_09
gate-oslo.vmware-tox-bandit
gate-packstack-vagrant-tox-lint
gate-pecan-tox-barbican-stable
gate-pecan-tox-barbican-tip
gate-pecan-tox-ceilometer-stable
gate-pecan-tox-ceilometer-tip
gate-pecan-tox-designate-stable
gate-pecan-tox-designate-tip
gate-pecan-tox-gnocchi-stable
gate-pecan-tox-gnocchi-tip
gate-pecan-tox-ironic-stable
gate-pecan-tox-ironic-tip
gate-pecan-tox-magnum-stable
gate-pecan-tox-magnum-tip
gate-pecan-tox-scaffolds-27
gate-pecan-tox-scaffolds-34
gate-pecan-tox-wsme-stable
gate-pecan-tox-wsme-tip
gate-project-config-dib
gate-project-config-irc-access
gate-project-config-jenkins-project
gate-project-config-layout
gate-project-config-projects-yaml
gate-python-ironic-inspector-client-tox-func
gate-python-keystoneclient-tox-bandit
gate-python-magnumclient-tox-bandit
gate-rally-tox-self
gate-release-tools-bashate
gate-releases-tox-list-changes
gate-releases-tox-validate
gate-requests-mock-tox-keystoneclient-tip
gate-requests-mock-tox-novaclient-tip
gate-requirements-tox-validate
gate-sahara-tox-bandit
gate-sahara-tox-py27-scenario-unit
gate-security-doc-tox-checkdeletions
gate-security-doc-tox-checklang
gate-security-doc-tox-checklinks
gate-security-doc-tox-checkniceness
gate-security-doc-tox-checksyntax
gate-security-doc-tox-doc-publish-checkbuild
gate-sqlalchemy-migrate-tox-py26sa07
gate-sqlalchemy-migrate-tox-py27sa07
gate-swift-tox-func
gate-swift3-tox-keystone
gate-swift3-tox-s3acl
gate-swift3-tox-tempauth
gate-system-config-bashate
gate-system-config-nodepool
gate-tooz-tox-py27-memcached
gate-tooz-tox-py27-mysql
gate-tooz-tox-py27-postgresql
gate-tooz-tox-py27-redis
gate-tooz-tox-py27-sentinel
gate-tooz-tox-py27-zookeeper
gate-tooz-tox-py34-memcached
gate-tooz-tox-py34-mysql
gate-tooz-tox-py34-postgresql
gate-tooz-tox-py34-redis
gate-tooz-tox-py34-sentinel
gate-tooz-tox-py34-zookeeper
gate-training-guides-tox-checkdeletions
gate-training-guides-tox

[openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

[Sheena Gregson]

Forwarding since Chris isn’t subscribed.



*From:* Chris Clason [mailto:ccla...@mirantis.com]
*Sent:* Friday, October 02, 2015 6:30 PM
*To:* Sheena Gregson ; OpenStack Development Mailing
List (not for usage questions) 
*Subject:* Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC



We are doing some technology evaluations with the intent of publishing
reference architectures at various scale points (500, 1500, 2000 etc). Part
of this work will be to determine how to best partition the nodes in to
regions based on scale limits of OpenStack components and workload
characteristics. The work we are doing increased in scope significantly, so
the first RA will be coming at the end of Q1 or early Q2.



We do plan on using some components of Fuel for our testing but the main
purpose is path finding. The work we do will eventually make it into Fuel,
but we are going to run in front of it a bit.



On Fri, Oct 2, 2015 at 9:19 AM Sheena Gregson  wrote:

Plans for multi-DC: my understanding is that we are working on developing a
whitepaper in Q4 that will provide a possible OpenStack multi-DC
configuration, but I do not know whether or not we intend to include Fuel
in the scope of this work (my guess would be no).  Chris – I copied you in
case you wanted to comment here.



Regarding specifying region names in UI, is it possible to specify region
names in API?  And (apologies for my ignorance on this one) what is the
relative equivalence to environments in Fuel (e.g. 1 environment : many
regions, 1 environment == 1 region)?



*From:* Roman Sokolkov [mailto:rsokol...@mirantis.com]
*Sent:* Friday, October 02, 2015 5:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC



Folks,



i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
support.



My ask is about tiny(but useful) feature: give user ability to *specify
Region name in UI.*



Region name is already in every puppet module, so we just need to add this
to UI.



Do we have smth already?



More general question: What are our plans in regards Multi-DC?



Thanks



-- 

Roman Sokolkov,

Deployment Engineer,

Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com

-- 

Chris Clason

Director of Architecture

ccla...@mirantis.com

Mobile: +1.408.409.0295
__
OpenStack Development Mailing 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] live migration in Mitaka

[Kashyap Chamarthy]

On Fri, Oct 02, 2015 at 06:20:31AM +, Koniszewski, Pawel wrote:
> > -Original Message-
> > From: Mathieu Gagné [mailto:mga...@internap.com]
> > Sent: Thursday, October 1, 2015 7:24 PM
> > To: OpenStack Development Mailing List (not for usage questions)

[. . .]

> > >> I have taken the liberty of listing those that responded to the
> > >> thread and the authors of mentioned patches as interested people.
> > >
> > >> From the responses and looking at the specs up for review it looks
> > >> like there are about five areas that could be addressed in Mitaka and
> > >> several others that could come later. The first five are:
> > >>
> > >>
> > >> - migrating instances with a mix of local disks and cinder volumes
> > >
> > > IIUC, this is possible with the selective block device migration work
> > > merged in upstream libvirt:
> > >
> > > https://www.redhat.com/archives/libvir-list/2015-May/msg00955.html
> > >
> > 
> > Can someone explain to me what is the actual "disk name" I have to pass in
> > to libvirt? I couldn't find any documentation about how to use this
> feature.
> 
> You have to pass device names from /dev/, e.g., if a VM has ephemeral disk
> attached at /dev/vdb you need to pass in 'vdb'. Format expected by
> migrate_disks is ",...".

Yeah, you can enumerate the current block devices for an instance by
doing:

$ virsh domblklist instance-0001

[If you're curious, the 'v' in the 'vda/vdb' stands for 'virtio' disks.
For non-virtio disks, you'd see a device name like 'hda'.]

-- 
/kashyap

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

Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC

[Sheena Gregson]

Plans for multi-DC: my understanding is that we are working on developing a
whitepaper in Q4 that will provide a possible OpenStack multi-DC
configuration, but I do not know whether or not we intend to include Fuel
in the scope of this work (my guess would be no).  Chris – I copied you in
case you wanted to comment here.



Regarding specifying region names in UI, is it possible to specify region
names in API?  And (apologies for my ignorance on this one) what is the
relative equivalence to environments in Fuel (e.g. 1 environment : many
regions, 1 environment == 1 region)?



*From:* Roman Sokolkov [mailto:rsokol...@mirantis.com]
*Sent:* Friday, October 02, 2015 5:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC



Folks,



i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
support.



My ask is about tiny(but useful) feature: give user ability to *specify
Region name in UI.*



Region name is already in every puppet module, so we just need to add this
to UI.



Do we have smth already?



More general question: What are our plans in regards Multi-DC?



Thanks



-- 

Roman Sokolkov,

Deployment Engineer,

Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][tc][elections] Voting for the TC Election is now open

[Tristan Cacqueray]

Voting for the TC Election is now open and will remain open until 23:59
UTC October 9th 2015.

We are electing 6 positions from a pool of 19 candidates[0].

When you receive your email providing your link to the ballot, follow
the instructions that are available on the page where you may vote. If
you are confused and need more instruction, close the webpage without
submitting your vote and then email myself and Tony[1]. Your ballot will
still be enabled to vote until the election is closed, as long as you
don't submit your ballot before your close your webpage.

We are selecting 6 TC members, please rank all candidates in your order
of preference.

You are eligible to vote if are a Foundation individual member[2] that
also has committed to one of the official programs projects[3] over the
Juno-Kilo timeframe (April 9, 2014 06:00 UTC to April 9, 2015 05:59 UTC)
or if you are one of the extra-atcs.[4]

What to do if you don't see the email and have a commit in at least one
of the official programs projects[3]:
  * check the trash or spam folder of your gerrit Preferred Email
address[5], in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project
repos[3] and email me and Tony[1]. If we can confirm that you are
entitled to vote, we will add you to the voters list and you will
be emailed a ballot.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names[0].

Happy voting,
Thank you,
Tristan

[0]:
https://wiki.openstack.org/wiki/TC_Elections_September/October_2015#Confirmed_Candidates
[1]: Tony's email: tony at bakeyournoodle dot com
 Tristan's email: tdecacqu at redhat dot com
[2]: http://www.openstack.org/community/members/
[3]:
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections
Note the tag for this repo, sept-2015-elections.
[4]:
http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2015-elections
[5]: Sign into review.openstack.org: Go to Settings > Contact
Information. Look at the email listed as your Preferred Email. That is
where the ballot has been sent.



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

[openstack-dev] [Fuel] Nominate Alexander Adamov and Olena Logvinova for fuel-docs cores

[Olga Gusarenko]

Dear Fuelers,

I would like to nominate Alexander Adamov and Olena Logvinova for the
fuel-docs-core status:

http://stackalytics.com/?user_id=aadamov&release=all&project_type=all&module=fuel-docs
http://stackalytics.com/?user_id=ologvinova&release=all&project_type=all&module=fuel-docs

They are making a great contribution into Fuel documentation as
professional technical writers. And it is high time to grant them core
reviewer's rights within fuel-docs.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

-- 
Best regards,
Olga

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

[openstack-dev] [puppet] new juno release

[Emilien Macchi]

We're happy to announce the release of:
* puppet-nova 5.2.1
* puppet-neutron 5.2.1
* puppet-cinder 5.2.0
* puppet-glance 5.2.0
* puppet-ceilometer 5.2.0
* puppet-heat 5.2.0
* puppet-keystone 5.2.0
* puppet-openstack_extras 5.1.0

More details about releases:
https://wiki.openstack.org/wiki/Puppet/releases
-- 
Emilien Macchi



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

Re: [openstack-dev] [neutron][ovn] New cycle started. What are you up to, folks?

[Miguel Angel Ajo]

Very nice thread. Sharing is caring, so... (please notice some of my 
ideas are aligned with Ihar):


* Kill bugs
* Kill bugs
* Kill bugs

* RPC Neutron Objects Callback:
- upgrade path: That wasn't needed before, but we're going to need it.
- implement an strategy to avoid the out-of-order issues in RPC 
messages to agents,
  if we can make it work for this API, and do it all with 
NeutronObjects (versioned objects),

  we could slim down the RPC in a lot of places.

* Keep working on the QoS challenges
   - help people with modeling new rules (DSCP first, probably),
   - ingress & egress path for bw control (already looking at this).
   - Working on bandwidth guarantees (best effort, and strict).
   - Nova integration (no overcommits/scheduling.)

* Helping on the OVS/CT firewall driver effort to cut out the complexity 
and enhance the performance

   of the security groups for the reference solution.

* Help with implementing traffic classifiers common API, and translators 
to iptables and openflow rules

   for linux agents consumption.


Russell Bryant wrote:

On 10/02/2015 11:32 AM, Russell Bryant wrote:

On 10/01/2015 03:26 PM, Russell Bryant wrote:

On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote:

Hi all,

I talked recently with several contributors about what each of us
plans for the next cycle, and found it’s quite useful to share
thoughts with others, because you have immediate yay/nay feedback,
and maybe find companions for next adventures, and what not. So
I’ve decided to ask everyone what you see the team and you
personally doing the next cycle, for fun or profit.

That’s like a PTL nomination letter, but open to everyone! :) No
commitments, no deadlines, just list random ideas you have in mind
or in your todo lists, and we’ll all appreciate the huge pile of
awesomeness no one will ever have time to implement even if
scheduled for Xixao release.

To start the fun, I will share my silly ideas in the next email.

Nice thread!

Here's a rough cut of what I have in mind.  My Neutron related
development time covers a few areas: Neutron, OVN itself, and the
networking-ovn plugin for Neutron.

For Neutron:

  - general code reviews.  I'm especially interested in reviewing the
design and implementation of any new APIs people are adding.  Feel
free to add me to reviews you think I could help with and I'll take
a look.

  - plugin infrastructure.  Ihar mentioned in one of his items that
there are features implemented as ML2 specific.  That has started
to be a pain for networking-ovn.  For example, the provider networks
extension is only implemented for ML2, and the data is only stored
in an ML2 specific db table.  The db table and related code should
be reusable by other plugins.  I'd like to help start to clean that
up for the sake of other plugins.

For OVN and networking-ovn:

First, for anyone not already familiar with OVN, it is an effort
within the Open vSwitch project to build a virtual networking control
plane for OVS.  There are several projects that have implemented
something in this space (including Neutron).  OVN is intended to be a
new, common implementation of this functionality that can be reused in
many contexts, including by Neutron.  It includes a focus on
implementation of features taking advantage of the newest features of
OVS, including some still being added as we go.  There was a
presentation about this in Vancouver [1] and we'll be doing another
one covering current status in Tokyo [2].

This plugin is developed in parallel with OVN itself.  My time on each
changes week to week, depending on what I'm working on.  The dev items
I expect in the near future (this release cycle at least) include:

  - security groups.  This is being implemented using conntrack suport
in OVS.  There's actually WIP code for this including kernel
changes, ovs userspace changes, OVN, and networking-ovn.  This is a
complex stack of dependencies, but it's starting to fall into place.
Most of the kernel changes have been accepted, thought there's
another change being reviewed now.  The OVS userspace changes have
been under review in the last few weeks and are close to being
merged.  Once that's done, we can finish up testing the OVN and
networking-ovn patches.  We expect this to be done by Tokyo.

  - provider networks.  There's a lot of demand in OpenStack for
supporting direct connectivity to existing networks as a simpler
deployment model without any overlays.  I've done most of the work
for both OVN and networking-ovn for this now and expect to have it
wrapped up in the next week or so.

  - L3.  So far we've been using Neutron's L3 agent with networking-ovn.
OVN will have native L3 support (will no longer use the L3 agent)
and development on that has now started.  We aim to at least have
initial distributed L3 support by Tokyo.  Some of it will certainly
extend past that, though.  For exa

Re: [openstack-dev] [all] Doc dependencies

[Jeremy Stanley]

On 2015-10-02 10:20:49 -0500 (-0500), Kevin L. Mitchell wrote:
[...]
> it feels wrong for us to install dependencies not directly related
> to testing, even if we also test the doc generation.
[...]

It's a bit of a mischaracterization to suggest that there is some
specific set of "dependencies [...] directly related to testing" in
a more tightly-coupled fashion than those required for testing the
included documentation builds. If you wanted to start splitting
these up, really just about every environment defined in tox could
conceivably have its own specific set of requirements which omits
those only used by the other environments (for example, why install
modules that won't be imported during a pep8 run? why install static
analysis tools when running unit tests?).

At least for now we can sort of draw a fuzzy line around things not
commonly used at run-time and call them testing-related.
-- 
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] [nova] live migration in Mitaka

[Rosa, Andrea (HP Cloud Services)]

Hi all

 
> Not all of these are covered by specs yet and all the existing specs need
> reviews. Please look at the etherpad and see if there is anything you think is
> missing.

What about adding a way to migrate files which are not migrated at the moment, 
like console.log?
I think that could be used to  migrate the unrescue.xml file as well and then 
we could enable the migration for instances in rescue state.
If we can't configure libvirt/QEMU to migrate those files, the only idea I have 
is using RPC mechanism,  any other ideas?
I'd like to have some opinions before proposing a new spec.

Thanks
--
Andrea Rosa

__
OpenStack Development Mailing 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][ovn] New cycle started. What are you up to, folks?

[Russell Bryant]

On 10/02/2015 11:32 AM, Russell Bryant wrote:
> On 10/01/2015 03:26 PM, Russell Bryant wrote:
>> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote:
>>> Hi all,
>>>
>>> I talked recently with several contributors about what each of us 
>>> plans for the next cycle, and found it’s quite useful to share 
>>> thoughts with others, because you have immediate yay/nay feedback, 
>>> and maybe find companions for next adventures, and what not. So
>>> I’ve decided to ask everyone what you see the team and you
>>> personally doing the next cycle, for fun or profit.
>>>
>>> That’s like a PTL nomination letter, but open to everyone! :) No 
>>> commitments, no deadlines, just list random ideas you have in mind
>>> or in your todo lists, and we’ll all appreciate the huge pile of 
>>> awesomeness no one will ever have time to implement even if
>>> scheduled for Xixao release.
>>>
>>> To start the fun, I will share my silly ideas in the next email.
>>
>> Nice thread!
>>
>> Here's a rough cut of what I have in mind.  My Neutron related
>> development time covers a few areas: Neutron, OVN itself, and the
>> networking-ovn plugin for Neutron.
>>
>> For Neutron:
>>
>>  - general code reviews.  I'm especially interested in reviewing the
>>design and implementation of any new APIs people are adding.  Feel
>>free to add me to reviews you think I could help with and I'll take
>>a look.
>>
>>  - plugin infrastructure.  Ihar mentioned in one of his items that
>>there are features implemented as ML2 specific.  That has started
>>to be a pain for networking-ovn.  For example, the provider networks
>>extension is only implemented for ML2, and the data is only stored
>>in an ML2 specific db table.  The db table and related code should
>>be reusable by other plugins.  I'd like to help start to clean that
>>up for the sake of other plugins.
>>
>> For OVN and networking-ovn:
>>
>> First, for anyone not already familiar with OVN, it is an effort
>> within the Open vSwitch project to build a virtual networking control
>> plane for OVS.  There are several projects that have implemented
>> something in this space (including Neutron).  OVN is intended to be a
>> new, common implementation of this functionality that can be reused in
>> many contexts, including by Neutron.  It includes a focus on
>> implementation of features taking advantage of the newest features of
>> OVS, including some still being added as we go.  There was a
>> presentation about this in Vancouver [1] and we'll be doing another
>> one covering current status in Tokyo [2].
>>
>> This plugin is developed in parallel with OVN itself.  My time on each
>> changes week to week, depending on what I'm working on.  The dev items
>> I expect in the near future (this release cycle at least) include:
>>
>>  - security groups.  This is being implemented using conntrack suport
>>in OVS.  There's actually WIP code for this including kernel
>>changes, ovs userspace changes, OVN, and networking-ovn.  This is a
>>complex stack of dependencies, but it's starting to fall into place.
>>Most of the kernel changes have been accepted, thought there's
>>another change being reviewed now.  The OVS userspace changes have
>>been under review in the last few weeks and are close to being
>>merged.  Once that's done, we can finish up testing the OVN and
>>networking-ovn patches.  We expect this to be done by Tokyo.
>>
>>  - provider networks.  There's a lot of demand in OpenStack for
>>supporting direct connectivity to existing networks as a simpler
>>deployment model without any overlays.  I've done most of the work
>>for both OVN and networking-ovn for this now and expect to have it
>>wrapped up in the next week or so.
>>
>>  - L3.  So far we've been using Neutron's L3 agent with networking-ovn.
>>OVN will have native L3 support (will no longer use the L3 agent)
>>and development on that has now started.  We aim to at least have
>>initial distributed L3 support by Tokyo.  Some of it will certainly
>>extend past that, though.  For example, NAT will be implemented with
>>an OVS native solution, and that will likely not be ready by Tokyo.
>>We may be able to deliver an intermediary NAT solution quicker.
>>
>>  - SFC.  There's a ton of interest in SFC.  I've been casually following
>>the networking-sfc project and the Neutron API they are proposing.
>>I've also been thinking about how to implement it in OVN.  I think
>>OVN's logical flows abstraction is going to make it surprisingly easy
>>to implement.  I think I have a good idea of what needs to be done,
>>but I'm not sure of when it will bubble up on my todo list.  I hope
>>to work on it for this dev cycle though.  I'd first be implementing
>>it in OVN, and then later doing the support for the networking-sfc
>>API.
>>
>>  - l2gw.  OVN already includes support for VTEP gateways.  We also just
>>merged a patch to sup

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Neil Jerram]

On 01/10/15 14:47, Ihar Hrachyshka wrote:
> Hi all,
>
> I talked recently with several contributors about what each of us plans for 
> the next cycle, and found it’s quite useful to share thoughts with others, 
> because you have immediate yay/nay feedback, and maybe find companions for 
> next adventures, and what not. So I’ve decided to ask everyone what you see 
> the team and you personally doing the next cycle, for fun or profit.
>
> That’s like a PTL nomination letter, but open to everyone! :) No commitments, 
> no deadlines, just list random ideas you have in mind or in your todo lists, 
> and we’ll all appreciate the huge pile of awesomeness no one will ever have 
> time to implement even if scheduled for Xixao release.

:-)

My plans are centred around the model for routed networking, and Calico
as a particular implementation of that.  But I'd also like to continue
understanding Neutron more broadly and deeply, so that I can be more
generally helpful.

_Routed networking and Calico_

- Help Carl to define API and data model enhancements that describe
routed networking semantics.

- Help with the core Neutron implementation of that.

- Update networking-calico accordingly.

- Enhance pluggable IPAM so that IP allocation for an instance can
depend on where that instance's host is.  (This is relevant when the
Neutron network maps onto some relatively complex physical network, and
for route aggregation on fabric routers.)

_Wider Neutron_

- Better understand L3 initiatives like BGP dynamic routing.

- Better understand Neutron scaling.

- Contribute more across the board.


Hope that's useful!

Neil


__
OpenStack Development Mailing 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][ovn] New cycle started. What are you up to, folks?

[Russell Bryant]

On 10/01/2015 03:26 PM, Russell Bryant wrote:
> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote:
>> Hi all,
>>
>> I talked recently with several contributors about what each of us 
>> plans for the next cycle, and found it’s quite useful to share 
>> thoughts with others, because you have immediate yay/nay feedback, 
>> and maybe find companions for next adventures, and what not. So
>> I’ve decided to ask everyone what you see the team and you
>> personally doing the next cycle, for fun or profit.
>>
>> That’s like a PTL nomination letter, but open to everyone! :) No 
>> commitments, no deadlines, just list random ideas you have in mind
>> or in your todo lists, and we’ll all appreciate the huge pile of 
>> awesomeness no one will ever have time to implement even if
>> scheduled for Xixao release.
>>
>> To start the fun, I will share my silly ideas in the next email.
> 
> Nice thread!
> 
> Here's a rough cut of what I have in mind.  My Neutron related
> development time covers a few areas: Neutron, OVN itself, and the
> networking-ovn plugin for Neutron.
> 
> For Neutron:
> 
>  - general code reviews.  I'm especially interested in reviewing the
>design and implementation of any new APIs people are adding.  Feel
>free to add me to reviews you think I could help with and I'll take
>a look.
> 
>  - plugin infrastructure.  Ihar mentioned in one of his items that
>there are features implemented as ML2 specific.  That has started
>to be a pain for networking-ovn.  For example, the provider networks
>extension is only implemented for ML2, and the data is only stored
>in an ML2 specific db table.  The db table and related code should
>be reusable by other plugins.  I'd like to help start to clean that
>up for the sake of other plugins.
> 
> For OVN and networking-ovn:
> 
> First, for anyone not already familiar with OVN, it is an effort
> within the Open vSwitch project to build a virtual networking control
> plane for OVS.  There are several projects that have implemented
> something in this space (including Neutron).  OVN is intended to be a
> new, common implementation of this functionality that can be reused in
> many contexts, including by Neutron.  It includes a focus on
> implementation of features taking advantage of the newest features of
> OVS, including some still being added as we go.  There was a
> presentation about this in Vancouver [1] and we'll be doing another
> one covering current status in Tokyo [2].
> 
> This plugin is developed in parallel with OVN itself.  My time on each
> changes week to week, depending on what I'm working on.  The dev items
> I expect in the near future (this release cycle at least) include:
> 
>  - security groups.  This is being implemented using conntrack suport
>in OVS.  There's actually WIP code for this including kernel
>changes, ovs userspace changes, OVN, and networking-ovn.  This is a
>complex stack of dependencies, but it's starting to fall into place.
>Most of the kernel changes have been accepted, thought there's
>another change being reviewed now.  The OVS userspace changes have
>been under review in the last few weeks and are close to being
>merged.  Once that's done, we can finish up testing the OVN and
>networking-ovn patches.  We expect this to be done by Tokyo.
> 
>  - provider networks.  There's a lot of demand in OpenStack for
>supporting direct connectivity to existing networks as a simpler
>deployment model without any overlays.  I've done most of the work
>for both OVN and networking-ovn for this now and expect to have it
>wrapped up in the next week or so.
> 
>  - L3.  So far we've been using Neutron's L3 agent with networking-ovn.
>OVN will have native L3 support (will no longer use the L3 agent)
>and development on that has now started.  We aim to at least have
>initial distributed L3 support by Tokyo.  Some of it will certainly
>extend past that, though.  For example, NAT will be implemented with
>an OVS native solution, and that will likely not be ready by Tokyo.
>We may be able to deliver an intermediary NAT solution quicker.
> 
>  - SFC.  There's a ton of interest in SFC.  I've been casually following
>the networking-sfc project and the Neutron API they are proposing.
>I've also been thinking about how to implement it in OVN.  I think
>OVN's logical flows abstraction is going to make it surprisingly easy
>to implement.  I think I have a good idea of what needs to be done,
>but I'm not sure of when it will bubble up on my todo list.  I hope
>to work on it for this dev cycle though.  I'd first be implementing
>it in OVN, and then later doing the support for the networking-sfc
>API.
> 
>  - l2gw.  OVN already includes support for VTEP gateways.  We also just
>merged a patch to support them through the Neutron API using a
>networking-ovn specific binding:profile.  This is just a first step,
>though

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 04:18 PM, Russell Bryant wrote:
> On 09/27/2015 06:50 AM, Kevin Benton wrote:
>> Assuming it implements the normal provider networks API, you just
>> specify the segmentation_id when you create the network. 
>>
>> neutron net-create NET_NAME --provider:network_type vlan
>> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG
> 
> Yes, the OVN plugin will implement the normal provider networks API.
> It's a WIP.
> 
> My first goal was to just implement support for "--provider:network_type
> flat" end to end.  I have the OVN side merged and now I'm working on the
> Neutron plugin piece.  Once that's done, I'll go back add add VLAN
> support, which shouldn't be very difficult at that point.  I'm aiming to
> have all of that done by the Tokyo summit (among other things).

Just as a brief follow-up here, I finished the VLAN provider network
support for OVN here:

https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5

I also wrote an OVN tutorial this week.  Examples 4 and 5 cover how
provider networks are modeled in OVN.

https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md

I have the Neutron API patch posted here:

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

I did the patch before I finished the VLAN support.  Adding the VLAN bit
will be a trivial update, though.

-- 
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-dev] [Fuel] 8.0 Region name support / Multi-DC

[Roman Sokolkov]

Folks,

i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
support.

My ask is about tiny(but useful) feature: give user ability to *specify
Region name in UI.*

Region name is already in every puppet module, so we just need to add this
to UI.

Do we have smth already?

More general question: What are our plans in regards Multi-DC?

Thanks

-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Doc dependencies

[Kevin L. Mitchell]

On Fri, 2015-10-02 at 11:00 -0400, Sean Dague wrote:
> On 10/02/2015 10:53 AM, Kevin L. Mitchell wrote:
> > The Pillow-breaking-gate issue was related to having doc dependencies
> > listed in the test-requirements.txt; however, those dependencies are not
> > needed for testing, except for doc testing and generation.  What do
> > people think about creating a new "doc-requirements.txt" file that would
> > contain only the doc dependencies?  The appropriate doc environments in
> > tox.ini would then need to be extended to pull in that file, and of
> > course the global requirements tooling would have to be enhanced to
> > recognize the new file as well.
> 
> It would still have broken the gate, we test if docs build on every commit.

Yes—this is why I characterized it as "related"—but the test failure
would have at least been isolated to the docs test.  That would have
allowed reviews to get useful test results, instead of having a
dependency installation issue.  It's ultimately just a thought; it feels
wrong for us to install dependencies not directly related to testing,
even if we also test the doc generation.

> I think the bigger question is if we believe that a c compiler should be
> required to build docs on a python project. Which seems really weird to
> me. And a substantially higher barrier to entry than I think we want for
> docs contributions.

Well, Pillow isn't the only transitive dependency that's going to
require a C compiler; there are many other dependencies we have that are
actually extensions.

> There was only 1 use of this in all of Nova, and I think we're better
> off removing it and coming up with other ways of addressing it.

Perhaps, but having diagrams in the documentation is still going to be
incredibly useful, and Nova isn't the only component we have to consider
(which is why I removed the [nova] tag from the subject line).  That
said, I have no objection if we find or create a tool that generates
images without depending on Pillow, but…*shrug*
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [heat] Traditional question about Heat IRC meeting time.

[Zane Bitter]

On 02/10/15 10:55, Sergey Kraynev wrote:

Thank you all for the feedback :)

Let's continue with the same time frames.

Zane, I will try to move main/complex questions on the 2000 UTC
meetings to allow you to debate in it :)


Thanks, but don't slow anything down for my benefit :) I think it would 
be better to have those discussions as soon as they come up and then 
post a follow-up to the mailing list to make sure we get input from 
anyone who couldn't make it to the meeting.


cheers,
Zane.


On 1 October 2015 at 20:13, x Lyn  wrote:

+1 for 7:00

Sent from my iPhone


On Oct 1, 2015, at 10:36 PM, Zane Bitter  wrote:


On 29/09/15 05:56, Sergey Kraynev wrote:
Hi Heaters!

Previously we had constant "tradition" to change meeting time for
involving more people from different time zones.
However last release cycle show, that two different meetings with 07:00
and 20:00 UTC are comfortable for most of our contributors. Both time
values are acceptable for me and I plan to visit both meetings. So I
suggested to leave it without any changes.

What do you think about it ?


Sadly I can only make the 2000 UTC, but +1 anyway... it seems to be working ok 
at the moment.

- ZB

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


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







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

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Neil Jerram]

On 02/10/15 16:03, Jeremy Stanley wrote:
> On 2015-10-02 11:33:05 + (+), Neil Jerram wrote:
> [...]
>> For the PyPI registration I put 0.1.0, but that doesn't mean that I
>> expect that to be the version number when networking-calico is actually
>> released. I guessed that PyPI might impose an increasing version number
>> requirement, and that the real release number might be 1.0.something,
>> and so chose something logically less than that.
> [...]
>
> When I'm initially registering a package name on PyPI, I just put
> "0" in the required version field and leave everything else blank.
> It's quick and easy and works fine.
Thanks, I'll do that next time!

Neil


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

[Sean Dague]

On 10/02/2015 10:53 AM, Kevin L. Mitchell wrote:
> The Pillow-breaking-gate issue was related to having doc dependencies
> listed in the test-requirements.txt; however, those dependencies are not
> needed for testing, except for doc testing and generation.  What do
> people think about creating a new "doc-requirements.txt" file that would
> contain only the doc dependencies?  The appropriate doc environments in
> tox.ini would then need to be extended to pull in that file, and of
> course the global requirements tooling would have to be enhanced to
> recognize the new file as well.

It would still have broken the gate, we test if docs build on every commit.

I think the bigger question is if we believe that a c compiler should be
required to build docs on a python project. Which seems really weird to
me. And a substantially higher barrier to entry than I think we want for
docs contributions.

There was only 1 use of this in all of Nova, and I think we're better
off removing it and coming up with other ways of addressing it.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Jeremy Stanley]

On 2015-10-02 11:33:05 + (+), Neil Jerram wrote:
[...]
> For the PyPI registration I put 0.1.0, but that doesn't mean that I
> expect that to be the version number when networking-calico is actually
> released. I guessed that PyPI might impose an increasing version number
> requirement, and that the real release number might be 1.0.something,
> and so chose something logically less than that.
[...]

When I'm initially registering a package name on PyPI, I just put
"0" in the required version field and leave everything else blank.
It's quick and easy and works fine.
-- 
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] [heat] Traditional question about Heat IRC meeting time.

[Sergey Kraynev]

Thank you all for the feedback :)

Let's continue with the same time frames.

Zane, I will try to move main/complex questions on the 2000 UTC
meetings to allow you to debate in it :)

On 1 October 2015 at 20:13, x Lyn  wrote:
> +1 for 7:00
>
> Sent from my iPhone
>
>> On Oct 1, 2015, at 10:36 PM, Zane Bitter  wrote:
>>
>>> On 29/09/15 05:56, Sergey Kraynev wrote:
>>> Hi Heaters!
>>>
>>> Previously we had constant "tradition" to change meeting time for
>>> involving more people from different time zones.
>>> However last release cycle show, that two different meetings with 07:00
>>> and 20:00 UTC are comfortable for most of our contributors. Both time
>>> values are acceptable for me and I plan to visit both meetings. So I
>>> suggested to leave it without any changes.
>>>
>>> What do you think about it ?
>>
>> Sadly I can only make the 2000 UTC, but +1 anyway... it seems to be working 
>> ok at the moment.
>>
>> - ZB
>>
>> __
>> OpenStack Development Mailing 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



-- 
Regards,
Sergey.

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

[openstack-dev] [all] Doc dependencies (was: Re: [infra][nova][all] Pillow breaking gate?)

[Kevin L. Mitchell]

The Pillow-breaking-gate issue was related to having doc dependencies
listed in the test-requirements.txt; however, those dependencies are not
needed for testing, except for doc testing and generation.  What do
people think about creating a new "doc-requirements.txt" file that would
contain only the doc dependencies?  The appropriate doc environments in
tox.ini would then need to be extended to pull in that file, and of
course the global requirements tooling would have to be enhanced to
recognize the new file as well.
-- 
Kevin L. Mitchell 
Rackspace


__
OpenStack Development Mailing 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] Running Debian packages on top of Trusty

[Ivan Berezovskiy]

Hello,

thanks for bringing up this topic, that's what I wanted to discuss on next
puppet-openstack irc meeting.

So, user case is following: users may want to install Debian packages on
Ubuntu host or vice versa,
the same problem can probably happen with CentOS, RHEL, Fedora; or users
may use non-official
package repositories with their own package (service) naming strategy and
so on.
Current situation in puppet modules is following that package and service
names are (let's say)
hardcoded in 'params' class (e.g. [0]). But in situation that I've
described it won't work.
Puppet will try to use Ubuntu names on Ubuntu host and it won't allow to
install and work with
Debian packages.

I've researched puppet modules and found an interesting example which can
help to solve
this issue. It's implemented in puppetlabs mongodb module:
they have 'globals' class [1] that allows to override most part of
parameters from 'params' class [2].

So, I've decided to rework this soltuion and use it in OpenStack modules.
As result I got draft patch
for ceilometer module [3]. By default we use parameters from 'params'
class, but every parameter
can be now overridden using 'globals' class.

OpenStack Puppet team, what do you think about this solution?

Also, I'l bring up this topic on weekly puppet-openstack irc meeting.

[0] -
https://github.com/openstack/puppet-ceilometer/blob/master/manifests/params.pp
[1] -
https://github.com/puppetlabs/puppetlabs-mongodb/blob/master/manifests/globals.pp
[2] -
https://github.com/puppetlabs/puppetlabs-mongodb/blob/master/manifests/params.pp
[3] - https://review.openstack.org/#/c/229918/

2015-10-02 15:43 GMT+03:00 Ivan Udovichenko :

> Hello,
>
> On 10/02/2015 03:15 PM, Emilien Macchi wrote:
> > Hey Thomas,
> >
> > On 10/02/2015 04:33 AM, Thomas Goirand wrote:
> > [...]
> >> We also may need, at some point, to add the type mosdebian and moscentos
> >> to the list of supported package suite, as there still will be some
> >> differences between the upstream Debian or CentOS packages. What is the
> >> best way to add this variable values?
> >>
> >> Could you Puppet experts explain to me and my Mirantis colleagues again?
> >
> > So we partially discussed about that during our last weekly meeting [1]
> > and it come out the best way to support both Debian & Ubuntu are Puppet
> > conditionals, like we already have in place.
> >
> > [1]
> >
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-29-15.00.html
>
> It does not solve the original problem. Let's say you want to install
> Debian packages on-top of Ubuntu, it will fail and you will have to use
> workarounds, for example in the params.pp [1] you have specified.
>
> [1]
>
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>
> >
> > See the example with puppet-nova |2] where we use $::operatingsystem
> > fact [3] to detect if we're running Ubuntu or Debian.
> > If we're running Ubuntu, we take reference from UCA packaging. If
> > Debian, we take your work as reference.
> >
> > [2]
> >
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
> > [3] https://puppetlabs.com/facter
> >
>
> What we need is some variable which can override the decision which
> Operating System is used and thereby required packages will be
> installed. At least for Debian, that is what we really need.
> I'd be grateful if you look into it. Thank you.
>
> >
> >> Sorry that I didn't take notes about it and couldn't explain,
> >> Cheers,
> >>
> >> Thomas Goirand (zigo)
> >>
> >> P.S: Where may I find the best tutorial to get up-to-speed about puppet,
> >> so that I know what I'm talking about next time?
> >>
> >
> > I personally learnt (and am still learning) by using official
> > documentation [4], that I suggest you to start with.
> >
> > [4] http://docs.puppetlabs.com/puppet/
> >
> > Hope it helps,
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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
>



-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
OpenStack Development Mailing 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] Running Debian packages on top of Trusty

[Alex Schultz]

On Fri, Oct 2, 2015 at 7:43 AM, Ivan Udovichenko
 wrote:
> Hello,
>
> On 10/02/2015 03:15 PM, Emilien Macchi wrote:
>> Hey Thomas,
>>
>> On 10/02/2015 04:33 AM, Thomas Goirand wrote:
>> [...]
>>> We also may need, at some point, to add the type mosdebian and moscentos
>>> to the list of supported package suite, as there still will be some
>>> differences between the upstream Debian or CentOS packages. What is the
>>> best way to add this variable values?
>>>
>>> Could you Puppet experts explain to me and my Mirantis colleagues again?
>>
>> So we partially discussed about that during our last weekly meeting [1]
>> and it come out the best way to support both Debian & Ubuntu are Puppet
>> conditionals, like we already have in place.
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-29-15.00.html
>
> It does not solve the original problem. Let's say you want to install
> Debian packages on-top of Ubuntu, it will fail and you will have to use
> workarounds, for example in the params.pp [1] you have specified.
>
> [1]
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>
>>
>> See the example with puppet-nova |2] where we use $::operatingsystem
>> fact [3] to detect if we're running Ubuntu or Debian.
>> If we're running Ubuntu, we take reference from UCA packaging. If
>> Debian, we take your work as reference.
>>
>> [2]
>> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>> [3] https://puppetlabs.com/facter
>>
>
> What we need is some variable which can override the decision which
> Operating System is used and thereby required packages will be
> installed. At least for Debian, that is what we really need.
> I'd be grateful if you look into it. Thank you.
>

There are a few alternatives for this issue.  The first one is that
the package names, etc can be overwritten in the code that pulls in
the OpenStack Puppet modules. We are already doing this today in our
openstack::nova::controler[0] code.  There is another alternative to
leverage a globals class that would allow for overriding params. I
know Ivan Berezovskiy is working on something[1] and I think he was
going to bring this up in the next irc meeting. His method would allow
for the overriding of the params where the current package & service
name calculations are being done.  Another alternative would be to
rework the params class to query hiera and default to the existing
params settings if not defined or something to that effect.

Basically I think the ask for OpenStack Puppet is allowing for
additional configuration options if a user does not want to leverage
the RDO or UCA packages or needs to specific alternative package &
service names.


Thanks,
-Alex


[0] 
https://github.com/stackforge/fuel-library/blob/deb63f09df23170207310f06ca4e12785d018dc2/deployment/puppet/openstack/manifests/nova/controller.pp#L399
[1] https://review.openstack.org/#/c/229918/


>>
>>> Sorry that I didn't take notes about it and couldn't explain,
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>> P.S: Where may I find the best tutorial to get up-to-speed about puppet,
>>> so that I know what I'm talking about next time?
>>>
>>
>> I personally learnt (and am still learning) by using official
>> documentation [4], that I suggest you to start with.
>>
>> [4] http://docs.puppetlabs.com/puppet/
>>
>> Hope it helps,
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [Manila] Liberty RC2 available

[Thierry Carrez]

Hello everyone,

Due to release-critical issues spotted in Manila during RC1 testing, a
new release candidate was created for Liberty. The list of RC2 fixes, as
well as RC2 tarballs are available at:

https://launchpad.net/manila/liberty/liberty-rc2

Unless new release-critical issues are found that warrant a last-minute
release candidate respin, this tarball will be formally released as the
final "Liberty" version on October 15. You are therefore strongly
encouraged to test and validate this tarball !

Alternatively, you can directly test the stable/liberty branch at:
http://git.openstack.org/cgit/openstack/manila/log/?h=stable/liberty

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/manila/+filebug

and tag it *liberty-rc-potential* to bring it to the release crew's
attention.

Thanks!

-- 
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] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

On Fri, Oct 2, 2015 at 6:33 AM, Neil Jerram 
wrote:

> On 02/10/15 11:42, Neil Jerram wrote:
> > Thanks Kyle! I'm looking at this now for networking-calico.
>
> Done, please see https://pypi.python.org/pypi/networking-calico.
>
> When you release, how will the version number be decided?  And should I
> make a change to put that version into the source somewhere, or will you
> do that?  Currently it appears that there's no explicit version in the
> source, but that the build process somehow infers '0.0.1.dev8'.
>
> For the PyPI registration I put 0.1.0, but that doesn't mean that I
> expect that to be the version number when networking-calico is actually
> released.  I guessed that PyPI might impose an increasing version number
> requirement, and that the real release number might be 1.0.something,
> and so chose something logically less than that.
>
> Hope that all makes sense!
>
>
I was going to go with post versioning here. That means I'll tag a 1.0.0
version when you're ready to release, and we don't need a version in the
setup.cfg file. If you want a different version, just let me know when you
request the release.

Thanks!
Kyle

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

Re: [openstack-dev] [cinder] NFS mount as cinder user instead of root

[Eric Harney]

On 10/02/2015 05:48 AM, Francesc Pinyol Margalef wrote:
> Hi,
> In a previous message in general openstack list I reported a problem
> when trying to mount an NFS volume from a Fujitsu Eternus DX
> http://lists.openstack.org/pipermail/openstack/2015-July/013578.html
> 
> The issue is that this file server does not allow mounts as root, and
> this behaviour cannot be changed.
> 
> Would it be possible to configure (or modify) Cinder in order to mount
> NFS points as cinder user instead of root?
> 
> Francesc
> 
> 
> 

With the NFS driver, setting the option "nas_secure_file_operations =
True" should cause files to be created as the cinder user rather than as
root.

Can you try setting this and let me know if that helps?

Eric


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

Re: [openstack-dev] [release][requirements] changes to the requirements-core team

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-09-28 16:16:59 -0400:
> It has been a while since we've reviewed the requirements-core team
> members. Since it's the end of the cycle, I did a quick scan of the
> stats this week and I am proposing some changes based on participation.
> 
> I spoke with Ghe Rivero and Julien Danjou, both of whom have done good
> work in the past but who have changed their focus more recently. Both
> agreed that it no longer made sense to have them on the core team, so I
> will remove them today. As with other core teams, renewed interest from
> past cores is usually handled by fast-tracking them back onto the team.
> Thank you, Ghe and Julien, for your contributions!
> 
> I also spoke with Davanum Srinivas (dims) about joining the team. He has
> been active this cycle with requirements reviews and related release
> work, and is interested in being more involved. The usual practice is to
> wait a few days for feedback before adding someone new, so I will wait a
> few days before adding dims.
> 
> Doug
> 

I think we've waited long enough, and there has been no negative
feedback, so I've added Dims to the requirements-core team.

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

[openstack-dev] [nova][mistral] Automatic evacuation as a long running task

[Roman Dobosz]

Hi all,

The case of automatic evacuation (or resurrection currently), is a topic 
which surfaces once in a while, but it isn't yet fully supported by 
OpenStack and/or by the cluster services. There was some attempts to 
bring the feature into OpenStack, however it turns out it cannot be 
easily integrated with. On the other hand evacuation may be executed 
from the outside using Nova client or Nova API calls for evacuation 
initiation.

I did some research regarding the ways how it could be designed, based 
on Russel Bryant blog post[1] as a starting point. Apart from it, I've 
also taken high availability and reliability into consideration when 
designing the solution.

Together with coworker, we did first PoC[2] to enable cluster to be able 
to perform evacuation. The idea behind that PoC was simple - providing 
additional, small service which would trigger and supervise the 
evacuation process, which would be triggered from the outside (in this 
example we were using Pacemaker fencing facility, but it might be 
anything) using RabbitMQ directly. Those services are running on the 
control plane in AA fashion.

That work well for us. So we started exploring other possibilities like 
oslo.messaging just to use it in the same manner as we did in the poc.  
It turns out that the implementation will not be as easy, because there 
is no facility in the oslo.messaging for letting sending an ACK from the 
client after the job is done (not as soon as it gets the message). We 
also looked at the existing OpenStack projects for a candidate which 
provide service for managing long running tasks.

There is the Mistral project, which gives us almost all the features we 
need. The one missing feature is the HA of the Mistral tasks execution.

The question is, how such problem (long running tasks) could be resolved 
in OpenStack?

[1] http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/
[2] https://github.com/dawiddeja/evacuationd

-- 
Cheers,
Roman Dobosz

__
OpenStack Development Mailing 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] New cycle started. What are you up to, folks?

[Ben Pfaff]

On Fri, Oct 02, 2015 at 08:19:47AM +0300, Gal Sagie wrote:
> *OVN*
> 
>1) OVN integration with Kuryr

Can you say anything more about what that entails?

Thanks,

Ben.

__
OpenStack Development Mailing 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] Running Debian packages on top of Trusty

[Ivan Udovichenko]

Hello,

On 10/02/2015 03:15 PM, Emilien Macchi wrote:
> Hey Thomas,
> 
> On 10/02/2015 04:33 AM, Thomas Goirand wrote:
> [...]
>> We also may need, at some point, to add the type mosdebian and moscentos
>> to the list of supported package suite, as there still will be some
>> differences between the upstream Debian or CentOS packages. What is the
>> best way to add this variable values?
>>
>> Could you Puppet experts explain to me and my Mirantis colleagues again?
> 
> So we partially discussed about that during our last weekly meeting [1]
> and it come out the best way to support both Debian & Ubuntu are Puppet
> conditionals, like we already have in place.
> 
> [1]
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-29-15.00.html

It does not solve the original problem. Let's say you want to install
Debian packages on-top of Ubuntu, it will fail and you will have to use
workarounds, for example in the params.pp [1] you have specified.

[1]
https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107

> 
> See the example with puppet-nova |2] where we use $::operatingsystem
> fact [3] to detect if we're running Ubuntu or Debian.
> If we're running Ubuntu, we take reference from UCA packaging. If
> Debian, we take your work as reference.
> 
> [2]
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
> [3] https://puppetlabs.com/facter
> 

What we need is some variable which can override the decision which
Operating System is used and thereby required packages will be
installed. At least for Debian, that is what we really need.
I'd be grateful if you look into it. Thank you.

> 
>> Sorry that I didn't take notes about it and couldn't explain,
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> P.S: Where may I find the best tutorial to get up-to-speed about puppet,
>> so that I know what I'm talking about next time?
>>
> 
> I personally learnt (and am still learning) by using official
> documentation [4], that I suggest you to start with.
> 
> [4] http://docs.puppetlabs.com/puppet/
> 
> Hope it helps,
> 
> 
> 
> __
> OpenStack Development Mailing 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] Running Debian packages on top of Trusty

[Emilien Macchi]

Hey Thomas,

On 10/02/2015 04:33 AM, Thomas Goirand wrote:
[...]
> We also may need, at some point, to add the type mosdebian and moscentos
> to the list of supported package suite, as there still will be some
> differences between the upstream Debian or CentOS packages. What is the
> best way to add this variable values?
> 
> Could you Puppet experts explain to me and my Mirantis colleagues again?

So we partially discussed about that during our last weekly meeting [1]
and it come out the best way to support both Debian & Ubuntu are Puppet
conditionals, like we already have in place.

[1]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-29-15.00.html

See the example with puppet-nova |2] where we use $::operatingsystem
fact [3] to detect if we're running Ubuntu or Debian.
If we're running Ubuntu, we take reference from UCA packaging. If
Debian, we take your work as reference.

[2]
https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
[3] https://puppetlabs.com/facter


> Sorry that I didn't take notes about it and couldn't explain,
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> P.S: Where may I find the best tutorial to get up-to-speed about puppet,
> so that I know what I'm talking about next time?
> 

I personally learnt (and am still learning) by using official
documentation [4], that I suggest you to start with.

[4] http://docs.puppetlabs.com/puppet/

Hope it helps,
-- 
Emilien Macchi



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

Re: [openstack-dev] [Fuel] backporting before merging to master

[Dmitry Pyzhov]

I'm not sure if core reviewers should be so harsh. But the guideline seems
to be very useful. Guys, please don't create backports too early.

On Fri, Oct 2, 2015 at 2:00 PM, Matthew Mosesohn 
wrote:

> Hi Fuelers,
>
> I would like to address a concern I have with backporting policy. I'm sure
> all of you know that we should always land patches to master before it
> reaches stable/X.X branch. What you are not aware of probably is that many
> people are making cherry picks well in advance of gathering reviews and
> getting the patch landed in master. Some argue that it "saves time waiting
> on CI", but in reality it's quite the opposite. Adding a cherry pick before
> merging master causes the following workflow to take place:
> 1 - Propose to master and to stable/7.0
> 2 - CI runs on 2 patches
> 3 - Reviewer A comments on master patch
> 4 - owner adjusts both patches and runs CI
> 5 - Reviewer B comments on stable patch
> 6 - owner adjusts both patches and runs CI
> (repeat 3-6 in varying degrees until enough patches are gathered)
> 7 - rebase stable/7.0 patch again... wait for CI again
>
> This doubles the burden on CI and complicates the overall review process
> where we are accepting feedback for the initial solution on two (nearly)
> identical patches. What's worse is it's possible that the two solutions
> merged won't be identical and introduce potential regressions.
>
> I propose we avoid raising any stable/X.X patches before a patch is
> _merged_ into master to avoid this scenario. Additionally, if a core sees
> that this is happening, he or she should mark it -2 and discourage
> submission of new patchsets.
>
> I welcome your thoughts and feedback.
>
> Best Regards,
> Matthew Mosesohn
>
> __
> OpenStack Development Mailing 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] OpenStack Liberty RC1 for Ubuntu 14.04 LTS and Ubuntu 15.10

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

The Ubuntu OpenStack Engineering team is pleased to announce the
general availability of the first release candidates for the OpenStack
Liberty release in Ubuntu 15.10 development and for Ubuntu 14.04 LTS
via the Ubuntu Cloud Archive.

Further release candidates will be pushed to the archives as and when
they appear.

Ubuntu 14.04 LTS
- 

You can enable the Ubuntu Cloud Archive for OpenStack Liberty on
Ubuntu 14.04 installations by running the following commands (make
sure you have an up-to-date software-properties-common package first):

  sudo add-apt-repository cloud-archive:liberty
  sudo apt-get update

The Ubuntu Cloud Archive for Liberty includes updates for Nova,
Glance, Keystone, Neutron, Cinder, Swift, Horizon, Ceilometer, Heat,
Designate, Barbican, Manila, Ironic, Trove and Sahara; Ceph (0.94.3),
RabbitMQ (3.5.4), QEMU (2.3), libvirt (1.2.16) and OpenvSwitch (2.4.0)
backports from Ubuntu 15.10 development have also been provided.

You can checkout the full list of packages and versions at [0].

Ubuntu 15.10 (Wily) development
- ---

No extra steps required; just start installing OpenStack!

Reporting bugs
- --

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad
- - and come poke any of my team (zul, coreycb, gnuoy, thedac, ddellav
or beisner) in #ubuntu-server if something is particularly annoying or
broken…

Finally - thank you to everyone who’s made OpenStack Liberty RC1 a
reality - and have fun!

Cheers

James

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/liberty
_versions.html

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDm1kAAoJEL/srsug59jDDO8QAIiv82Z7MiOdssAiN1jktbCE
6etKZE4mM2CqF91t1NYDNkjGbQvEYfFI1PpNrSd0HmLuybkMR0XEQj07oPhTgdJd
HUFvXwJBPzsPa2mBer5WylQz4RAuVBfdIanjvgAa4My/SvoLFDFjeSqXj0sYSBgC
VyGPdpk6c5NwkzaxsAYL7TB/BWGFzDWeht9YF4wNyvxzGQOhyMkxRvQ2VMRUMxHt
6z8iR+vSENoHzrV0UPt4wTG8L51ZkXv+TaC8pXZTEtSWTGjaOxEa0YMjX5I/bNwX
y3VkuOmoXn+6lshBNJrri8Mr/KtwrWAZ/+UnwT8GmwbPVQ49tdCd0hFC5LRBC7cR
fneEcGBcOxJ4ftzJP5HOz3ZnFH7szvSAfmPrdDCDvuN0bpCHuCbi6dPAjse3MqVp
LIKNWPSD1BEzPUONF4y+/9iIpEEPHt6ehxBu/i9i0fLt4/KYd51GuR+rl/ZvQjn4
G2tnTEuKn+2znT2D+Y2LyQgEZlIThewZJFUuTq5s+B3KhZ0orCuvRvY0qJMyHS0A
TA1XGxTEOp5DZVzVy0/rCyp5V316u//a4lSPHuP+1aneV2q7T3CkafjgNScG/P8h
wAg0clhe5vWeMMDlgooBEsOYak+AFObdtojpDTaVmtfEbUbwpRZ77/SnhWm7pBlA
M8C8gWQojDXLHD7Cox1s
=CPST
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all] [ptls] Proposed Design Summit track/room/time allocation

[Hayes, Graham]

On 02/10/15 09:08, Thierry Carrez wrote:
> Hayes, Graham wrote:
>> In previous years we have had "related open source project" sessions at
>> the design summit, is that happening this year, or is space at too much
>> of a premium?
> 
> With the set up of the big tent, a larger number of project teams need
> space at the Summit, and it is easier than ever to join. As a
> consequence, the *Design Summit* is now purely restricted to official
> OpenStack project teams.
> 
> That said, neighbour projects could request "collaboration days" to be
> present in Tokyo. Ceph, the Linux kernel and Ansible apparently got some
> space as a result:
> 
> https://openstacksummitoctober2015tokyo.sched.org/overview/type/collaboration+day
> 

That is what I figured - in this post "Kosmos Jurisprudence" Big Tent I
was hoping to sneak in a session for us.

If you never ask, the answer is always no :)


__
OpenStack Development Mailing 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] pypi packages for networking sub-projects

[Neil Jerram]

On 02/10/15 11:42, Neil Jerram wrote:
> Thanks Kyle! I'm looking at this now for networking-calico.

Done, please see https://pypi.python.org/pypi/networking-calico.

When you release, how will the version number be decided?  And should I
make a change to put that version into the source somewhere, or will you
do that?  Currently it appears that there's no explicit version in the
source, but that the build process somehow infers '0.0.1.dev8'.

For the PyPI registration I put 0.1.0, but that doesn't mean that I
expect that to be the version number when networking-calico is actually
released.  I guessed that PyPI might impose an increasing version number
requirement, and that the real release number might be 1.0.something,
and so chose something logically less than that.

Hope that all makes sense!

Neil


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

[openstack-dev] [Fuel] backporting before merging to master

[Matthew Mosesohn]

Hi Fuelers,

I would like to address a concern I have with backporting policy. I'm sure
all of you know that we should always land patches to master before it
reaches stable/X.X branch. What you are not aware of probably is that many
people are making cherry picks well in advance of gathering reviews and
getting the patch landed in master. Some argue that it "saves time waiting
on CI", but in reality it's quite the opposite. Adding a cherry pick before
merging master causes the following workflow to take place:
1 - Propose to master and to stable/7.0
2 - CI runs on 2 patches
3 - Reviewer A comments on master patch
4 - owner adjusts both patches and runs CI
5 - Reviewer B comments on stable patch
6 - owner adjusts both patches and runs CI
(repeat 3-6 in varying degrees until enough patches are gathered)
7 - rebase stable/7.0 patch again... wait for CI again

This doubles the burden on CI and complicates the overall review process
where we are accepting feedback for the initial solution on two (nearly)
identical patches. What's worse is it's possible that the two solutions
merged won't be identical and introduce potential regressions.

I propose we avoid raising any stable/X.X patches before a patch is
_merged_ into master to avoid this scenario. Additionally, if a core sees
that this is happening, he or she should mark it -2 and discourage
submission of new patchsets.

I welcome your thoughts and feedback.

Best Regards,
Matthew Mosesohn
__
OpenStack Development Mailing 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] pypi packages for networking sub-projects

[Neil Jerram]

On 30/09/15 19:58, Kyle Mestery wrote:
> Folks:
>
> In trying to release some networking sub-projects recently, I ran into
> an issue [1] where I couldn't release some projects due to them not
> being registered on pypi. I have a patch out [2] which adds pypi
> publishing jobs, but before that can merge, we need to make sure all
> projects have pypi registrations in place. The following networking
> sub-projects do NOT have pypi registrations in place and need them
> created following the guidelines here [3]:
>
> networking-calico
> networking-infoblox
> networking-powervm
>
> The following pypi registrations did not follow directions to enable
> openstackci has "Owner" permissions, which allow for the publishing of
> packages to pypi:
>
> networking-ale-omniswitch
> networking-arista
> networking-l2gw
> networking-vsphere
>
> Once these are corrected, we can merge [2] which will then allow the
> neutron-release team the ability to release pypi packages for those
> packages.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
> [2] https://review.openstack.org/#/c/229564/1
> [3]
> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases

Thanks Kyle!  I'm looking at this now for networking-calico.

Neil


__
OpenStack Development Mailing 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] New cycle started. What are you up to, folks?

[Moshe Levi]

> -Original Message-
> From: Sean M. Collins [mailto:s...@coreitpro.com]
> Sent: Thursday, October 01, 2015 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] New cycle started. What are you up
> to, folks?
> 
> On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:
> > On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins 
> wrote:
> >
> > > On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:
> > > > - more changes with less infra tinkering! neutron devs should not
> > > > need
> > > to go to infra projects so often to make an impact;
> > > > -- make our little neat DevStack plugin used for qos and sr-iov
> > > > only a
> > > huge pile of bash code that is currently stored in DevStack and is
> > > proudly called neutron-legacy now; and make the latter obsolete and
> > > eventually removed from DevStack;
> > >
> > > We may need to discuss this. I am currently doing a refactor of the
> > > Neutron DevStack integration in
> > >
> > > https://review.openstack.org/168438
> > >
> > > If I understand your message correctly, I disagree that we should be
> > > moving all the DevStack support for Neutron out of DevStack and
> > > making it a plugin. All that does is move the mess from one corner
> > > of the room, to another corner.
> > >
> > >
> > I would actually be in favor of cleaning up the mess AND moving it
> > into neutron. If it's in Neutron, we control our own destiny with
> > regards to landing patches which affect DevStack and ultimately our
> > gate jobs. To me, that's a huge win-win. Thus, cleanup first, then move to
> Neutron.
> 
> Frankly we have a bad track record in DevStack, if we are to make an
> argument about controlling our own destiny. Neutron-lib is in a sad state of
> affairs because we haven't had the discipline to keep things simple.
> 
> In fact, I think the whole genesis of the Neutron plugin for DevStack is a 
> great
> example of how controlling our own destiny has started to grow the mess.
> Yes, we needed it to gate the QoS code. But now things are starting to get
> added.
> 
> https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa26
> 1b8686072d9b448e8
> 
I think the decision  should be based on where is the core code located. 
So if SR-IOV, OVS ,Linux Bridge, Qos are still in the neutron core the neutron 
devstack plugin 
should know how to install them. If we will decide to move them to different 
repos the
their devstack part should be moved as well.


> The trend is now that people are going to throw things into the Neutron
> DevStack plugin to get their doo-dad up and running, because making a new
> repo is harder than creating a patch (which maybe shows are repo creation
> process needs streamlining). I was originally for making Neutron DevStack
> plugins that exist in their own repos, instead of putting them in the Neutron
> tree. At least that makes things small, manageable, and straight forward. Yes,
> it makes for more plugin lines in your DevStack configuration, but at least 
> you
> know what each one does, instead of being an agglomeration.
> 
> If we are not careful, the Neutron DevStack plugin will grow into the big mess
> that neutron-legacy is.
> 
> Finally, Look at how many configuration knobs we have, and how there is a
> tendency to introduce new ones, instead of using local.conf to inject
> configuration into Neutron and the associated components. This ends up
> making it very complicated for someone to actually run Neutron in their
> DevStack, and I think a lot of people would give up and just run Nova-
> Network, which I will note is *still the default*.
> 
> We need to keep our ties strong with other projects, and improve them in
> some cases. I think culturally, if we start trying to move things into our 
> corner
> of the sandbox because working with other groups is hard, we send bad
> signals to others. This will eventually come back to bite us.
> 
> /rant
> 
> --
> Sean M. Collins
> 
> __
> 
> OpenStack Development Mailing 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][macvtap] [ml2] New cycle started. What are you up to, folks?

[Andreas Scheuring]

Hi everybody, 

I'm trying to to achieve 2 things:

#1 Add common macvtap support for all kind of interfaces to neutron core
(via a macvtap ml2-plugin & agent) [1]. There has been a long discussion
where this should land but finally we Kyle decided to do it in tree [2].

For the agent part, Sean Collins and myself are currently evaluating a
refactoring and extension of the linuxbridge agent to support both,
linuxbridge and macvtap attachments. If this will end up in just sharing
classes or if we will create a agent-plugin-framework is still to be
discussed.

#2 Continue Modular-layer-2-agent discussion  
The refactoring mentioned in #1 could be a first step into the direction
of a modular-layer-2-agent - or at least to common agent code. I will
gather information from passed discussions and try to come up with ideas
about feasible steps to such a modular agent.
At least between sriov, linuxbridge and macvtap I can see a lot of
potential. Not sure about OVS which has become much more powerful and
complex in the meanwhile - we will see.


Any feedback is welcome!
Thanks!


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


-- 
Andreas
(IRC: scheuran)

On Do, 2015-10-01 at 15:45 +0200, Ihar Hrachyshka wrote:
> Hi all,
> 
> I talked recently with several contributors about what each of us plans for 
> the next cycle, and found it’s quite useful to share thoughts with others, 
> because you have immediate yay/nay feedback, and maybe find companions for 
> next adventures, and what not. So I’ve decided to ask everyone what you see 
> the team and you personally doing the next cycle, for fun or profit.
> 
> That’s like a PTL nomination letter, but open to everyone! :) No commitments, 
> no deadlines, just list random ideas you have in mind or in your todo lists, 
> and we’ll all appreciate the huge pile of awesomeness no one will ever have 
> time to implement even if scheduled for Xixao release.
> 
> To start the fun, I will share my silly ideas in the next email.
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [all] Something about being an ATC

[Flavio Percoco]

Greetings,

First and foremost, thanks to all the amazing candidates running for
the TC. I'm very excited to see new candidacies, other candidacies
from the previous terms and exciting proposals.

Just like for the PTL elections, I took the time to share a few
thoughts about the upcoming TC voting week. I wanted to dedicate these
thoughts to OpenStack's ATCs, which are the ones that will elect the
members of the TC.

The link is: http://blog.flaper87.com/post/something-about-being-an-ATC/

For the sake of discussion, I'm pasting it below (enjoy markdown):

You may be probably wondering what the heck is wrong with me. If you
haven't, please, keep reading. If you have, though, please, keep
reading.

It's that time of the cycle - ha! you saw this comming, didn't you? -,
in OpenStack, when we need to elect new members for the Technical
Committee. In a [previous 
post](http://blog.flaper87.com/post/something-about-being-a-ptl/), I
talked about what being a 
[PTL](http://docs.openstack.org/project-team-guide/open-development.html#project-team-lead)
means. I talked directly to candidates and I encouraged them to
understand each and every point that I've made in that post. This
time, though, I'd like to talk directly to ATCs for a couple of
reasons. First one is that Thierry Carrez has a [great 
post](http://ttx.re/tech-committee-candidates.html) already where he
explains what being a TC member means. Second one is that I think you,
my dear ATC, are one of the most valuable member of this community and
of the ones with most power throughout OpenStack.

Let's start by laying down what ATC means.


Active Technical Contributor


An Active Technical Contributor (ATC) is a member of the OpenStack
Foundation that has contributed to any of the official projects in the
last two cycles. Any contributions to the projects will make you an
ATC.

Being an ATC, like anything else in OpenStack, is a volunteers job.
It's not necessary to be an ATC to be part of the community and, if
you are, you're not required to cover for all the ATC
responsibilities, although you'll still get all the ATC benefits.

Why do ATCs have power?
===

As in any other democratic model, members of the communities have the
power to elect their leaders. As far as OpenStack goes, every ATC will
have the power to vote for the people that will represent the
community in the Technical Committee and in the Foundation Board
(Individual members only).

If you're not familiar with these groups, I'd really suggest you to
read more about the [governance 
structure](https://wiki.openstack.org/wiki/Governance/Foundation/Structure)
and I'd also recommend you to take a look at the current [Technical
Committee](http://governance.openstack.org/).

I'll abstain to give a short version of the current governance model
because anything I'll write here won't be as detailed as what's in
those links. However, I'd like to encourage you to read them before
going forward with this post.

Now that you've a better understanding of OpenStack's governance model
and the responsabilities of each of its parts, I hope it's also
clearer why your vote, more importantly your conscious vote, is so
critical.

Teach me how to vote


Glad you asked because that's what this post is about. I don't mean to
tell you who to vote for and I definitely don't mean to share this as
the definitive guide of how/why you should vote. However, I do think
the points below should be added to your list of considerations when
you're casting your vote.

Technical Committee takes time
==

Being part of the technical committee takes a lot of time. Just like
being a PTL and being a super active ATC. It all takes time. Don't
ever give for granted that people running for a TC seat have enough
time in their hands. If you have doubts, I'd highly recommend you to
openly ask to *everyone* whether they have enough time in their hands.

Look at the candidates tasks. Look at how many things they are doing
and ask yourself (or themselves) whether, considering their current
tasks, they'll have enough time. For example, PTLs may find it hard to
dedicate a significant amount of time to being a TC. It depends on the
project, it depends on the satus, etc. But, past has proven that this
is normally the case.

The reason you should care about that is not just because you want the
TC members to take good care of you and OpenStack. That's an amazing
reason. However, you, as an ATC, should also take care of the TC. You
don't want members of the TC to burnout when OpenStack is half-way
through a cycle. Many times, people underestimate the cost of time and
what the TC requirements are.

Did you know the TC meetings are on Tuesdays at 20:00 UTC? That's
22:00 CEST and 8:00 in New Zealand (during summer/winter ;). The only
reason I'm mentioning this is because it's relevant for the next
topic.

Attending Meetings
==

You'd think t

[openstack-dev] [cinder] NFS mount as cinder user instead of root

[Francesc Pinyol Margalef]

Hi,
In a previous message in general openstack list I reported a problem
when trying to mount an NFS volume from a Fujitsu Eternus DX
http://lists.openstack.org/pipermail/openstack/2015-July/013578.html

The issue is that this file server does not allow mounts as root, and
this behaviour cannot be changed.

Would it be possible to configure (or modify) Cinder in order to mount
NFS points as cinder user instead of root?

Francesc


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

Re: [openstack-dev] [Fuel] Bugfixing status. 12 weeks before SCF.

[Sergii Golovatiuk]

Hi,

+1 to Evgeniy... Since 'critical' and 'high' were cleared up from SCF to
Release we should assume that new Cricital and High bugs are introduced by
'new' features. In this case feature team should fix it.

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

On Fri, Oct 2, 2015 at 10:01 AM, Evgeniy L  wrote:

> Hi Dmitry,
>
> Thanks for the information.
>
> >> My personal opinion is that we can ignore our medium-priority
> technical debt bugs for now. We should fix them but there is nothing that
> cannot be postponed here. We will continue fixing them in background. The
> only exception here should be bugs related to alignment with global
> requirements, tox and oslo-related changes. We definitely should fix this
> stuff.
>
> I think we shouldn't ignore medium priority tech debt bugs now, the
> beginning of the release
> cycle is the best time to fix them.
>
> Thanks,
>
> On Thu, Oct 1, 2015 at 9:17 PM, Dmitry Pyzhov 
> wrote:
>
>> Guys,
>>
>> I was not able to participate in our weekly IRC meeting. So I'd like to
>> share our bug status for 8.0 release with offline e-mail.
>>
>> We have 494 Fuel bugs on Launchpad. This number can be splitted into
>> several piles.
>>
>> 1) Critical and High priority bugs. We have 48 of them now. 2 in UI, 31
>> in python, 15 in library. Here is our focus and we are working on reducing
>> the numbers.
>> 2) Medium/Low/Wishlist priority bugs. We have 241 bug. 72 in UI, 119 in
>> python, 50 in library.
>> 3) Features reported as bugs and bugs that can be fixed only by
>> implementing new blueprints. We have 133 of them. 3 in UI, 106 in python
>> and 24 in library. These bugs are marked with 'feature', 'covered-by-bp'
>> and 'need-bp' tags. Numbers look scary but only 40 of them have high and
>> critical priority.
>> 4) Technical debt. Things that we should do better from developer's point
>> of view. 72 bugs in total. 60 in python, 12 in library. They are marked
>> with 'tech-debt' tag.
>>
>> My personal opinion is that we can ignore our medium-priority technical
>> debt bugs for now. We should fix them but there is nothing that cannot be
>> postponed here. We will continue fixing them in background. The only
>> exception here should be bugs related to alignment with global
>> requirements, tox and oslo-related changes. We definitely should fix this
>> stuff.
>>
>> You can see that we have big demand for python developers. Here is my
>> early estimation. With current pace we can fix all existing library bugs in
>> 8.0. Also we can fix all existing high priority bugs in python. It includes
>> technical debt and maybe feature-bugs. It looks like we are able to fix
>> about half of medium priority python bugs. I don't have any estimations for
>> medium priority feature-bugs in python. And I'd prefer to be pessimistic
>> here. Also we will fix very small number of medium priority technical debt
>> bugs.
>>
>> There is a good chance that number of incoming bugs will became smaller
>> over time and we will fix most of existing medium priority python bugs.
>>
>> __
>> OpenStack Development Mailing 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] [puppet] Running Debian packages on top of Trusty

[Thomas Goirand]

Hi!

I've already discussed the topic on IRC with Emilien, however, it came
back within Mirantis, and as I don't have puppet skills, I was not able
to answer my colleagues correctly. Opening this thread is an attempt to
solve the issue once and for all. Hopefully, Emilien (and other puppet
guys) will be able to help.

Puppet currently takes decision based on the type of OS. For example,
"am I running under Debian?" will lead to install "nova-consoleproxy"
instead of nova-novncproxy or nova-spicehtml5proxy. However, when
rebuilding the Debian package, rebuilt and install over on Trusty, the
code path shouldn't depend on the operating system, but on the package type.

As MOS is becoming closer to the Debian packages (Mirantis is slowly
taking the path of contributing to Debian first, before integrating
packages into MOS), and as we would like to contribute in the upstream
puppet project as much as possible (as opposed to maintaining patches on
top), I'd like to know what's the best way to address this issue.

We also may need, at some point, to add the type mosdebian and moscentos
to the list of supported package suite, as there still will be some
differences between the upstream Debian or CentOS packages. What is the
best way to add this variable values?

Could you Puppet experts explain to me and my Mirantis colleagues again?

Sorry that I didn't take notes about it and couldn't explain,
Cheers,

Thomas Goirand (zigo)

P.S: Where may I find the best tutorial to get up-to-speed about puppet,
so that I know what I'm talking about next time?

__
OpenStack Development Mailing 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] Announcing Liberty RC1 availability in Debian

[Thomas Goirand]

On 10/01/2015 09:39 PM, Thomas Goirand wrote:
> On 09/30/2015 01:58 PM, Thomas Goirand wrote:
>> 3/ Horizon dependencies still in NEW queue
>> ==
>>
>> It is also worth noting that Horizon hasn't been fully FTP master
>> approved, and that some packages are still remaining in the NEW queue.
>> This isn't the first release with such an issue with Horizon. I hope
>> that 1/ FTP masters will approve the remaining packages son 2/ for
>> Mitaka, the Horizon team will care about freezing external dependencies
>> (ie: new Javascript objects) earlier in the development cycle. I am
>> hereby proposing that the Horizon 3rd party dependency freeze happens
>> not later than Mitaka b2, so that we don't experience it again for the
>> next release. Note that this problem affects both Debian and Ubuntu, as
>> Ubuntu syncs dependencies from Debian.
> 
> Good news. All of the dependencies for Horizon have been FTP master
> approved. Only Horizon itself is now in the FTP master NEW queue because
> I added a horizon-doc binary package.

Here we go, Horizon got approved too! :)
So, Liberty really is fully in Debian now, nothing (apart from Zaqar)
remains in the NEW queue.

Cheers,

Thomas


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

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q&A Session

[Evgeniy L]

Hi Mike,

According to the description of the role, I wouldn't say that the role is
less architectural than
political, since PTL should review designs and resolve conflicts between
cores (which are
usually technical), PTL should also have strong skills in software
architecture, and understanding
of what Fuel should look like.

Thanks,

On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov 
wrote:

> > we may mix technical direction / tech debt roadmap and process,
> political, and people management work of PTL.
> sorry, of course I meant that we rather should NOT mix these things.
>
> To make my email very short, I'd say PTL role is more political and
> process-wise rather than architectural.
>
> On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov 
> wrote:
>
>> Vladimir,
>> we may mix technical direction / tech debt roadmap and process,
>> political, and people management work of PTL.
>>
>> PTL definition in OpenStack [1] reflects many things which PTL becomes
>> responsible for. This applies to Fuel as well.
>>
>> I'd like to reflect some things here which I'd expect PTL doing, most of
>> which will intersect with [1]:
>> - Participate in cross-project initiatives & resolution of issues around
>> it. Great example is puppet-openstack vs Fuel [2]
>> - Organize required processes around launchpad bugs & blueprints
>> - Personal personal feedback to Fuel contributors & public suggestions
>> when needed
>> - Define architecture direction & review majority of design specs. Rely
>> on Component Leads and Core Reviewers
>> - Ensure that roadmap & use cases are aligned with architecture work
>> - Resolve conflicts between core reviewers, component leads. Get people
>> to the same page
>> - Watch for code review queues and quality of reviews. Ensure discipline
>> of code review.
>> - Testing / coverage have to be at the high level
>>
>> Considering all above, contributors actually have been working with all
>> of us and know who could be better handling such a hard work. I don't think
>> special Q&A is needed. If there are concerns / particular process/tech
>> questions we'd like to discuss - those should be just open as email threads.
>>
>> [1] https://wiki.openstack.org/wiki/PTL_Guide
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html
>>
>> Thank you,
>>
>> On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin 
>> wrote:
>>
>>> Folks
>>>
>>> I think it is awesome we have three candidates for PTL position in Fuel.
>>> I read all candidates' emails (including mine own several times :-) ) and I
>>> got a slight thought of not being able to really differentiate the
>>> candidates platforms as they are almost identical from the high-level point
>>> of view. But we all know that the devil is in details. And this details
>>> will actually affect project future.
>>>
>>> Thus I thought about Q&A session at #fuel-dev channel in IRC. I think
>>> that this will be mutually benefitial for everyone to get our platforms a
>>> little bit more clear.
>>>
>>> Let's do it before or right at the start of actual voting so that our
>>> contributors can make better decisions based on this session.
>>>
>>> I suggest the following format:
>>>
>>> 1) 3 questions from electorate members - let's put them onto an etherpad
>>> 2) 2 questions from a candidate to his opponents (1 question per
>>> opponent)
>>> 3) external moderator - I suppose, @xarses as our weekly meeting
>>> moderator could help us
>>> 4) time and date - Wednesday or Thursday comfortable for both timezones,
>>> e.g. after 4PM UTC or right after fuel weekly meeting.
>>>
>>> What do you think, folks?
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Defining a public API for tripleo-common

[Jan Provazník]

On 09/30/2015 10:08 AM, Dougal Matthews wrote:

Hi,

What is the standard practice for defining public API's for OpenStack
libraries? As I am working on refactoring and updating tripleo-common I have
to grep through the projects I know that use it to make sure I don't break
anything.

Personally I would choose to have a policy of "If it is documented, it is
public" because that is very clear and it still allows us to do internal
refactoring.

Otherwise we could use __all__ to define what is public in each file, or
assume everything that doesn't start with an underscore is public.

Cheers,
Dougal



Hi,
my preference would be to follow the same approach which is used in oslo 
libraries (I think these libs should be take as a best practice example 
if possible). And oslo libs AFAIK use the last of your options.


But if there is a plan to build some thin REST API layer on top if it, I 
think that versioning will be necessary. So I would lean to the default 
underscore convention in versioned directory structure :).


Jan

__
OpenStack Development Mailing 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] [ptls] Proposed Design Summit track/room/time allocation

[Thierry Carrez]

Hayes, Graham wrote:
> In previous years we have had "related open source project" sessions at
> the design summit, is that happening this year, or is space at too much
> of a premium?

With the set up of the big tent, a larger number of project teams need
space at the Summit, and it is easier than ever to join. As a
consequence, the *Design Summit* is now purely restricted to official
OpenStack project teams.

That said, neighbour projects could request "collaboration days" to be
present in Tokyo. Ceph, the Linux kernel and Ansible apparently got some
space as a result:

https://openstacksummitoctober2015tokyo.sched.org/overview/type/collaboration+day

-- 
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] [Fuel] Bugfixing status. 12 weeks before SCF.

[Evgeniy L]

Hi Dmitry,

Thanks for the information.

>> My personal opinion is that we can ignore our medium-priority technical
debt bugs for now. We should fix them but there is nothing that cannot be
postponed here. We will continue fixing them in background. The only
exception here should be bugs related to alignment with global
requirements, tox and oslo-related changes. We definitely should fix this
stuff.

I think we shouldn't ignore medium priority tech debt bugs now, the
beginning of the release
cycle is the best time to fix them.

Thanks,

On Thu, Oct 1, 2015 at 9:17 PM, Dmitry Pyzhov  wrote:

> Guys,
>
> I was not able to participate in our weekly IRC meeting. So I'd like to
> share our bug status for 8.0 release with offline e-mail.
>
> We have 494 Fuel bugs on Launchpad. This number can be splitted into
> several piles.
>
> 1) Critical and High priority bugs. We have 48 of them now. 2 in UI, 31 in
> python, 15 in library. Here is our focus and we are working on reducing the
> numbers.
> 2) Medium/Low/Wishlist priority bugs. We have 241 bug. 72 in UI, 119 in
> python, 50 in library.
> 3) Features reported as bugs and bugs that can be fixed only by
> implementing new blueprints. We have 133 of them. 3 in UI, 106 in python
> and 24 in library. These bugs are marked with 'feature', 'covered-by-bp'
> and 'need-bp' tags. Numbers look scary but only 40 of them have high and
> critical priority.
> 4) Technical debt. Things that we should do better from developer's point
> of view. 72 bugs in total. 60 in python, 12 in library. They are marked
> with 'tech-debt' tag.
>
> My personal opinion is that we can ignore our medium-priority technical
> debt bugs for now. We should fix them but there is nothing that cannot be
> postponed here. We will continue fixing them in background. The only
> exception here should be bugs related to alignment with global
> requirements, tox and oslo-related changes. We definitely should fix this
> stuff.
>
> You can see that we have big demand for python developers. Here is my
> early estimation. With current pace we can fix all existing library bugs in
> 8.0. Also we can fix all existing high priority bugs in python. It includes
> technical debt and maybe feature-bugs. It looks like we are able to fix
> about half of medium priority python bugs. I don't have any estimations for
> medium priority feature-bugs in python. And I'd prefer to be pessimistic
> here. Also we will fix very small number of medium priority technical debt
> bugs.
>
> There is a good chance that number of incoming bugs will became smaller
> over time and we will fix most of existing medium priority python bugs.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] should we use fsync when writing iscsi config file?

[Joshua Harlow]

A library that seems to have a pretty nice abstraction for this kind of
thing/pattern, could be an idea to use it, or have something similar
like it...

https://boltons.readthedocs.org/en/latest/fileutils.html#atomic-file-saving

-Josh

On Sat, 26 Sep 2015 10:48:39 +0200
Julien Danjou  wrote:

> On Tue, Sep 22 2015, Chris Friesen wrote:
> 
> > On 09/22/2015 05:48 PM, Joshua Harlow wrote:
> >> A present:
> >>
> >>  >>> import contextlib
> >>  >>> import os
> >>  >>>
> >>  >>> @contextlib.contextmanager
> >> ... def synced_file(path, mode='wb'):
> >> ...   with open(path, mode) as fh:
> >> ...  yield fh
> >> ...  os.fdatasync(fh.fileno())
> >> ...
> >>  >>> with synced_file("/tmp/b.txt") as fh:
> >> ...fh.write("b")
> >
> > Isn't that missing an "fh.flush()" somewhere before the fdatasync()?
> 
> Unless proven otherwise, close() does a flush().
> 


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