Re: [openstack-dev] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Lana Brindley]

On 09/04/16 10:05, Anne Gentle wrote:
> Okay. I'll try to propose an idea.
> 
> In the Mitaka install spec review, [1] I asked if the drama was worth the 
> extra effort to remove. Personally I don't believe so, having refereed this 
> discussion for years now.
> 
> I think you're both reasonable people and do believe in OpenStack. You both 
> want it to succeed, yet for the particular goals of the install guide you 
> haven't come to consensus. That's fine.


Anne has, as usual, stated my opinion much more eloquently than I ever would be 
able to. Thomas and Matt, this has been an ongoing feud since well before I was 
around, and while I understand we're not there yet, every release brings us so 
much closer to an Install Guide solution that will work for everyone. Not just 
to get a Debian Install Guide published, but to get an Install Guide that 
covers every project in the big tent. This conversation, and the many other 
conversations we have had on this topic over the past few months will again 
form a large part of the agenda at the design summit, and I look forward to 
being able to hash this out in more detail then.

> 
> I have another idea for a way forward that doesn't require consensus across 
> teams. Now that we have the governance in place for debian packaging, let's 
> move the debian install guide to a new repo that can go under the packaging 
> project, and you can create and maintain build jobs for the debian install 
> guide. No one will have the additional burden of maintaining conditional 
> text. You can write what you like and publish what you want, taking 
> responsibility for quality control and ongoing maintenance.
> 
> Monty's the PTL for packaging-rpm. [2] Can you envision a 
> debian-install-guide repo within the packaging-rpm team, with both a review 
> team and bug triaging only for that repo? You'll need to work on the gate and 
> build jobs as well, but I truly believe we have the systems in place to 
> enable this. And with the direction of the individual projects taking 
> responsibility for their install guides, we have a framework we're moving 
> towards and this case seems to fit the new framework. [3]
> 
> I think it's a great use of the time you have now, and lets us all stop 
> losing time to the debate.

+1

L

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] [magnum] Enhance Mesos bay to a DCOS bay

[Adrian Otto]

On Apr 8, 2016, at 3:15 PM, Hongbin Lu 
> wrote:

Hi team,
I would like to give an update for this thread. In the last team, we discussed 
several options to introduce Chronos to our mesos bay:
1.   Add Chronos to the mesos bay. With this option, the mesos bay will 
have two mesos frameworks by default (Marathon and Chronos).
2.   Add a configuration hook for users to configure additional mesos 
frameworks, such as Chronos. With this option, Magnum team doesn’t need to 
maintain extra framework configuration. However, users need to do it themselves.

This is my preference.

Adrian

3.   Create a dedicated bay type for Chronos. With this option, we separate 
Marathon and Chronos into two different bay types. As a result, each bay type 
becomes easier to maintain, but those two mesos framework cannot share 
resources (a key feature of mesos is to have different frameworks running on 
the same cluster to increase resource utilization).
Which option you prefer? Or you have other suggestions? Advices are welcome.

Best regards,
Hongbin

From: Guz Egor [mailto:guz_e...@yahoo.com]
Sent: March-28-16 12:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Jay,

just keep in mind that Chronos can be run by Marathon.

---
Egor


From: Jay Lau >
To: OpenStack Development Mailing List (not for usage questions) 
>
Sent: Friday, March 25, 2016 7:01 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to 
Mesos Bay to make it can handle both long running services and batch jobs.

Thanks,

On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki 
> wrote:

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy
a DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here
https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)

Sorry if I'm missing something, but isn't DCOS a closed source software?

However, the "DCOS cli"[1] seems to be working perfectly with Marathon and 
Mesos installed by any way if you configure it well. I think that the thing 
which can be done in Magnum is to make the experience with "DOCS" tools as easy 
as possible by using open source components from Mesosphere.

Cheers,
Michal

[1] https://github.com/mesosphere/dcos-cli

__
OpenStack Development Mailing 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,
Jay Lau (Guangya Liu)

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Diana Clarke]

On Fri, Apr 8, 2016 at 5:23 PM, Davanum Srinivas  wrote:
> To that effect, i am capturing stuff here:
> https://davanum.wordpress.com/2016/04/08/new-to-openstack-reviews-start-here/

Here are a few more links for your list, Dims. I remember especially
liking Sean's blog post, and I think of it often when I start feeling
discouraged about review turnaround time.

  https://dague.net/2014/02/28/why-you-should-be-reviewing-more-openstack-code/

  
http://docs.openstack.org/developer/nova/how_to_get_involved.html#why-do-code-reviews-if-i-am-not-in-nova-core

  http://docs.openstack.org/infra/manual/developers.html#peer-review

Have a great weekend, folks!

--diana

__
OpenStack Development Mailing 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][elections] Results of the TC Election

[Monty Taylor]

On 04/08/2016 02:01 PM, Tim Bell wrote:


On 08/04/16 20:08, "gordon chung"  wrote:




On 08/04/2016 9:14 AM, Thierry Carrez wrote:

Eoghan Glynn wrote:

However, the turnout continues to slide, dipping below 20% for
the first time:


Election | Electorate (delta %) | Votes | Turnout (delta %)
===
Oct '13  | 1106 | 342   | 30.92
Apr '14  | 1510(+36.52)  | 448   | 29.69   (-4.05)
Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)



This ongoing trend of a decreasing proportion of the electorate
participating in TC elections is a concern.


One way to look at it is that every cycle (mostly due to the habit of
giving summit passes to recent contributors) we have more and more
one-patch contributors (more than 600 in Mitaka), and those usually are
not really interested in voting... So the electorate number is a bit
inflated, resulting in an apparent drop in turnout.

It would be interesting to run the same analysis but taking only >=3
patch contributors as "expected voters" and see if the turnout still
drops as much.

Long term I'd like to remove the summit pass perk (or no longer link it
to "one commit"). It will likely result in a drop in contributors
numbers (gasp), but a saner electorate.



just for reference, while only affecting a subset of the electorate, if
you look at the PTL elections, they all had over 40% turnout (even the
older and larger projects).

it may be because of those with "one commit", but if that were the case,
you would think the turnout would be inline/similar to the PTL elections.


It could also be that the projects with the lower hanging fruit were 
uncontested.

BTW, I don’t feel that a 1 commit person should be ignored in the voting. Many 
of us
have roles which do not mean we spend all the time committing but when we see 
something
wrong in the docs, spend a few hours to go through the process. I certainly 
favor
those PTLs/TC members in my voting who still count the sum of this contribution 
to be significant.

As we progress further with the UC-Recognition activity, there will be further 
discussion
on this so I feel waiting for that work to make a proposal on how those people 
could also
contribute to setting the technical direction.


I think the two thoughts are not mutually exclusive. The existence of a 
commit was an easy thing to track early on. I think it's problematic 
both in being too lax a guide for who is involved as the one commit 
issue shows, and also too strict - as the UC/Operator problem shows.


Ultimately the question isn't "how many commits is the right number" but 
"how do we recognize our electorate as close as we can as being the set 
of people who are actually involved and interested and part of the 
community". I'm pretty sure all systems we will devise to describe such 
a set of people will be deficient in some way, but I think purely one 
commit can be improved on from many directions.


Monty


__
OpenStack Development Mailing 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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Anne Gentle]

Okay. I'll try to propose an idea.

In the Mitaka install spec review, [1] I asked if the drama was worth the
extra effort to remove. Personally I don't believe so, having refereed this
discussion for years now.

I think you're both reasonable people and do believe in OpenStack. You both
want it to succeed, yet for the particular goals of the install guide you
haven't come to consensus. That's fine.

I have another idea for a way forward that doesn't require consensus across
teams. Now that we have the governance in place for debian packaging, let's
move the debian install guide to a new repo that can go under the packaging
project, and you can create and maintain build jobs for the debian install
guide. No one will have the additional burden of maintaining conditional
text. You can write what you like and publish what you want, taking
responsibility for quality control and ongoing maintenance.

Monty's the PTL for packaging-rpm. [2] Can you envision a
debian-install-guide repo within the packaging-rpm team, with both a review
team and bug triaging only for that repo? You'll need to work on the gate
and build jobs as well, but I truly believe we have the systems in place to
enable this. And with the direction of the individual projects taking
responsibility for their install guides, we have a framework we're moving
towards and this case seems to fit the new framework. [3]

I think it's a great use of the time you have now, and lets us all stop
losing time to the debate.

Thoughts?
Anne

1.
https://review.openstack.org/#/c/274231/4/specs/mitaka/installguide-mitaka.rst
2.
http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Packaging-Deb/Monty_Taylor.txt
3. https://review.openstack.org/#/c/301284/


On Fri, Apr 8, 2016 at 11:47 AM, Thomas Goirand  wrote:

> I don't do ab-dominem pointing fingers. I believe this is normally
> detrimental to the project. However, I don't have any choice in this
> case. Matthew is consistently attempting to remove the Debian support
> from the install-guide. He's doing it again:
>
> https://review.openstack.org/#/c/302934/
>
> And without any discussion with me, who did all of the work. And again,
> just after the release, which is when I usually have the time to work
> again on the install-guide.
>
> The first time it happened, was when the install-guide was converted to
> RST. I was told I couldn't commit, as it was frozen.
>
> This type of behavior is completely in opposition to what we've voted
> for: the bit tent, where everyone is welcome. In this case Matthew, is
> clearly making a war against Debian support in the install-guide. I
> don't want this to happen.
>
> Matthew, in his CR, wrote:
> "lack of maintenance and usability"
>
> Well, first of all, I don't agree with that. Second, like on every
> releases, I intended to work on it after the packages were done, for the
> Mitaka release.
>
> Another thing is that the Debian packages are the only ones available
> for many services, as Canonical doesn't work on them (these packages are
> just sync from Debian, at best). So we'd be effectively removing the
> only OS where it can be installed.
>
> I received *many* feedback from people who would like to see more of
> Debian in the install-guide, not less, and even less get it completely
> removed. During a year, I had to point to the direct link where the
> Debian guide was installed, as the link on docs.openstack.org was
> removed (up to now, still don't understand why this happened). Now, even
> the generation of the Debian docs is removed, and I can't point to it.
>
> This has to stop. This is disgusting, and with no valid reason. The same
> way every project should be welcome in the install-guide, contributors
> should be welcome, and for all operating systems.
>
> 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
>



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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Tom Barron]

On 04/08/2016 05:16 PM, Anita Kuno wrote:
> On 04/08/2016 05:10 PM, gordon chung wrote:
>>
>>
>> On 08/04/2016 1:26 PM, Davanum Srinivas wrote:
>>> Team,
>>>
>>> Steve pointed out to a problem in Stackalytics:
>>> https://twitter.com/stevebot/status/718185667709267969
>>>
>>> It's pretty clear what's happening if you look here:
>>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>>
>>> Here's the drastic step (i'd like to avoid):
>>> https://review.openstack.org/#/c/303545/
>>>
>>
>> is it actually affecting anything in the community aside from the 
>> reviews being useless. aside from the 'diversity' tags in governance, 
>> does anything else use stackalytics?
>>
>> cheers,
>>
> Some company managers only look as far as stackalytics to calculate
> career decisions for their group.
> 
> Sad but true.
> 

Certainly true, and sad, but "some" is a quantifier that starts at
greater than zero and runs on up from there :-)

IMO we non-managers also have to take responsibility for a system that
uses quantitative measures that "gamify" OpenStack performance.  Humans
respond to this kind of reward system.  They aren't (for that reason at
least) evil and the effect is not all that surprising.  The harder
question is whether there is a better way to set things up, or more to
the point, since many of us are sure there is, exactly what it is.

-- Tom

> Anita.
> 
> __
> OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Armando M.]

On 8 April 2016 at 11:06, Sean Dague  wrote:

> On 04/08/2016 12:05 PM, Morales, Victor wrote:
> > Agree, sometimes is hard to figure out what is the Devstack variable
> that will modify the configuration value.
> >
> > There is an effort to categorize the configuration options[1] of some of
> the projects.  I’m wondering if it could be possible to create category or
> field that specifies the Destack variable that changes this configuration
> value.
> >
> > [1]
> https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst
>
> I really don't think that Devstack should leak that far back into real
> projects.
>
> Devstack variables make a ton of sense when you are communicating a
> higher level construct, and it needs to do some logic on it and possibly
> set multiple things.
>
> Devstack variables that are basically pass through for individual config
> vars aren't really a good idea. We try to -1 them all now. But a lot of
> leaked in.
>
> I think Sean Collins' plan is a good one.
>
> -Sean
>
>
The plethora of networking-specific config variables is a vestigial
presence of a time where local.conf and the plugin mechanism was not in
place in DevStack. Bear in mind that this is not a Neutron specific
problem: all projects are affected more or less equally.

I 100% agree with SeanD that the proposals of passthrough variables is to
be shot down. Those that are used to tune more than one variable at any
given time are more useful instead, as they reduce the number of moving
parts that will have to go into local.conf.

My understanding of the plan to overhaul the neutron (bloated) layer
present in DevStack being tackled in [1] has always been that this was
about trimming the layer rather than eliminating it altogether. Is this
email a reflection of a desire to change direction? If so, SeanC please
clarify because I am slightly confused.

To the very minimum we'd need to find the right blend of config variables
which (in conjunction with some other *optional* local.conf extra juice)
produce the Neutron configuration files that we have in the gate, namely
OVS, LB and OVS+DVR, with their multi-node variants, and thus allow us to
get happy pass with Grenade/Tempest (if that means skipping some tests so
be it) across all the branches we currently gate against. The rest of the
layer can be stripped to the bare bone, but without it we're basically
gonna have to deal with long local.conf files with entire chunks of agent
files etc. thus making Neutron support for repos like devstack-gate and
project-config rather more painful (I am assuming we're gonna have to use
the new layer/approach at some point?). Bear in mind that the complexity
bubble needs to move/split, it's not just gonna burst and vanish :)

On another note, we'd have to keep in mind neutron_plugins that currently
have a place in the devstack tree and/or that rely on the existing
neutron_legacy bits. What's the plan for those (e.g. networking-[ovn, odl,
...] et al)? Finally, what's the plan for switching in the gate?

Cheers,
Armando

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


> --
> 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
>
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Jay Faulkner]

I know a lot of folks explicitly avoid a +0 vote with a comment because you 
don't get "credit" for it in statistics. Whether or not that should matter is 
another discussion, but there is a significant disincentive to no-voting right 
now.


-

Jay Faulkner



From: Dolph Mathews 
Sent: Friday, April 8, 2016 1:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats



On Friday, April 8, 2016, John Dickinson > 
wrote:


On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:

> On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>> There are many ways to game a simple +1 counter, such as +1'ing changes
>> that already have at least 1x +2, or which already approved, or which need
>> rechecking...
> [...]
>
> The behavior which baffles me, and also seems to be on the rise
> lately, is random +1 votes on changes whose commit messages and/or
> status clearly indicate they should not merged and do not need to be
> reviewed. I suppose that's another an easy way to avoid the dreaded
> "disagreements" counter?
> --
> Jeremy Stanley


I have been told that some OpenStack on boarding teaches new members of the 
community to do reviews. And they say, effectively, "muddle through as you can. 
You won't understand it all at first, but do your best. When you're done, add a 
+1 and move to the next one"

I advocate for basically this, but instead of a +1, leave a +0 and ask 
questions. The new reviewer will inevitably learn something and the author will 
benefit by explaining their change (teaching is the best way to learn).


I've been working to correct this when I've seen it, but +1 reviews with no 
comments might not be people trying to game. It might simply be people trying 
to get involved that don't know any better yet.

--John



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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Nikhil Komawar]

Hi,

Steve, thanks for pointing that out and Dims, thanks for starting the
discussion.

I guess I feel that the drastic step is/may not be necessary. Here's the
reason why: we're trying to solve a subjective problem with a objective
solution. All systems have loopholes and there will be people who will
try to take advantage of them, so we should into look into more
contextual info while forming opinions.

To say this in more "in practice terms" we are disallowing counting
stats for certain specific events, although there could be significant
number of those +1s that do matter. An extreme case of this being, a
downstream openstack consumer/cloud operator appointing someone to take
a look at the ongoing efforts upstream on the requirements and packages;
report back on some of the 'internally beware' changes. It would be a
loss for the management to track info on such individuals. To lesser
extreme, if I've to ask someone to take another look at requirements
changes and make sure that the project changes are appropriate that
potentially conflict with the updates, such individuals might be
demotivated to pick such jobs -- specifically stable and release
liaisons, sometime cross project efforts. I think we need to value such
work and give a way to (first) the individuals to keep themselves
motivated and then management to keep a check.

Hence, this is a subjective problem, it applies to some cases and
doesn't to others; the info is valuable to have but needs to be consumed
correctly. On top of that, I think a general rule of statistics is that
-- the more info/large sample set you have, more accurate are the
results. How and where you need to read them is we should solve. And I
think there are a few today who avoid such speculative results, for ex.
quarterly results at your resp. orgs, aren't you interested, do they
always tell story of the value addition/subtraction by the org as a
whole? Yet they are important, to keep us moving and keep us motivated!

Hence, my proposal is:

* instead of completely ignoring the stats on such reviews, we either
ignore or not ignore them on "generic" +1s
* introduce a new more-info-like tab/UI-stuff in Stackalytics and keep
those stats there, consequently we need to modify the Stackalytics
processor to show that info there
* encourage the teams to carefully read the review stats, say % of - vs.
+ and be more subjective on the evaluation by browsing some of the
reviews (TBH, I know that +0s are sometimes the best feedback on
reviews). I think this is a bit easier for me to say because I'm
primarily looking from Glance perspective which is a relatively small
team and we happen to stumble upon each others' reviews often.

In the interest of keeping the community inclusive, collaborative and
healthy,

yours sincerely,

On 4/8/16 1:26 PM, Davanum Srinivas wrote:
> Team,
>
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969
>
> It's pretty clear what's happening if you look here:
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/
>
> What do you think?
>
> Thanks,
> Dims
>
>
>


-- 

Thanks,
Nikhil



__
OpenStack Development Mailing 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] [magnum] Enhance Mesos bay to a DCOS bay

[Hongbin Lu]

Hi team,
I would like to give an update for this thread. In the last team, we discussed 
several options to introduce Chronos to our mesos bay:

1.   Add Chronos to the mesos bay. With this option, the mesos bay will 
have two mesos frameworks by default (Marathon and Chronos).

2.   Add a configuration hook for users to configure additional mesos 
frameworks, such as Chronos. With this option, Magnum team doesn’t need to 
maintain extra framework configuration. However, users need to do it themselves.

3.   Create a dedicated bay type for Chronos. With this option, we separate 
Marathon and Chronos into two different bay types. As a result, each bay type 
becomes easier to maintain, but those two mesos framework cannot share 
resources (a key feature of mesos is to have different frameworks running on 
the same cluster to increase resource utilization).
Which option you prefer? Or you have other suggestions? Advices are welcome.

Best regards,
Hongbin

From: Guz Egor [mailto:guz_e...@yahoo.com]
Sent: March-28-16 12:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Jay,

just keep in mind that Chronos can be run by Marathon.

---
Egor


From: Jay Lau >
To: OpenStack Development Mailing List (not for usage questions) 
>
Sent: Friday, March 25, 2016 7:01 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to 
Mesos Bay to make it can handle both long running services and batch jobs.

Thanks,

On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki 
> wrote:

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy
a DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here
https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)

Sorry if I'm missing something, but isn't DCOS a closed source software?

However, the "DCOS cli"[1] seems to be working perfectly with Marathon and 
Mesos installed by any way if you configure it well. I think that the thing 
which can be done in Magnum is to make the experience with "DOCS" tools as easy 
as possible by using open source components from Mesosphere.

Cheers,
Michal

[1] https://github.com/mesosphere/dcos-cli

__
OpenStack Development Mailing 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,
Jay Lau (Guangya Liu)

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Jim Meyer]

