date:20170615

On Thu, Jun 15, 2017 at 03:48:00PM +0300, Denis Meltsaykin wrote:
> Greetings everyone!
> 
> Since the development of fuel-related projects is currently not so active
> as it used to be, I want to propose a change in how we maintain stable
> branches.
> 
> -Motivation-
> As for now to commit anything into a stable branch of a fuel-related
> project one should get at least one approval from a core developer in that
> project and another approval from the maintenance team. While this was a
> pretty good working workflow in the last couple of years, at the moment it
> slows down the maintenance of the stable branches due to reduced presence
> of core developers.
> 
> -Proposal-
> I propose to grant CR+2 permissions in the stable branches to the
> fuel-stable-core [0] group, which represents the current maintenance team
> working on the stable branches.
> Since the beginning the maintenance team is one of the most active
> contributors to the stable branches of fuel-* projects and is fully
> involved into the contribution process. I've prepared a commit [1]
> beforehand.
> 
> -Advantages-
> Maintenance of the stable branches will become significantly better.

With my stable hat on I endorse this plan.  I suggest you include the
stable-maint-core [
https://review.openstack.org/#/admin/groups/530,members ] group. but
that's entirely optional at this point.

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] [stable][kolla][release] Policy regarding backports of gate code

On Mon, Jun 05, 2017 at 02:38:44PM -0700, Ihar Hrachyshka wrote:
> On 06/05/2017 09:42 AM, Michał Jastrzębski wrote:
> > My question is, is it ok to backport gate logic to stable branch?
> > Regular code doesn't change so it might not be considered a feature
> > backport (users won't see a thing).
> 
> Yes, that's allowed. Stable maintainers are concerned about destabilizing
> production code. Touching gate infrastructure, adding tests, updating
> documentation is almost always ok. (Assuming your changes don't e.g. reduce
> test coverage.)

Yup what Ihar said :)

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][stable][ptls] Tagging mitaka as EOL

On Wed, Apr 12, 2017 at 04:47:25PM +1000, Tony Breeds wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
> 
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
> 
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'stable:follows-policy'.
> 
> Some statistics:
> All Repos  : 1584 (covered in zuul/layout.yaml)
> Checked Repos  :  416 (match one or more of the above 
> criteria)
> Repos with mitaka branches :  409
> EOL Repos  :  199 (repos that match the criteria *and* 
> have
>a mitaka branch) [1]
> NOT EOL Repos  :  210 (repos with a mitaka branch but
>otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>mitaka branches)
> Tagged Repos   :0
> Open Reviews   :  159 (reviews to close)
> 
> Please look over both lists by 2017-04-17 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
> 
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.

It seeems a little odd to be following up so long after I first started
this thread  but can someone on infra please process the EOLs as
described in [1].

Yours Tony.

[1] 
https://gist.githubusercontent.com/tbreeds/c99e62bf8da19380e4eb130be8783be7/raw/6d02deb40e07516ce8fc529d2ba8c74af11a5a6b/mitaka_eol_data.txt


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

[openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

2017-06-15 Thread Rabi Mishra

Hi All,

As we know,  'deferred_auth_method=trusts' being the default, we use
trust_auth_plugin whenever a resource requires deferred_auth (any resource
derived from SignalResponder and StackResource). We also support
'deferred_auth_method=password' where  'X-Auth-User'/username and
'X-Auth-Key'/password is passed in the request header and we then store
them in 'user_creds' (rather than 'trust_id')  to create a 'password'
auth_plugin when loading the stack with stored context for signalling. I
assume for this very reason we've the '--include-pass' option in heat cli.

However, when using keystone session(which is the default), we don't have
the above implemented with SessionClient (i.e to pass the headers). There
is a bug[1] and patch[2]  to add this to SessionClient in the review queue.
Aslo, we don't have anything like '--include-pass' for osc.

I've noticed that 'deferred_auth_method=password' is broken and does not
work with keystone v3 at all. As we don't store the 'user_domain_id/name'
in 'user_creds', we can not even intialize the 'password' auth_plugin when
creating the StoredContext, as it would not be able to authenticate the
user without the user_domain[3].

I'm not sure whether this works with keystone v2 and anyone is using it or
not. Keeping in mind that heat-cli is deprecated and keystone v3 is now the
default, we've 2 options

1. Continue to support 'deferred_auth_method=passsword' option and fix all
the above issues.

2. Remove/deprecate the option in pike itlsef.

I would prefer option 2, but probably I miss some history and use cases for
it.

Thoughts?


[1] https://bugs.launchpad.net/python-heatclient/+bug/1665321

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

[3]
https://github.com/openstack/heat/blob/master/heat/common/context.py#L292

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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Shake Chen

HI Vikash

I think Kolla is suitable for official project for deployment



On Fri, Jun 16, 2017 at 1:02 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> I strongly believe Openstack must have any one official project for
> deployment whether its Fuel or anything else. Cutting it short, talking to
> number of people across industry/academic/government institutions, got a
> sense that its necessary that there should be a official tool more than
> Devstack for deployment.
>
> Regards,
> Vikash
>
> On Fri, Jun 16, 2017 at 2:20 AM, Dean Troyer  wrote:
>
>> On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes  wrote:
>> > I'd fully support the removal of all deployment projects from the
>> "official
>> > OpenStack projects list".
>>
>> Nice to hear Jay! :)
>>
>> It was intentional from the beginning to not be in the deployment
>> space, we allowed those projects in (not unanimously IIRC) and most of
>> them did not evolve as expected.
>>
>> I would not mind picking one winner and spending effort making an
>> extremely easy, smooth, upgradable install that is The OneTrue
>> OpenStack, I do not expect us to ever agree what that will look like
>> so it is effectively never going to happen.  We've seen how far
>> single-vendor projects have gone, and none of them reached that level.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Vikash Kumar

I strongly believe Openstack must have any one official project for
deployment whether its Fuel or anything else. Cutting it short, talking to
number of people across industry/academic/government institutions, got a
sense that its necessary that there should be a official tool more than
Devstack for deployment.

Regards,
Vikash

On Fri, Jun 16, 2017 at 2:20 AM, Dean Troyer  wrote:

> On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes  wrote:
> > I'd fully support the removal of all deployment projects from the
> "official
> > OpenStack projects list".
>
> Nice to hear Jay! :)
>
> It was intentional from the beginning to not be in the deployment
> space, we allowed those projects in (not unanimously IIRC) and most of
> them did not evolve as expected.
>
> I would not mind picking one winner and spending effort making an
> extremely easy, smooth, upgradable install that is The OneTrue
> OpenStack, I do not expect us to ever agree what that will look like
> so it is effectively never going to happen.  We've seen how far
> single-vendor projects have gone, and none of them reached that level.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On 15/06/17 06:28 PM, Doug Hellmann wrote:
>> i see, so this is less an existential question of 'what is openstack'
>> > and more 'how to differentiate governance projects from a random repo
>> > created last weekend'
>> >
>> > this might have been just me, but big tent was exactly 'big tent ==
>> > governance' so when i read 'moving away from "big tent"' i think 'what
>> > is this *new* thing we're moving to and if we're redefining this new
>> > thing, what for?'. it seems this is not the case.
> No. We're trying to pick new words, because there continues to be
> confusion about the old words.

my bad, apologies for taking the scenic route. regardless of new words, 
we failed to properly describe what the big tent was the first go to 
some people, how do we make sure they're not confused this time? and how 
do we not confuse the ones that did understand the first time?

for me personally, the first go, the messaging was kind of muddled. i 
remember 'level playing field' being used frequently. not sure if that's 
still one of the reasons for ?

>> >
>> > sorry, i probably wasn't clear, i simply noticed that it was a corporate
>> > sponsor that was misusing the 'big tent' name so was just thinking we
>> > could easily tell them, that's not what it means. wasn't suggesting
>> > anything else by sponsor comment.
> You'd think it would be that easy. A surprising number of folks
> within the community don't really understand the old naming either,
> though (see the rest of this thread for examples).

*sigh* so this is why we can't have nice things :p

as an aside, in telemetry project, we did something somewhat similar 
when we renamed/rebranded to telemetry from ceilometer. we wrote several 
notes to the ML, had a few blog posts, fixed the docs, mentioned the new 
project structure in our presentations... 2 years on, we still 
occasionally get asked "what's ceilometer", "is xyz not ceilometer?", or 
"so ceilometer is deprecated?". to a certain extent i think we'll have 
to be prepared to do some hand holding and say "hey, that's not what the 
"big tent/."

-- 
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] [nova][api] Strict validation in query parameters

2017-06-15 Thread Ghanshyam Mann

On Fri, Jun 16, 2017 at 11:01 AM, Matt Riedemann  wrote:
> On 6/15/2017 8:43 PM, Alex Xu wrote:
>>
>> We added new decorator 'query_schema' to support validate the query
>> parameters by JSON-Schema.
>>
>> It provides more strict valiadation as below:
>> * set the 'additionalProperties=False' in the schema, it means that reject
>> any invalid query parameters and return HTTPBadRequest 400 to the user.
>> * use the marco function 'single_param' to declare the specific query
>> parameter only support single value. For example, the 'marker' parameters
>> for the pagination actually only one value is the valid. If the user
>> specific multiple values "marker=1=2", the validation will return 400
>> to the user.
>>
>> Currently there is patch related to this:
>>
>> https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py
>>
>> So my question is:
>> Are we all good with this strict validation in all the future
>> microversion?
>>
>> I didn't remember we explicit agreement this at somewhere, just want to
>> double check this is the direction everybody want to go.
>>
>> Thanks
>> Alex
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I think this is fine and makes sense for new microversions. The spec for
> consistent query parameter validation does talk about it a bit:
>
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/consistent-query-parameters-validation.html#proposed-change
>
> "The behaviour additionalProperties as below:
>
> * When the value of additionalProperties is True means the extra query
> parameters are allowed. But those extra query parameters will be stripped
> out.
> * When the value of additionalProperties is False means the extra query
> aren’t allowed.
>
> The value of additionalProperties will be True until we decide to restrict
> the parameters in the future, and it will be changed with new microversion."
>
> I don't see a point in allowing someone to specify a query parameter
> multiple times if we only pick the first one from the list and use that.
>
> There are certain query parameters that we allow multiple instances of, for
> sorting I believe. But for other things like filtering restricting to 1
> should be fine, and using additionalProperties=False should also be fine on
> new microversions. For example, if we allow additional properties, someone
> could type the parameter name incorrectly and we'd just ignore it. With
> strict validation, we'll return a 400 which should be clear to the end user
> that what they requested as invalid and they need to fix it on their end.

Yea, strict validation is always good and makes interface hard to use
wrongly. Starting strict validation on query param with microversion
is nice way but yes we cannot do that without microversion.

+1 on that direction.

>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing 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][qa][glance] some recent tempest problems

2017-06-15 Thread Ghanshyam Mann

On Fri, Jun 16, 2017 at 9:43 AM,   wrote:
> https://review.openstack.org/#/c/471352/   may be an example

If this is case which is ceph related, i think we already discussed
these kind of cases, where functionality depends on backend storage
and how to handle corresponding tests failure [1].

Solution on that was Ceph job should exclude such test case which
functionality is not implemented/supported in ceph byregex. Jon
Bernard is working on this tests blacklist [2].

If there is any other job or case, then we can discuss/think of having
job running for Tempest gate also which i think we do in most cases.

And about making ceph job as voting, i remember we did not do that due
to stability ok job. Ceph job fails frequently and once Jon patches
merge and job is consistently stable then we can make voting.

>
>
> Original Mail
> Sender:  ;
> To:  ;
> Date: 2017/06/16 05:25
> Subject: Re: [openstack-dev] [all][qa][glance] some recent tempest problems
>
>
> On 06/15/2017 01:04 PM, Brian Rosmaita wrote:
>> This isn't a glance-specific problem though we've encountered it quite
>> a few times recently.
>>
>> Briefly, we're gating on Tempest jobs that tempest itself does not
>> gate on.  This leads to a situation where new tests can be merged in
>> tempest, but wind up breaking our gate. We aren't claiming that the
>> added tests are bad or don't provide value; the problem is that we
>> have to drop everything and fix the gate.  This interrupts our current
>> work and forces us to prioritize bugs to fix based not on what makes
>> the most sense for the project given current priorities and resources,
>> but based on whatever we can do to get the gates un-blocked.
>>
>> As we said earlier, this situation seems to be impacting multiple
>> projects.
>>
>> One solution for this is to change our gating so that we do not run
>> any Tempest jobs against Glance repositories that are not also gated
>> by Tempest.  That would in theory open a regression path, which is why
>> we haven't put up a patch yet.  Another way this could be addressed is
>> by the Tempest team changing the non-voting jobs causing this
>> situation into voting jobs, which would prevent such changes from
>> being merged in the first place.  The key issue here is that we need
>> to be able to prioritize bugs based on what's most important to each
>> project.
>>
>> We want to be clear that we appreciate the work the Tempest team does.
>> We abhor bugs and want to squash them too.  The problem is just that
>> we're stretched pretty thin with resources right now, and being forced
>> to prioritize bug fixes that will get our gate un-blocked is
>> interfering with our ability to work on issues that may have a higher
>> impact on end users.
>>
>> The point of this email is to find out whether anyone has a better
>> suggestion for how to handle this situation.
>
> It would be useful to provide detailed examples. Everything is trade
> offs, and having the conversation in the abstract is very difficult to
> understand those trade offs.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>


..1 http://lists.openstack.org/pipermail/openstack-dev/2017-May/116172.html

..2 https://review.openstack.org/#/c/459774/ ,
https://review.openstack.org/#/c/459445/


-gmann

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

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

[openstack-dev] [devstack] etcd v3.2.0?

Hi All,
I just push a review [1] to bump the minimum etcd version to
3.2.0 which works on intel and ppc64le.  I know we're pretty late in the
cycle to be making changes like this but releasing pike with a dependacy
on 3.1.x make it harder for users on ppc64le (not many but a few :D)

Yours Tony.

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


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] [nova][api] Strict validation in query parameters

2017-06-15 Thread Matt Riedemann


On 6/15/2017 8:43 PM, Alex Xu wrote:
We added new decorator 'query_schema' to support validate the query 
parameters by JSON-Schema.


It provides more strict valiadation as below:
* set the 'additionalProperties=False' in the schema, it means that 
reject any invalid query parameters and return HTTPBadRequest 400 to the 
user.
* use the marco function 'single_param' to declare the specific query 
parameter only support single value. For example, the 'marker' 
parameters for the pagination actually only one value is the valid. If 
the user specific multiple values "marker=1=2", the validation 
will return 400 to the user.


Currently there is patch related to this:
https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py

So my question is:
Are we all good with this strict validation in all the future microversion?

I didn't remember we explicit agreement this at somewhere, just want to 
double check this is the direction everybody want to go.


Thanks
Alex


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



I think this is fine and makes sense for new microversions. The spec for 
consistent query parameter validation does talk about it a bit:


https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/consistent-query-parameters-validation.html#proposed-change

"The behaviour additionalProperties as below:

* When the value of additionalProperties is True means the extra query 
parameters are allowed. But those extra query parameters will be 
stripped out.
* When the value of additionalProperties is False means the extra query 
aren’t allowed.


The value of additionalProperties will be True until we decide to 
restrict the parameters in the future, and it will be changed with new 
microversion."


I don't see a point in allowing someone to specify a query parameter 
multiple times if we only pick the first one from the list and use that.


There are certain query parameters that we allow multiple instances of, 
for sorting I believe. But for other things like filtering restricting 
to 1 should be fine, and using additionalProperties=False should also be 
fine on new microversions. For example, if we allow additional 
properties, someone could type the parameter name incorrectly and we'd 
just ignore it. With strict validation, we'll return a 400 which should 
be clear to the end user that what they requested as invalid and they 
need to fix it on their end.


--

Thanks,

Matt

__
OpenStack Development Mailing 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][api] Strict validation in query parameters

2017-06-15 Thread Alex Xu

We added new decorator 'query_schema' to support validate the query
parameters by JSON-Schema.

It provides more strict valiadation as below:
* set the 'additionalProperties=False' in the schema, it means that reject
any invalid query parameters and return HTTPBadRequest 400 to the user.
* use the marco function 'single_param' to declare the specific query
parameter only support single value. For example, the 'marker' parameters
for the pagination actually only one value is the valid. If the user
specific multiple values "marker=1=2", the validation will return
400 to the user.

Currently there is patch related to this:
https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py

