date:20160909




On 廿十六年九月九日 暮 02:01, Shamail wrote:

Hi Tom,

I'll help with that.  :)


Thanks Shamail - standby - I will write up instructions and send them 
through.




Thanks,
Shamail


On Sep 9, 2016, at 2:49 PM, Tom Fifield  wrote:


On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top right, 
click on your username)

I'm also going through the recent edits and adding people to get the "bulk" of 
us in there, when time permits. Anyone else that wants to help is welcome.






Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
OpenStack Development Mailing 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] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

2016-09-09 Thread Matthew Thode

On 09/09/2016 04:24 PM, gordon chung wrote:
> 
> 
> On 09/09/16 03:45 PM, Matthew Thode wrote:
>> Does this mean that the minimum (GR needs raising as well)?
> 
> iiuc, just the max or upper-constraints.
> 
> cheers,
> 
k, I already +2'd it as I think this is fine, waiting on glorious leader
(tonyb) to +2+W it.

-- 
-- Matthew Thode (prometheanfire)



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] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

2016-09-09 Thread gordon chung



On 09/09/16 03:45 PM, Matthew Thode wrote:
> Does this mean that the minimum (GR needs raising as well)?

iiuc, just the max or upper-constraints.

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] Timeframe for future elections & "Release stewards"

2016-09-09 Thread gordon chung



On 09/09/16 03:50 PM, Matt Riedemann wrote:
>
> Do we really expect the next cycle PTL to be planning for the next cycle
> midway through the current cycle? That seems pretty extreme to me, when
> we're still crunching to the 3rd milestone and trying to wrap things up
> for feature freeze, which will determine a lot of what spills over into
> the next cycle.
>
> I think having a PTL switchover in the middle of a release and then
> having them start bugging everyone about planning for the next cycle
> would be really distracting.

i imagine it would be ok for transition to occur during RC period where 
the PTL-elect and some subset of contributors start planning while 
others work on stability of current release. that of course would be 
based on many assumptions like having enough contributors to take away 
resource from testing and your project as a whole being ok with a subset 
of people having fun task of planning and others laboring away at fixing 
stuff. that said, these decisions probably can't be applied to all 
projects generally.

>>
>> Talking with operators at the recent Ops midcycle, they were pretty
>> enthusiastic with the idea of having someone take responsibility for a
>> release cycle from day 0 (when you start collecting priorities) through
>> the development cycle, to release, up to early stable branch backports
>> and communication about the work that has been accomplished. The best
>> way to achieve that is to have that person designated in the middle of
>> the previous cycle, not just a few weeks before the development branches
>> open.
>>
>
> Are there specific bad acting projects that operators are having a
> problem with? Like, are there just terrible transitions happening
> somewhere in the community that the rest of us don't know about and it's
> impacting release-to-release development of major projects?

i imagine transitions would be hidden from operators by the 
deployment/packaging/release teams? i don't know of any bad transitions 
personally.

-- 
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] [javascript] [fuel-ui] Is ReactJS OSI Compliant?

2016-09-09 Thread Monty Taylor

On 09/07/2016 07:06 AM, Michael Krotscheck wrote:
> Preface: IANAL (I-am-not-a-lawyer).
> 
> ReactJS claims to be BSD licensed. However, it has a non-BSD patent
> rider with a very aggressive "Strong Retaliation Clause", meaning that
> if there's ever a patent dispute between [React Project] and Facebook,
> the patents are revoked.
> 
> This might be fine. It might not. If possible, I'd like one of the
> foundation lawyers to weigh in on this, as one of our projects (Fuel-UI)
> is using it.
> 
> Some discussion on the matter:
> https://news.ycombinator.com/item?id=12108158
> 
> Our own guidelines.
> http://governance.openstack.org/reference/licensing.html
> 
> Historically, OpenStack has avoided projects that make custom
> modifications to a license (see the do-no-evil license on JSLint/JSHint).

I forwarded this to legal-discuss, fwiw.


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

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting Monday 1400 UTC

2016-09-09 Thread Ed Leafe

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

The main topic for discussion will be the status of the patches for the 
placement API: https://etherpad.openstack.org/p/placement-next

Add anything else to the agenda at 
https://wiki.openstack.org/wiki/Meetings/NovaScheduler


-- Ed Leafe






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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Thiago da Silva




On 09/09/2016 04:27 PM, Doug Hellmann wrote:


Tomato, tomato.

We're all, I think, looking at this "One OpenStack" principle from
different perspectives.  You say "a toolkit". I say "a project".
Thierry said "a product". The important word in all of those phrases
is "a" -- as in singular.
Doug, I'm not sure I can agree with you on that. To use a simple 
example, I could buy *a* remote control car that is very well defined by 
the manufacturer or *a* kit that allows me to build a remote control car 
the way I want, which would probably look very different.


But I *think* what you are getting at, and I agree that we (as a 
community) need to discuss and have a better understanding, is that this 
discussion is really about the autonomy of the projects that make 
openstack. If it's one product, then projects have very little autonomy, 
but if they are a federation, they problably have more autonomy. Reading 
over the IRC chat from 2011 that ttx posted in a earlier email, it 
seemed that the vote was also about that very issue.


Thiago


Doug

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



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

Re: [openstack-dev] [nova] What would you like to ask users in order to plan Ocata development?

2016-09-09 Thread Chris Dent


On Fri, 9 Sep 2016, Matt Riedemann wrote:

I have some questions, but wanted to send this out for broader input from the 
team since I'm sure there are things I'm not thinking of on a Friday 
afternoon.


If we're just brainstorming here's some from off the top of my head.
Some of these have probably been done before but doing them
regularly is probably good.

I'm really glad you've asked the "are microversions working for you"
question. I wonder if it can be asked in a way that makes it more
straightforward to answer?

Some ideas:

- If nova were divided into more, and more separated, services would
  you think this is a positive or a negative?

- Should orchestration (for example associating a network or a
  volume with a VM) happen in an API call to nova, as multiple
  calls to separate APIs, or by a call to a "porcelain" layer
  that is "above" nova and other services and makes calls to them?

- Is it more important for Nova to fix bugs or add features?

  (You had this one in you list but this is more direct.)

- Should the openstack project start on a backwards incompatible
  greenfield compute service that people can choose to use while
  maintaining nova (bug and security fixes)?

  (If you're gonna ask, may as well throw a hail mary.)

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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] [all] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Doug Hellmann

Excerpts from Jay Pipes's message of 2016-09-09 14:30:29 -0400:
> On 09/09/2016 02:10 PM, Doug Hellmann wrote:
> > Excerpts from Jay Pipes's message of 2016-09-09 13:03:42 -0400:
> >> My vote is definitely for something #2-like, as I've said before and on
> >> the review, I believe OpenStack should be a "cloud toolkit" composed of
> >> well-scoped and limited services in the vein of the UNIX model of do one
> >> thing and do it well. I believe that vendors and cloud providers should
> >> be able to choose services and tools from this OpenStack cloud toolkit
> >> to build clouds, cloud products, and products that utilize OpenStack
> >> service APIs to please customers.
> >>
> >> It makes sense for many of those cloud toolkit services and components
> >> to integrate well with each other via public, stable interfaces and
> >> there's nothing about OpenStack being a collection of cloud tools that
> >> prevents or discourages that integration.
> >>
> >> Best,
> >> -jay
> >
> > I don't see a conflict with saying that what we're producing is a
> > set of things that can be composed in different ways depending on
> > need, but that the way we produce them is through a unified community
> > with common practices, tools, and patterns.
> 
> Absolutely agree with you above. But note that you say "what we're 
> producing is a set of things". You do not say "what we're producing is 
> *one* thing", which is what "a single product composed of cooperating 
> components" implies and which I don't think is realistic or correct.
> 
>  > To me, this statement
> > about One OpenStack is about emphasizing those commonalities and
> > working together to increase them, with the combined goals of
> > improving the user and operator experience of using OpenStack and
> > improving our own experience of making it.
> 
> +1000 to the above, and I don't believe anything about my stance that 
> OpenStack should be a cloud toolkit goes against that.
> 
> The wording/philosophy that I disagree with is the "one product" thing :)

Tomato, tomato.

We're all, I think, looking at this "One OpenStack" principle from
different perspectives.  You say "a toolkit". I say "a project".
Thierry said "a product". The important word in all of those phrases
is "a" -- as in singular.

Doug

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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

On 2016-09-09 19:58:23 + (+), John Davidge wrote:
[...]
> I don't think the problem was the path, but the goal. The
> expectation was that Stackforge projects would eventually graduate
> into OpenStack projects, but with the definition/requirements of
> OpenStack at the time that didn't always make sense.
[...]

For what it's worth, I think you're mistaken about this as well. It
was never intended that projects which were hosted in our toolchain
infrastructure needed to become an official part of OpenStack. It
eased that transition for those who did want to have their
projects/programs/teams (pick your favorite term from some point in
our history) join OpenStack but it was never required of them.

> * Create a new place for complimentary projects to live
> * Bring back Stackforge

StackForge never went away. We simply renamed it to "unofficial
repositories" dropping the (formerly confusing and, in the opinions
of many, unnecessary) branding reference to another popular
"S*Forge" service. It still works just like it did. If you have
software you want to maintain in our infrastructure and it's in some
way related to OpenStack or generally useful to our community, then
feel free to put it there. If you want that software to be an
official part of OpenStack, talk to the TC.
-- 
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] [all] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Clark Boylan

On Fri, Sep 9, 2016, at 12:58 PM, John Davidge wrote:
> Yes, that's a part of what I'm saying. After writing my first reply I
> decided there wasn't much point talking about the problem without
> proposing a solution, so I wrote one[2]. Essentially it boils down to:
> 
> * Abolish The Big Tent
> * Define OpenStack as its core components
> * Create a new place for complimentary projects to live
> * Bring back Stackforge
> 
> The link[2] below goes into a lot more detail, and I'd love to hear
> feedback from all interested parties.
> 
> >My vote is definitely for something #2-like, as I've said before and on
> >the review, I believe OpenStack should be a "cloud toolkit" composed of
> >well-scoped and limited services in the vein of the UNIX model of do one
> >thing and do it well. I believe that vendors and cloud providers should
> >be able to choose services and tools from this OpenStack cloud toolkit
> >to build clouds, cloud products, and products that utilize OpenStack
> >service APIs to please customers.
> 
> So it seems we both agree that the current definition doesn't fit, even
> if
> we don’t agree on the solution :)
> 
> Thanks,
> 
> John
> 
> [1] https://review.openstack.org/#/c/357260
> [2]
> https://johndavidge.wordpress.com/2016/09/09/mr-openstack-tear-down-this-te
> nt/

FWIW stackforge didn't go away. We just stopped using a separate Gerrit
prefix for those projects. You do not have to be part of the big tent to
be hosted on review.openstack.org. See
http://docs.openstack.org/infra/system-config/stackforge.html

Clark

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

Re: [openstack-dev] [kolla] Problem regarding named volume data location

2016-09-09 Thread Steven Dake (stdake)

I believe what Pual was indicating was

On 9/2/16, 12:59 PM, "Christian Berendt"  wrote:

> On 02 Sep 2016, at 19:04, Jeffrey Zhang  wrote:
> 
> I think the right solution should warn the end-user: you need configure a 
large partition for /var/lib/docker.

Confirmed. The volumes of Mongodb and of Mariadb are getting pretty big as 
well. Using /var/lib/nova (or /var/lib/mariadb, ..) on the local filesystem 
instead of a named volume will change nothing.

I think it is the best to stay with named volumes and to document the host 
requirements.

While using named volumes it is also possible to use alternative Docker 
volume plugins like Convoy.

Christian.

I believe what Paull was indicating was with /var/lib/nova and 
/var/lib/mariadb, it is possible to mount /var/lib/nova to /dev/sdb and 
/var/lib/mariadb to /dev/sdc.  This permits custom sizing of partitions.  I am 
not in favor – named volumes work with docker natively and permit all lkinds of 
good activity for the one tradeoff that they must be on the same filesystem and 
device.

I wonder if Paul’s use case could be met by moutning 
/var/lib/docker/_volumes/whateer to a specific disk.

The proper answer here is plugins, which can route the named volume to whatever 
backend storage is desired.  I don’t know if any plugins exist, but the 
tradeoff of bindmounting the host filesystem without docker manging the volume 
appears very problematic to me.

Regards
-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] [all] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread John Davidge

Jay Pipes wrote:

>[…]
>The TC doesn't comply with anything at all. It's the body that is
>elected to make overarching governance decisions for the OpenStack
>community.

Sure, that's an important distinction. My point is that when governance
decisions are made that seem to contradict each other, it can be difficult
to follow.

>> This is the
>> moment that OpenStack stopped being: ³A single product made of a lot of
>> independent, but cooperating, components.² And became: ³A collection of
>> independent projects that work together for some level of integration
>>and
>> releases.²
>
>You are mistaken, I'm sorry to say.

That's entirely possible. The review we're all debating highlights that
the intentions and realities of OpenStack are not easy to agree upon.

>Firstly, your statement that OpenStack stopped being "a single product"
>at some point is just flat-out wrong. It never *was* a single product,
>regardless of whether some time in 2011 seven individuals on the project
>policy board said that that was the direction they preferred the
>community to go in.

As Thierry pointed out, 'A single product made of a lot of independent,
but cooperating, components' is the closest thing we currently have to a
common philosophy. The review[1] in question is attempting to codify this
into our governance policies. The opinion of the TC seems to be that this
is what were currently are. I disagree with that assessment - it sounds
like you do as well. I take your point about OpenStack never being a
single product to begin with. The distinction I would make is that The Big
Tent was the first time a governance decision was made to undermine that
goal.

>Secondly, the Big Tent was about changing the process by which new
>projects applying to become "OpenStack projects" were evaluated by the
>TC. We went from a situation of evaluating new projects using
>subjective, often contradicting and changing opinions on architectural
>and software design to instead evaluating new project teams on whether
>the project team followed "The OpenStack Way" (followed the 4 Opens and
>furthered the mission of OpenStack)
>
>The Big Tent **was not a redefinition of what OpenStack was or is**.

In theory, perhaps. In practice, I'd say that it was. Prior to The Big
Tent there was a clear distinction between which projects were OpenStack,
and which projects were OpenStack-in-waiting (Stackforge). A problem that
The Big Tent seemed to be solving was that there wasn't always a clear
path for a given Stackforge project to become an OpenStack project. I
don't think the problem was the path, but the goal. The expectation was
that Stackforge projects would eventually graduate into OpenStack
projects, but with the definition/requirements of OpenStack at the time
that didn't always make sense. So we changed what it meant to be an
OpenStack project. Perhaps what we should have done is define a new place
for such projects to land.

>Sounds to me like you are just complaining about OpenStack having too
>many projects in it. If so, please tell us which projects you would have
>leave OpenStack.

Yes, that's a part of what I'm saying. After writing my first reply I
decided there wasn't much point talking about the problem without
proposing a solution, so I wrote one[2]. Essentially it boils down to:

* Abolish The Big Tent
* Define OpenStack as its core components
* Create a new place for complimentary projects to live
* Bring back Stackforge

The link[2] below goes into a lot more detail, and I'd love to hear
feedback from all interested parties.

>My vote is definitely for something #2-like, as I've said before and on
>the review, I believe OpenStack should be a "cloud toolkit" composed of
>well-scoped and limited services in the vein of the UNIX model of do one
>thing and do it well. I believe that vendors and cloud providers should
>be able to choose services and tools from this OpenStack cloud toolkit
>to build clouds, cloud products, and products that utilize OpenStack
>service APIs to please customers.

So it seems we both agree that the current definition doesn't fit, even if
we don’t agree on the solution :)

Thanks,

John

[1] https://review.openstack.org/#/c/357260
[2]
https://johndavidge.wordpress.com/2016/09/09/mr-openstack-tear-down-this-te
nt/

Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"


On 9/9/2016 6:49 AM, Thierry Carrez wrote:

Rob Cresswell wrote:

I've been toying with send this email for a while, but here goes: this
all feels like overcomplication and changing of a system that doesn't
really need to change.


