Re: [openstack-dev] Adding Custom Meters in Kilo Ceilometer

[ZhiQiang Fan]

basically, you need to inherit the base class and impl the get_samples
interface, then registry it in setup.cfg.

see an example in kilo: https://review.openstack.org/#/c/145819/  this
patch adds some new meters polling by compute agent

On Tue, Mar 29, 2016 at 3:29 PM, Murali Krishna  wrote:

>
>
> Hi Team,
>
>
> Anyone please help on writing a custom meters in open-stack kilo
> version.
>
>
> I tried going through many docs, but i couldn't find out any
> hint. please guide me how to customize it as per new parameters.
>
>
> Thanks in Advance [image: ] [image: ] [image:
> ] [image: ] [image: ]
>
>
> Thanks & Regards,
>
> Murali Krishna R
>
>
>
>
>
> __
> OpenStack Development Mailing 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 Developer Mailing List Digest April 2-8

[Mike Perez]

HTML rendering: 
http://www.openstack.org/blog/2016/04/openstack-developer-mailing-list-digest-20160408/

SuccessBot Says
===
* Ttx: Design Summit placeholder sessions pushed to the Austin official
* schedule.
* Pabelanger: Launched our first ubuntu-xenial job with node pool!
* Mriedem: Flavors are now in the Nova API database.
* sridhar_ram: First official release of Tacker 0.3.0 for Mitaka is released!
* Dhellmann: we have declared Mitaka released, congratulations everyone! 
* Tristanc: 54 PTL and 7 TC members elected for Newton.
* Ajaeger: docs.openstack.org is ready for Mitaka - including new manuals and
  links to release notes.
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes


Mitaka Release Is Out!
==
* Great work everyone!
* Read more about our 13th release! [1]
* See release notes from projects for new features, bug fixes, upgrade notes.
  [2]


Recently Accepted API-WG Guidelines
===
* Version discover guideline for API microversions [3]
* Client interaction guideline for API microversions [4]
* Versioning guideline for API microversions [5]
* Unexpected attribute guideline [6]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091677.html


Results of the Technical Committee Election
===
* Davanum Srinivas (dims)
* Flavio Percoco (flaper87)
* John Garbutt (johnthetubaguy)
* Matthew Treinish (mtreinish)
* Mike Perez (thingee)
* Morgan Fainberg (morgan)/(notmorgan)
* Thierry Carrez (ttx)
* Full results [7]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/thread.html#91702


Cross-Project Session Schedule
==
* Schedule posted [8].
* If there's a session you're interested in, but can't attend because of
  conflicting reasons, consider getting the conversation going early on the
  mailing list.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091739.html

[1] - http://www.openstack.org/software/mitaka
[2] - http://releases.openstack.org/mitaka/index.html
[3] - https://review.openstack.org/243429
[4] - https://review.openstack.org/243414
[5] - https://review.openstack.org/243041
[6] - https://review.openstack.org/260292
[7] - http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
[8] - 
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Cross%20Project%20workshops%3A

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

[Amrith Kumar]

Thanks to Dims and Steve for bringing this up.

It has long been my opinion that +0's are invaluable for the question 
asking, and for getting to understand software, and unfortunately +0's are lost 
in the noise. So a while ago, I posted to the ML [1] asking about making +0's 
more visible. I signed up to submit a request on gerrit upstream (and promptly 
forgot to do that). This mail thread has reminded me of that. I have now posted 
a request for the upstream gerrit folks to fix [2].

I believe that people don't use +0's enough because they often get 
ignored. I know that one can be cynical and say it is because it gives one no 
credit in stackalytics; I choose not to be that person.

I post +0's a lot. But, I find that they are often ignored. If you 
agree with me that +0's are useful, and could be highlighted better in the 
gerrit review screen, please post a comment on [2].

Thanks,

-amrith

