Re: [openstack-dev] [Neutron] OVS flow modification performance

[Kevin Benton]

Thanks for doing this. A couple of questions:

What were your rootwrap settings when running these tests? Did you just
have it calling sudo directly?

Also, you mention that this is only ~10% of the time spent during flow
reconfiguration. What other areas are eating up so much time?

Cheers,
Kevin Benton

On Sun, Jan 17, 2016 at 10:12 PM, IWAMOTO Toshihiro 
wrote:

> I'm sending out this mail to share the finding and discuss how to
> improve with those interested in neutron ovs performance.
>
> TL;DR: The native of_interface code, which has been merged recently
> and isn't default, seems to consume less CPU time but gives a mixed
> result.  I'm looking into this for improvement.
>
> * Introduction
>
> With an ML2+ovs Neutron configuration, openflow rule modification
> happens often and is somewhat a heavy operation as it involves
> exec() of the ovs-ofctl command.
>
> The native of_interface driver doesn't use the ovs-ofctl command and
> should have less performance impact on the system.  This document
> tries to confirm this hypothesis.
>
>
> * Method
>
> In order to focus on openflow rule operation time and avoid noise from
> other operations (VM boot-up, etc.), neutron-openvswitch-agent was
> restarted and the time it took to reconfigure the flows was measured.
>
> 1. Use devstack to start a test environment.  As debug logs generate
>considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
> 2. Apply https://review.openstack.org/#/c/267905/ to enable
>measurement of flow reconfiguration times.
> 3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
>flows.  If you have >16G RAM, more could be booted.
> 4. Stop neutron-openvswitch-agent and restart with --run-once arg.
>Use time, oprofile, and python's cProfile (use --profile arg) to
>collect data.
>
> * Results
>
> Execution time (averages of 3 runs):
>
> native 28.3s user 2.9s sys 0.4s
> ovs-ofctl  25.7s user 2.2s sys 0.3s
>
> ovs-ofctl runs faster and seems to use less CPU, but the above doesn't
> count in execution time of ovs-ofctl.
>
> Oprofile data collected by running "operf -s -t" contain the
> information.
>
> With of_interface=native config, "opreport tgid:" shows:
>
>samples|  %|
> --
> 87408 100.000 python2.7
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 69160 79.1232 python2.7
>  8416  9.6284 vmlinux-3.13.0-24-generic
>
> and "opreport --merge tgid" doesn't show ovs-ofctl.
>
> With of_interface=ovs-ofctl, "opreport tgid:" shows:
>
>samples|  %|
> --
> 62771 100.000 python2.7
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 49418 78.7274 python2.7
>  6483 10.3280 vmlinux-3.13.0-24-generic
>
> and  "opreport --merge tgid" shows CPU consumption by ovs-ofctl
>
> 35774  3.5979 ovs-ofctl
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 28219 78.8813 vmlinux-3.13.0-24-generic
>  3487  9.7473 ld-2.19.so
>  2301  6.4320 ovs-ofctl
>
> Comparing 87408 (native python) with 62771+35774, the native
> of_interface uses 0.4s less CPU time overall.
>
> * Conclusion and future steps
>
> The native of_interface uses slightly less CPU time but takes longer
> time to complete a flow reconfiguration after an agent restart.
>
> As an OVS agent accounts for only 1/10th of total CPU usage during a
> flow reconfiguration (data not shown), there may be other areas for
> improvement.
>
> The cProfile Python module gives more fine grained data, but no
> apparent performance bottleneck was found.  The data show more
> eventlet context switches with the native of_interface, which is due
> to how the native of_interface is written.  I'm looking into for
> improving CPU usage and latency.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] changing in neutron code

[Smigiel, Dariusz]

Hey Atif,
Welcome to the Community.
If you do not know where to start, I'd suggest to read this wiki page [1].
Because you've mentioned Neutron, you can join #openstack-neutron channel on 
Freenode and talk to other people there.
Kilo release is currently considered stable, so just bugfix are allowed to be 
sent there, to prevent from regression problems. If you wanna get more info 
about this, talk to Stable Team [2]
In case of testing your changes, you can do this by running tox, write some 
unittests, integration tests and of course check if you're changes are OK, by 
deploying in testing cloud. [3]

If you have more questions, feel free to use Ask Openstack [4]

[1] https://wiki.openstack.org/wiki/How_To_Contribute
[2] https://wiki.openstack.org/wiki/Meetings/StableTeam
[3] https://wiki.openstack.org/wiki/Network/Testing
[4] https://ask.openstack.org/en/questions/

Regards,
 Dariusz (dasm) Smigiel
 Intel Technology Poland

> 
> Hi All,
> 
> I am a newbie in an Open Stack developers community. I want to do some
> modification in Devstack/kilo neutron part. Can anyone guide me how to test
> the modification in the code part.
> 
> (1) Should I need to define my own module/class.
> (2) Can I add some def in neutron code.
> 
> and Importantly, How to test that my code is working or not?
> 
> Suggestions are highly appreciated and welcome. Really need to get help.
> 
> A.
> 
> 


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

Re: [openstack-dev] [horizon]Back porting code from master to liberty

[Matthias Runge]

On 18/01/16 07:22, Sirisha Guduru wrote:
> Hi,
> 
> ³VolumeTypeList² for admin is enabled in the master release of openstack
> horizon, where an admin can see all the volume types listed in horizon.
> The same is not implemented in liberty. Can we back port the code from
> master to liberty to meet the requirement or should it be implemented
> locally?

Sirisha,

in your local repositories, you can do anything you want.

For official branches there is an official policy:
https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes

Best,
Matthias

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

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[James Bottomley]