Except the proposal here is actually to not change anything, but I see
what you mean.


I've read the pros and cons, and I still can't really see a convincing
reason not to move the PTL election to just-before-PTG, so that the new
PTL is present for one development cycle as before.


Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.


Do we really expect the next cycle PTL to be planning for the next cycle 
midway through the current cycle? That seems pretty extreme to me, when 
we're still crunching to the 3rd milestone and trying to wrap things up 
for feature freeze, which will determine a lot of what spills over into 
the next cycle.


I think having a PTL switchover in the middle of a release and then 
having them start bugging everyone about planning for the next cycle 
would be really distracting.




Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.



Are there specific bad acting projects that operators are having a 
problem with? Like, are there just terrible transitions happening 
somewhere in the community that the rest of us don't know about and it's 
impacting release-to-release development of major projects?


--

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] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

2016-09-09 Thread Matthew Thode

On 09/09/2016 02:29 PM, Pradeep Kilambi wrote:
> Hi,
> 
> This is FFE request to get ceilometerclient 2.6.1 into upper
> constraints. There is already a patch for this blocked by freeze[1].
> 
> ceilometerclient 2.6.1 was cut 3 days after the freeze looks like and it
> includes various critical fixes such as[2]. Without this aodh logs fill
> up with following errors[3] and alarm creation fails.
> 
> Please consider approving this for newton asap.
> 
> Thanks,
> 
> ~ Prad
> 
> [1] https://review.openstack.org/#/c/367386/
> [2] https://review.openstack.org/#/c/366638/
> [3] 
> http://logs.openstack.org/96/366896/4/check/gate-tripleo-ci-centos-7-scenario001-multinode-nv/97ed4b4/logs/subnode-2/var/log/aodh/evaluator.txt.gz#_2016-09-09_13_05_23_261
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Does this mean that the minimum (GR needs raising as well)?

-- 
-- Matthew Thode (prometheanfire)



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] Timeframe for future elections & "Release stewards"


On 9/9/2016 3:42 AM, Thierry Carrez wrote:


That doesn't prevent you from doing it Nova-style and use the PTL as the
release steward. It just lets you use someone else if you want to. A bit
like keeping a headphone jack. Options.



What's preventing any projects from delegating release duties to a 
non-PTL person today? That's the whole point of the release liaison I 
thought? That's why I don't really get the point of this release steward 
proposal except it's more process and a new official title, and maybe a 
different time to do the PTL election.


--

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

[openstack-dev] [nova] What would you like to ask users in order to plan Ocata development?

I've got to fill out some questions for the Newton wrap up and some 
questions about looking forward for Ocata and Pike, and one of the 
open-ended questions, I think used for the user survey, is:


"What are the questions you would like to ask users for additional 
insights to help guide the planned development in the Ocata release?"


I have some questions, but wanted to send this out for broader input 
from the team since I'm sure there are things I'm not thinking of on a 
Friday afternoon.


Random thoughts:

- How is the adoption of the v2.1 API going? Are users sticking with 
just the 2.1 microversion or are they incrementally moving forward with 
newer microversions as they are released?


- What major gaps do you feel exist in the Compute API?

- What makes deploying/operating Nova the most difficult?

- Are we effectively communicating changes/features, be it release 
notes, mailing list threads, docs, other? (Personally my feeling is we 
probably don't spend enough time on documentation and it's an afterthought).


- What are we not focusing on? For example, major features that are 
missing, or are we spending too much time on features and not enough 
time on fixing bugs?


--

That last one is hard since the big multi-cycle issues that we're 
focusing on, like cells v2 and the placement service, are not really 
features as much as they are resolutions to long-standing latent bugs.


--

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] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

+1, this release fix a bug to better understand the errors in logs for
Aodh and Ceilometer.

On Fri, Sep 9, 2016 at 3:29 PM, Pradeep Kilambi  wrote:
> Hi,
>
> This is FFE request to get ceilometerclient 2.6.1 into upper constraints.
> There is already a patch for this blocked by freeze[1].
>
> ceilometerclient 2.6.1 was cut 3 days after the freeze looks like and it
> includes various critical fixes such as[2]. Without this aodh logs fill up
> with following errors[3] and alarm creation fails.
>
> Please consider approving this for newton asap.
>
> Thanks,
>
> ~ Prad
>
> [1] https://review.openstack.org/#/c/367386/
> [2] https://review.openstack.org/#/c/366638/
> [3]
> http://logs.openstack.org/96/366896/4/check/gate-tripleo-ci-centos-7-scenario001-multinode-nv/97ed4b4/logs/subnode-2/var/log/aodh/evaluator.txt.gz#_2016-09-09_13_05_23_261
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

[openstack-dev] [Cinder] FFE request for RBD replication

2016-09-09 Thread Gorka Eguileor

Hi,

As some of you may know, Jon Bernard (jbernard on IRC) has been working
on the RBD v2.1 replication implementation [1] for a while, and we would
like to request a Feature Freeze Exception for that work, as we believe
it is a good candidate being a low risk change for the integrity of
the existing functionality in the driver:

- It's non intrusive if it's not enabled (enabled using
  replication_device configuration option).
- It doesn't affect existing deployments (disabled by default).
- Changes are localized to the driver itself (rbd.py) and the driver
  unit tests file (test_rbd.py).

Jon would have liked to make this request himself, but due to the
untimely arrival of his newborn baby this is not possible.

For obvious reasons Jon will not be available for a little while, but
this will not be a problem, as I am well acquainted with the code -and
I'll be able to reach Jon if necessary- and will be taking care of the
final steps of the review process of his patch: replying to comments in
a timely fashion, making changes to the code as required, and answering
pings on IRC regarding the patch.

Since some people may be interested in testing this functionality during
the reviewing process -or just for fun- I'll be publishing a post with
detailed explanation on how to deploy and test this feature as well as
an automated way to deploy 2 Ceph clusters -linked to be mirroring one
another-, and one devstack node with everything ready to test the
functionality (configuration and keys for the Ceph clusters, cinder
configuration, the latest upstream patch, and a volume type with the
right configuration).

Please, do not hesitate to ask if there are any questions to or concerns
related to this request.

Thank you for taking the time to evaluate this request.

Cheers,
Gorka.

[1]: https://review.openstack.org/333565

__
OpenStack Development Mailing 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] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Nikhil Komawar



On 9/9/16 4:42 AM, Thierry Carrez wrote:
> John Griffith wrote:
>> I think Sean Dague made some really good points and I'd tend to lean
>> that way.  Honestly charters, bylaws, governance etc shift or are
>> rewritten fairly often.  Why not just change when we do elections to
>> correspond with releases and keep the continuity that we have now.  Is
>> there a problem with the existing terms and cycles that maybe I'm missing?
> AFAICT this is not what Sean is proposing. He is saying that we should
> run elections in the weeks before Summit as usual, but the newly-elected
> PTL would /not/ take over the current PTL until 3 months later when the
> next development branches are opened.
>
> While it's true that there are projects with a lot of continuity and
> succession planning, with the old PTL staying around after they have
> been replaced, there are also a fair share of projects where the PTL is
> replaced by election and either rage-quits or lowers their involvement
> significantly as a result. I'd rather have the /possibility/ to separate
> the PTL from the release steward role and ensure continuity.
>
> That doesn't prevent you from doing it Nova-style and use the PTL as the
> release steward. It just lets you use someone else if you want to. A bit
> like keeping a headphone jack. Options.

LOL. May be we need to name the release steward as "headphone jack" then!

>

-- 

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

[openstack-dev] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

2016-09-09 Thread Pradeep Kilambi

Hi,

This is FFE request to get ceilometerclient 2.6.1 into upper constraints.
There is already a patch for this blocked by freeze[1].

ceilometerclient 2.6.1 was cut 3 days after the freeze looks like and it
includes various critical fixes such as[2]. Without this aodh logs fill up
with following errors[3] and alarm creation fails.

Please consider approving this for newton asap.

Thanks,

~ Prad

[1] https://review.openstack.org/#/c/367386/
[2] https://review.openstack.org/#/c/366638/
[3]
http://logs.openstack.org/96/366896/4/check/gate-tripleo-ci-centos-7-scenario001-multinode-nv/97ed4b4/logs/subnode-2/var/log/aodh/evaluator.txt.gz#_2016-09-09_13_05_23_261
__
OpenStack Development Mailing 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] [stable] [all] Regarding string freeze and back ports involving translatable strings

2016-09-09 Thread Nikhil Komawar

I have had some questions offline so, I think documenting the theory,
interpretations and POC will be helpful in our release schedule pages to
get this practice consistent across projects. If not required (or if the
process is subjective) we do not necessarily have to enforce strict
process, but we do have to make sure everyone reading the schedule are
on the same page and not wondering twice or looking for ML emails.

http://releases.openstack.org/newton/schedule.html

https://releases.openstack.org/ocata/schedule.html



On 9/9/16 3:12 PM, Matt Riedemann wrote:
> On 9/9/2016 1:58 PM, Ben Swartzlander wrote:
>
>> On 09/08/2016 08:37 PM, Matt Riedemann wrote:
>>
>>> On 9/8/2016 7:05 PM, Ravi, Goutham wrote:
>>>
 Hi,







 I was looking for some clarity around backports of bug fixes that

 qualify the stable branch policy [1].

 





 What is the policy if the fix introduces a new translatable string or

 modifies an existing one?



 The guidelines in Release management [2]

 

 regarding string freeze do not specifically call this scenario out. I

 see that while translatable strings are mostly avoided, some projects

 have been merging changes to stable branches with introduction of new

 translatable strings.







 The question is reminiscent of one posed in the ML a few releases ago

 [3];

 





 but applies to stable branches. Should we allow changes to translatable

 strings for bug fixes that matter, or is it better to always deny them

 for the sake of translation accuracy?

>>>
>>>
>>> The former IMO, a high severity bug fix trumps a translation. Note that
>>>
>>> some projects are translated on the stable branches too, I know this is
>>>
>>> the case for Nova.
>>>
>>>
>>>
>>> If it's a user-facing change, like an error message in the API, then it
>>>
>>> might require a bit more careful consideration, but if it's just a log
>>>
>>> message marked for translation that an end user of the API wouldn't see
>>>
>>> anyway, then I think it's fine to backport it.
>>>
>>
>>
>> So this stance makes sense to me, but I can't reconcile it with the
>>
>> "hard string freeze" rules. Is the theory that after we release, the
>>
>> string freeze ends for the stable branch, and that the hard string
>>
>> freeze only exists for that 3 week period between RC1 and final release,
>>
>> or is the theory that hard string freeze is always subject to exceptions
>>
>> for "critical" bug fixes?
>>
>>
>>
>> -Ben Swartzlander
>>
>>
>>






 [1]

 http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes









 [2]
 http://docs.openstack.org/project-team-guide/release-management.html



 [3]

 http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html













 Thanks,



 Goutham







 __





 OpenStack Development Mailing 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
>>
>>
>>
>
>
> I treat it as the former.
>
>
>
>
>


-- 

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] [all] Timeframe for future elections & "Release stewards"

On 2016-09-09 06:35:10 -0600 (-0600), John Griffith wrote:
> On Fri, Sep 9, 2016 at 2:42 AM, Thierry Carrez 
> wrote:
[...]
> > That doesn't prevent you from doing it Nova-style and use the PTL as the
> > release steward. It just lets you use someone else if you want to. A bit
> > like keeping a headphone jack. Options.
> >
> I see what you did there (and I like it).

An act of true courage if I've ever seen one. ;)
-- 
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] [all] governance proposal worth a visit: Write down OpenStack principles

On 2016-09-09 14:45:57 +0200 (+0200), Flavio Percoco wrote:
[...]
> As one of the folks that have always brought up "assuming good
> faith" whenever possible, I admit that I mistakenly (?) assumed
> that it was shared practice
[...]

You're certainly not alone. I for one don't wish to welcome
contributions into the community from entities who are self-serving
and willing to undermine the project and the community for their own
benefit. I'd rather be able to assume those within our community are
acting in good faith to better us all, and not hesitate to evict any
people or organizations who cannot help but succumb to greed and a
lack of empathy for positive work being done by the rest of us.

Taking a stance that we can't trust contributions from some parts of
our community reinforces an idea that we're still willing to accept
them.
-- 
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] [poll][kolla] Name of baremetal role/group

2016-09-09 Thread Mooney, Sean K