On Apr 8, 2016, at 1:57 PM, Major Hayden  wrote:
> 
> On 04/08/2016 03:31 PM, Jeremy Stanley wrote:
>> Thanks for taking this up--some people just need
>> encouragement/suggestions for better ways to make an impact. On the
>> other hand, if you find that many of them have addresses at the same
>> company domain... well I guess we can find people higher up the
>> ladder in those companies and talk to them about how to channel
>> their employee quotas/incentives in more productive directions for
>> the community as well.
> 
> Hey folks,
> 
> I have sent five emails so far and I received two responses already.  Both of 
> the people who replied said they are new to OpenStack and how to do reviews.  
> They welcomed more input on how to find the right code reviews and how to 
> complete the review.  They weren't aware that these particular contributions 
> were seen as unhelpful or gaming the system.

First, thanks Major for reaching out and asking questions. 

Having just caught this thread, I was a bit startled by the assumption of 
ill-intent vs. a straight-up “Hey, this seems silly. Why are they doing this? 
We should ask!” That’s a bummer attitude for us to launch out with.

I’m glad to see a few folks approach it as, “They probably don’t know” and 
offer blog posts. Might be good to get some of these incorporated into 
https://wiki.openstack.org/wiki/How_To_Contribute 
 so that n00bs (like me) get 
guidance early.

I can’t speak for others, but I can say I’ve made it abundantly clear in my org 
that Stackalytics isn’t a useful or interesting metric beyond knowing where 
we’re contributing (and not). As a leaderboard, it’s untrustworthy because 
there’s no guarantee that any contribution it tracks is making value for 
OpenStack operators or users. I suspect that we’re reflecting on attitudes 
past, but I could be wrong.

> Would it make sense to encourage cores/PTLs on these projects to reach out to 
> these users and share gerrit dashboard[1] links?  A PTL shared some of these 
> with me and it certainly helped me focus better on the right reviews.
> 
> [1] https://github.com/openstack/gerrit-dash-creator 
> 

That seems smart in general. Most of the projects have a getting started page; 
I like the Nova one[1] because it calls out reviews as a good way to start 
familiarizing yourself with the code, and points out their code review guide[2].

Always good to see you, Major. Big fan of your work. =]

—j

[1] http://docs.openstack.org/developer/nova/how_to_get_involved.html 

[2] http://docs.openstack.org/developer/nova/code-review.html#code-review 

__
OpenStack Development Mailing 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][elections] Results of the TC Election

[Eoghan Glynn]

> > Increase the commit requirements, but don't remove the summit pass
> > perk. You'll add a barrier for ATCs and see fewer of them at
> > summits.
> 
> The commit counts for the latest TC electorate show 27% had only one
> merged change in Gerrit during the qualifying one year period. It's
> worth keeping in mind that for recent summits only the current
> cycle's contributions were taken into account for free passes
> though, rather than a full year, so it's possibly more telling that
> 40% of the electorate had only 1 or 2 qualifying commits (the bare
> minimum to get free conference registration for Liberty, Mitaka or
> both).
> 
> A basic regression analysis of the owner totals for 3 through 50
> changes closely fits a power curve of 857.39*x^-1.239 and comes

Thanks Jeremy for doing the analysis, that model curve just begs
to be graphed :)  

/E

> within 3.3% of predicting how many of the electorate have only one
> change, but falls 15% short of predicting those with two. That said,
> the deviation only means an additional 94 more contributors who had
> one or two changes than the model predicts there should be, so I
> don't think there's a strong enough correlation with the limited
> data we have to say for sure that free summit passes result in a
> significant bloat in electorate size (certainly a lot less of one
> than I expected anyway).
> --
> Jeremy Stanley
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 05:53 PM, gordon chung wrote:
> 
> 
> On 08/04/2016 5:23 PM, Davanum Srinivas wrote:
>> On Fri, Apr 8, 2016 at 5:10 PM, gordon chung  wrote:
>>>
>>>
>>> is it actually affecting anything in the community aside from the
>>> reviews being useless. aside from the 'diversity' tags in governance,
>>> does anything else use stackalytics?
>>
>> Gordon,
>>
>> I feel that we are missing an opportunity to teaching what we want new
>> folks to do! As a group we should all try to spot these patterns and
>> make sure everyone's efforts are fruitful.
>>
>> To that effect, i am capturing stuff here:
>> https://davanum.wordpress.com/2016/04/08/new-to-openstack-reviews-start-here/
>>
>> Thanks,
>> Dims
>>
> 
> i imagine the fact they're gaming the stackalytics system means they're 
> aware of what their doing and no one has called them out on it yet. i'm 
> a glass half empty individual :)

Well Major reports that in at least 2 instances those contacted have
replied that they were new to OpenStack and didn't realize that their
behaviour was considered gaming. I'm not going to extrapolate to the
whole group based on that sample size but it appears there are at least
some folks who self-identify as being in the didn't know category.
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091822.html

> 
> this has been discussed in some form already in the past[1] and it'll 
> probably keep happening. i get the feeling if you tell some to stop 
> putting useless reviews in one place, they'll do it somewhere else or at 
> random frequencies -- you may be endlessly chasing white noise. if it 
> only affects lazy managers using stackalytics then it's probably not a 
> big deal for now? i can't imagine the current useless reviews are 
> swaying the overall stats of a project (aside from top global reviewers)
> 
> i like anteaya/your posts, hopefully it helps.

Thank you Gord that is kind of you to say, I appreciate your feedback. I
hope it helps as well.

Thank you,
Anita.

> 
> [1] source: i'm too lazy to search list
> 
> cheers,
> 


__
OpenStack Development Mailing 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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Matthew Thode]

On 04/08/2016 03:16 PM, Thomas Goirand wrote:
> On 04/08/2016 07:47 PM, Matthew Thode wrote:
>> On 04/08/2016 11:47 AM, Thomas Goirand wrote:
>>> Another thing is that the Debian packages are the only ones available
>>> for many services, as Canonical doesn't work on them (these packages are
>>> just sync from Debian, at best). So we'd be effectively removing the
>>> only OS where it can be installed.
>>
>> Saying that it's the only OS where some packages can be installed is not
>> nice to the other packagers /s
>>
>> -- Matthew Thode (prometheanfire)
> 
> I'm not trying to attack any other package maintainer. I get on well
> with all of them. Those I know: Corey & David from Canonical, Haikel,
> Alan and Mathias from RedHat / RDO.
> 
> I'm very sorry that I don't know the Gentoo people. Are you going to Austin?
> 
> Now, what you wrote made me investigate.
> 
> Because I discussed it with Canonical package maintainers to get these
> synced from Debian to Ubuntu, I know this list of package available in
> Debian, and either not available in Ubuntu, or synced from the Debian
> packages:
> 
>   *  congress
>   *  gnocchi
>   *  magnum
>   *  mistral
>   *  murano
>   *  sahara
>   *  senlin
>   *  zaqar
> 
> A quick search on packages.gentoo.org shows no results for them, so I
> don't think it's there (let me know if I'm wrong).
> 
> In this list above, Congress, Murano and Senlin aren't packaged in RDO.
> The others are there, seemingly (I didn't search for too long).
> 
> So yeah, some packages really are only available in Debian, at least for
> this Mitaka release.
> 
> The point here isn't to make me (or Debian) look better. It is to say
> it's important to have Debian documented in the install-guide. This came
> truth today, when a Magnum contributor asked me about contributing to
> the install-guide. He's the one who pointed to Matthew's commit removing
> my contributions to the install-guide.
> 
> I strongly believe the install-guide should follow the all-inclusive, in
> big-tentish spirit that we currently have. Rejection of contributions
> isn't welcome. And by the way, RedHat / RDO people didn't enjoy much the
> removal of their distro just before the Liberty release. This is a very
> dangerous slope. If one don't care about Debian and it's removal from
> the install-guide, probably this someone cares about the wrong spirit,
> and the "we decide what goes in" atmosphere who's been in the doc team
> for the last few years.
> 
> 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
> 
Sorry it didn't come across as a joke, but that's what the '/s' was for.
 I will be at summit in Austin at a bunch of the cross project stuff
along with openstack-ansible stuff though.

-- 
-- Matthew Thode (prometheanfire)

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[gordon chung]

On 08/04/2016 5:23 PM, Davanum Srinivas wrote:
> On Fri, Apr 8, 2016 at 5:10 PM, gordon chung  wrote:
>>
>>
>> is it actually affecting anything in the community aside from the
>> reviews being useless. aside from the 'diversity' tags in governance,
>> does anything else use stackalytics?
>
> Gordon,
>
> I feel that we are missing an opportunity to teaching what we want new
> folks to do! As a group we should all try to spot these patterns and
> make sure everyone's efforts are fruitful.
>
> To that effect, i am capturing stuff here:
> https://davanum.wordpress.com/2016/04/08/new-to-openstack-reviews-start-here/
>
> Thanks,
> Dims
>

i imagine the fact they're gaming the stackalytics system means they're 
aware of what their doing and no one has called them out on it yet. i'm 
a glass half empty individual :)

this has been discussed in some form already in the past[1] and it'll 
probably keep happening. i get the feeling if you tell some to stop 
putting useless reviews in one place, they'll do it somewhere else or at 
random frequencies -- you may be endlessly chasing white noise. if it 
only affects lazy managers using stackalytics then it's probably not a 
big deal for now? i can't imagine the current useless reviews are 
swaying the overall stats of a project (aside from top global reviewers)

i like anteaya/your posts, hopefully it helps.

[1] source: i'm too lazy to search list

cheers,

-- 
gord

__
OpenStack Development Mailing 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] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

[Hongbin Lu]

Thanks Ihar & neutron team for the quick fix.

Best regards,
Hongbin

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: April-08-16 7:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> object has no attribute 'strftime'
> 
> Kevin's patch landed. I hope it solves the issue for Magnum and other
> projects that could be affected thru LBaaS. If not, please ping me in
> #openstack-neutron channel.
> 
> Ihar
> 
> Hirofumi Ichihara  wrote:
> 
> >
> >
> > On 2016/04/08 12:10, Kevin Benton wrote:
> >> Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e
> > I tried. Let's wait for the result.
> >
> >
> >> On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu 
> wrote:
> >>
> >>
> >> > -Original Message-
> >> > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> >> > Sent: April-07-16 12:04 PM
> >> > To: OpenStack Development Mailing List (not for usage questions)
> >> > Subject: Re: [openstack-dev] [magnum][neutron] AttributeError:
> 'str'
> >> > object has no attribute 'strftime'
> >> >
> >> > Hongbin Lu  wrote:
> >> >
> >> > > Hi all,
> >> > > Magnum gate recently broke with error: "AttributeError: 'str'
> >> > > object has no attribute 'strftime'" (here is a full log [1]). I
> >> > > would like
> >> > to
> >> > > confirm if there is a recent commit in Neutron that causes the
> >> > breakage.
> >> > > If yes, a quick fix is greatly appreciated.
> >> > >
> >> > > [1]
> >> > > http://logs.openstack.org/91/301891/1/check/gate-functional-
> dsvm-
> >> > magnu
> >> > > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> >> > >
> >> >
> >> > The fix should be: https://review.openstack.org/#/c/302904/
> >>
> >> This patch doesn't resolve the problem. I depends on the patch and
> >> re-ran the tests [1], but the tests still failed with the same error
> [2].
> >>
> >> [1] https://review.openstack.org/#/c/303179/
> >> [2]
> >> http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-
> magn
> >> um-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027
> >>
> >> >
> >> > 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 Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Davanum Srinivas]

On Fri, Apr 8, 2016 at 5:10 PM, gordon chung  wrote:
>
>
> On 08/04/2016 1:26 PM, Davanum Srinivas wrote:
>> Team,
>>
>> Steve pointed out to a problem in Stackalytics:
>> https://twitter.com/stevebot/status/718185667709267969
>>
>> It's pretty clear what's happening if you look here:
>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>
>> Here's the drastic step (i'd like to avoid):
>> https://review.openstack.org/#/c/303545/
>>
>
> is it actually affecting anything in the community aside from the
> reviews being useless. aside from the 'diversity' tags in governance,
> does anything else use stackalytics?

Gordon,

I feel that we are missing an opportunity to teaching what we want new
folks to do! As a group we should all try to spot these patterns and
make sure everyone's efforts are fruitful.

To that effect, i am capturing stuff here:
https://davanum.wordpress.com/2016/04/08/new-to-openstack-reviews-start-here/

Thanks,
Dims

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



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

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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Eoghan Glynn]

> >> However, the turnout continues to slide, dipping below 20% for
> >> the first time:
> >
> >Election | Electorate (delta %) | Votes | Turnout (delta %)
> >===
> >Oct '13  | 1106 | 342   | 30.92
> >Apr '14  | 1510  (+36.52)  | 448   | 29.69   (-4.05)
> >Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
> >Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
> >Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
> >Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
> >
> >>
> >> This ongoing trend of a decreasing proportion of the electorate
> >> participating in TC elections is a concern.
> 
> One way to look at it is that every cycle (mostly due to the habit of
> giving summit passes to recent contributors) we have more and more
> one-patch contributors (more than 600 in Mitaka), and those usually are
> not really interested in voting... So the electorate number is a bit
> inflated, resulting in an apparent drop in turnout.
> 
> It would be interesting to run the same analysis but taking only >=3
> patch contributors as "expected voters" and see if the turnout still
> drops as much.
> 
> Long term I'd like to remove the summit pass perk (or no longer link it
> to "one commit"). It will likely result in a drop in contributors
> numbers (gasp), but a saner electorate.

I'd be -1 on removing this "perk" ... I prefer to think of it as
something that contributors "earn" by their efforts.

OTOH I'd be fine with moving the goalposts somewhat to require more
than a single commit. Increasing that to 3 or 5 commits would likely
still result in some contributors dividing that single patch into a
series of 3, but for others might not be worth the effort.

Another approach to consider would be to continue to offer the ATC
pass for a single commit, but to require a little more participation
in order to vote in TC/PTL elections (modulo Foundation bye-laws etc.)

Cheers,
Eoghan

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 05:10 PM, gordon chung wrote:
> 
> 
> On 08/04/2016 1:26 PM, Davanum Srinivas wrote:
>> Team,
>>
>> Steve pointed out to a problem in Stackalytics:
>> https://twitter.com/stevebot/status/718185667709267969
>>
>> It's pretty clear what's happening if you look here:
>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>
>> Here's the drastic step (i'd like to avoid):
>> https://review.openstack.org/#/c/303545/
>>
> 
> is it actually affecting anything in the community aside from the 
> reviews being useless. aside from the 'diversity' tags in governance, 
> does anything else use stackalytics?
> 
> cheers,
> 
Some company managers only look as far as stackalytics to calculate
career decisions for their group.

Sad but true.

Anita.

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[gordon chung]

On 08/04/2016 1:26 PM, Davanum Srinivas wrote:
> Team,
>
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969
>
> It's pretty clear what's happening if you look here:
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/
>

is it actually affecting anything in the community aside from the 
reviews being useless. aside from the 'diversity' tags in governance, 
does anything else use stackalytics?

cheers,

-- 
gord

__
OpenStack Development Mailing 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][elections] Results of the TC Election

[Eoghan Glynn]

> > > > Please join me in congratulating the 7 newly elected members of the TC.
> > > >
> > > > << REMOVE UNEEDED >
> > > > * Davanum Srinivas (dims)
> > > > * Flavio Percoco (flaper87)
> > > > * John Garbutt (johnthetubaguy)
> > > > * Matthew Treinish (mtreinish)
> > > > * Mike Perez (thingee)
> > > > * Morgan Fainberg (morgan)/(notmorgan)
> > > > * Thierry Carrez (ttx)
> > > >
> > > > Full results:
> > > > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> > > >
> > > > Thank you to all candidates who stood for election, having a good
> > group of
> > > > candidates helps engage the community in our democratic process.
> > > >
> > > > Thank you to all who voted and who encouraged others to vote. We need
> > to
> > > > ensure
> > > > your voice is heard.
> > > >
> > > > Thank you for another great round.
> > > >
> > > > Here's to Newton!
> > >
> > > Thanks Tony for efficiently running this election, congrats to
> > > the candidates who prevailed, and thanks to everyone who ran
> > > for putting themselves out there.
> > >
> > > It was the most open race since the pattern of TC 2.0 half-
> > > elections was established, which was great to see.
> > >
> > > However, the turnout continues to slide, dipping below 20% for
> > > the first time:
> > >
> > >  Election | Electorate (delta %) | Votes | Turnout (delta %)
> > >  ===
> > >  Oct '16  | 1106 | 342   | 30.92
> > >  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
> > >  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
> > >  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
> > >  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
> >
> > Meh, I screwed up that table, not enough coffee yet today :)
> >
> > Should be:
> >
> >   Election | Electorate (delta %) | Votes | Turnout (delta %)
> >   ===
> >   Oct '13  | 1106 | 342   | 30.92
> >   Apr '14  | 1510   (+36.52)  | 448   | 29.69   (-4.05)
> >   Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
> >   Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
> >   Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
> >   Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
> >
> 
> ​It would also be interesting to know how the "long tail" of OpenStack has
> evolved over time, as well.
> 
> https://twitter.com/tcarrez/status/710858829760598017
> 
> "​A long tail: ~2500 devs are involved in #OpenStack Mitaka, but less than
> 200 devs produce more than 50% of changes"
> 
> 652 contributors represents roughly 80% of the changes in Mitaka by
> eye-balling that graph.  That doesn't sound as bad.

Very true, though of course we've no way of knowing the intersection
between the ATCs responsible for 80% of the commits, and the voters
who turned out for the TC election. Intuition suggests the more engaged
a contributor is, the more likely she is to vote in TC elections. But
it would be great to have hard data to back that up.

I wonder if it would be possible to tag each vote with the approximate
range of commits that voter has on their record, without breaking
anonymity ... e.g. by encoding in each personalized voting URL the
bucket that voter falls into in rough terms (e.g. 1-5 commits, 10-50,
50-100 etc.)

I'd be less worried about the TC election participation rates declining
and lagging far behind the PTL elections if we'd more visibility on
what cohorts of voters are ignoring TC elections.

Cheers,
Eoghan

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Morgan Fainberg]

On Fri, Apr 8, 2016 at 4:54 PM, Dolph Mathews 
wrote:

>
>
> On Friday, April 8, 2016, John Dickinson  wrote:
>
>>
>>
>> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
>>
>> > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>> >> There are many ways to game a simple +1 counter, such as +1'ing changes
>> >> that already have at least 1x +2, or which already approved, or which
>> need
>> >> rechecking...
>> > [...]
>> >
>> > The behavior which baffles me, and also seems to be on the rise
>> > lately, is random +1 votes on changes whose commit messages and/or
>> > status clearly indicate they should not merged and do not need to be
>> > reviewed. I suppose that's another an easy way to avoid the dreaded
>> > "disagreements" counter?
>> > --
>> > Jeremy Stanley
>>
>>
>> I have been told that some OpenStack on boarding teaches new members of
>> the community to do reviews. And they say, effectively, "muddle through as
>> you can. You won't understand it all at first, but do your best. When
>> you're done, add a +1 and move to the next one"
>
>
> I advocate for basically this, but instead of a +1, leave a +0 and ask
> questions. The new reviewer will inevitably learn something and the author
> will benefit by explaining their change (teaching is the best way to learn).
>
>

This is exactly what I tell people to do as well! Definitely a good
direction to encourage folks to go.

>
>> I've been working to correct this when I've seen it, but +1 reviews with
>> no comments might not be people trying to game. It might simply be people
>> trying to get involved that don't know any better yet.
>>
>> --John
>>
>>
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Major Hayden]

On 04/08/2016 03:31 PM, Jeremy Stanley wrote:
> Thanks for taking this up--some people just need
> encouragement/suggestions for better ways to make an impact. On the
> other hand, if you find that many of them have addresses at the same
> company domain... well I guess we can find people higher up the
> ladder in those companies and talk to them about how to channel
> their employee quotas/incentives in more productive directions for
> the community as well.

