[openstack-dev] [requirements][FFE] pymod2pkg 0.5.4

2016-09-09 Thread Dirk Müller 
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

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

2016-09-09 Thread John Davidge 
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

Re: [openstack-dev] [requirements][FFE] block graphviz 0.5.0

2016-09-09 Thread Dirk Müller 
Hi Tony,

2016-09-09 9:42 GMT+02:00 Tony Breeds :

> Has some impact on  octavia (doc-requirements) and rpm-packaging (internal
> global-requirements.txt)

Yeah, rpm-packaging shouldn't be a blocker on this, since we're just
trying to keep a snapshot of g-r that we have tested against (this
isn't fully functional yet).

so +2, workflow+1.

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

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

2016-09-09 Thread Flavio Percoco 

Please, if you haven't, I'd love for you to read Monty's response. He explained
in way better words what I was not able too:

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

Flavio

On 08/09/16 11:32 -0700, Clay Gerrard wrote:

On Thu, Sep 8, 2016 at 6:13 AM, Chris Dent  wrote:


That is, it thinks of itself as an existing truth to be ratified.



Gah!  YES!!  Exactly this!  Well said!

And this attitude keeps getting echoed again and again from the current
oligarchy TC!  "We know what OpenStack is; we know the principles we
operate under."

[from https://review.openstack.org/#/c/357260/]

If the OpenStack Principles are in conflict with someone's thoughts
or dreams, it is probably best to find something else to do that is more
aligned with those


How can you get behind a document with a closing paragraph like this!?
OBEY OR LEAVE?!


Because of the ordering of the process and the
presumption of the document they will simply choose to ignore it and
carry on with whatever other important things they've got going on.


Gah!  YES!  Please pay attention!

I know how it feels - I too want to focus *only* on THE MISSON:

[from
http://governance.openstack.org/reference/charter.html#openstack-project-teams
]

OpenStack “Project Teams” are groups of people dedicated to the
completion of the OpenStack project mission, which is ‘’to produce the
ubiquitous Open Source Cloud Computing platform that enables building
interoperable public and private clouds regardless of size, by being
simple to implement and massively scalable while serving the cloud
users’ needs.’’ Project Teams may create any code repository and produce
any deliverable they deem necessary to achieve their goals.


^ what an amazing mission!!!

But remember, our mission must be "performed under the *oversight* of
the TC" - the trick is - *we* elect that *representative* governance!
Elections are next month people!

http://governance.openstack.org/#current-members

OpenStack for the Operators!

Not OpenStack for OpenStack sake!

-Clay



__
OpenStack Development Mailing 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] [requirements][FFE] block graphviz 0.5.0

2016-09-09 Thread Tony Breeds 
On Fri, Sep 09, 2016 at 09:50:46AM +0100, Dave Walker wrote:
> Looking at the Kolla CI log[0], it doesn't look like Kolla is either at
> fault, or can adapt to the issue in Graphviz.
> 
> Graphviz released 0.5.0 last night, and it seems to have introduced a
> regression.  I've raised this as an issue[1], and made a pull request for a
> fix for this.
> 
> The change I've proposed to them does allow Kolla tests to pass.  Providing
> this, or similar lands - then it is entirely appropriate to blacklist
> graphviz===0.5.0 and pick up the fix in the next release of Graphviz.

Great.  Thanks for following up and providing a fix.

Yours Tony.


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

2016-09-09 Thread Dmitry Tantsur 

On 09/08/2016 08:01 PM, Doug Hellmann wrote:

Focus
-

All teams should be wrapping up their work to prepare release
candidates for the end of Newton.

General Notes
-

The release candidate deadline for Newton releases is 15 Sept. All
projects following cycle-based release models that want to include
a deliverable in Newton should have a release prepared by 15 Sept.

We will create stable/newton branches for milestone-based projects
when the release candidate is tagged.

Release Actions
---

Be prepared to have a release candidate tagged by 15 Sept, but wait
as late as possible to include as many bug fixes and translations
as possible. This also avoids having a second release candidate
quickly after the first, and therefore indicating to consumers that
they may want to ignore those initial release candidates.

Projects not following the milestone-based release model who want
stable/newton branches created should include that information in
the commit message for their release request. Remember, we always
create stable branches from tagged commits, so we need the tag to
exist before we branch.

Review the members of your $project-release group in gerrit, based
on the instructions Thierry sent on 15 Aug to ensure there are team
members able to approve patches on the new branch when it is created.


Doug, Thierry,

Could you please link to email you're talking about? I can't find 
anything like that neither in my inbox nor on 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/author.html.




Watch for translation patches and merge them quickly to ensure we
have as many user-facing strings translated as possible in the
release candidates.

Liaisons for projects with independent deliverables should import
the release history by preparing patches to openstack/releases.

Important Dates
---

Newton RC-1, 15 Sept.

Newton final release, 6 Oct.

Newton release schedule: http://releases.openstack.org/newton/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




__
OpenStack Development Mailing 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 Tony Breeds 
On Fri, Sep 09, 2016 at 11:17:17AM +0200, Andreas Jaeger wrote:
> On 09/09/2016 04:34 AM, Tony Breeds wrote:
> > [...]
> > I did a spot check and it seems like liberty is closed for translations.
> 
> Yes, liberty is closed for translations now,

Thanks Andreas.

Yours Tony.


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 Thierry Carrez 
Joshua Harlow wrote:
> [...]
> 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 can answer that one.

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.

[1]
http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-28-20.06.html

-- 
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] [stable] [all] Regarding string freeze and back ports involving translatable strings