> -Original Message-
> From: Mark Casey [mailto:markca...@pointofrental.com]
> Sent: Thursday, September 8, 2016 7:38 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [poll][kolla] Name of baremetal role/group
> 
> On 9/8/2016 2:21 AM, Martin André wrote:
> > On Wed, Sep 7, 2016 at 11:58 PM, Steven Dake (stdake)
>  wrote:
> >> Sean,
> >>
> >>
> >>
> >> I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)
> > +1
> > I also like deploy-host better than the other proposed names. Can we
> > update the poll to include this option?
> 
> I have some concern that present-day conversation, operator support,
> and code reviews often refer to the host that will run kolla-ansible as
> the 'kolla host' or the 'deploy host'. So I worry this will be very
> ambiguous (i.e.: "your next step is to run deploy-hosts on the
> deployment host to deploy the hosts"). I'd lean more towards
> terminology like "target-prep", "install-node-deps", or similar.
[Mooney, Sean K] I think the topic here has drifted from what I originally want
To capture in this thread but I still find this interesting.

What I was original asking if we should change was the name of the group
In the multimode inventory
https://github.com/openstack/kolla/blob/99897c5438f59b3fa40ade388e0eafe6a0fbfffb/ansible/inventory/multinode#L30
And the corresponding ansible role name.
https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal

this would no be exposed to the enduser at all and was just a question of 
internal naming
of the role/group given that the term baremetal may be confused with ironic or 
bifrost.
> 
> imho this is really an opportunity to be more consistent with these
> terms project-wide or (perhaps more reasonably) just work towards
> making other references match the decision here. We tell a lot of
> people to start with AIO via vagrant and it (the Vagrantfile - likely
> the defacto most-read documentation we have)
[Mooney, Sean K] really I have been using kolla for a while now and I did not
Even know there was a vagrant file. even if I did know it was there it would
Be the last thing I would ever think of reading as documentation the quickstart
Guide and other documentation we have is much more useful. Vagrant certenly 
would
Not be my first choice when introducing some new to kolla. you don’t want to 
have to
Learn another workflow e.g. vagrats when you are trying to wrap your head 
around ansible,jinja and docker.

[Mooney, Sean K] > refers to these as the
> operator host and the nodes, most of the documentation calls them the
> deployment host and either the target nodes or deployment targets, and
> this change would make the name of the step to install dependencies on
> the nodes/target nodes/deployment targets to deploy-host[s] which
> sounds more like a reference to creating multiple instances of the
> deployment host/operator (I know, that's not even a thing).
> 
> Obviously you can't control what Kolla users refer to these components
> as when asking for help or etc., but I suspect it may be frustrating
> for them to use different official names as they make their particular
> progression through stages such as AIO vagrant, AIO baremetal,
> multinode in VMs, and multinode baremetal (actually, if you're having
> to read all of these sentences more slowly or even twice because I'm
> using all of the common terms in all contexts - *that*).  :D
> 
> 
> >> I’d also add a duplicate API of “deploy” and mark deploy as
> >> deprecated and follow the standard deprecation policies.  I’d
> >> recommend making the new OpenStack specific deploy command
> >> deploy-openstack
> > Agreed.
> >
> > Martin
> 
> I think I'm lost on this part. Does 'deploy'/deploy command here refer
> to 'kolla-ansible deploy' or something else entirely? AFAIK that is
> still a wholly separate step, unless we were just trying to make it
> consistent with the role rename at hand.
[Mooney, Sean K] yes this was a separate topic which Is already tracked by 
https://bugs.launchpad.net/kolla/+bug/1616221
> 
> Thank you,
> Mark
> 
> >> Regards
> >>
> >> -steve
> >>
> >>
> >>
> >>
> >>
> >> From: "sean.k.moo...@intel.com" 
> >> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> >> 
> >> Date: Wednesday, September 7, 2016 at 11:51 AM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> 
> >> Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group
> >>
> >>
> >>
> >> Hi
> >>
> >> I recently introduced a new baremetal role/group which is used as
> >> part of the kolla-host playbook.
> >>
> >>
> https://github.com/openstack/kolla/tree/master/ansible/roles/baremeta
> >> l
> >>
> >> This baremetal role is used to install all the dependencies required
> >> to deploy kolla containers on a

Re: [openstack-dev] [stable] [all] Regarding string freeze and back ports involving translatable strings


On 9/9/2016 1:58 PM, Ben Swartzlander wrote:

On 09/08/2016 08:37 PM, Matt Riedemann wrote:

On 9/8/2016 7:05 PM, Ravi, Goutham wrote:

Hi,



I was looking for some clarity around backports of bug fixes that
qualify the stable branch policy [1].



What is the policy if the fix introduces a new translatable string or
modifies an existing one?

The guidelines in Release management [2]

regarding string freeze do not specifically call this scenario out. I
see that while translatable strings are mostly avoided, some projects
have been merging changes to stable branches with introduction of new
translatable strings.



The question is reminiscent of one posed in the ML a few releases ago
[3];



but applies to stable branches. Should we allow changes to translatable
strings for bug fixes that matter, or is it better to always deny them
for the sake of translation accuracy?


The former IMO, a high severity bug fix trumps a translation. Note that
some projects are translated on the stable branches too, I know this is
the case for Nova.

If it's a user-facing change, like an error message in the API, then it
might require a bit more careful consideration, but if it's just a log
message marked for translation that an end user of the API wouldn't see
anyway, then I think it's fine to backport it.


So this stance makes sense to me, but I can't reconcile it with the
"hard string freeze" rules. Is the theory that after we release, the
string freeze ends for the stable branch, and that the hard string
freeze only exists for that 3 week period between RC1 and final release,
or is the theory that hard string freeze is always subject to exceptions
for "critical" bug fixes?

-Ben Swartzlander





[1]
http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes




[2] http://docs.openstack.org/project-team-guide/release-management.html

[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html






Thanks,

Goutham



__


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



I treat it as the former.

--

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] [interop][defcore][ptl] Intro to creating next Interop (DefCore) guideline

2016-09-09 Thread Egle Sigler

Hello Everyone,

Thanks everyone for tuning into presentation by Chris Hoge on how the next 
interop guideline is created. If you missed the session, here is the recording:
https://www.youtube.com/watch?v=kDn4jj0iSK8=youtu.be=260

Slides from the presentation: 
https://docs.google.com/presentation/d/1DqhUD4jdc8Cvmcid215age1AAp-K0xyqYHvgr45hWYE/edit?usp=sharing

Please let us know if you have any questions on 
defcore-commit...@lists.openstack.org
 mailing list or #openstack-defcore IRC channel.

Thank you,
Egle

From: Egle Sigler >
Date: Wednesday, September 7, 2016 at 8:52 PM
To: openstack-dev 
>, 
"defcore-commit...@lists.openstack.org"
 
>
Subject: [interop][defcore][ptl] Intro to creating next Interop (DefCore) 
guideline

Hello Everyone,

Interop Working Group (aka DefCore Committee) is starting to work on the next 
guideline. The next guideline will be published on 2017.01, but before then, we 
need to evaluate and score additional components to see if they should be added 
to the guideline. What is scoring? How does a component get added to the 
guideline? Will your favorite project be added to the next guideline? We are 
going to have a google hangout session on Friday and Chris Hoge will answer all 
these questions. The session will be recorded, so if you are not able to attend 
it, you can watch it later.

Event Page: https://plus.google.com/events/cuejgn5k8keg0j0c11qi3k4j15c
YouTube page: http://www.youtube.com/watch?v=kDn4jj0iSK8

Reading list for those that would like to prepare questions ahead of time:

  *   Hacking: https://github.com/openstack/defcore/blob/master/HACKING.rst

  *   Scoring: 
https://github.com/openstack/defcore/blob/master/working_materials/scoring.txt

  *   Lexicon: 
https://github.com/openstack/defcore/blob/master/doc/source/process/Lexicon.rst

  *   Core Criteria: 
https://github.com/openstack/defcore/blob/master/doc/source/process/CoreCriteria.rst

  *   Core Definition: 
https://github.com/openstack/defcore/blob/master/doc/source/process/CoreDefinition.rst

  *   Designated Sections: 
https://github.com/openstack/defcore/blob/master/doc/source/process/DesignatedSections.rst

As always, we are available to answer questions on #openstack-defcore IRC 
channel or 
defcore-commit...@lists.openstack.org
 mailing list.

Thank you,
Egle Sigler
__
OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA

2016-09-09 Thread Shamail

Hi Tom,

I'll help with that.  :)

Thanks,
Shamail 

> On Sep 9, 2016, at 2:49 PM, Tom Fifield  wrote:
> 
>> On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:
>>> On 09/09/2016 08:44, Tom Fifield wrote:
>>> 
>>> 
 On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:
> On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
> Is it just me who likes to hit the save button often?
> It gets tedious proving often that you are not a robot. Wiki
> reCAPTCHA likes proof even if saves are spaced less than a minute
> apart!
> Wiki Gods, hear my plea!
 
 I sympathize. That captcha addition is one of several tools we're
 leveraging currently to combat the ongoing spam/scammer/vandalism
 problems on wiki.openstack.org, as an alternative to shutting it
 down completely. Unfortunately even now I still spend a chunk of
 every day blocking new accounts created by abusers and cleaning up
 all their modifications, but am hoping that with other improvements
 we have pending the onslaught will lessen and we can revisit some of
 the more intrusive mechanisms on which we've been forced to rely
 (for example, I think we should be able to configure it so that
 users whose previous edits have been confirmed by a wiki admin are
 added to a group that bypasses the captcha, and then get a team of
 wiki groomers in the habit of adding known good accounts to that
 group).
>>> 
>>> Indeed - fungi has been doing amazing work :(
>>> 
>>> I have been adding "known good" accounts to such a group - there's about
>>> 64 so far:
>>> 
>>> https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol
>> 
>> How would someone get in said list?
> 
> $100 donation to the buy-fungi-beer fund.
> 
> ... and/or email me a link to your wiki user page (Click in the top right, 
> click on your username)
> 
> I'm also going through the recent edits and adding people to get the "bulk" 
> of us in there, when time permits. Anyone else that wants to help is welcome.
> 
> 
> 
> 
>>> 
>>> Is it possible to disable CAPTCHA for users in group "autopatrol"?
>>> 
>>> __
>>> OpenStack Development Mailing 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] [stable] [all] Regarding string freeze and back ports involving translatable strings

2016-09-09 Thread Ben Swartzlander


On 09/08/2016 08:37 PM, Matt Riedemann wrote:

On 9/8/2016 7:05 PM, Ravi, Goutham wrote:

Hi,



I was looking for some clarity around backports of bug fixes that
qualify the stable branch policy [1].


What is the policy if the fix introduces a new translatable string or
modifies an existing one?

The guidelines in Release management [2]

regarding string freeze do not specifically call this scenario out. I
see that while translatable strings are mostly avoided, some projects
have been merging changes to stable branches with introduction of new
translatable strings.



The question is reminiscent of one posed in the ML a few releases ago
[3];


but applies to stable branches. Should we allow changes to translatable
strings for bug fixes that matter, or is it better to always deny them
for the sake of translation accuracy?


The former IMO, a high severity bug fix trumps a translation. Note that
some projects are translated on the stable branches too, I know this is
the case for Nova.

If it's a user-facing change, like an error message in the API, then it
might require a bit more careful consideration, but if it's just a log
message marked for translation that an end user of the API wouldn't see
anyway, then I think it's fine to backport it.


So this stance makes sense to me, but I can't reconcile it with the 
"hard string freeze" rules. Is the theory that after we release, the 
string freeze ends for the stable branch, and that the hard string 
freeze only exists for that 3 week period between RC1 and final release, 
or is the theory that hard string freeze is always subject to exceptions 
for "critical" bug fixes?


-Ben Swartzlander





[1]
http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes



[2] http://docs.openstack.org/project-team-guide/release-management.html

[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html





Thanks,

Goutham



__

OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA


On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top  
right, click on your username)


I'm also going through the recent edits and adding people to get the  
"bulk" of us in there, when time permits. Anyone else that wants to help  
is welcome.







Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
OpenStack Development Mailing 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] [poll][kolla] Name of baremetal role/group

2016-09-09 Thread Mooney, Sean K

From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent: Wednesday, September 7, 2016 10:59 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [poll][kolla] Name of baremetal role/group

Sean,

I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)
[Mooney, Sean K] hi steve this is not related to the command that is run 
(kolla-ansible bootstrap-servers) it is related to the name of the ansible role 
that
Is invoked by the kolla-host playbook  when you execute the “kolla-ansible 
bootstrap-servers” command.

I’d also add a duplicate API of “deploy” and mark deploy as deprecated and 
follow the standard deprecation policies.  I’d recommend making the new 
OpenStack specific deploy command deploy-openstack
[Mooney, Sean K] this is a sperate  item that I agree would be good to do. I 
have a tech debt bug to resolve this so that we will have 
deploy-biforst,deploy-servers and deploy-openstack. I will submit a
Patch to do this before rc1.

Regards
-steve

From: "sean.k.moo...@intel.com" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 7, 2016 at 11:51 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group

Hi
I recently introduced a new baremetal role/group which is used as part of the 
kolla-host playbook.
https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
This baremetal role is used to install all the dependencies required to deploy 
kolla containers on a “baremetal” host.
The host does not have to be baremetal it can be a vm but the term baremetal 
was originally chosen as unlike other rules in
Kolla it installs and configures packages on the host os.

Given that kolla also has baremetal as a service via ironic and baremetal 
provision of servers with bifrost the question I would like
To ask is should we change the name of the current role to install the kolla 
dependencies to something else.

I have created a strawpoll link for this here http://www.strawpoll.me/11175159
The options available in the strawpool are:

· kolla-host

· host

· baremetal

· pre-install
If there are any other suggestions fell free to discuss them in this thread.
I will check the poll Friday evening gmt and submit a patch for review if 
consensus is that it should be changed.

Regards
Sean.
__
OpenStack Development Mailing 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] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Jay Pipes


On 09/09/2016 02:10 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-09-09 13:03:42 -0400:

My vote is definitely for something #2-like, as I've said before and on
the review, I believe OpenStack should be a "cloud toolkit" composed of
well-scoped and limited services in the vein of the UNIX model of do one
thing and do it well. I believe that vendors and cloud providers should
be able to choose services and tools from this OpenStack cloud toolkit
to build clouds, cloud products, and products that utilize OpenStack
service APIs to please customers.

It makes sense for many of those cloud toolkit services and components
to integrate well with each other via public, stable interfaces and
there's nothing about OpenStack being a collection of cloud tools that
prevents or discourages that integration.

Best,
-jay


I don't see a conflict with saying that what we're producing is a
set of things that can be composed in different ways depending on
need, but that the way we produce them is through a unified community
with common practices, tools, and patterns.


Absolutely agree with you above. But note that you say "what we're 
producing is a set of things". You do not say "what we're producing is 
*one* thing", which is what "a single product composed of cooperating 
components" implies and which I don't think is realistic or correct.


> To me, this statement

about One OpenStack is about emphasizing those commonalities and
working together to increase them, with the combined goals of
improving the user and operator experience of using OpenStack and
improving our own experience of making it.


+1000 to the above, and I don't believe anything about my stance that 
OpenStack should be a cloud toolkit goes against that.


The wording/philosophy that I disagree with is the "one product" thing :)

Best,
-jay

__
OpenStack Development Mailing 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] [release][ptl] ocata schedule approved

2016-09-09 Thread Doug Hellmann

Lacking any significant negative comments, the Ocata schedule proposed
in [1] has been approved. See [2] for a more nicely rendered version.

Projects with team-specific deadlines should go ahead and propose
patches to add that information, as time permits.

Doug

[1] https://review.openstack.org/#/c/357214/
[2] https://releases.openstack.org/ocata/schedule.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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Julien Danjou

On Fri, Sep 09 2016, Emilien Macchi wrote:

> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,

Congratulations for your great work during that time, and your
leadership. You built a great community, and that's no easy task.

See you soon!
-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Doug Hellmann

Excerpts from Jay Pipes's message of 2016-09-09 13:03:42 -0400:
> On 09/09/2016 06:22 AM, John Davidge wrote:
> > Thierry Carrez wrote:
> >
> >> [...]
> >> In the last years there were a lot of "questions" asked by random
> >> contributors, especially around the "One OpenStack" principle (which
> >> seems to fuel most of the reaction here). Remarks like "we should really
> >> decide once and for all if OpenStack is a collection of independent
> >> projects, or one thing".
> >>
> >> A lot of people actually ignore that this question was already asked,
> >> pretty early on (by John Dickinson in June 2011). Back then it was
> >> settled by the PPB (the ancestor to the TC). You can read it all
> >> here[1]. It was never brought again as a proposed change to the TC, so
> >> that decision from June 2011 is still defining how we should think about
> >> OpenStack.
> >>
> >> Most of the TC members know the governance history and know those
> >> principles. That is, after all, one of the reasons you elect them for.
> >> But we realized that the people asking those questions again and again
> >> were not at fault. It was our failure to *document* this history
> >> properly which caused the issue. Took us some time to gather the courage
> >> to write it, then finally Monty wrote a draft, and I turned it into a
> >> change.
> >
> > To provide a counter point, I think the reason this question is asked so
> > often is not because the TC has failed to *document* this policy, but that
> > it has failed to *comply* with it.
> 
> The TC doesn't comply with anything at all. It's the body that is 
> elected to make overarching governance decisions for the OpenStack 
> community.
> 
> > I¹m of course referring to the introduction of The Big Tent.
> 
> And I'm of course going to correct your misstatements below about what 
> the Big Tent (formally called the Project Structure Reform) was about.
> 
>  > This is the
> > moment that OpenStack stopped being: ³A single product made of a lot of
> > independent, but cooperating, components.² And became: ³A collection of
> > independent projects that work together for some level of integration and
> > releases.²
> 
> You are mistaken, I'm sorry to say.
> 
> Firstly, your statement that OpenStack stopped being "a single product" 
> at some point is just flat-out wrong. It never *was* a single product, 
> regardless of whether some time in 2011 seven individuals on the project 
> policy board said that that was the direction they preferred the 
> community to go in.
> 
> OpenStack was never a single product made of a lot of independent but 
> cooperating components. From the very beginning of OpenStack-time, Swift 
> and Nova were never designed or planned as a single product. To this 
> *day*, Swift is its own product with very few pieces of integration with 
> some other OpenStack projects where relevant (Keystone) but there was 
> never any push or reason to have Swift become simply a "part of a single 
> OpenStack product".
> 
> Secondly, the Big Tent was about changing the process by which new 
> projects applying to become "OpenStack projects" were evaluated by the 
> TC. We went from a situation of evaluating new projects using 
> subjective, often contradicting and changing opinions on architectural 
> and software design to instead evaluating new project teams on whether 
> the project team followed "The OpenStack Way" (followed the 4 Opens and 
> furthered the mission of OpenStack)
> 
> The Big Tent **was not a redefinition of what OpenStack was or is**.
> 
> > This is in direct contradiction to the stated and collectively understood
> > goal of the project, and has left many scratching their heads.
> 
> I don't know what you are referring to above as "the stated and 
> collectively understood goal of the project". Are you referring to the 
> OpenStack Mission Statement? If so, see point above. The Big Tent didn't 
> change the Mission nor did it redefine what OpenStack was.
> 
> > The principles as written in the review do not accurately describe the
> > current state of the project. To make it so that they do, we either need
> > to change the principles or change the project. As I see it, our options
> > are:
> >
> > 1. Adjust the project to reflect the principles by abolishing The Big Tent.
> > 2. Adjust the principles to reflect the project by redefining it as: ³A
> > collection of independent projects that work together for some level of
> > integration and releases.²
> >
> > Personally, my vote is for option 1.
> 
> Sounds to me like you are just complaining about OpenStack having too 
> many projects in it. If so, please tell us which projects you would have 
> leave OpenStack.
> 
> No more deployment projects? Cut Triple-O, Fuel, Puppet, Chef, Ansible, 
> Saltstack, devstack.
> 
> No more competing implementations of things? Cut Ceilometer or Monasca. 
> Your choice.
> 
> No more Telco-specific stuff? Cut Tacker, networking-sfc, and a whole 
> host of other stuff.
> 
>