On Fri, 2016-01-15 at 20:48 +0800, Thomas Goirand wrote:
> This isn't the first time I'm calling for it. Let's hope this time, 
> I'll be heard.
> 
> Randomly, contributors put their company names into source code. When
> they do, then effectively, this tells that a given source file 
> copyright holder is whatever is claimed, even though someone from 
> another company may have patched it.
> 
> As a result, we have a huge mess. It's impossible for me, as a 
> package maintainer, to accurately set the copyright holder names in 
> the debian/copyright file, which is a required by the Debian FTP
> masters.

The debian copyright policy merely requires the debian/copyright file
to aggregate the stated copyright of the project ... it doesn't require
the project to keep complete and accurate records or Debian to
manufacture them:

https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

Traditionally the git repository is the complete record of who changed
the file.  However, legally, not every change might be considered
copyrightable so most open source projects leave it up to authors
whether they want to add a copyright annotation or not.

Just simply aggregating what's stated in the files is enough to satisfy
the debian policy.

> I see 2 ways forward:
> 1/ Require every one to give-up copyright holding, and give it to the
> OpenStack Foundation.

Good grief, I thought we'd got beyond the days of copyright assignment
... it might simplify your administration, but it would greatly
increase the burden of someone to maintain the files of the necessary
assignments.

> 2/ Maintain a copyright-holder file in each project.

How is that different from letting people decide if they want to add
their copyrights to the header of the file ... in other words, how will
it make the situation different from today?

> The later is needed if we want to do things correctly. Leaving the
> possibility for everyone to just write (c) MyCompany LLC randomly in 
> the source code doesn't cut it. Expecting that a package maintainer
> should double-guess copyright holding just by reading the email 
> addresses of "git log" output doesn't work either.
> 
> Please remember that a copyright holder has nothing to do with the
> license, neither with the author of some code. So please do *not*
> take
> over this thread, and discuss authorship or licensing.
> 
> Whatever we choose, I think we should ban having copyright holding
> text
> within our source code. While licensing is a good idea, as it is
> accurate, the copyright holding information isn't and it's just
> missleading.
> 
> If I was the only person to choose, I'd say let's go for 1/, but
> probably managers of every company wont agree.
> 
> Some thoughts anyone?

I don't think there's anything broken here, so I'd vote for not trying
to fix it ...

James



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

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[James Bottomley]

On Fri, 2016-01-15 at 15:38 +, Daniel P. Berrange wrote:
> On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote:
> > This isn't the first time I'm calling for it. Let's hope this time,
> > I'll
> > be heard.
> > 
> > Randomly, contributors put their company names into source code.
> > When
> > they do, then effectively, this tells that a given source file
> > copyright
> > holder is whatever is claimed, even though someone from another
> > company
> > may have patched it.
> > 
> > As a result, we have a huge mess. It's impossible for me, as a
> > package
> > maintainer, to accurately set the copyright holder names in the
> > debian/copyright file, which is a required by the Debian FTP
> > masters.
> 
> I don't think OpenStack is in a different situation to the vast
> majority of open source projects I've worked with or seen. Except
> for those projects requiring copyright assignment to a single
> entity, it is normal for source files to contain an unreliable
> random splattering of Copyright notices. This hasn't seemed to
> create a blocking problem for their maintenance in Debian. Loooking
> at the debian/copyright files I see most of them have just done a
> grep for the 'Copyright' statements & included as is - IOW just
> ignored the fact that this is essentially worthless info and included
> it regardless.
> 
> > I see 2 ways forward:
> > 1/ Require everyone to give-up copyright holding, and give it to
> > the
> > OpenStack Foundation.
> > 2/ Maintain a copyright-holder file in each project.
> 
> 3/ Do nothing, just populate debian/copyright with the random
>set of 'Copyright' lines that happen to be the source files,
>as appears to be common practice across many debian packages
> 
>eg the kernel package
> 
> http://metadata.ftp-master.debian.org/changelogs/main/l/linux/lin
> ux_3.16.7-ckt11-1+deb8u3_copyright
> 
> "Copyright: 1991-2012 Linus Torvalds and many others"
> 
>if its good enough for the Debian kernel package, it should be
>good enough for openstack packages too IMHO.

This is what I'd vote for.  It seems to be enough to satisfy the debian
policy on copyrights and it means nothing has to change in Openstack.

James


__
OpenStack Development Mailing 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] changing in neutron code

[Atif Saeed]

Hi All, 

I am a newbie in an Open Stack developers community. I want to do some 
modification in Devstack/kilo neutron part. Can anyone guide me how to test the 
modification in the code part. 

(1) Should I need to define my own module/class. 
(2) Can I add some def in neutron code. 

and Importantly, How to test that my code is working or not?

Suggestions are highly appreciated and welcome. Really need to get help.

A. 


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

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

[Adrian Turjak]

Updating the label code in django_openstack_auth isn't an option since
it would mean forking and maintaining our own copy of the library for
most likely one line of code.

Diana, any clue how would I go about overriding the label solely with
code placed in Horizon? Ideally we'd like to just place this in our own
theme to make rebasing horizon changes easier, but if needed we can live
with making this a non-theme patch for us to carry.

No clue how much we care about Localization, but if the answer is that
we do, how much work do you think adding "Email" to our Horizon
Localization would be?

Cheers,
-Adrian