2016-09-09 Thread Andreas Jaeger 
On 09/09/2016 04:34 AM, Tony Breeds wrote:
> [...]
> I did a spot check and it seems like liberty is closed for translations.

Yes, liberty is closed for translations now,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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 Julien Danjou 
On Fri, Sep 09 2016, gordon chung wrote:

> On 08/09/16 09:13 AM, Chris Dent wrote:
>
>> The truth, for me, is that I agree with most of the things in the
>> document. What is problematic for me is that I know a lot of people
>> who will not. Because of the ordering of the process and the
>> presumption of the document they will simply choose to ignore it and
>> carry on with whatever other important things they've got going on.
>
> i read it... and did this ^. you know us so well.

Ditto as I said on IRC lol.

> it seems like a lot of the issues people have are because either the 
> tenet is ambiguous, the tenet is arguably untrue, and/or it's not clear 
> why we even need the tenet.

Yeah, though I agree with Chris that I tend to feel the process being
biased by how it's run (e.g. top-bottom).
On the other hand, one can argue that the TC is elected by the community
so if you don't agree with what they wrote, you elected the wrong
people.

Now, why the TC picked a top-bottom approach whereas some sort of
crowd-sourcing of the principles could have been done is questionable –
though probably highly pragmatic. :)

> maybe if we want to progress on this, it'd be best to explain why we 
> even consider it necessary to write down the principle in the first 
> place. e.g we are writing principle x because it helps us solve problem 
> y. you'll probably get even more critical feedback when you do this but 
> if you do, it'll help affirm that you probably don't need to write this.

I think writing is down is building a good tool that you can use to
refer to if anything is going in a different direction – it's not just
"something everybody should know" but "something everybody can know".

Some sort of "ignorantia juris non excusat".

The short term problem that I see from both the approach and the
writing-down itself, is that the result of it might end up having some
folks not recognizing themselves anymore in OpenStack. It's an easy trap
when the knowledge is tribal to think everybody is on the same line,
whereas it's not true.

So those guidelines might clear everything for everyone, but also make
some people/project not in line.

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

2016-09-09 Thread Thierry Carrez 
Sean Dague wrote:
> [...]
> 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.

I think that we are in alignment in 98% of what's proposed here.
Elections would still be run in the weeks prior to the summit. I'm
saying that there should be release stewards and by default it would be
the PTL. You are saying there should be PTLs with release duties, but
they can still delegate that. That's nearly the same thing.

The two differences are:
- defining "release stewards" as a thing slightly encourages PTLs to
delegate the role.
- the transfer of the ultimate tie-breaking/veto authority of the PTL
happens at election time in my case (as defined in the TC charter),
while you suggest it happens 3 months later, when development on N+1 starts.