[1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
[2] https://code.google.com/p/gerrit/issues/detail?id=4050

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Saturday, April 09, 2016 9:43 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
> stats
> 
> 
> 
> On 4/8/2016 5:54 PM, Jay Faulkner wrote:
> > 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
> >
> 
> There is also disincentive in +1ing a change that you don't understand and
> is wrong and then a core comes along and -1s it (you get dinged for the
> disagreement). And there is disincentive in -1ing a change for the wrong
> reasons (silly nits or asking questions for understanding). I ask a lot of
> questions in a lot of changes and I don't vote on those because it would
> be inappropriate.
> 
> I also notice when "newcomers" are asking good questions for understanding
> and not voting on them, it shows me they are trying to learn and are
> getting invested in the project, not just trying to pad stats. Those are
> the people we look to mentor into bigger roles in the project team, be
> that working on subteams or eventually looking at for the core reviewer
> team.
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

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

[Adam Lawson]

I have a quick question:
How is anyone hurt out harmed by the practice? I agree it isn't helpful.
But it isn't harming either. It could be gaming and it could be ignorance -
mistakes by not knowing.

I'm asking because I see the same predictable personalities making passive
aggressive accusations against their peers about gaming and ill intent.
When folks are approached, they realize it is due to not knowing. Their
answers are received with suspicion and presumptions that they are in the
minority.

We really need to stop rushing to embrace the worst in each other.

//adam
On Apr 9, 2016 1:18 PM, "Morgan Fainberg"  wrote:


On Apr 9, 2016 12:05, "Ken'ichi Ohmichi"  wrote:
>
>
> 2016/04/08 10:55、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...
>
> Can we merge this kind of patches without reviews?
> When seeing this kind of patches, I check all jobs are succeeded.
Sometimes some job failed, I check the reason and +2 if that is unrelated.
>
> This workflow seems possible to be implemented automatically.
> Or bad idea?
>
> Thanks
>

A true automerge has potential to accidentally clobber things in an ugly
way if it goes wrong. The auto propose but core approval still has a level
of human spot checking. I would personally be uncomfortable with the bot
automatically merging  things. At face value the overhead of a core
approval and possibility of what is highlighted in this thread is better
IMHO.

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

[Morgan Fainberg]

On Apr 9, 2016 12:05, "Ken'ichi Ohmichi"  wrote:
>
>
> 2016/04/08 10:55、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...
>
> Can we merge this kind of patches without reviews?
> When seeing this kind of patches, I check all jobs are succeeded.
Sometimes some job failed, I check the reason and +2 if that is unrelated.
>
> This workflow seems possible to be implemented automatically.
> Or bad idea?
>
> Thanks
>

A true automerge has potential to accidentally clobber things in an ugly
way if it goes wrong. The auto propose but core approval still has a level
of human spot checking. I would personally be uncomfortable with the bot
automatically merging  things. At face value the overhead of a core
approval and possibility of what is highlighted in this thread is better
IMHO.

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

[Ken'ichi Ohmichi]

2016/04/08 10:55、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...

Can we merge this kind of patches without reviews?
When seeing this kind of patches, I check all jobs are succeeded. Sometimes 
some job failed, I check the reason and +2 if that is unrelated.

This workflow seems possible to be implemented automatically.
Or bad idea?

Thanks








>> 
>> 
>>> 
>>> 
>>> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] Recently accepted API-WG guidelines

[Ken'ichi Ohmichi]

I much prefer this lib work.
Thanks, Chris

2016/04/08 4:32、Chris Dent 

>> On Thu, 7 Apr 2016, michael mccune wrote:
>> 
>> 1. version discover guideline for API microversions
>> https://review.openstack.org/243429
>> 
>> 2. client interaction guideline for API microversions
>> https://review.openstack.org/243414
>> 
>> 3. versioning guideline for API microversions
>> https://review.openstack.org/243041
> 
> As you can see several of these address microversions. To help make
> processing microversion headers consistent and reliable, with the
> help of sdague and elmiko I've created a library that does one thing
> and one thing only: It looks in request headers and extracts a
> microversion for a given service type from the default (modern)
> header or from a provided (legacy) header.
> 
>https://github.com/openstack/microversion-parse
>https://pypi.python.org/pypi/microversion_parse
> 
> I've started a WIP for integrating it into Nova, just to see how it
> might work and demonstrate how it could be used:
> 
>https://review.openstack.org/#/c/300076/
>https://review.openstack.org/#/c/300077/
> 
> If you look you'll see the library does very little. This is a)
> intentional, b) good. Let's have more of that.
> 
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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/09/2016 06:21 PM, Monty Taylor wrote:
> This thread is completely and totally inappropriate. Attacking a person
> the mailing list is a violation of our community standards.

Monty,

I don't take it lightly either. Please think twice about who's behavior
is inappropriate.

Because I've seen attempts from Matthew to remove Debian from the
install-guide, I was monitoring the -doc list. I've seen no thread about
it, neither I haven't been contacted, or even pinged on IRC. To me, it's
clear that it has been done behind my back, when I was not watching. And
this is a repeating pattern.

Don't you think that, at the bare minimum, I should have been
approached, and the topic discussed with me, at least to let me know
about a collective decision from the -doc team?

If it happened in a normal way, I would have probably accept it. Doing
it again, when I'm not watching (the same way it was done before),
*that* is "totally inappropriate", as you put it.

> However, this approach to this problem is categorically unacceptable
> in OpenStack.

What approach do you recommend in this case? I should just shut up, not
mention Matthew's name, and give-up my contributions, just so that I can
stay polite and pretend everyone is nice? Or let this pattern repeat
itself during another 2 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] [all][elections] Results of the TC Election