So my question is:
Are we all good with this strict validation in all the future microversion?

I didn't remember we explicit agreement this at somewhere, just want to
double check this is the direction everybody want to go.

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread Amrith Kumar

I'm confused by the proposal; you've made a 1-1 substitution of "big tent"
with "openstack project" and then there are some "openstack hosted
projects".

How does that clarify the situation?

It does not help me answer the question "Is Trove part of OpenStack?" with
any more clarity than before.

So I'm missing something and judging by the follow-up's I'm not the only
one.

And yes, "friends of OpenStack" only begs the question who are not friends
of OpenStack :)

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Thu, Jun 15, 2017 at 8:57 AM, Thierry Carrez 
wrote:

> Sean Dague wrote:
> > [...]
> > I think those are all fine. The other term that popped into my head was
> > "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> > that aren't official projects. It may be too informal, but I do think
> > the OpenStack-Hosted vs. OpenStack might still mix up in people's head.
>
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting that
> we don't actually do.
>
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!
>
> --
> 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][qa][glance] some recent tempest problems

2017-06-15 Thread zhu.fanglei

https://review.openstack.org/#/c/471352/   may be an example






Original Mail



Sender:  
To:  
Date: 2017/06/16 05:25
Subject: Re: [openstack-dev] [all][qa][glance] some recent tempest problems





On 06/15/2017 01:04 PM, Brian Rosmaita wrote:
> This isn't a glance-specific problem though we've encountered it quite
> a few times recently.
> 
> Briefly, we're gating on Tempest jobs that tempest itself does not
> gate on.  This leads to a situation where new tests can be merged in
> tempest, but wind up breaking our gate. We aren't claiming that the
> added tests are bad or don't provide value the problem is that we
> have to drop everything and fix the gate.  This interrupts our current
> work and forces us to prioritize bugs to fix based not on what makes
> the most sense for the project given current priorities and resources,
> but based on whatever we can do to get the gates un-blocked.
> 
> As we said earlier, this situation seems to be impacting multiple projects.
> 
> One solution for this is to change our gating so that we do not run
> any Tempest jobs against Glance repositories that are not also gated
> by Tempest.  That would in theory open a regression path, which is why
> we haven't put up a patch yet.  Another way this could be addressed is
> by the Tempest team changing the non-voting jobs causing this
> situation into voting jobs, which would prevent such changes from
> being merged in the first place.  The key issue here is that we need
> to be able to prioritize bugs based on what's most important to each
> project.
> 
> We want to be clear that we appreciate the work the Tempest team does.
> We abhor bugs and want to squash them too.  The problem is just that
> we're stretched pretty thin with resources right now, and being forced
> to prioritize bug fixes that will get our gate un-blocked is
> interfering with our ability to work on issues that may have a higher
> impact on end users.
> 
> The point of this email is to find out whether anyone has a better
> suggestion for how to handle this situation.

It would be useful to provide detailed examples. Everything is trade
offs, and having the conversation in the abstract is very difficult to
understand those trade offs.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

Excerpts from gordon chung's message of 2017-06-15 20:24:06 +:
> 
> On 15/06/17 03:23 PM, Doug Hellmann wrote:
> >
> > We are very open with our hosting, allowing projects that have not
> > yet, and may never, sign up to be governed by the TC to use our
> > infrastructure services. We expect them to be related in some way,
> > but we have even imported projects when we've taken over maintenance
> > (several Oslo libs fall into this category, as do a few others like
> > mox3 and sqlalchemy-migrate). With the move away from stackforge,
> > and other changes in that hosting (that were made for good reasons
> > to make the infra team's lives easier and to make it simpler for a
> > project to join the set of governed projects), we have removed most
> > of the other technical signals about which projects are in that
> > "official" list and which are not.  We did not at the same time
> > remove all of the people in the world who want to understand what
> > is, and what is not, "in" OpenStack.
> 
> i see, so this is less an existential question of 'what is openstack' 
> and more 'how to differentiate governance projects from a random repo 
> created last weekend'
> 
> this might have been just me, but big tent was exactly 'big tent == 
> governance' so when i read 'moving away from "big tent"' i think 'what 
> is this *new* thing we're moving to and if we're redefining this new 
> thing, what for?'. it seems this is not the case.

No. We're trying to pick new words, because there continues to be
confusion about the old words.

> > And for the record, from the TC's perspective, being a governed
> > project has nothing to do with whether the participants are sponsors
> > of the foundation.
> 
> sorry, i probably wasn't clear, i simply noticed that it was a corporate 
> sponsor that was misusing the 'big tent' name so was just thinking we 
> could easily tell them, that's not what it means. wasn't suggesting 
> anything else by sponsor comment.

You'd think it would be that easy. A surprising number of folks
within the community don't really understand the old naming either,
though (see the rest of this thread for examples).

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] [keystone][glance][nova][neutron][horizon][cinder][osc][swift][manila][telemetry][heat][ptls][all][tc][docs] Documentation migration spec

Excerpts from Doug Hellmann's message of 2017-06-12 11:43:25 -0400:
> I added subject tags for the projects most affected by this change. It
> would be good to have the PTLs or liaisons from those teams review the
> spec so there are no surprises when we start moving files around.

I have set up patches for oslo.config, glance, glance client,
python-openstackclient, and horizon for folks to use as examples
[1]. I've also updated the tracking etherpad [2] with some more
detailed directions.

I hope the examples will answer any remaining questions about the
plan and PTLs will sign-off on the spec so we can move forward in
earnest next week.

Doug

[1] https://review.openstack.org/#/q/topic:doc-migration
[2] https://etherpad.openstack.org/p/doc-migration-tracking

> 
> Excerpts from Alexandra Settle's message of 2017-06-08 15:17:34 +:
> > Hi everyone,
> > 
> > Doug and I have written up a spec following on from the conversation [0] 
> > that we had regarding the documentation publishing future.
> > 
> > Please take the time out of your day to review the spec as this affects 
> > *everyone*.
> > 
> > See: https://review.openstack.org/#/c/472275/
> > 
> > I will be PTO from the 9th – 19th of June. If you have any pressing 
> > concerns, please email me and I will get back to you as soon as I can, or, 
> > email Doug Hellmann and hopefully he will be able to assist you.
> > 
> > Thanks,
> > 
> > Alex
> > 
> > [0] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117162.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] [Openstack-dev] [Congress] [Designate]

2017-06-15 Thread Tim Hinrichs

This error happens happens when the translator thinks there's an
object/dictionary when in actuality there's just a string.  I don't know of
a good way to know where in the translator the problem is, other than
simplifying the input and the translator and rerunning (which you're
already doing).

Tim

On Thu, Jun 15, 2017 at 12:52 AM Carmine Annunziata <
carmine.annunziat...@gmail.com> wrote:

> Hi everyone,
> I wrote a congress datasource driver and its unit test for designate, but
> i got the following errors in the method test_update_from_datasource. It's
> something wrong in the translation.
> Here is the traceback:
>
>  File "congress/tests/datasources/test_designate_driver.py", line 34, in
> setUp
> self.driver = designate_driver.DesignateDriver(args=args)
>   File "congress/datasources/designate_driver.py", line 150, in __init__
> super(DesignateDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 1282, in __init__
> super(PollingDataSourceDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 324, in __init__
> self.initialize_translators()
>   File "congress/datasources/datasource_driver.py", line 1324, in
> initialize_translators
> self.register_translator(translator)
>   File "congress/datasources/datasource_driver.py", line 457, in
> register_translator
> self._validate_translator(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 389, in
> _validate_hdict_type
> self._validate_translator(subtranslator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 386, in
> _validate_hdict_type
> self.check_params(field_translator.keys(),
> AttributeError: 'str' object has no attribute 'keys'
>
> Thank you,
> Carmine
> __
> OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On 2017-06-15 16:35:15 -0500 (-0500), Ed Leafe wrote:
[...]
> I'm expecting responses that "of course you don't care", or
> "OpenStack is people, and you're hurting our feelings!". So flame
> away!

Nah. Now SoylentStack on the other hand, that one _is_ people but
have you actually tried it? Not very appetizing in my opinion. ;)
-- 
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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Ed Leafe

On Jun 15, 2017, at 3:35 PM, Jeremy Stanley  wrote:

> For me it's one of the most annoying yet challenging/interesting
> aspects: free software development is as much about community and
> politics as it is actual software development (perhaps more so).

Another way to look at it is how we see ourselves (as a community) and how 
people on the outside see OpenStack. I would imagine that someone looking at 
OpenStack for the first time would not care a whit about governance, repo 
locations, etc. They would certainly care about "what do I need to do to use 
this thing?"

What we call things isn't confusing to those of us in the community - well, at 
least to those of us who take the time to read big long email threads like 
this. We need to be clearer in how we represent OpenStack to outsiders. To that 
end, I think that limiting the term "OpenStack" to a handful of the core 
projects would make things a whole lot clearer. We can continue to present 
everything else as a marketplace, or an ecosystem, or however the more 
marketing-minded want to label it, but we should *not* call those projects 
"OpenStack".

Now I know, I work on Nova, so I'm expecting responses that "of course you 
don't care", or "OpenStack is people, and you're hurting our feelings!". So 
flame away!

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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][qa][glance] some recent tempest problems

2017-06-15 Thread Sean Dague

On 06/15/2017 01:04 PM, Brian Rosmaita wrote:
> This isn't a glance-specific problem though we've encountered it quite
> a few times recently.
> 
> Briefly, we're gating on Tempest jobs that tempest itself does not
> gate on.  This leads to a situation where new tests can be merged in
> tempest, but wind up breaking our gate. We aren't claiming that the
> added tests are bad or don't provide value; the problem is that we
> have to drop everything and fix the gate.  This interrupts our current
> work and forces us to prioritize bugs to fix based not on what makes
> the most sense for the project given current priorities and resources,
> but based on whatever we can do to get the gates un-blocked.
> 
> As we said earlier, this situation seems to be impacting multiple projects.
> 
> One solution for this is to change our gating so that we do not run
> any Tempest jobs against Glance repositories that are not also gated
> by Tempest.  That would in theory open a regression path, which is why
> we haven't put up a patch yet.  Another way this could be addressed is
> by the Tempest team changing the non-voting jobs causing this
> situation into voting jobs, which would prevent such changes from
> being merged in the first place.  The key issue here is that we need
> to be able to prioritize bugs based on what's most important to each
> project.
> 
> We want to be clear that we appreciate the work the Tempest team does.
> We abhor bugs and want to squash them too.  The problem is just that
> we're stretched pretty thin with resources right now, and being forced
> to prioritize bug fixes that will get our gate un-blocked is
> interfering with our ability to work on issues that may have a higher
> impact on end users.
> 
> The point of this email is to find out whether anyone has a better
> suggestion for how to handle this situation.

It would be useful to provide detailed examples. Everything is trade
offs, and having the conversation in the abstract is very difficult to
understand those trade offs.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread Arkady.Kanevsky

Right on the point Rocky (no wonder you have release named after you)

We also need to update https://www.openstack.org/software/project-navigator/
To align with whatever decision agreed upon.
And we better make decision stick and not change it again in a year or two.
Arkady

-Original Message-
From: Rochelle Grober [mailto:rochelle.gro...@huawei.com] 
Sent: Thursday, June 15, 2017 3:21 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

OK.  So, our naming is like branding.  We are techies -- not good at marketing. 
 But, gee, the foundation has a marketing team.  And they end up fielding a lot 
of the confusing questions from companies not deeply entrenched in the 
OpenStack Dev culture.  Perhaps it would be worth explaining what we are trying 
to do to the marketing team and let them suggest some branding words.

What we would need to do pretty much goes back to Chris and Gord's emails about 
answering the questions of what we mean by "Openstack Project" and  "projects 
we allow to use our infrastructure in pursuit of something that somehow works 
with OpenStack projects".  If we provide marketing with a solid definition of 
what is an OpenStack project (we have that one down fairly well, but they might 
ask about core or other things we haven't debated in a while), and provide them 
with what those other projects have in common besides being hosted by us, they 
might come up with something that works for them and is ok for us.  Remember, 
they get hit with it a lot more than we do at this point.

So what we need is:

* detailed definition of "OpenStack Project" (maybe based on answering those 
questions Chris proposed plus others)
* good definition of what the "others" hosted on our infrastructure are/are 
expected to be
* removal of "big tent" from everywhere (aside/non sequitur -- There was a doge 
of Venice that got deposed for treason and his visage and name were eradicated 
from all buildings, documents, etc.  He also happened to be the inventor of the 
chastity belt)
* introduce the marketing guys to the definitions and the branding issue
* call in OpenStack projects and Others until we have a reasonable brand for 
Others.

--Rocky 

Thierry Carrez Wrote:
> Jeremy Stanley wrote:
> > On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> I'd like to propose that we introduce a new concept:
> >> "OpenStack-Hosted projects". There would be "OpenStack projects" on 
> >> one side, and "Projects hosted on OpenStack infrastructure" on the 
> >> other side (all still under the openstack/ git repo prefix).
> >
> > I'm still unconvinced a term is needed for this. Can't we just have 
> > "OpenStack Projects" (those under TC governance) and "everything 
> > else?" Why must the existence of any term require a term for its 
> > opposite?
> 
> Well, we tried that for 2.5 years now, and people are still confused 
> about which projects are an Openstack project and what are not. The 
> confusion led to the perception that everything under openstack/ is an 
> openstack project.
> It led to the perception that "big tent" means "anything goes in" or 
> "flea market".
> 
> Whether we like it or not, giving a name to that category, a name that 
> people can refer to (not "projects under openstack infrastructure that 
> are not officially recognized by the TC"), is I think the only way out of 
> this confusion.
> 
> Obviously we are not the target audience for that term. I think we are 
> deep enough in OpenStack and technically-focused enough to see through that.
> But reality is, the majority of the rest of the world is confused, and 
> needs help figuring it out. Giving the category a name is a way to do that.
> 
> --
> 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] [neutron] does neutron actually use the salve_connection ?

2017-06-15 Thread Kevin Benton

No, it currently does not. As we implement
https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch that
will change, but that won't be available until Pike or Queens.

On Thu, Jun 15, 2017 at 5:47 AM,  wrote:

> Hello,
>
>
>
>
>
>
>
> I am looking to improve the database load distribution and one of the
> things that may help with this is to spread out the reads.
>
> From the configuration reference it looks like neutron dues support a
> slave_connection parameter but when I enabled it and enabled query logging
> on the secondary databases there aren’t any queries being executed on the
> secondaries. Is there anything I am missing ?
>
>
>
> Sorry for CC’ing the dev list as well but someone in the dev teams may
> have an answer from a developer point of view.
>
>
>
>
>
> My setup is like this:
>
>
>
> Openstack stable/mitaka (built from git)
>
> 3 galera nodes
>
> 1 haproxy running on each node with active/backup with local node as
> single active configuration for the frontend listening on :3306 and
> active/backup with the other nodes as active for the frontend listening on
> :3308
>
>
>
> In neutron.conf in the [database] section I set up the the connection and
> slave_connection parameters like this:
>
>
>
> [database]
>
> connection = mysql+pymysql://neutron:XXX@neutron-db.service:
> 3306/neutron?charset=utf8
>
> slave_connection = mysql+pymysql://neutron: XXX@neutron-db.service:
> 3308/neutron?charset=utf8
>
> idle_timeout = 1800
>
> max_retries = -1
>
> retry_interval = 5
>
> min_pool_size = 8
>
> max_pool_size = 32
>
> max_overflow = 16
>
>
>
>
>
> Loooking on a slave it opens a single connection which is eventually
> closed because of lack of activity.
>
>
>
>
> Thanks,
>
> Cristian
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Paul Belanger

On Thu, Jun 15, 2017 at 03:56:30PM +, Jeremy Stanley wrote:
> On 2017-06-15 11:48:42 -0400 (-0400), Davanum Srinivas wrote:
> > We took that tradeoff before and have suffered as a result. I'd say
> > it's the cost of getting a project under governance.
> 
> Well, sort of. We took the slightly less work (for the Infra team)
> approach of renaming repos within a single Gerrit instead of trying
> to relocate projects between Gerrit deployments.
> 
> Ultimately, if the solution is to run a separate copy of our
> infrastructure to host non-OpenStack projects, it might as well have
> its own volunteer team running it. We're down to a skeleton crew as
> it is, so I don't relish the idea of us being responsible for
> maintaining an extra copy of all these services.
> -- 
> Jeremy Stanley

++ completely agree!


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


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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Dean Troyer

On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes  wrote:
> I'd fully support the removal of all deployment projects from the "official
> OpenStack projects list".

Nice to hear Jay! :)

It was intentional from the beginning to not be in the deployment
space, we allowed those projects in (not unanimously IIRC) and most of
them did not evolve as expected.

I would not mind picking one winner and spending effort making an
extremely easy, smooth, upgradable install that is The OneTrue
OpenStack, I do not expect us to ever agree what that will look like
so it is effectively never going to happen.  We've seen how far
single-vendor projects have gone, and none of them reached that level.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Ben Nemec

On 06/15/2017 11:05 AM, Jay Pipes wrote:

On 06/15/2017 11:56 AM, Ben Nemec wrote:

Full disclosure: I primarily work on TripleO so I do have a horse in
this race.

On 06/15/2017 10:33 AM, Jay Pipes wrote:

On 06/15/2017 10:35 AM, Jeremy Stanley wrote:

On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
[...]

I think that, despite the efforts of the Fuel team, Fuel did not
become
what we hoped when we made it official: a universal installer that
would
be used across the board. It was worth a try, I'm happy that we tried,
but I think it's time to stop considering it a part of "OpenStack"
proper and make it a hosted project. It can of course continue its
existence as an unofficial project hosted on OpenStack infrastructure.

Thoughts ?

I agree, it makes sense to be more clear as to the lack of
community-wide support for that effort. Perhaps if its popularity
increases outside one vendor's customer base to the point where
contributions from a broader set of stakeholders emerge, we can once
again evaluate its governance state.

While I personally agree that Fuel should be moved out of the official
projects list, I'd like to point out that Triple-O is virtually entirely
a Red Hat project:

http://stackalytics.com/?module=tripleo-group
http://stackalytics.com/?module=tripleo-group=commits

so the fact that a project is entirely run by a single vendor or "has
popularity outside one vendor's customer base" has not been and
continues not to be a deciding factor on whether something is an
official OpenStack project or not.

I don't believe the single vendor-ness of the project is the reason
it's being proposed for removal. It's the fact that the single vendor
has all but dropped their support for it. If Red Hat suddenly decided
they were pulling out of TripleO I'd expect the same response, but
that is not the case.

Please see Jeremy's paragraph directly above my response. He
specifically mentions single-vendor-ness as a reason for removal.

I'd fully support the removal of all deployment projects from the
"official OpenStack projects list".

I would not. Deployment of OpenStack remains one of the most
difficult to solve problems and I would be highly disappointed in the
community if they essentially washed their hands of it.

This right here is the perfect example of what Thierry is getting at
with the *perceived value* of the term "Big Tent" or "Official OpenStack
project". :(

What about having deployment projects be "non-official" or "ecosystem"
or "community" projects means that "the community ... essentially washed
their hands of it"? :( You are putting words in my mouth and making a
false equivalence between "community project" and "of lesser value". And
that's precisely the problem these terms: people read way too much into
them.

The problem is that no matter what you call it, as long as you have two
groups, one that includes Nova, Neutron, etc. and one that doesn't, the
one that does is always going to be seen as more "important". Even if
it's purely a perception thing (which I won't dispute), it's a
meaningful perception thing and I think moving the deployment projects
would send the wrong message. Deployment tools are a critical part of
the OpenStack ecosystem and their categorization (whatever it ends up
being called) should reflect that.

Maybe part of the problem is the context of this discussion. We moved
from talking about a largely abandoned project to all the deployment
projects, which (intentionally or not) draws some uncomfortable
parallels. It also appears this is a discussion we should probably
table until the big tent terminology one is completed because until then
we're mostly debating our individual interpretation of the governance
model. Once we're done redrawing the lines of demarcation in the
OpenStack community maybe the correct place for deployment projects will
be more obvious. I doubt it, but one can hope :-).

There are considerably more deployment projects than just TripleO and
Fuel, and there is more collaboration going on there than a simple
commits metric would show. For example, see
http://specs.openstack.org/openstack/oslo-specs/specs/pike/machine-readable-sample-config.html

which came out of a cross-deployment project session at the PTG as a
way to solve a problem that all deployment tools have.

Ben, I don't doubt this and as I've said publicly, I 100% support the
joint deployment efforts and collaboration.

We should be encouraging more community involvement in deployment
tools, not sending the message that deployment tools are not important
enough to be official projects.

What better way to encourage *community involvement* by saying all
deployment tools are *community projects*?

Best,
-jay

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

On 2017-06-15 15:22:14 -0500 (-0500), Matt Riedemann wrote:
[...]
> God I feel like I waste an inordinate amount of time each week
> reading about what new process or thing we're going to call
> something, rather than actually working on getting stuff done for
> the release or reviewing changes. I'm tired of constant
> bureaucratic distraction. I believe it has to be demoralizing to
> the development community.
[...]

For me it's one of the most annoying yet challenging/interesting
aspects: free software development is as much about community and
politics as it is actual software development (perhaps more so).
-- 
Jeremy Stanley


signature.asc
Description: 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][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 4:22 PM, Matt Riedemann  wrote:
> On 6/15/2017 9:57 AM, Thierry Carrez wrote:
>>
>> Obviously we are not the target audience for that term. I think we are
>> deep enough in OpenStack and technically-focused enough to see through
>> that. But reality is, the majority of the rest of the world is confused,
>> and needs help figuring it out. Giving the category a name is a way to
>> do that.
>
>
> Maybe don't ask the inmates what the asylum/prison should be called. Why
> don't we have people that are confused about this weighing in on this
> thread? Oh right because they don't subscribe to, or read, or reply to a
> development mailing list.
>
> God I feel like I waste an inordinate amount of time each week reading about
> what new process or thing we're going to call something, rather than
> actually working on getting stuff done for the release or reviewing changes.
> I'm tired of constant bureaucratic distraction. I believe it has to be
> demoralizing to the development community.

I hear you loud and clear Matt. unfortunately this affects how our
community is viewed/perceived and will have an effect for our health
long term.

> I'm not trying to offend or troll so much as vent some frustration.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology



On 15/06/17 03:23 PM, Doug Hellmann wrote:
>
> We are very open with our hosting, allowing projects that have not
> yet, and may never, sign up to be governed by the TC to use our
> infrastructure services. We expect them to be related in some way,
> but we have even imported projects when we've taken over maintenance
> (several Oslo libs fall into this category, as do a few others like
> mox3 and sqlalchemy-migrate). With the move away from stackforge,
> and other changes in that hosting (that were made for good reasons
> to make the infra team's lives easier and to make it simpler for a
> project to join the set of governed projects), we have removed most
> of the other technical signals about which projects are in that
> "official" list and which are not.  We did not at the same time
> remove all of the people in the world who want to understand what
> is, and what is not, "in" OpenStack.

i see, so this is less an existential question of 'what is openstack' 
and more 'how to differentiate governance projects from a random repo 
created last weekend'

this might have been just me, but big tent was exactly 'big tent == 
governance' so when i read 'moving away from "big tent"' i think 'what 
is this *new* thing we're moving to and if we're redefining this new 
thing, what for?'. it seems this is not the case.

> And for the record, from the TC's perspective, being a governed
> project has nothing to do with whether the participants are sponsors
> of the foundation.

sorry, i probably wasn't clear, i simply noticed that it was a corporate 
sponsor that was misusing the 'big tent' name so was just thinking we 
could easily tell them, that's not what it means. wasn't suggesting 
anything else by sponsor comment.


-- 
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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Matt Riedemann


On 6/15/2017 9:57 AM, Thierry Carrez wrote:

Obviously we are not the target audience for that term. I think we are
deep enough in OpenStack and technically-focused enough to see through
that. But reality is, the majority of the rest of the world is confused,
and needs help figuring it out. Giving the category a name is a way to
do that.


Maybe don't ask the inmates what the asylum/prison should be called. Why 
don't we have people that are confused about this weighing in on this 
thread? Oh right because they don't subscribe to, or read, or reply to a 
development mailing list.


God I feel like I waste an inordinate amount of time each week reading 
about what new process or thing we're going to call something, rather 
than actually working on getting stuff done for the release or reviewing 
changes. I'm tired of constant bureaucratic distraction. I believe it 
has to be demoralizing to the development community.


I'm not trying to offend or troll so much as vent some frustration.

--

Thanks,

Matt

__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Rochelle Grober

OK.  So, our naming is like branding.  We are techies -- not good at marketing. 
 But, gee, the foundation has a marketing team.  And they end up fielding a lot 
of the confusing questions from companies not deeply entrenched in the 
OpenStack Dev culture.  Perhaps it would be worth explaining what we are trying 
to do to the marketing team and let them suggest some branding words.

What we would need to do pretty much goes back to Chris and Gord's emails about 
answering the questions of what we mean by "Openstack Project" and  "projects 
we allow to use our infrastructure in pursuit of something that somehow works 
with OpenStack projects".  If we provide marketing with a solid definition of 
what is an OpenStack project (we have that one down fairly well, but they might 
ask about core or other things we haven't debated in a while), and provide them 
with what those other projects have in common besides being hosted by us, they 
might come up with something that works for them and is ok for us.  Remember, 
they get hit with it a lot more than we do at this point.

So what we need is:

* detailed definition of "OpenStack Project" (maybe based on answering those 
questions Chris proposed plus others)
* good definition of what the "others" hosted on our infrastructure are/are 
expected to be
* removal of "big tent" from everywhere (aside/non sequitur -- There was a doge 
of Venice that got deposed for treason and his visage and name were eradicated 
from all buildings, documents, etc.  He also happened to be the inventor of the 
chastity belt)
* introduce the marketing guys to the definitions and the branding issue
* call in OpenStack projects and Others until we have a reasonable brand for 
Others.

--Rocky 

Thierry Carrez Wrote:
> Jeremy Stanley wrote:
> > On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> I'd like to propose that we introduce a new concept:
> >> "OpenStack-Hosted projects". There would be "OpenStack projects" on
> >> one side, and "Projects hosted on OpenStack infrastructure" on the
> >> other side (all still under the openstack/ git repo prefix).
> >
> > I'm still unconvinced a term is needed for this. Can't we just have
> > "OpenStack Projects" (those under TC governance) and "everything
> > else?" Why must the existence of any term require a term for its
> > opposite?
> 
> Well, we tried that for 2.5 years now, and people are still confused about
> which projects are an Openstack project and what are not. The confusion led
> to the perception that everything under openstack/ is an openstack project.
> It led to the perception that "big tent" means "anything goes in" or "flea
> market".
> 
> Whether we like it or not, giving a name to that category, a name that people
> can refer to (not "projects under openstack infrastructure that are not
> officially recognized by the TC"), is I think the only way out of this 
> confusion.
> 
> Obviously we are not the target audience for that term. I think we are deep
> enough in OpenStack and technically-focused enough to see through that.
> But reality is, the majority of the rest of the world is confused, and needs
> help figuring it out. Giving the category a name is a way to do that.
> 
> --
> 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][qa][glance] some recent tempest problems

Excerpts from Brian Rosmaita's message of 2017-06-15 13:04:39 -0400:
> This isn't a glance-specific problem though we've encountered it quite
> a few times recently.
> 
> Briefly, we're gating on Tempest jobs that tempest itself does not
> gate on.  This leads to a situation where new tests can be merged in
> tempest, but wind up breaking our gate. We aren't claiming that the
> added tests are bad or don't provide value; the problem is that we
> have to drop everything and fix the gate.  This interrupts our current
> work and forces us to prioritize bugs to fix based not on what makes
> the most sense for the project given current priorities and resources,
> but based on whatever we can do to get the gates un-blocked.
> 
> As we said earlier, this situation seems to be impacting multiple projects.
> 
> One solution for this is to change our gating so that we do not run
> any Tempest jobs against Glance repositories that are not also gated
> by Tempest.  That would in theory open a regression path, which is why
> we haven't put up a patch yet.  Another way this could be addressed is
> by the Tempest team changing the non-voting jobs causing this
> situation into voting jobs, which would prevent such changes from
> being merged in the first place.  The key issue here is that we need
> to be able to prioritize bugs based on what's most important to each
> project.
> 
> We want to be clear that we appreciate the work the Tempest team does.
> We abhor bugs and want to squash them too.  The problem is just that
> we're stretched pretty thin with resources right now, and being forced
> to prioritize bug fixes that will get our gate un-blocked is
> interfering with our ability to work on issues that may have a higher
> impact on end users.
> 
> The point of this email is to find out whether anyone has a better
> suggestion for how to handle this situation.
> 
> Thanks!
> 
> Erno Kuvaja
> Glance Release Czar
> 
> Brian Rosmaita
> Glance PTL
> 

Asymmetric gating definitely has a way of introducing these problems.

Which jobs are involved?

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] [Openstack-dev] [Congress] [Designate]

2017-06-15 Thread Eric K

Hi Carmine,

Yes, I¹d guess that the translator you defined attempted to go deeper than
the structure obtained by API. If you push the changes to
review.openstack.org you may get better feedback =)

Eric

From:  Carmine Annunziata 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Thursday, June 15, 2017 at 12:51 AM
To:  
Subject:  [openstack-dev] [Openstack-dev] [Congress] [Designate]