Re: [openstack-dev] [tripleo] what's up in upgrades?

2016-09-09 Thread Paul Belanger

On Fri, Sep 09, 2016 at 09:29:46AM +0200, mathieu bultel wrote:
> On 09/09/2016 12:42 AM, Emilien Macchi wrote:
> > On Thu, Sep 8, 2016 at 4:18 PM, David Moreau Simard  wrote:
> >> How long does the upgrade job take ?
> > undercloud upgrade is a matter of 10 min max.
> > overcloud upgrade will be much more, I don't have metrics right now.
> > matbu maybe?
> It really depend on the infra which run the upgrade. I don't know much
> about the upstream infra but
> on my local box, with a SSD, 8 cores and 32Go of RAM, It could take
> around 1h30 2hours for a full upgrade.
> On centos ci infra and with RDO, some jobs can takes 4hours or so ...
> 
> I'm really curious to see how long a full upgrade will take with upstream.
> 
> Right now, the full upgrade job didn't go far from the controller
> upgrade (step 2).
> AFAIK, the timeout in upstream is 3 hours minus 10 minutes ...
> I think if we keep a 2 nodes deployment with only pacemaker, it would be
> enough... I will keep you in touch of my progress here..
> 
> But, even if the jobs takes 2 or 3 hours to vote, I think it would be a
> real huge gain for the tripleo work.

Today we use 8vCPU 8GB RAM, 80GB HDD our nodepool nodes. Obviously how the job
performs is subjective to which cloud it is one.

With that said, it might be worth moving these tests into 3rd party CI where
more powerful servers would live.  Even though tripleo jobs upstream today
support 3 hour 10 minutes as the time out, some of our longest running jobs.

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

2016-09-09 Thread Cody Herriges

On September 9, 2016 at 10:15:09 AM, Emilien Macchi (emil...@redhat.com) wrote:
On Fri, Sep 9, 2016 at 1:12 PM, Cody Herriges  wrote: 
> On September 9, 2016 at 9:08:56 AM, Emilien Macchi (emil...@redhat.com) 
> wrote: 
> 
> Hi, 
> 
> I wrote a little blog post about the last cycle in PuppetOpenStack: 
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/ 
> 
> I can't describe how much I liked to be PTL during the last 18 months 
> and I wouldn't imagine we would be where we are today when I started 
> to contribute on this project. 
> Working on it is something I really enjoy because we have interactions 
> with all OpenStack community and I can't live without it. 
> 
> However, I think it's time to pass the PTL torch for Ocata cycle. 
> Don't worry, I'll still be around and bother you when CI is broken ;-) 
> 
> Again, a big thank you for those who work with me, 
> 
> 
> Truly indebted to you for all your great work and progress you've driven 
> forward in OpenStack and Puppet over your many years of participation in 
> both communities. Looking forward to continuing to work with you in any role 
> you choose to take going forward. 

Thanks Cody! I also appreciate the close collaboration between 
OpenStack and Puppetlabs. Let's continue that way. 
There is no change in my work, I just don't want to be the next PTL, 
I'll keep working on the modules and TripleO, really no change except 
the PTL thing :-) 
I totally meant the role you take going forward while working on OpenStack and 
Puppet. :)

Will try my best to keep you from going anywhere.


-- 
Cody Herriges__
OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA

2016-09-09 Thread Shamail



> On Sep 9, 2016, at 12:38 PM, Jeremy Stanley  wrote:
> 
>> On 2016-09-09 11:06:21 -0500 (-0500), Tom Fifield wrote:
>> https://review.openstack.org/#/c/368114/
> [...]
> 
> Thanks! I had already written almost the exact same change, applied
> it in production and tested it with a non-admin account to make sure
> that when the account didn't have verified user checked it got
> presented a captcha but saw no captcha after checking verified in
> the account permissions. Hopefully this makes things more convenient
> for everyone
+1, thanks for enabling this Jeremy and Tom!
> -- 
> 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

[openstack-dev] [nova] Seeking info on PCI Passthrough scheduling

2016-09-09 Thread Carlton, Paul (Cloud Services)

Hi


I'm investigating a issue raised by our QA team and trying to locate the 
documentation or specifications that describe how

instances that use PCI-PT devices get scheduled.  I'm trying to understand what 
the expected behavior is when scheduling

an instance that used a port associated with a pci device and a flavor that 
defines numa and cpu requirements etc.


Thanks







Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard Enterprise
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Office: +44 (0) 1173 162189
Mobile:+44 (0)7768 994283
Email:paul.carl...@hpe.com
Hewlett-Packard Enterprise Limited registered Office: Cain Road, Bracknell, 
Berks RG12 1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error, you should 
delete it from your system immediately and advise the sender. To any recipient 
of this message within HP, unless otherwise stated you should consider this 
message and attachments as "HP CONFIDENTIAL".

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

On Fri, Sep 9, 2016 at 1:12 PM, Cody Herriges  wrote:
> On September 9, 2016 at 9:08:56 AM, Emilien Macchi (emil...@redhat.com)
> wrote:
>
> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
>
>
> Truly indebted to you for all your great work and progress you've driven
> forward in OpenStack and Puppet over your many years of participation in
> both communities. Looking forward to continuing to work with you in any role
> you choose to take going forward.

Thanks Cody! I also appreciate the close collaboration between
OpenStack and Puppetlabs. Let's continue that way.
There is no change in my work, I just don't want to be the next PTL,
I'll keep working on the modules and TripleO, really no change except
the PTL thing :-)

> --
> Cody Herriges



-- 
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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Cody Herriges

On September 9, 2016 at 9:08:56 AM, Emilien Macchi (emil...@redhat.com) wrote:

Hi,  

I wrote a little blog post about the last cycle in PuppetOpenStack:  
http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/  

I can't describe how much I liked to be PTL during the last 18 months  
and I wouldn't imagine we would be where we are today when I started  
to contribute on this project.  
Working on it is something I really enjoy because we have interactions  
with all OpenStack community and I can't live without it.  

However, I think it's time to pass the PTL torch for Ocata cycle.  
Don't worry, I'll still be around and bother you when CI is broken ;-)  

Again, a big thank you for those who work with me,  


Truly indebted to you for all your great work and progress you've driven 
forward in OpenStack and Puppet over your many years of participation in both 
communities. Looking forward to continuing to work with you in any role you 
choose to take going forward.

-- 
Cody Herriges__
OpenStack Development Mailing 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] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Jay Pipes


On 09/09/2016 06:22 AM, John Davidge wrote:

Thierry Carrez wrote:


[...]
In the last years there were a lot of "questions" asked by random
contributors, especially around the "One OpenStack" principle (which
seems to fuel most of the reaction here). Remarks like "we should really
decide once and for all if OpenStack is a collection of independent
projects, or one thing".

A lot of people actually ignore that this question was already asked,
pretty early on (by John Dickinson in June 2011). Back then it was
settled by the PPB (the ancestor to the TC). You can read it all
here[1]. It was never brought again as a proposed change to the TC, so
that decision from June 2011 is still defining how we should think about
OpenStack.

Most of the TC members know the governance history and know those
principles. That is, after all, one of the reasons you elect them for.
But we realized that the people asking those questions again and again
were not at fault. It was our failure to *document* this history
properly which caused the issue. Took us some time to gather the courage
to write it, then finally Monty wrote a draft, and I turned it into a
change.


To provide a counter point, I think the reason this question is asked so
often is not because the TC has failed to *document* this policy, but that
it has failed to *comply* with it.


The TC doesn't comply with anything at all. It's the body that is 
elected to make overarching governance decisions for the OpenStack 
community.



I¹m of course referring to the introduction of The Big Tent.


And I'm of course going to correct your misstatements below about what 
the Big Tent (formally called the Project Structure Reform) was about.


> This is the

moment that OpenStack stopped being: ³A single product made of a lot of
independent, but cooperating, components.² And became: ³A collection of
independent projects that work together for some level of integration and
releases.²


You are mistaken, I'm sorry to say.

Firstly, your statement that OpenStack stopped being "a single product" 
at some point is just flat-out wrong. It never *was* a single product, 
regardless of whether some time in 2011 seven individuals on the project 
policy board said that that was the direction they preferred the 
community to go in.


OpenStack was never a single product made of a lot of independent but 
cooperating components. From the very beginning of OpenStack-time, Swift 
and Nova were never designed or planned as a single product. To this 
*day*, Swift is its own product with very few pieces of integration with 
some other OpenStack projects where relevant (Keystone) but there was 
never any push or reason to have Swift become simply a "part of a single 
OpenStack product".


Secondly, the Big Tent was about changing the process by which new 
projects applying to become "OpenStack projects" were evaluated by the 
TC. We went from a situation of evaluating new projects using 
subjective, often contradicting and changing opinions on architectural 
and software design to instead evaluating new project teams on whether 
the project team followed "The OpenStack Way" (followed the 4 Opens and 
furthered the mission of OpenStack)


The Big Tent **was not a redefinition of what OpenStack was or is**.


This is in direct contradiction to the stated and collectively understood
goal of the project, and has left many scratching their heads.


I don't know what you are referring to above as "the stated and 
collectively understood goal of the project". Are you referring to the 
OpenStack Mission Statement? If so, see point above. The Big Tent didn't 
change the Mission nor did it redefine what OpenStack was.



The principles as written in the review do not accurately describe the
current state of the project. To make it so that they do, we either need
to change the principles or change the project. As I see it, our options
are:

1. Adjust the project to reflect the principles by abolishing The Big Tent.
2. Adjust the principles to reflect the project by redefining it as: ³A
collection of independent projects that work together for some level of
integration and releases.²

Personally, my vote is for option 1.


Sounds to me like you are just complaining about OpenStack having too 
many projects in it. If so, please tell us which projects you would have 
leave OpenStack.


No more deployment projects? Cut Triple-O, Fuel, Puppet, Chef, Ansible, 
Saltstack, devstack.


No more competing implementations of things? Cut Ceilometer or Monasca. 
Your choice.


No more Telco-specific stuff? Cut Tacker, networking-sfc, and a whole 
host of other stuff.


My vote is definitely for something #2-like, as I've said before and on 
the review, I believe OpenStack should be a "cloud toolkit" composed of 
well-scoped and limited services in the vein of the UNIX model of do one 
thing and do it well. I believe that vendors and cloud providers should 
be able to choose services and tools from this OpenStack cloud

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Javier Pena

Emilien, you've done an awesome job, thanks a lot!

Javier

- Original Message -
> Hi,
> 
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
> 
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
> 
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
> 
> Again, a big thank you for those who work with me,
> --
> 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
> 

__
OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA

2016-09-09 Thread Hayes, Graham

On 09/09/2016 08:44, Tom Fifield wrote:
>
>
> On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:
>> On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
>>> Is it just me who likes to hit the save button often?
>>> It gets tedious proving often that you are not a robot. Wiki
>>> reCAPTCHA likes proof even if saves are spaced less than a minute
>>> apart!
>>> Wiki Gods, hear my plea!
>>
>> I sympathize. That captcha addition is one of several tools we're
>> leveraging currently to combat the ongoing spam/scammer/vandalism
>> problems on wiki.openstack.org, as an alternative to shutting it
>> down completely. Unfortunately even now I still spend a chunk of
>> every day blocking new accounts created by abusers and cleaning up
>> all their modifications, but am hoping that with other improvements
>> we have pending the onslaught will lessen and we can revisit some of
>> the more intrusive mechanisms on which we've been forced to rely
>> (for example, I think we should be able to configure it so that
>> users whose previous edits have been confirmed by a wiki admin are
>> added to a group that bypasses the captcha, and then get a team of
>> wiki groomers in the habit of adding known good accounts to that
>> group).
>>
>
> Indeed - fungi has been doing amazing work :(
>
> I have been adding "known good" accounts to such a group - there's about
> 64 so far:
>
> https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol

How would someone get in said list?

>
> Is it possible to disable CAPTCHA for users in group "autopatrol"?
>
> __
> OpenStack Development Mailing 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 PTL non-candidacy

2016-09-09 Thread David Moreau Simard

Thanks for your hard and passionate work.

Keep on rocking.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Fri, Sep 9, 2016 at 12:05 PM, Emilien Macchi  wrote:
> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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

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

2016-09-09 Thread Colleen Murphy

Emilien,

Thank you so much for your incredible work on this project. The deployment
tools and OpenStack itself is in a better state because of your work. I'm
glad to work with you and call you a friend.

Colleen

On Fri, Sep 9, 2016 at 9:05 AM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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
>
__
OpenStack Development Mailing 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 PTL non-candidacy

2016-09-09 Thread Matt Fischer

On Fri, Sep 9, 2016 at 10:05 AM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> Emilien Macchi
>

Emilien,

It's been a pleasure collaborating with you and learning from you for the
past 18 months. As others have said the puppet modules are in such better
shape now thanks to your leadership and focus.

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

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Steve Martinelli

Thanks for your leadership, dedication and hard work over the last 18
months. I've always enjoyed working with you to resolve the gate failures
(despite being a cause of said failures :] )


On Fri, Sep 9, 2016 at 12:05 PM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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
>
__
OpenStack Development Mailing 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] what's up in upgrades?

2016-09-09 Thread Ben Nemec

On 09/08/2016 01:27 PM, Emilien Macchi wrote:

What's up in upgrades?

1) Undercloud: Mitaka to Newton

We just approved a patch in openstack-infra/tripleo-ci that test
undercloud upgrades.
I don't think we should make it vote as for now it's quite
experimental. Though I'm wondering if we should move it to the check
pipeline as non-voting (currently in experimental queue).

This is a first iteration and if you plan to upgrade your undercloud,
you'll still have to do manual steps that we do in tripleo-ci. They
are described here:
https://github.com/openstack-infra/tripleo-ci/blob/41e8560cf3d313f2be69df64e4c95a3240dfa402/scripts/tripleo.sh#L554-L577

We need to decide where to put these bits: in tripleoclient? in
instack-undercloud? Let's talk about it.

I think we already did:
https://specs.openstack.org/openstack/tripleo-specs/specs/newton/undercloud-upgrade.html

There are details about where various bits of the implementation should
live because it turns out that is pretty fundamental to the design of
the upgrade process.

2) Overcloud: Mitaka to Newton

matbu and myself are working together on a CI job that will test the
upgrade of an undercloud + overcloud from Mitaka to Newton.
Work is here: https://review.openstack.org/#/c/364859 and
https://review.openstack.org/#/c/323750/ (both patches are going to
merge together so we have one single patch for review).
The idea is to use multinode job for now as a first iteration, with
the simplest scenario possible so we can easily iterate later.

3) Overcloud: Newton to Newton
I'm working on a simple patch that would test updates from Newton to
Newton: https://review.openstack.org/#/c/351330/ like we had with OVB
jobs but this time using multinode.

Any feedback, help, is highly welcome.

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

2016-09-09 Thread Tim Bell



Emilien,

Thanks for all your hard work in this area. 

You may not know how many happy consumers of the OpenStack Puppet project there 
are because we’re quiet until you decide to step down.

Tim

On 09/09/16 18:05, "Emilien Macchi"  wrote:

Hi,

I wrote a little blog post about the last cycle in PuppetOpenStack:
http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/

I can't describe how much I liked to be PTL during the last 18 months
and I wouldn't imagine we would be where we are today when I started
to contribute on this project.
Working on it is something I really enjoy because we have interactions
with all OpenStack community and I can't live without it.

However, I think it's time to pass the PTL torch for Ocata cycle.
Don't worry, I'll still be around and bother you when CI is broken ;-)

Again, a big thank you for those who work with me,
-- 
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



__
OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA

On 2016-09-09 11:06:21 -0500 (-0500), Tom Fifield wrote:
> https://review.openstack.org/#/c/368114/
[...]

Thanks! I had already written almost the exact same change, applied
it in production and tested it with a non-admin account to make sure
that when the account didn't have verified user checked it got
presented a captcha but saw no captcha after checking verified in
the account permissions. Hopefully this makes things more convenient
for everyone.
-- 
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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Iury Gregory

Thank you very much for your work in the last 3 cycles! You rock :D

2016-09-09 13:29 GMT-03:00 Emilien Macchi :

> On Fri, Sep 9, 2016 at 12:15 PM, gordon chung  wrote:
> > mec, great work trying to make the stuff we build work and telling us to
> > make it less broken.
> >
> > so we play ping pong now?
>
> not really: https://review.openstack.org/#/c/367386/
>
> > On 09/09/16 12:05 PM, Emilien Macchi wrote:
> >> Hi,
> >>
> >> I wrote a little blog post about the last cycle in PuppetOpenStack:
> >> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
> >>
> >> I can't describe how much I liked to be PTL during the last 18 months
> >> and I wouldn't imagine we would be where we are today when I started
> >> to contribute on this project.
> >> Working on it is something I really enjoy because we have interactions
> >> with all OpenStack community and I can't live without it.
> >>
> >> However, I think it's time to pass the PTL torch for Ocata cycle.
> >> Don't worry, I'll still be around and bother you when CI is broken ;-)
> >>
> >> Again, a big thank you for those who work with me,
> >>
> >
> > --
> > 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
>
>
>
> --
> 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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Benjamin Kero

Thanks for all your hard work and contributions, making the
Puppet-OpenStack project mature and interesting. I look forward to continue
contributing to it with you!

Ben

On Fri, Sep 9, 2016 at 9:05 AM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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
>
__
OpenStack Development Mailing 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 PTL non-candidacy

On Fri, Sep 9, 2016 at 12:15 PM, gordon chung  wrote:
> mec, great work trying to make the stuff we build work and telling us to
> make it less broken.
>
> so we play ping pong now?

not really: https://review.openstack.org/#/c/367386/

> On 09/09/16 12:05 PM, Emilien Macchi wrote:
>> Hi,
>>
>> I wrote a little blog post about the last cycle in PuppetOpenStack:
>> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>>
>> I can't describe how much I liked to be PTL during the last 18 months
>> and I wouldn't imagine we would be where we are today when I started
>> to contribute on this project.
>> Working on it is something I really enjoy because we have interactions
>> with all OpenStack community and I can't live without it.
>>
>> However, I think it's time to pass the PTL torch for Ocata cycle.
>> Don't worry, I'll still be around and bother you when CI is broken ;-)
>>
>> Again, a big thank you for those who work with me,
>>
>
> --
> 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



-- 
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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Clayton O'Neill

On Fri, Sep 9, 2016 at 12:05 PM, Emilien Macchi  wrote:
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,

I think it’s impossible to overstate how much the Puppet modules for
Openstack have improved over the past 18 months.  Thank you for all
hard work and long hours you’ve put in to help get them 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] [puppet] Puppet OpenStack PTL non-candidacy

On Fri, Sep 9, 2016 at 12:14 PM, Denis Egorenko  wrote:
> Hey Emilien,
>
> It was a big pleasure to work with you!
>
> Thank you for all your help! :) And good luck on your next project and
> activities!

I don't have any next project :-) I just think we should have a new
PTL this time.
Sorry, but I'll keep bother you for long time :-P

> 2016-09-09 19:05 GMT+03:00 Emilien Macchi :
>>
>> Hi,
>>
>> I wrote a little blog post about the last cycle in PuppetOpenStack:
>> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>>
>> I can't describe how much I liked to be PTL during the last 18 months
>> and I wouldn't imagine we would be where we are today when I started
>> to contribute on this project.
>> Working on it is something I really enjoy because we have interactions
>> with all OpenStack community and I can't live without it.
>>
>> However, I think it's time to pass the PTL torch for Ocata cycle.
>> Don't worry, I'll still be around and bother you when CI is broken ;-)
>>
>> Again, a big thank you for those who work with me,
>> --
>> 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
>
>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread Paul Belanger

On Fri, Sep 09, 2016 at 12:05:36PM -0400, Emilien Macchi wrote:
> Hi,
> 
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
> 
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
> 
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
> 
> Again, a big thank you for those who work with me,

Agreed, great work to you and the rest of the PuppetOpenStack team in the last
18month.

I enjoyed watch the CI coverage for the PuppetOpenStack team grow too.

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

2016-09-09 Thread Denis Egorenko

Hey Emilien,

It was a big pleasure to work with you!

Thank you for all your help! :) And good luck on your next project and
activities!

2016-09-09 19:05 GMT+03:00 Emilien Macchi :

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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
>



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

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

2016-09-09 Thread gordon chung

mec, great work trying to make the stuff we build work and telling us to 
make it less broken.

so we play ping pong now?

On 09/09/16 12:05 PM, Emilien Macchi wrote:
> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
>

-- 
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] [requirements][FFE] pymod2pkg 0.5.4

2016-09-09 Thread Matthew Thode

On 09/09/2016 05:26 AM, Dirk Müller wrote:
> Hi,
> 
> OpenStack RPM Packaging would like to update to pymod2pkg 0.5.4:
> 
> https://review.openstack.org/#/c/367388/
> 
> this package is only used by packaging (renderspec and rpm-packaging
> git repos) that are on a release-independent schedule (iirc we're
> tagged as never-release) and
> since we're packaging, we needed to wait until all the deps we depend
> on were released to finalize packaging and include the needed fixes.
> 
> it is bugfix only with no effect whatsoever on any of the OpenStack
> Newton deliverables as far as I can say.
> 
> Please approve,
> 
> Thanks,
> Dirk
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

I don't think this will impact and cause a rerelease for any project so
I'm fine with this.

-- 
-- Matthew Thode (prometheanfire)



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] [cinder] moving driver to open source

2016-09-09 Thread John Griffith

On Sep 9, 2016 08:26, "Ben Swartzlander"  wrote:
>
> On 09/08/2016 04:41 PM, Duncan Thomas wrote:
>>
>> On 8 September 2016 at 20:17, John Griffith > > wrote:
>>
>> On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley > > wrote:
>>
>>
>>
>>
>> 
>>
>> they should be able to simply install it and its free
dependencies
>> and get a working system that can communicate with "supported"
>> hardware without needing to also download and install separate
>> proprietary tools from the hardware vendor. It's not what we say
>> today, but it's what I personally feel like we *should* be
saying.
>>
>>
>> Your view on what you feel we *should* say, is exactly how I've
>> interpreted our position in previous discussions within the Cinder
>> project.  Perhaps I'm over reaching in my interpretation and that's
>> why this is so hotly debated when I do see it or voice my concerns
>> about it.
>>
>>
>> Despite the fact I've appeared to be slightly disagreeing with John in
>> the IRC discussion on this subject, you've summarised my concern very
>> well. I'm not convinced that these support tools need to be open source,
>> but they absolutely need to be licensed in such a way that distributions
>> can repackage them and freely distribute them. I'm not aware of any
>> tools currently required by cinder where this is not the case, but a few
>> of us are in the process of auditing this to make sure we understand the
>> situation before we clarify our rules.
>
>
> I don't agree with this stance. I think the Cinder (and OpenStack)
communities should be able to dictate what form driver take, including the
code and the license, but when we start to try to control what drivers are
allowed to talk to (over and API or CLI) then we are starting to
artificially limit what kinds of storage systems can integrate with
OpenStack.
>
> Storage systems take a wide variety of forms, including specialized
hardware systems, clusters of systems, pure software-based systems, open
source, closed source, and even other SDS abstraction layers. I don't see
the point is creating rules that specify what form a storage system has to
take if we are going to allow a driver for it. As long as the driver itself
and all of it's python dependencies are Apache licensed, we can do our job
of reviewing the code and fixing cinder-level bugs. Any other kind of
restrictions just limit customer choice and stifle competition.
>
I get it, like I said I realize that my view doesn't match others, and I
certainly seem to be in the minority.  I'm sure there's some things we can
hammer out and define clearly that makes everybody at least a 'little'
happy.

> Even if you don't agree with my stance, I see serious practical problems
with trying to define what it and is not permitted in terms of "support
tools". Is a proprietary binary that communicates with a physical
controller using a proprietary API a "support tool"? What if someone
creates a software-defined-storage system which is purely a proprietary
binary and nothing else?
>
> API proxies are also very hard to nail down. Is an API proxy with a
proprietary license not allowed? What if that proxy runs on the box itself?
What if it's a separate software package you have to install? I don't think
we can write a set of rules that won't accidentally exclude things we don't
want to exclude.
>
> -Ben Swartzlander
>
>> --
>> Duncan Thomas
>>
>>
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA


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


On 廿十六年九月九日 朝 10:51, Morgan Fainberg wrote:



On Fri, Sep 9, 2016 at 8:43 AM, Tom Fifield > wrote:



On 廿十六年九月九日 朝 10:41, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than
a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools
we're
leveraging currently to combat the ongoing
spam/scammer/vandalism
problems on wiki.openstack.org ,
as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and
cleaning up
all their modifications, but am hoping that with other
improvements
we have pending the onslaught will lessen and we can revisit
some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki
admin are
added to a group that bypasses the captcha, and then get a
team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group -
there's about
64 so far:


https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol





Is it possible to disable CAPTCHA for users in group "autopatrol"?


aha! It is indeed.

Adding

$wgGroupPermissions['autopatrol']['skipcaptcha'] = true;


will solve this annoyance for Malini and others


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

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



For what it's worth, the captcha is the reason I stopped using /
updating the wiki and was a driver for keystone to move to using
etherpad for the weekly meeting agenda instead.

--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-dev] [puppet] Puppet OpenStack PTL non-candidacy

Hi,

I wrote a little blog post about the last cycle in PuppetOpenStack:
http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/

I can't describe how much I liked to be PTL during the last 18 months
and I wouldn't imagine we would be where we are today when I started
to contribute on this project.
Working on it is something I really enjoy because we have interactions
with all OpenStack community and I can't live without it.

However, I think it's time to pass the PTL torch for Ocata cycle.
Don't worry, I'll still be around and bother you when CI is broken ;-)

Again, a big thank you for those who work with me,
-- 
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] Is this a bug in metadata proxy...

2016-09-09 Thread Paul Michali

Yeah, the setting for user was neutron. The setting for group was different
than the process that started up the proxy (which had user neutron and
group neutron). The review 161494, was it applied to Liberty?

I think in our case, DHCP agent only had dhcp ini file and not metadata ini
file, so it didn't have the user/group setting.

I was wondering if the user/group should be (only) set in a common config,
like neutron.conf, if it should be duplicated in dhcp and metadata config
files, or if the metadata ini should be added to the list of ini files,
when starting up the DHCP agent.

With the wrong config, I hit the access denied issue and had no info
indicating that is what has happened. Was wondering if there was any
protection against that misconfiguration case, or way to get an indication
of it.

P.S. Sorry, I didn't see your reply till now...

PCM


On Wed, Aug 31, 2016 at 10:36 AM ZZelle  wrote:

> Hi,
>
> Are you sure metadata_proxy_user==neutron?
>
> neutron-metadata-proxy must be able to connect to the metadata-agent
> socket and watchs its log files and neutron user should be able to do both
> with usual file permissions.
>
> Otherwise the metadata proxy is generally no more able to:
> - watch log[1] so you should set metadata_proxy_watch_log=False
> - connect to the metadata-agent because of socket permissions, so you
> should set metadata_proxy_socket_mode option[2] in order to let the
> metadata agent set the correct perms on metadata socket.
>
> If you provide metadata_proxy_user/group in l3/dhcp-agent and
> metadata-agent config then neutron should be able to deduce both
> metadata_proxy_watch_log and metadata_proxy_socket_mode values.
>
>
>
> [1] https://review.openstack.org/#/c/161494/
> [2] https://review.openstack.org/#/c/165115/
>
> Cédric/ZZelle
>
> On Wed, Aug 31, 2016 at 2:16 PM, Paul Michali  wrote:
>
>> Hi,
>>
>> I had seen something and was not sure if this was a subtle bug or not.
>>
>> I have a Liberty based openstack setup. The account that is setting up
>> processes was user=neutron, group=neutron, however the metadata_agent.ini
>> config file was set up for a different group. So there was a
>> metadata_proxy_user=neutron, and metadata_proxy_group=foo config setting.
>>
>> This ini file was used by the metadata agent process, but it was not
>> included in the DHCP agent process (not sure if I should have included the
>> metadata_agent.ini in the startup of DHCP or should have added these two
>> metadata proxy settings to neutron.conf, so that they were available to
>> DHCP).
>>
>> In any case, here is what I saw happen...
>>
>> I created a subnet (not using a router in this setup). It looks like DHCP
>> starts up the metadata agent proxy daemon) and the DHCP configuration is
>> used, which does NOT include the metadata_proxy_user/group, so the current
>> user's uid and gid are used (neutron/neutron) for the
>> metadata_proxy_user/group settings.
>>
>> The proxy calls drop_privileges(), which because the group is different,
>> the log file can no longer be accessed by the daemon. An OSError occurs
>> with permission denied on the log file for this process, and the process
>> exits without any indications.
>>
>> When I then try to use metadata services it fails (obviously). Looking,
>> we see that the metadata service is running (but the proxy is not, and I
>> don't see a way for an end user to check that - is there a way?).
>>
>> Looking in the proxy log, the initial startup messages are seen, showing
>> all the configuration settings, and then there is nothing more. No
>> indication that it is lowering privileges to run under some other
>> user/group, that there was a fatal error, or that it is working and ready
>> to process requests. Nothing more appears in the log, as it was working and
>> there were no metadata proxy requests occurring.
>>
>> I was only able to figure it out, by first checking to see if the proxy
>> was running, and then manually trying to start the proxy, using the command
>> line in the log, under a debugger, to find out that there was a permission
>> denied error.
>>
>> So, it is likely a misconfiguration error on the user's part, but it was
>> really hard to figure that out.
>>
>> Should/could we somehow indicate if there is an error lowering privs?
>>
>> Is there a (user) way to tell if proxy is running?
>>
>> Is there some documentation indicating that the proxy user/group settings
>> need to be available for both the metadata agent and for other agents that
>> may spawn the proxy (DHCP, L3)?
>>
>> Regards,
>>
>> PCM
>>
>>
>> __
>> OpenStack Development Mailing 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

Re: [openstack-dev] venting -- OpenStack wiki reCAPTCHA

2016-09-09 Thread Morgan Fainberg

On Fri, Sep 9, 2016 at 8:43 AM, Tom Fifield  wrote:

>
>
> On 廿十六年九月九日 朝 10:41, Tom Fifield wrote:
>
>>
>>
>> On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:
>>
>>> On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
>>>
 Is it just me who likes to hit the save button often?
 It gets tedious proving often that you are not a robot. Wiki
 reCAPTCHA likes proof even if saves are spaced less than a minute
 apart!
 Wiki Gods, hear my plea!

>>>
>>> I sympathize. That captcha addition is one of several tools we're
>>> leveraging currently to combat the ongoing spam/scammer/vandalism
>>> problems on wiki.openstack.org, as an alternative to shutting it
>>> down completely. Unfortunately even now I still spend a chunk of
>>> every day blocking new accounts created by abusers and cleaning up
>>> all their modifications, but am hoping that with other improvements
>>> we have pending the onslaught will lessen and we can revisit some of
>>> the more intrusive mechanisms on which we've been forced to rely
>>> (for example, I think we should be able to configure it so that
>>> users whose previous edits have been confirmed by a wiki admin are
>>> added to a group that bypasses the captcha, and then get a team of
>>> wiki groomers in the habit of adding known good accounts to that
>>> group).
>>>
>>>
>> Indeed - fungi has been doing amazing work :(
>>
>> I have been adding "known good" accounts to such a group - there's about
>> 64 so far:
>>
>> https://wiki.openstack.org/w/index.php?title=Special:ListUse
>> rs=autopatrol
>>
>>
>>
>> Is it possible to disable CAPTCHA for users in group "autopatrol"?
>>
>
> aha! It is indeed.
>
> Adding
>
> $wgGroupPermissions['autopatrol']['skipcaptcha'] = true;
>
>
> will solve this annoyance for Malini and others
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

For what it's worth, the captcha is the reason I stopped using / updating
the wiki and was a driver for keystone to move to using etherpad for the
weekly meeting agenda instead.

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

Re: [openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery

2016-09-09 Thread Michael Krotscheck

Hey there, Goutham, thanks for replying!

I don't dispute that the services are properly returning a list of
supported versions, if you request the root resource. So far, that works
wonderfully.

I'm speaking of the resource endpoint that an API client is given when it
queries the keystone service catalog. We have a dump of the devstack output
in our testing data here ->
http://git.openstack.org/cgit/openstack/js-openstack-lib/tree/test/unit/helpers/data/keystone.js#n392

As you can see, some services give us tenant ID, some give us version, some
give us the root resource - and there's no indication of why that is. Is it
fragile? Would removing the version from the nova URI in the catalog entry
itself cause other services to fail? One would think not, but if that's the
case why are the versions declared explicitly in the first place?

Michael Krotscheck

On Thu, Sep 8, 2016 at 10:15 AM Ravi, Goutham 
wrote:

> Hi Michael,
>
>
>
> We discussed this at the API-WG meeting today (occurs at 16:00 UTC on
> Thursdays, #openstack-meeting-3). A point regarding the ‘/’ endpoint and
> the versions response is made in the microversions guideline [1]
> .
> I was testing the services you mentioned (+ manila), the results from my
> environment are here [2].  Looks
> like none of the services require authentication to make a request to the
> bare endpoint. What am I missing? One thing to note is that you included
> the tenant ID and /v3 in case of cinder; why is that?
>
>
>
> When instantiating a client and performing version negotiation, you may
> have auth details; but looks like we have some consistency among all of the
> projects you mentioned to not require auth. Maybe we can add this to [1].
>
>
>
> Thanks,
>
> Goutham
>
>
>
> [1]
> https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
>
> [2] http://paste.openstack.org/show/569282/
>
>
>
>
>
> *From: *Michael Krotscheck 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, August 30, 2016 at 1:11 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [api] [devstack] [ocata] Consistent Endpoint
> Discovery
>
>
>
> Hey everyone - I have a little bit of a UX request for our API developers.
>
>
>
> For the last week or so, I've been working on building version negotiation
> logic for an OpenStack SDK. The process is pretty simple:
>
>
>
> 1- Read clouds.yaml for the keystone URL.
>
> 2- Query keystone for the service catalog.
>
> 3- Instantiate service instances for each discovered service.
>
> 4- Perform version negotiation on each service.
>
>
>
> The problem: the service endpoints registered in the catalog all behave
> just a little bit differently, which makes building consistent version
> negotiation a royal PITA. I've annotated the various behaviors from a
> default devstack configuration here:
> http://paste.openstack.org/show/564863/.
>
>
>
> In a perfect world, every endpoint would return the same type of resource
> - most likely the versions resource as described in the API WG
> Microversions spec. It would also be nice if version negotiation can happen
> without requiring authentication, the easiest path to which would be
> supporting the 'max_version' and 'min_version' fields in the root versions
> resource.
>
>
>
> Sadly, this is my last week before I'm no longer paid to contribute to the
> OpenStack community, so I can't take on the responsibility of proposing
> something of this magnitude as an Ocata goal with only my own free time to
> offer. Is there anyone willing to help push this forward?
>
>
>
> Michael
> __
> OpenStack Development Mailing 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] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Nikhil Komawar



On 9/9/16 11:32 AM, Thierry Carrez wrote:
> Thierry Carrez wrote:
>> [...]
>> One interesting side-effect is that since the timing of the election
>> period (for PTL and TC positions) is defined in the TC charter[3]
>> relative to the *Summit*, it means that (unless we change this) we'll
>> now run elections to renew PTL and TC positions in the middle of the
>> cycle. Crazy, right ? That's what I first thought. But after discussing
>> it with various people, this is not as crazy as it sounds.
>> [...]
> Oh. Wait. *Some* of the wording in the charter actually mentions "design
> summit" -- since that's dissolved into two events, we kind of need to to
> alter the wording there anyway. There is no status quo.
>
> So we'll have to discuss whether it's better to define our next PTL/TC
> elections relative to the PTG (happening Feb 20-24, 2017) or to the
> Summit (happening May 8-12, 2017), or to something completely different
> (like the release date).
>
> I still think it's simpler to run relative to Summit (so that the PTLs
> running for election in the coming days will have a normal 6-month
> term), but the other solution would work too.
>
> Personally I care about having a point person to handle a release cycle
> from the preparation stages (months before the PTG) to the post-release
> stage (months after release). I don't care as much about exactly when
> the name of the person holding the PTL title (may) change... since there


"""
> is no perfect timing for that, you're always in the middle of something.
>
"""

"no perfect timing..." this can go in as thought of the day and I will
acknowledge +1000 to it.

-- 

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] venting -- OpenStack wiki reCAPTCHA




On 廿十六年九月九日 朝 10:41, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol



Is it possible to disable CAPTCHA for users in group "autopatrol"?


aha! It is indeed.

Adding

$wgGroupPermissions['autopatrol']['skipcaptcha'] = true;


will solve this annoyance for Malini and others

__
OpenStack Development Mailing 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] venting -- OpenStack wiki reCAPTCHA




On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about 
64 so far:


https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
OpenStack Development Mailing 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] [tripleo] tripleo-test-cloud-rh1 and bastion host

2016-09-09 Thread Paul Belanger

Greetings,

I would like to start the discussions around the removal of the bastion host
that sits in front of tripleo-test-cloud-rh1.  It is my understanding, all
traffic from tripleo-test-cloud-rh1 flows through this linux box.  Obviously
this is problematic for a public cloud.

I currently do not know the history of the bastion host, I am hoping this thread
will start discussions around it.

However, my personal preference is to remove the bastion from the pipeline
between internet and tripleo-test-cloud-rh1. My main objection to the host, is
the fact we do packet filtering of traffic flowing between the internet and
tripleo-test-cloud-rh1.

Ideally tripleo-test-cloud-rh1 will simply have an unfiltered network drop on
the public web, this is how we do it today with the infracloud in
#openstack-infra.

This will avoid the need to gain access to a private server (bastion) and need
to manipulate networking traffic.

I'd like for us to try and establish a time frame to make this happen too.

---
Paul

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

Thierry Carrez wrote:
> [...]
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and TC positions in the middle of the
> cycle. Crazy, right ? That's what I first thought. But after discussing
> it with various people, this is not as crazy as it sounds.
> [...]

Oh. Wait. *Some* of the wording in the charter actually mentions "design
summit" -- since that's dissolved into two events, we kind of need to to
alter the wording there anyway. There is no status quo.

So we'll have to discuss whether it's better to define our next PTL/TC
elections relative to the PTG (happening Feb 20-24, 2017) or to the
Summit (happening May 8-12, 2017), or to something completely different
(like the release date).

I still think it's simpler to run relative to Summit (so that the PTLs
running for election in the coming days will have a normal 6-month
term), but the other solution would work too.

Personally I care about having a point person to handle a release cycle
from the preparation stages (months before the PTG) to the post-release
stage (months after release). I don't care as much about exactly when
the name of the person holding the PTL title (may) change... since there
is no perfect timing for that, you're always in the middle of something.

-- 
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] [TripleO] Network Template Generator

2016-09-09 Thread Liz Blanchard

On Wed, Aug 10, 2016 at 7:10 PM, Ben Nemec  wrote:

> On 08/10/2016 11:05 AM, Liz Blanchard wrote:
> >
> >
> > On Wed, Aug 10, 2016 at 11:52 AM, Ben Nemec  > > wrote:
> >
> > On 08/08/2016 09:22 PM, Dan Prince wrote:
> > > On Mon, 2016-08-08 at 15:42 -0500, Ben Nemec wrote:
> > >> This is something that has existed for a while, but I had been
> > >> hesitant
> > >> to evangelize it until it was a little more proven.  At this point
> > >> I've
> > >> used it to generate templates for a number of different
> environments,
> > >> and it has worked well.  I decided it was time to record another
> demo
> > >> and throw it out there for the broader community to look at.  See
> > >> details on my blog:
> > >> http://blog.nemebean.com/content/tripleo-network-isolation-t
> emplate-g  template-g>
> > >> enerator
> > >>
> > >> Most of what you need to know is either there or in the video
> itself.
> > >> Let me know what you think.
> > >
> > > Very cool. For those that don't like "hand cutting" their own
> network
> > > configuration templates this is a good CLI based generator.
> > >
> > > Like you mention it would be nice to eventually converge this tool
> > > somehow into both the UI and CLI but given that it works with older
> > > releases as well it makes sense that it is CLI only for now.
> >
> > Yeah, my assumption is that at some point the UI will have similar
> > functionality.  Ideally the UI would replace this entirely, but I
> > suspect that's a ways off and we'll have to see how it plays out for
> > people doing CLI installs.
> >
> >
> > Speaking of which...I'd love to work closely with you, Ben, to put
> > together a wireframe design for the TripleO UI to support something like
> > what you've done here. It looks awesome and I'd love to understand the
> > use cases a bit more and how it might work into the current UI flow.
> >
> > I do have a first draft of a design that allows for some network
> > configuration that I'd love to get folks thoughts on:
> > https://invis.io/UM87J4NBQ
> >
> > Of course, as you mention, this would be something that is looking into
> > the future for the UI but it would be awesome to start now with
> > wireframes :)
>
> Sure, I'm happy to provide whatever input I can.  We'll probably want to
> include Dan Sneddon in those discussions as well.  He had a lot of good
> feedback on the early versions of this tool.
>
> In general, I'm pretty happy with how the tool's UI works.  The one big
> thing missing is an overview diagram of what's been configured.  The
> multi-pane layout keeps the view simple since you can only drill down
> one path at a time, but it does make it hard to see the big picture
> sometimes.  I think I actually saw a mockup of a network visualization
> you had done a while back that would potentially have filled this gap
> nicely.
>
> I'm not really a web UI developer (and I'm pointedly not looking at
> http://ucw-bnemec.rhcloud.com/ ;-) so I don't know how everything in my
> tool will map to that, but I could probably write up some user stories
> that I was trying to address.  I can also tell you what I specifically
> did not intend to support, because I lost some time designing for stuff
> that Dan ultimately told me we didn't need to worry about.
>
> I'm out on PTO next week, so it may be after that before I have a chance
> to follow-up, but I'll add it to the TODO list. :-)
>

Ben,

I hope you had a good PTO. Sorry it's taken me a little while to follow up,
but I wanted to share some ideas I've put together around translating the
tool you've built into some UI components within the TripleO UI. If you
have some time check out the workflow I've started around Network
Configuration:
https://openstack.invisionapp.com/share/UM87J4NBQ

Specifically pages 8-11 show how a user could view and edit Network
Isolation configuration options as you've allowed in the tool you wrote.

This is still an early draft so please feel free to make any comments or
suggestions on how to change and improve this for users :)

Thanks,
Liz


>
> >
> > Thanks for sharing this,
> > Liz
> >
> >
> >
> > >
> > > Dan
> > >
> > >>
> > >> Thanks.
> > >>
> > >> -Ben
> > >>
> > >> 
> _
> > >> _
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > 
> > >> cribe
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> >
> >

Re: [openstack-dev] [cinder] moving driver to open source

2016-09-09 Thread Duncan Thomas

On 9 September 2016 at 17:22, Ben Swartzlander  wrote:

On 09/08/2016 04:41 PM, Duncan Thomas wrote:
>


> Despite the fact I've appeared to be slightly disagreeing with John in
>> the IRC discussion on this subject, you've summarised my concern very
>> well. I'm not convinced that these support tools need to be open source,
>> but they absolutely need to be licensed in such a way that distributions
>> can repackage them and freely distribute them. I'm not aware of any
>> tools currently required by cinder where this is not the case, but a few
>> of us are in the process of auditing this to make sure we understand the
>> situation before we clarify our rules.
>>
>
> I don't agree with this stance. I think the Cinder (and OpenStack)
> communities should be able to dictate what form driver take, including the
> code and the license, but when we start to try to control what drivers are
> allowed to talk to (over and API or CLI) then we are starting to
> artificially limit what kinds of storage systems can integrate with
> OpenStack.
>
> Storage systems take a wide variety of forms, including specialized
> hardware systems, clusters of systems, pure software-based systems, open
> source, closed source, and even other SDS abstraction layers. I don't see
> the point is creating rules that specify what form a storage system has to
> take if we are going to allow a driver for it. As long as the driver itself
> and all of it's python dependencies are Apache licensed, we can do our job
> of reviewing the code and fixing cinder-level bugs. Any other kind of
> restrictions just limit customer choice and stifle competition.
>
> Even if you don't agree with my stance, I see serious practical problems
> with trying to define what it and is not permitted in terms of "support
> tools". Is a proprietary binary that communicates with a physical
> controller using a proprietary API a "support tool"? What if someone
> creates a software-defined-storage system which is purely a proprietary
> binary and nothing else?
>
> API proxies are also very hard to nail down. Is an API proxy with a
> proprietary license not allowed? What if that proxy runs on the box itself?
> What if it's a separate software package you have to install? I don't think
> we can write a set of rules that won't accidentally exclude things we don't
> want to exclude.


So my issue is not with any of those things, it is that I believe anybody
should be able to put together a distribution of openstack, that just
works, which any supported backend, without needed to negotiate licensing
deals with vendors, and without having to have nasty hacks in their
installers that pull things down off the web on to cinder nodes to get
around licensing rules. That is one of the main 'opens' to me in openstack.

I don't care so much whether your CLI or API proxy in open or closed
source, but I really do care if I can create a distribution, even a novel
one, with that software in it, without hitting licensing issues. That is,
as I see it, a bare minimum - anything less than that and it does not
belong in the cinder source tree.


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

Re: [openstack-dev] [QA] [Ironic] [Tempest] Problem with paramiko on grenade

2016-09-09 Thread Dmitry Tantsur

On 09/09/2016 02:08 PM, Jim Rollenhagen wrote:

On Fri, Sep 9, 2016 at 7:32 AM, Dmitry Tantsur wrote:

On 09/08/2016 11:24 AM, Anton Arefiev wrote:

Hi folks!

We've ran into the problem with paramiko, similar to[1] in Inspector.
Our grenade job fails on TestNetworkBasicOps.test_network_basic_ops with
[2] or [3] in 90% cases.

Folks, we're close to the release, and this becomes critical. We don't
actually care much about this particular test, it's just imposed on us by
the way grenade and tempest are implemented. Is there a way to disable it,
so that we can at least release something?

We've merged a hack to ironic-inspector to prevent the offending test
from running, so it's no longer critical. Still, I'd love to see it
fixed properly.

Any hints are really appreciated.

Looks like reverting fix [4] solves the problem, at least grenade passed
few times with reverting patch. But it will back other problems, which
mentioned patch fixes. So we need to help with this.