[Jim Meyer]

On Apr 8, 2016, at 2:21 PM, Eoghan Glynn  wrote:
> 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.)

+1 on this. A commit gets you invite to engage more; some larger contribution 
demonstrates that you're more engaged, meriting the ability to influence 
direction.

--j

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

[Monty Taylor]

This thread is completely and totally inappropriate. Attacking a person 
the mailing list is a violation of our community standards.


I'm going to respond to a different email in the chain because Anne asks 
a question. However, this approach to this problem is categorically 
unacceptable in OpenStack.


On 04/08/2016 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




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

[openstack-dev] [nova] Newton Instance Snapshot Capability Extended

[Ayenson, Michael D.]

Hi All,

I have proposed a blueprint 
(https://blueprints.launchpad.net/nova/+spec/instance-memory-snapshot) and nova 
spec (https://review.openstack.org/#/c/295415/) to improve the current snapshot 
capability. In the past this topic has been introduced and several times it has 
been left behind. Is there any interest in this topic in any capacity or is 
there a reason why this hasn't been extended before?


__
OpenStack Development Mailing 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][trove] Trove bug scrub

[Mariam John]

Thanks Amrith for going through the list and triaging the bugs. I think
it's a great thing that we now have bugs assigned as 'low-hanging-fruit'.
It should make it easier for newcomers to pick bugs and get started.

Regards,
Mariam.




From:   Amrith Kumar 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/05/2016 03:59 PM
Subject:Re: [openstack-dev] [all][trove] Trove bug scrub




From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Tuesday, April 05, 2016 4:35 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][trove] Trove bug scrub

Thanks Amrith.

I'll follow your lead and do some triaging as well.

We should organize bug triage days to make this process easier next time.

[amrith] I’ve been meaning to do this for some time and this morning I
finally got around to it. But in the future, it would be good to stay ahead
of this so we don’t have so much of backlog.

How about bug fixing days or bug squashing days? I’d love to do that as
well and further trim the backlog.