> Hi everyone,
> I wrote a congress datasource driver and its unit test for designate, but i
> got the following errors in the method test_update_from_datasource. It's
> something wrong in the translation.
> Here is the traceback:
> 
>  File "congress/tests/datasources/test_designate_driver.py", line 34, in setUp
> self.driver = designate_driver.DesignateDriver(args=args)
>   File "congress/datasources/designate_driver.py", line 150, in __init__
> super(DesignateDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 1282, in __init__
> super(PollingDataSourceDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 324, in __init__
> self.initialize_translators()
>   File "congress/datasources/datasource_driver.py", line 1324, in
> initialize_translators
> self.register_translator(translator)
>   File "congress/datasources/datasource_driver.py", line 457, in
> register_translator
> self._validate_translator(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 389, in
> _validate_hdict_type
> self._validate_translator(subtranslator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 386, in
> _validate_hdict_type
> self.check_params(field_translator.keys(),
> AttributeError: 'str' object has no attribute 'keys'
> 
> Thank you,
> Carmine
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

Excerpts from Jay Pipes's message of 2017-06-15 12:06:53 -0400:
> On 06/15/2017 11:59 AM, Thierry Carrez wrote:
> > Jay Pipes wrote:
> >> While I personally agree that Fuel should be moved out of the official
> >> projects list, I'd like to point out that Triple-O is virtually entirely
> >> a Red Hat project:
> >>
> >> http://stackalytics.com/?module=tripleo-group
> >> http://stackalytics.com/?module=tripleo-group=commits
> >>
> >> so the fact that a project is entirely run by a single vendor or "has
> >> popularity outside one vendor's customer base" has not been and
> >> continues not to be a deciding factor on whether something is an
> >> official OpenStack project or not.
> > 
> > Right, it's certainly not sufficient reason. The main difference between
> > the two is that activity in TripleO is actually growing, so there is
> > still a chance that it may attract a more diverse base in the future.
> 
> Sure, it may very well be. My point was that team diversity isn't a 
> defining characteristic of "officialness" in OpenStack. If it was, we'd 
> have far fewer "official" projects.
> 
> Best,
> -jay
> 

Right. We said that we would not block projects from joining just
because the contributors were mostly coming from one source *because* we
wanted to let teams attract new contributors, and we were told that some
companies would only allow their employees to work on official projects.

In my mind, it is far more important that the project doesn't seem
very healthy/active right now. I would be happy to hear that I am
wrong in that impression, though.

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] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Emilien Macchi

On Thu, Jun 15, 2017 at 12:05 PM, Jay Pipes  wrote:
> On 06/15/2017 11:56 AM, Ben Nemec wrote:
>>
>> Full disclosure: I primarily work on TripleO so I do have a horse in this
>> race.
>>
>> On 06/15/2017 10:33 AM, Jay Pipes wrote:
>>>
>>> On 06/15/2017 10:35 AM, Jeremy Stanley wrote:

 On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
 [...]
>
> I think that, despite the efforts of the Fuel team, Fuel did not become
> what we hoped when we made it official: a universal installer that
> would
> be used across the board. It was worth a try, I'm happy that we tried,
> but I think it's time to stop considering it a part of "OpenStack"
> proper and make it a hosted project. It can of course continue its
> existence as an unofficial project hosted on OpenStack infrastructure.
>
> Thoughts ?


 I agree, it makes sense to be more clear as to the lack of
 community-wide support for that effort. Perhaps if its popularity
 increases outside one vendor's customer base to the point where
 contributions from a broader set of stakeholders emerge, we can once
 again evaluate its governance state.
>>>
>>>
>>> While I personally agree that Fuel should be moved out of the official
>>> projects list, I'd like to point out that Triple-O is virtually entirely
>>> a Red Hat project:
>>>
>>> http://stackalytics.com/?module=tripleo-group
>>> http://stackalytics.com/?module=tripleo-group=commits
>>>
>>> so the fact that a project is entirely run by a single vendor or "has
>>> popularity outside one vendor's customer base" has not been and
>>> continues not to be a deciding factor on whether something is an
>>> official OpenStack project or not.
>>
>>
>> I don't believe the single vendor-ness of the project is the reason it's
>> being proposed for removal.  It's the fact that the single vendor has all
>> but dropped their support for it.  If Red Hat suddenly decided they were
>> pulling out of TripleO I'd expect the same response, but that is not the
>> case.
>
>
> Please see Jeremy's paragraph directly above my response. He specifically
> mentions single-vendor-ness as a reason for removal.
>
>>> I'd fully support the removal of all deployment projects from the
>>> "official OpenStack projects list".
>>
>>
>> I would not.  Deployment of OpenStack remains one of the most difficult to
>> solve problems and I would be highly disappointed in the community if they
>> essentially washed their hands of it.
>
>
> This right here is the perfect example of what Thierry is getting at with
> the *perceived value* of the term "Big Tent" or "Official OpenStack
> project". :(
>
> What about having deployment projects be "non-official" or "ecosystem" or
> "community" projects means that "the community ... essentially washed their
> hands of it"? :( You are putting words in my mouth and making a false
> equivalence between "community project" and "of lesser value". And that's
> precisely the problem these terms: people read way too much into them.
>
>> There are considerably more deployment projects than just TripleO and
>> Fuel, and there is more collaboration going on there than a simple
>> commits metric would show. For example, see
>> http://specs.openstack.org/openstack/oslo-specs/specs/pike/machine-readable-sample-config.html
>>  which came out of a cross-deployment project session at the PTG as a
>> way to solve a problem that all deployment tools have.
>
>
> Ben, I don't doubt this and as I've said publicly, I 100% support the joint
> deployment efforts and collaboration.
>
>> We should be encouraging more community involvement in deployment tools,
>> not sending the message that deployment tools are not important enough to be
>> official projects.
>
>
> What better way to encourage *community involvement* by saying all
> deployment tools are *community projects*?

I think I understand what you're pointing out here and in the same
time I understand Ben's opinion.
We have been working hard on collaborating with other OpenStack
projects in many ways (I don't think we need to give examples here)
that folks would be scared of the fact to stop being an official
project.

I see two eventual impacts (open for discussion) that I would see if
we (deployment projects) would become unofficial:

* some Deployment projects are working harder than some others not
part of the Big Tent to collaborate with other OpenStack projects.
This collaboration gave some notoriety and we're now able to tell
which Deployment projects are mature and the ones who aren't yet (I
know it's opinionated but some Deployment tools not part of the Big
Tent haven't demonstrated yet a wide collaboration in OpenStack
community). So if we become unofficial and are all put in the same
bucket, it would be hard for newcomers in the community to understand
which projects are really collaborating and mature and the one who
aren't.

* we would need to make sure these projects

Re: [openstack-dev] [vitrage-dashboard] Alarm Header Blueprint

2017-06-15 Thread Waines, Greg

Alon,
Just checking if you’ve had a chance to look at the following blueprint:
https://blueprints.launchpad.net/vitrage-dashboard/+spec/alarm-header

The HORIZON blueprint that it depends on is, I believe, on the verge of
being approved ... Horizon maintainers want to move forward with it,
they’ve assigned a priority to the blueprint ... I think that means it will
move to Approved.

anyways,
would be interested in any comments you have on the Vitrage-Dashboard
blueprint,
Greg.



From: Greg Waines 
Date: Thursday, June 8, 2017 at 7:58 AM
To: "openstack-dev@lists.openstack.org" 
Cc: "Heller, Alon (Nokia - IL/Kfar Sava)" , "Afek, Ifat 
(Nokia - IL/Kfar Sava)" 
Subject: [openstack-dev] [vitrage-dashboard] Alarm Header Blueprint

I have registered a new blueprint in Vitrage-dashboard which leverages the 
proposed extensible headers of Horizon.

https://blueprints.launchpad.net/vitrage-dashboard/+spec/alarm-header

let me know your thoughts,
Greg


p.s proposed extensible header blueprint in horizon is here:
   https://blueprints.launchpad.net/horizon/+spec/extensible-header



From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Date: Wednesday, June 7, 2017 at 4:52 AM
To: Greg Waines 
Cc: "Heller, Alon (Nokia - IL/Kfar Sava)" 
Subject: Re: vitrage-dashboard blueprints / specs

Hi Greg,

Adding Alon, a vitrage-dashboard core contributor.

In general, your plan seems great ☺ indeed, we don’t have many blueprints in 
vitrage-dashboard launchapd… the vitrage-dashboard team usually just implement 
the features and do code reviews without too many specs. You are welcome to 
write a blueprint-only description, and maybe send us (or add to the 
blueprintß) a UI mock.

Let us know if you need any help with that.

Best Regards,
Ifat.


From: "Waines, Greg" 
Date: Wednesday, 7 June 2017 at 1:33
To: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Subject: vitrage-dashboard blueprints / specs

Ifat,
Vitrage-dashboard seems to have very short 1-2 sentence blueprints and no spec 
files.

The Vitrage Alarm Count in Horizon Header work has turned into 3x blueprints now
- alarm-counts-api  in  Vitrage
- extensible-headers  in  Horizon <-- I am in process of 
submitting this to Horizon
- alarm-header  in  Vitrage-Dashboard

What do you suggest for the blueprint / spec for Vitrage-Dashboard ?
I could submit a blueprint using the blueprint-only template used by Horizon.

let me know what you think,
Greg.


__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

Excerpts from gordon chung's message of 2017-06-15 18:56:22 +:
> 
> On 15/06/17 02:05 PM, Davanum Srinivas wrote:
> > Example from https://www.meetup.com/openstack/events/237621777/
> > "Platform9 recently open-sourced Project Mors and VM HA as part of the
> > OpenStack Big Tent initiative."
> 
> ah i see, i imagine you could correct those who are corporate sponsors 
> (and send in the suits for those who aren't. j/k).
> 
> it seems like we want to drop "big tent" because marketers ruined it but 
> i'm still not sure we've formalised why we need a replacement (not 
> saying we don't).
> 

One of the *most* common complaints the TC gets from outside the
contributor community is that people do not understand what projects
are part of OpenStack and what parts are not. We have a clear
definition of that in our minds (the projects that have said they
want to be part of OpenStack, and agreed to put themselves under
TC governance, with all of the policies that implies). That definition
is so trivial to say, that it seems like a tautology.  However,
looking in from the outside of the community, that definition isn't
helpful.

We are very open with our hosting, allowing projects that have not
yet, and may never, sign up to be governed by the TC to use our
infrastructure services. We expect them to be related in some way,
but we have even imported projects when we've taken over maintenance
(several Oslo libs fall into this category, as do a few others like
mox3 and sqlalchemy-migrate). With the move away from stackforge,
and other changes in that hosting (that were made for good reasons
to make the infra team's lives easier and to make it simpler for a
project to join the set of governed projects), we have removed most
of the other technical signals about which projects are in that
"official" list and which are not.  We did not at the same time
remove all of the people in the world who want to understand what
is, and what is not, "in" OpenStack.

So, we need to find a way to answer that question. As Thierry said,
one way is to have 2 names to describe the 2 states. Big Tent used
to be one such name, except that we have learned that term was
unclear to a bunch of people (insert joke about how hard naming
things can be here).

Other communities don't seem to have this problem, because they either
don't host projects that are not part of their umbrella, or they don't
have projects moving in and out of governance so often.

And for the record, from the TC's perspective, being a governed
project has nothing to do with whether the participants are sponsors
of the foundation. The minute it does, I will step down. As part
of continuing to have a healthy community, we want to attract new
members, regardless of whether they are coming with money (and in
fact being an individual member is free).  We look at whether
projects (a) ask to be and (b) follow the guidelines we've set down.
We do look at who is contributing, but only when we consider the
various team diversity tags, none of which are required to be a
governed project.

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][tc] Moving away from "big tent" terminology

On 15/06/17 02:05 PM, Davanum Srinivas wrote:
> Example from https://www.meetup.com/openstack/events/237621777/
> "Platform9 recently open-sourced Project Mors and VM HA as part of the
> OpenStack Big Tent initiative."

ah i see, i imagine you could correct those who are corporate sponsors 
(and send in the suits for those who aren't. j/k).

it seems like we want to drop "big tent" because marketers ruined it but 
i'm still not sure we've formalised why we need a replacement (not 
saying we don't).

-- 
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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

2017-06-15 Thread Harry Rybacki

On Thu, Jun 15, 2017 at 1:57 PM, Brant Knudson  wrote:
>
>
> On Thu, Jun 15, 2017 at 5:14 AM, Mikhail Fedosin  wrote:
>>
>> Recently I decided to remove deprecated parameters from keystone_authtoken
>> mistral config and replace them with recommended function of devstack [1].
>> In doing so, I discovered a strange behavior of configuration mechanism, and
>> specifically parameters auth_uri and auth_url.
>>
>> 1. The parameter auth_url is not included in the list of the middleware
>> parameters, there is auth_uri only [2]. Nevertheless, it must be present,
>> because it's required by identity plugin [3]. Attempts to remove or replace
>> it with the recommended auth_uri result with these stacktraces [4]
>>
>> 2. Even if auth_url is set, it can't be used later, because it is not
>> registered in oslo_config [5]
>>
>> So I would like to get an advise from keystone team and understand what I
>> should do in such cases. Official documentation doesn't add clarity on the
>> matter because it recommends to use auth_uri in some cases and auth_url in
>> others.
>
>
> While to a human auth_uri and auth_url might look very similar they're
> treated completely differently by auth_token / keystoneauth. One doesn't
> replace the other in any way. So it shouldn't be surprising that
> documentation would say to use auth_uri for one thing and auth_url for
> something else.
>
In this case it's probably worth filing a docs bug against Keystone.
If one person is confused by this, others likely are or will be.

- Harry

>  - Brant
>
>
>>
>> My suggestion is to add auth_url in the list of keystone authtoken
>> middleware config options, so that the parameter can be used by the others.
>>
>> Best,
>> Mike
>>
>> [1] https://review.openstack.org/#/c/473796/
>> [2]
>> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L31
>> [3]
>> https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/identity.py#L37
>> [4] http://paste.openstack.org/show/612662/
>> [5] http://paste.openstack.org/show/612664/
>>
>> __
>> OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

Sorry, re-reading my email :)

On Thu, Jun 15, 2017 at 1:38 PM, gordon chung  wrote:
>
>
> On 15/06/17 01:17 PM, Davanum Srinivas wrote:
>> [DIMS] Tons of folks confused about "Big-Tent", folks are confusing
>> that label with "projects under governance".

What i meant was "Folks are equating Big-Tent with all projects in our
git repo and not just projects-under-governance"

Example from https://www.meetup.com/openstack/events/237621777/
"Platform9 recently open-sourced Project Mors and VM HA as part of the
OpenStack Big Tent initiative."

> wait, the big tent isn't the projects under governance? that's what i
> thought it was based on all the noise... more confused than i thought.
>
> so if what we're trying to do is emphasis/segregate these project under
> governance, what for?  who's the target audience of: "here are some
> projects that use the openstack name, have 1+ people working on it, are
> 'open', have some testing"?
>
> cheers,
>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [horizon] Extensible Header Blueprint

2017-06-15 Thread Waines, Greg

Just wondering if Horizon Team has had a chance to review the following 
blueprint:

https://blueprints.launchpad.net/horizon/+spec/extensible-header

let me know,
interested in your feedback,
Greg.

From: Greg Waines 
Date: Thursday, June 8, 2017 at 7:53 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [horizon] Extensible Header Blueprint

I have registered a new blueprint to address the extensible header functionality
discussed below.

https://blueprints.launchpad.net/horizon/+spec/extensible-header

interested in your feedback,
Greg.

From: David Lyle 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, June 1, 2017 at 12:50 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [horizon] Blueprint process question

There have been a couple of projects that would like some space in the
page header. I think the work in Horizon is to provide an extensible
space in the page header for plugins to post content. The UI plugin
for Vitrage, in this case, would then be responsible for populating
that content if desired. This specific blueprint should really be
targeted at the Vitrage UI plugin and a separate blueprint should be
added to Horizon to create the extension point in the page header.

David

On Wed, May 31, 2017 at 11:06 AM, Waines, Greg
> wrote:
Hey Rob,

Just thought I’d check in on whether Horizon team has had a chance to review
the following blueprint:

https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar

The blueprint in Vitrage which the above Horizon blueprint depends on has
been approved by Vitrage team.

i.e.   https://blueprints.launchpad.net/vitrage/+spec/alarm-counts-api

let me know if you’d like to setup a meeting to discuss,

Greg.

From: Rob Cresswell 
>
Reply-To: 
"openstack-dev@lists.openstack.org"
>
Date: Thursday, May 18, 2017 at 11:40 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [horizon] Blueprint process question

There isn't a specific time for blueprint review at the moment. It's usually
whenever I get time, or someone asks via email or IRC. During the weekly
meetings we always have time for open discussion of bugs/blueprints/patches
etc.

Rob

On 18 May 2017 at 16:31, Waines, Greg 
> wrote:

A blueprint question for horizon team.

I registered a new blueprint the other day.

https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar

Do I need to do anything else to get this reviewed?  I don’t think so, but
wanted to double check.

How frequently do horizon blueprints get reviewed?  once a week?

Greg.

p.s. ... the above blueprint does depend on a Vitrage blueprint which I do
have in review.

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

__
OpenStack Development Mailing 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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

2017-06-15 Thread Brant Knudson

On Thu, Jun 15, 2017 at 5:14 AM, Mikhail Fedosin  wrote:

> Recently I decided to remove deprecated parameters from keystone_authtoken
> mistral config and replace them with recommended function of devstack [1].
> In doing so, I discovered a strange behavior of configuration mechanism,
> and specifically parameters auth_uri and auth_url.
>
> 1. The parameter auth_url is not included in the list of the middleware
> parameters, there is auth_uri only [2]. Nevertheless, it must be present,
> because it's required by identity plugin [3]. Attempts to remove or replace
> it with the recommended auth_uri result with these stacktraces [4]
>
> 2. Even if auth_url is set, it can't be used later, because it is not
> registered in oslo_config [5]
>
> So I would like to get an advise from keystone team and understand what I
> should do in such cases. Official documentation doesn't add clarity on the
> matter because it recommends to use auth_uri in some cases and auth_url in
> others.
>

While to a human auth_uri and auth_url might look very similar they're
treated completely differently by auth_token / keystoneauth. One doesn't
replace the other in any way. So it shouldn't be surprising that
documentation would say to use auth_uri for one thing and auth_url for
something else.

 - Brant



> My suggestion is to add auth_url in the list of keystone authtoken
> middleware config options, so that the parameter can be used by the others.
>
> Best,
> Mike
>
> [1] https://review.openstack.org/#/c/473796/
> [2] https://github.com/openstack/keystonemiddleware/blob/
> master/keystonemiddleware/auth_token/_opts.py#L31
> [3] https://github.com/openstack/keystoneauth/blob/master/
> keystoneauth1/loading/identity.py#L37
> [4] http://paste.openstack.org/show/612662/
> [5] http://paste.openstack.org/show/612664/
>
> __
> OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On 15/06/17 01:17 PM, Davanum Srinivas wrote:
> [DIMS] Tons of folks confused about "Big-Tent", folks are confusing
> that label with "projects under governance".

wait, the big tent isn't the projects under governance? that's what i 
thought it was based on all the noise... more confused than i thought.

so if what we're trying to do is emphasis/segregate these project under 
governance, what for?  who's the target audience of: "here are some 
projects that use the openstack name, have 1+ people working on it, are 
'open', have some testing"?

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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Michał Jastrzębski

First of all, we definitely need that distinction to be clear.
Second, what are incentives to actually be an OpenStack project?
1. TC oversight - it's more a requirement than incentive
2. PTG space - definitely incentive
...anything else?

What else? TC has an important role, we need oversight to keep
OpenStack tidy, working together, follow four opens and all that. But
to agree for TC oversight (which you could argue makes life harder,
more rules to adhere to) project has to be an OpenStack project. How
do we push projects to join?

On 15 June 2017 at 10:17, Davanum Srinivas  wrote:
> On Thu, Jun 15, 2017 at 1:01 PM, gordon chung  wrote:
>>
>>
>> On 15/06/17 11:28 AM, Davanum Srinivas wrote:
>>> The purpose (my 2 cents) is to highlight what projects are under
>>> governance and those that are not.
>>
>> going down the rabbit hole, what does it mean to be under governance?
>> projects that want to use the openstack brand and were, at the time of
>> acceptance, supported some subset[1] of: 'open',
> [DIMS] Yes,
>> had some testing,
> [DIMS] Yes
>> supported keystone,
> [DIMS] No. It was never mandatory
> had a human resource?
> [DIMS] Yes, hopefully a bunch of people work on it
>  i don't really see how this
>> differs from big tent?
> [DIMS] Tons of folks confused about "Big-Tent", folks are confusing
> that label with "projects under governance".
> seems more like the same but without the
>> 'big-tent' stigma?
> [DIMS] Not sure about stigma. The label is useless right now.
>
>
>
>>
>> are we hoping openstack foundation to be a cloud-specific apache
>> foundation? maybe it already is, and if so, i don't really understand
>> the additional labeling we're trying to achieve.
>>
>> [1]
>> https://governance.openstack.org/tc/reference/new-projects-requirements.html
>>
>> --
>> gord
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [glance] priorities for the coming week (06/16-06/22)

2017-06-15 Thread Brian Rosmaita

As discussed at today's Glance meeting, the priorities for this week are:

1  WSGI community goal
- 
https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
- https://review.openstack.org/#/c/459451/

Just one priority, let's knock this out this week.  It will clear the
deck for next week, so we can focus on the image import refactor work
Erno's got underway.

In other news:

Thanks to Erno, the Glance Release Czar, for getting the P-2 milestone
release out on time!


cheers,
brian

__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 1:01 PM, gordon chung  wrote:
>
>
> On 15/06/17 11:28 AM, Davanum Srinivas wrote:
>> The purpose (my 2 cents) is to highlight what projects are under
>> governance and those that are not.
>
> going down the rabbit hole, what does it mean to be under governance?
> projects that want to use the openstack brand and were, at the time of
> acceptance, supported some subset[1] of: 'open',
[DIMS] Yes,
> had some testing,
[DIMS] Yes
> supported keystone,
[DIMS] No. It was never mandatory
had a human resource?
[DIMS] Yes, hopefully a bunch of people work on it
 i don't really see how this
> differs from big tent?
[DIMS] Tons of folks confused about "Big-Tent", folks are confusing
that label with "projects under governance".
seems more like the same but without the
> 'big-tent' stigma?
[DIMS] Not sure about stigma. The label is useless right now.



>
> are we hoping openstack foundation to be a cloud-specific apache
> foundation? maybe it already is, and if so, i don't really understand
> the additional labeling we're trying to achieve.
>
> [1]
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread Tim Bell

And since Electrons are neither waves or particles, it is difficult to pin them 
down (

https://en.wikipedia.org/wiki/Wave%E2%80%93particle_duality

Tim

-Original Message-
From: Sean McGinnis 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 15 June 2017 at 18:36
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent"  
terminology

On Thu, Jun 15, 2017 at 03:41:30PM +, Tim Bell wrote:
> OpenStack Nucleus and OpenStack Electrons?
> 
> Tim
> 

Hah, love it!


__
OpenStack Development Mailing 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] Containers Deep Dive - 15th June

2017-06-15 Thread Harry Rybacki

Thanks for putting this together, Jirka. The recording is very much
worth anyone's time!

On Thu, Jun 15, 2017 at 12:36 PM, Jiří Stránský  wrote:
> On 15.6.2017 18:25, Jiří Stránský wrote:
>>
>> On 9.6.2017 16:49, Jiří Stránský wrote:
>>>
>>> Hello,
>>>
>>> as discussed previously on the list and at the weekly meeting, we'll do
>>> a deep dive about containers. The time:
>>>
>>> Thursday 15th June, 14:00 UTC (the usual time)
>>>
>>> Link for attending will be at the deep dives etherpad [1], preliminary
>>> agenda is in another etherpad [2], and i hope i'll be able to record it
>>> too.
>>
>>
>> The recording is available here:
>>
>> https://www.youtube.com/watch?v=xhTwHfi65p8
>
>
> And the slides:
>
> https://jistr.github.io/tripleo-deep-dive-containers-june-2017/
>
>
>>
>> Thanks Carlos for managing our youtube channel!
>>
>> Jirka
>>
>>>
>>> This time it may be more of a "broad dive" :) as that's what containers
>>> in TripleO mostly are -- they add new bits into many TripleO
>>> areas/topics (composable services/upgrades, Quickstart/CI, etc.). So
>>> i'll be trying to bring light to the container-specific parts of the
>>> mix, and assume some familiarity with the generic TripleO
>>> concepts/features (e.g. via docs and previous deep dives). Given this
>>> pattern, i'll have slides with links into code. I'll post them online,
>>> so that you can reiterate or examine some code more closely later, in
>>> case you want to.
>>>
>>>
>>> Have a good day!
>>>
>>> Jirka
>>>
>>> [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>>> [2] https://etherpad.openstack.org/p/tripleo-deep-dive-containers
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [deployment][kolla][openstack-ansible][openstack-helm][tripleo] ansible role to produce oslo.config files for openstack services

2017-06-15 Thread Emilien Macchi

I missed [tripleo] tag.

On Thu, Jun 15, 2017 at 12:09 PM, Emilien Macchi  wrote:
> If you haven't followed the "Configuration management with etcd /
> confd" thread [1], Doug found out that using confd to generate
> configuration files wouldn't work for the Cinder case where we don't
> know in advance of the deployment what settings to tell confd to look
> at.
> We are still looking for a generic way to generate *.conf files for
> OpenStack, that would be usable by Deployment tools and operators.
> Right now, Doug and I are investigating some tooling that would be
> useful to achieve this goal.
>
> Doug has prototyped an Ansible role that would generate configuration
> files by consumming 2 things:
>
> * Configuration schema, generated by Ben's work with Machine Readable
> Sample Config.
>   $ oslo-config-generator --namespace cinder --format yaml > 
> cinder-schema.yaml
>
> It also needs: https://review.openstack.org/#/c/474306/ to generate
> some extra data not included in the original version.
>
> * Parameters values provided in config_data directly in the playbook:
>config_data:
>  DEFAULT:
>transport_url: rabbit://user:password@hostname
>verbose: true
>
> There are 2 options disabled by default but which would be useful for
> production environments:
> * Set to true to always show all configuration values: config_show_defaults
> * Set to true to show the help text: config_show_help: true
>
> The Ansible module is available on github:
> https://github.com/dhellmann/oslo-config-ansible
>
> To try this out, just run:
>   $ ansible-playbook ./playbook.yml
>
> You can quickly see the output of cinder.conf:
> https://clbin.com/HmS58
>
>
> What are the next steps:
>
> * Getting feedback from Deployment Tools and operators on the concept
> of this module.
>   Maybe this module could replace what is done by Kolla with
> merge_configs and OpenStack Ansible with config_template.
> * On the TripleO side, we would like to see if this module could
> replace the Puppet OpenStack modules that are now mostly used for
> generating configuration files for containers.
>   A transition path would be having Heat to generate Ansible vars
> files and give it to this module. We could integrate the playbook into
> a new task in the composable services, something like
>   "os_gen_config_tasks", a bit like we already have for upgrade tasks,
> also driven by Ansible.
> * Another similar option to what Doug did is to write a standalone
> tool that would generate configuration, and for Ansible users we would
> write a new module to use this tool.
>   Example:
>   Step 1. oslo-config-generator --namespace cinder --format yaml >
> cinder-schema.yaml (note this tool already exists)
>   Step 2. Create config_data.yaml in a specific format with
> parameters values for what we want to configure (note this format
> doesn't exist yet but look at what Doug did in the role, we could use
> the same kind of schema).
>   Step 3. oslo-gen-config -i config_data.yaml -s schema.yaml >
> cinder.conf (note this tool doesn't exist yet)
>
>   For Ansible users, we would write an Ansible module that would
> take in entry 2 files: the schema and the data. The module would just
> run the tool provided by oslo.config.
>   Example:
>   - name: Generate cinder.conf
> oslo-gen-config: schema=cinder-schema.yaml
>data=config_data.yaml
>
>
> Please bring feedback and thoughts, it's really important to know what
> folks from Installers think about this idea; again the ultimate goal
> is to provide a reference tool to generate configuration in OpenStack,
> in a way that scales and is friendly for our operators.
>
> Thanks,
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118176.html
> --
> Emilien Macchi



-- 
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] [all][qa][glance] some recent tempest problems

2017-06-15 Thread Brian Rosmaita

This isn't a glance-specific problem though we've encountered it quite
a few times recently.

Briefly, we're gating on Tempest jobs that tempest itself does not
gate on.  This leads to a situation where new tests can be merged in
tempest, but wind up breaking our gate. We aren't claiming that the
added tests are bad or don't provide value; the problem is that we
have to drop everything and fix the gate.  This interrupts our current
work and forces us to prioritize bugs to fix based not on what makes
the most sense for the project given current priorities and resources,
but based on whatever we can do to get the gates un-blocked.

As we said earlier, this situation seems to be impacting multiple projects.

One solution for this is to change our gating so that we do not run
any Tempest jobs against Glance repositories that are not also gated
by Tempest.  That would in theory open a regression path, which is why
we haven't put up a patch yet.  Another way this could be addressed is
by the Tempest team changing the non-voting jobs causing this
situation into voting jobs, which would prevent such changes from
being merged in the first place.  The key issue here is that we need
to be able to prioritize bugs based on what's most important to each
project.

We want to be clear that we appreciate the work the Tempest team does.
We abhor bugs and want to squash them too.  The problem is just that
we're stretched pretty thin with resources right now, and being forced
to prioritize bug fixes that will get our gate un-blocked is
interfering with our ability to work on issues that may have a higher
impact on end users.

The point of this email is to find out whether anyone has a better
suggestion for how to handle this situation.

Thanks!

Erno Kuvaja
Glance Release Czar

Brian Rosmaita
Glance PTL

__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On 15/06/17 11:28 AM, Davanum Srinivas wrote:
> The purpose (my 2 cents) is to highlight what projects are under
> governance and those that are not.

going down the rabbit hole, what does it mean to be under governance? 
projects that want to use the openstack brand and were, at the time of 
acceptance, supported some subset[1] of: 'open', had some testing, 
supported keystone, had a human resource? i don't really see how this 
differs from big tent? seems more like the same but without the 
'big-tent' stigma?

are we hoping openstack foundation to be a cloud-specific apache 
foundation? maybe it already is, and if so, i don't really understand 
the additional labeling we're trying to achieve.

[1] 
https://governance.openstack.org/tc/reference/new-projects-requirements.html

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

[openstack-dev] [all][api] POST /api-wg/news

2017-06-15 Thread Chris Dent



Greetings OpenStack community,

Today's meeting was short and sweet. We merged some frozen reivews (see below) and 
determined that other pending reviews are still pending. The survey to get some feedback 
on how to express the earliest possible date a microversion might raise didn't get a ton 
of votes, but those votes that did happen suggest that the original 
"not_before" is the least worst choice.

# Newly Published Guidelines

The following reviews have all merged

* Add guideline about consuming endpoints from catalog
  https://review.openstack.org/#/c/462814/

* Add support for historical service type aliases
  https://review.openstack.org/#/c/460654/

* Describe the publication of service-types-authority data
  https://review.openstack.org/#/c/462815/

They all modified the same document, resulting in: 
http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A (shrinking) suite of several documents about doing version discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
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][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 03:41:30PM +, Tim Bell wrote:
> OpenStack Nucleus and OpenStack Electrons?
> 
> Tim
> 

Hah, love it!


__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Kirill Zaitsev

Not touching the separate gerrit topic, but I genuinely like the "community" 
name. In my opinion it very well covers the "projects not governed by TC" 
definition.

Regards, Kirill

> Le 15 июня 2017 г. à 18:28, Davanum Srinivas  a écrit :
> 
>> On Thu, Jun 15, 2017 at 11:17 AM, gordon chung  wrote:
>> 
>> 
>>> On 15/06/17 10:57 AM, Thierry Carrez wrote:
>>> Jeremy Stanley wrote:
> 
> I'm still unconvinced a term is needed for this. Can't we just have
> "OpenStack Projects" (those under TC governance) and "everything
> else?" Why must the existence of any term require a term for its
> opposite?
>>> Well, we tried that for 2.5 years now, and people are still confused
>>> about which projects are an Openstack project and what are not. The
>>> confusion led to the perception that everything under openstack/ is an
>>> openstack project. It led to the perception that "big tent" means
>>> "anything goes in" or "flea market".
>> 
>> regardless of terminology, i'm not entirely certain what everyone's
>> definition of an openstack project and > it> project is. additionally, what the purpose of this categorization is?
> 
> The purpose (my 2 cents) is to highlight what projects are under
> governance and those that are not.
> 
> Maybe we should call those not under governance as "community"
> projects, aggregate these under say community.openstack.org also run a
> second gerrit instance (community-git.openstack.org ?) so the
> separation is clear and distinct.
> 
> Thanks,
> Dims
> 
>> 
>> --
>> gord
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Containers Deep Dive - 15th June

2017-06-15 Thread Jiří Stránský


On 15.6.2017 18:25, Jiří Stránský wrote:

On 9.6.2017 16:49, Jiří Stránský wrote:

Hello,

as discussed previously on the list and at the weekly meeting, we'll do
a deep dive about containers. The time:

Thursday 15th June, 14:00 UTC (the usual time)

Link for attending will be at the deep dives etherpad [1], preliminary
agenda is in another etherpad [2], and i hope i'll be able to record it too.


The recording is available here:

https://www.youtube.com/watch?v=xhTwHfi65p8


And the slides:

https://jistr.github.io/tripleo-deep-dive-containers-june-2017/



Thanks Carlos for managing our youtube channel!

Jirka



This time it may be more of a "broad dive" :) as that's what containers
in TripleO mostly are -- they add new bits into many TripleO
areas/topics (composable services/upgrades, Quickstart/CI, etc.). So
i'll be trying to bring light to the container-specific parts of the
mix, and assume some familiarity with the generic TripleO
concepts/features (e.g. via docs and previous deep dives). Given this
pattern, i'll have slides with links into code. I'll post them online,
so that you can reiterate or examine some code more closely later, in
case you want to.


Have a good day!

Jirka

[1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
[2] https://etherpad.openstack.org/p/tripleo-deep-dive-containers

__
OpenStack Development Mailing 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] [tripleo] Containers Deep Dive - 15th June

2017-06-15 Thread Jiří Stránský


On 9.6.2017 16:49, Jiří Stránský wrote:

Hello,

as discussed previously on the list and at the weekly meeting, we'll do
a deep dive about containers. The time:

Thursday 15th June, 14:00 UTC (the usual time)

Link for attending will be at the deep dives etherpad [1], preliminary
agenda is in another etherpad [2], and i hope i'll be able to record it too.


The recording is available here:

https://www.youtube.com/watch?v=xhTwHfi65p8

Thanks Carlos for managing our youtube channel!

Jirka



This time it may be more of a "broad dive" :) as that's what containers
in TripleO mostly are -- they add new bits into many TripleO
areas/topics (composable services/upgrades, Quickstart/CI, etc.). So
i'll be trying to bring light to the container-specific parts of the
mix, and assume some familiarity with the generic TripleO
concepts/features (e.g. via docs and previous deep dives). Given this
pattern, i'll have slides with links into code. I'll post them online,
so that you can reiterate or examine some code more closely later, in
case you want to.


Have a good day!

Jirka

[1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
[2] https://etherpad.openstack.org/p/tripleo-deep-dive-containers

__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

Please note that this ended up being discussed during (and before and
after) the TC office hour today on #openstack-tc:

For those interested, see:

http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-06-15.log.html#t2017-06-15T13:00:53

TL;DR: We are still deep in initial discussion, trying to wrap our heads
around the problem space and the potential solutions.

-- 
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] [tc][fuel] Making Fuel a hosted project

On 2017-06-15 12:05:42 -0400 (-0400), Jay Pipes wrote:
[...]
> Please see Jeremy's paragraph directly above my response. He
> specifically mentions single-vendor-ness as a reason for removal.
[...]

It is, when the danger of being single-vendor becomes manifest in
that vendor ceasing their interest in continuing to support the
project and nobody else seems to step forward to continue it.
-- 
Jeremy Stanley


signature.asc
Description: 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][tc] Moving away from "big tent" terminology

On 2017-06-15 11:07:11 -0400 (-0400), Sean Dague wrote:
[...]
> I do kind of wonder if we returned the stackforge or
> friends-of-openstack or whatever to the github namespace when we
> mirrored if it would clear a bunch of things up for people. It would
> just need to be an extra piece of info in our project list about where
> those projects should mirror to (which may not be the same namespace as
> in gerrit).

I don't immediately see any good way to do that with
https://gerrit.googlesource.com/plugins/replication/+doc/master/src/main/resources/Documentation/config.md
 >
so if that's something we wanted, we'd likely need to switch to a
different replication solution than the one Gerrit itself provides.

I'm also not thrilled with the idea of making the hoops we already
jump through to deal with GH mirroring any more complex, just for
the sake of people who want to use it instead of the systems we
maintain. It's not free software, probably never will be, and most
of the Infra team (me included) don't get any real joy from
supporting it in the first place.
-- 
Jeremy Stanley


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

[openstack-dev] [deployment][kolla][openstack-ansible][kolla][openstack-helm] ansible role to produce oslo.config files for openstack services

2017-06-15 Thread Emilien Macchi

If you haven't followed the "Configuration management with etcd /
confd" thread [1], Doug found out that using confd to generate
configuration files wouldn't work for the Cinder case where we don't
know in advance of the deployment what settings to tell confd to look
at.
We are still looking for a generic way to generate *.conf files for
OpenStack, that would be usable by Deployment tools and operators.
Right now, Doug and I are investigating some tooling that would be
useful to achieve this goal.

Doug has prototyped an Ansible role that would generate configuration
files by consumming 2 things:

* Configuration schema, generated by Ben's work with Machine Readable
Sample Config.
  $ oslo-config-generator --namespace cinder --format yaml > cinder-schema.yaml

It also needs: https://review.openstack.org/#/c/474306/ to generate
some extra data not included in the original version.

* Parameters values provided in config_data directly in the playbook:
   config_data:
 DEFAULT:
   transport_url: rabbit://user:password@hostname
   verbose: true

There are 2 options disabled by default but which would be useful for
production environments:
* Set to true to always show all configuration values: config_show_defaults
* Set to true to show the help text: config_show_help: true

The Ansible module is available on github:
https://github.com/dhellmann/oslo-config-ansible

To try this out, just run:
  $ ansible-playbook ./playbook.yml

You can quickly see the output of cinder.conf:
https://clbin.com/HmS58


What are the next steps:

* Getting feedback from Deployment Tools and operators on the concept
of this module.
  Maybe this module could replace what is done by Kolla with
merge_configs and OpenStack Ansible with config_template.
* On the TripleO side, we would like to see if this module could
replace the Puppet OpenStack modules that are now mostly used for
generating configuration files for containers.
  A transition path would be having Heat to generate Ansible vars
files and give it to this module. We could integrate the playbook into
a new task in the composable services, something like
  "os_gen_config_tasks", a bit like we already have for upgrade tasks,
also driven by Ansible.
* Another similar option to what Doug did is to write a standalone
tool that would generate configuration, and for Ansible users we would
write a new module to use this tool.
  Example:
  Step 1. oslo-config-generator --namespace cinder --format yaml >
cinder-schema.yaml (note this tool already exists)
  Step 2. Create config_data.yaml in a specific format with
parameters values for what we want to configure (note this format
doesn't exist yet but look at what Doug did in the role, we could use
the same kind of schema).
  Step 3. oslo-gen-config -i config_data.yaml -s schema.yaml >
cinder.conf (note this tool doesn't exist yet)

  For Ansible users, we would write an Ansible module that would
take in entry 2 files: the schema and the data. The module would just
run the tool provided by oslo.config.
  Example:
  - name: Generate cinder.conf
oslo-gen-config: schema=cinder-schema.yaml
   data=config_data.yaml


Please bring feedback and thoughts, it's really important to know what
folks from Installers think about this idea; again the ultimate goal
is to provide a reference tool to generate configuration in OpenStack,
in a way that scales and is friendly for our operators.

Thanks,

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118176.html
-- 
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] [tc][fuel] Making Fuel a hosted project


On 06/15/2017 11:59 AM, Thierry Carrez wrote:

Jay Pipes wrote:

While I personally agree that Fuel should be moved out of the official
projects list, I'd like to point out that Triple-O is virtually entirely
a Red Hat project:

http://stackalytics.com/?module=tripleo-group
http://stackalytics.com/?module=tripleo-group=commits

so the fact that a project is entirely run by a single vendor or "has
popularity outside one vendor's customer base" has not been and
continues not to be a deciding factor on whether something is an
official OpenStack project or not.


Right, it's certainly not sufficient reason. The main difference between
the two is that activity in TripleO is actually growing, so there is
still a chance that it may attract a more diverse base in the future.


Sure, it may very well be. My point was that team diversity isn't a 
defining characteristic of "officialness" in OpenStack. If it was, we'd 
have far fewer "official" projects.


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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

On 06/15/2017 11:56 AM, Ben Nemec wrote:
Full disclosure: I primarily work on TripleO so I do have a horse in
this race.

On 06/15/2017 10:33 AM, Jay Pipes wrote:

On 06/15/2017 10:35 AM, Jeremy Stanley wrote:

On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
[...]

I think that, despite the efforts of the Fuel team, Fuel did not become
what we hoped when we made it official: a universal installer that
would

be used across the board. It was worth a try, I'm happy that we tried,
but I think it's time to stop considering it a part of "OpenStack"
proper and make it a hosted project. It can of course continue its
existence as an unofficial project hosted on OpenStack infrastructure.

Thoughts ?

While I personally agree that Fuel should be moved out of the official
projects list, I'd like to point out that Triple-O is virtually entirely
a Red Hat project:

http://stackalytics.com/?module=tripleo-group
http://stackalytics.com/?module=tripleo-group=commits

I don't believe the single vendor-ness of the project is the reason it's
being proposed for removal. It's the fact that the single vendor has
all but dropped their support for it. If Red Hat suddenly decided they
were pulling out of TripleO I'd expect the same response, but that is
not the case.

Please see Jeremy's paragraph directly above my response. He
specifically mentions single-vendor-ness as a reason for removal.

I'd fully support the removal of all deployment projects from the
"official OpenStack projects list".

I would not. Deployment of OpenStack remains one of the most difficult
to solve problems and I would be highly disappointed in the community if
they essentially washed their hands of it.

This right here is the perfect example of what Thierry is getting at
with the *perceived value* of the term "Big Tent" or "Official OpenStack
project". :(

which came out of a cross-deployment project session at the PTG as a
way to solve a problem that all deployment tools have.

Ben, I don't doubt this and as I've said publicly, I 100% support the
joint deployment efforts and collaboration.

We should be encouraging more community involvement in deployment tools,
not sending the message that deployment tools are not important enough
to be official projects.

What better way to encourage *community involvement* by saying all
deployment tools are *community projects*?

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

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

Jay Pipes wrote:
> While I personally agree that Fuel should be moved out of the official
> projects list, I'd like to point out that Triple-O is virtually entirely
> a Red Hat project:
> 
> http://stackalytics.com/?module=tripleo-group
> http://stackalytics.com/?module=tripleo-group=commits
> 
> so the fact that a project is entirely run by a single vendor or "has
> popularity outside one vendor's customer base" has not been and
> continues not to be a deciding factor on whether something is an
> official OpenStack project or not.

Right, it's certainly not sufficient reason. The main difference between
the two is that activity in TripleO is actually growing, so there is
still a chance that it may attract a more diverse base in the future.

-- 
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] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Ben Nemec

Full disclosure: I primarily work on TripleO so I do have a horse in
this race.

On 06/15/2017 10:33 AM, Jay Pipes wrote:

On 06/15/2017 10:35 AM, Jeremy Stanley wrote:

On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
[...]

I think that, despite the efforts of the Fuel team, Fuel did not become
what we hoped when we made it official: a universal installer that would
be used across the board. It was worth a try, I'm happy that we tried,
but I think it's time to stop considering it a part of "OpenStack"
proper and make it a hosted project. It can of course continue its
existence as an unofficial project hosted on OpenStack infrastructure.

Thoughts ?

While I personally agree that Fuel should be moved out of the official
projects list, I'd like to point out that Triple-O is virtually entirely
a Red Hat project:

http://stackalytics.com/?module=tripleo-group
http://stackalytics.com/?module=tripleo-group=commits

I don't believe the single vendor-ness of the project is the reason it's
being proposed for removal. It's the fact that the single vendor has
all but dropped their support for it. If Red Hat suddenly decided they
were pulling out of TripleO I'd expect the same response, but that is
not the case.

I'd fully support the removal of all deployment projects from the
"official OpenStack projects list".

I would not. Deployment of OpenStack remains one of the most difficult
to solve problems and I would be highly disappointed in the community if
they essentially washed their hands of it. There are considerably more
deployment projects than just TripleO and Fuel, and there is more
collaboration going on there than a simple commits metric would show.
For example, see
http://specs.openstack.org/openstack/oslo-specs/specs/pike/machine-readable-sample-config.html
which came out of a cross-deployment project session at the PTG as a way
to solve a problem that all deployment tools have.

We should be encouraging more community involvement in deployment tools,
not sending the message that deployment tools are not important enough
to be official projects.

-Ben

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

On 2017-06-15 11:48:42 -0400 (-0400), Davanum Srinivas wrote:
> We took that tradeoff before and have suffered as a result. I'd say
> it's the cost of getting a project under governance.

Well, sort of. We took the slightly less work (for the Infra team)
approach of renaming repos within a single Gerrit instead of trying
to relocate projects between Gerrit deployments.

Ultimately, if the solution is to run a separate copy of our
infrastructure to host non-OpenStack projects, it might as well have
its own volunteer team running it. We're down to a skeleton crew as
it is, so I don't relish the idea of us being responsible for
maintaining an extra copy of all these services.
-- 
Jeremy Stanley


signature.asc
Description: 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][tc] Moving away from "big tent" terminology

Jeremy,

We took that tradeoff before and have suffered as a result. I'd say
it's the cost of getting a project under governance.

-- Dims

On Thu, Jun 15, 2017 at 11:38 AM, Jeremy Stanley  wrote:
> On 2017-06-15 11:28:23 -0400 (-0400), Davanum Srinivas wrote:
> [...]
>> Maybe we should call those not under governance as "community"
>> projects, aggregate these under say community.openstack.org also run a
>> second gerrit instance (community-git.openstack.org ?) so the
>> separation is clear and distinct.
>
> Expecting everyone to change Git and Gerrit URLs when becoming (or
> ceasing to be) official is still pretty painful.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology


On 06/15/2017 08:57 AM, Thierry Carrez wrote:

An alternative would be to give "the OpenStack project infrastructure"
some kind of a brand name (say, "Opium", for OpenStack project
infrastructure ultimate madness)


or... OpenStack Stadium, shortened.

__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Clay Gerrard

On Thu, Jun 15, 2017 at 8:07 AM, Sean Dague  wrote:

>
> I do kind of wonder if we returned the stackforge or
> friends-of-openstack or whatever to the github namespace when we
> mirrored if it would clear a bunch of things up for people. It would
> just need to be an extra piece of info in our project list about where
> those projects should mirror to (which may not be the same namespace as
> in gerrit).
>
>
Whoa.  

-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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread Tim Bell

OpenStack Nucleus and OpenStack Electrons?

Tim

-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 15 June 2017 at 14:57
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent"  
terminology

Sean Dague wrote:
> [...]
> I think those are all fine. The other term that popped into my head was
> "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> that aren't official projects. It may be too informal, but I do think
> the OpenStack-Hosted vs. OpenStack might still mix up in people's head.

My original thinking was to call them "hosted projects" or "host
projects", but then it felt a bit incomplete. I kinda like the "Friends
of OpenStack" name, although it seems to imply some kind of vetting that
we don't actually do.

An alternative would be to give "the OpenStack project infrastructure"
some kind of a brand name (say, "Opium", for OpenStack project
infrastructure ultimate madness) and then call the hosted projects
"Opium projects". Rename the Infra team to Opium team, and voilà!

-- 
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][tc] Moving away from "big tent" terminology