On 16/01/16 07:43, Diana Whitten wrote:
> Adrian,
> 
> Changing the label is also possible through overrides, but customizing any
> label that goes through Localization might affect other languages.  Not
> sure if this might be a problem for you.
> 
> If this isn't ideal, we can easily put in hooks to allow customization
> purely through CSS, using pseudo selectors like ':before' or ':after' in
> combination with 'content'.  We just need to wrap the contents of the label
> with an inner span.
> 
> Thoughts?
> 
> - Diana
> 
> 
> 
> On Fri, Jan 15, 2016 at 10:47 AM, Lin Hua Cheng  wrote:
> 
>> It might be simpler to just update the label on the python code. This is
>> where the form label are defined.
>>
>> You can update the label here:
>> https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51
>>
>> -Lin
>>
>>
>> On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia >> wrote:
>>
>>>
>>> Looks like the form comes from django_openstack_auth:
>>>
>>> https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53
>>>
>>>
>>> But to be honest, no idea how that can be overridden trough the themes,
>>> not sure if its even possible to override anything on that page without
>>> modifying django_openstack_auth directly :(
>>>
>>> Maybe someone else has a better insight on this than me.
>>>
>>>
>>> * Horrible Hack Incoming, read at your own discretion *
>>>
>>> You can override the template here:
>>>
>>> https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51
>>>
>>> And change this line:
>>> {{ field.label }}
>>>
>>> For this:
>>> {% if field.label == "User Name" and not
>>> request.user.is_authenticated %}Email{% else %}{{ field.label }}{% endif
>>> %}
>>>
>>>
>>> Which will check if the label is "User Name" and the user is logged out
>>> and directly write "Email" as the field label.
>>>
>>> I know, its horrible and if you update horizon it will be overriden, but
>>> probably works for the time being if you really need it ¯\_(ツ)_/¯
>>>
>>> * Horrible Hack Finished *
>>>
>>>
>>>
>>>
>>> Itxaka
>>>
>>>
>>>
>>>
>>>
>>> On 01/15/2016 05:13 AM, Adrian Turjak wrote:
>>>
 I've run into a weird issue with the Liberty release of Horizon.

 For our deployment we enforce emails as usernames, and thus for Horizon
 we used to have "User Name" on the login page replaced with "Email".
 This used to be a straightforward change in the html template file, and
 with the introduction of themes we assumed it would be the same. When
 one of our designers was migrating our custom CSS and html changes to
 the new theme system they missed that change and I at first it was a
 silly mistake.

 Only on digging through the code myself I found that the "User Name" on
 the login screen isn't in the html file at all, nor anywhere else
 straightforward. The login page form is built on the fly with javascript
 to facilitate different modes of authentication. While a bit annoying
 that didn't seem too bad and I then assumed it might mean a javascript
 change, only that the more I dug, the more I became confused.

 Where exactly is the login form defined? And where exactly is the "User
 Name" text for the login form set?

 I've tried all manner of stuff to change it with no luck and I feel like
 I must have missed something obvious.

 Cheers,
 -Adrian Turjak


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


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

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[Clint Byrum]

Excerpts from Thomas Goirand's message of 2016-01-16 22:36:23 -0800:
> On 01/16/2016 10:16 PM, Jeremy Stanley wrote:
> > On 2016-01-16 12:14:20 +0800 (+0800), Thomas Goirand wrote:
> > [...]
> >> I've just asked this very point with the same example to the FTP
> >> masters. Let's see what they say...
> > 
> > Please point them to the archive for this thread. Specifically it
> > would be helpful for them to give _you_ feedback on your attempts to
> > switch or remove a large free software project's declared
> > contributor copyrights for your own packaging convenience. I
> > particularly find it galling that you suggest we should switch from
> > contributor-held copyright to a copyright assignment model because
> > it would make your life as a package maintainer easier.
> 
> It isn't at all how I wrote things.
> 
> What I wrote is that I feel like the currently situation makes it very
> blurry for one to tell who is the copyright holder(s). I'm seeking a way
> to fix this. It looks like its another failed attempt, as some
> (including you) are opposed to do any of the things I proposed, and
> nobody has a better solution (and I don't see how writing to the legal
> list will change anything). I suppose I can only give-up.

Sorry that this process has you down. I know that I personally have gone
through the exercise of attempting to document the copyright holders
of some very large projects, one of those being MySQL. It is futile and
pointless as long as the original license grant has been verified, and no
evidence of a relicense by all copyright holders is known to exist. Do
you reach out to all of these copyright holders and ask for any such
evidence? No. That would be a massive burden and nobody actually cares. So
why do we have to even know who these people or organizations are?

The point of doing this for Debian is to make sure Debian users can use
the software in the archive confident in their freedoms. That some FTP
masters are sticklers that each file have at least one copyright holder
known is a quirk of Debian, and I think should be addressed directly
in Debian, _not_ here, where we know we're producing and distributing
free software.

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

[openstack-dev] [Murano] Murano actions authentication and accessability

[Stan Lagun]

Hello everyone!

As many of you know, Murano actions is the Murano way to do something
to applications that are already deployed using simple ReST API. For
example, health monitoring system may trigger an action on high CPU
load so that application could scale itself up.

However there are several obstacles that makes it hard to use actions
for such scenarios:

* There is no way to obtain a URI for the action from within MuranoPL
code. If application wants that health monitoring system to call
Murano back it need to provide it with a URI it could use to signal
the event (i.e. URI of the action).
However applications are not aware of Murano API server endpoint and
other required details which makes it hard to construct such a URI
from MuranoPL. This effectively puts a constraint that the action
caller must be murano-aware which is a rare case yet.

* Even if application manages somehow to provide external system with
an action URI, an attempt to call it will require a valid Keystone
token. It is because action URIs are served by Murano API which
requires it and especially because all changes made to applications
must be authorized. This may be a problem, especially when that
external system is not OpenStack-aware and cannot authenticate to
Keystone.


Recently I submitted a specification for review that addresses those
issues. It can be fond here: [1]. It is not perfect and it adds some
pieces of code to Murano that I wish could be handled by Keystone
alone. However it should solve most of use cases we have today.

I'd like to ask anyone who faced those issues or have an experience in
the field to read and share your feedback on the spec. We need to make
sure that it doesn't have serious flaws and does cover your use cases
before we proceed with implementation.
Thanks for your help!

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


Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

__
OpenStack Development Mailing 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] [api] API Working Group Refresher