Hey folks,

I have sent five emails so far and I received two responses already.  Both of 
the people who replied said they are new to OpenStack and how to do reviews.  
They welcomed more input on how to find the right code reviews and how to 
complete the review.  They weren't aware that these particular contributions 
were seen as unhelpful or gaming the system.

Would it make sense to encourage cores/PTLs on these projects to reach out to 
these users and share gerrit dashboard[1] links?  A PTL shared some of these 
with me and it certainly helped me focus better on the right reviews.

[1] https://github.com/openstack/gerrit-dash-creator

--
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] [all][stackalytics] Gaming the Stackalytics stats

[Dolph Mathews]

On Friday, April 8, 2016, John Dickinson  wrote:

>
>
> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
>
> > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
> >> There are many ways to game a simple +1 counter, such as +1'ing changes
> >> that already have at least 1x +2, or which already approved, or which
> need
> >> rechecking...
> > [...]
> >
> > The behavior which baffles me, and also seems to be on the rise
> > lately, is random +1 votes on changes whose commit messages and/or
> > status clearly indicate they should not merged and do not need to be
> > reviewed. I suppose that's another an easy way to avoid the dreaded
> > "disagreements" counter?
> > --
> > Jeremy Stanley
>
>
> I have been told that some OpenStack on boarding teaches new members of
> the community to do reviews. And they say, effectively, "muddle through as
> you can. You won't understand it all at first, but do your best. When
> you're done, add a +1 and move to the next one"


I advocate for basically this, but instead of a +1, leave a +0 and ask
questions. The new reviewer will inevitably learn something and the author
will benefit by explaining their change (teaching is the best way to learn).


>
> I've been working to correct this when I've seen it, but +1 reviews with
> no comments might not be people trying to game. It might simply be people
> trying to get involved that don't know any better yet.
>
> --John
>
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 04:39 PM, John Dickinson wrote:
> 
> 
> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
> 
>> On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>>> There are many ways to game a simple +1 counter, such as +1'ing changes
>>> that already have at least 1x +2, or which already approved, or which need
>>> rechecking...
>> [...]
>>
>> The behavior which baffles me, and also seems to be on the rise
>> lately, is random +1 votes on changes whose commit messages and/or
>> status clearly indicate they should not merged and do not need to be
>> reviewed. I suppose that's another an easy way to avoid the dreaded
>> "disagreements" counter?
>> -- 
>> Jeremy Stanley
> 
> 
> I have been told that some OpenStack on boarding teaches new members of the 
> community to do reviews. And they say, effectively, "muddle through as you 
> can. You won't understand it all at first, but do your best. When you're 
> done, add a +1 and move to the next one"

Oh my, I haven't heard that but I agree, such advice is very unhelpful
and unlikely to help reviewers learn good habits.

I offer up this post from my blog when asked for assistance in how to
review patches:
http://anteaya.info/blog/2013/03/21/reviewing-an-openstack-patch/

The folks who have bothered to read it and work through the steps I
outline do go on to provide useful reviews and gain confidence in their
reviewing.

Thanks John,
Anita.

> 
> I've been working to correct this when I've seen it, but +1 reviews with no 
> comments might not be people trying to game. It might simply be people trying 
> to get involved that don't know any better yet.
> 
> --John
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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] [all][stackalytics] Gaming the Stackalytics stats

[John Dickinson]

On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:

> On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>> There are many ways to game a simple +1 counter, such as +1'ing changes
>> that already have at least 1x +2, or which already approved, or which need
>> rechecking...
> [...]
>
> The behavior which baffles me, and also seems to be on the rise
> lately, is random +1 votes on changes whose commit messages and/or
> status clearly indicate they should not merged and do not need to be
> reviewed. I suppose that's another an easy way to avoid the dreaded
> "disagreements" counter?
> -- 
> Jeremy Stanley


I have been told that some OpenStack on boarding teaches new members of the 
community to do reviews. And they say, effectively, "muddle through as you can. 
You won't understand it all at first, but do your best. When you're done, add a 
+1 and move to the next one"

I've been working to correct this when I've seen it, but +1 reviews with no 
comments might not be people trying to game. It might simply be people trying 
to get involved that don't know any better yet.

--John





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] [all][stackalytics] Gaming the Stackalytics stats

[Davanum Srinivas]

On Fri, Apr 8, 2016 at 4:31 PM, Jeremy Stanley  wrote:
> On 2016-04-08 14:28:33 -0500 (-0500), Major Hayden wrote:
>> I'll take a sample of the folks listed there and contact them.
>> Hopefully I can provide some general results here soon.
>
> Thanks for taking this up--some people just need
> encouragement/suggestions for better ways to make an impact. On the
> other hand, if you find that many of them have addresses at the same
> company domain... well I guess we can find people higher up the
> ladder in those companies and talk to them about how to channel
> their employee quotas/incentives in more productive directions for
> the community as well.

+1 Major, Jeremy.

I am also sending this suggestion. If you can think of other good
links, please share.

==
Please watch this video:
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/tales-from-the-ship-navigating-the-openstack-community-seas

Please take a look at tips here:
https://developer.ibm.com/opentech/2015/03/27/checklist-performing-openstack-code-reviews/
https://krotscheck.net/2015/07/13/code-review-in-openstack.html
==

> 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



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

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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Jeremy Stanley]

On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
> There are many ways to game a simple +1 counter, such as +1'ing changes
> that already have at least 1x +2, or which already approved, or which need
> rechecking...
[...]

The behavior which baffles me, and also seems to be on the rise
lately, is random +1 votes on changes whose commit messages and/or
status clearly indicate they should not merged and do not need to be
reviewed. I suppose that's another an easy way to avoid the dreaded
"disagreements" counter?
-- 
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] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Bharath M]

Thanks Michael and team.

I am glad to have this opportunity. It's been fun and looking forward for
the great progress of the Octavia project.

Thanks.
Bharath.

On Fri, Apr 8, 2016 at 1:12 PM, Michael Johnson  wrote:

> Thank you cores.  That is a majority core vote in favor, so welcome to
> the core reviewer team Bharath!
>
> Michael
>
> On Fri, Apr 8, 2016 at 12:26 PM, Bertrand LALLAU
>  wrote:
> > +1
> >
> > On Fri, Apr 8, 2016 at 8:06 PM, Doug Wiegley <
> doug...@parksidesoftware.com>
> > wrote:
> >>
> >> +1
> >>
> >> > On Apr 4, 2016, at 10:53 AM, Adam Harwell  >
> >> > wrote:
> >> >
> >> > +1
> >> > 
> >> > From: Brandon Logan 
> >> > Sent: Thursday, March 31, 2016 8:04 AM
> >> > To: openstack-dev@lists.openstack.org
> >> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath
> >> > Munirajulu as Octavia Core
> >> >
> >> > +1
> >> >
> >> > On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
> >> >> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
> >> >> Octavia core reviewer.
> >> >> His contributions [1] are in line with other cores and he has been an
> >> >> active member of our community.  I have been impressed with the
> >> >> insight and quality of his reviews.
> >> >>
> >> >> Current Octavia cores, please vote by replying to this e-mail.
> >> >>
> >> >> Michael
> >> >>
> >> >>
> >> >> [1] http://stackalytics.com/report/contribution/octavia/90
> >> >>
> >> >>
> >> >>
> __
> >> >> OpenStack Development Mailing 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 Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Jeremy Stanley]

On 2016-04-08 14:28:33 -0500 (-0500), Major Hayden wrote:
> I'll take a sample of the folks listed there and contact them.
> Hopefully I can provide some general results here soon.

Thanks for taking this up--some people just need
encouragement/suggestions for better ways to make an impact. On the
other hand, if you find that many of them have addresses at the same
company domain... well I guess we can find people higher up the
ladder in those companies and talk to them about how to channel
their employee quotas/incentives in more productive directions for
the community as well.
-- 
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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Thomas Goirand]

On 04/08/2016 07:47 PM, Matthew Thode wrote:
> On 04/08/2016 11:47 AM, Thomas Goirand wrote:
>> Another thing is that the Debian packages are the only ones available
>> for many services, as Canonical doesn't work on them (these packages are
>> just sync from Debian, at best). So we'd be effectively removing the
>> only OS where it can be installed.
> 
> Saying that it's the only OS where some packages can be installed is not
> nice to the other packagers /s
> 
> -- Matthew Thode (prometheanfire)

I'm not trying to attack any other package maintainer. I get on well
with all of them. Those I know: Corey & David from Canonical, Haikel,
Alan and Mathias from RedHat / RDO.

I'm very sorry that I don't know the Gentoo people. Are you going to Austin?

Now, what you wrote made me investigate.

Because I discussed it with Canonical package maintainers to get these
synced from Debian to Ubuntu, I know this list of package available in
Debian, and either not available in Ubuntu, or synced from the Debian
packages:

  *  congress
  *  gnocchi
  *  magnum
  *  mistral
  *  murano
  *  sahara
  *  senlin
  *  zaqar

A quick search on packages.gentoo.org shows no results for them, so I
don't think it's there (let me know if I'm wrong).

In this list above, Congress, Murano and Senlin aren't packaged in RDO.
The others are there, seemingly (I didn't search for too long).

So yeah, some packages really are only available in Debian, at least for
this Mitaka release.

The point here isn't to make me (or Debian) look better. It is to say
it's important to have Debian documented in the install-guide. This came
truth today, when a Magnum contributor asked me about contributing to
the install-guide. He's the one who pointed to Matthew's commit removing
my contributions to the install-guide.

I strongly believe the install-guide should follow the all-inclusive, in
big-tentish spirit that we currently have. Rejection of contributions
isn't welcome. And by the way, RedHat / RDO people didn't enjoy much the
removal of their distro just before the Liberty release. This is a very
dangerous slope. If one don't care about Debian and it's removal from
the install-guide, probably this someone cares about the wrong spirit,
and the "we decide what goes in" atmosphere who's been in the doc team
for the last few years.

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] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Michael Johnson]

Thank you cores.  That is a majority core vote in favor, so welcome to
the core reviewer team Bharath!

Michael

On Fri, Apr 8, 2016 at 12:26 PM, Bertrand LALLAU
 wrote:
> +1
>
> On Fri, Apr 8, 2016 at 8:06 PM, Doug Wiegley 
> wrote:
>>
>> +1
>>
>> > On Apr 4, 2016, at 10:53 AM, Adam Harwell 
>> > wrote:
>> >
>> > +1
>> > 
>> > From: Brandon Logan 
>> > Sent: Thursday, March 31, 2016 8:04 AM
>> > To: openstack-dev@lists.openstack.org
>> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath
>> > Munirajulu as Octavia Core
>> >
>> > +1
>> >
>> > On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
>> >> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
>> >> Octavia core reviewer.
>> >> His contributions [1] are in line with other cores and he has been an
>> >> active member of our community.  I have been impressed with the
>> >> insight and quality of his reviews.
>> >>
>> >> Current Octavia cores, please vote by replying to this e-mail.
>> >>
>> >> Michael
>> >>
>> >>
>> >> [1] http://stackalytics.com/report/contribution/octavia/90
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing 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 Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Dariusz Smigiel]

On 08.04.2016 14:47, Assaf Muller wrote:

On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley
 wrote:

On Apr 8, 2016, at 1:28 PM, Sean M. Collins  wrote:

Assaf Muller wrote:

I do want to say that ML2's "mechanism_drivers" option probably does
not have a default for the same reason we do not have a default for
the core_plugin value, we don't want to play favorites. From Neutron's
point of view, ignoring the existence of Devstack and upstream CI, I
think that makes sense.


True, I do see your point.

I do however think, that if you do pick the ML2 plugin as your
core_plugin, it should have some mechanism drivers enabled by default. You
shouldn't have to pick core_plugin, then be forced to pick
mechanism_drivers. I'd rather see some mechanism_drivers already
enabled, and if you have a difference in opinion, set mechanism_drivers
in your local.conf.

I previously thought that a default there made no sense, but really, how is a 
default core plugin of ml2 with a default mech of local going to hurt anyone?

I was playing devil's advocate. I'm fine with picking ML2 and OVS+LB.
You will face resistance from people that have an interest in having
the ML2 reference implementation gone.

I think that idea of getting rid of devstack configuration is good thing.
Instead of learning how to setup something using internal devstack 
variables, would be good to use targeted values/settings.
But it also shows some kind of problem. We need to have good default 
configuration to setup devstack.

Right now, default All-in-one configuration is done by this [1]:

[[local|localrc]]
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
# Optional, to enable tempest configuration as part of devstack
enable_service tempest


That's all what's necessary to run Neutron in devstack. For someone who 
doesn't want to learn about Neutron and how it works, it's enough (yes, 
there are people who don't want know anything about the best project, 
like Neutron :))
When Sean's idea will materialize, it's required to be sure, that we 
have default config, that can be just copy-pasted without thinking.


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

dasm
--
Darek Smigiel

We had a big argument of whether to have a default DNS resolver… 8.8.8.8 leaks 
internal info to a third-party, hypervisor default potentially leaks 
infrastructure details.  Not having a default there at least has some 
security/privacy implications.

There are likely things that we can start defaulting in a saner way.

doug




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

__
OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Assaf Muller]

On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley
 wrote:
>
>> On Apr 8, 2016, at 1:28 PM, Sean M. Collins  wrote:
>>
>> Assaf Muller wrote:
>>> I do want to say that ML2's "mechanism_drivers" option probably does
>>> not have a default for the same reason we do not have a default for
>>> the core_plugin value, we don't want to play favorites. From Neutron's
>>> point of view, ignoring the existence of Devstack and upstream CI, I
>>> think that makes sense.
>>>
>>
>> True, I do see your point.
>>
>> I do however think, that if you do pick the ML2 plugin as your
>> core_plugin, it should have some mechanism drivers enabled by default. You
>> shouldn't have to pick core_plugin, then be forced to pick
>> mechanism_drivers. I'd rather see some mechanism_drivers already
>> enabled, and if you have a difference in opinion, set mechanism_drivers
>> in your local.conf.
>
> I previously thought that a default there made no sense, but really, how is a 
> default core plugin of ml2 with a default mech of local going to hurt anyone?

I was playing devil's advocate. I'm fine with picking ML2 and OVS+LB.
You will face resistance from people that have an interest in having
the ML2 reference implementation gone.

>
> We had a big argument of whether to have a default DNS resolver… 8.8.8.8 
> leaks internal info to a third-party, hypervisor default potentially leaks 
> infrastructure details.  Not having a default there at least has some 
> security/privacy implications.
>
> There are likely things that we can start defaulting in a saner way.
>
> doug
>
>
>
>>
>> --
>> 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

__
OpenStack Development Mailing 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][neutron] Eliminating the DevStack layer

[Doug Wiegley]

> On Apr 8, 2016, at 1:28 PM, Sean M. Collins  wrote:
> 
> Assaf Muller wrote:
>> I do want to say that ML2's "mechanism_drivers" option probably does
>> not have a default for the same reason we do not have a default for
>> the core_plugin value, we don't want to play favorites. From Neutron's
>> point of view, ignoring the existence of Devstack and upstream CI, I
>> think that makes sense.
>> 
> 
> True, I do see your point.
> 
> I do however think, that if you do pick the ML2 plugin as your
> core_plugin, it should have some mechanism drivers enabled by default. You
> shouldn't have to pick core_plugin, then be forced to pick
> mechanism_drivers. I'd rather see some mechanism_drivers already
> enabled, and if you have a difference in opinion, set mechanism_drivers
> in your local.conf.

I previously thought that a default there made no sense, but really, how is a 
default core plugin of ml2 with a default mech of local going to hurt anyone?

We had a big argument of whether to have a default DNS resolver… 8.8.8.8 leaks 
internal info to a third-party, hypervisor default potentially leaks 
infrastructure details.  Not having a default there at least has some 
security/privacy implications.

There are likely things that we can start defaulting in a saner way.

doug



> 
> -- 
> 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] [all][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 03:28 PM, Major Hayden wrote:
> On 04/08/2016 02:25 PM, Anita Kuno wrote:
>> Nothing is stopping you from doing so. You can see the names and can
>> find the emails of those engaged in this by following the gerrit link
>> Dims posted in his first post.
>>
>> Perhaps as you say, the personal touch may help them to learn how to
>> contribute in a way that has value.
> 
> I'll take a sample of the folks listed there and contact them.  Hopefully I 
> can provide some general results here soon.
> 
> --
> 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
> 
Wonderful, thank you Major, I hope your efforts prove fruitful.

Thank you,
Anita.

__
OpenStack Development Mailing 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][neutron] Eliminating the DevStack layer

[Sean M. Collins]

Assaf Muller wrote:
> I do want to say that ML2's "mechanism_drivers" option probably does
> not have a default for the same reason we do not have a default for
> the core_plugin value, we don't want to play favorites. From Neutron's
> point of view, ignoring the existence of Devstack and upstream CI, I
> think that makes sense.
> 

True, I do see your point.

I do however think, that if you do pick the ML2 plugin as your
core_plugin, it should have some mechanism drivers enabled by default. You
shouldn't have to pick core_plugin, then be forced to pick
mechanism_drivers. I'd rather see some mechanism_drivers already
enabled, and if you have a difference in opinion, set mechanism_drivers
in your local.conf.

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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Major Hayden]

On 04/08/2016 02:25 PM, Anita Kuno wrote:
> Nothing is stopping you from doing so. You can see the names and can
> find the emails of those engaged in this by following the gerrit link
> Dims posted in his first post.
> 
> Perhaps as you say, the personal touch may help them to learn how to
> contribute in a way that has value.

I'll take a sample of the folks listed there and contact them.  Hopefully I can 
provide some general results here soon.

--
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] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Bertrand LALLAU]

+1

On Fri, Apr 8, 2016 at 8:06 PM, Doug Wiegley 
wrote:

> +1
>
> > On Apr 4, 2016, at 10:53 AM, Adam Harwell 
> wrote:
> >
> > +1
> > 
> > From: Brandon Logan 
> > Sent: Thursday, March 31, 2016 8:04 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath
> Munirajulu as Octavia Core
> >
> > +1
> >
> > On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
> >> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
> >> Octavia core reviewer.
> >> His contributions [1] are in line with other cores and he has been an
> >> active member of our community.  I have been impressed with the
> >> insight and quality of his reviews.
> >>
> >> Current Octavia cores, please vote by replying to this e-mail.
> >>
> >> Michael
> >>
> >>
> >> [1] http://stackalytics.com/report/contribution/octavia/90
> >>
> >>
> __
> >> OpenStack Development Mailing 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 Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 03:19 PM, Major Hayden wrote:
> On 04/08/2016 02:04 PM, Doug Wiegley wrote:
>> Are they using the numbers for some internal company purpose maybe?  If so, 
>> how does it matter to any of us?
>>
>> Chasing this tail just takes time away from useful things, IMO.
> 
> Although I understand the reasoning behind the effort underway in the review 
> above to skip Stackalytics stats for proposal bot reviews, it doesn't really 
> add a ton of value.  As Doug noted, one cannot simply become a core reviewer 
> by gaming stackalytics.
> 
> Those personal interactions on mailing lists, reviews with lots of patchsets, 
> IRC meetings, and in-person events (like mid-cycles/summits) make the big 
> difference.  Can we reach out to some of these people making questionable 
> +1's and find out if we can help them become a more productive community 
> member?  If there are companies out there who are setting "quotas" for review 
> counts, we could possibly reach out to them as well.  Perhaps I'm being too 
> optimistic. :)

Nothing is stopping you from doing so. You can see the names and can
find the emails of those engaged in this by following the gerrit link
Dims posted in his first post.

Perhaps as you say, the personal touch may help them to learn how to
contribute in a way that has value.

Thanks,
Anita.