On 2017-06-15 11:28:23 -0400 (-0400), Davanum Srinivas wrote:
[...]
> Maybe we should call those not under governance as "community"
> projects, aggregate these under say community.openstack.org also run a
> second gerrit instance (community-git.openstack.org ?) so the
> separation is clear and distinct.

Expecting everyone to change Git and Gerrit URLs when becoming (or
ceasing to be) official is still pretty painful.
-- 
Jeremy Stanley


signature.asc
Description: 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] [tc][fuel] Making Fuel a hosted project


On 06/15/2017 10:35 AM, Jeremy Stanley wrote:

On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
[...]

I think that, despite the efforts of the Fuel team, Fuel did not become
what we hoped when we made it official: a universal installer that would
be used across the board. It was worth a try, I'm happy that we tried,
but I think it's time to stop considering it a part of "OpenStack"
proper and make it a hosted project. It can of course continue its
existence as an unofficial project hosted on OpenStack infrastructure.

Thoughts ?


I agree, it makes sense to be more clear as to the lack of
community-wide support for that effort. Perhaps if its popularity
increases outside one vendor's customer base to the point where
contributions from a broader set of stakeholders emerge, we can once
again evaluate its governance state.


While I personally agree that Fuel should be moved out of the official 
projects list, I'd like to point out that Triple-O is virtually entirely 
a Red Hat project:


http://stackalytics.com/?module=tripleo-group
http://stackalytics.com/?module=tripleo-group=commits

so the fact that a project is entirely run by a single vendor or "has 
popularity outside one vendor's customer base" has not been and 
continues not to be a deciding factor on whether something is an 
official OpenStack project or not.


I'd fully support the removal of all deployment projects from the 
"official OpenStack projects list".


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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 11:17 AM, gordon chung  wrote:
>
>
> On 15/06/17 10:57 AM, Thierry Carrez wrote:
>> Jeremy Stanley wrote:
>>> >
>>> > I'm still unconvinced a term is needed for this. Can't we just have
>>> > "OpenStack Projects" (those under TC governance) and "everything
>>> > else?" Why must the existence of any term require a term for its
>>> > opposite?
>> Well, we tried that for 2.5 years now, and people are still confused
>> about which projects are an Openstack project and what are not. The
>> confusion led to the perception that everything under openstack/ is an
>> openstack project. It led to the perception that "big tent" means
>> "anything goes in" or "flea market".
>
> regardless of terminology, i'm not entirely certain what everyone's
> definition of an openstack project and  it> project is. additionally, what the purpose of this categorization is?

The purpose (my 2 cents) is to highlight what projects are under
governance and those that are not.

Maybe we should call those not under governance as "community"
projects, aggregate these under say community.openstack.org also run a
second gerrit instance (community-git.openstack.org ?) so the
separation is clear and distinct.

Thanks,
Dims

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



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

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology



On 15/06/17 10:57 AM, Thierry Carrez wrote:
> Jeremy Stanley wrote:
>> >
>> > I'm still unconvinced a term is needed for this. Can't we just have
>> > "OpenStack Projects" (those under TC governance) and "everything
>> > else?" Why must the existence of any term require a term for its
>> > opposite?
> Well, we tried that for 2.5 years now, and people are still confused
> about which projects are an Openstack project and what are not. The
> confusion led to the perception that everything under openstack/ is an
> openstack project. It led to the perception that "big tent" means
> "anything goes in" or "flea market".

regardless of terminology, i'm not entirely certain what everyone's 
definition of an openstack project and  project is. additionally, what the purpose of this categorization is?

-- 
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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

2017-06-15 Thread Gyorgy Szombathelyi

> 
> >
> > auth_url is actually a dynamic parameter and depends on the
> keystone
> > auth plugin used
> > (auth_type=xxx). The plugin which needs this parameter, registers it.
> >
> >
> >
> > Based on this http://paste.openstack.org/show/612664/ I would say that
> > the plugin doesn't register it :( It either can be a bug, or it was
> > done intentionally, I don't know.
> >
> It should register it after you load it, via
> keystonauth1.loading.load_auth_plugin_from_conf_options()
> There are also register_auth_conf_options() and
> get_auth_plugin_conf_options,  which I think are mainly used for listing the
> most used plugins' options in the debug log. But I don't think it would be 
> wise
> just to choose a plugin and register its options for auth_url, because it is 
> ugly,
> I think, and can lead to other problems.