[Qiming Teng]

On Fri, Jan 15, 2016 at 12:48:51PM +, Chris Dent wrote:
> 
> At yesterday's API Working Group meeting we decided it would be a
> good idea to send out a refresher on the existence of the group,
> its goals and activities. If you have interest in the improvement
> and standardization of OpenStack APIs please take this as an
> invitation to participate.
> 
> The group meets once a week in openstack-meeting-3 on Thursdays
> alternating between 00:00 UTC and 16:00 UTC[0].

The meeting time is quite confusing based on info on the wiki. It says
that 'next' meeting would be 2016-01-28 at 00:00UTC, previous meeting
was 2016-01-14 at 16:00UTC. Do we have a meeting on 2016-01-21? What
timeslot should it be? 16:00UTC or 00:00UTC?

Maybe we should keep at least one 'past' meeting on the wiki page so
that people can get a better idea what's going on?

- Qiming
 
> The primary goal of the group is to help OpenStack HTTP APIs adhere
> to standards and be consistent in the context of OpenStack[1]. To that
> end the main activities of members are:
> 
> * Creating, encouraging projects to create, and reviewing API
>   guidelines:
> 
>   * https://review.openstack.org/#/q/project:openstack/api-wg
>   * http://specs.openstack.org/openstack/api-wg/
> 
>   To be clear these are guidelines, not rules. The members of the
>   API working group are not cops. There's an open question of
>   whether the guidelines should codify existing behaviors or be more
>   aspirational. If you have an opinion on such things, you might
>   like to come along and share it.
> 
> * Providing guidance and sounding boards for changes which impact
>   HTTP APIS:
> 
>   * 
> https://review.openstack.org/#/q/status:open+AND+%28message:ApiImpact+OR+message:APIImpact%29,n,z
> 
> * Exploring existing APIs to get a sense of existing practices and
>   tease out which are "best":
> 
>   * https://wiki.openstack.org/wiki/API_Working_Group/Current_Design
> 
> Ideally every OpenStack project that has an HTTP API should have a
> designated cross project liaison who is willing to participate in the
> API working group and operate as bi-directional conduit. Talk to your
> PTL if you want this responsibility and then show up at the meetings.
> 
> [0] https://wiki.openstack.org/wiki/Meetings/API-WG
> [1] https://wiki.openstack.org/wiki/API_Working_Group#Purpose
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent



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

[IWAMOTO Toshihiro]

I'm sending out this mail to share the finding and discuss how to
improve with those interested in neutron ovs performance.

TL;DR: The native of_interface code, which has been merged recently
and isn't default, seems to consume less CPU time but gives a mixed
result.  I'm looking into this for improvement.

* Introduction

With an ML2+ovs Neutron configuration, openflow rule modification
happens often and is somewhat a heavy operation as it involves
exec() of the ovs-ofctl command.

The native of_interface driver doesn't use the ovs-ofctl command and
should have less performance impact on the system.  This document
tries to confirm this hypothesis.


* Method

In order to focus on openflow rule operation time and avoid noise from
other operations (VM boot-up, etc.), neutron-openvswitch-agent was
restarted and the time it took to reconfigure the flows was measured.

1. Use devstack to start a test environment.  As debug logs generate
   considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
2. Apply https://review.openstack.org/#/c/267905/ to enable
   measurement of flow reconfiguration times.
3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
   flows.  If you have >16G RAM, more could be booted.
4. Stop neutron-openvswitch-agent and restart with --run-once arg.
   Use time, oprofile, and python's cProfile (use --profile arg) to
   collect data.

* Results

Execution time (averages of 3 runs):

native 28.3s user 2.9s sys 0.4s
ovs-ofctl  25.7s user 2.2s sys 0.3s

ovs-ofctl runs faster and seems to use less CPU, but the above doesn't
count in execution time of ovs-ofctl.

Oprofile data collected by running "operf -s -t" contain the
information.

With of_interface=native config, "opreport tgid:" shows:

   samples|  %|
--
87408 100.000 python2.7
CPU_CLK_UNHALT...|
  samples|  %|
--
69160 79.1232 python2.7
 8416  9.6284 vmlinux-3.13.0-24-generic

and "opreport --merge tgid" doesn't show ovs-ofctl.

With of_interface=ovs-ofctl, "opreport tgid:" shows:

   samples|  %|
--
62771 100.000 python2.7
CPU_CLK_UNHALT...|
  samples|  %|
--
49418 78.7274 python2.7
 6483 10.3280 vmlinux-3.13.0-24-generic

and  "opreport --merge tgid" shows CPU consumption by ovs-ofctl 

35774  3.5979 ovs-ofctl
CPU_CLK_UNHALT...|
  samples|  %|
--
28219 78.8813 vmlinux-3.13.0-24-generic
 3487  9.7473 ld-2.19.so
 2301  6.4320 ovs-ofctl

Comparing 87408 (native python) with 62771+35774, the native
of_interface uses 0.4s less CPU time overall.

* Conclusion and future steps

The native of_interface uses slightly less CPU time but takes longer
time to complete a flow reconfiguration after an agent restart.

As an OVS agent accounts for only 1/10th of total CPU usage during a
flow reconfiguration (data not shown), there may be other areas for
improvement.

The cProfile Python module gives more fine grained data, but no
apparent performance bottleneck was found.  The data show more
eventlet context switches with the native of_interface, which is due
to how the native of_interface is written.  I'm looking into for
improving CPU usage and latency.



__
OpenStack Development Mailing 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] Exception request : [stable] Ironic doesn't use cacert while talking to Swift ( https://review.openstack.org/#/c/253460/)