> 
> But, as Dolph said earlier, leaving this issue alone certainly makes it 
> easier to single out the folks who are doing something unproductive. ;)
> 
> --
> 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
> 


__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Major Hayden]

On 04/08/2016 02:04 PM, Doug Wiegley wrote:
> Are they using the numbers for some internal company purpose maybe?  If so, 
> how does it matter to any of us?
> 
> Chasing this tail just takes time away from useful things, IMO.

Although I understand the reasoning behind the effort underway in the review 
above to skip Stackalytics stats for proposal bot reviews, it doesn't really 
add a ton of value.  As Doug noted, one cannot simply become a core reviewer by 
gaming stackalytics.

Those personal interactions on mailing lists, reviews with lots of patchsets, 
IRC meetings, and in-person events (like mid-cycles/summits) make the big 
difference.  Can we reach out to some of these people making questionable +1's 
and find out if we can help them become a more productive community member?  If 
there are companies out there who are setting "quotas" for review counts, we 
could possibly reach out to them as well.  Perhaps I'm being too optimistic. :)

But, as Dolph said earlier, leaving this issue alone certainly makes it easier 
to single out the folks who are doing something unproductive. ;)

--
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] [all][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 03:04 PM, Doug Wiegley wrote:
> 
>> On Apr 8, 2016, at 11:26 AM, Davanum Srinivas  wrote:
>>
>> Team,
>>
>> Steve pointed out to a problem in Stackalytics:
>> https://twitter.com/stevebot/status/718185667709267969
>>
>> It's pretty clear what's happening if you look here:
>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>
>> Here's the drastic step (i'd like to avoid):
>> https://review.openstack.org/#/c/303545/
>>
>> What do you think?
> 
> Is it really worth trying to stop the folks that will game the system?  That 
> is a never-ending arms race.
> 
> Has anyone ever been made core or had some influence purely by pumping 
> stacklytics? I haven’t seen it, since that usually requires personal 
> relationships that are far more important than numbers.
> 
> Are they using the numbers for some internal company purpose maybe?  If so, 
> how does it matter to any of us?
> 
> Chasing this tail just takes time away from useful things, IMO.
> 
> doug

The shame of it is that at least one of the folks wasting their time
with this has the ability to become a beneficial contributor including
useful reviews. I do hope that drawing attention to their activity will
motivate them to re-evaluate and perhaps engage in behaviour that is
both needed and valued.

I do agree with you though Doug, to most people this already is obvious.

Thanks,
Anita.

> 
> 
>>
>> Thanks,
>> Dims
>>
>> -- 
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Doug Wiegley]

> On Apr 8, 2016, at 11:26 AM, Davanum Srinivas  wrote:
> 
> Team,
> 
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969
> 
> It's pretty clear what's happening if you look here:
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
> 
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/
> 
> What do you think?

Is it really worth trying to stop the folks that will game the system?  That is 
a never-ending arms race.

Has anyone ever been made core or had some influence purely by pumping 
stacklytics? I haven’t seen it, since that usually requires personal 
relationships that are far more important than numbers.

Are they using the numbers for some internal company purpose maybe?  If so, how 
does it matter to any of us?

Chasing this tail just takes time away from useful things, IMO.

doug


> 
> Thanks,
> Dims
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Tim Bell]

On 08/04/16 20:08, "gordon chung"  wrote:

>
>
>On 08/04/2016 9:14 AM, Thierry Carrez wrote:
>> Eoghan Glynn wrote:
 However, the turnout continues to slide, dipping below 20% for
 the first time:
>>>
>>>Election | Electorate (delta %) | Votes | Turnout (delta %)
>>>===
>>>Oct '13  | 1106 | 342   | 30.92
>>>Apr '14  | 1510(+36.52)  | 448   | 29.69   (-4.05)
>>>Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>>>Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>>Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>>Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>>>

 This ongoing trend of a decreasing proportion of the electorate
 participating in TC elections is a concern.
>>
>> One way to look at it is that every cycle (mostly due to the habit of
>> giving summit passes to recent contributors) we have more and more
>> one-patch contributors (more than 600 in Mitaka), and those usually are
>> not really interested in voting... So the electorate number is a bit
>> inflated, resulting in an apparent drop in turnout.
>>
>> It would be interesting to run the same analysis but taking only >=3
>> patch contributors as "expected voters" and see if the turnout still
>> drops as much.
>>
>> Long term I'd like to remove the summit pass perk (or no longer link it
>> to "one commit"). It will likely result in a drop in contributors
>> numbers (gasp), but a saner electorate.
>>
>
>just for reference, while only affecting a subset of the electorate, if 
>you look at the PTL elections, they all had over 40% turnout (even the 
>older and larger projects).
>
>it may be because of those with "one commit", but if that were the case, 
>you would think the turnout would be inline/similar to the PTL elections.

It could also be that the projects with the lower hanging fruit were 
uncontested.

BTW, I don’t feel that a 1 commit person should be ignored in the voting. Many 
of us
have roles which do not mean we spend all the time committing but when we see 
something
wrong in the docs, spend a few hours to go through the process. I certainly 
favor
those PTLs/TC members in my voting who still count the sum of this contribution 
to be significant.

As we progress further with the UC-Recognition activity, there will be further 
discussion
on this so I feel waiting for that work to make a proposal on how those people 
could also
contribute to setting the technical direction.

Tim

>
>cheers,
>-- 
>gord
>
>__
>OpenStack Development Mailing 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] [app-catalog] Newton summit schedule

[Christopher Aedo]

Hello!  I'm tagging "all" in hopes of getting more attention and some
good attendance and conversations going in Austin.  The sessions are
on the schedule[1] so please join us!

In addition to the time we hope to spend with the Horizon team, we'll
also talk about what I think is one of the biggest things holding back
growth of the catalog - the question of how to develop an app meant
for OpenStack (and how best to package and distribute them).  This
impacts the larger OpenStack ecosystem as well, and I'm hoping to
solicit more opinions and views either in person or via the mailing
list[2].

Looking forward to some great conversations in Austin!

[1] 
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=App%20Catalog
[2] http://lists.openstack.org/pipermail/user-committee/2016-April/000722.html

-Christopher

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Morgan Fainberg]

On Fri, Apr 8, 2016 at 1:42 PM, Dmitry Tantsur 
wrote:

>
> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas :
>
>> Team,
>>
>> Steve pointed out to a problem in Stackalytics:
>> https://twitter.com/stevebot/status/718185667709267969
>
>
> There are many ways to game a simple +1 counter, such as +1'ing changes
> that already have at least 1x +2, or which already approved, or which need
> rechecking...
>
>
>>
>>
>> It's pretty clear what's happening if you look here:
>>
>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>
>> Here's the drastic step (i'd like to avoid):
>> https://review.openstack.org/#/c/303545/
>>
>> What do you think?
>>
>
> One more possible (though also imperfect) mitigation is to make exception
> from the usual 2x +2 rule for requirements updates passing gates and use
> only 1x +2. Then requirements reviews will take substantially less time to
> land, reducing need/possibility of having such +1's.
>
>

Many projects (including Keystone) already go with a single core +2/+A for
Proposal Bot changes. This definitely helps them land faster (which is why
the policy is there).
__
OpenStack Development Mailing 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][elections] Results of the TC Election

[gordon chung]

On 08/04/2016 9:14 AM, Thierry Carrez wrote:
> Eoghan Glynn wrote:
>>> However, the turnout continues to slide, dipping below 20% for
>>> the first time:
>>
>>Election | Electorate (delta %) | Votes | Turnout (delta %)
>>===
>>Oct '13  | 1106 | 342   | 30.92
>>Apr '14  | 1510(+36.52)  | 448   | 29.69   (-4.05)
>>Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>>Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>>
>>>
>>> This ongoing trend of a decreasing proportion of the electorate
>>> participating in TC elections is a concern.
>
> One way to look at it is that every cycle (mostly due to the habit of
> giving summit passes to recent contributors) we have more and more
> one-patch contributors (more than 600 in Mitaka), and those usually are
> not really interested in voting... So the electorate number is a bit
> inflated, resulting in an apparent drop in turnout.
>
> It would be interesting to run the same analysis but taking only >=3
> patch contributors as "expected voters" and see if the turnout still
> drops as much.
>
> Long term I'd like to remove the summit pass perk (or no longer link it
> to "one commit"). It will likely result in a drop in contributors
> numbers (gasp), but a saner electorate.
>

just for reference, while only affecting a subset of the electorate, if 
you look at the PTL elections, they all had over 40% turnout (even the 
older and larger projects).

it may be because of those with "one commit", but if that were the case, 
you would think the turnout would be inline/similar to the PTL elections.

cheers,
-- 
gord

__
OpenStack Development Mailing 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][neutron] Eliminating the DevStack layer

[Sean Dague]

On 04/08/2016 12:05 PM, Morales, Victor wrote:
> Agree, sometimes is hard to figure out what is the Devstack variable that 
> will modify the configuration value.
> 
> There is an effort to categorize the configuration options[1] of some of the 
> projects.  I’m wondering if it could be possible to create category or field 
> that specifies the Destack variable that changes this configuration value.
> 
> [1] 
> https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst

I really don't think that Devstack should leak that far back into real
projects.

Devstack variables make a ton of sense when you are communicating a
higher level construct, and it needs to do some logic on it and possibly
set multiple things.

Devstack variables that are basically pass through for individual config
vars aren't really a good idea. We try to -1 them all now. But a lot of
leaked in.

I think Sean Collins' plan is a good one.

-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] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Doug Wiegley]

+1

> On Apr 4, 2016, at 10:53 AM, Adam Harwell  wrote:
> 
> +1
> 
> From: Brandon Logan 
> Sent: Thursday, March 31, 2016 8:04 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu 
> as Octavia Core
> 
> +1
> 
> On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
>> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
>> Octavia core reviewer.
>> His contributions [1] are in line with other cores and he has been an
>> active member of our community.  I have been impressed with the
>> insight and quality of his reviews.
>> 
>> Current Octavia cores, please vote by replying to this e-mail.
>> 
>> Michael
>> 
>> 
>> [1] http://stackalytics.com/report/contribution/octavia/90
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Jeremy Stanley]

On 2016-04-08 14:04:15 + (+), gordon chung wrote:
[...]
> understandably it's more difficult to manage a large group of
> cores, but it does seem strange that all the projects have roughly
> the same core team size even though some projects have a
> contributor base that is significantly larger than others.

That may be a sign that something like Dunbar's number is at work
limiting group sizes. Crunching Gerrit approver group membership
counts across 566 official Git repos (those belonging to a TC
recognized project team), 90% have 17 or fewer accounts capable of
approving changes. Below that there's a pretty varied spread (with
23% of repos having only 1 approver). This is a pretty raw analysis
though, so something taking into account how many of those reviewers
regularly exercised their approval access may yield different
insights entirely.
-- 
Jeremy Stanley
0 openstack-infra/puppet-dashboard
0 openstack/freezer-specs
0 openstack/python-tuskarclient
0 openstack/tuskar
1 openstack-infra/infra-specs
1 openstack/python-neutron-pd-driver
2 openstack/cue
2 openstack/cue-dashboard
2 openstack/faafo
2 openstack/horizon-cisco-ui
2 openstack/python-cueclient
2 openstack/training-labs
2 openstack/zaqar-specs
3 openstack/ceilometer-powervm
3 openstack/cloudkitty
3 openstack/cloudkitty-dashboard
3 openstack/ec2-api
3 openstack/fuel-stats
3 openstack/ironic-ui
3 openstack/performance-docs
3 openstack/python-cloudkittyclient
3 openstack/python-wsmanclient
3 openstack/stackviz
4 openstack-dev/grenade
4 openstack/anchor
4 openstack/app-catalog
4 openstack/app-catalog-common
4 openstack/app-catalog-ui
4 openstack/deb-openstack-pkg-tools
4 openstack/designate-specs
4 openstack/eslint-config-openstack
4 openstack/fuel-dev-tools
4 openstack/fuel-devops
4 openstack/fuel-plugin-murano
4 openstack/fuel-plugins
4 openstack/fuel-upgrade
4 openstack/i18n
4 openstack/os-win
4 openstack/ossa
4 openstack/python-dracclient
4 openstack/python-tackerclient
4 openstack/refstack
4 openstack/refstack-client
4 openstack/tacker
4 openstack/tacker-horizon
4 openstack/tacker-specs
5 openstack/cookbook-openstack-bare-metal
5 openstack/cookbook-openstack-block-storage
5 openstack/cookbook-openstack-client
5 openstack/cookbook-openstack-common
5 openstack/cookbook-openstack-compute
5 openstack/cookbook-openstack-dashboard
5 openstack/cookbook-openstack-data-processing
5 openstack/cookbook-openstack-database
5 openstack/cookbook-openstack-identity
5 openstack/cookbook-openstack-image
5 openstack/cookbook-openstack-integration-test
5 openstack/cookbook-openstack-network
5 openstack/cookbook-openstack-object-storage
5 openstack/cookbook-openstack-ops-database
5 openstack/cookbook-openstack-ops-messaging
5 openstack/cookbook-openstack-orchestration
5 openstack/cookbook-openstack-telemetry
5 openstack/neutron-lib
5 openstack/openstack-chef-repo
5 openstack/openstack-chef-specs
5 openstack/os-testr
5 openstack/python-senlinclient
5 openstack/senlin
5 openstack/syntribos
6 openstack/astara
6 openstack/astara-appliance
6 openstack/astara-horizon
6 openstack/astara-neutron
6 openstack/bandit
6 openstack/gnocchi
6 openstack/mistral-specs
6 openstack/neutron-specs
6 openstack/nova-specs
6 openstack/openstack-health
6 openstack/pymod2pkg
6 openstack/python-gnocchiclient
6 openstack/releases
6 openstack/renderspec
6 openstack/reno
6 openstack/rpm-packaging
6 openstack/rpm-packaging-tools
6 openstack/trove-integration
6 openstack/trove-specs
7 openstack/congress
7 openstack/congress-specs
7 openstack/fuel-docs
7 openstack/fuel-qa
7 openstack/fuel-ui
7 openstack/ironic-specs
7 openstack/mistral
7 openstack/mistral-dashboard
7 openstack/mistral-extra
7 openstack/os-vif
7 openstack/python-congressclient
7 openstack/python-mistralclient
7 openstack/senlin-dashboard
8 openstack-dev/devstack
8 openstack-dev/devstack-plugin-cookiecutter
8 openstack-dev/devstack-vagrant
8 openstack/fuel-agent
8 openstack/fuel-astute
8 openstack/fuel-nailgun-agent
8 openstack/fuel-virtualbox
8 openstack/fuel-web
8 openstack/manila-image-elements
8 openstack/murano-specs
8 openstack/python-manilaclient
8 openstack/shotgun
9 openstack-dev/bashate
9 openstack/fairy-slipper
9 openstack/freezer
9 openstack/freezer-api
9 openstack/freezer-web-ui
9 openstack/murano
9 openstack/murano-agent
9 openstack/murano-apps
9 openstack/murano-dashboard
9 openstack/murano-deployment
9 openstack/openstack-ansible
9 openstack/openstack-ansible-apt_package_pinning
9 openstack/openstack-ansible-galera_client
9 openstack/openstack-ansible-galera_server
9 openstack/openstack-ansible-ironic
9 openstack/openstack-ansible-lxc_container_create
9 openstack/openstack-ansible-lxc_hosts
9 openstack/openstack-ansible-memcached_server
9 openstack/openstack-ansible-openstack_hosts
9 openstack/openstack-ansible-openstack_openrc
9 openstack/openstack-ansible-os_aodh
9 openstack/openstack-ansible-os_ceilometer
9 openstack/openstack-ansible-os_cinder
9 openstack/openstack-ansible-os_glance
9 

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalyticsstats

[Steve Martinelli]

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead



From:   Dmitry Tantsur 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2016/04/08 01:43 PM
Subject:Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
stats




2016-04-08 19:26 GMT+02:00 Davanum Srinivas :
  Team,

  Steve pointed out to a problem in Stackalytics:
  https://twitter.com/stevebot/status/718185667709267969

There are many ways to game a simple +1 counter, such as +1'ing changes
that already have at least 1x +2, or which already approved, or which need
rechecking...


But these are harder to create automated scripts for (maybe)


  It's pretty clear what's happening if you look here:
  https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org
+status:open


  Here's the drastic step (i'd like to avoid):
  https://review.openstack.org/#/c/303545/

  What do you think?

One more possible (though also imperfect) mitigation is to make exception
from the usual 2x +2 rule for requirements updates passing gates and use
only 1x +2. Then requirements reviews will take substantially less time to
land, reducing need/possibility of having such +1's.

At least in keystone projects, we don't have that requirement, first core
to see the change (and it's passing jenkins) gets to push it through.


  Thanks,
  Dims

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

  __

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



--
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Anita Kuno]

On 04/08/2016 01:42 PM, Dmitry Tantsur wrote:
> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas :
> 
>> Team,
>>
>> Steve pointed out to a problem in Stackalytics:
>> https://twitter.com/stevebot/status/718185667709267969
> 
> 
> There are many ways to game a simple +1 counter, such as +1'ing changes
> that already have at least 1x +2, or which already approved, or which need
> rechecking...
> 
> 
>>
>>
>> It's pretty clear what's happening if you look here:
>>
>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>
>> Here's the drastic step (i'd like to avoid):
>> https://review.openstack.org/#/c/303545/
>>
>> What do you think?
>>
> 
> One more possible (though also imperfect) mitigation is to make exception
> from the usual 2x +2 rule for requirements updates passing gates and use
> only 1x +2. Then requirements reviews will take substantially less time to
> land, reducing need/possibility of having such +1's.

Proposal bot patches merge in many cases with 1 +2 already.

Have you looked at the timing of the bot patches generated and the first
+1's? If not, take a look at that.

I don't think we should be expecting core reviewers to schedule
approving bot proposals to prevent extraneous +1s.

Thanks,
Anita.

> 
>>
>> Thanks,
>> Dims
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing 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] [qa][api] exploring gabbi+tempest

[Chris Dent]

Mehdi did some interesting work to explore integrating tempest
and gabbi in a tempest plugin for gnocchi[1]. Inspired by that I've
started exploring more generic ways of doing gabbi+tempest.

That work is at[2]. I'm posting about it for a couple reasons:

* I'm not super savvy about tempest so I could be missing out on
  ways to do things correctly; input most appreciated.

* As soon as I started writing tests in the gabbi style against both
  Nova and Glance I found (and reported[3]) multiple HTTP-related bugs (for
  example, the glance discovery resource returns links which 404).

  This suggests that having tooling which makes it pretty easy
  to dynamically write and run tests against OpenStack without
  assumption-having clients is a good idea.

For those that don't know, gabbi[4] is a testing harness for writing
HTTP requests and expected responses in a YAML format with
(optional) JSONPath evaluation of responses.

It is particularly useful in the OpenStack context because you can use
it to write tests from the standpoint of an uninformed client: write
requests that might make sense and see what happens, discover bugs
and behavior that violates the principle of least surprise, easily.

Most OpenStack API tests don't have this standpoint so frequently
don't explore edge cases that any curious real client might very
well do.

Anyway, I hope this is useful to people in some fashion. Ideally
over the long run it would be useful to turn this into a library
that other tempest plugins can use (instead of being a plugin
itself). If that sounds interesting or you have ideas, let me know.

Thanks.

[1] https://review.openstack.org/#/c/301585/
[2] https://github.com/cdent/gabbi-tempest
[3] https://bugs.launchpad.net/nova/+bugs?field.tag=gabbi
[4] https://gabbi.readthedocs.org/


--
Chris Dent   (�s°□°)�s�喋擤ォ�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

Re: [openstack-dev] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Matthew Thode]

On 04/08/2016 11:47 AM, Thomas Goirand wrote:
> Another thing is that the Debian packages are the only ones available
> for many services, as Canonical doesn't work on them (these packages are
> just sync from Debian, at best). So we'd be effectively removing the
> only OS where it can be installed.