Another note: if you write this code, I think you should not use auth_url 
directly
creating the keystone client (did not look at the code in question, just 
thinking loud looking at the stacktrace).
Use keystoneauth1's loading.load_auth_plugin_from_conf_options()
and loading.load_session_from_conf_options(). You don't have to register 
anything if you're 
using the [keystone_authtoken] section. Lots of components introduce another 
config sections
for credentials, like [nova], [neutron], in this case one has to use 
register_auth_conf_options()
and register_session_conf_options().


__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Sean Dague

On 06/15/2017 10:57 AM, Thierry Carrez wrote:
> Jeremy Stanley wrote:
>> On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
>> [...]
>>> I'd like to propose that we introduce a new concept: "OpenStack-Hosted
>>> projects". There would be "OpenStack projects" on one side, and
>>> "Projects hosted on OpenStack infrastructure" on the other side (all
>>> still under the openstack/ git repo prefix).
>>
>> I'm still unconvinced a term is needed for this. Can't we just have
>> "OpenStack Projects" (those under TC governance) and "everything
>> else?" Why must the existence of any term require a term for its
>> opposite?
> 
> Well, we tried that for 2.5 years now, and people are still confused
> about which projects are an Openstack project and what are not. The
> confusion led to the perception that everything under openstack/ is an
> openstack project. It led to the perception that "big tent" means
> "anything goes in" or "flea market".
> 
> Whether we like it or not, giving a name to that category, a name that
> people can refer to (not "projects under openstack infrastructure that
> are not officially recognized by the TC"), is I think the only way out
> of this confusion.
> 
> Obviously we are not the target audience for that term. I think we are
> deep enough in OpenStack and technically-focused enough to see through
> that. But reality is, the majority of the rest of the world is confused,
> and needs help figuring it out. Giving the category a name is a way to
> do that.

Right, I think the point is that we both need to have an internal
understanding, as well as be able to effectively communicate the state
of things with people that aren't reading yaml out of git trees. The
human tendency to need a category for things (especially things they
aren't 100% familiar with the inner workings of) is way too strong to
ignore.

And the fact that namespaces in github mean something to the rest of the
world, even if they don't mean it to us, as that's a first order piece
of data the way other projects organize.

I do kind of wonder if we returned the stackforge or
friends-of-openstack or whatever to the github namespace when we
mirrored if it would clear a bunch of things up for people. It would
just need to be an extra piece of info in our project list about where
those projects should mirror to (which may not be the same namespace as
in gerrit).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

2017-06-15 Thread Gyorgy Szombathelyi

> 
>   auth_url is actually a dynamic parameter and depends on the
> keystone auth plugin used
>   (auth_type=xxx). The plugin which needs this parameter, registers it.
> 
> 
> 
> Based on this http://paste.openstack.org/show/612664/ I would say that the
> plugin doesn't register it :( It either can be a bug, or it was done 
> intentionally,
> I don't know.
> 
It should register it after you load it, via 
keystonauth1.loading.load_auth_plugin_from_conf_options()
There are also register_auth_conf_options() and get_auth_plugin_conf_options,  
which I think are mainly used 
for listing the most used plugins' options in the debug log. But I don't think 
it would be wise
just to choose a plugin and register its options for auth_url, because it is 
ugly, I think, and can lead to
other problems.
 
> 
> My final thought that we have to use both (auth_url and auth_uri) options in
> mistral config, which looks ugly, but necessary.

It's not just Mistral, but every component which uses keystonemiddleware.

> 
> Best,
> Mike
Br,
György
__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

On 15/06/17 07:03 AM, Chris Dent wrote:
>
> Part of the issue is that the meaning and value of being  an
> "OpenStack project" (an "official" one) is increasingly diffuse.
> I suspect that if we could make that more concrete then things like
> names would be easier to decide. Some things we might ask ourselves
> to help clarify the situation include (as usual, some of these
> questions may have obvious answers, but enumerating them can help
> make things explicit):
>
> * What motivates a project to seek status as an OpenStack project?
>   * What do they get?
>   * What do they lose?
>
> * What motivates OpenStack to seek more projects?
>   * What does OpenStack get?
>   * What does OpenStack lose?
>   * What gets more complicated when there are more projects?
>
> * Why would a project choose to be "hosted on OpenStack
>   infrastructure" instead of be an "OpenStack project"?
>
> * Why should OpenStack be willing to host projects that are not
>   "OpenStack projects"?
>
> * When a project goes from the status of "OpenStack project" to
>   "hosted on OpenStack infrastructure" (as currently being discussed
>   with regard to Fuel) what is the project losing, what does the
>   change signify and why should anyone care?
>
> (I'm sure other people can come up with a few more questions.)
>
> I think that if we're going to focus on this issue then we need to
> make sure that we focus on marshalling the value and resources that
> are required to support a project. That is: it has to be worth
> everyone's time and enery to be and have (official) projects. It's
> likely that this could mean that some projects are unable to be
> (official) projects anymore.

do this ^ first. if we cant qualify what we're trying to do with this 
labeling then it doesn't matter what name you slap on it. is it for 
marketing purposes? is it to define an OpenStack Community Edition? is 
it to create a repo of known projects that are solely funded/developed 
by OpenStack sponsors? is it to help developers somehow?

currently, if i read the new projects requirements[1], the 'big tent' is 
something along the lines of "here's a bunch of 'cloud' stuff the 
proprietary companies provide but from companies that fund openstack 
brand that is 'open'. we make no guarantees that they actually work 
(they probably don't), this is solely to say these projects: exists, are 
'open', and probably work with nova/keystone."

there is nothing wrong with this (except it being a terrible sales 
pitch) but since the 'big tent' message was ambiguous and we labeled it, 
it reached a marketer and became: 'look at us, we have a big tent 
project. what's the big tent? it's '.

labeling is inherently a branding exercise, so my question is what are 
we trying to market and should we be doing it or is it something that 
companies[2] should be doing.

[1] 
https://governance.openstack.org/tc/reference/new-projects-requirements.html
[2] https://www.openstack.org/marketplace/

-- 
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][tc] Moving away from "big tent" terminology

Jeremy Stanley wrote:
> On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> I'd like to propose that we introduce a new concept: "OpenStack-Hosted
>> projects". There would be "OpenStack projects" on one side, and
>> "Projects hosted on OpenStack infrastructure" on the other side (all
>> still under the openstack/ git repo prefix).
> 
> I'm still unconvinced a term is needed for this. Can't we just have
> "OpenStack Projects" (those under TC governance) and "everything
> else?" Why must the existence of any term require a term for its
> opposite?

Well, we tried that for 2.5 years now, and people are still confused
about which projects are an Openstack project and what are not. The
confusion led to the perception that everything under openstack/ is an
openstack project. It led to the perception that "big tent" means
"anything goes in" or "flea market".

Whether we like it or not, giving a name to that category, a name that
people can refer to (not "projects under openstack infrastructure that
are not officially recognized by the TC"), is I think the only way out
of this confusion.

Obviously we are not the target audience for that term. I think we are
deep enough in OpenStack and technically-focused enough to see through
that. But reality is, the majority of the rest of the world is confused,
and needs help figuring it out. Giving the category a name is a way to
do that.

-- 
Thierry Carrez (ttx)

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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

2017-06-15 Thread Mikhail Fedosin

Thanks György!

On Thu, Jun 15, 2017 at 1:55 PM, Gyorgy Szombathelyi <
gyorgy.szombathe...@doclerholding.com> wrote:

> Hi Mikhail,
>
> (I'm not from the Keystone team, but did some patches for using
> keystonauth1).
>
> >
> > 2. Even if auth_url is set, it can't be used later, because it is not
> registered in
> > oslo_config [5]
>
> auth_url is actually a dynamic parameter and depends on the keystone auth
> plugin used
> (auth_type=xxx). The plugin which needs this parameter, registers it.
>

Based on this http://paste.openstack.org/show/612664/ I would say that the
plugin doesn't register it :(
It either can be a bug, or it was done intentionally, I don't know.


>
> >
> > So I would like to get an advise from keystone team and understand what I
> > should do in such cases. Official documentation doesn't add clarity on
> the
> > matter because it recommends to use auth_uri in some cases and auth_url
> in
> > others.
> > My suggestion is to add auth_url in the list of keystone authtoken
> > middleware config options, so that the parameter can be used by the
> others.
>
> Yepp, this makes some confusion, but adding auth_url will make a clash with
> most (all?) authentication plugins. auth_url can be considered as an
> 'internal'
> option for the keystoneauth1 modules, and not used by anything else (like
> the keystonemiddleware itself). However if there would be a more elagant
> solution, I would also hear about it.
>
> >
> > Best,
> > Mike
> >
> Br,
> György
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


My final thought that we have to use both (auth_url and auth_uri) options
in mistral config, which looks ugly, but necessary.

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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
[...]
> I'd like to propose that we introduce a new concept: "OpenStack-Hosted
> projects". There would be "OpenStack projects" on one side, and
> "Projects hosted on OpenStack infrastructure" on the other side (all
> still under the openstack/ git repo prefix).

I'm still unconvinced a term is needed for this. Can't we just have
"OpenStack Projects" (those under TC governance) and "everything
else?" Why must the existence of any term require a term for its
opposite?

> We'll stop saying "official OpenStack project" and "unofficial
> OpenStack project". The only "OpenStack projects" will be the
> official ones. We'll chase down the last mentions of "big tent" in
> documentation and remove it from our vocabulary.
[...]

I agree on getting rid of the "big tent" phrase anywhere we find it,
though I thought we'd already avoided using that in favor of more
descriptive terminology anyway. Also I'm very excited to see a focus
on "OpenStack projects" I just don't see a benefit to making up a
name for "not an OpenStack project."
-- 
Jeremy Stanley


signature.asc
Description: 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] [tc][fuel] Making Fuel a hosted project

On 2017-06-15 10:48:21 +0200 (+0200), Thierry Carrez wrote:
[...]
> I think that, despite the efforts of the Fuel team, Fuel did not become
> what we hoped when we made it official: a universal installer that would
> be used across the board. It was worth a try, I'm happy that we tried,
> but I think it's time to stop considering it a part of "OpenStack"
> proper and make it a hosted project. It can of course continue its
> existence as an unofficial project hosted on OpenStack infrastructure.
> 
> Thoughts ?

I agree, it makes sense to be more clear as to the lack of
community-wide support for that effort. Perhaps if its popularity
increases outside one vendor's customer base to the point where
contributions from a broader set of stakeholders emerge, we can once
again evaluate its governance state.
-- 
Jeremy Stanley


signature.asc
Description: 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread John Griffith

On Thu, Jun 15, 2017 at 3:15 AM, Thierry Carrez 
wrote:

> Hi everyone,
>
> Back in 2014, OpenStack was facing a problem. Our project structure,
> inherited from days where Nova, Swift and friends were the only game in
> town, was not working anymore. The "integrated release" that we ended up
> producing was not really integrated, already too big to be installed by
> everyone, and yet too small to accommodate the growing interest in other
> forms of "open infrastructure". The incubation process (from stackforge
> to incubated, from incubated to integrated) created catch-22s that
> prevented projects from gathering enough interest to reach the upper
> layers. Something had to give.
>
> The project structure reform[1] that resulted from those discussions
> switched to a simpler model: project teams would be approved based on
> how well they fit the OpenStack overall mission and community
> principles, rather than based on a degree of maturity. It was nicknamed
> "the big tent" based on a blogpost[2] that Monty wrote -- mostly
> explaining that things produced by the OpenStack community should be
> considered OpenStack projects.
>
> So the reform removed the concept of incubated vs. integrated, in favor
> of a single "official" category. Tags[3] were introduced to better
> describe the degree of maturity of the various official things. "Being
> part of the big tent" was synonymous to "being an official project" (but
> people kept saying the former).
>
> At around the same time, mostly for technical reasons around the
> difficulty of renaming git repositories, the "stackforge/" git
> repository prefix was discontinued (all projects hosted on OpenStack
> infrastructure would be created under an "openstack/" git repository
> prefix).
>
> All those events combined, though, sent a mixed message, which we are
> still struggling with today. "Big tent" has a flea market connotation of
> "everyone can come in". Combined with the fact that all git repositories
> are under the same prefix, it created a lot of confusion. Some people
> even think the big tent is the openstack/ namespace, not the list of
> official projects. We tried to stop using the "big tent" meme, but (I
> blame Monty), the name is still sticking. I think it's time to more
> aggressively get rid of it. We tried using "unofficial" and "official"
> terminology, but that did not stick either.
>
> I'd like to propose that we introduce a new concept: "OpenStack-Hosted
> projects". There would be "OpenStack projects" on one side, and
> "Projects hosted on OpenStack infrastructure" on the other side (all
> still under the openstack/ git repo prefix). We'll stop saying "official
> OpenStack project" and "unofficial OpenStack project". The only
> "OpenStack projects" will be the official ones. We'll chase down the
> last mentions of "big tent" in documentation and remove it from our
> vocabulary.
>
> I think this new wording (replacing what was previously Stackforge,
> replacing what was previously called "unofficial OpenStack projects")
> will bring some clarity as to what is OpenStack and what is beyond it.
>
> Thoughts ?
>
> [1]
> https://governance.openstack.org/tc/resolutions/20141202-
> project-structure-reform-spec.html
> [2] http://inaugust.com/posts/big-tent.html
> [3] https://governance.openstack.org/tc/reference/tags/index.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
>
I like it, and I actually like the naming.  "Friends of OpenStack" is way
too touchy feely, koomba ya.  True there's not a glaring distinction in the
names (OpenStack Project vs OpenStack Hosted), but I thought that was kind
of a good thing.  A sort of compromise between the two extremes we've had
in the past.  Either way, whatever the names etc, the concept seems solid
to me and I think might be more clear for those trying to wrap their head
around things.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Flavio Percoco


On 15/06/17 10:48 +0200, Thierry Carrez wrote:

Hi everyone,

Part of reducing OpenStack perceived complexity is to cull projects that
have not delivered on their initial promises. Those are always difficult
discussions, but we need to have them. In this email I'd like to discuss
whether we should no longer consider Fuel an official OpenStack project,
and turn it into a hosted (unofficial) project.

Fuel originated at Mirantis as their OpenStack installer. It was
proposed as an official OpenStack project in July 2015 and approved in
November 2015. The promise at that time was that making it official
would drive other organizations to participate in its development and
turn it into the one generic OpenStack installer that everyone wanted.
Fuel was not a small endeavor: in Mitaka and Newton it represented more
commits than Nova.

The Fuel team fully embraced open collaboration, but failed to attract
other organizations. Mitaka and Newton were still 96% the work of
Mirantis. In my view, while deployment/packaging tools sit at the
periphery of the "OpenStack" map, they make sense as official OpenStack
teams if they create an open collaboration playing field and attract
multiple organizations. Otherwise they are just another opinionated
install tool that happens to be blessed with an "official" label.

Since October 2016, Fuel's activity has dropped, following the gradual
disengagement of its main sponsor. Comparing activity in the 5 first
months of the year, there was a 68% drop between 2016 and 2017, the
largest of any official OpenStack project. The Fuel team hasn't met on
IRC for the last 3 months. Activity dropped from ~990 commits/month (Apr
2016, Aug 2016) to 52 commits in April 2017 and 25 commits in May 2017.
And there are unsolved issues around licensing that have been lingering
for the last 6 months.

I think that, despite the efforts of the Fuel team, Fuel did not become
what we hoped when we made it official: a universal installer that would
be used across the board. It was worth a try, I'm happy that we tried,
but I think it's time to stop considering it a part of "OpenStack"
proper and make it a hosted project. It can of course continue its
existence as an unofficial project hosted on OpenStack infrastructure.

Thoughts ?


+1 to change Fuel* status

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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Flavio Percoco


On 15/06/17 14:09 +, Jeremy Stanley wrote:

On 2017-06-15 14:57:20 +0200 (+0200), Thierry Carrez wrote:
[...]

An alternative would be to give "the OpenStack project infrastructure"
some kind of a brand name (say, "Opium", for OpenStack project
infrastructure ultimate madness) and then call the hosted projects
"Opium projects". Rename the Infra team to Opium team, and voilà!


Not to be cynical, but it sounds like a return to StackForge under a
different name.

The thing I like about _not_ having a name for that is it's not an
either/or situation. There are OpenStack projects under official
governance, and everything else in existence (some of which we might
host, other stuff is elsewhere on the Internet at large). Keeping
the discussion focused on OpenStack is key for me. I am not
personally keen on the idea of branding the Infrastructure team's
work as an unrelated hosting service and feel like we only recently
managed to get away from that paradigm when we ditched the
StackForge branding as a euphemism for projects that weren't under
OpenStack governance.


+1 I literally just sent an email asking whether we want to make this separation
more evident. The fact that we're picking these names makes me think it's
important for us to have such separation so that we can be clear on what the
releases will bring, among other things.

If we're going to have such separation, then I'd rather make it evident since
it's confusing for people to understand what the difference between big-tent and
official project is and the name change won't help much with this problem, I
reckon.

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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Flavio Percoco


On 15/06/17 11:15 +0200, Thierry Carrez wrote:

I'd like to propose that we introduce a new concept: "OpenStack-Hosted
projects". There would be "OpenStack projects" on one side, and
"Projects hosted on OpenStack infrastructure" on the other side (all
still under the openstack/ git repo prefix). We'll stop saying "official
OpenStack project" and "unofficial OpenStack project". The only
"OpenStack projects" will be the official ones. We'll chase down the
last mentions of "big tent" in documentation and remove it from our
vocabulary.

I think this new wording (replacing what was previously Stackforge,
replacing what was previously called "unofficial OpenStack projects")
will bring some clarity as to what is OpenStack and what is beyond it.


The wording sounds good to me. I've found that it's a bit unclear what projects
are part of OpenStack to folks that are not entirely familiar with the
terminology (regardless of the terminology). Stackforge made this very clear,
so, I wonder if we should find a better way to clarify what projects are Hosted
and what projects are part of OpenStack. So far we have badges, which were added
to some Readmes and they only show up on github so, badges might not be clear
enough. To be honest, I don't have an idea that I'm happy with but here are a
couple:

* Have an autogenerated (?) doc with the list of hosted services
* Update badges to reflect the terminology change
* Have a different documentation theme for hosted projects (?)

I'm not super happy with these ideas but I'm throwing them out there hoping that
we can brainstorm a bit on how we can do this and whether this is something we
really want/need to do.

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][tc] Moving away from "big tent" terminology

On 2017-06-15 14:57:20 +0200 (+0200), Thierry Carrez wrote:
[...]
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!

Not to be cynical, but it sounds like a return to StackForge under a
different name.

The thing I like about _not_ having a name for that is it's not an
either/or situation. There are OpenStack projects under official
governance, and everything else in existence (some of which we might
host, other stuff is elsewhere on the Internet at large). Keeping
the discussion focused on OpenStack is key for me. I am not
personally keen on the idea of branding the Infrastructure team's
work as an unrelated hosting service and feel like we only recently
managed to get away from that paradigm when we ditched the
StackForge branding as a euphemism for projects that weren't under
OpenStack governance.
-- 
Jeremy Stanley


signature.asc
Description: 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][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 02:57:20PM +0200, Thierry Carrez wrote:
> Sean Dague wrote:
> > [...]
> > I think those are all fine. The other term that popped into my head was
> > "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> > that aren't official projects. It may be too informal, but I do think
> > the OpenStack-Hosted vs. OpenStack might still mix up in people's head.
> 
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting that
> we don't actually do.
> 
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!
> 
> -- 
> Thierry Carrez (ttx)

Hmm, I like the concept. Giing it a "brand" would make it something identifiable
while still creating a separation from OpenStack as a whole.

Not sure about the name, but I like this direction more than "OpenStack Hosted".


__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Melvin Hillsman

Just my .02,

I agree with those who have said distinction is still difficult with
initial thoughts and possibly fleshing out more clearly how that would be
handled - opium branding, questions/criteria proposed by Chris, etc. - can
address the identified potential confusion. I like the idea of branding the
infra team - wonder what they think of that. As others have stated I do not
have any good suggestions just throwing in an extra +1 where appropriate :)