One thing to note is that unless someone proposes a TC charter change
during Ocata, the authority of the newly-elected PTL starts at election
time, since the charter only recognizes one PTL at a time.

-- 
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] [requirements][FFE] block graphviz 0.5.0

2016-09-09 Thread Dave Walker 
On 9 September 2016 at 08:42, Tony Breeds  wrote:

> On Fri, Sep 09, 2016 at 11:58:29AM +0530, Swapnil Kulkarni (coolsvap)
> wrote:
> > Currently kolla gate jobs are failing due to issues in graphviz 0.5.0.
> [1]
> >
> > We need to unblock the gates by blocking graphviz===0.5.0.
>
> It looks to me that the only package directly affected by this FFE is kolla
>
> Package  : graphviz [graphviz>=0.4.0] (used by 1 projects)
> Also affects : 1 projects
> openstack/kolla   [release:cycle-trailing]
>
> http://codesearch.openstack.org/?q=graphviz=nope=.
> *requirements.txt=
>
> Has some impact on  octavia (doc-requirements) and rpm-packaging (internal
> global-requirements.txt)
>
> So Looks good to me
>
> Yours Tony.
>
>
Looking at the Kolla CI log[0], it doesn't look like Kolla is either at
fault, or can adapt to the issue in Graphviz.

Graphviz released 0.5.0 last night, and it seems to have introduced a
regression.  I've raised this as an issue[1], and made a pull request for a
fix for this.

The change I've proposed to them does allow Kolla tests to pass.  Providing
this, or similar lands - then it is entirely appropriate to blacklist
graphviz===0.5.0 and pick up the fix in the next release of Graphviz.

Thanks

[0]
http://logs.openstack.org/16/367416/1/gate/gate-kolla-python34/64dd4ae/console.html#_2016-09-09_04_42_27_380320
[1] https://github.com/xflr6/graphviz/issues/24

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

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core

2016-09-09 Thread Maksim Malchuk 
+1

On Thu, Sep 8, 2016 at 11:54 AM, Igor Kalnitsky  wrote:

> Hey Fuelers,
>
> I'd like to nominate Ilya for joining fuel-plugins-core group. He's a
> top contributor by both reviews [1] and commits [2] over the past
> release cycle. Fuel cores, please share your votes.
>
> - Igor
>
> [1] http://stackalytics.com/?module=fuel-plugins=
> newton=marks
> [2] http://stackalytics.com/?module=fuel-plugins=
> newton=commits
>
> __
> OpenStack Development Mailing 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,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

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

2016-09-09 Thread Thierry Carrez 
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.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core

2016-09-09 Thread Dmitry Guryanov 
+1

On Fri, Sep 9, 2016 at 7:34 AM, Alexey Stepanov 
wrote:

> +1
> Best regards,
> Alexey Stepanov.
>
> чт, 8 сент. 2016 г., 12:19 Bulat Gaifullin :
>
>> +1
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> On 08 Sep 2016, at 12:05, Georgy Kibardin  wrote:
>>
>> +1
>>
>> On Thu, Sep 8, 2016 at 11:54 AM, Igor Kalnitsky 
>> wrote:
>>
>>> Hey Fuelers,
>>>
>>> I'd like to nominate Ilya for joining fuel-plugins-core group. He's a
>>> top contributor by both reviews [1] and commits [2] over the past
>>> release cycle. Fuel cores, please share your votes.
>>>
>>> - Igor
>>>
>>> [1] http://stackalytics.com/?module=fuel-plugins=
>>> newton=marks
>>> [2] http://stackalytics.com/?module=fuel-plugins=
>>> newton=commits
>>>
>>> 
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Dmitry Guryanov
__
OpenStack Development Mailing 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] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

2016-09-09 Thread Ihar Hrachyshka 

Tony Breeds  wrote:


On Thu, Sep 08, 2016 at 09:21:57AM -0500, Matthew Thode wrote:


Ya that makes sense, the patch can be altered to just block 4.13.1,2
(assuming 4.13.3 really does fix it)


I feel like we've gotten ourselves (well at least I'm confused) about what
we're trying to achieve here.

It seem to be the primary purpose is to get a release of oslo.db out that  
works

for everyone both requirements consumers and non-consumers.