Saying that it's the only OS where some packages can be installed is not
nice to the other packagers /s

-- Matthew Thode (prometheanfire)

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Dmitry Tantsur]

2016-04-08 19:26 GMT+02:00 Davanum Srinivas :

> Team,
>
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969


There are many ways to game a simple +1 counter, such as +1'ing changes
that already have at least 1x +2, or which already approved, or which need
rechecking...


>
>
> It's pretty clear what's happening if you look here:
>
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/
>
> What do you think?
>

One more possible (though also imperfect) mitigation is to make exception
from the usual 2x +2 rule for requirements updates passing gates and use
only 1x +2. Then requirements reviews will take substantially less time to
land, reducing need/possibility of having such +1's.


>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Dean Troyer]

On Fri, Apr 8, 2016 at 12:26 PM, Davanum Srinivas  wrote:

> Team,
>
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969
>
> It's pretty clear what's happening if you look here:
>
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/


Allow me to go and +1 that even if it hurts my stats when the -2 comes. :)

I fear that the only way to make Stackalytics meaningless to
management-types is for it to go away, only to be replaced by some other
(possibly worse) metric to be misused.

We all need to educate our internal company leadership on the (lack of)
actual truth in those numbers...

dt

-- 

Dean Troyer
dtro...@gmail.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] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

[Dolph Mathews]

We're _all_ winners.

On Friday, April 8, 2016, Brad Topol  wrote:

> If Termie comes out of retirement to respond to a thread are there really
> any winners??? :-)
>
> --Brad
>
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> 
> Assistant: Kendra Witherspoon (919) 254-0680
>
> [image: Inactive hide details for Monty Taylor ---04/08/2016 01:10:23
> PM---On 04/08/2016 11:12 AM, Andy Smith wrote: > Aahahahahhah]Monty
> Taylor ---04/08/2016 01:10:23 PM---On 04/08/2016 11:12 AM, Andy Smith
> wrote: > Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhah
>
> From: Monty Taylor  >
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org
> >
> Date: 04/08/2016 01:10 PM
> Subject: Re: [openstack-dev] [tc][ptl][keystone] Proposal to split
> authentication part out of Keystone to separated project
> --
>
>
>
> On 04/08/2016 11:12 AM, Andy Smith wrote:
> > Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha
>
> This is the indication that this thread wins.
>
> > On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad  
> >  >> wrote:
> >
> > In response to point 2.2, the progress with Fernet in the last year
> > has exposed performance pain points in keystone. Finding sensible
> > solutions for those issues is crucial in order for people to adopt
> > Fernet. In Mitaka we had a lot of discussion that resulted in
> > landing several performance related patches.
> >
> > As of today, we're already focusing on scalability, performance, and
> > simplicity. I'm afraid a project split would only delay the work
> > we're doing right now.
> >
> > On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg
> >   <
> mailto:morgan.fainb...@gmail.com
> >> wrote:
> >
> >
> >
> > On Wed, Apr 6, 2016 at 6:29 PM, David Stanek
> >   <
> mailto:dsta...@dstanek.com
> >> wrote:
> >
> >
> > On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic
> >   <
> mailto:bpavlo...@mirantis.com
> >> wrote:
> >
> >
> > 2) This will reduce scope of Keystone, which means 2
> things
> > 2.1) Smaller code base that has less issues and is
> > simpler for testing
> > 2.2) Keystone team would be able to concentrate more on
> > fixing perf/scalability issues of authorization, which
> > is crucial at the moment for large clouds.
> >
> >
> > I'm not sure that this is entirely true. If we truly just
> > split up the project, meaning we don't remove functionality,
> > then we'd have the same number of bugs and work. It would
> > just be split across two projects.
> >
> > I think the current momentum to get out of the authn
> > business is still our best bet. As Steve mentioned this is
> > ongoing work.
> >
> > -- David
> >
> >
> > What everyone else said... but add in the need then to either
> > pass the AuthN over to the Assignment/AuthZ api or bake it in
> > (via apache module?) and we are basically where we are now.
> >
> > Steve alluded to splitting out the authentication bit (but not
> > to a new service), the idea there is to make it so AuthN is not
> > part of the CRUD interface of the server. All being said, AuthN
> > and AuthZ are going to be hard to split into two separate
> > services and with exception of the unfounded "scope" benefit, we
> > already can handle most of what you've proposed with zero
> > changes to Keystone.
> >
> > Cheers,
> > --Morgan
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> 

[openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Davanum Srinivas]

Team,

Steve pointed out to a problem in Stackalytics:
https://twitter.com/stevebot/status/718185667709267969

It's pretty clear what's happening if you look here:
https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open

Here's the drastic step (i'd like to avoid):
https://review.openstack.org/#/c/303545/

What do you think?

Thanks,
Dims

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

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

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

[Brad Topol]

If Termie comes out of retirement to respond to a thread are there really
any winners??? :-)

--Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/08/2016 01:10 PM
Subject:Re: [openstack-dev] [tc][ptl][keystone] Proposal to split
authentication part out of Keystone to separated project



On 04/08/2016 11:12 AM, Andy Smith wrote:
> Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha

This is the indication that this thread wins.

> On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad  > wrote:
>
> In response to point 2.2, the progress with Fernet in the last year
> has exposed performance pain points in keystone. Finding sensible
> solutions for those issues is crucial in order for people to adopt
> Fernet. In Mitaka we had a lot of discussion that resulted in
> landing several performance related patches.
>
> As of today, we're already focusing on scalability, performance, and
> simplicity. I'm afraid a project split would only delay the work
> we're doing right now.
>
> On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg
> > wrote:
>
>
>
> On Wed, Apr 6, 2016 at 6:29 PM, David Stanek
> > wrote:
>
>
> On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic
> >
wrote:
>
>
> 2) This will reduce scope of Keystone, which means 2
things
> 2.1) Smaller code base that has less issues and is
> simpler for testing
> 2.2) Keystone team would be able to concentrate more on
> fixing perf/scalability issues of authorization, which
> is crucial at the moment for large clouds.
>
>
> I'm not sure that this is entirely true. If we truly just
> split up the project, meaning we don't remove functionality,
> then we'd have the same number of bugs and work. It would
> just be split across two projects.
>
> I think the current momentum to get out of the authn
> business is still our best bet. As Steve mentioned this is
> ongoing work.
>
> -- David
>
>
> What everyone else said... but add in the need then to either
> pass the AuthN over to the Assignment/AuthZ api or bake it in
> (via apache module?) and we are basically where we are now.
>
> Steve alluded to splitting out the authentication bit (but not
> to a new service), the idea there is to make it so AuthN is not
> part of the CRUD interface of the server. All being said, AuthN
> and AuthZ are going to be hard to split into two separate
> services and with exception of the unfounded "scope" benefit, we
> already can handle most of what you've proposed with zero
> changes to Keystone.
>
> Cheers,
> --Morgan
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <
http://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 Development Mailing 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][neutron] Eliminating the DevStack layer

[Assaf Muller]

On Fri, Apr 8, 2016 at 11:57 AM, Sean M. Collins  wrote:
> Edgar Magana wrote:
>> This is a very solid plan. Maybe to fair on the current state of the 
>> devstack with neutron functionality, what will be the disadvantage(s) of 
>> this change from your perspective?
>>
>
> A user's local.conf will probably get a little bigger - and I think a
> lot of the issues about Neutron's inability to run out of the box will
> be exposed.
>
> I mean let's face it - Neutron, installed from source, with no
> configuration Does Not Work™. There are not enough settings that have
> defaults set, for it to actually run.
>
> This was made painfully obvious to me when I had to make new revisions
> to the Neutron DevStack refactor, where I had to add more inisets, in
> order for Neutron to finish stacking correctly.
>
> Did you know, for example, that we rely on DevStack[1] to set the list
> of mechanism_drivers? Without this, you'll get an empty mechanism_driver
> list and nothing will ever be wired up.

I don't want to detract from what you're saying Sean, and I largely
agree that we can be more opinionated in Neutron and rely less on
Devstack. I also never liked Devstack's "macros" and have always
preferred configuring everything myself via local.conf when that was
made an option, simply because I already know how to configure Neutron
and I didn't want to learn Devstack's options. I do want to say that
ML2's "mechanism_drivers" option probably does not have a default for
the same reason we do not have a default for the core_plugin value, we
don't want to play favorites. From Neutron's point of view, ignoring
the existence of Devstack and upstream CI, I think that makes sense.

>
> I'm sure there is an argument that can be made about why there is no
> default for mechanism_drivers in ML2, since there are lots of options.
> But, I think that we can at least enable the ones that we have in
> Neutron's main tree. Packagers who make packages for each mechanism
> driver (LB, OVS, etc..) already had to handle things like
> mechanism_drivers in the Ml2 configuration already, so it shouldn't
> really impact them since we're only setting a default if nothing is set,
> and their packages should explicitly set it.
>
> [1]: 
> https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/ml2#L27
>
>
> --
> 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] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

[Monty Taylor]

On 04/08/2016 11:12 AM, Andy Smith wrote:

Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha


This is the indication that this thread wins.


On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad > wrote:

In response to point 2.2, the progress with Fernet in the last year
has exposed performance pain points in keystone. Finding sensible
solutions for those issues is crucial in order for people to adopt
Fernet. In Mitaka we had a lot of discussion that resulted in
landing several performance related patches.

As of today, we're already focusing on scalability, performance, and
simplicity. I'm afraid a project split would only delay the work
we're doing right now.

On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg
> wrote:



On Wed, Apr 6, 2016 at 6:29 PM, David Stanek
> wrote:


On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic
> wrote:


2) This will reduce scope of Keystone, which means 2 things
2.1) Smaller code base that has less issues and is
simpler for testing
2.2) Keystone team would be able to concentrate more on
fixing perf/scalability issues of authorization, which
is crucial at the moment for large clouds.


I'm not sure that this is entirely true. If we truly just
split up the project, meaning we don't remove functionality,
then we'd have the same number of bugs and work. It would
just be split across two projects.

I think the current momentum to get out of the authn
business is still our best bet. As Steve mentioned this is
ongoing work.

-- David


What everyone else said... but add in the need then to either
pass the AuthN over to the Assignment/AuthZ api or bake it in
(via apache module?) and we are basically where we are now.

Steve alluded to splitting out the authentication bit (but not
to a new service), the idea there is to make it so AuthN is not
part of the CRUD interface of the server. All being said, AuthN
and AuthZ are going to be hard to split into two separate
services and with exception of the unfounded "scope" benefit, we
already can handle most of what you've proposed with zero
changes to Keystone.

Cheers,
--Morgan



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

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


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

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



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




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

Re: [openstack-dev] [all][elections] Results of the TC Election

[Jeremy Stanley]

On 2016-04-08 09:43:59 -0400 (-0400), Ryan Brady wrote:
> Increase the commit requirements, but don't remove the summit pass
> perk. You'll add a barrier for ATCs and see fewer of them at
> summits.

The commit counts for the latest TC electorate show 27% had only one
merged change in Gerrit during the qualifying one year period. It's
worth keeping in mind that for recent summits only the current
cycle's contributions were taken into account for free passes
though, rather than a full year, so it's possibly more telling that
40% of the electorate had only 1 or 2 qualifying commits (the bare
minimum to get free conference registration for Liberty, Mitaka or
both).

A basic regression analysis of the owner totals for 3 through 50
changes closely fits a power curve of 857.39*x^-1.239 and comes
within 3.3% of predicting how many of the electorate have only one
change, but falls 15% short of predicting those with two. That said,
the deviation only means an additional 94 more contributors who had
one or two changes than the model predicts there should be, so I
don't think there's a strong enough correlation with the limited
data we have to say for sure that free summit passes result in a
significant bloat in electorate size (certainly a lot less of one
than I expected anyway).
-- 
Jeremy Stanley
Owners of only 1 changes: 887
Owners of only 2 changes: 428
Owners of only 3 changes: 242
Owners of only 4 changes: 178
Owners of only 5 changes: 112
Owners of only 6 changes: 110
Owners of only 7 changes: 70
Owners of only 8 changes: 66
Owners of only 9 changes: 56
Owners of only 10 changes: 50
Owners of only 11 changes: 45
Owners of only 12 changes: 35
Owners of only 13 changes: 31
Owners of only 14 changes: 34
Owners of only 15 changes: 31
Owners of only 16 changes: 23
Owners of only 17 changes: 19
Owners of only 18 changes: 28
Owners of only 19 changes: 21
Owners of only 20 changes: 17
Owners of only 21 changes: 18
Owners of only 22 changes: 17
Owners of only 23 changes: 22
Owners of only 24 changes: 14
Owners of only 25 changes: 12
Owners of only 26 changes: 13
Owners of only 27 changes: 22
Owners of only 28 changes: 18
Owners of only 29 changes: 13
Owners of only 30 changes: 10
Owners of only 31 changes: 16
Owners of only 32 changes: 14
Owners of only 33 changes: 13
Owners of only 34 changes: 9
Owners of only 35 changes: 8
Owners of only 36 changes: 11
Owners of only 37 changes: 11
Owners of only 38 changes: 16
Owners of only 39 changes: 4
Owners of only 40 changes: 14
Owners of only 41 changes: 9
Owners of only 42 changes: 11
Owners of only 43 changes: 4
Owners of only 44 changes: 12
Owners of only 45 changes: 6
Owners of only 46 changes: 10
Owners of only 47 changes: 8
Owners of only 48 changes: 11
Owners of only 49 changes: 7
Owners of only 50 changes: 4
Owners of only 51 changes: 6
Owners of only 52 changes: 9
Owners of only 53 changes: 7
Owners of only 54 changes: 9
Owners of only 55 changes: 4
Owners of only 56 changes: 6
Owners of only 57 changes: 5
Owners of only 58 changes: 7
Owners of only 59 changes: 3
Owners of only 60 changes: 4
Owners of only 61 changes: 4
Owners of only 62 changes: 5
Owners of only 63 changes: 7
Owners of only 64 changes: 3
Owners of only 65 changes: 4
Owners of only 66 changes: 4
Owners of only 67 changes: 6
Owners of only 68 changes: 8
Owners of only 69 changes: 3
Owners of only 70 changes: 3
Owners of only 71 changes: 0
Owners of only 72 changes: 2
Owners of only 73 changes: 4
Owners of only 74 changes: 2
Owners of only 75 changes: 7
Owners of only 76 changes: 8
Owners of only 77 changes: 7
Owners of only 78 changes: 4
Owners of only 79 changes: 3
Owners of only 80 changes: 2
Owners of only 81 changes: 4
Owners of only 82 changes: 3
Owners of only 83 changes: 4
Owners of only 84 changes: 8
Owners of only 85 changes: 4
Owners of only 86 changes: 1
Owners of only 87 changes: 1
Owners of only 88 changes: 1
Owners of only 89 changes: 6
Owners of only 90 changes: 1
Owners of only 91 changes: 2
Owners of only 92 changes: 0
Owners of only 93 changes: 5
Owners of only 94 changes: 1
Owners of only 95 changes: 7
Owners of only 96 changes: 3
Owners of only 97 changes: 3
Owners of only 98 changes: 1
Owners of only 99 changes: 2
Owners of only 100 changes: 2
Owners of only 101 changes: 1
Owners of only 102 changes: 1
Owners of only 103 changes: 4
Owners of only 104 changes: 0
Owners of only 105 changes: 1
Owners of only 106 changes: 5
Owners of only 107 changes: 1
Owners of only 108 changes: 2
Owners of only 109 changes: 4
Owners of only 110 changes: 2
Owners of only 111 changes: 5
Owners of only 112 changes: 1
Owners of only 113 changes: 2
Owners of only 114 changes: 3
Owners of only 115 changes: 3
Owners of only 116 changes: 3
Owners of only 117 changes: 2
Owners of only 118 changes: 2
Owners of only 119 changes: 0
Owners of only 120 changes: 1
Owners of only 121 changes: 3
Owners of only 122 changes: 6
Owners of only 123 changes: 0
Owners of only 124 changes: 3
Owners of only 125 changes: 1

Re: [openstack-dev] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Thomas Goirand]

I forgot...

I'd also like to point out that I can fix any bug open tagged for
Debian, if someone opens it and if it is *actionable* (ie: not the way
that Matthew adopted when he reported bugs about 2 years ago).

So far, I haven't been pointed at any bug opened. Neither I've been
involved in the spec which were drafted to remove Debian (I'm
discovering it today).

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] [devstack][neutron] Eliminating the DevStack layer

[Mike Spreitzer]

I like this, for a reason not mentioned.  I am not a Neutron dev or 
operator and have never learned how to deploy Neutron; I have always 
driven it through DevStack.  The documentation for that has never been 
adequate, and I have concluded it will never be adequate.  With inadequate 
documentation, that layer isn't really doing its job anyway.  If there is 
no devstack layer getting in my way, I am willing to learn how to deploy 
Neutron from what I suppose is better documentation than I have been 
reading.  I understand that direct Neutron configuration is more 
troublesome than it should be.  Eliminating the devstack Neutron layer 
will only increase the pressure to both improve the documentation of 
Neutron configuration and simplify the subject, both of which are Good 
Things (TM).

Regards,
Mike



__
OpenStack Development Mailing 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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Thomas Goirand]

I don't do ab-dominem pointing fingers. I believe this is normally
detrimental to the project. However, I don't have any choice in this
case. Matthew is consistently attempting to remove the Debian support
from the install-guide. He's doing it again:

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

And without any discussion with me, who did all of the work. And again,
just after the release, which is when I usually have the time to work
again on the install-guide.

The first time it happened, was when the install-guide was converted to
RST. I was told I couldn't commit, as it was frozen.

This type of behavior is completely in opposition to what we've voted
for: the bit tent, where everyone is welcome. In this case Matthew, is
clearly making a war against Debian support in the install-guide. I
don't want this to happen.

Matthew, in his CR, wrote:
"lack of maintenance and usability"

Well, first of all, I don't agree with that. Second, like on every
releases, I intended to work on it after the packages were done, for the
Mitaka release.

Another thing is that the Debian packages are the only ones available
for many services, as Canonical doesn't work on them (these packages are
just sync from Debian, at best). So we'd be effectively removing the
only OS where it can be installed.

I received *many* feedback from people who would like to see more of
Debian in the install-guide, not less, and even less get it completely
removed. During a year, I had to point to the direct link where the
Debian guide was installed, as the link on docs.openstack.org was
removed (up to now, still don't understand why this happened). Now, even
the generation of the Debian docs is removed, and I can't point to it.

This has to stop. This is disgusting, and with no valid reason. The same
way every project should be welcome in the install-guide, contributors
should be welcome, and for all operating systems.

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] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Brandon Logan]

+1

On Fri, 2016-04-08 at 13:04 +0300, Anna Kamyshnikova wrote:
> +1
> 
> On Fri, Apr 8, 2016 at 12:49 PM, Miguel Angel Ajo Pelayo
>  wrote:
> 
> 
> On Fri, Apr 8, 2016 at 11:28 AM, Ihar Hrachyshka
>  wrote:
> Kevin Benton  wrote:
> 
> I don't know if my vote counts in this area,
> but +1!
> 
> What the gentleman said ^, +1.
> 
> 
> "me too ^" , +1 ! 
> 
> 
> 
> 
>  
> 
> __
> OpenStack Development Mailing 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,
> Ann Kamyshnikova
> Mirantis, Inc
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [sahara] Newton summit draft schedule

[Vitaly Gridnev]

Hi Sahara team,

Here [0] is the proposed schedule for our summit work sessions and
fishbowls.

Together with Nikita Konovalov we prepared all needed etherpads (now almost
empty) where we need to collect all required topics to discuss in the
specific session. We tried to make schedule in such way so that folks from
other projects will have minimal possible intersections with our sessions.

Please, let me or Nikita know if you have some kind of intersections or
blockers for timings. Also all suggestions are welcome.