Yeah, so far it seems like everything we do about this bit breaks somebody
:(

I think we should land the revert - the fix at [4] was fixing out of tree code
and problems not seen in upstream CI. With the release so close, and inspector's
gate dead in the water, I think we should revert it and find a better way to fix
the problem folks saw there.

I guess the real fix will be part of https://review.openstack.org/367478

// jim

Any suggestions are welcome.
Thanks in advance.

[1] https://bugs.launchpad.net/tempest/+bug/1615659
[2]

http://logs.openstack.org/79/358779/2/check/gate-grenade-dsvm-ironic-inspector/8b5c901/logs/grenade.sh.txt.gz#_2016-09-08_08_36_02_408
[3]

http://logs.openstack.org/95/352295/9/check/gate-grenade-dsvm-ironic-inspector/b6e3aa7/console.html#_2016-09-08_08_12_20_050120
[4] https://review.openstack.org/#/c/358610/

--
Best regards,
Anton Arefiev
Mirantis, Inc.

Re: [openstack-dev] [cinder] moving driver to open source

2016-09-09 Thread Ben Swartzlander


On 09/08/2016 04:41 PM, Duncan Thomas wrote:

On 8 September 2016 at 20:17, John Griffith > wrote:

On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley > wrote:






they should be able to simply install it and its free dependencies
and get a working system that can communicate with "supported"
hardware without needing to also download and install separate
proprietary tools from the hardware vendor. It's not what we say
today, but it's what I personally feel like we *should* be saying.


Your view on what you feel we *should* say, is exactly how I've
interpreted our position in previous discussions within the Cinder
project.  Perhaps I'm over reaching in my interpretation and that's
why this is so hotly debated when I do see it or voice my concerns
about it.


Despite the fact I've appeared to be slightly disagreeing with John in
the IRC discussion on this subject, you've summarised my concern very
well. I'm not convinced that these support tools need to be open source,
but they absolutely need to be licensed in such a way that distributions
can repackage them and freely distribute them. I'm not aware of any
tools currently required by cinder where this is not the case, but a few
of us are in the process of auditing this to make sure we understand the
situation before we clarify our rules.


I don't agree with this stance. I think the Cinder (and OpenStack) 
communities should be able to dictate what form driver take, including 
the code and the license, but when we start to try to control what 
drivers are allowed to talk to (over and API or CLI) then we are 
starting to artificially limit what kinds of storage systems can 
integrate with OpenStack.


Storage systems take a wide variety of forms, including specialized 
hardware systems, clusters of systems, pure software-based systems, open 
source, closed source, and even other SDS abstraction layers. I don't 
see the point is creating rules that specify what form a storage system 
has to take if we are going to allow a driver for it. As long as the 
driver itself and all of it's python dependencies are Apache licensed, 
we can do our job of reviewing the code and fixing cinder-level bugs. 
Any other kind of restrictions just limit customer choice and stifle 
competition.


Even if you don't agree with my stance, I see serious practical problems 
with trying to define what it and is not permitted in terms of "support 
tools". Is a proprietary binary that communicates with a physical 
controller using a proprietary API a "support tool"? What if someone 
creates a software-defined-storage system which is purely a proprietary 
binary and nothing else?


API proxies are also very hard to nail down. Is an API proxy with a 
proprietary license not allowed? What if that proxy runs on the box 
itself? What if it's a separate software package you have to install? I 
don't think we can write a set of rules that won't accidentally exclude 
things we don't want to exclude.


-Ben Swartzlander


--
Duncan Thomas


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




__
OpenStack Development Mailing 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] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Hongbin Lu



> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: September-09-16 8:19 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> On 08/09/16 18:41 +, Hongbin Lu wrote:
> >
> >
> >> -Original Message-
> >> From: Thierry Carrez [mailto:thie...@openstack.org]
> >> Sent: September-08-16 5:00 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> >> "Release stewards"
> >>
> >> Sean Dague wrote:
> >> > On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> >> >> Barrett, Carol L wrote:
> >> >>> From: Sean Dague [mailto:s...@dague.net]
> >>  I think another option would be to run the PTL election early,
> >>  but just don't have the turn over happen until the master
> >>  release
> >> opens
> >>  up. The current transition period is > > > actually quite short
> >>  as
> >> noted by the comments around how design summit planning happens.
> >> Having the PTL-next elected half way through the cycle, but having
> >> PTL current > still > own landing the current release actually
> >> provides a lot more transition time.
> >> 
> >>    -Sean
> >> >>>
> >> >>> I had a similar thought to Sean's, with a few changes. Why not
> >> >>> have
> >> a PTL own the release from start to finish, with the PTL for the
> next
> >> release getting elected as above. In this model, it would probably
> be
> >> advisable (or a guideline) that a PTL not run for 2 cycles in a row,
> >> because the work load would be unmanageable. This approach could
> help
> >> to grow a stronger leadership pipeline for each project and provide
> >> more opportunities for people in the team to grow their skills and
> >> take on leadership.
> >> >>
> >> >> The drawback of this approach is that it breaks the governance
> >> >> model around project teams. You need a "the buck stops here"
> >> >> person (even if that power is seldom used). But you can't have
> two
> >> >> -- what
> >> happens
> >> >> if they disagree ?
> >> >>
> >> >> So it's simpler to have a single PTL at all times and one or two
> >> >> release liaisons at all times. Could be the same person though.
> >> >
> >> > It doesn't give you 2 PTLs. It gives you PTL-next that gets to
> make
> >> > decisions on master once it opens up, and guides it until it's a
> >> > stable branch. It doesn't seem like it breaks anything to me.
> >>
> >> So... the difference between your proposal and mine is: you force
> the
> >> PTL to be the release steward (rather than having a choice there),
> >> and introduce a delay between election and start of authority for
> the PTL.
> >>
> >> I don't see that delay as a good thing. You would elect in April a
> >> PTL whose authority over the project would start in August. That
> >> sounds a bit weird to me. I'd rather say that the authority of the
> >> PTL starts when he is elected, and not introduce a delay.
> >
> >If the authority of the PTL starts in the middle of a cycle, what
> happen if the just-elected PTL disagree with what were planned by the
> previous PTL? Does the just-elected PTL have authority to override what
> were planned? For contributors, it is confusing to have two PTLs in one
> cycle. They might follow the instruction from one PTL to setup the plan
> for the whole cycle. Then, in the second half of the cycle, the new PTL
> give a totally different instruction for the same item. As a result,
> the plan needs to be changed or extra efforts are needed to ensure the
> new PTL agrees with the original plan. In this case, introducing
> "release stewards" doesn't solve the problem because this new role
> doesn't have final says.
> 
> I think you're pushing the role of the PTL a bit too far, or at least
> how PTLs should interact with the community. I've written about this in
> the past:

Maybe, but I was not arguing the role of the PTL. I was arguing it is confusing 
to have two PTLs in one cycle.

> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-
> September/073986.html
> 
> Flavio
> 
> >>
> >> I don't see *forcing* the PTL to be the release steward to be a good
> >> thing either. The just-elected PTL can totally be the release
> steward
> >> for the upcoming cycle -- actually, that is how my proposal would
> >> work by default: the PTL elected around Boston would be the default
> >> release steward for Q, and the PTL elected around Sydney would be
> the
> >> default release steward for R. But I'd rather allow for some
> >> flexibility here, in case the PTL prefers to delegate more of his
> >> work. I also think allowing for more leadership roles (rather than
> >> piling it all on the
> >> PTL) helps growing a stronger leadership pipeline.
> >>
> >> In summary, I see drawbacks to your variant, and I fail to see any
> >> benefits... Am I missing something ?
> >>
> >> --
> >> Thierry Carrez (ttx)
> >>
>

[openstack-dev] [neutron][stadium][release] Doing new stadium releases through openstack/releases only

2016-09-09 Thread Ihar Hrachyshka


Hi all,

Cathy noticed lately that networking-sfc 2.0.0 release did not trigger an  
announcement email. This was because the tag pushed did not contain some  
metadata required by the post-merge job:


http://logs.openstack.org/64/64eb217de2273cf3760b2f73967a77aed0346d96/release/networking-sfc-announce-release/ff7d533/console.html#_2016-09-06_14_08_34_257103

We discussed the matter briefly with Doug Hellmann, and he suggested that  
we stop pushing tags ourselves, instead relying on openstack/releases  
automation and global openstack release team to do the job. [Some time in  
the past, the global release team was reluctant to take the load, but now  
they seem to have the proper automation for release:independent projects in  
place.]


I don’t have any objection against doing all neutron releases through  
centralized means. So I proposed the following changes:


- https://review.openstack.org/#/c/368010/ to modify stadium release  
guidelines to exclude neutron-release team from pushing new tags;
- https://review.openstack.org/#/c/368012/ to remove push-tag ACLs from  
neutron-release team for all stadium repos.


I hope it’s ok with everyone,
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-dev] [new][oslo] oslo.db 4.13.3 release (newton)

2016-09-09 Thread no-reply

We are ecstatic to announce the release of:

oslo.db 4.13.3: Oslo Database library

This release is part of the newton stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

For more details, please see below.

Changes in oslo.db 4.13.2..4.13.3
-

13223e4 Add additional caution looking for table, info


Diffstat (except docs and test files)
-

oslo_db/sqlalchemy/utils.py| 21 +
2 files changed, 37 insertions(+), 9 deletions(-)




__
OpenStack Development Mailing 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] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Ihar Hrachyshka


Thierry Carrez  wrote:


Ihar Hrachyshka wrote:

[...]
I slightly disagree with enforcing another formal role to all teams. I
feel that we have enough of them (release liaison for one) to cover for
release cross-project work, and projects are free to set their teams
with more roles if needed.


You should probably re-read what I wrote, because there is no
"enforcement" at all. There is merely the added possibility for teams to
pick someone different for release liaison work per-cycle, so that the
person preparing the next cycle is not necessarily the same person who
works on completing the release. Quoting my original email: "some teams
[...] may want to use the same super-human to handle everything [...],
and some others might use two or three humans to spread the load”.


Well, unless you won’t request projects to designate someone specific for  
the role, you enforce it. But that’s not my main problem with the proposal,  
and I can live with another name assigned to release liaison, I am more  
concerned about switching the PTL that oversights the team in the middle of  
release cycle.





I somewhat disagree with attempt to document a single project team
hierarchy and impose, top to bottom, same roles on everyone irrespective
to project needs. I understand the need of some ‘liaison’ roles where
project decisions influence other projects, but I feel that now we get
into over-formalizing internal project structure. New roles in a team
should be generally driven by actual needs, from the bottom.


Define "bottom". The need for a release liaison comes from the Release
Management Team, just as the need for an Oslo liaison comes from the
Oslo team. In case this is not clear, the idea of having "release
stewards" comes from the Release Management Team. Quoting my original
email: "a sort of per-cycle release liaison on steroids”.


There is a significant difference between release liaison role defined to  
handle cross project work, and release steward defined for what seems to be  
purely internal project matters.





I very much disagree with the idea of switching PTL in midterm. I
believe in some cases this proposal will add unnecessary rivalry in
lives of projects.


Define "midterm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.


From where I came (neutron), it does not happen that way, but maybe we are  
just bad at handling release cycles? We have release cut-off as an  
opportunity to clean the slate and reconsider our direction for the next  
release. I don’t think introducing a structure that will allow for  
significant direction changes in the middle of the release cycle will be to  
the benefit of the project.


But having earlier elections for more smooth power transition would.

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

Re: [openstack-dev] [puppet] today was a bad day for CI

2016-09-09 Thread James Page

On Fri, 9 Sep 2016 at 01:17 Emilien Macchi  wrote:
[...]

> 3) Disable Ironic testing on Ubuntu. Packages are broken in recent
> Newton upgrade. They are working on it.
>

Ironic packaging issue fixed and released to newton-updates; that will
teach me to spend a morning tidying up old bugs :).

> 4) Enable br_netfilter kernel module on Ubuntu.
> See https://bugs.launchpad.net/cloud-archive/+bug/1621651
> Even if it's not critical, it's a nice-to-have because it removed the
> ERROR that we had in neutron logs. We'll see how the bug report evolve
> and maybe remove this workaround.
>

I've moved this to:

  https://bugs.launchpad.net/cloud-archive/+bug/1621854

as its a separate issue to the os-vif version problem (see below).

6) Disable linuxbridge on scenario003 for Ubuntu
> Also see https://bugs.launchpad.net/cloud-archive/+bug/1621651

os-vif updated to 1.2.1 and released to newton-updates; not detected by our
version checker as its was not in upper-constraints until recently.
__
OpenStack Development Mailing 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] governance proposal worth a visit: Write down OpenStack principles

2016-09-09 Thread Paul Dardeau

Re: "One OpenStack" product

Is vim, less, awk, sed, and emacs one product? Are the bolt and nut of same
size (and produced by same manufacturer) sitting in a hardware store a
single product? A vote or edict does not automatically make things one
product - it only conveys a desire. I would argue that OpenStack is closer
to being a single, very large toolkit (instead of a product) that can be
configured and used in many different ways. For those that do consider it a
single product -- have you tried watching someone brand new to OpenStack
try to roll it out (not devstack)? If you still consider it a product, what
are the competing products and how easy are they to use?

In my view, a 'product' has a certain level of integration and common-ness
about it (still vague, I know). Some may argue that a product is
indivisible (or not readily indivisible).

-paul

On Fri, Sep 9, 2016 at 5:22 AM, John Davidge 
wrote:

> Thierry Carrez wrote:
>
> >[...]
> >In the last years there were a lot of "questions" asked by random
> >contributors, especially around the "One OpenStack" principle (which
> >seems to fuel most of the reaction here). Remarks like "we should really
> >decide once and for all if OpenStack is a collection of independent
> >projects, or one thing".
> >
> >A lot of people actually ignore that this question was already asked,
> >pretty early on (by John Dickinson in June 2011). Back then it was
> >settled by the PPB (the ancestor to the TC). You can read it all
> >here[1]. It was never brought again as a proposed change to the TC, so
> >that decision from June 2011 is still defining how we should think about
> >OpenStack.
> >
> >Most of the TC members know the governance history and know those
> >principles. That is, after all, one of the reasons you elect them for.
> >But we realized that the people asking those questions again and again
> >were not at fault. It was our failure to *document* this history
> >properly which caused the issue. Took us some time to gather the courage
> >to write it, then finally Monty wrote a draft, and I turned it into a
> >change.
>
> To provide a counter point, I think the reason this question is asked so
> often is not because the TC has failed to *document* this policy, but that
> it has failed to *comply* with it.
>
> I¹m of course referring to the introduction of The Big Tent. This is the
> moment that OpenStack stopped being: ³A single product made of a lot of
> independent, but cooperating, components.² And became: ³A collection of
> independent projects that work together for some level of integration and
> releases.²
>
> This is in direct contradiction to the stated and collectively understood
> goal of the project, and has left many scratching their heads.
>
> The principles as written in the review do not accurately describe the
> current state of the project. To make it so that they do, we either need
> to change the principles or change the project. As I see it, our options
> are:
>
> 1. Adjust the project to reflect the principles by abolishing The Big Tent.
> 2. Adjust the principles to reflect the project by redefining it as: ³A
> collection of independent projects that work together for some level of
> integration and releases.²
>
> Personally, my vote is for option 1.
>
> John
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing 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] governance proposal worth a visit: Write down OpenStack principles


On 08/09/16 23:41 -0700, Joshua Harlow wrote:

Chris Dent wrote:


There's a governance proposal in progress at
https://review.openstack.org/#/c/357260/ that I think is worth a
visit by anyone interested in the definition and evolution of
OpenStack's identity and the processes and guidelines used in OpenStack.

I'm assuming that not everyone regularly cruises the governance
project so this thing, which is pretty important, has probably not
been seen yet by many community members. It is full of many
assertions, some probably controversial, about what OpenStack is and
what we get up to.

At the moment a lot of the reviews are obsessing over the details and
interpretations of various phrases and paragraphs. This is in
preparation for a later presentation to the community that ought to
engender a long email thread where we will discuss it and try to ratify.
I fear that discussion will also obsess over the details.

The ordering here is backwards from a process that could be happening if
what we want is effective engagement and a useful outcome (one where we
agree). We should first have a conversation about the general principles
that are desired, then capture those into a document and only then
obsess over the details. The current process will inevitably privilege
the existing text and thus the bias of the authors[1].

I presume that the process that is happening was chosen to avoid too
much bikeshedding. The issue with that is that the work we need to
do is stepping back a bit and concerning ourselves not with the color of
the shed, but with whether it is for bikes, or even a shed. Last we
talked about it, it was a tent, but there's no consensus that that is
going well.

[1] I don't wish to indicate that there's anything wrong (or right!)
about the current text, simply that it is a presentation of a few
authors, including some written in the past, not a summary of an open
discussion in the present day.


Thanks for starting this chris, and I do also find it a little odd, 
but on a slightly different aspect...