That seems to be done by:
1. Release oslo.db (4.13.3)
https://review.openstack.org/#/c/367482/
2. Bump upper-constraints to point to the new release
Generated once the review above merges
Once it is generated we can abandon: 
https://review.openstack.org/#/c/366298/
4. Update global-requirements to mark some oslo.db versions as bad
I'll update https://review.openstack.org/#/c/365565 RSN


Agreed. Though I already have a patch for that:  
https://review.openstack.org/#/c/365565/



5. Re-Release library packages that get a new the restricted oslo.db
   requirement.

There is also another goal to unblock PyMysql 0.7.7 from  
global-requirements

and upper-constraints.txt

I don't see the need for this.  If distros were shipping 0.7.7 then maybe  
but

even then it's a risky change at this stage.


Agreed, and I expressed the same sentiment in Matthew’s patches before.



https://packages.gentoo.org/packages/dev-python/pymysql
https://build.opensuse.org/package/show/devel:languages:python/python-PyMySQL
https://launchpad.net/ubuntu/+source/python-pymysql
https://apps.fedoraproject.org/packages/python-PyMySQL
http://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHOS/SRPMS/python-PyMySQL-0.6.7-2.2.el7ost.src.rpm

The only really compelling reason for unblocking 0.7.7 *now* would be  
because
we can't do it after we branch[1] but if we leave it masked it just means  
that

distro packagers will know to skip it.

We should Abandon https://review.openstack.org/#/c/364541/


Agreed, except that I don’t suggest we should abandon it. If there is some  
interest in unblocking it, then just postpone it to when Ocata is open.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] block graphviz 0.5.0

2016-09-09 Thread Tony Breeds 
On Fri, Sep 09, 2016 at 11:58:29AM +0530, Swapnil Kulkarni (coolsvap) wrote:
> Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]
> 
> We need to unblock the gates by blocking graphviz===0.5.0.

It looks to me that the only package directly affected by this FFE is kolla

Package  : graphviz [graphviz>=0.4.0] (used by 1 projects)
Also affects : 1 projects
openstack/kolla   [release:cycle-trailing]

http://codesearch.openstack.org/?q=graphviz=nope=.*requirements.txt=

Has some impact on  octavia (doc-requirements) and rpm-packaging (internal
global-requirements.txt)

So Looks good to me

Yours Tony.


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] [tripleo] what's up in upgrades?

2016-09-09 Thread mathieu bultel 
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.
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>>
>> On Thu, Sep 8, 2016 at 2: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.
>>>
>>>
>>> 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.
>>> --
>>> 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
>
>


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

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.


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

Re: [openstack-dev] [requirements][FFE] block graphviz 0.5.0

2016-09-09 Thread Swapnil Kulkarni 
On Fri, Sep 9, 2016 at 12:07 PM, Shake Chen  wrote:
> seem the link is error.
>
> https://review.openstack.org/#/c/367740/
>
>
>
> On Fri, Sep 9, 2016 at 2:28 PM, Swapnil Kulkarni (coolsvap)
>  wrote:
>>
>> Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]
>>
>> We need to unblock the gates by blocking graphviz===0.5.0.
>>
>> [1] https://review.openstack.org/#/c/367416/
>>
>> --
>> Best Regards,
>> Swapnil Kulkarni
>> irc : coolsvap
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Shake Chen
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


This is the change [1]  where py34 gate is failing. The requirements
update will be triggered with requirements bot once FFE is granted and
related change is merged.

__
OpenStack Development Mailing 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] block graphviz 0.5.0

2016-09-09 Thread Shake Chen 
seem the link is error.

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



On Fri, Sep 9, 2016 at 2:28 PM, Swapnil Kulkarni (coolsvap)  wrote:

> Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]
>
> We need to unblock the gates by blocking graphviz===0.5.0.
>
> [1] https://review.openstack.org/#/c/367416/
>
> --
> Best Regards,
> Swapnil Kulkarni
> irc : coolsvap
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Shake Chen
__
OpenStack Development Mailing 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] block graphviz 0.5.0

2016-09-09 Thread Swapnil Kulkarni (coolsvap) 
Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1]

We need to unblock the gates by blocking graphviz===0.5.0.

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

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

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

<    1   2