[0]
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Sahara%3A
[1] https://etherpad.openstack.org/p/sahara-newton-summit

P.S.

If you would like to take a lead in the specific session, you may start
filling our etherpads!

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

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

[Heck, Joseph]

You know it’s an interesting discussion thread on keystone when both Termie and 
I are watching, chuckling, and grimacing in remembered pain …

-joe

From: Andy Smith >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, April 8, 2016 at 9:12 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [tc][ptl][keystone] Proposal to split 
authentication part out of Keystone to separated project

Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha

On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad 
> wrote:
In response to point 2.2, the progress with Fernet in the last year has exposed 
performance pain points in keystone. Finding sensible solutions for those 
issues is crucial in order for people to adopt Fernet. In Mitaka we had a lot 
of discussion that resulted in landing several performance related patches.

As of today, we're already focusing on scalability, performance, and 
simplicity. I'm afraid a project split would only delay the work we're doing 
right now.

On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg 
> wrote:


On Wed, Apr 6, 2016 at 6:29 PM, David Stanek 
> wrote:

On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic 
> wrote:

2) This will reduce scope of Keystone, which means 2 things
2.1) Smaller code base that has less issues and is simpler for testing
2.2) Keystone team would be able to concentrate more on fixing perf/scalability 
issues of authorization, which is crucial at the moment for large clouds.

I'm not sure that this is entirely true. If we truly just split up the project, 
meaning we don't remove functionality, then we'd have the same number of bugs 
and work. It would just be split across two projects.

I think the current momentum to get out of the authn business is still our best 
bet. As Steve mentioned this is ongoing work.

-- David


What everyone else said... but add in the need then to either pass the AuthN 
over to the Assignment/AuthZ api or bake it in (via apache module?) and we are 
basically where we are now.

Steve alluded to splitting out the authentication bit (but not to a new 
service), the idea there is to make it so AuthN is not part of the CRUD 
interface of the server. All being said, AuthN and AuthZ are going to be hard 
to split into two separate services and with exception of the unfounded "scope" 
benefit, we already can handle most of what you've proposed with zero changes 
to Keystone.

Cheers,
--Morgan


__
OpenStack Development Mailing 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] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

[Andy Smith]

Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha

On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad  wrote:

> In response to point 2.2, the progress with Fernet in the last year has
> exposed performance pain points in keystone. Finding sensible solutions for
> those issues is crucial in order for people to adopt Fernet. In Mitaka we
> had a lot of discussion that resulted in landing several performance
> related patches.
>
> As of today, we're already focusing on scalability, performance, and
> simplicity. I'm afraid a project split would only delay the work we're
> doing right now.
>
> On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg  > wrote:
>
>>
>>
>> On Wed, Apr 6, 2016 at 6:29 PM, David Stanek  wrote:
>>
>>>
>>> On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic 
>>> wrote:
>>>

 2) This will reduce scope of Keystone, which means 2 things
 2.1) Smaller code base that has less issues and is simpler for testing
 2.2) Keystone team would be able to concentrate more on fixing
 perf/scalability issues of authorization, which is crucial at the moment
 for large clouds.

>>>
>>> I'm not sure that this is entirely true. If we truly just split up the
>>> project, meaning we don't remove functionality, then we'd have the same
>>> number of bugs and work. It would just be split across two projects.
>>>
>>> I think the current momentum to get out of the authn business is still
>>> our best bet. As Steve mentioned this is ongoing work.
>>>
>>> -- David
>>>
>>>
>> What everyone else said... but add in the need then to either pass the
>> AuthN over to the Assignment/AuthZ api or bake it in (via apache module?)
>> and we are basically where we are now.
>>
>> Steve alluded to splitting out the authentication bit (but not to a new
>> service), the idea there is to make it so AuthN is not part of the CRUD
>> interface of the server. All being said, AuthN and AuthZ are going to be
>> hard to split into two separate services and with exception of the
>> unfounded "scope" benefit, we already can handle most of what you've
>> proposed with zero changes to Keystone.
>>
>> Cheers,
>> --Morgan
>>
>>
>> __
>> OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Morales, Victor]

Agree, sometimes is hard to figure out what is the Devstack variable that will 
modify the configuration value.

There is an effort to categorize the configuration options[1] of some of the 
projects.  I’m wondering if it could be possible to create category or field 
that specifies the Destack variable that changes this configuration value.

[1] 
https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst

Victor Morales






On 4/8/16, 10:07 AM, "Sean M. Collins"  wrote:

>Prior to the introduction of local.conf, the only way to configure
>OpenStack components was to introduce code directly into DevStack, so
>that DevStack would pick it up then inject it into the configuration
>file.
>
>This was because DevStack writes out new configuration files on each
>run, so it wasn't possible for you to make changes to any configuration
>file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).
>
>So, someone who wanted to set the Linux Bridge Agent's
>physical_interface_mappings setting for Neutron would have to use
>$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by
>DevStack[1].
>
>The local.conf functionality was introduced quite a while back, and
>I think it's time to have a conversation about why we should start
>moving away from the previous practice of declaring variables in
>DevStack, and then having them injected into the configuration files.
>
>The biggest issue is: There is a disconnect between the developers
>using DevStack and someone who is an operator or who has been editing
>OpenStack conf files directly. So, for example I can tell you all about
>how DevStack has a bunch of variables for configuring Neutron (which is
>Not a Good Thing™), and how those go into DevStack and then end up coming
>out the other side in a Neutron configuration file.
>
>Really, I would like to get rid of the intermediate layer (DevStack)
>and get both Devs and Deployers to be able to just say: Here's my
>neutron.conf - let's diff mine and yours and see what we need to sync.
>
>Matt Kassawara and I have had this issue, since he's coming from the
>OSAD side, and I'm coming from the DevStack side. We both know what the
>Neutron configuration should end up as, but DevStack having its own set
>of variables and how those variables are handled and eventually rendered
>as a Neutron config file makes things more difficult than it needs to
>be, since Matt has to now go and learn about how DevStack handles all
>these Neutron specific variables.
>
>The Neutron refactor[2] that I am working on, I am trying to configure
>as little as possible in DevStack. Neutron should be able to, out of the
>box, Just Work™. If it can't, then that needs to be fixed in Neutron.
>
>Secondly, the Neutron refactor will be getting rid of all the things
>like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using
>DevStack actually set the apropriate line in their local.conf
>
>Such as:
>
>[[post-config|/$Q_PLUGIN_CONF_FILE]]
>[linux_bridge]
>physical_interface_mappings = foo:bar
>
>
>The advantage of this is, when someone is working with DevStack, the
>things they are configuring are the same as all the other OpenStack 
>documentation.
>
>For example, someone could read the Networking Guide, read the example
>configuration[3] and the only thing they'd need to learn is our syntax
>for specifying what file the contents go in (the 
>"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).
>
>Thoughts?
>
>[1]: 
>https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63
>
>[2]: https://review.openstack.org/168438
>
>[3]: 
>http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration
>
>-- 
>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] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

[Dolph Mathews]

You can use the public URL as a fallback to the internal URL; however, the
admin URL is assumed to be the only privileged API endpoint.

The details are buried in API documentation (and perhaps history), but I
tried to summarize the intended design here as I understand it:

  http://dolphm.com/openstack-keystone-service-catalog/

On Thu, Apr 7, 2016 at 1:39 PM, Brad Pokorny 
wrote:

> Hi Brian,
>
> Copying to the general list, as this is something I've wondered about, and
> others probably are as well.
>
> Please see below. I'm not an expert on this topic, but I've looked at it a
> little bit.
>
> On 4/7/16, 11:02 AM, "Tully, Brian"  wrote:
>
> >Hi there -
> >
> >I'm reaching out to ask for some clarification on what the difference is
> >between adminURL and internalURL as it pertains to the keystoneclient ‹
> >specifically in api/keystone.py
> >(
> http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/
> >a
> >pi/keystone.py#n163) whereby if the user is logged in as an admin, the api
> >will specify 'adminURL' as the endpoint type.
> >
> >We have a scenario where our admin interface and internal interface are on
> >2 separate networks, and therefore the adminURL is not accessible by
> >Horizon.
>
> I think the original intent of having separate URL types was this exact
> purpose - having them on different networks/ports that can be locked down
> to protect admin operations. This was briefly mentioned in a recent ML
> post:
> http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
> er:date-backward=1
>
> It sounds like operations were locked down for the v2 identity API, but
> maybe not for v3 (which I'm assuming is what you're using).
>
> >When using the openstack CLI, we can specify the endpoint type as
> >internal and do not see any perceived reduction in functionality as an
> >admin user.
>
> If everything can be done via the CLI with the internal URL anyway, then
> what's the point of protecting the admin URL on a separate network? Sounds
> like this is what your question below is getting at.
>
> >Are there certain functions that can only be accessed through
> >the adminURL?
>
> This is what I'm not sure of.
>
> >
> >
> >For our use case, we think we can workaround this by adding a new config
> >setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
> >'internalURL' in local_settings.py:
> >
> ># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in
> >the
> ># case that the default admin interface in the Keystone service catalog
> ># is not accessible by Horizon. Use this setting when Horizon cannot
> ># access the identity endpoint at the default 'adminURL' and set it to
> ># 'internalURL'.
> >#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
> >
> >
> >then in api/keystone.py we can change
> >
> >endpoint_type = 'adminURL'
> >
> >to
> >
> >endpoint_type = getattr(settings,
> >'IDENTITY_ADMIN_ENDPOINT_TYPE',
> >'adminURL')
> >
> >which will use 'adminURL' as the default, but allow user customizable
> >endpoint type for identity
> >
> >
> >Does this seem even remotely useful upstream? Let me know...
>
> I would think if the internal URL can do everything the admin URL can do,
> and if that's how things are supposed to remain long term, there's no
> reason to have internal and admin on separate networks.
>
> >
> >Thanks!
> >
> >Brian Tully
> >Software Engineer
> >HPE
> >
> >
>
>
> __
> OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Sean M. Collins]

Edgar Magana wrote:
> This is a very solid plan. Maybe to fair on the current state of the devstack 
> with neutron functionality, what will be the disadvantage(s) of this change 
> from your perspective?
> 

A user's local.conf will probably get a little bigger - and I think a
lot of the issues about Neutron's inability to run out of the box will
be exposed.

I mean let's face it - Neutron, installed from source, with no
configuration Does Not Work™. There are not enough settings that have
defaults set, for it to actually run.

This was made painfully obvious to me when I had to make new revisions
to the Neutron DevStack refactor, where I had to add more inisets, in
order for Neutron to finish stacking correctly.

Did you know, for example, that we rely on DevStack[1] to set the list
of mechanism_drivers? Without this, you'll get an empty mechanism_driver
list and nothing will ever be wired up.

I'm sure there is an argument that can be made about why there is no
default for mechanism_drivers in ML2, since there are lots of options.
But, I think that we can at least enable the ones that we have in
Neutron's main tree. Packagers who make packages for each mechanism
driver (LB, OVS, etc..) already had to handle things like
mechanism_drivers in the Ml2 configuration already, so it shouldn't
really impact them since we're only setting a default if nothing is set,
and their packages should explicitly set it.

[1]: 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/ml2#L27


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

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Doug Wiegley]

+1 (ditto)

> On Apr 8, 2016, at 9:31 AM, Carl Baldwin  wrote:
> 
> +1 (whether my vote counts or note for this area)
> 
> On Thu, Apr 7, 2016 at 10:34 PM, Akihiro Motoki  wrote:
>> Hi Neutrinos,
>> 
>> As the API Lieutenant of Neutron team,
>> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
>> Neutron core reviewer team mainly focuing on the API/DB area.
>> 
>> Hirofumi has been contributing neutron actively in the recent two
>> releases constantly.
>> He was involved in key features in API/DB areas in Mitaka such as
>> tagging support and network availability zones.
>> I believe his knowledge and involvement will be great addition to our team.
>> He have been reviewing constantly [1] and I expect he continue to work
>> for Newton or later.
>> 
>> Existing API/DB core reviews (and other Neutron core reviewers),
>> please vote +1/-1 for the addition of Hirofumi to the team.
>> 
>> Thanks!
>> Akihiro
>> 
>> 
>> [1] http://stackalytics.com/report/contribution/neutron/90
>> 
>> __
>> OpenStack Development Mailing 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] [puppet] Puppet OpenStack Community Session in Austin Summit

[Emilien Macchi]

On Tue, Mar 22, 2016 at 4:31 PM, Emilien Macchi  wrote:
> Puppet OpenStack group will have a Community Session during the next
> Summit in Austin.
>
> This session is great to gather feedback from anyone in OpenStack community:
> * developers can ask questions about how to contribute.
> * operators / users can give feedback at how modules work on their 
> deployments.
>
> What we would like during this session is getting a maximum of
> feedback about Puppet OpenStack modules:
> * what would you like us to develop / improve / fix during Newton?
> * how do you use the modules? Do you use Hiera? Which version of
> Puppet? Which operating system? Which OpenStack version?
>
> If you are interested by this session, or if you can't attend it but
> you have some feedback / questions you want us to discuss, please
> look:
> https://etherpad.openstack.org/p/newton-community-puppet
>
>
> Puppet OpenStack team will do their best to get feedback and address
> it during Newton cycle, your help is really important!

This morning I updated our agenda for next Summit.
I would like people to look at our etherpad and comment if needed
(can't attend session, suggestions, etc)
https://etherpad.openstack.org/p/newton-design-puppet

We have one session about CI, if someone from infra could join, and
one about Docker, where we want mfish or clayton around.
Sessions are pretty flexible, I can still modify what I did in
schedule, but let me know asap.

Output of schedule is here:
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Puppet%20OpenStack%3A

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Carl Baldwin]

+1 (whether my vote counts or note for this area)

On Thu, Apr 7, 2016 at 10:34 PM, Akihiro Motoki  wrote:
> Hi Neutrinos,
>
> As the API Lieutenant of Neutron team,
> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
> Neutron core reviewer team mainly focuing on the API/DB area.
>
> Hirofumi has been contributing neutron actively in the recent two
> releases constantly.
> He was involved in key features in API/DB areas in Mitaka such as
> tagging support and network availability zones.
> I believe his knowledge and involvement will be great addition to our team.
> He have been reviewing constantly [1] and I expect he continue to work
> for Newton or later.
>
> Existing API/DB core reviews (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Hirofumi to the team.
>
> Thanks!
> Akihiro
>
>
> [1] http://stackalytics.com/report/contribution/neutron/90
>
> __
> OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Edgar Magana]

This is a very solid plan. Maybe to fair on the current state of the devstack 
with neutron functionality, what will be the disadvantage(s) of this change 
from your perspective?

Edgar



On 4/8/16, 8:07 AM, "Sean M. Collins"  wrote:

>Prior to the introduction of local.conf, the only way to configure
>OpenStack components was to introduce code directly into DevStack, so
>that DevStack would pick it up then inject it into the configuration
>file.
>
>This was because DevStack writes out new configuration files on each
>run, so it wasn't possible for you to make changes to any configuration
>file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).
>
>So, someone who wanted to set the Linux Bridge Agent's
>physical_interface_mappings setting for Neutron would have to use
>$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by
>DevStack[1].
>
>The local.conf functionality was introduced quite a while back, and
>I think it's time to have a conversation about why we should start
>moving away from the previous practice of declaring variables in
>DevStack, and then having them injected into the configuration files.
>
>The biggest issue is: There is a disconnect between the developers
>using DevStack and someone who is an operator or who has been editing
>OpenStack conf files directly. So, for example I can tell you all about
>how DevStack has a bunch of variables for configuring Neutron (which is
>Not a Good Thing™), and how those go into DevStack and then end up coming
>out the other side in a Neutron configuration file.
>
>Really, I would like to get rid of the intermediate layer (DevStack)
>and get both Devs and Deployers to be able to just say: Here's my
>neutron.conf - let's diff mine and yours and see what we need to sync.
>
>Matt Kassawara and I have had this issue, since he's coming from the
>OSAD side, and I'm coming from the DevStack side. We both know what the
>Neutron configuration should end up as, but DevStack having its own set
>of variables and how those variables are handled and eventually rendered
>as a Neutron config file makes things more difficult than it needs to
>be, since Matt has to now go and learn about how DevStack handles all
>these Neutron specific variables.
>
>The Neutron refactor[2] that I am working on, I am trying to configure
>as little as possible in DevStack. Neutron should be able to, out of the
>box, Just Work™. If it can't, then that needs to be fixed in Neutron.
>
>Secondly, the Neutron refactor will be getting rid of all the things
>like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using
>DevStack actually set the apropriate line in their local.conf
>
>Such as:
>
>[[post-config|/$Q_PLUGIN_CONF_FILE]]
>[linux_bridge]
>physical_interface_mappings = foo:bar
>
>
>The advantage of this is, when someone is working with DevStack, the
>things they are configuring are the same as all the other OpenStack 
>documentation.
>
>For example, someone could read the Networking Guide, read the example
>configuration[3] and the only thing they'd need to learn is our syntax
>for specifying what file the contents go in (the 
>"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).
>
>Thoughts?
>
>[1]: 
>https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63
>
>[2]: https://review.openstack.org/168438
>
>[3]: 
>http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration
>
>-- 
>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] [TripleO][CI] Ability to reproduce failures

[Derek Higgins]

On 7 April 2016 at 22:03, Gabriele Cerami  wrote:
> Hi,
>
> I'm trying to find an entry point to join the effort in TripleO CI.
Hi Gabriele, welcome aboard

> I studied the infrastructure and the scripts, but there's still something I'm 
> missing.
> The last step of studying the complex landscape of TripleO CI and the first 
> to start contributing
> is being able to reproduce failures in an accessible environment, to start 
> debugging issues.
> I have not found an easy and stable way to do this. Jobs are certainly 
> gathering
> a lot of logs, but that's not enough.
>
> At the moment, I started launching periodic jobs on my local test box using
> this script
> https://github.com/sshnaidm/various/blob/master/tripleo_repr.sh
>
> It's quite handy, but I'm not sure it's able to produce perfectly compatible
> environments with what's in CI.

Great, I haven't tried to run it but at quick glance this looks like
your doing most of main steps that are needed to mimic CI, I haven't
seen anything that is obviously missing what kind of differences are
you seeing in the results when compared to CI?

>
> Can anyone suggest a way to make jobs reproducible locally? I know it may be 
> complicated
> to setup an environment through devtest, but may If we can start with just a 
> list of steps,
> then it would be easier to put them into a script, hten make it availabe in 
> the log in place
> of the current reproduce.sh that is not very useful.

So, I think the problem with reproduce.sh is that nobody in tripleo
has ever used it, and as a result toci_gate_test.sh and
toci_instack.sh just aren't compatible with it, I'd suggest we change
the the toci_* scripts so that they play nice together. I'll see if I
can give it a whirl over the next few days and see what problem we're
likely to hit.

>
> thanks for any feedback.
>
> __
> OpenStack Development Mailing 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][CI] Ability to reproduce failures

[Steven Hardy]

Hi Gabriele,

On Thu, Apr 07, 2016 at 05:03:33PM -0400, Gabriele Cerami wrote:
> Hi,
> 
> I'm trying to find an entry point to join the effort in TripleO CI.
> I studied the infrastructure and the scripts, but there's still something I'm 
> missing.
> The last step of studying the complex landscape of TripleO CI and the first 
> to start contributing
> is being able to reproduce failures in an accessible environment, to start 
> debugging issues.
> I have not found an easy and stable way to do this. Jobs are certainly 
> gathering
> a lot of logs, but that's not enough.
> 
> At the moment, I started launching periodic jobs on my local test box using
> this script
> https://github.com/sshnaidm/various/blob/master/tripleo_repr.sh
> 
> It's quite handy, but I'm not sure it's able to produce perfectly compatible 
> environments with what's in CI.
> 
> Can anyone suggest a way to make jobs reproducible locally? I know it may be 
> complicated
> to setup an environment through devtest, but may If we can start with just a 
> list of steps, 
> then it would be easier to put them into a script, hten make it availabe in 
> the log in place
> of the current reproduce.sh that is not very useful.