2016-04-05 14:44 GMT-03:00 Flavio Percoco :
 On 05/04/16 15:15 +, Amrith Kumar wrote:
  If you are subscribed to bug notifications from Trove, you’d have
  received a
  lot of email from me over the past couple of days as I’ve gone through
  the LP
  bug list for the project and attempted to do some spring cleaning.



  Here’s (roughly) what I’ve tried to do:



  -many bugs that have been inactive, and/or assigned to people who
  have not
  been active in Trove for a while have been updated and are now no longer
  assigned to anyone

  -many bugs that related to reviews that have been abandoned at some
  time
  and were marked as “in-progress” at the time are now updated; some are
  marked
  ‘confirmed’, others which appear to be no longer the case are set to
  ‘incomplete’

  -some bugs that were recently fixed, or are in the process of getting
  merged have been nominated for backports to mitaka and in some cases
  liberty

 Awesome! I'll go through the backport reviews.
  Over the next several days, I will continue this process and start
  assigning
  meaningful milestones for the bugs that don’t have them.



  There are now a number of bugs marked as ‘low-hanging-fruit’, and several
  others that are unassigned so please feel free to pitch in and help with
  making
  this list shorter.

 ++

 Flavio

 --
 @flaper87
 Flavio Percoco

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

[Matt Riedemann]

On 4/8/2016 5:54 PM, Jay Faulkner wrote:

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



There is also disincentive in +1ing a change that you don't understand 
and is wrong and then a core comes along and -1s it (you get dinged for 
the disagreement). And there is disincentive in -1ing a change for the 
wrong reasons (silly nits or asking questions for understanding). I ask 
a lot of questions in a lot of changes and I don't vote on those because 
it would be inappropriate.


I also notice when "newcomers" are asking good questions for 
understanding and not voting on them, it shows me they are trying to 
learn and are getting invested in the project, not just trying to pad 
stats. Those are the people we look to mentor into bigger roles in the 
project team, be that working on subteams or eventually looking at for 
the core reviewer team.


--

Thanks,

Matt Riedemann


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

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

[Goirand Thomas (aka zigo)]

On Apr 9, 2016 11:51 AM, Tom Fifield  wrote:
> The standing issue that I recall that raises the maintenance burden is 
> the use of debconf rather than/in addition to manual config file edits 
> as per the other distros. I can't remember whether you already tried a 
> version without debconf or not though. 

Debconf is the standard interface for configuring packages.
It should be what we document, as it is what is going to be
in action for Debian users.

There is no "standing issue", just the opinion of Matthew. Trying
to transform his opinion as an established fact doesn't work,
I'm sorry.

On Apr 9, 2016 11:51 AM, Tom Fifield  wrote:

On 09/04/16 14:49, Thomas Goirand wrote:
> I still don't have any idea what's wrong with the
> Debian guide.

The standing issue that I recall that raises the maintenance burden is 
the use of debconf rather than/in addition to manual config file edits 
as per the other distros. I can't remember whether you already tried a 
version without debconf or not though.

__
OpenStack Development Mailing 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 11:39 PM, Diana Clarke
 wrote:
> 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

Thanks Diana, Added to my list here:
https://davanum.wordpress.com/2016/04/08/new-to-openstack-reviews-start-here/

> 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



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

[Ivan Udovichenko]

As I've commented on Matthew's patch to the guide, you may just ask apt
not to ask questions provided by debconf, by prepending
DEBIAN_FRONTEND=noninteractive to it. Of course you will need to add
more options in case of an upgrade if you want to get rid of all the
questions, like adding force-confold and force-confdef options to dpkg
but it is up to you.

On 04/09/2016 12:20 PM, Tom Fifield wrote:
> On 09/04/16 14:49, Thomas Goirand wrote:
>> I still don't have any idea what's wrong with the
>> Debian guide.
> 
> The standing issue that I recall that raises the maintenance burden is
> the use of debconf rather than/in addition to manual config file edits
> as per the other distros. I can't remember whether you already tried a
> version without debconf or not though.
> 
> __
> OpenStack Development Mailing 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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Shinobu Kinjo]

Tom,

Would you elaborate more?

- Original Message -
From: "Tom Fifield" 
To: openstack-dev@lists.openstack.org
Sent: Saturday, April 9, 2016 6:20:31 PM
Subject: Re: [openstack-dev] Constant attempts from Matthew Kassawara to remove 
Debian from the install-guide

On 09/04/16 14:49, Thomas Goirand wrote:
> I still don't have any idea what's wrong with the
> Debian guide.

The standing issue that I recall that raises the maintenance burden is 
the use of debconf rather than/in addition to manual config file edits 
as per the other distros. I can't remember whether you already tried a 
version without debconf or not though.

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