[Nisha Agarwal]

Hello Team,

This patch got approval long back(Jan 6)  but due to Jenkins failure in the
merge pipeline of the Kilo branch, this patch was not merged.

Hence I request for an exception for this patch as  this was not merged due
to Jenkins issue.

Regards
Nisha

-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

[Martin André]

On Sat, Jan 16, 2016 at 5:34 AM, Harm Weites  wrote:

> Hi guys,
>
> As Steven noted, activity from my side has dropped significantly, and with
> +2 comes a certain responsibility of at the very least keeping track of the
> codebase. Various reasons keep me from even doing that so this seems the
> logical outcome.
>
> Thanks for your support, it’s been a great ride :)
>
> see you in #kolla!
>

Harm, I know from experience it's difficult to keep up to date with Kolla's
codebase, even after a small hiatus. Thanks for your helpful reviews. I
hope we'll see you again soon among the core reviewers.

Martin


> Op 15 jan. 2016, om 20:10 heeft Steven Dake (stdake) 
> het volgende geschreven:
>
> I counted 6 votes in favor of removal.  We have 10 people on our core
> team.  A majority has been met and I have removed Harm from the core
> reviewer team.
>
> Harm,
>
> Thanks again for your helpful reviews and remember, your always welcome
> back in the future if your availability changes.
>
> For the record, the core reviewers that voted for removal were:
> Steven Dake
> Jeff Peeler
> Paul Bourke
> Michal Jastrzebski
> Ryan Hallisey
> Michal Rostecki
>
> Regards,
> -steve
>
>
> From: Steven Dake 
> Reply-To: openstack-dev 
> Date: Thursday, January 14, 2016 at 5:12 PM
> To: openstack-dev 
> Subject: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites
> from the core reviewer team
>
> Hi fellow core reviewers,
>
> Harm joined Kolla early on with great enthusiasm and did a bang-up job for
> several months working on Kolla.  We voted unanimously to add him to the
> core team.  Over the last 6 months Harm hasn't really made much
> contribution to Kolla.  I have spoken to him about it in the past, and he
> indicated his work and other activities keep him from being able to execute
> the full job of a core reviewer and nothing environmental is changing in
> the near term that would improve things.
>
> I faced a similar work/life balance problem when working on Magnum as a
> core reviewer and also serving as PTL for Kolla.  My answer there was to
> step down from the Magnum core reviewer team [1] because Kolla needed a PTL
> more then Magnum needed a core reviewer.  I would strongly prefer if folks
> don't have the time available to serve as a Kolla core reviewer, to step
> down as was done in the above example.  Folks that follow this path will
> always be welcome back as a core reviewer in the future once they become
> familiar with the code base, people, and the project.
>
> The other alternative to stepping down is for the core reviewer team to
> vote to remove an individual from the core review team if that is deemed
> necessary.  For future reference, if you as a core reviewer have concerns
> about a fellow core reviewer's performance, please contact the current PTL
> who will discuss the issue with you.
>
> I propose removing Harm from the core review team.  Please vote:
>
> +1 = remove Harm from the core review team
> -1 = don't remove Harm from the core review team
>
> Note folks that are voted off the core review team are always welcome to
> rejoin the core team in the future once they become familiar with the code
> base, people, and the project.  Harm is a great guy, and I hope in the
> future he has more time available to rejoin the Kolla core review team
> assuming this vote passes with simple majority.
>
> It is important to explain why, for some folks that may be new to a core
> reviewer role (which many of our core reviewers are), why a core reviewer
> should have their +2/-2 voting rights removed when they become inactive or
> their activity drops below an acceptable threshold for extended or
> permanent periods.  This hasn't happened in Harm's case, but it is possible
> that a core reviewer could approve a patch that is incorrect because they
> lack sufficient context with the code base.  Our core reviewers are the
> most important part of ensuring quality software.  If the individual has
> lost context with the code base, their voting may be suspect, and more
> importantly the other core reviewers may not trust the individual's votes.
> Trust is the cornerstone of a software review process, so we need to
> maximize trust on a technical level between our core team members.  That is
> why maintaining context with the code base is critical and why I am
> proposing a vote to remove Harm from the core reviewer team.
>
> On a final note, folks should always know, joining the core review team is
> never "permanent".  Folks are free to move on if their interests take them
> into other areas or their availability becomes limited.  Core Reviewers can
> also be removed by majority vote.  If there is any core reviewer's
> performance you are concerned with, please contact the current PTL to first
> work on improving performance, or alternatively initiating a core reviewer
> removal 

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Samuel Bercovici]

Btw.

I am still in favor on associating the subnets to the LB and then not specify 
them per node at all.

-Sam.


-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com] 
Sent: Sunday, January 17, 2016 10:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be 
optional on member create?

+1
Subnet should be mandatory

The only thing this makes supporting load balancing servers which are not 
running in the cloud more challenging to support.
But I do not see this as a huge user story (lb in cloud load balancing IPs 
outside the cloud)

-Sam.

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Saturday, January 16, 2016 6:56 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on 
member create?

I filed a bug [1] a while ago that subnet_id should be an optional parameter 
for member creation.  Currently it is required.  Review [2] is makes it 
optional.

The original thinking was that if the load balancer is ever connected to that 
same subnet, be it by another member on that subnet or the vip on that subnet, 
then the user does not need to specify the subnet for new member if that new 
member is on one of those subnets.

At the midcycle we discussed it and we had an informal agreement that it 
required too many assumptions on the part of the end user, neutron lbaas, and 
driver.

If anyone wants to voice their opinion on this matter, do so on the bug report, 
review, or in response to this thread.  Otherwise, it'll probably be abandoned 
and not done at some point.

Thanks,
Brandon