Note we're not using devtest at all anymore, the developer script many
folks use is tripleo.sh:

https://github.com/openstack-infra/tripleo-ci/blob/master/scripts/tripleo.sh

Your script is already calling this so you're pretty close to what others
are using I think.

There is an effort in https://github.com/openstack/tripleo-quickstart to
make this process more automated, but my setup process looks like this
http://paste.fedoraproject.org/351818/1283361/ (note the RAM allocation
there is more than is typically required)

In both cases you end up using a different process to setup the instack VM,
but otherwise gets you very close to what CI runs and generally reproduces
issues.

Note that once you have an environment, you can often just yum update the
undercloud (and possibly re-run openstack undercloud install) to reproduce
issues (sometimes you'll also have to rebuild the overcloud-full image) -
so when I seen an issue in CI typically my first step is incrementally
updating things on my local environment rather than completly building a
new one from scratch (which obviously takes much longer).

I agree we could make this easier, and it'd be good if those scripts other
than tripleo.sh were more easily reusable in developer environments.

Steve

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

Re: [openstack-dev] [kloudbuster] authorization failed problem

[Alec Hothan (ahothan)]

From: Akshay Kumar Sanghai 
>
Date: Thursday, April 7, 2016 at 1:46 AM
To: "Yichen Wang (yicwang)" >, Alec 
Hothan >
Cc: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Thanks Yichen and Alec.
Yichen, It was what I was looking for. I started with Rally , but faced problem 
with defining the number of router per tenant and traffic generation. Then, I 
found that there is a new project Kloudbuster. I faced some issues , but with 
your help , I succeeded in running it.
One suggestion: I think Rally developers  are also trying for the traffic 
generation. So just make sure, we don't have two things for the same work under 
the openstack umbrella.

We're also using Rally to test our control plane. Data plane testing at scale 
is a whole different ballgame (than control plane) and we had very specific 
scale test requirements in mind for our own usage as far back as late 2014, 
which is why we developed kloudbuster in Feb 2015 with HTTP traffic at scale. 
At that time there was no solution available for doing automated data plane 
scale testing, even today as you can see the number of solutions is actually 
very limited.
Anyway if the Rally developers are interested to discuss about it, I or Yichen 
would be happy to discuss.


One Request:  I have not contributed to any project till now. I am interested 
in contributing to the Kloudbuster project. Please suggest how to start and 
help me in getting up to speed.

There is currently no bug backlog in kloudbuster. Since we use it quite a lot, 
every issue we run into is fixed pretty quickly but it is likely there are 
uncovered issues when run in a different environment.
There are also obviously many feature enhancements of any size but we only add 
when there is an ask as we want to keep the code small (do one thing but do it 
well).
If you use it and find a bug or need some enhancement, you're welcome to 
contribute and we can help root cause and fix.
Have you been looking for traffic generation for any particular purpose? We use 
it for testing our openstack data plane at scale (and storage now).

Regards,

  Alec




Regards,
Akshay

On Wed, Apr 6, 2016 at 1:44 PM, Yichen Wang (yicwang) 
> wrote:
Hi, Akshay,

Just curious, how do you find KloudBuster so far? Does it do its job and fit 
your needs? ☺

Thanks very much!

Regards,
Yichen

From: Alec Hothan (ahothan)
Sent: Tuesday, April 5, 2016 9:54 AM
To: Akshay Kumar Sanghai 
>; Yichen 
Wang (yicwang) >
Cc: OpenStack List 
>

Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem


Akshay,

Note that version 6 is now released so please use the official image from the 
OpenStack App Catalog and update your code to latest.
The doc has also been updated, you might want to have a look at the new arch 
section and gallery - those should help you with the questions you had below 
regarding the scale test staging and traffic flows.
http://kloudbuster.readthedocs.org/en/latest/index.html

Thanks

   Alec


From: Akshay Kumar Sanghai 
>
Date: Wednesday, March 30, 2016 at 11:11 AM
To: "Yichen Wang (yicwang)" >
Cc: Alec Hothan >, OpenStack List 
>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Yichen,
Thanks a lot . I will try with v6 and reach out to you for further help.

Regards,
Akshay

On Wed, Mar 30, 2016 at 11:35 PM, Yichen Wang (yicwang) 
> wrote:
Hi, Akshay,

From the log you attached, the good news is you got KloudBuster installed and 
running fine! The problem is the image you are using (v5) is outdated for the 
latest KloudBuster main code. ☺

Normally for every version of KloudBuster, it needs certain version of image to 
support the full functionality. In the case when new feature is brought in, we 
tag the main code with a new version, and bump up the image version. Like from 
v5 to v6, we added the capability to support storage testing on cinder volume 
and ephemeral disks as well. We are right in our time for publishing the v6 
image to the OpenStack App Catalog, which may take another day or two. This is 
why you are seeing the connection to the redis agent in KB-Proxy is failing…

In order to unblock you, here is the RC image of v6 we are using 

[openstack-dev] [devstack][neutron] Eliminating the DevStack layer

[Sean M. Collins]

Prior to the introduction of local.conf, the only way to configure
OpenStack components was to introduce code directly into DevStack, so
that DevStack would pick it up then inject it into the configuration
file.

This was because DevStack writes out new configuration files on each
run, so it wasn't possible for you to make changes to any configuration
file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).

So, someone who wanted to set the Linux Bridge Agent's
physical_interface_mappings setting for Neutron would have to use
$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by
DevStack[1].

The local.conf functionality was introduced quite a while back, and
I think it's time to have a conversation about why we should start
moving away from the previous practice of declaring variables in
DevStack, and then having them injected into the configuration files.

The biggest issue is: There is a disconnect between the developers
using DevStack and someone who is an operator or who has been editing
OpenStack conf files directly. So, for example I can tell you all about
how DevStack has a bunch of variables for configuring Neutron (which is
Not a Good Thing™), and how those go into DevStack and then end up coming
out the other side in a Neutron configuration file.

Really, I would like to get rid of the intermediate layer (DevStack)
and get both Devs and Deployers to be able to just say: Here's my
neutron.conf - let's diff mine and yours and see what we need to sync.

Matt Kassawara and I have had this issue, since he's coming from the
OSAD side, and I'm coming from the DevStack side. We both know what the
Neutron configuration should end up as, but DevStack having its own set
of variables and how those variables are handled and eventually rendered
as a Neutron config file makes things more difficult than it needs to
be, since Matt has to now go and learn about how DevStack handles all
these Neutron specific variables.

The Neutron refactor[2] that I am working on, I am trying to configure
as little as possible in DevStack. Neutron should be able to, out of the
box, Just Work™. If it can't, then that needs to be fixed in Neutron.

Secondly, the Neutron refactor will be getting rid of all the things
like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using
DevStack actually set the apropriate line in their local.conf

Such as:

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[linux_bridge]
physical_interface_mappings = foo:bar


The advantage of this is, when someone is working with DevStack, the
things they are configuring are the same as all the other OpenStack 
documentation.

For example, someone could read the Networking Guide, read the example
configuration[3] and the only thing they'd need to learn is our syntax
for specifying what file the contents go in (the 
"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).

Thoughts?

[1]: 
https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63

[2]: https://review.openstack.org/168438

[3]: 
http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration

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

Re: [openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering

[Bogdan Dobrelya]

On 03/17/2016 10:01 AM, Bogdan Dobrelya wrote:
> On 03/17/2016 12:17 AM, Andrew Beekhof wrote:
>>
>>
>> On Tue, Feb 16, 2016 at 2:58 AM, Bogdan Dobrelya > > wrote:
>>
>> Hello!
>> A quick status update inline:
>>
>>
>> [snip] 
>>
>>
>> So, what's next?
>>
>> - I'm open for merging both [5], [6] of the existing OCF RA solutions,
>> as it was proposed by Andrew Beekhof. Let's make it happen.
>>
>>
>> Great :-)
>> Oyvind (CC'd) is the relevant contact from our side, should he talk to
>> you or someone else?
> 
> Yes, we should make a follow-up perhaps and define the plan for merging
> agents

An update!
The followup was very productive, the upstream OCF RAs merge plan is

1. The rabbitmq-server repo [0] will be the destination for the merged
OCF RA.
2. Fork it [1] for the merge process and enable a travis CI check for
incoming pull requests. Note that the check exists upstream as well but
has yet to be enabled properly. Also, we decided to run tests for *only*
a cluster assembled with the merged OCF RA, w/o other components like
OpenStack or DB cluster.
3. Update the travis CI check (see example job script [2]) to meet use
cases of the 2nd OCF RA, from the resource-agents repo, we want to merge
with. So the test case shall benefit all sides of the merge process.
4. Start submitting patches to the merged RA.
5. Once finished, submit it to the upstream source at step #1. Or do it
by every (stable) patch based as well.

Action items:
* Peter Lemenkov (petro) to try a dev env via vagrant scripts [3] as
well as check it against the (RHOS/resource-agents?) packages containing
the 2nd upstream OCF RA.
* Oyvind Albrigtsen (e-ddie) to investigate ASL/GPL licensing questions.
Hopefully no issues expected and the merged OCF RA should be licensed
with ASL v2.0.
* Bogdan Dobrelya (bogdando) to investigate destructive test cases for
the travis CI check as well. The plan is to use custom jepsen tests [4]
for that.

An update item #2:
I created the aforementioned jepsen test [4], to test a rabbit cluster
recovery after network partitions. The travis CI check may run it now as
well [5], although faily a little - It may time out, but works well for
my dev box :) How-to use can be found in the README [3].

[0]
https://github.com/rabbitmq/rabbitmq-server/blob/master/scripts/rabbitmq-server-ha.ocf
[1]
https://github.com/bogdando/rabbitmq-server/blob/master/scripts/rabbitmq-server-ha.ocf
[2]
https://github.com/bogdando/rabbitmq-server/blob/rabbit_ocf_ra_travis/scripts/travis_test_ocf_ra.sh
[3] https://github.com/bogdando/rabbitmq-cluster-ocf-vagrant
[4] https://github.com/bogdando/jepsen/tree/rabbit_pcmk/rabbitmq_ocf_pcmk
[5] https://travis-ci.org/bogdando/rabbitmq-server/jobs/121704254

> 
>>  
>>
>>
>> - Would be nice to make Travis CI based gate to the upstream
>> rabbitmq-server's HA OCF RA. As for now, it relies on Fuel CI gates and
>> manual testing with atlas boxes.
>>
>> - Please also consider Travis or a suchlike CI for the resource-agents'
>> rabbit-cluster OCF RA as well.
>>
>> [1] https://github.com/bogdando/rabbitmq-cluster-ocf-vagrant
>> [2] https://github.com/bogdando/packer-atlas-example
>> [3] https://hub.docker.com/r/bogdando/rabbitmq-cluster-ocf/
>> [4] https://hub.docker.com/r/bogdando/rabbitmq-cluster-ocf-wily/
>> [5]
>> 
>> https://github.com/rabbitmq/rabbitmq-server/blob/master/scripts/rabbitmq-server-ha.ocf
>> [6]
>> 
>> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster
>>
>> >
>> > I'm also planning to refer this official RabbitMQ cluster setup guide 
>> in
>> > the OpenStack HA guide as well [2].
>>
>> Done, see [7]
>>
>> [7] http://docs.openstack.org/ha-guide/controller-ha-rabbitmq.html
>>
>> >
>> > PS. Original rabbitmq-users mail thread is here [3].
>> > [openstack-operators] cross posted as well.
>> >
>> > [0] http://www.rabbitmq.com/pacemaker.html
>> > [1] https://atlas.hashicorp.com/bogdando/boxes/rabbitmq-cluster-ocf
>> > [2] https://bugs.launchpad.net/openstack-manuals/+bug/1497528
>> > [3] https://groups.google.com/forum/#!topic/rabbitmq-users/BnoIQJb34Ao
>> >
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 

Re: [openstack-dev] [all][elections] Results of the TC Election

[Anita Kuno]

On 04/08/2016 09:14 AM, Thierry Carrez wrote:
> Eoghan Glynn wrote:
>>> However, the turnout continues to slide, dipping below 20% for
>>> the first time:
>>
>>Election | Electorate (delta %) | Votes | Turnout (delta %)
>>===
>>Oct '13  | 1106 | 342   | 30.92
>>Apr '14  | 1510(+36.52)  | 448   | 29.69   (-4.05)
>>Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>>Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>>
>>>
>>> This ongoing trend of a decreasing proportion of the electorate
>>> participating in TC elections is a concern.
> 
> One way to look at it is that every cycle (mostly due to the habit of
> giving summit passes to recent contributors) we have more and more
> one-patch contributors (more than 600 in Mitaka), and those usually are
> not really interested in voting... So the electorate number is a bit
> inflated, resulting in an apparent drop in turnout.
> 
> It would be interesting to run the same analysis but taking only >=3
> patch contributors as "expected voters" and see if the turnout still
> drops as much.
> 
> Long term I'd like to remove the summit pass perk (or no longer link it
> to "one commit"). It will likely result in a drop in contributors
> numbers (gasp), but a saner electorate.
> 

I think that splitting the Conference & Summit single event into two
separate events might make the summit pass perk redundant anyway.

I do look forward to evaluating election statistics once we address the
inflated numbers of single patch contributors.

Thanks Thierry,
Anita.

__
OpenStack Development Mailing 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] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Brian Haley]

+1

On 4/8/16 6:58 AM, Henry Gessau wrote:

+1, Hirofumi will make a great addition.

Akihiro Motoki  wrote:

Hi Neutrinos,

As the API Lieutenant of Neutron team,
I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
Neutron core reviewer team mainly focuing on the API/DB area.

Hirofumi has been contributing neutron actively in the recent two
releases constantly.
He was involved in key features in API/DB areas in Mitaka such as
tagging support and network availability zones.
I believe his knowledge and involvement will be great addition to our team.
He have been reviewing constantly [1] and I expect he continue to work
for Newton or later.

Existing API/DB core reviews (and other Neutron core reviewers),
please vote +1/-1 for the addition of Hirofumi to the team.

Thanks!
Akihiro


[1] http://stackalytics.com/report/contribution/neutron/90



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

[Sean McGinnis]

On Fri, Apr 08, 2016 at 01:24:29PM +0800, Kenny Ji-work wrote:
> Hi all,
> 
> 
> The newest version called mitaka is released, what's the new features of this 
> version. Or is there some documents to describe it? Thank you!
> 
> 
> Best regards!
> Kenny Ji

Hi Kenny,

You can find links for release notes for most projects here:

http://releases.openstack.org/mitaka/index.html

I have also seen some general summaries for various vendors like
Mirantis that might help give you a broader overview.

https://www.mirantis.com/event/live-webcast-whats-new-in-openstack-mitaka/

Sean (smcginnis)

> __
> OpenStack Development Mailing 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-Ansible] Design Summit Schedule

[Jesse Pretorius]

Hi everyone,

The Design Summit Schedule has been posted and the details for each session
has been completed [1].

Please can all moderators for the sessions ensure that the session times
don't clash with any other commitments, the content in the description is
correct and ensure that the Etherpads are populated with some initial
content describing the material you wish to cover, questions to ask, etc.

If anyone needs changes made, please let me know and I'll get it done.

Looking forward to seeing you all!

[1]
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=OpenStackAnsible

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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][elections] Results of the TC Election

[gordon chung]

On 08/04/2016 9:32 AM, Sheel Rana Insaan wrote:
> I agree with Thierry Carrez  , I think this would help.
>
> Along with this, we need to motivate new joiners to continue with openstack.
> Most of them leave earlier or participate less due to some demotivating
> factors like coding is easy but getting things reviewed is much
> difficult. :)
>
> In every group we have aome extra ordinary guys who help new
> contributors join and continue with, but some are just enjoying corehood.
> May be we should also make core members on rotation basis to give equal
> chances to everyone. This will also motivate those who are working for
> openstack in their part time.
>

forced rotations arguably wouldn't be fair to the cores that are still 
active. maybe it's best if projects don't adhere to some unwritten 
self-imposed "one out, one in" core rule. understandably it's more 
difficult to manage a large group of cores, but it does seem strange 
that all the projects have roughly the same core team size even though 
some projects have a contributor base that is significantly larger than 
others.

cheers,

-- 
gord

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

[openstack-dev] [Ironic] Failed to update Neutron port

[Senthilprabu Shanmugavel]

Hello,

I am deploying an ARMv8 board using Ironic integrated with Openstack
Liberty on Ubuntu 12.04 host. I am using fake_pxe driver and doing the
power on manually. Deploy image created from disk image creator tool

Nova boot starts the deployment, deployment image is booted, ironic-agent
is able to communicate with ironic conductor. After this, scsi connection
is established, I can see this in syslog in ironic conductor node


Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.620364] scsi
host10: iSCSI Initiator over TCP/IP
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.885579] scsi
10:0:0:0: RAID  IET  Controller   0001 PQ: 0 ANSI: 5
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.886404] scsi
10:0:0:0: Attached scsi generic sg2 type 12
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.887088] scsi
10:0:0:1: Direct-Access IET  VIRTUAL-DISK 0001 PQ: 0 ANSI: 5
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888157] sd
10:0:0:1: Attached scsi generic sg3 type 0
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888490] sd
10:0:0:1: [sdc] 15240576 512-byte logical blocks: (7.80 GB/7.26 GiB)
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889114] sd
10:0:0:1: [sdc] Write Protect is off
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889118] sd
10:0:0:1: [sdc] Mode Sense: 69 00 10 08
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889462] sd
10:0:0:1: [sdc] Write cache: enabled, read cache: enabled, supports DPO and
FUA
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.894611]  sdc:
unknown partition table
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.896728] sd
10:0:0:1: [sdc] Attached SCSI disk
Apr  8 16:31:35 lionfish-ocp-controller iscsid: Connection4:0 to [target:
iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal:
192.168.2.161,3260] through [iface: default] is operational now

On my node console, I see below messages

root@ubuntu:~# SysRq : Emergency Sync
SysRq : Power Off
reboot: Power down

I think this is triggered by scsi driver (also seen in ironic conductor
syslog) but node did not reboot due to known problem. So I powered off
manually and powered on.

Apr  8 16:31:38 lionfish-ocp-controller kernel: [16.290404] sd
10:0:0:1: [sdc] Synchronizing SCSI cache
Apr  8 16:31:38 lionfish-ocp-controller iscsid: Connection4:0 to [target:
iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal:
192.168.2.161,3260] through [iface: default] is shutdown.

So far looks good. I was expecting user image download via scsi is
successful and should be booted after going down.

By then ironic conductor log says deployment failed due to neutron failing
to set DHCP BOOT option for port.


2016-04-08 16:31:14.229 31893 INFO ironic.drivers.modules.agent_base_vendor
[req-c1e50ceb-1e11-47ea-9260-e30a2f10605d - - - - -] Initial lookup for
node 5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0 succeeded, agent is running and
waiting for commands
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron [-] Failed to
update Neutron port 7fb98457-90e6-43be-a353-f03ea1959912.
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron Traceback (most
recent call last):
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/ironic/dhcp/neutron.py", line 126, in
update_port_dhcp_opts
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
_build_client(token).update_port(port_id, port_req_body)
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 102,
in with_params
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron ret =
self.function(instance, *args, **kwargs)
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 562,
in update_port
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron return
self.put(self.port_path % (port), body=body)
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 302,
in put
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
headers=headers, params=params)
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 270,
in retry_request
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
headers=headers, params=params)
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 200,
in do_request
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
content_type=self.content_type())
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
"/usr/lib/python2.7/dist-packages/neutronclient/client.py", line 158, in
do_request
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
self.authenticate_and_fetch_endpoint_url()

Re: [openstack-dev] [all][elections] Results of the TC Election