This one along with https://review.openstack.org/#/c/365590/ (and 
others that I don't know about?) make me wonder what is going on 
with/in certain TC folks heads (not in a bad way, but the thought 
processes that are spurring these documents to be generated). Why the 
sudden desire to write down principles and intents and 'community' 
beliefs all of a sudden when it has been about 5 (or is it 6 now) 
years since the community started.


I really think Monty explained the intentions well enough here[0] and Thierry's
reply to this email also provides great insights of what motivates these
changes.

In addition to their comments, I want to add that definitely one of the
strongest motivations (at least for me) is to understand which of these
principles are shared an which aren't. As you can see from that change I
proposed, not many folks agree with assuming good faith from people and I think
that's perfect, valid and we should respect that.

As one of the folks that have always brought up "assuming good faith" whenever
possible, I admit that I mistakenly (?) assumed that it was shared practice (?
sorry, my english couldn't come up with a better word here) and this patched
proved me wrong. I think this is great and it's made the time spent on this work
already useful.

Flavio

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103242.html

Is there something I'm missing that all of a sudden as the going gets 
tough for various companies using openstack (businesses getting merged 
into other businesses, some going back into private ownership...) and 
the big tent IMHO diluted what is openstack (I believe to dangerous 
levels) that all of a sudden it felt like a useful thing to spend time 
on beliefs or principles vs say like ummm, technical things (the T in 
TC) :-/


Just strikes at least myself, as sort of weird; and not exactly a 
thing I would realistically be worried about if I was in a technical 
committee position at the current time.


-Josh

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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

Ihar Hrachyshka wrote:
> [...]
> I slightly disagree with enforcing another formal role to all teams. I
> feel that we have enough of them (release liaison for one) to cover for
> release cross-project work, and projects are free to set their teams
> with more roles if needed.

You should probably re-read what I wrote, because there is no
"enforcement" at all. There is merely the added possibility for teams to
pick someone different for release liaison work per-cycle, so that the
person preparing the next cycle is not necessarily the same person who
works on completing the release. Quoting my original email: "some teams
[...] may want to use the same super-human to handle everything [...],
and some others might use two or three humans to spread the load".

> I somewhat disagree with attempt to document a single project team
> hierarchy and impose, top to bottom, same roles on everyone irrespective
> to project needs. I understand the need of some ‘liaison’ roles where
> project decisions influence other projects, but I feel that now we get
> into over-formalizing internal project structure. New roles in a team
> should be generally driven by actual needs, from the bottom.

Define "bottom". The need for a release liaison comes from the Release
Management Team, just as the need for an Oslo liaison comes from the
Oslo team. In case this is not clear, the idea of having "release
stewards" comes from the Release Management Team. Quoting my original
email: "a sort of per-cycle release liaison on steroids".

> I very much disagree with the idea of switching PTL in midterm. I
> believe in some cases this proposal will add unnecessary rivalry in
> lives of projects.

Define "midterm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.

-- 
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] governance proposal worth a visit: Write down OpenStack principles


On 09/09/16 10:22 +, John Davidge wrote:

Thierry Carrez wrote:


[...]
In the last years there were a lot of "questions" asked by random
contributors, especially around the "One OpenStack" principle (which
seems to fuel most of the reaction here). Remarks like "we should really
decide once and for all if OpenStack is a collection of independent
projects, or one thing".

A lot of people actually ignore that this question was already asked,
pretty early on (by John Dickinson in June 2011). Back then it was
settled by the PPB (the ancestor to the TC). You can read it all
here[1]. It was never brought again as a proposed change to the TC, so
that decision from June 2011 is still defining how we should think about
OpenStack.

Most of the TC members know the governance history and know those
principles. That is, after all, one of the reasons you elect them for.
But we realized that the people asking those questions again and again
were not at fault. It was our failure to *document* this history
properly which caused the issue. Took us some time to gather the courage
to write it, then finally Monty wrote a draft, and I turned it into a
change.


To provide a counter point, I think the reason this question is asked so
often is not because the TC has failed to *document* this policy, but that
it has failed to *comply* with it.

I¹m of course referring to the introduction of The Big Tent. This is the
moment that OpenStack stopped being: ³A single product made of a lot of
independent, but cooperating, components.² And became: ³A collection of
independent projects that work together for some level of integration and
releases.²

This is in direct contradiction to the stated and collectively understood
goal of the project, and has left many scratching their heads.

The principles as written in the review do not accurately describe the
current state of the project. To make it so that they do, we either need
to change the principles or change the project. As I see it, our options
are:

1. Adjust the project to reflect the principles by abolishing The Big Tent.
2. Adjust the principles to reflect the project by redefining it as: ³A
collection of independent projects that work together for some level of
integration and releases.²


I think #2 is missing a critical part, which is that these "independent"
projects are working towards a unified mission. This differentiates OpenStack
from many other communities out there and it helps understanding the principles
and other changes a bit better. But I might be biased here :/

Either way, writing down this principles has proven the effort useful already.
It doesn't matter if the outcome is a well thought-out document or a set of
changes to the community. The time spent writing this document is already
helping us to get rid of some tribal knowledge.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-09 Thread John Griffith

On Fri, Sep 9, 2016 at 2:42 AM, Thierry Carrez 
wrote:

> John Griffith wrote:
> > I think Sean Dague made some really good points and I'd tend to lean
> > that way.  Honestly charters, bylaws, governance etc shift or are
> > rewritten fairly often.  Why not just change when we do elections to
> > correspond with releases and keep the continuity that we have now.  Is
> > there a problem with the existing terms and cycles that maybe I'm
> missing?
>
> AFAICT this is not what Sean is proposing. He is saying that we should
> run elections in the weeks before Summit as usual, but the newly-elected
> PTL would /not/ take over the current PTL until 3 months later when the
> next development branches are opened.
>
Yes, which is a reasonable choice in my mind as well.  I was throwing out
there however that maybe this isn't that hard, maybe we could just move the
election date as well.



>
> While it's true that there are projects with a lot of continuity and
> succession planning, with the old PTL staying around after they have
> been replaced, there are also a fair share of projects where the PTL is
> replaced by election and either rage-quits or lowers their involvement
> significantly as a result. I'd rather have the /possibility/ to separate
> the PTL from the release steward role and ensure continuity.


> That doesn't prevent you from doing it Nova-style and use the PTL as the
> release steward. It just lets you use someone else if you want to. A bit
> like keeping a headphone jack. Options.
>
I see what you did there (and I like it).


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"


On 08/09/16 16:48 -0600, Doug Wiegley wrote:



On Sep 8, 2016, at 12:49 PM, Matt Riedemann  wrote:

On 9/8/2016 6:42 AM, Sean Dague wrote:

On 09/08/2016 05:00 AM, Thierry Carrez wrote:

Sean Dague wrote:



So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.

I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?


I can only bring my own experience from projects, which is to expose
projects to succession planning a bit earlier, but otherwise keep things
the same. Both with working in the QA team, and in Nova, usually the
standing PTL starts telling folks about half way through their final
term that they aren't going to run again. And there ends up being a
bunch of private team conversations to figure out who else is
interested. Often those folks need to clear some things off their plate.
So there is some completely private indication of who might be the next
PTL. However, nothing is made official, and no one wants to presume
until an actual election happens months later.

When succession planning doesn't go well, you get to nomination week,
and you find out the current PTL isn't running, and there are two days
of mad scramble trying to figure out who is going to run.

Forcing the PTL-next conversation back some amount of time means it
matches the way I've seen succession planning work in projects for the
best handoff.

I feel like projects and PTLs do already delegate the things they can
and want to. It's not clear to me that creating another title of release
steward is going to dramatically change that. Maybe it's an active
suggestion to delegate that role out? Or that another title helps
convince employers that someone needs to end up at the PTG?

I'm also not very concerned about delayed authority of the PTL. Peaceful
handoff should be a pretty basic tenant in projects. Knowing about it
for a longer time shouldn't be a big deal. If it causes giant strife to
pass the torch from one PTL to the next there is something else going
wrong in that project. In the few cases I'm familiar with in which a
standing PTL lost an election, the relationship between that PTL and the
PTL-next was fine.

Again, these are personal experiences from the projects I'm actively
involved with, or collaborate with the most.

-Sean



+1 to everything sdague said here.


Another +1 to sdague’s sentiments.

If a PTL wants to setup this kind of heirarchy, they are already free to do so. 
 (And in your proposal, if they want to not do it, they are free not to, so why 
codify it?)


This is true but not often known or even used. Sure, anyone is free to do
whatever they feel like. Some PTLs decide to do everything themselves, others
decide to delegate as much as possible. One other benefit of Thierry's proposal
is encouraging PTLs to delegate this bit of work, which is crucial. The proposal
does that by recognizing this role in the community (this is not to say other
liaison roles are not important) and by encouraging PTLs to help creating new
leaders in the community.

Again, this is one extra benefit but not the main motivation behind this change.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Ihar Hrachyshka


Thierry Carrez  wrote:


Rob Cresswell wrote:

I've been toying with send this email for a while, but here goes: this
all feels like overcomplication and changing of a system that doesn't
really need to change.


Except the proposal here is actually to not change anything, but I see
what you mean.



Maybe it does not change anything in formal wording, but it definitely  
changes dynamics in project teams. I feel like it’s better to change the  
wording than impose real life impact on developers. I was actually under  
(wrong?) impression that the split summit initiative was not supposed to  
influence how engineers do their work, but now I am quite surprized by  
where it’s leading us.



I've read the pros and cons, and I still can't really see a convincing
reason not to move the PTL election to just-before-PTG, so that the new
PTL is present for one development cycle as before.


Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.


Fine, just move the election a bit earlier, and give the new PTL to transit  
into the role naturally, having extended time to accommodate for the new  
role.


I agree the way it is done now (immediate power transition) is not ideal.  
In democracies, you usually have some time between elections and ascension  
to power. This time is taken so that the new person can learn the process,  
talk to the old PTL, close current affairs, participate in actual decisions  
for the next PTG already in the new role. I believe just holding elections  
a tad earlier (+3 weeks as of  now?) would be the best outcome.


I slightly disagree with enforcing another formal role to all teams. I feel  
that we have enough of them (release liaison for one) to cover for release  
cross-project work, and projects are free to set their teams with more  
roles if needed.


I somewhat disagree with attempt to document a single project team  
hierarchy and impose, top to bottom, same roles on everyone irrespective to  
project needs. I understand the need of some ‘liaison’ roles where project  
decisions influence other projects, but I feel that now we get into  
over-formalizing internal project structure. New roles in a team should be  
generally driven by actual needs, from the bottom.


I very much disagree with the idea of switching PTL in midterm. I believe  
in some cases this proposal will add unnecessary rivalry in lives of  
projects.


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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

On 08/09/16 18:41 +, Hongbin Lu wrote:

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: September-08-16 5:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections &
"Release stewards"

Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
>> Barrett, Carol L wrote:
>>> From: Sean Dague [mailto:s...@dague.net]
 I think another option would be to run the PTL election early, but
 just don't have the turn over happen until the master release
opens
 up. The current transition period is > > > actually quite short as
noted by the comments around how design summit planning happens. Having
the PTL-next elected half way through the cycle, but having PTL
current > still > own landing the current release actually provides a
lot more transition time.

-Sean
>>>
>>> I had a similar thought to Sean's, with a few changes. Why not have
a PTL own the release from start to finish, with the PTL for the next
release getting elected as above. In this model, it would probably be
advisable (or a guideline) that a PTL not run for 2 cycles in a row,
because the work load would be unmanageable. This approach could help
to grow a stronger leadership pipeline for each project and provide
more opportunities for people in the team to grow their skills and take
on leadership.
>>
>> The drawback of this approach is that it breaks the governance model
>> around project teams. You need a "the buck stops here" person (even
>> if that power is seldom used). But you can't have two -- what
happens
>> if they disagree ?
>>
>> So it's simpler to have a single PTL at all times and one or two
>> release liaisons at all times. Could be the same person though.
>
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a
> stable branch. It doesn't seem like it breaks anything to me.

So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.

If the authority of the PTL starts in the middle of a cycle, what happen if the 
just-elected PTL disagree with what were planned by the previous PTL? Does the 
just-elected PTL have authority to override what were planned? For contributors, it is 
confusing to have two PTLs in one cycle. They might follow the instruction from one PTL 
to setup the plan for the whole cycle. Then, in the second half of the cycle, the new PTL 
give a totally different instruction for the same item. As a result, the plan needs to be 
changed or extra efforts are needed to ensure the new PTL agrees with the original plan. 
In this case, introducing "release stewards" doesn't solve the problem because 
this new role doesn't have final says.

I think you're pushing the role of the PTL a bit too far, or at least how PTLs
should interact with the community. I've written about this in the past:

http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html

Flavio

I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?

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

--
@flaper87
Flavio Percoco

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

2016-09-09 Thread Rob Cresswell

This makes sense to me. I think I'm having a slow day and wasn't connecting the 
dots. Having the next PTL come in and immediately hear feedback and begin 
planning how to address it, rather than coming in shortly before the planning 
event without a feedback loop, sounds like a good move.

+1

Rob

On 9 September 2016 at 12:49, Thierry Carrez 
> wrote:
Rob Cresswell wrote:
> I've been toying with send this email for a while, but here goes: this
> all feels like overcomplication and changing of a system that doesn't
> really need to change.

Except the proposal here is actually to not change anything, but I see
what you mean.

> I've read the pros and cons, and I still can't really see a convincing
> reason not to move the PTL election to just-before-PTG, so that the new
> PTL is present for one development cycle as before.

Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.

Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.

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

Re: [openstack-dev] [QA] [Ironic] [Tempest] Problem with paramiko on grenade

2016-09-09 Thread Jim Rollenhagen

On Fri, Sep 9, 2016 at 7:32 AM, Dmitry Tantsur  wrote:
> On 09/08/2016 11:24 AM, Anton Arefiev wrote:
>>
>> Hi folks!
>>
>> We've ran into the problem with paramiko, similar to[1] in Inspector.
>> Our grenade job fails on TestNetworkBasicOps.test_network_basic_ops with
>> [2] or [3] in 90% cases.
>
>
> Folks, we're close to the release, and this becomes critical. We don't
> actually care much about this particular test, it's just imposed on us by
> the way grenade and tempest are implemented. Is there a way to disable it,
> so that we can at least release something?
>
> Any hints are really appreciated.
>
>>
>> Looks like reverting fix [4] solves the problem, at least grenade passed
>> few times with reverting patch. But it will back other problems, which
>> mentioned patch fixes. So we need to help with this.
>
>
> Yeah, so far it seems like everything we do about this bit breaks somebody
> :(

I think we should land the revert - the fix at [4] was fixing out of tree code
and problems not seen in upstream CI. With the release so close, and inspector's
gate dead in the water, I think we should revert it and find a better way to fix
the problem folks saw there.

// jim

>
>>
>> Any suggestions are welcome.
>> Thanks in advance.
>>
>> [1] https://bugs.launchpad.net/tempest/+bug/1615659
>> [2]
>>
>> http://logs.openstack.org/79/358779/2/check/gate-grenade-dsvm-ironic-inspector/8b5c901/logs/grenade.sh.txt.gz#_2016-09-08_08_36_02_408
>> [3]
>>
>> http://logs.openstack.org/95/352295/9/check/gate-grenade-dsvm-ironic-inspector/b6e3aa7/console.html#_2016-09-08_08_12_20_050120
>> [4] https://review.openstack.org/#/c/358610/
>>
>> --
>> Best regards,
>> Anton Arefiev
>> 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 Development Mailing 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] Timeframe for future elections & "Release stewards"

Rob Cresswell wrote:
> I've been toying with send this email for a while, but here goes: this
> all feels like overcomplication and changing of a system that doesn't
> really need to change.

Except the proposal here is actually to not change anything, but I see
what you mean.

> I've read the pros and cons, and I still can't really see a convincing
> reason not to move the PTL election to just-before-PTG, so that the new
> PTL is present for one development cycle as before.

Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.

Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.

-- 
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] [release] Release countdown for week R-3, 12 - 16 Sept -- Release Candidate Deadline