[1] https://bugs.launchpad.net/neutron/+bug/1426248
[2] https://review.openstack.org/#/c/267935/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

[Martin André]

On Sun, Jan 17, 2016 at 1:29 PM, Steven Dake (stdake) 
wrote:

> Ryan,
>
> I read your response and the idea of incubators is interesting, but the
> risk there is we will end up with "two core teams" with different
> objectives, purpose, focus, and most importantly a lack of coordinated
> efforts and thinking.  I'd like to experiment with converting two of our
> meetings to an apac timezone meeting, since the main problem I think at
> the moment is some folks in apac can't participate in our weekly meetings.
>
> How do folks feel about that idea?
>

Steve, the risk in doing so is to have two completely different groups of
core reviewers attending the different meetings. I would be opposed for
example to an APAC friendly meeting time where you and other highly active
members can't join. We've tried in the past and it didn't work well. Maybe
now we'll be able to get more people attend the APAC friendly meeting.
Basically I'm not in favor of anything that would split up the community,
kolla-* projects should all work toward a common goal.

Angus, I feel your pain. The meeting is at 1:30 am for me (for two more
month before I move to EMEA), and I would also be happy with a more decent
meeting time.

Martin


> Thanks
> -steve
>
> Regards
> -steve
>
> On 1/15/16, 6:10 AM, "Ryan Hallisey"  wrote:
>
> >Hello,
> >
> >I think creating a separate kolla-mesos meeting is a good idea. My only
> >issue is that I'm a little afraid it might separate our community a
> >little, but I think it's necessary for kolla-mesos to grow.  My other
> >thought is what is there to come of other kolla-* repos? That being not
> >only kolla-mesos, but in the future kolla-anisble.  Maybe kolla meetings
> >can be an incubator for those repos until they need to move out on their
> >own?  Just a thought here.
> >
> >+1
> >-Ryan
> >
> >- Original Message -
> >From: "Michal Rostecki" 
> >To: openstack-dev@lists.openstack.org
> >Sent: Friday, January 15, 2016 6:38:39 AM
> >Subject: [openstack-dev] [kolla] kolla-mesos IRC meeting
> >
> >Hi,
> >
> >Currently we're discussing stuff about kolla-mesos project on kolla IRC
> >meetings[1]. We have an idea of creating the separate meeting for
> >kolla-mesos. I see the following reasons for that:
> >
> >- kolla-mesos has some contributors which aren't able to attend kolla
> >meeting because of timezone reasons
> >- kolla meetings had a lot of topics recently and there was a short time
> >for discussing kolla-mesos things
> >- in the most of kolla meetings, we treated the whole kolla-mesos as one
> >topic, which is bad in terms of analyzing single problems inside this
> >project
> >
> >The things I would like to know from you is:
> >- whether you're +1 or -1 to the whole idea of having separate meeting
> >- what is your preferred time of meeting - please use this etherpad[2]
> >(I already added there some names of most active contributors from who
> >I'd like to hear an opinion, so if you're interested - please "override
> >color"; if not, remove the corresponding line)
> >
> >About the time of meeting and possible conflicts - I think that in case
> >of conflicting times and the equal number of votes, opinion of core
> >reviewers and people who are already contributing to the project
> >(reviews and commits) will be more important. You can see the
> >contributors here[3][4].
> >
> >[1] https://wiki.openstack.org/wiki/Meetings/Kolla
> >[2] https://etherpad.openstack.org/p/kolla-mesos-irc-meeting
> >[3] http://stackalytics.com/?module=kolla-mesos
> >[4] http://stackalytics.com/?module=kolla-mesos=commits
> >
> >Cheers,
> >Michal
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] [mistral] Proposal for new resource type - OS::Mistral::WorkflowExecution

[MENDEL, Sharon (Sharon)]

This spec proposes a new Heat resource type -  OS::Mistral::WorkflowExecution .
This new resource type will enable more control on execution of Mistral 
workflows when deploying a service in heat.
Specifically it will  provide feedback whether the execution succeeded or 
failed, which is important in cases where the workflow execution is an 
important part of the stack (preparation, post configuration, etc.) and if that 
fails we would like to fail the stack creation.
Moreover it will it will simplify stacks of use cases in which there is a need 
as part of the deployment to create resources and  run the workflows in a 
certain order

Please review the spec [1] -

[1] http://review.openstack.org/267770




__
OpenStack Development Mailing 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][LBaaS][Octavia] Should subnet be optional on member create?

[Samuel Bercovici]

+1
Subnet should be mandatory

The only thing this makes supporting load balancing servers which are not 
running in the cloud more challenging to support.
But I do not see this as a huge user story (lb in cloud load balancing IPs 
outside the cloud)

-Sam.

-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com] 
Sent: Saturday, January 16, 2016 6:56 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on 
member create?

I filed a bug [1] a while ago that subnet_id should be an optional parameter 
for member creation.  Currently it is required.  Review [2] is makes it 
optional.

The original thinking was that if the load balancer is ever connected to that 
same subnet, be it by another member on that subnet or the vip on that subnet, 
then the user does not need to specify the subnet for new member if that new 
member is on one of those subnets.

At the midcycle we discussed it and we had an informal agreement that it 
required too many assumptions on the part of the end user, neutron lbaas, and 
driver.

If anyone wants to voice their opinion on this matter, do so on the bug report, 
review, or in response to this thread.  Otherwise, it'll probably be abandoned 
and not done at some point.

Thanks,
Brandon

[1] https://bugs.launchpad.net/neutron/+bug/1426248
[2] https://review.openstack.org/#/c/267935/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

[Michal Rostecki]

On 01/17/2016 05:29 AM, Steven Dake (stdake) wrote:

Ryan,