[Ryan Brady]

On Fri, Apr 8, 2016 at 9:14 AM, Thierry Carrez 
wrote:

> Eoghan Glynn wrote:
>
>> However, the turnout continues to slide, dipping below 20% for
>>> the first time:
>>>
>>
>>Election | Electorate (delta %) | Votes | Turnout (delta %)
>>===
>>Oct '13  | 1106 | 342   | 30.92
>>Apr '14  | 1510  (+36.52)  | 448   | 29.69   (-4.05)
>>Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>>Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>>
>>
>>> This ongoing trend of a decreasing proportion of the electorate
>>> participating in TC elections is a concern.
>>>
>>
> One way to look at it is that every cycle (mostly due to the habit of
> giving summit passes to recent contributors) we have more and more
> one-patch contributors (more than 600 in Mitaka), and those usually are not
> really interested in voting... So the electorate number is a bit inflated,
> resulting in an apparent drop in turnout.
>
> It would be interesting to run the same analysis but taking only >=3 patch
> contributors as "expected voters" and see if the turnout still drops as
> much.
>
> Long term I'd like to remove the summit pass perk (or no longer link it to
> "one commit"). It will likely result in a drop in contributors numbers
> (gasp), but a saner electorate.


Increase the commit requirements, but don't remove the summit pass perk.
You'll add a barrier for ATCs and see fewer of them at summits.


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



-- 
Ryan Brady
rbr...@redhat.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][elections] Results of the TC Election

[Sheel Rana Insaan]

I agree with Thierry Carrez  , I think this would help.

Along with this, we need to motivate new joiners to continue with openstack.
Most of them leave earlier or participate less due to some demotivating
factors like coding is easy but getting things reviewed is much difficult.
:)

In every group we have aome extra ordinary guys who help new contributors
join and continue with, but some are just enjoying corehood.
May be we should also make core members on rotation basis to give equal
chances to everyone. This will also motivate those who are working for
openstack in their part time.

A lot of other suggestions as well, but mail growing longer..:)

Best Regards,
Sheel Rana
On Apr 8, 2016 6:46 PM, "Thierry Carrez"  wrote:

> Eoghan Glynn wrote:
>
>> However, the turnout continues to slide, dipping below 20% for
>>> the first time:
>>>
>>
>>Election | Electorate (delta %) | Votes | Turnout (delta %)
>>===
>>Oct '13  | 1106 | 342   | 30.92
>>Apr '14  | 1510  (+36.52)  | 448   | 29.69   (-4.05)
>>Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>>Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>>
>>
>>> This ongoing trend of a decreasing proportion of the electorate
>>> participating in TC elections is a concern.
>>>
>>
> One way to look at it is that every cycle (mostly due to the habit of
> giving summit passes to recent contributors) we have more and more
> one-patch contributors (more than 600 in Mitaka), and those usually are not
> really interested in voting... So the electorate number is a bit inflated,
> resulting in an apparent drop in turnout.
>
> It would be interesting to run the same analysis but taking only >=3 patch
> contributors as "expected voters" and see if the turnout still drops as
> much.
>
> Long term I'd like to remove the summit pass perk (or no longer link it to
> "one commit"). It will likely result in a drop in contributors numbers
> (gasp), but a saner electorate.
>
> --
> 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
>
__
OpenStack Development Mailing 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] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

[Miguel Angel Ajo Pelayo]

Hi!,

   In the context of [1] (generic resource pools / scheduling in nova) and
[2] (minimum bandwidth guarantees -egress- in neutron), I had a talk a few
weeks ago with Jay Pipes,

   The idea was leveraging the generic resource pools and scheduling
mechanisms defined in [1] to find the right hosts and track the total
available bandwidth per host (and per host "physical network"), something
in neutron (still to be defined where) would notify the new API about the
total amount of "NIC_BW_KB" available on every host/physnet.

   That part is quite clear to me,

   From [1] I'm not sure which blueprint introduces the ability to schedule
based on the resource allocation/availability itself,
("resource-providers-scheduler" seems more like an optimization to the
schedule/DB interaction, right?)

And, that brings me to another point: at the moment of filtering hosts,
nova  I guess, will have the neutron port information, it has to somehow
identify if the port is tied to a minimum bandwidth QoS policy.

That would require identifying that the port has a "qos_policy_id"
attached to it, and then, asking neutron for the specific QoS policy  [3],
then look out for a minimum bandwidth rule (still to be defined), and
extract the required bandwidth from it.

   That moves, again some of the responsibility to examine and understand
external resources to nova.

Could it make sense to make that part pluggable via stevedore?, so we
would provide something that takes the "resource id" (for a port in this
case) and returns the requirements translated to resource classes
(NIC_BW_KB in this case).


Best regards,
Miguel Ángel Ajo


[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
[2] https://bugs.launchpad.net/neutron/+bug/1560963
[3] http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy
__
OpenStack Development Mailing 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][elections] Results of the TC Election

[Thierry Carrez]

Eoghan Glynn wrote:

However, the turnout continues to slide, dipping below 20% for
the first time:


   Election | Electorate (delta %) | Votes | Turnout (delta %)
   ===
   Oct '13  | 1106 | 342   | 30.92
   Apr '14  | 1510  (+36.52)  | 448   | 29.69   (-4.05)
   Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
   Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
   Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
   Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)



This ongoing trend of a decreasing proportion of the electorate
participating in TC elections is a concern.


One way to look at it is that every cycle (mostly due to the habit of 
giving summit passes to recent contributors) we have more and more 
one-patch contributors (more than 600 in Mitaka), and those usually are 
not really interested in voting... So the electorate number is a bit 
inflated, resulting in an apparent drop in turnout.


It would be interesting to run the same analysis but taking only >=3 
patch contributors as "expected voters" and see if the turnout still 
drops as much.


Long term I'd like to remove the summit pass perk (or no longer link it 
to "one commit"). It will likely result in a drop in contributors 
numbers (gasp), but a saner electorate.


--
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] [all][elections] Results of the TC Election

[Russell Bryant]

On Fri, Apr 8, 2016 at 8:35 AM, Eoghan Glynn  wrote:

>
>
> > > Please join me in congratulating the 7 newly elected members of the TC.
> > >
> > > << REMOVE UNEEDED >
> > > * Davanum Srinivas (dims)
> > > * Flavio Percoco (flaper87)
> > > * John Garbutt (johnthetubaguy)
> > > * Matthew Treinish (mtreinish)
> > > * Mike Perez (thingee)
> > > * Morgan Fainberg (morgan)/(notmorgan)
> > > * Thierry Carrez (ttx)
> > >
> > > Full results:
> > > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> > >
> > > Thank you to all candidates who stood for election, having a good
> group of
> > > candidates helps engage the community in our democratic process.
> > >
> > > Thank you to all who voted and who encouraged others to vote. We need
> to
> > > ensure
> > > your voice is heard.
> > >
> > > Thank you for another great round.
> > >
> > > Here's to Newton!
> >
> > Thanks Tony for efficiently running this election, congrats to
> > the candidates who prevailed, and thanks to everyone who ran
> > for putting themselves out there.
> >
> > It was the most open race since the pattern of TC 2.0 half-
> > elections was established, which was great to see.
> >
> > However, the turnout continues to slide, dipping below 20% for
> > the first time:
> >
> >  Election | Electorate (delta %) | Votes | Turnout (delta %)
> >  ===
> >  Oct '16  | 1106 | 342   | 30.92
> >  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
> >  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
> >  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
> >  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>
> Meh, I screwed up that table, not enough coffee yet today :)
>
> Should be:
>
>   Election | Electorate (delta %) | Votes | Turnout (delta %)
>   ===
>   Oct '13  | 1106 | 342   | 30.92
>   Apr '14  | 1510   (+36.52)  | 448   | 29.69   (-4.05)
>   Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>   Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>   Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>   Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>

​It would also be interesting to know how the "long tail" of OpenStack has
evolved over time, as well.

https://twitter.com/tcarrez/status/710858829760598017

"​A long tail: ~2500 devs are involved in #OpenStack Mitaka, but less than
200 devs produce more than 50% of changes"

652 contributors represents roughly 80% of the changes in Mitaka by
eye-balling that graph.  That doesn't sound as bad.

-- 
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] [all][elections] Results of the TC Election

[Tristan Cacqueray]

On 04/08/2016 12:35 PM, Eoghan Glynn wrote:
> 
> 
>>> Please join me in congratulating the 7 newly elected members of the TC.
>>>
>>> << REMOVE UNEEDED >
>>> * Davanum Srinivas (dims)
>>> * Flavio Percoco (flaper87)
>>> * John Garbutt (johnthetubaguy)
>>> * Matthew Treinish (mtreinish)
>>> * Mike Perez (thingee)
>>> * Morgan Fainberg (morgan)/(notmorgan)
>>> * Thierry Carrez (ttx)
>>>
>>> Full results:
>>> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
>>>
>>> Thank you to all candidates who stood for election, having a good group of
>>> candidates helps engage the community in our democratic process.
>>>
>>> Thank you to all who voted and who encouraged others to vote. We need to
>>> ensure
>>> your voice is heard.
>>>
>>> Thank you for another great round.
>>>
>>> Here's to Newton!
>>
>> Thanks Tony for efficiently running this election, congrats to
>> the candidates who prevailed, and thanks to everyone who ran
>> for putting themselves out there.
>>
>> It was the most open race since the pattern of TC 2.0 half-
>> elections was established, which was great to see.
>>
>> However, the turnout continues to slide, dipping below 20% for
>> the first time:
>>
>>  Election | Electorate (delta %) | Votes | Turnout (delta %)
>>  ===
>>  Oct '16  | 1106 | 342   | 30.92
>>  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
>>  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>>  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>>  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
> 
> Meh, I screwed up that table, not enough coffee yet today :)
> 
> Should be:
> 
>   Election | Electorate (delta %) | Votes | Turnout (delta %)
>   ===
>   Oct '13  | 1106 | 342   | 30.92
>   Apr '14  | 1510 (+36.52)  | 448   | 29.69   (-4.05)
>   Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>   Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>   Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>   Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
> 
> Cheers,
> Eoghan
> 
>>
>> This ongoing trend of a decreasing proportion of the electorate
>> participating in TC elections is a concern.
>>
>> Cheers,
>> Eoghan
>>



Here is my take on TC election's statistics:
* voter count between L->M: +71 and M->N: +33
* those 33 new voters represent 5.33% of the voter count

So while the voter count growth doesn't scale with electorate, it is
still a positive trend where more and more people vote at each elections.

Regards,
-Tristan



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] [Security] Standing agenda for security IRC meetings

[Clark, Robert Graham]

Hi all,

As per yesterday’s meeting[1], it seems more sensible to create a standing 
agenda rather than using a new ether pad for each meeting.

The standing agenda is available here: 
https://etherpad.openstack.org/p/security-agenda

Please bookmark this and add topics you’d like to discuss before each weekly 
meeting.

Cheers
-Rob

[1]http://eavesdrop.openstack.org/meetings/security/2016/security.2016-04-07-17.00.log.html



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

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Assaf Muller]

+1

On Fri, Apr 8, 2016 at 6:58 AM, Henry Gessau  wrote:
> +1, Hirofumi will make a great addition.
>
> Akihiro Motoki  wrote:
>> Hi Neutrinos,
>>
>> As the API Lieutenant of Neutron team,
>> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
>> Neutron core reviewer team mainly focuing on the API/DB area.
>>
>> Hirofumi has been contributing neutron actively in the recent two
>> releases constantly.
>> He was involved in key features in API/DB areas in Mitaka such as
>> tagging support and network availability zones.
>> I believe his knowledge and involvement will be great addition to our team.
>> He have been reviewing constantly [1] and I expect he continue to work
>> for Newton or later.
>>
>> Existing API/DB core reviews (and other Neutron core reviewers),
>> please vote +1/-1 for the addition of Hirofumi to the team.
>>
>> Thanks!
>> Akihiro
>>
>>
>> [1] http://stackalytics.com/report/contribution/neutron/90
>
>
> __
> OpenStack Development Mailing 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][elections] Results of the TC Election

[Sylvain Bauza]

Le 08/04/2016 14:24, Eoghan Glynn a écrit :



Please join me in congratulating the 7 newly elected members of the TC.

<< REMOVE UNEEDED >
* Davanum Srinivas (dims)
* Flavio Percoco (flaper87)
* John Garbutt (johnthetubaguy)
* Matthew Treinish (mtreinish)
* Mike Perez (thingee)
* Morgan Fainberg (morgan)/(notmorgan)
* Thierry Carrez (ttx)

Full results:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a

Thank you to all candidates who stood for election, having a good group of
candidates helps engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We need to
ensure
your voice is heard.

Thank you for another great round.

Here's to Newton!

Thanks Tony for efficiently running this election, congrats to
the candidates who prevailed, and thanks to everyone who ran
for putting themselves out there.

It was the most open race since the pattern of TC 2.0 half-
elections was established, which was great to see.

However, the turnout continues to slide, dipping below 20% for
the first time:

  Election | Electorate (delta %) | Votes | Turnout (delta %)
  ===
  Oct '16  | 1106 | 342   | 30.92
  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)

This ongoing trend of a decreasing proportion of the electorate
participating in TC elections is a concern.


Honestly, I think that now OpenStack is better known, most people 
wanting to implement their own features are just thinking about that, 
and not trying to be in the community.


I could review how many people provide more than one patch, but I think 
we'd see that now we have more contributors but not really helping 
OpenStack, just trying to get what they want.


-Sylvain


Cheers,
Eoghan

__
OpenStack Development Mailing 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][elections] Results of the TC Election

[Eoghan Glynn]

> > Please join me in congratulating the 7 newly elected members of the TC.
> > 
> > << REMOVE UNEEDED >
> > * Davanum Srinivas (dims)
> > * Flavio Percoco (flaper87)
> > * John Garbutt (johnthetubaguy)
> > * Matthew Treinish (mtreinish)
> > * Mike Perez (thingee)
> > * Morgan Fainberg (morgan)/(notmorgan)
> > * Thierry Carrez (ttx)
> > 
> > Full results:
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> > 
> > Thank you to all candidates who stood for election, having a good group of
> > candidates helps engage the community in our democratic process.
> > 
> > Thank you to all who voted and who encouraged others to vote. We need to
> > ensure
> > your voice is heard.
> > 
> > Thank you for another great round.
> > 
> > Here's to Newton!
> 
> Thanks Tony for efficiently running this election, congrats to
> the candidates who prevailed, and thanks to everyone who ran
> for putting themselves out there.
> 
> It was the most open race since the pattern of TC 2.0 half-
> elections was established, which was great to see.
> 
> However, the turnout continues to slide, dipping below 20% for
> the first time:
> 
>  Election | Electorate (delta %) | Votes | Turnout (delta %)
>  ===
>  Oct '16  | 1106 | 342   | 30.92
>  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
>  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)

Meh, I screwed up that table, not enough coffee yet today :)

Should be:

  Election | Electorate (delta %) | Votes | Turnout (delta %)
  ===
  Oct '13  | 1106 | 342   | 30.92
  Apr '14  | 1510   (+36.52)  | 448   | 29.69   (-4.05)
  Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)

Cheers,
Eoghan

> 
> This ongoing trend of a decreasing proportion of the electorate
> participating in TC elections is a concern.
> 
> Cheers,
> Eoghan
> 
> __
> OpenStack Development Mailing 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][elections] Results of the TC Election

[Eoghan Glynn]

> Please join me in congratulating the 7 newly elected members of the TC.
> 
> << REMOVE UNEEDED >
> * Davanum Srinivas (dims)
> * Flavio Percoco (flaper87)
> * John Garbutt (johnthetubaguy)
> * Matthew Treinish (mtreinish)
> * Mike Perez (thingee)
> * Morgan Fainberg (morgan)/(notmorgan)
> * Thierry Carrez (ttx)
> 
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> 
> Thank you to all candidates who stood for election, having a good group of
> candidates helps engage the community in our democratic process.
> 
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure
> your voice is heard.
> 
> Thank you for another great round.
> 
> Here's to Newton!

Thanks Tony for efficiently running this election, congrats to
the candidates who prevailed, and thanks to everyone who ran
for putting themselves out there.

It was the most open race since the pattern of TC 2.0 half-
elections was established, which was great to see.

However, the turnout continues to slide, dipping below 20% for
the first time:

 Election | Electorate (delta %) | Votes | Turnout (delta %)
 ===
 Oct '16  | 1106 | 342   | 30.92
 Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
 Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
 Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
 Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)

This ongoing trend of a decreasing proportion of the electorate
participating in TC elections is a concern.

Cheers,
Eoghan 

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

[openstack-dev] [oslo][messaging][pika] Pika driver development status

[Dmitriy Ukhlov]

Hi stackers!

In Mitaka new oslo.messaging driver for RabbitMQ is released (pika driver).
I would like to share information about current state of pika driver and plans 
for improvements
during next release cycle

Now we have driver implementation which:
1) passes all tempest tests
2) implements heartbeat mechanism properly (uses pika implementation instead of 
implementing by own, like kombu driver does)
3) implements fast detection of connection problem (tcp_user_timeout usage for 
sending, heartbeats for listening)
and reconnection to next available connection node (works better with 
RabbitMQ cluster then kombu)
4) implements pure at-most-once message processing for RPC if retry=0 is set 
for message sending 
(kombu driver does not guarantee at-most-once processing even with retry=0 
because uses acknowledges)
5) is about 50% faster then kombu (at least in my simple test with simulator.py 
- 1 rpc server process and 1 rpc client process, each client runs 5 threads):
results for rabbit: 330.2 msg/sec
results for pika: 497.6 msg/sec
6) eats RabbitMQ a bit more then kombu (especially mandatory flag for rpc to 
fail fast if nobody listen target).
Therefore in performance testing (17 rpc server processes and 17 rpc client 
processes, each client runs 5 threads),
when RabbitMQ cluster is overloaded, pika driver works about 10% slower in 
rpc call. My results:
results for rabbit: 3097 msg/sec
results for pika: 2825 msg/sec
but casts work faster about 17% then kombu because it is more lightweight 
and RabbitMQ is not so heavy loaded in my tests:
results for rabbit: 5687 msg/sec
results for pika: 6697 msg/sec
7) implements separately notifications and rpc messaging (using different 
exchanges, etc) which allows to use different configuration
for different use cases (for example durable notification messaging and not 
durable rpc messaging)

Plans for future development:
1) Implement configurable message serialisation (json - current implementation, 
msgpack)
2) Implement configurable connection factory (pool of connection - current 
implementation, single connection)
3) Now it is impossible to perform rolling update from kombu to pika, we need 
to implements some solution for cross driver rolling update
4) Polishing, bug fixing, profiling etc., as usual

P.S. Thank everyone who have been helping to develop pika driver!







__
OpenStack Development Mailing 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] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

[Ihar Hrachyshka]

Kevin’s patch landed. I hope it solves the issue for Magnum and other  
projects that could be affected thru LBaaS. If not, please ping me in  
#openstack-neutron channel.


Ihar

Hirofumi Ichihara  wrote:




On 2016/04/08 12:10, Kevin Benton wrote:

Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e

I tried. Let's wait for the result.



On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu  wrote:


> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: April-07-16 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> object has no attribute 'strftime'
>
> Hongbin Lu  wrote:
>
> > Hi all,
> > Magnum gate recently broke with error: “AttributeError: 'str' object
> > has no attribute 'strftime'” (here is a full log [1]). I would like
> to
> > confirm if there is a recent commit in Neutron that causes the
> breakage.
> > If yes, a quick fix is greatly appreciated.
> >
> > [1]
> > http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-
> magnu
> > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> >
>
> The fix should be: https://review.openstack.org/#/c/302904/

This patch doesn't resolve the problem. I depends on the patch and  
re-ran the tests [1], but the tests still failed with the same error [2].


[1] https://review.openstack.org/#/c/303179/
[2]  
http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-magnum-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027


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