On Thu, Jun 15, 2017 at 7:57 AM, Thierry Carrez 
wrote:

> Sean Dague wrote:
> > [...]
> > I think those are all fine. The other term that popped into my head was
> > "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> > that aren't official projects. It may be too informal, but I do think
> > the OpenStack-Hosted vs. OpenStack might still mix up in people's head.
>
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting that
> we don't actually do.
>
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!
>
> --
> 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
>



-- 
-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646

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

[openstack-dev] [neutron] security group OVO change

2017-06-15 Thread Gary Kotton

Hi,
The commit https://review.openstack.org/284738 has broken decomposed plugins 
(those that extend security groups and rules). The reason for this is that 
there is a extend callback that we use which expects to get a database object 
and the aforementioned patch passes a new neutron object.
I have posted [i] to temporarily address the issue. An alternative is to revert 
the patch until the decomposed plugins can figure out how to correctly address 
this.
Thanks
Gary
[i] https://review.openstack.org/474575
__
OpenStack Development Mailing 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][tc] Moving away from "big tent" terminology

Sean Dague wrote:
> [...]
> I think those are all fine. The other term that popped into my head was
> "Friends of OpenStack" as a way to describe the openstack-hosted efforts
> that aren't official projects. It may be too informal, but I do think
> the OpenStack-Hosted vs. OpenStack might still mix up in people's head.

My original thinking was to call them "hosted projects" or "host
projects", but then it felt a bit incomplete. I kinda like the "Friends
of OpenStack" name, although it seems to imply some kind of vetting that
we don't actually do.

An alternative would be to give "the OpenStack project infrastructure"
some kind of a brand name (say, "Opium", for OpenStack project
infrastructure ultimate madness) and then call the hosted projects
"Opium projects". Rename the Infra team to Opium team, and voilà!

-- 
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] [tc][fuel] Making Fuel a hosted project

Excerpts from Thierry Carrez's message of 2017-06-15 10:48:21 +0200:
> Hi everyone,
> 
> Part of reducing OpenStack perceived complexity is to cull projects that
> have not delivered on their initial promises. Those are always difficult
> discussions, but we need to have them. In this email I'd like to discuss
> whether we should no longer consider Fuel an official OpenStack project,
> and turn it into a hosted (unofficial) project.
> 
> Fuel originated at Mirantis as their OpenStack installer. It was
> proposed as an official OpenStack project in July 2015 and approved in
> November 2015. The promise at that time was that making it official
> would drive other organizations to participate in its development and
> turn it into the one generic OpenStack installer that everyone wanted.
> Fuel was not a small endeavor: in Mitaka and Newton it represented more
> commits than Nova.
> 
> The Fuel team fully embraced open collaboration, but failed to attract
> other organizations. Mitaka and Newton were still 96% the work of
> Mirantis. In my view, while deployment/packaging tools sit at the
> periphery of the "OpenStack" map, they make sense as official OpenStack
> teams if they create an open collaboration playing field and attract
> multiple organizations. Otherwise they are just another opinionated
> install tool that happens to be blessed with an "official" label.
> 
> Since October 2016, Fuel's activity has dropped, following the gradual
> disengagement of its main sponsor. Comparing activity in the 5 first
> months of the year, there was a 68% drop between 2016 and 2017, the
> largest of any official OpenStack project. The Fuel team hasn't met on
> IRC for the last 3 months. Activity dropped from ~990 commits/month (Apr
> 2016, Aug 2016) to 52 commits in April 2017 and 25 commits in May 2017.
> And there are unsolved issues around licensing that have been lingering
> for the last 6 months.
> 
> I think that, despite the efforts of the Fuel team, Fuel did not become
> what we hoped when we made it official: a universal installer that would
> be used across the board. It was worth a try, I'm happy that we tried,
> but I think it's time to stop considering it a part of "OpenStack"
> proper and make it a hosted project. It can of course continue its
> existence as an unofficial project hosted on OpenStack infrastructure.
> 
> Thoughts ?
> 

IIRC, they are hosting their release artifacts on a Mirantis server,
too. I agree, the project was never fully "upstreamed" in the way we
hoped.

+1 for changing the project status.

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-dev] [fuel] stable branches maintenance

2017-06-15 Thread Denis Meltsaykin

Greetings everyone!

Since the development of fuel-related projects is currently not so active
as it used to be, I want to propose a change in how we maintain stable
branches.

-Motivation-
As for now to commit anything into a stable branch of a fuel-related
project one should get at least one approval from a core developer in that
project and another approval from the maintenance team. While this was a
pretty good working workflow in the last couple of years, at the moment it
slows down the maintenance of the stable branches due to reduced presence
of core developers.

-Proposal-
I propose to grant CR+2 permissions in the stable branches to the
fuel-stable-core [0] group, which represents the current maintenance team
working on the stable branches.
Since the beginning the maintenance team is one of the most active
contributors to the stable branches of fuel-* projects and is fully
involved into the contribution process. I've prepared a commit [1]
beforehand.

-Advantages-
Maintenance of the stable branches will become significantly better.

-Disadvantages-
None.

[0]: https://review.openstack.org/#/admin/groups/984,members
[1]: https://review.openstack.org/#/c/474541/
[2]: https://docs.openstack.org/project-team-guide/stable-
branches.html#stable-maintenance-teams

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

[openstack-dev] [neutron] does neutron actually use the salve_connection ?

2017-06-15 Thread cristi.calin

Hello,



I am looking to improve the database load distribution and one of the things 
that may help with this is to spread out the reads.
>From the configuration reference it looks like neutron dues support a 
>slave_connection parameter but when I enabled it and enabled query logging on 
>the secondary databases there aren't any queries being executed on the 
>secondaries. Is there anything I am missing ?

Sorry for CC'ing the dev list as well but someone in the dev teams may have an 
answer from a developer point of view.


My setup is like this:

Openstack stable/mitaka (built from git)
3 galera nodes
1 haproxy running on each node with active/backup with local node as single 
active configuration for the frontend listening on :3306 and active/backup with 
the other nodes as active for the frontend listening on :3308

In neutron.conf in the [database] section I set up the the connection and 
slave_connection parameters like this:

[database]
connection = 
mysql+pymysql://neutron:XXX@neutron-db.service:3306/neutron?charset=utf8
slave_connection = mysql+pymysql://neutron: 
XXX@neutron-db.service:3308/neutron?charset=utf8
idle_timeout = 1800
max_retries = -1
retry_interval = 5
min_pool_size = 8
max_pool_size = 32
max_overflow = 16


Loooking on a slave it opens a single connection which is eventually closed 
because of lack of activity.


Thanks,
Cristian

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [openstack-dev] [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

2017-06-15 Thread Dnyaneshwar Pawar


On 6/14/17, 6:00 PM, "Abhishek Kane"  wrote:

>Thank you for the comments Emilien!
>
>Updated as per your suggestions:
>puppet-veritas-hyperscale: 
>https://github.com/abhishek-kane/puppet-veritas-hyperscale
>
>Also, please find the inline replies to your comments.
>
>We had been able to call the old puppet modules (which had scripts) using the 
>generic puppet way (puppet agent --test). But we are unable to deploy the new 
>puppet modules (which use existing puppet classes) the tripleo way. Following 
>paste shows a sample puppet module which we are trying to deploy on an 
>overcloud which is already deployed. We see that our resources are in 
>“CREATE_COMPLETE” status, but the actual operation hasn’t happened.
>http://paste.openstack.org/show/612537/

Thanks to Steven Hardy, We are now able to apply (puppet apply) our individual 
puppet modules inside overcloud controller.
We are working on creating compossible services. 



>
>Regards,
>Abhishek
>
>On 6/14/17, 1:18 AM, "Emilien Macchi"  wrote:
>
>On Wed, Jun 7, 2017 at 10:38 AM, Abhishek Kane
> wrote:
>> Hi,
>>
>> On cinder node- we need to modify the cinder.conf. We don’t change any 
> config apart from this. We want to keep the config changes in heat template, 
> package installation in puppet, and trigger rest of the operations via 
> Horizon (as it’s done today). We are also trying to get rid of the nova.conf 
> file changes. Once the approach for cinder is sorted, will get back on this.
>>
>> If this is correct approach for cinder, I will raise review requests for 
> the following projects:
>> puppet-tripleo: http://paste.openstack.org/show/611697/
>> puppet-cinder: http://paste.openstack.org/show/611698/
>> tripleo-heat-templates: http://paste.openstack.org/show/611700/
>>
>> Also, I am not sure which TripleO repos need to be patched for the 
> controller components.
>>
>> We have decomposed the controller bin installer into idempotent 
> modules/scripts. Now, the installer is not a black box operation:
>> https://github.com/abhishek-kane/puppet-veritas-hyperscale
>> The inline replies below are w.r.t. this project. The product installer 
> bin currently works in atomic fashion. One issue which we see in puppet is 
> the error handling and rollback operations.
>>
>> Thanks,
>> Abhishek
>>
>> On 6/1/17, 8:41 PM, "Emilien Macchi"  wrote:
>>
>> On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane 
>  wrote:
>> > Hi Emilien,
>> >
>> > The bin does following things on controller:
>> > 1. Install core HyperScale packages.
>>
>> Should be done by Puppet, with Package resource.
>> Ak> It’s done.
>>
>> > 2. Start HyperScale API server
>>
>> Should be done by Puppet, with Service resource.
>> AK> It’s done.
>>
>> > 3. Install UI packages. This will add new files to and modify some 
> existing files of Horison.
>>
>> Should be done by Puppet, with Package resource and also some changes
>> in puppet-horizon maybe if you need to change Horizon config.
>> Ak> We have got rid of the horizon dependency right now. Our GUI 
> components get installed via separate package.
>>
>> > 4. Create HyperScale user in mysql db. Create database and dump 
> config. Add permissions of nova and cinder DB to HyperScale user.
>>
>> We have puppet-openstacklib which already manages DBs, you could
>> easily re-use it. Please look at puppet-nova for example to see how
>> things works in nova::db::mysql, etc.
>> AK> TBD
>>
>> > 5. Add ceilometer pollsters for additional stats and modify 
> ceilometer files.
>>
>> puppet-ceilometer I guess. What do you mean by "files"? Config files?
>> Ak> We are trying to get rid of this dependency as well. TBD.
>>
>> > 6. Change OpenStack configuration:
>> > a. Create rabbitmq exchanges
>>
>> puppet-* modules already does it.
>> AK> It’s done via script. Do we need to patch any module?
>
>Everything that touch *.conf files of OpenStack services need to be
>done by existing openstack/puppet-* modules.
>
>AK> 
>https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_rabbitmq.pp
> We are still doing some operation via script, but it’s idempotent.
>
>>
>> > b. Create keystone user
>>
>> puppet-keystone already does it.
>> AK> It’s done via script. Do we need to patch keystone module?
>
>No, you'll need to create the right user/roles/endpoints/... in
>puppet-tripleo, in a new profile, most probably.
>You'll probably need to read a bit about:
>https://github.com/openstack/puppet-keystone#setup
>Let me know if you need more help on this thing.

Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

On Thu, Jun 15, 2017 at 07:39:23AM -0400, Davanum Srinivas wrote:
> +1 to drop Fuel from governance
> 
> -- Dims
> 

+1 from me too.

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][tc] Moving away from "big tent" terminology

On Thu, Jun 15, 2017 at 12:06:17PM +0100, Chris Dent wrote:
> On Thu, 15 Jun 2017, Chris Dent wrote:
> 
> >On Thu, 15 Jun 2017, Thierry Carrez wrote:
> >
> >>I'd like to propose that we introduce a new concept: "OpenStack-Hosted
> >>projects". There would be "OpenStack projects" on one side, and
> >>"Projects hosted on OpenStack infrastructure" on the other side (all
> >>still under the openstack/ git repo prefix). We'll stop saying "official
> >>OpenStack project" and "unofficial OpenStack project". The only
> >>"OpenStack projects" will be the official ones. We'll chase down the
> >>last mentions of "big tent" in documentation and remove it from our
> >>vocabulary.
> >
> >I agree that something needs to change, but also agree with some of
> >the followups that the distinction you're proposing isn't
> >particularly memorable.
> 
> I should also say that despite my previous comments, discussion
> resolving those issues should not delay sanitizing the term "big
> tent".

I'm in the same boat (or tent? :) ) that I don't think the new terms would
be distinguishing enough to improve the misunderstanding. But like Chris,
I don't really have any good suggestions at the moment either.

+1 for removing references to the big tent while we bikeshed on naming.

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] [tc][fuel] Making Fuel a hosted project