I read your response and the idea of incubators is interesting, but the
risk there is we will end up with "two core teams" with different
objectives, purpose, focus, and most importantly a lack of coordinated
efforts and thinking.  I'd like to experiment with converting two of our
meetings to an apac timezone meeting, since the main problem I think at
the moment is some folks in apac can't participate in our weekly meetings.

How do folks feel about that idea?

Thanks
-steve


If proposal with kolla-mesos meeting is rejected now, I'm OK with trying 
with scheduling kolla meeting to APAC timezone. At least we may solve a 
problem with availability of Angus.


Cheers,
Michal

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

Re: [openstack-dev] [devstack] Failure on installing openstack with latest devstack.

[Nader Lahouti]

Vikram,

Removing the clouds.yaml did not help. It causes the following error:

8:48:28.810 | SCREEN_LOGDIR:

2016-01-17 08:48:28.810 | log: /opt/stack/logs/g-reg.log.2016-01-17-004213

2016-01-17 08:48:31.857 | Waiting for g-api (openstack-server:9292) to
start...

2016-01-17 08:49:33.081 | Named cloud devstack-admin requested that was not
found.

2016-01-17 08:49:33.798 | Named cloud devstack-admin requested that was not
found.

2016-01-17 08:49:34.658 | Named cloud devstack-admin requested that was not
found.

2016-01-17 08:49:34.680 | Error on exit



Thanks,

Nader.

On Sat, Jan 16, 2016 at 6:50 PM, Vikram Choudhary  wrote:

> Remove cloud.yaml file and try!
>
> *os-client-config* will look for a file called *clouds.yaml*in the
> following locations:
>
> Current Directory
> ~/.config/openstack
> /etc/openstack
>
> Thanks
> Vikram
> On Jan 17, 2016 8:19 AM, "Vikram Choudhary"  wrote:
>
>> Remove cloud.yaml file try!
>>
>> *os-client-config* will look for a file called *clouds.yaml*in the
>> following locations:
>>
>> Current Directory~/.config/openstack/etc/openstack
>>
>> Thanks
>> Vikram
>> Hi,
>>
>> I'm continuously seeing failure installing openstack with latest
>> devstack. It exits with the following messages:
>>
>> ==
>> 
>>
>>
>>  
>> ramdisk=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
>>
>> ++ for f in '"$xdir/"*.img' '"$xdir/"ami-*/image'
>>
>> ++ '[' -f
>> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
>> ']'
>>
>> ++ echo
>> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
>>
>> ++ break
>>
>> ++ true
>>
>> +
>> image=/home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-blank.img
>>
>> + [[ -z cirros-0.3.4-x86_64-uec ]]
>>
>> + is_arch ppc64
>>
>> ++ uname -m
>>
>> + [[ x86_64 == \p\p\c\6\4 ]]
>>
>> + is_arch aarch64
>>
>> ++ uname -m
>>
>> + [[ x86_64 == \a\a\r\c\h\6\4 ]]
>>
>> + '[' '' = bare ']'
>>
>> + local kernel_id= ramdisk_id=
>>
>> + '[' -n
>> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
>> ']'
>>
>> ++ openstack --os-cloud=devstack-admin image create
>> cirros-0.3.4-x86_64-uec-kernel --public --container-format aki
>> --disk-format aki
>>
>> ++ grep ' id '
>>
>> ++ get_field 2
>>
>> ++ local data field
>>
>> ++ read data
>>
>> Could not determine a suitable URL for the plugin
>>
>> + kernel_id=
>>
>> + '[' -n
>> /home/localadmin/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
>> ']'
>>
>> ++ openstack --os-cloud=devstack-admin image create
>> cirros-0.3.4-x86_64-uec-ramdisk --public --container-format ari
>> --disk-format ari
>>
>> ++ grep ' id '
>>
>> ++ get_field 2
>>
>> ++ local data field
>>
>> ++ read data
>>
>> *Could not determine a suitable URL for the plugin*
>>
>> + ramdisk_id=
>>
>> + openstack --os-cloud=devstack-admin image create
>> cirros-0.3.4-x86_64-uec --public --container-format ami --disk-format ami
>>
>> *Could not determine a suitable URL for the plugin*
>>
>> + exit_trap
>>
>> + local r=1
>>
>> ++ jobs -p
>>
>> + jobs=
>>
>> + [[ -n '' ]]
>>
>> + kill_spinner
>>
>> + '[' '!' -z '' ']'
>>
>> + [[ 1 -ne 0 ]]
>>
>> + echo 'Error on exit'
>>
>> Error on exit
>>
>> + [[ -z /opt/stack/logs ]]
>>
>> + /home/localadmin/devstack/tools/worlddump.py -d /opt/stack/logs
>>
>> World dumping... see /opt/stack/logs/worlddump-2016-01-15-231937.txt for
>> details
>>
>> + exit 1
>>
>> Fri, 15. Jan 2016,15:19:37
>>
>>
>> 
>>
>> Has anybody seen the same issue?
>>
>> Thanks,
>> Nader.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ec2-api] Removing Nova's In tree ec2 API code in favor of ec2-api project

[Alexandre Levine]

I've created a review: https://review.openstack.org/#/c/268774/

Best regards,
  Alex Levine

On 1/8/16 3:45 PM, Thierry Carrez wrote:

Alexandre Levine wrote:

The ec2-api project is in gating and totally functional. We'll apply for
it to become OpenStack project very shortly. Next week in fact.


Great to hear! Thanks Alex.




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

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

[Michał Jastrzębski]

Hey,

Since we're growing and if anything, more people will join kolla from
APAC (we already see few new faces this release), I'd vote for
re-introducing apac-friendly meeting. We'll need to do it anyway at
some point.

Cheers,
Michal./