[Tom Fifield]

On 09/04/16 14:49, Thomas Goirand wrote:

I still don't have any idea what's wrong with the
Debian guide.


The standing issue that I recall that raises the maintenance burden is 
the use of debconf rather than/in addition to manual config file edits 
as per the other distros. I can't remember whether you already tried a 
version without debconf or not though.


__
OpenStack Development Mailing 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 11:57 PM, Matthew Thode wrote:
> Sorry it didn't come across as a joke, but that's what the '/s' was for.

Maybe I'm getting old, but that's the first time I read that '/s' means
joke. Does it stand for "" ?

> I will be at summit in Austin at a bunch of the cross project stuff
> along with openstack-ansible stuff though.

Let's meet there at the cross-project sessions then!

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

[Thomas Goirand]

On 04/09/2016 02:05 AM, Anne Gentle wrote:
> 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.

So, Debian is being kicked away by actions from Matthew, and your reply
to my complain about it is to show the way out? Really?

Having a separate guide for Debian, re-written from scratch, is *not*
the solution.

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

That's exactly the type of duplicate work which we should try to avoid.

> 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 really don't see how it fits. Quite the opposite: if Debian is kicked
away from the install-guide, individual projects will not write
conditionals for it, leading to more work to be done for anyone trying
to maintain a separated install-guide for Debian. Or am I missing
something here?

Also, how do you propose to get projects like Congress, Senlin or Murano
documented in the install-guide, when only Debian has packages available
for them (and Ubuntu only syncs them, so what should be documented there
is the Debian way)?

On 04/09/2016 06:33 AM, Lana Brindley wrote:
> 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.

Every of the last 3 releases are making me even more mad about the doc
people, with each time, actions on Matthew's side to drive Debian out of
the install-guide which I have to fight:
- The first time was Kilo, where the RST conversion happened, and I was
told it was forbidden to write in the docs, and I couldn't repair the
Debian install-guide.
- Then in Liberty, it was decided to remove Debian *AND* RedHat just
right before the release.
- Now, just after Mitaka, a patch is proposed to get Debian out.

It's not getting any better, it's getting worse. Now the Debian guide
isn't even published (not even talking about the link to it on
docs.openstack.org). Could you please get this restored ASAP?

> Not just to get a Debian Install Guide published

Well, start by re-activating the generation of the Debian install-guide,
so that at least, once can see the actual result. I really don't
understand why it's been removed from the pool of generated docs. I
don't understand why the link to it has been removed too. OF COURSE,
this leads to even less chance for contributions.

But that's not the main issue. The biggest problem that there is, is
that to this date, I still don't have any idea what's wrong with the
Debian guide. Matthew has been producing opinions about the way Debian
handle things, like, why using MySQL and not MariaDB, versions of
RabbitMQ, use of guest account in Rabbit, etc., rather than telling what
should be done to fix the guide. As a result, there's no clear action
plan that can be drawn in order to bring the fixes, and make the doc
team satisfied about the Debian install-guide. To say it in a shorter
way: maybe he doesn't realize it himself, but Matthew has a strong
tendency to lean towards destructive complains, instead of constructive
criticism.

We have 2 alternatives
1/ either let me do my work, and accept the Debian install-guide the way
it is, or
2/ provide *clear* guidance and directions (without destructive
complains) so that one can improve the debian-guide in a way that makes
the team satisfied.

I'd very much prefer option 2/ than 1/. But what cannot happen is:

3/ complain about the global shape of the Debian install-guide, not tell
why it is bad, and get it removed.

4/ give opinions about how the packages are working in Debian and use
that as points of argumentation for the removal of Debian from the
install-guide: that's not helpful to get the install-guide better, and
not helping me to get to a stage where everyone (but Matthew?) is happy.

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

On every design summit, I'd like to get this discussion happen with the
doc people, though never, it was possible to have it even started. If
you really care, please define a clear schedule for it which doesn't
conflict with the other sessions I'll be attending.

Cheers,