On 17 January 2016 at 03:26, Martin André  wrote:
>
>
> On Sun, Jan 17, 2016 at 1:29 PM, Steven Dake (stdake) 
> wrote:
>>
>> Ryan,
>>
>> I read your response and the idea of incubators is interesting, but the
>> risk there is we will end up with "two core teams" with different
>> objectives, purpose, focus, and most importantly a lack of coordinated
>> efforts and thinking.  I'd like to experiment with converting two of our
>> meetings to an apac timezone meeting, since the main problem I think at
>> the moment is some folks in apac can't participate in our weekly meetings.
>>
>> How do folks feel about that idea?
>
>
> Steve, the risk in doing so is to have two completely different groups of
> core reviewers attending the different meetings. I would be opposed for
> example to an APAC friendly meeting time where you and other highly active
> members can't join. We've tried in the past and it didn't work well. Maybe
> now we'll be able to get more people attend the APAC friendly meeting.
> Basically I'm not in favor of anything that would split up the community,
> kolla-* projects should all work toward a common goal.
>
> Angus, I feel your pain. The meeting is at 1:30 am for me (for two more
> month before I move to EMEA), and I would also be happy with a more decent
> meeting time.
>
> Martin
>
>>
>> Thanks
>> -steve
>>
>> Regards
>> -steve
>>
>> On 1/15/16, 6:10 AM, "Ryan Hallisey"  wrote:
>>
>> >Hello,
>> >
>> >I think creating a separate kolla-mesos meeting is a good idea. My only
>> >issue is that I'm a little afraid it might separate our community a
>> >little, but I think it's necessary for kolla-mesos to grow.  My other
>> >thought is what is there to come of other kolla-* repos? That being not
>> >only kolla-mesos, but in the future kolla-anisble.  Maybe kolla meetings
>> >can be an incubator for those repos until they need to move out on their
>> >own?  Just a thought here.
>> >
>> >+1
>> >-Ryan
>> >
>> >- Original Message -
>> >From: "Michal Rostecki" 
>> >To: openstack-dev@lists.openstack.org
>> >Sent: Friday, January 15, 2016 6:38:39 AM
>> >Subject: [openstack-dev] [kolla] kolla-mesos IRC meeting
>> >
>> >Hi,
>> >
>> >Currently we're discussing stuff about kolla-mesos project on kolla IRC
>> >meetings[1]. We have an idea of creating the separate meeting for
>> >kolla-mesos. I see the following reasons for that:
>> >
>> >- kolla-mesos has some contributors which aren't able to attend kolla
>> >meeting because of timezone reasons
>> >- kolla meetings had a lot of topics recently and there was a short time
>> >for discussing kolla-mesos things
>> >- in the most of kolla meetings, we treated the whole kolla-mesos as one
>> >topic, which is bad in terms of analyzing single problems inside this
>> >project
>> >
>> >The things I would like to know from you is:
>> >- whether you're +1 or -1 to the whole idea of having separate meeting
>> >- what is your preferred time of meeting - please use this etherpad[2]
>> >(I already added there some names of most active contributors from who
>> >I'd like to hear an opinion, so if you're interested - please "override
>> >color"; if not, remove the corresponding line)
>> >
>> >About the time of meeting and possible conflicts - I think that in case
>> >of conflicting times and the equal number of votes, opinion of core
>> >reviewers and people who are already contributing to the project
>> >(reviews and commits) will be more important. You can see the
>> >contributors here[3][4].
>> >
>> >[1] https://wiki.openstack.org/wiki/Meetings/Kolla
>> >[2] https://etherpad.openstack.org/p/kolla-mesos-irc-meeting
>> >[3] http://stackalytics.com/?module=kolla-mesos
>> >[4] http://stackalytics.com/?module=kolla-mesos=commits
>> >
>> >Cheers,
>> >Michal
>> >
>>
>> > >__
>> >OpenStack Development Mailing List (not for usage questions)
>> >Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> > >__
>> >OpenStack Development Mailing List (not for usage questions)
>> >Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[Jeremy Stanley]

On 2016-01-17 14:36:23 +0800 (+0800), Thomas Goirand wrote:
[...]
> What I wrote is that I feel like the currently situation makes it
> very blurry for one to tell who is the copyright holder(s). I'm
> seeking a way to fix this.

I fail to see what's blurry about it. The contributors who feel
compelled to acknowledge their copyright or that of their employer
do so by adding or updating a comment at the top of the file to
which they're contributing. This is typical of many (I hesitate to
say "most" though I suspect it may be) projects, and is a
long-standing part of our culture in the greater free software
community.

I am definitely (and happily) not a lawyer, but the instructions at
http://www.apache.org/licenses/LICENSE-2.0.html#apply indicate that
at least one copyright notice is expected when applying the Apache
License, Version 2.0. There is also nothing out of the ordinary with
files having multiple copyright holders declared (because they made
significant copyrightable contributions to the same file at
different points in time), nor with different files in a project
having different copyright holders. Further, section 4c of the
license indicates that copyright and attribution notices must be
redistributed even in derivative works, and it seems pretty obvious
that any patch updating a file results in a derivative work of the
prior version of that same file, so retaining our existing copyright
notices is necessary (in my non-lawyer opinion).

> It looks like its another failed attempt, as some (including you)
> are opposed to do any of the things I proposed, and nobody has a
> better solution (and I don't see how writing to the legal list
> will change anything). I suppose I can only give-up.

I am (and probably others are as well) unlikely to be convinced
without prominent lawyers who possess expertise in free software and
copyright law weighing in on efficacy and viability of your proposed
changes. Also suggestions which have any bearing on the
responsibilities of the OpenStack Foundation (such as switching to a
copyright assignment model) would need input from their legal
counsel, and possibly even a majority vote of the foundation
membership to actually enact.
-- 
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