Re: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

[SUZUKI, Kazuhiro]

Hi,

I would like to announce a new repository for tap-as-a-service was
created.
Could you please take a look.

http://git.openstack.org/cgit/openstack/tap-as-a-service-dashboard/

Regards,
Kaz


From: Akihiro Motoki 
Subject: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas 
dashboard split out
Date: Wed, 21 Jun 2017 13:46:37 +0900

> Hi neutron and horizon teams (especially fwaas and vpnaas folks),
> 
> As we discussed so far, I prepared separate git repositories for FWaaS
> and VPNaaS dashboards.
> http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
> http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
> 
> All new features will be implemented in the new repositories, for
> example, FWaaS v2 support.
> The initial core members consist of neutron-fwaas/vpnaas-core
> (respectively) + horizon-core.
> 
> There are several things to do to complete the split out.
> I gathered a list of work items at the etherpad and we will track the
> progress here.
> https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
> If you are interested in helping the efforts, sign up on the etherpad
> or contact me.
> 
> I would like to release the initial release which is compatible with
> the current horizon
> FWaaS/VPNaaS dashboard (with no new features).
> I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).
> 
> It also will be good examples for neutron stadium/related projects
> which are interested in
> adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
> interested in it.
> 
> Thanks,
> Akihiro
> 
> __
> OpenStack Development Mailing 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] How to deal with confusion around "hosted projects"

[Steven Dake]

Agree.

Regards
-steve

On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor  wrote:

> On 06/28/2017 11:27 PM, Steven Dake wrote:
>
>
>>
>> On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor > > wrote:
>>
>> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC
>> workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The
>> thread went
>> in a lot of directions, including discussing GitHub mirroring
>> strategy,
>> what makes projects want to be official, the need for returning
>> to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>> > e/118368.html>
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we
>> should stop
>> using it. The issue is, merely stopping using it won't be enough.
>> We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to
>> see what
>> is a part of OpenStack and what's not. If you google "openstack
>> machine
>> learning", the first hits are Cognitive and Meteos, and it's
>> impossible
>> to tell that those are actually not OpenStack projects. One of
>> those has
>> been dead for 2 years -- having people think that those are
>> official
>> projects hurts all the OpenStack projects, by lowering
>> expectations
>> around what that means, in terms of quality, maintenance, or
>> community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's
>> nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even
>> with the
>> expansive "are you one of us" definition. Arguably the most
>> confusing
>> aspect is the "openstack/" prefix in the git repository name,
>> which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue
>> on the
>> edges, or you can treat the root cause. Neither of those options
>> is
>> really an OpenStack  governance change (or "big tent" change) --
>> they
>> are more about what to do with things that are actually *not* in
>> our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer
>> when
>> things are not official. The thread above discussed a lot of
>> potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could
>> find a
>> way to tag all projects on GitHub that are not official, or
>> mirror them
>> to another organization, or stop mirroring them altogether. We
>> could
>> remove the openstack/ prefix from all the projects we host. We
>> could
>> actively mark all wiki pages that are not about an official
>> project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is
>> that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop
>> offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The
>> benefits of
>> offering that service are:
>>
>>
>> I disagree that this is removing the root cause.
>>
>> I believe this is reacting to a misunderstanding by hiding from it.
>> I do not believe that doing this provides any value to us as a
>> community.
>>
>> Even though we do not actually use github for development, we have
>> implicitly accepted the false premise that github is a requirement.
>> It is suggested that the existence of git repos in the openstack/
>> github org is confusing to people. And our reaction to that is to
>> cut off access to our Open 

[openstack-dev] [glance] priorities for the coming week (06/30-07/06)

[Brian Rosmaita]

(Light list this week because of a long holiday weekend in the USA.)

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

1  image download error
https://review.openstack.org/#/c/460280

2  weirdness on the 'protected' property filter patch
Strange test failure error (see Abhishek's comment on the patch).
https://review.openstack.org/#/c/449108/

3  glance bugs
Let's get some action on open bugs.


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

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Jun. 30 2017

[hu.zhijiang]

1.ODL L2/L3 Integration 

2.Scenario in JJB

3.Documentation task

4.AoB











B. R.,

Zhijiang__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

On Fri, Jun 30, 2017 at 12:18 AM, Jeremy Stanley  wrote:

> On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> > So I apologise if this has already been suggested/discussed (the
> > long threads are difficult to keep up with), but has it been
> > considered to go back to using a stackforge namespace?
> [...]
>
> Back in the bad ol' days when we had a separate namespace for
> unofficial projects, it seemed to me like newcomers were just as
> confused as they are now, perhaps even more so. People like to
> forget, or wax nostalgic, or simply weren't around to see it first
> hand back then; so I agree it's probably worth rehashing the pain
> points as it's been a long time since I can recall anyone
> enumerating them.
>
> Gerrit's design assumes project names (including any prefixed
> namespace) never change. This means project renames in Gerrit are
> painful and disruptive (service outage for everyone, Git remote
> changes for anyone working on that repo, risk of breaking things
> with a SQL update query or directory move, et cetera). There is no
> good automation for transfers between orgs in GH either so handling
> this is a manual process involving lot of clicking around in a Web
> browser. Project renames also touch other systems (our many Git
> servers, StoryBoard) so more places to make mistakes or miss
> something.
>
> As a result, we would want to actively discourage repos moving from
> the stackforge namespace into the openstack namespace (or vice
> versa) which creates an artificial hurdle for projects seeking to
> become official. This causes them to place an urgent pressure on the
> Infra team which makes it harder for us to ease the pain of renames
> by batching them up and processing them less frequently. We
> similarly would no longer be allowed to create repos directly in the
> openstack namespace without prior approval from the TC, which puts
> the brakes on the current flow where teams can create a new repo as
> quickly as the project-config-cores review the change and then work
> on the corresponding governance addition in parallel with doing
> their project development.
>
> In the past the ability to push most of the work of doing renames
> onto the Infra team created a perverse incentive for projects to
> start unofficial so they didn't have to wait on the TC, and then ask
> for a rename once they got approval rather than waiting to start
> work until the TC approved their request. It's hard for the Infra
> team to effectively deter that sort of behavior because the most we
> can do is ask authors of their intentions and then trust that
> they're being up front about a lack of interest in becoming official
> (and that they're unlikely to change their minds about it later).
>
> Unfortunately, hosting unofficial projects grants official teams a
> license to experiment in that space rather than taking
> responsibility up front, and this is detrimental to our community as
> a whole. It also gives new teams an easy excuse to put off applying
> to become official until later since they get most of the
> infrastructure benefits right away regardless. If we could get rid
> of this pervasive temptation to "incubate" ideas out from under the
> shadow of governance then maybe that would make maintaining the rest
> under a different namespace slightly less of a burden, as the need
> to move repos between namespaces would then be far less common or
> urgent.
> --
> 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
>
>
Hey Jeremy,

Thanks for that, it's a good refresher. I'm aware of the technical
challenges however (and I think I did a poor job of saying this) I was
suggesting that if we suspend the technical issues for the purpose of this
discussion what does it look like. In other words, lets assume we can
easily move between namespaces (and even git remotes aren't a problem), in
this case is returning to something like stackforge advantageous?

Then, if so, has anybody looked at how difficult it would be to actually to
fix gerrit, automate github (perhaps through a newer API or simulating
those clicks etc), come up with a creative fix to git remotes (redirects,
updating via git review or something) etc.

This possibly isn't helpful as I'm unfortunately not in a position to be
able to volunteer to work on any of the above. Realistically I imagine that
the amount of work is not feasible and that is one of the reasons we moved
away from multiple name spaces. I'm just wondering if that is still the
case.

Cheers,
Josh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [tripleo] Plan description in the create/update plan form

[Ben Nemec]

On 06/29/2017 07:25 AM, Ana Krivokapic wrote:

Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic > wrote:

Hi TripleO devs,

I am working on adding a description field to the "Crate Plan" form
in the TripleO UI [1]. The goal is to make it possible for the user
to specify a plan description using a form field when creating a
plan. As the plan description lives in the plan-environment.yaml
file[2], the idea is to retrieve this value from
plan-environment.yaml when the user uploads the plan, populate the
form field with it, let the user change it, and then save it back to
the file.

I have a WIP patch up [3] which solves the issue in the case of
uploading the plan as a folder. However, I am having a hard time
solving the case of uploading the plan as a tarball. The issue is
obviously with accessing the contents of the tarball. Here are some
possible approaches that come to mind:

1) Use one of the existing third-party JS libraries that can extract
a tarball in the browser. Pros: front-end only solution, no need for
additional API calls, no need for back-end changes. Cons: adding a
new dependency, these libraries don't seem much maintained.

2) Use swift to upload and extract the tarball. Pros: no need for
back-end changes, we can just call the swift API. Cons: splitting
the tarball upload from plan creation, which should really be one
atomic operation.

3) Modify the plan create workflow to accept a plan description as a
parameter. Pros: keeps plan creation atomic. Cons: changes to the
plan create workflow interface needed. Also this way there is no way
to send back the information about the description to the UI, we
would have to just accept the value of the form field, and overwrite
whatever was in the plan-environment.yaml file.

Of course there is also a fourth option:

4) This is not worth the effort to implement and we should just drop
it. :)


So the user can update the description after the initial upload, right? 
I wouldn't have a huge problem with just saying that you don't get the 
description box pre-populated if you upload a binary format like tar. 
It's not quite as ideal, but as long as there is some way to set the 
description at some point in the process it should be fine until/unless 
we decide to pursue a more complicated solution.




My personal opinion is that the cons of 1) and 2) make these
approaches unacceptable. The cons of 3) make it kind of not worth it
- seems like a lot of work for a partial solution. So I'm leaning
towards 4) at the moment.

I'd like to hear your opinions on this, is there a another/better
approach that I'm missing? Jirka, you mentioned we could postpone
this work to the next cycle and there are improvements that we can
work on in the meantime which would make implementation of this
feature easier?

Any and all thoughts, comments, opinions are welcome.

[1] https://bugs.launchpad.net/tripleo/+bug/1698818

[2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5


[3] https://review.openstack.org/#/c/477536/


--
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.




--
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.


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



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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 19:25:09 + (+), Tim Bell wrote:
[...]
> Can an ‘official’ project be deprecated? The economics say yes.
> The consumer confidence impact would be substantial.
[...]

Does https://review.openstack.org/475721 count? What about
https://review.openstack.org/452086 or, going back a ways,
https://review.openstack.org/376609 maybe? We deprecate official
projects by removing them from our governance with some regularity,
though being realistic it's no more than a few a year.
-- 
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] How to deal with confusion around "hosted projects"

[Zane Bitter]

On 29/06/17 10:18, Jeremy Stanley wrote:

Gerrit's design assumes project names (including any prefixed
namespace) never change. This means project renames in Gerrit are
painful and disruptive (service outage for everyone, Git remote
changes for anyone working on that repo, risk of breaking things
with a SQL update query or directory move, et cetera). There is no
good automation for transfers between orgs in GH either so handling
this is a manual process involving lot of clicking around in a Web
browser. Project renames also touch other systems (our many Git
servers, StoryBoard) so more places to make mistakes or miss
something.


Or just abandon all pending patches, delete the branches, and clone the 
git repo to a fresh project?


For a project at an early enough stage that they're just managing to 
convince the TC that they have the critical mass to be a 'going concern' 
following the 4 opens (and thus able to become an official project), 
that's not even that onerous. We effectively did it with Heat when 
moving from GitHub to StackForge and at worst it was a minor annoyance 
for a couple of days.


We can't keep giving away our trademark to literally anybody who comes 
along. In retrospect, if our top priority was to avoid renaming we 
should have moved the official projects to the stackforge/ namespace 
instead of the other way around.


__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Fox, Kevin M]

Part of the confusion is around what is allowed to use the term openstack and 
the various ways its used.

we have software such as github.com/openstack/openstack-helm,

which is in the openstack namespace, has openstack in its title, but not under 
tc governance. 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

But it also also has stated its an 'openstack project'.

(not trying to pick on openstack-helm here. just the most recent example I can 
think of that shows off the various ways something can/can't be "openstack" 
today)

So whats really unclear to end users is that when they talk about a piece of 
"openstack" they may be talking about a great many things:
1. is it managed under the 4 opens
2. is it in github.com/openstack.
3. is it under openstack governance.
4. is it an 'openstack project' (what does this mean anymore. I thought that 
was #3, but maybe not?)
5. is "openstack" part of its title

Is a project part of openstack if it meets one of those? all of them? or some 
subset? If we can't answer it, I'm not sure users will ever understand it.

This is separate entirely from the maturity of the software and the level of 
integration with other openstack software issue too. :/

Thanks,
Kevin


From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, June 29, 2017 12:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] How to deal with confusion around 
"hosted projects"

> On 29 Jun 2017, at 17:35, Chris Friesen  wrote:
>
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
>
>> We are already WELL past where we can solve the problem you are describing.
>> Pandora's box has been opened - we have defined ourselves as an Open 
>> community.
>> Our only requirement to be official is that you behave as one of us. There is
>> nothing stopping those machine learning projects from becoming official. If 
>> they
>> did become official but were still bad software - what would we have solved?
>>
>> We have a long-time official project that currently has staffing problems. If
>> someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
>> that
>> the contribution rate has fallen off recently they could get the impression 
>> that
>> OpenStack is a bunch of dead crap.
>>
>> Inclusion as an Official Project in OpenStack is not an indication that 
>> anyone
>> thinks the project is good quality. That's a decision we actively made. This 
>> is
>> the result.
>
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level of stability/usefulness/maturity/quality" to help newcomers weed out 
> projects that are under TC governance but are not ready for prime time.
>

There is certainly a concern on the operator community as to how viable/useful 
a project is (and how to determine this). Adopting too early makes for a very 
difficult discussion with cloud users who rely on the function.

Can an ‘official’ project be deprecated? The economics say yes. The consumer 
confidence impact would be substantial.

However, home grown solutions where there is common interest implies technical 
debt in the long term.

Tim

> Chris
>
> __
> OpenStack Development Mailing 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] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Amy Marrich]

On Thu, Jun 29, 2017 at 3:12 PM, Mike Perez  wrote:

> On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> > First off it looks really sleek and I love the look! A few thoughts
> though
> > and I do realize it's just a mock up:
> >
> > 1) We have Sponsor just to pick one but don't have
> Operators/Administrators
> > and their feedback is a major contribution so please don't leave them
> out.
>
> Ah yes, I should’ve mentioned earlier that this is totally a POC.
> There are lots missing, don’t worry! :)
>
> > 2) I would list the contributor types in alphabetical order that way no
> > group feels slighted, you can't help it if Use Cases are last it's just
> > that they start with a U vs Code which is a C.
>
> Sure!
>
> > 3) What if you would like to contribute in multiple ways?
>
> You would come back to the main contributor portal and click on a
> different contribution. How about at the end of each lesson it gives
> them the option to go back to main contributor portal to pick another
> way to contribute?
>
> What if on the bottom it could list out the other ways and they could just
proceed from there?


> >
> > Resources are definitely still underdevelopment there but are they meant
> to
> > be broad applicable to all resources with more specialized one's visible
> > when you click on how you'd like to contribute?
>
> That’s a good question. I think it should probably on top contain the
> more general stuff, then in alphabetical order we can list resources
> for all contribution types? It can be like the “I want to contribute
> to OpenStack by…” top piece, but instead lists resource links to pick
> through based on your contribution type(s). Maybe we keep them as
> separate pages as originally given in the mock up so it’s not overly
> crowded?
>
> Thanks for the help Amy!
>
> —
> Mike Perez
>

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

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

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

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress bar somewhere to show how close you are 
> > to being ready
> > to contribute to whatever team. Of course there are a lot of other fancy 
> > things we can
> come
> > up with, but I think getting something up as an initial pass would be 
> > better than what
> we
> > have today.
> >
> > Here's an example of what the sections/chapters could look like:
> >
> > - Code
> > * Volumes (Cinder)
> > * IRC
> > * Git
> > * Account Setup
> > * Generating Configs
> > * Compute (Nova)
> > * IRC
> > * Git
> > * 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Tim Bell]

> On 29 Jun 2017, at 17:35, Chris Friesen  wrote:
> 
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
> 
>> We are already WELL past where we can solve the problem you are describing.
>> Pandora's box has been opened - we have defined ourselves as an Open 
>> community.
>> Our only requirement to be official is that you behave as one of us. There is
>> nothing stopping those machine learning projects from becoming official. If 
>> they
>> did become official but were still bad software - what would we have solved?
>> 
>> We have a long-time official project that currently has staffing problems. If
>> someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
>> that
>> the contribution rate has fallen off recently they could get the impression 
>> that
>> OpenStack is a bunch of dead crap.
>> 
>> Inclusion as an Official Project in OpenStack is not an indication that 
>> anyone
>> thinks the project is good quality. That's a decision we actively made. This 
>> is
>> the result.
> 
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level of stability/usefulness/maturity/quality" to help newcomers weed out 
> projects that are under TC governance but are not ready for prime time.
> 

There is certainly a concern on the operator community as to how viable/useful 
a project is (and how to determine this). Adopting too early makes for a very 
difficult discussion with cloud users who rely on the function. 

Can an ‘official’ project be deprecated? The economics say yes. The consumer 
confidence impact would be substantial.

However, home grown solutions where there is common interest implies technical 
debt in the long term.

Tim

> Chris
> 
> __
> OpenStack Development Mailing 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] realtime kvm cpu affinities

[Chris Friesen]

On 06/29/2017 10:59 AM, sfinu...@redhat.com wrote:


Thus far, we've no clear conclusions on directions to go, so I've took a stab
below. Henning, Sahid, Chris: does the above/below make sense, and is there
anything we need to further clarify?


The above is close enough. :)


# Problem 1

 From the above, there are 3-4 work items:

- Add a 'emulator_pin_set' or 'cpu_emulator_threads_mask' configuration option

   - If using a mask, rename 'vcpu_pin_set' to 'pin_set' (or, better,
 'usable_cpus')

- Add a 'emulator_overcommit_ratio', which will do for emulator threads what
   the other ratios do for vCPUs and memory


If we were going to support "emulator_overcommit_ratio", then we wouldn't 
necessarily need an explicit mask/set as a config option. If someone wants to 
run with 'hw:emulator_thread_policy=isolate' and we're below the overcommit 
ratio then we run it, otherwise nova could try to allocate a new pCPU to add to 
the emulator_pin_set internally tracked by nova.  This would allow for the 
number of pCPUs in emulator_pin_set to vary depending on the number of instances 
with 'hw:emulator_thread_policy=isolate'on the compute node, which should allow 
for optimal packing.



- Deprecate 'hw:emulator_thread_policy'???


I'm not sure we need to deprecate it, it would instead signify whether the 
emulator threads should be isolated from the vCPU threads.  If set to "isolate" 
then they would run on the emulator_pin_set identified above (potentially 
sharing them with emulator threads from other instances) rather than each 
instance getting a whole pCPU for its emulator threads.



# Problem 2

No clear conclusions yet?


I don't see any particular difficulty in supporting both RT and non-RT instances 
on the same host with one nova-compute process.  It might even be valid for a 
high-performance VM to make use of 'hw:emulator_thread_policy=isolate' without 
enabling RT.  (Which is why I've been careful not to imply RT in the description 
above.)


Chris

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

Re: [openstack-dev] [glance] stepping down from glance core and other related groups

[Kekane, Abhishek]

Hi Nikhil,

I am very thankful for support and guidance you have provided to me and other 
new members. Hoping to work with you again in near future. All the best for 
your future activities.

Cheers,

Abhishek

Sent from OWA on Android

From: Nikhil Komawar 
Sent: Thursday, June 29, 2017 9:39:30 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [glance] stepping down from glance core and other 
related groups

I am thankful to the community for such amazing experience over the past few 
years. For the changes required for glance personnel in the active cycle, I 
would like to step down from core as I cannot commit as much time upstream. I 
was hanging out to help in general but even that time commitment will be 
difficult in the coming months. This should effectively mean, me stepping down 
from the release, core-sec, specs core groups too. I am happy to help where 
needed on case by case basis but I do not think +2/-2 rights or me being 
subscribed to glance-core-sec is needed for such.

Good luck to glancers and all those who form (ionic or covalent) bonds with the 
glance community. Cheers.

--
--
Thanks,
Nikhil

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 08:49:19 -0500 (-0500), Jimmy McArthur wrote:
[...]
> If there is specifically confusion around Google searches, I'd
> suggest as a first step to spend some time working on redirects
> for dead projects and very clearly updating documentation. For all
> of Google's magic, there are some simple and easy rules to help
> correct bad search data.

A good idea, but we're actually not (yet) letting Google or other
robots-abiding crawlers index our repositories on git.openstack.org
until https://review.openstack.org/427959 or something like it
lands.

> Additionally, we just implemented SwifType on OpenStack.org and
> docs.o.o b/c Google deprecated their Site Search product. We have
> a ton of control over that search and can very easily modify
> search results.

At the moment we maintain a specialized search engine for source
code at http://codesearch.openstack.org/ which is a bit more
empowering than basic Web content searches, and it might be a good
idea to see if we can better integrate that in the places where
people see a need for it.

> Let me know if I can be of service on any of these fronts.

Always appreciated!
-- 
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] realtime kvm cpu affinities

[sfinucan]

On Tue, 2017-06-20 at 09:48 +0200, Henning Schild wrote:
> Hi,
> 
> We are using OpenStack for managing realtime guests. We modified
> it and contributed to discussions on how to model the realtime
> feature. More recent versions of OpenStack have support for realtime,
> and there are a few proposals on how to improve that further.
> 
> ...

I'd put off working my way through this thread until I'd time to sit down and
read it in full. Here's what I'm seeing by way of summaries _so far_.

# Current situation

I think this tree (sans 'hw' prefixes for brevity) represents the current
situation around flavor extra specs and image meta. Pretty much everything
hangs off cpu_policy=dedicated. Correct me if I'm wrong.

  cpu_policy
  ╞═> shared
  ╘═> dedicated
  ├─> cpu_thread_policy
  │   ╞═> prefer
  │   ╞═> isolate
  │   ╘═> require
  ├─> emulator_threads_policy (*)
  │   ╞═> share
  │   ╘═> isolate
  └─> cpu_realtime
  ╞═> no
  ╘═> yes
  └─> cpu_realtime_mask
  ╘═> (a mask of guest cores)

(*) this one isn't configurable via images. I never really got why but meh.

There's also some host-level configuration options

  vcpu_pin_set
  ╘═> (a list of host cores that nova can use)

Finally, there's some configuration you can do with your choice of kernel and
kernel options (e.g. 'isolcpus').

For real time workloads, the expectation would be that you would set:

  cpu_policy
  ╘═> dedicated
  ├─> cpu_thread_policy
  │   ╘═> isolate
  ├─> emulator_threads_policy
  │   ╘═> isolate
  └─> cpu_realtime
  ╘═> yes
  └─> cpu_realtime_mask
  ╘═> (a mask of guest cores)

That would result in a host that would use N+1 vCPUs, where N corresponds to
the number of instance cores. Of the N cores, the set masked by
'cpu_realtime_mask' will be non-realtime. The remainder will be realtime.

# The Problem(s)

I'm going to thread this to capture the arguments and counter arguments:

## Problem 1

henning.schild suggested that the current implementation of
'emulator_thread_policy' is too resource intensive, as the 1 core generally
has a minimal workload for entire guests. This can significantly limit the
number of guests that can be booted per host, particularly for guests with
smaller numbers of cores. Instead, he has implemented a 'emulator_pin_set'
host-level option, which complements 'vcpu_pin_set'. This allows us to "pool"
emulator threads, similar to how vCPU threads behave with 'cpu_policy=shared'.
He suggests this be adopted by nova.

  sahid seconded this, but suggests 'emulator_pin_set' be renamed
  'cpu_emulator_threads_mask' and work as a mask of 'vcpu_pin_set'. He also
  suggested making a similarly-named flavor property, that would allow the
  user to use one of their cores for non-realtime 

henning.schild suggested a set would still be better, but that
'vpu_pin_set' be renamed to 'pin_set', as it would no longer be for only
vCPUs

  cfriesen seconded henning.schild's position but was not entirely
  convinced that sharing emulator threads on a single pCPU is guaranteed
  to be safe, for example if one instance starts seriously hammering on
  I/O or does live migration or something. He suggested that an additional
  option, 'rt_emulator_overcommit_ratio' be added to make overcommitting
  explicit. In addition, he suggested making the flavor property a bitmask

sahid questioned the need for an overcommit ratio, given that there is
no overcommit of the hosts. An operator could synthesize a suitable
value for 'emulator_pin_set'/'cpu_emulator_threads_mask'. He also
disagreed with the suggestion that the flavor property be a bitmask as
the only set is that of the vCPUs.

  cfriesen clarifies to point out how a few instances with many vCPUs
  will have more overhead requirements than many instances with few
  vCPUs. We need to be able to fail scheduling if the emulator thread
  cores are oversubscribed.

## Problem 2

henning.schild suggests that hosts should be able to handle both RT and non-RT
instances. This could be achieved through multiple instances of nova

  sahid points out that the recommendation is to use host aggregates to
  separate the two.

henning.schild states that hosts with RT kernels can manage non-RT guests
just fine. However, if using host aggregates is the recommendation then it
should be possible to run multiple nova instances on a host, because
dedicating an entire machine is not viable for smaller operations. cfriesen
seconds this perspective, though not this solution.

# Solutions

Thus far, we've no clear conclusions on directions to go, so I've took a stab
below. Henning, Sahid, Chris: does the above/below make sense, and is there
anything we need to further clarify?

# Problem 1

From the above, there are 3-4 work items:

- Add a 

[openstack-dev] [keystone] stable/newton is broken

[Lance Bragstad]

Keystone's stable/newton gate is broken [0] [1]. The TL;DR is that our
keystone_tempest_plugin is validating federated mappings before updating
the protocol [2]. The lack of validation was a bug [3] that was fixed in
Ocata, but the fix [4] was never backported.

Since stable/newton is in Phase II, I would consider this a critical fix
to unblock the stable/newton gate. I have a backport up for review [5].

[0] https://review.openstack.org/#/c/469514/
[1]
http://logs.openstack.org/14/469514/1/check/gate-keystone-dsvm-functional-ubuntu-xenial/a4aac66/console.html
[2]
https://github.com/openstack/keystone-tempest-plugin/blob/360bbafa385624f1e86841875baabbbf1104e877/keystone_tempest_plugin/tests/api/identity/v3/test_identity_providers.py#L228-L244
[3] https://bugs.launchpad.net/keystone/+bug/1571878
[4] https://review.openstack.org/#/c/362397/
[5] https://review.openstack.org/#/c/478994/





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

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

[michael mccune]

Greetings OpenStack community,

Today's meeting was slightly longer than last week's, with a few more in 
attendance as well. There were no new major issues brought up and the 
main topics were last week's frozen change[4] and a few minor 
fixes[5][6] in the queue now. These fixes were considered trivial and 
have been merged.


# Newly Published Guidelines

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

# Newly published typo fixes

* Fix html_last_updated_fmt for Python3
  https://review.openstack.org/475219

* Fix missing close bracket
  https://review.openstack.org/#/c/478603/

# API Guidelines Proposed for Freeze

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

None this week

# Guidelines Currently Under Review [3]

* 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

[4] https://review.openstack.org/#/c/446138/
[5] https://review.openstack.org/#/c/475219/
[6] https://review.openstack.org/#/c/478603/

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

__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Andreas Jaeger]

On 2017-06-29 17:33, Monty Taylor wrote:
> On 06/29/2017 10:00 AM, Jimmy McArthur wrote:
>>
>>
>>> Thierry Carrez 
>>> June 29, 2017 at 9:54 AM
>>>
>>> Unfortunately, those pages just exist -- those hundreds of projects
>>> projects might be inactive, they still have git repositories and wiki
>>> pages. We could more actively clean them up (and then yes, adjusting the
>>> corresponding Google juice), but (1) we don't really have any right to
>>> do so unless we get permission (which is hard to get from dead
>>> projects), and (2) that's a giganormous amount of maintenance work.
>> It might be a giganormous amount of maintenance work, but it's the
>> only way you're going to properly fix the Google problem. You can
>> still keep the data archived, but I would change the link to something
>> like /inactive-projects/meteos, again with the proper redirects. And
>> again, updating the sitemap.
>>
>> As far as github, if the project is legitimately dead, the repo should
>> be set to private.
>>
>> Just because something is a lot of work doesn't mean it's not worth
>> doing :)
> 
> When we retire a project, we land a commit to that project that removes
> all of the content and replaces it with a commit message that indicates
> that the project has been retired.
>
Check:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n355

acl-config: /home/gerrit2/acls/openstack/retired.config

So, that's a current mark.

> We could probably add a flag to our projects.yaml file that is "retired"
> or something, that would cause the cgit mirror config to stop listing
> the project (the git repo would still exist and still be cloneable, it
> just wouldn't show up in the web listings)


> Since github for us is just a read-only mirror, I would not object to
> having that flag cause our automation to delete the mirror repo from
> github. Again, we would not be deleting any content, we would just be
> un-publishing it.


> I do not believe either of those would be much work- other than someone
> needing to go through and flag retired projects as such in projects.yaml
> - and I do not believe there are any downsides.

That flagging can be done quickly, see above.

> There is still the wiki- which is still a wiki.

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


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

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

[Along Meng]

Yes， and you need make sure ceilometer-agent-notification and panko was
intalled in a same machine in your environment.
Because ceilometer will load the publisher dispatcher panko from the module
panko and use the database url[1] which configured in panko.conf to init
the database connection.

[1]
https://github.com/openstack/panko/blob/stable/ocata/panko/dispatcher/database.py#L43

MengAlong


On Thu, Jun 29, 2017 at 8:56 PM, gordon chung  wrote:

>
>
> On 29/06/17 07:24 AM, Yaguang Tang wrote:
> > sinks:
> > - name: event_sink
> >   transformers:
> >   triggers:
> >   publishers:
> >   - direct://
> >   - panko://
>
> the publisher path is only available if you have Pike Panko. you need to
> either backport[1] or configure your publisher as:
>
> direct://?dispatcher=panko
>
>
> [1]
> https://github.com/openstack/panko/commit/d785015552937455d76f083d313a73
> a7c0c076b3
>
> cheers,
> --
> gord
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to test private patches on overcloud ?

[Steven Hardy]

On Thu, Jun 29, 2017 at 4:21 PM, Dnyaneshwar Pawar
 wrote:
> Hi,
>
> while testing my patches i am getting errors with command 'openstack deploy
> --templates' any idea what is wrong here?
>
> http://paste.openstack.org/show/614074/

This shows rabbit is failing to start:

 Error: Systemd start for rabbitmq-server failed!

Your patches modify the rabbit configuration I think?

My next step to debug this would be to run rabbit manually and see why
it won't start, fix the config until it does, then align the puppet
configuration with the working settings.

Steve

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Doug Hellmann]

Excerpts from Chris Friesen's message of 2017-06-29 09:35:01 -0600:
> On 06/29/2017 09:23 AM, Monty Taylor wrote:
> 
> > We are already WELL past where we can solve the problem you are describing.
> > Pandora's box has been opened - we have defined ourselves as an Open 
> > community.
> > Our only requirement to be official is that you behave as one of us. There 
> > is
> > nothing stopping those machine learning projects from becoming official. If 
> > they
> > did become official but were still bad software - what would we have solved?
> >
> > We have a long-time official project that currently has staffing problems. 
> > If
> > someone Googles for OpenStack DBaaS and finds Trove and then looks to see 
> > that
> > the contribution rate has fallen off recently they could get the impression 
> > that
> > OpenStack is a bunch of dead crap.
> >
> > Inclusion as an Official Project in OpenStack is not an indication that 
> > anyone
> > thinks the project is good quality. That's a decision we actively made. 
> > This is
> > the result.
> 
> I wonder if it would be useful to have a separate orthogonal status as to 
> "level 
> of stability/usefulness/maturity/quality" to help newcomers weed out projects 
> that are under TC governance but are not ready for prime time.
> 
> Chris
> 

It would be. When we made the shift away from the old incubation
process to our current 4-opens-based governance process, we said
the TC was not necessarily the right body to be making that call.
We may have the expertise for one project, but not another. We also
said that because different people could reasonably have different
opinions based on different criteria, The Market or The Community
should produce that information and share it.

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] How to deal with confusion around "hosted projects"

[Chris Friesen]

On 06/29/2017 09:23 AM, Monty Taylor wrote:


We are already WELL past where we can solve the problem you are describing.
Pandora's box has been opened - we have defined ourselves as an Open community.
Our only requirement to be official is that you behave as one of us. There is
nothing stopping those machine learning projects from becoming official. If they
did become official but were still bad software - what would we have solved?

We have a long-time official project that currently has staffing problems. If
someone Googles for OpenStack DBaaS and finds Trove and then looks to see that
the contribution rate has fallen off recently they could get the impression that
OpenStack is a bunch of dead crap.

Inclusion as an Official Project in OpenStack is not an indication that anyone
thinks the project is good quality. That's a decision we actively made. This is
the result.


I wonder if it would be useful to have a separate orthogonal status as to "level 
of stability/usefulness/maturity/quality" to help newcomers weed out projects 
that are under TC governance but are not ready for prime time.


Chris

__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 10:00 AM, Jimmy McArthur wrote:




Thierry Carrez 
June 29, 2017 at 9:54 AM

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.
It might be a giganormous amount of maintenance work, but it's the only 
way you're going to properly fix the Google problem. You can still keep 
the data archived, but I would change the link to something like 
/inactive-projects/meteos, again with the proper redirects. And again, 
updating the sitemap.


As far as github, if the project is legitimately dead, the repo should 
be set to private.


Just because something is a lot of work doesn't mean it's not worth doing :)


When we retire a project, we land a commit to that project that removes 
all of the content and replaces it with a commit message that indicates 
that the project has been retired.


We could probably add a flag to our projects.yaml file that is "retired" 
or something, that would cause the cgit mirror config to stop listing 
the project (the git repo would still exist and still be cloneable, it 
just wouldn't show up in the web listings)


Since github for us is just a read-only mirror, I would not object to 
having that flag cause our automation to delete the mirror repo from 
github. Again, we would not be deleting any content, we would just be 
un-publishing it.


I do not believe either of those would be much work- other than someone 
needing to go through and flag retired projects as such in projects.yaml 
- and I do not believe there are any downsides.


There is still the wiki- which is still a wiki.



Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow 

Re: [openstack-dev] [Openstack-operators] [doc[ptls] Doc meeting

[Alexandra Settle]

Hi everyone,

If you have any questions/concerns/comments/feelings you have about the doc 
migration, bring ‘em to #openstack-meeting at 1600UTC today :)

I’ll be there to chat instead of our regularly scheduled meeting :)

Cheers,

Alex

From: Alexandra Settle 
Date: Wednesday, June 28, 2017 at 6:45 PM
To: "'openstack-d...@lists.openstack.org'" 
, "OpenStack Development Mailing List (not 
for usage questions)" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: [Openstack-operators] [openstack-dev][doc[ptls] Doc meeting

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

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] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 03:00 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


Sure - but:

* wikis are wikis - people can literally put anything there they want to.
* The number of official projects is much larger than the number of 
unofficial. Removing unofficial projects will not solve any confusion.



* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.


Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.


I understand the confusion you're talking about. Removing unofficial 
projects will not solve it.



* Kicking non-official things out will not help

If I'm wrong about the above and it really is all just about not being
able to navigate a set of repositories that are prefixed with the string
'openstack/', it STILL WON'T HELP.

There are 1049 official repos. There are only 1676 repos in gerrit.

Do we honestly think that people who are confused are going to be less
confused by the number of repos in the sacred 'openstack/' namespace
going from 1676 to 1049? Do we next tell projects they can only have
their primary service managed? Kick out chef, puppet, juju and ansible,
as well as the deb- repos? Because maybe the existence of
openstack/deb-python-oslo.privsep is confusing someone?


Again, I agree, but I think you're missing my point. Kicking
non-official things is not about cutting the number of repositories, or
somehow making the git.openstack.org/cgit front page more navigable. We
are indeed past that.

Kicking non-official things is about stopping blurring the line between
what's "in" openstack and what's "out". It's about someone googling for
machine learning on openstack, finding Cognitive on git.openstack.org
and wiki.openstack.org, assuming it's an official openstack project
based on those domain names, trying to check it out, realizing it's only
4 commits and dead for two years, and assuming OpenStack has pretty low
standards and is a bunch of dead crap. How do you propose we address
*that* ?


I'm not missing your point - I'm disagreeing with your premise and your 
conclusions.


We are already WELL past where we can solve 

[openstack-dev] [tripleo] I18n-themed Deep Dive - July 6th

[Julie Pichon]

Hi folks,

As I mentioned during the weekly meeting on Tuesday, I'd like to do a
short i18n-themed deep dive during next week's slot (Thu July 6th, 14:00
UTC). I'll use my BlueJeans at [1] and updated the deep dives etherpad
[2] with that information.

There should be two broad topics:
- Life and journey of a string
  - From when it gets introduced in tripleo-ui, goes through infra, up
to Zanata, and then back
  - I'd also like to share some debugging tips, and how the infra jobs
work
- Working with the I18n team
  - The role of the I18n cross-project liaison
  - How we interact with the team in general, how to make their work
easier
  - Governance, release schedule & string freezes, particularly as a
cycle-trailing project

I mentioned this presentation at the I18n meeting this morning and
several people expressed an interest in attending, it could be a nice
opportunity for both devs & translators to see another side of the
work. If there's something in particular you'd like me to touch on,
feel free to bring it up.

The talk will be recorded and I'll post a transcript as well.

Regards,

Julie

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

__
OpenStack Development Mailing 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] How to test private patches on overcloud ?

[Dnyaneshwar Pawar]

Hi,
while testing my patches i am getting errors with command 'openstack deploy 
--templates' any idea what is wrong here?
http://paste.openstack.org/show/614074/

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

Re: [openstack-dev] [glance] stepping down from glance core and other related groups

[Brian Rosmaita]

On Thu, Jun 29, 2017 at 12:09 AM, Nikhil Komawar  wrote:
> I am thankful to the community for such amazing experience over the past few
> years.

And the Glance community is thankful for your service, which includes
three cycles as the Glance PTL!

> For the changes required for glance personnel in the active cycle, I
> would like to step down from core as I cannot commit as much time upstream.
> I was hanging out to help in general but even that time commitment will be
> difficult in the coming months. This should effectively mean, me stepping
> down from the release, core-sec, specs core groups too. I am happy to help
> where needed on case by case basis but I do not think +2/-2 rights or me
> being subscribed to glance-core-sec is needed for such.

We will certainly appreciate any help you can continue to give on open issues.

> Good luck to glancers and all those who form (ionic or covalent) bonds with
> the glance community. Cheers.

On behalf of the entire Glance community, thank you for your extensive
past service to Glance, and we sincerely hope that you find time to
work on Glance again in the future!

cheers,
brian

>
> --
> --
> Thanks,
> Nikhil
>

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Monty Taylor wrote:
> I also continue to challenge the assertion. There are dead projects in
> there for sure- but there are a LOT of non-dead live projects. It's not
> like we have 6 live and 6 dead projects. The overwhelming majority of
> the projects are not dead.

Early results on my analysis says otherwise... Although it's far from
complete I would say about half of them haven't been touched over the
past year. Feel free to help classifying them at:

https://etherpad.openstack.org/p/negative-space-analysis

-- 
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][tc] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Thierry Carrez 
June 29, 2017 at 9:54 AM

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.
It might be a giganormous amount of maintenance work, but it's the only 
way you're going to properly fix the Google problem. You can still keep 
the data archived, but I would change the link to something like 
/inactive-projects/meteos, again with the proper redirects. And again, 
updating the sitemap.


As far as github, if the project is legitimately dead, the repo should 
be set to private.


Just because something is a lot of work doesn't mean it's not worth doing :)


Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing that people
suggest is one of the causes of people being confused?


I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.


* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people who
express that they think we should only be IaaS - so they're still going
to be unhappy with cloudkitty, congress and karbor.

Such people are under the misguided impression that kicking cloudkitty
out of OpenStack will somehow cause Nova features to land quicker. I
can't even begin to express all of the ways in which it's wrong. We
aren't a top-down corporate structure and we can't 'reassign' humans -
but even if we WERE - this flawed thinking runs afoul of the Mythical
Man Month.


Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/28/2017 11:27 PM, Steven Dake wrote:



On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor > wrote:


On 06/28/2017 09:50 AM, Thierry Carrez wrote:

Hi everyone,

Two weeks ago, as a result of a discussion at the Board+TC+UC
workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The
thread went
in a lot of directions, including discussing GitHub mirroring
strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html



Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we
should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.

The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to
see what
is a part of OpenStack and what's not. If you google "openstack
machine
learning", the first hits are Cognitive and Meteos, and it's
impossible
to tell that those are actually not OpenStack projects. One of
those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or
community.

The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's
nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even
with the
expansive "are you one of us" definition. Arguably the most
confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.

I'd say we have two options. We can address the perception issue
on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack  governance change (or "big tent" change) --
they
are more about what to do with things that are actually *not* in our
governance.

Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of
potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could
find a
way to tag all projects on GitHub that are not official, or
mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official
project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is
that it's
a *lot* of work, and it never completely eliminates the confusion.

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The
benefits of
offering that service are:


I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it.
I do not believe that doing this provides any value to us as a
community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement.
It is suggested that the existence of git repos in the openstack/
github org is confusing to people. And our reaction to that is to
cut off access to our Open Source tools that we set up to
collaboratively develop cloud software and tell people to go use the
thing that people suggest is one of the causes of people being confused?

* People are not 'confused' by what OpenStack is.

Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people
who express that they think we should only 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Jimmy McArthur wrote:
> Thierry Carrez wrote:
>> The confusion I'm talking about is not the passive-aggressive from
>> people involved in openstack. It's from our prospective new users, who
>> have no idea about our governance, making random searches on Google.
>> It's from people getting hit by marketing message from projects claiming
>> to be official OpenStack projects, while they are not. It's extremely
>> difficult for those to see clearly, especially with all our online
>> presence reinforcing the confusion.
>
> If there is specifically confusion around Google searches, I'd suggest
> as a first step to spend some time working on redirects for dead
> projects and very clearly updating documentation. For all of Google's
> magic, there are some simple and easy rules to help correct bad search
> data.

Unfortunately, those pages just exist -- those hundreds of projects
projects might be inactive, they still have git repositories and wiki
pages. We could more actively clean them up (and then yes, adjusting the
corresponding Google juice), but (1) we don't really have any right to
do so unless we get permission (which is hard to get from dead
projects), and (2) that's a giganormous amount of maintenance work.

-- 
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] [trove][all][tc] A proposal to rearchitect Trove

[Amrith Kumar]

Manoj,

It would be great if these teams were brought into this conversation. I am
not averse to the evolutionary approach, merely observing that in the
absence of commitment and contributors who wish to participate in this
evolution, we will be unable to sustain the project.

Regarding your view that it is feasible and rational to evolve Trove, I
would to understand the rationale behind those judgements and the resources
that you believe that it will take to make those possible, and a clear
statement of what your/IBM's commitment of resources to the project would
be.

Thanks,

-amrith


On Thu, Jun 29, 2017 at 9:33 AM, Manoj Kumar  wrote:

> Amrith: Some comments regarding the scarcity of deployments, and the
> proposed approach.
>
> We know of multiple teams that are now independently charging down and
> investing in a Trove path.  They are at various stages of deployment and
> are beyond tire-kicking. They are beginning to build dev/test environments,
> some are building commercial products, and we fully expect some people to
> be in production with Trove by the end of the year.  Collectively, we need
> to start bridging and engaging these people into the Trove community.
>
> We also strongly believe that we need an evolutionary approach to moving
> Trove forward vs. the revolutionary approach that is being proposed.  Our
> deeply held view is that it is feasible and rationale to evolve Trove as it
> exists today.  We agree that there are architectural issues that have to be
> addressed.   Let's start working on addressing these issues as well as the
> current currency issues but in a evolutionary way.  The revolutionary
> approach will halt all progress and set a bad precedent, and we believe
> that it will cause people to walk away from the community and likely
> OpenStack as well.
>
> - Manoj
>
>
>
> From:Amrith Kumar 
> To:"OpenStack Development Mailing List (not for usage questions)"
> 
> Date:06/18/2017 06:41 AM
> Subject:[openstack-dev] [trove][all][tc] A proposal to
> rearchitect Trove
> --
>
>
>
> Trove has evolved rapidly over the past several years, since integration
> in IceHouse when it only supported single instances of a few databases.
> Today it supports a dozen databases including clusters and replication.
>
> The user survey [1] indicates that while there is strong interest in the
> project, there are few large production deployments that are known of (by
> the development team).
>
> Recent changes in the OpenStack community at large (company realignments,
> acquisitions, layoffs) and the Trove community in particular, coupled with
> a mounting burden of technical debt have prompted me to make this proposal
> to re-architect Trove.
>
> This email summarizes several of the issues that face the project, both
> structurally and architecturally. This email does not claim to include a
> detailed specification for what the new Trove would look like, merely the
> recommendation that the community should come together and develop one so
> that the project can be sustainable and useful to those who wish to use it
> in the future.
>
> TL;DR
>
> Trove, with support for a dozen or so databases today, finds itself in a
> bind because there are few developers, and a code-base with a significant
> amount of technical debt.
>
> Some architectural choices which the team made over the years have
> consequences which make the project less than ideal for deployers.
>
> Given that there are no major production deployments of Trove at present,
> this provides us an opportunity to reset the project, learn from our v1 and
> come up with a strong v2.
>
> An important aspect of making this proposal work is that we seek to
> eliminate the effort (planning, and coding) involved in migrating existing
> Trove v1 deployments to the proposed Trove v2. Effectively, with work
> beginning on Trove v2 as proposed here, Trove v1 as released with Pike will
> be marked as deprecated and users will have to migrate to Trove v2 when it
> becomes available.
>
> While I would very much like to continue to support the users on Trove v1
> through this transition, the simple fact is that absent community
> participation this will be impossible. Furthermore, given that there are no
> production deployments of Trove at this time, it seems pointless to build
> that upgrade path from Trove v1 to Trove v2; it would be the proverbial
> bridge from nowhere.
>
> This (previous) statement is, I realize, contentious. There are those who
> have told me that an upgrade path must be provided, and there are those who
> have told me of unnamed deployments of Trove that would suffer. To this,
> all I can say is that if an upgrade path is of value to you, then please
> commit the development resources to participate in the community to make
> that possible. But equally, preventing a v2 of Trove or delaying it 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Anne Gentle 
June 29, 2017 at 9:17 AM
On Thu, Jun 29, 2017 at 8:49 AM, Jimmy McArthur  wrote:

Thierry Carrez wrote:

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.

If there is specifically confusion around Google searches, I'd suggest as a
first step to spend some time working on redirects for dead projects and
very clearly updating documentation. For all of Google's magic, there are
some simple and easy rules to help correct bad search data.


This.

Even though I've worked on the docs for years, I don't think we are
improving on this front.

Jimmy, do you know how to put more recent docs (instead of most
established docs) at the top of the search hits? The nature of the
algorithm rewards longevity over recency, and I've never quite learned
how to take care of that.
Longevity is one thing, as is relevance. If there are projects that are 
no longer maintained but still have "relevant" data under the o.o 
domain, they will come up in a Google search.  The trick is to make sure 
you're removing that data, not just putting a message at the top to the 
end user to say it's no longer an OpenStack project. In this specific 
example, I would create a new page like wiki.o.o/machine-learning with 
valid links to OpenStack docs on machine learning and do a 301 permanent 
redirect from pages that are no longer relevant (e.g. 
https://wiki.openstack.org/wiki/Meteos).


Are there other specific ideas you have?
The best way to tailor Google results is to ensure the sitemap is up to 
date (https://docs.openstack.org/sitemap.xml) and you are setting the 
proper  301, 302, and 404 responses.  If there is old data, it needs to 
be dealt with properly, which is a massive PITA, but completely worth 
it.  Search engines WILL follow the rules if you direct them properly.



Additionally, we just implemented SwifType on OpenStack.org and docs.o.o b/c
Google deprecated their Site Search product. We have a ton of control over
that search and can very easily modify search results.


Pretty sure we want to tackle the "Google is my front page to the
Internet" problem first, but this search change is also excellent and
helpful.
100% correct :)  Just wanted to mention it. Honestly, if you fix the 
Google problem, then you'll automatically fix the new SwifType search as 
well.


Anne


Let me know if I can be of service on any of these fronts.



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




Jimmy McArthur 
June 29, 2017 at 8:49 AM



If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and 
docs.o.o b/c Google deprecated their Site Search product. We have a 
ton of control over that search and can very easily modify search 
results.


Let me know if I can be of service on any of these fronts.


__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez 
June 29, 2017 at 3:00 AM
Monty Taylor wrote:

On 06/28/2017 09:50 AM, Thierry Carrez wrote:

[...] Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The benefits of
offering that service are:

I disagree that this is removing the root cause.

I believe this is reacting to a misunderstanding by hiding from it. I do
not believe that doing this provides any value to us as a community.

Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement. It
is suggested that the existence of git repos in the openstack/ github
org is confusing to people. And our reaction to that is to cut off
access to our Open Source tools that we set up to collaboratively
develop cloud software and tell people to go use the thing 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Monty Taylor]

On 06/29/2017 02:35 AM, Thierry Carrez wrote:

Sean McGinnis wrote:


The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not. If you google "openstack machine
learning", the first hits are Cognitive and Meteos, and it's impossible
to tell that those are actually not OpenStack projects. One of those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or community.


Maybe this is a bit of a tangent from the overall discussion, but
since a lot of confusion, and bad perception, can stem from dead
projects - as a first small step, could we move dead projects
out of openstack/* into closedstack/* and move or mark their wiki
to indicate it is just for legacy reference?


It's difficult to do. From a governance perspective, the "hosted" (or
"unofficial") space has no rules, so it's nobody's job (and right) to
clean things up. From a technical perspective, it's painful due to
Gerrit requiring restarts for every rename.

It's doable -- we'd have to create some governance for the "hosted"
space (creating a bit more confusion, since this was previously defined
as the "ungoverned" space), and add more to the infra team pile of work.

Anyway, that's part of "addressing the confusion at the edges" option.



Agree, it is doable - but is also work.

I also continue to challenge the assertion. There are dead projects in 
there for sure- but there are a LOT of non-dead live projects. It's not 
like we have 6 live and 6 dead projects. The overwhelming majority of 
the projects are not dead.


__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> So I apologise if this has already been suggested/discussed (the
> long threads are difficult to keep up with), but has it been
> considered to go back to using a stackforge namespace?
[...]

Back in the bad ol' days when we had a separate namespace for
unofficial projects, it seemed to me like newcomers were just as
confused as they are now, perhaps even more so. People like to
forget, or wax nostalgic, or simply weren't around to see it first
hand back then; so I agree it's probably worth rehashing the pain
points as it's been a long time since I can recall anyone
enumerating them.

Gerrit's design assumes project names (including any prefixed
namespace) never change. This means project renames in Gerrit are
painful and disruptive (service outage for everyone, Git remote
changes for anyone working on that repo, risk of breaking things
with a SQL update query or directory move, et cetera). There is no
good automation for transfers between orgs in GH either so handling
this is a manual process involving lot of clicking around in a Web
browser. Project renames also touch other systems (our many Git
servers, StoryBoard) so more places to make mistakes or miss
something.

As a result, we would want to actively discourage repos moving from
the stackforge namespace into the openstack namespace (or vice
versa) which creates an artificial hurdle for projects seeking to
become official. This causes them to place an urgent pressure on the
Infra team which makes it harder for us to ease the pain of renames
by batching them up and processing them less frequently. We
similarly would no longer be allowed to create repos directly in the
openstack namespace without prior approval from the TC, which puts
the brakes on the current flow where teams can create a new repo as
quickly as the project-config-cores review the change and then work
on the corresponding governance addition in parallel with doing
their project development.

In the past the ability to push most of the work of doing renames
onto the Infra team created a perverse incentive for projects to
start unofficial so they didn't have to wait on the TC, and then ask
for a rename once they got approval rather than waiting to start
work until the TC approved their request. It's hard for the Infra
team to effectively deter that sort of behavior because the most we
can do is ask authors of their intentions and then trust that
they're being up front about a lack of interest in becoming official
(and that they're unlikely to change their minds about it later).

Unfortunately, hosting unofficial projects grants official teams a
license to experiment in that space rather than taking
responsibility up front, and this is detrimental to our community as
a whole. It also gives new teams an easy excuse to put off applying
to become official until later since they get most of the
infrastructure benefits right away regardless. If we could get rid
of this pervasive temptation to "incubate" ideas out from under the
shadow of governance then maybe that would make maintaining the rest
under a different namespace slightly less of a burden, as the need
to move repos between namespaces would then be far less common or
urgent.
-- 
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] How to deal with confusion around "hosted projects"

[Anne Gentle]

On Thu, Jun 29, 2017 at 8:49 AM, Jimmy McArthur  wrote:
>
>
> Thierry Carrez wrote:
>>
>> The confusion I'm talking about is not the passive-aggressive from
>> people involved in openstack. It's from our prospective new users, who
>> have no idea about our governance, making random searches on Google.
>> It's from people getting hit by marketing message from projects claiming
>> to be official OpenStack projects, while they are not. It's extremely
>> difficult for those to see clearly, especially with all our online
>> presence reinforcing the confusion.
>
> If there is specifically confusion around Google searches, I'd suggest as a
> first step to spend some time working on redirects for dead projects and
> very clearly updating documentation. For all of Google's magic, there are
> some simple and easy rules to help correct bad search data.

This.

Even though I've worked on the docs for years, I don't think we are
improving on this front.

Jimmy, do you know how to put more recent docs (instead of most
established docs) at the top of the search hits? The nature of the
algorithm rewards longevity over recency, and I've never quite learned
how to take care of that.

Are there other specific ideas you have?

>
> Additionally, we just implemented SwifType on OpenStack.org and docs.o.o b/c
> Google deprecated their Site Search product. We have a ton of control over
> that search and can very easily modify search results.

Pretty sure we want to tackle the "Google is my front page to the
Internet" problem first, but this search change is also excellent and
helpful.

Anne

>
> Let me know if I can be of service on any of these fronts.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.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] [telemetry][ceilometer]Cannot get vmware virtual machine's disk usage rate via vsphere inspector

[Along Meng]

HI,gord

Thanks for your infomation.
But I think vmware driver already support my requirement because It's docs
indicate it's already support the counter.
Maybe just the vsphere inspector in ceilometer haven't implement the
interface or we need add some other configuration in ceilometer.
So, is there any one know something about vsphere inspector in ceilometer
can give me some advice?
And I'll try to contact some developers on vmware driver for some help.

MengAlong

On Thu, Jun 29, 2017 at 8:58 PM, gordon chung  wrote:

> i'll be honest, i don't think any of the active developers on Ceilometer
> uses or knows anything about vmware driver. you will probably want to
> reach out to vmware themselves so they can provide support or fix the
> driver (or ideally move the vmware driver to their own repo).
>
> On 28/06/17 10:34 AM, Along Meng wrote:
> >
> > HI, all
> >
> > Today I try to add a new pollster plugin in ceilometer-agent-compute to
> > collect vmware virtual machines's disk usage rate.
> >
> > After researched the vmware docs:
> > https://www.vmware.com/support/developer/converter-
> sdk/conv61_apireference/disk_counters.html#usage
> >  sdk/conv61_apireference/disk_counters.html#usage>
> >
> > I think I can call the vsphere inspector get the
> > counter capacity.provisioned and capacity.usage.
> > Then I can get the virtual machine's disk usage rate via: disk_util
> > = capacity.usage/capacity.provisioned
> >
> > *But, when I add a new function in vsphere inspector like below, It
> > cannot get any data from vcenter:*
> > My example code like this:
> >
> > ceilometer.compute.virt.vmware.inspector.VsphereInspector#inspect_disks
> > 
> =
> > def inspect_disks(self, instance, duration=None):
> > vm_moid = self._ops.get_vm_moid(instance.id )
> > if not vm_moid:
> > raise virt_inspector.InstanceNotFoundException(
> > _('VM %s not found in VMware vSphere') % instance.id
> > )
> >
> > VC_DISK_PROVISIONED_CNTR = "disk:capacity.provisioned:average"
> > disk_counter_id =
> > self._ops.get_perf_counter_id(VC_DISK_PROVISIONED_CNTR)
> > disk_infos = self._ops.query_vm_aggregate_stats(vm_moid,
> > mem_counter_id, duration)
> > print “The disk info is:%s” % disk_infos
> > 
> 
> >
> > The disk_infos is empty.
> >
> > I try to use these functions to query the counter value:
> > self._ops.query_vm_device_stats(vm_moid, disk_counter_id, duration)
> > self._ops.query_vm_aggregate_stats(vm_moid, mem_counter_id, duration)
> >
> > *But cannot get any data from vcenter, and I'm sure the vcenter service
> > is correct in my env.*
> >
> > *Does anyone know what's wrong with my code? *
> > *Or is there any other solutions for my requirement.*
> >
> > Thanks~
> >
> > ==
> > MengAlong
>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Need volunteer(s) to help migrate project docs

[sfinucan]

On Mon, 2017-06-26 at 10:07 +0100, sfinu...@redhat.com wrote:
> On Sat, 2017-06-24 at 14:22 +0800, Zhenyu Zheng wrote:
> > On Sat, Jun 24, 2017 at 12:23 AM, Matt Riedemann 
> > wrote:
> > > The spec [1] with the plan to migrate project-specific docs from
> > > docs.openstack.org to each project has merged.
> > > 
> > > There are a number of steps outlined in there which need people from the
> > > project teams, e.g. nova, to do for their project. Some of it we're
> > > already
> > > doing, like building a config reference, API reference, using the
> > > openstackdocstheme, etc. But there are other things like moving the
> > > install
> > > guide for compute into the nova repo.
> > > 
> > > Is anyone interested in owning this work? There are enough tasks that it
> > > could probably be a couple of people coordinating. It also needs to be
> > > done
> > > by the end of the Pike release, so time is a factor.
> > > 
> > > [1] https://review.openstack.org/#/c/472275/
> > 
> > I will help
> 
> As will I. I've already started restructuring the existings docs (and gave
> feedback to the spec based on that experience) and will start working on
> moving stuff in once done with that. We can probably break this up between
> us, Kevin.

The restructuring patches are up under the topic 'doc-rework' [1]. Would
appreciate reviews so we can move onto dragging in the various guides from
openstack-manuals.

I also note that Chason Chan (no idea what their IRC nick is) has done some
work on this, so we can probably just rebase and use that once the above works.

Stephen

[1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:
master+topic:doc-migration

__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Jimmy McArthur]

Thierry Carrez wrote:

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.
If there is specifically confusion around Google searches, I'd suggest 
as a first step to spend some time working on redirects for dead 
projects and very clearly updating documentation. For all of Google's 
magic, there are some simple and easy rules to help correct bad search 
data.


Additionally, we just implemented SwifType on OpenStack.org and docs.o.o 
b/c Google deprecated their Site Search product. We have a ton of 
control over that search and can very easily modify search results.


Let me know if I can be of service on any of these fronts.


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

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

[Manoj Kumar]

Amrith: Some comments regarding the scarcity of deployments, and the 
proposed approach.

We know of multiple teams that are now independently charging down and 
investing in a Trove path.  They are at various stages of deployment and 
are beyond tire-kicking. They are beginning to build dev/test 
environments, some are building commercial products, and we fully expect 
some people to be in production with Trove by the end of the year. 
Collectively, we need to start bridging and engaging these people into the 
Trove community. 

We also strongly believe that we need an evolutionary approach to moving 
Trove forward vs. the revolutionary approach that is being proposed.  Our 
deeply held view is that it is feasible and rationale to evolve Trove as 
it exists today.  We agree that there are architectural issues that have 
to be addressed.   Let's start working on addressing these issues as well 
as the current currency issues but in a evolutionary way.  The 
revolutionary approach will halt all progress and set a bad precedent, and 
we believe that it will cause people to walk away from the community and 
likely OpenStack as well. 

- Manoj



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

Date:   06/18/2017 06:41 AM
Subject:[openstack-dev] [trove][all][tc] A proposal to rearchitect 
Trove



Trove has evolved rapidly over the past several years, since integration 
in IceHouse when it only supported single instances of a few databases. 
Today it supports a dozen databases including clusters and replication.

The user survey [1] indicates that while there is strong interest in the 
project, there are few large production deployments that are known of (by 
the development team).

Recent changes in the OpenStack community at large (company realignments, 
acquisitions, layoffs) and the Trove community in particular, coupled with 
a mounting burden of technical debt have prompted me to make this proposal 
to re-architect Trove.

This email summarizes several of the issues that face the project, both 
structurally and architecturally. This email does not claim to include a 
detailed specification for what the new Trove would look like, merely the 
recommendation that the community should come together and develop one so 
that the project can be sustainable and useful to those who wish to use it 
in the future.

TL;DR

Trove, with support for a dozen or so databases today, finds itself in a 
bind because there are few developers, and a code-base with a significant 
amount of technical debt.

Some architectural choices which the team made over the years have 
consequences which make the project less than ideal for deployers.

Given that there are no major production deployments of Trove at present, 
this provides us an opportunity to reset the project, learn from our v1 
and come up with a strong v2.

An important aspect of making this proposal work is that we seek to 
eliminate the effort (planning, and coding) involved in migrating existing 
Trove v1 deployments to the proposed Trove v2. Effectively, with work 
beginning on Trove v2 as proposed here, Trove v1 as released with Pike 
will be marked as deprecated and users will have to migrate to Trove v2 
when it becomes available.

While I would very much like to continue to support the users on Trove v1 
through this transition, the simple fact is that absent community 
participation this will be impossible. Furthermore, given that there are 
no production deployments of Trove at this time, it seems pointless to 
build that upgrade path from Trove v1 to Trove v2; it would be the 
proverbial bridge from nowhere.

This (previous) statement is, I realize, contentious. There are those who 
have told me that an upgrade path must be provided, and there are those 
who have told me of unnamed deployments of Trove that would suffer. To 
this, all I can say is that if an upgrade path is of value to you, then 
please commit the development resources to participate in the community to 
make that possible. But equally, preventing a v2 of Trove or delaying it 
will only make the v1 that we have today less valuable.

We have learned a lot from v1, and the hope is that we can address that in 
v2. Some of the more significant things that I have learned are:

- We should adopt a versioned front-end API from the very beginning; 
making the REST API versioned is not a ‘v2 feature’

- A guest agent running on a tenant instance, with connectivity to a 
shared management message bus is a security loophole; encrypting traffic, 
per-tenant-passwords, and any other scheme is merely lipstick on a 
security hole

- Reliance on Nova for compute resources is fine, but dependence on Nova 
VM specific capabilities (like instance rebuild) is not; it makes things 
like containers or bare-metal second class citizens

- A fair portion of what Trove does is resource orchestration; 

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

[sfinucan]

On Wed, 2017-06-21 at 07:01 -0400, Sean Dague wrote:
> On 06/21/2017 04:43 AM, sfinu...@redhat.com wrote:
> > On Tue, 2017-06-20 at 16:48 -0600, Chris Friesen wrote:
> > > On 06/20/2017 09:51 AM, Eric Fried wrote:
> > > > Nice Stephen!
> > > > 
> > > > For those who aren't aware, the rendered version (pretty, so pretty)
> > > > can
> > > > be accessed via the gate-nova-docs-ubuntu-xenial jenkins job:
> > > > 
> > > > http://docs-draft.openstack.org/10/475810/1/check/gate-nova-docs-ubuntu
> > > > -xen
> > > > ial/25e5173//doc/build/html/scheduling.html?highlight=scheduling
> > > 
> > > Can we teach it to not put line breaks in the middle of words in the text
> > > boxes?
> > 
> > Doesn't seem configurable in its current form :( This, and the defaulting
> > to PNG output instead of SVG (which makes things ungreppable) are my
> > biggest bug bear.
> > 
> > I'll go have a look at the sauce and see what can be done about it. If not,
> > still better than nothing?
> 
> I've actually looked through the blockdiag source (to try to solve a
> similar problem). There is no easy way to change it.
> 
> If people find it confusing, the best thing to do would be short labels
> on boxes, then explain in more detail in footnotes.

I managed to get this working through some monkey patching of the module [1].
It's not perfect and efried and I want to do something else to prevent
truncating [2], but it's much better now.

Stephen

[1] https://review.openstack.org/#/c/476159/
[2] https://review.openstack.org/#/c/476204/

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

Re: [openstack-dev] [telemetry][ceilometer]Cannot get vmware virtual machine's disk usage rate via vsphere inspector

[gordon chung]

i'll be honest, i don't think any of the active developers on Ceilometer 
uses or knows anything about vmware driver. you will probably want to 
reach out to vmware themselves so they can provide support or fix the 
driver (or ideally move the vmware driver to their own repo).

On 28/06/17 10:34 AM, Along Meng wrote:
>
> HI, all
>
> Today I try to add a new pollster plugin in ceilometer-agent-compute to
> collect vmware virtual machines's disk usage rate.
>
> After researched the vmware docs:
> https://www.vmware.com/support/developer/converter-sdk/conv61_apireference/disk_counters.html#usage
> 
>
> I think I can call the vsphere inspector get the
> counter capacity.provisioned and capacity.usage.
> Then I can get the virtual machine's disk usage rate via: disk_util
> = capacity.usage/capacity.provisioned
>
> *But, when I add a new function in vsphere inspector like below, It
> cannot get any data from vcenter:*
> My example code like this:
>
> ceilometer.compute.virt.vmware.inspector.VsphereInspector#inspect_disks
> =
> def inspect_disks(self, instance, duration=None):
> vm_moid = self._ops.get_vm_moid(instance.id )
> if not vm_moid:
> raise virt_inspector.InstanceNotFoundException(
> _('VM %s not found in VMware vSphere') % instance.id
> )
>
> VC_DISK_PROVISIONED_CNTR = "disk:capacity.provisioned:average"
> disk_counter_id =
> self._ops.get_perf_counter_id(VC_DISK_PROVISIONED_CNTR)
> disk_infos = self._ops.query_vm_aggregate_stats(vm_moid,
> mem_counter_id, duration)
> print “The disk info is:%s” % disk_infos
> 
>
> The disk_infos is empty.
>
> I try to use these functions to query the counter value:
> self._ops.query_vm_device_stats(vm_moid, disk_counter_id, duration)
> self._ops.query_vm_aggregate_stats(vm_moid, mem_counter_id, duration)
>
> *But cannot get any data from vcenter, and I'm sure the vcenter service
> is correct in my env.*
>
> *Does anyone know what's wrong with my code? *
> *Or is there any other solutions for my requirement.*
>
> Thanks~
>
> ==
> MengAlong

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

[Jeremy Stanley]

On 2017-06-29 11:28:10 +1000 (+1000), Tony Breeds wrote:
[...]
> In the meantime we could look at adding permissions such that the Stable
> PTL (Well actually I guess eventually it'd be the same bot that does the
> release tagging) can push tags and abandon changes on all projects.
> 
> Right now stable-maint-core can do that in a lot of projects but the
> coverage isn't complete.

Sure, we just need to set it in the global configuration instead of
on a per-project basis.

> That would allow us to make forward progress and reduce the task for the
> infra team to deleting the branches.  It does of course introduce a
> race where I could tag a branch as EOL and then that project merge
> another change.  Can you think of a way to avoid that?

Not a convenient one anyway... we could probably merge (hundreds of)
ACL changes preventing approvals on that branch for the projects
participating in the EOL process, but that's probably worse than
accepting that there might be a patch or two created, reviewed and
landed on some project between the EOL tag and branch deletion. The
additional changes that merge after the tag won't effectively be
reachable once the branch is gone anyway (you could hunt them down
in Gerrit, but there's no longer a branch in Git containing them an
they're not in the history of any tag at that point). It's probably
neither common nor disruptive enough to be worth our concern.
-- 
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] [ceilometer][panko] Ocata ceilometer event storage configuration

[gordon chung]

On 29/06/17 07:24 AM, Yaguang Tang wrote:
> sinks:
> - name: event_sink
>   transformers:
>   triggers:
>   publishers:
>   - direct://
>   - panko://

the publisher path is only available if you have Pike Panko. you need to 
either backport[1] or configure your publisher as:

direct://?dispatcher=panko


[1] 
https://github.com/openstack/panko/commit/d785015552937455d76f083d313a73a7c0c076b3

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] [tc][all] Move away from meeting channels

[Flavio Percoco]

On 28/06/17 14:02 +, Jeremy Stanley wrote:

Anyway, I don't think we need to propose "moving away from meeting
channels" but rather "allowing teams to not use meeting channels if
it's inconvenient for them." I expect many (most even?) teams who
continue to hold regularly scheduled meetings would do so in the
official meeting channels even if given the opportunity and freedom
to use a different channel.


Yes, this is the goal. I chose a poor title for the thread. The idea is not to
delete the existing meeting channels but certainly not add more. Allow folks to
use their own channels instead.

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] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the
check_instance_state() routine since it doesn't currently handle the power 
state.

The trickier question is how to handle the "resized" state...after evacuating 
an instance in the "resized" state should you be able to revert the resize?  If 
so, how would that work in the case where the instance was resized on the same 
host originally and that host is no longer available?  If not, then you'll end 
up with resources permanently reserved on the host the instance was on before 
the resize.  I suppose one option would be to auto-confirm the resize in the 
case of a resize-to-same-host, but that'll be tricky to process with the host 
not available.

Also, it should be noted that when rebuilding/evacuating a "stopped" instance 
the nova code just boots it up as normal and sets the vm_state to "active", 
then realizes that it's supposed to be stopped and sets the task_state to 
"powering_off" and goes down the normal path to stop the instance, eventually 
setting the vm_state to "stopped".  So you're still going to end up with the 
same state transitions as what you have now, though the timing will probably be 
a bit tighter.  If you really want a stopped instance to not actually start up 
on a rebuild/evacuate then that would be additional work.

Chris

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for 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] Plan description in the create/update plan form

[Ana Krivokapic]

Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic  wrote:

> Hi TripleO devs,
>
> I am working on adding a description field to the "Crate Plan" form in the
> TripleO UI [1]. The goal is to make it possible for the user to specify a
> plan description using a form field when creating a plan. As the plan
> description lives in the plan-environment.yaml file[2], the idea is to
> retrieve this value from plan-environment.yaml when the user uploads the
> plan, populate the form field with it, let the user change it, and then
> save it back to the file.
>
> I have a WIP patch up [3] which solves the issue in the case of uploading
> the plan as a folder. However, I am having a hard time solving the case of
> uploading the plan as a tarball. The issue is obviously with accessing the
> contents of the tarball. Here are some possible approaches that come to
> mind:
>
> 1) Use one of the existing third-party JS libraries that can extract a
> tarball in the browser. Pros: front-end only solution, no need for
> additional API calls, no need for back-end changes. Cons: adding a new
> dependency, these libraries don't seem much maintained.
>
> 2) Use swift to upload and extract the tarball. Pros: no need for back-end
> changes, we can just call the swift API. Cons: splitting the tarball upload
> from plan creation, which should really be one atomic operation.
>
> 3) Modify the plan create workflow to accept a plan description as a
> parameter. Pros: keeps plan creation atomic. Cons: changes to the plan
> create workflow interface needed. Also this way there is no way to send
> back the information about the description to the UI, we would have to just
> accept the value of the form field, and overwrite whatever was in the
> plan-environment.yaml file.
>
> Of course there is also a fourth option:
>
> 4) This is not worth the effort to implement and we should just drop it. :)
>
> My personal opinion is that the cons of 1) and 2) make these approaches
> unacceptable. The cons of 3) make it kind of not worth it - seems like a
> lot of work for a partial solution. So I'm leaning towards 4) at the moment.
>
> I'd like to hear your opinions on this, is there a another/better approach
> that I'm missing? Jirka, you mentioned we could postpone this work to the
> next cycle and there are improvements that we can work on in the meantime
> which would make implementation of this feature easier?
>
> Any and all thoughts, comments, opinions are welcome.
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1698818
> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/plan-
> environment.yaml#L4-L5
> [3] https://review.openstack.org/#/c/477536/
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Plan description in the create/update plan form

[Ana Krivokapic]

Hi TripleO devs,

I am working on adding a description field to the "Crate Plan" form in the
TripleO UI [1]. The goal is to make it possible for the user to specify a
plan description using a form field when creating a plan. As the plan
description lives in the plan-environment.yaml file[2], the idea is to
retrieve this value from plan-environment.yaml when the user uploads the
plan, populate the form field with it, let the user change it, and then
save it back to the file.

I have a WIP patch up [3] which solves the issue in the case of uploading
the plan as a folder. However, I am having a hard time solving the case of
uploading the plan as a tarball. The issue is obviously with accessing the
contents of the tarball. Here are some possible approaches that come to
mind:

1) Use one of the existing third-party JS libraries that can extract a
tarball in the browser. Pros: front-end only solution, no need for
additional API calls, no need for back-end changes. Cons: adding a new
dependency, these libraries don't seem much maintained.

2) Use swift to upload and extract the tarball. Pros: no need for back-end
changes, we can just call the swift API. Cons: splitting the tarball upload
from plan creation, which should really be one atomic operation.

3) Modify the plan create workflow to accept a plan description as a
parameter. Pros: keeps plan creation atomic. Cons: changes to the plan
create workflow interface needed. Also this way there is no way to send
back the information about the description to the UI, we would have to just
accept the value of the form field, and overwrite whatever was in the
plan-environment.yaml file.

Of course there is also a fourth option:

4) This is not worth the effort to implement and we should just drop it. :)

My personal opinion is that the cons of 1) and 2) make these approaches
unacceptable. The cons of 3) make it kind of not worth it - seems like a
lot of work for a partial solution. So I'm leaning towards 4) at the moment.

I'd like to hear your opinions on this, is there a another/better approach
that I'm missing? Jirka, you mentioned we could postpone this work to the
next cycle and there are improvements that we can work on in the meantime
which would make implementation of this feature easier?

Any and all thoughts, comments, opinions are welcome.

[1] https://bugs.launchpad.net/tripleo/+bug/1698818
[2]
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5
[3] https://review.openstack.org/#/c/477536/

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

[Yaguang Tang]

Hi all,

 I am using Ocata Ceilometer  Gnocchi with Panko, Panko is configured to
use MySQL as backend to store events, I configured Ceilometer
event_pipeline.yaml as follow:


sinks:
- name: event_sink
  transformers:
  triggers:
  publishers:
  - direct://
  - panko://

but it seems no events stored  actually, looking at the code, Ceilometer
have no event storage backend already, so how to config Ceilometer to
pushlish/dispatch events to store through Panko database ?

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

Re: [openstack-dev] realtime kvm cpu affinities

[Henning Schild]

Am Wed, 28 Jun 2017 11:34:42 +0200
schrieb Sahid Orentino Ferdjaoui :

> On Tue, Jun 27, 2017 at 04:00:35PM +0200, Henning Schild wrote:
> > Am Tue, 27 Jun 2017 09:44:22 +0200
> > schrieb Sahid Orentino Ferdjaoui :
> >   
> > > On Mon, Jun 26, 2017 at 10:19:12AM +0200, Henning Schild wrote:  
> > > > Am Sun, 25 Jun 2017 10:09:10 +0200
> > > > schrieb Sahid Orentino Ferdjaoui :
> > > > 
> > > > > On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen
> > > > > wrote:
> > > > > > On 06/23/2017 09:35 AM, Henning Schild wrote:  
> > > > > > > Am Fri, 23 Jun 2017 11:11:10 +0200
> > > > > > > schrieb Sahid Orentino Ferdjaoui
> > > > > > > :  
> > > > > >   
> > > > > > > > In Linux RT context, and as you mentioned, the non-RT
> > > > > > > > vCPU can acquire some guest kernel lock, then be
> > > > > > > > pre-empted by emulator thread while holding this lock.
> > > > > > > > This situation blocks RT vCPUs from doing its work. So
> > > > > > > > that is why we have implemented [2]. For DPDK I don't
> > > > > > > > think we have such problems because it's running in
> > > > > > > > userland.
> > > > > > > > 
> > > > > > > > So for DPDK context I think we could have a mask like we
> > > > > > > > have for RT and basically considering vCPU0 to handle
> > > > > > > > best effort works (emulator threads, SSH...). I think
> > > > > > > > it's the current pattern used by DPDK users.  
> > > > > > > 
> > > > > > > DPDK is just a library and one can imagine an application
> > > > > > > that has cross-core communication/synchronisation needs
> > > > > > > where the emulator slowing down vpu0 will also slow down
> > > > > > > vcpu1. You DPDK application would have to know which of
> > > > > > > its cores did not get a full pcpu.
> > > > > > > 
> > > > > > > I am not sure what the DPDK-example is doing in this
> > > > > > > discussion, would that not just be cpu_policy=dedicated? I
> > > > > > > guess normal behaviour of dedicated is that emulators and
> > > > > > > io happily share pCPUs with vCPUs and you are looking for
> > > > > > > a way to restrict emulators/io to a subset of pCPUs
> > > > > > > because you can live with some of them beeing not
> > > > > > > 100%.  
> > > > > > 
> > > > > > Yes.  A typical DPDK-using VM might look something like
> > > > > > this:
> > > > > > 
> > > > > > vCPU0: non-realtime, housekeeping and I/O, handles all
> > > > > > virtual interrupts and "normal" linux stuff, emulator runs
> > > > > > on same pCPU vCPU1: realtime, runs in tight loop in
> > > > > > userspace processing packets vCPU2: realtime, runs in tight
> > > > > > loop in userspace processing packets vCPU3: realtime, runs
> > > > > > in tight loop in userspace processing packets
> > > > > > 
> > > > > > In this context, vCPUs 1-3 don't really ever enter the
> > > > > > kernel, and we've offloaded as much kernel work as possible
> > > > > > from them onto vCPU0.  This works pretty well with the
> > > > > > current system. 
> > > > > > > > For RT we have to isolate the emulator threads to an
> > > > > > > > additional pCPU per guests or as your are suggesting to
> > > > > > > > a set of pCPUs for all the guests running.
> > > > > > > > 
> > > > > > > > I think we should introduce a new option:
> > > > > > > > 
> > > > > > > >- hw:cpu_emulator_threads_mask=^1
> > > > > > > > 
> > > > > > > > If on 'nova.conf' - that mask will be applied to the
> > > > > > > > set of all host CPUs (vcpu_pin_set) to basically pack
> > > > > > > > the emulator threads of all VMs running here (useful
> > > > > > > > for RT context).  
> > > > > > > 
> > > > > > > That would allow modelling exactly what we need.
> > > > > > > In nova.conf we are talking absolute known values, no need
> > > > > > > for a mask and a set is much easier to read. Also using
> > > > > > > the same name does not sound like a good idea.
> > > > > > > And the name vcpu_pin_set clearly suggest what kind of
> > > > > > > load runs here, if using a mask it should be called
> > > > > > > pin_set.  
> > > > > > 
> > > > > > I agree with Henning.
> > > > > > 
> > > > > > In nova.conf we should just use a set, something like
> > > > > > "rt_emulator_vcpu_pin_set" which would be used for running
> > > > > > the emulator/io threads of *only* realtime instances.  
> > > > > 
> > > > > I'm not agree with you, we have a set of pCPUs and we want to
> > > > > substract some of them for the emulator threads. We need a
> > > > > mask. The only set we need is to selection which pCPUs Nova
> > > > > can use (vcpus_pin_set).
> > > > 
> > > > At that point it does not really matter whether it is a set or a
> > > > mask. They can both express the same where a set is easier to
> > > > read/configure. With the same argument you could say that
> > > > vcpu_pin_set should be a mask over the hosts pcpus.
> > > > 
> > > > As i said before: vcpu_pin_set should be renamed 

Re: [openstack-dev] [tc][swg] The future of the Stewardship Working Group

[Amrith Kumar]

Colette,

First of all, thank you for all that you have done in leading the charge
around the SWG (since long before it got that name). I had the good fortune
of being able to work with the first group of members of the TC who
attended the training in Michigan at Zing Train and I think the discussions
we had there, and the changes that you were able to drive as part of the
SWG were very useful.

Thanks, and all the very best at Spotify,

-amrith




On Wed, Jun 28, 2017 at 4:08 PM, Colette Alexander <
colettealexan...@gmail.com> wrote:

> Hello Stackers,
>
> As many of you know, I recently took a job with Spotify in New York City.
> I spoke with many folks about the transition plans when I was at the Boston
> Forum, and we all decided that it would make sense for me to get settled
> into the new position before deciding what amounts of time I had to tend to
> SWG work, and therefore what my future in the community would look like.
>
> My new job has become a lot busier a lot sooner than expected. I think
> I'll have a little bit more time in my schedule in the next month or so to
> do OpenStack related work, but after summer holidays, I expect things to
> pick back up again.
>
> Because of all of the unknowns around my availability for working on SWG
> things, I think now is a good time to start discussing a potential
> replacement for me as the chair of the group. I have loved working with
> OpenStack and I plan on sticking around in the IRC channel and monitoring
> mailing list work, but I don't think it's fair to the SWG, TC or the entire
> community for me to stay on as chair when I can't devote as much time as
> I'd like to spearheading efforts in the community.
>
> So - that means I'd love to hear from folks about who might be a good
> replacement. I have spoken to a few people behind the scenes to gauge
> interest, but I'd like to open it up the community as a whole at this point
> to start a discussion.
>
> For those of you who don't know what the Stewardship Working Group is:
> https://wiki.openstack.org/wiki/Stewardship_Working_Group is a good place
> to start
>
> Some of the workstreams going on:
> a) Follow up on project ideas from leadership training
> https://etherpad.openstack.org/p/pathtocontribution
> https://etherpad.openstack.org/p/communication-vision
>
> b) Any more poking/helping along of the TC with their current vision
>
> c) An actual vision for the SWG and their next batch of work (this would
> be based on feedback from the training sessions above, and from the
> community, collected at the Atlanta PTG - https://etherpad.openstack.
> org/p/AtlantaPTG-SWG
>
> d) The future of leadership training (more to schedule? break it up into
> smaller groups? who knows?)
>
> I'd be happy to onboard anyone who's interested in terms of getting them
> up to speed on these items.
>
> If anyone wants to discuss any of this with me directly I'm gothicmindfood
> on IRC.
>
> Thanks so much for being such an amazing community to be in - you all
> continue to be some of my favorite humans and I'm so lucky to have gotten a
> chance to work with you.
>
> Sincerely,
>
> -colette/gothicmindfood
>
> __
> OpenStack Development Mailing 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] diskimage builder works for trusty but not for xenial

[Ignazio Cassano]

Hello All,
unfortunately os-refresh-config does not work because new diskimage-builder
does not install dib-utils and jq in the centos7 image.
Regards
Ignazio

2017-06-28 15:28 GMT+02:00 Ignazio Cassano :

> PS
> PS
> Unfortunately os-refresh-config is not working also for centos7 if I
> create a new image today and then a new centos 7 instance on ocata.
> Last centos7 image where os-refresh-config works fine has been created
> with diskimage-builder on 23 of March 2017.
> Please, what is changed meanwhile ?
> Regards
> Ignazio
>
> 2017-06-22 8:00 GMT+02:00 Ignazio Cassano :
>
>> It works fine
>> Thanks
>>
>> 2017-06-22 0:24 GMT+02:00 Ian Wienand :
>>
>>> On 06/21/2017 04:44 PM, Ignazio Cassano wrote:
>>>
 * Connection #0 to host cloud-images.ubuntu.com left intact
 Downloaded and cached
 http://cloud-images.ubuntu.com/xenial/current/xenial-server-
 cloudimg-amd64-root.tar.gz,
 having forced upstream caches to revalidate
 xenial-server-cloudimg-amd64-root.tar.gz: FAILED
 sha256sum: WARNING: 1 computed checksum did NOT match

>>>
>>> Are there any problems on http://cloud-images.ubuntu.com ?

>>>
>>> There was [1] which is apparently fixed.
>>>
>>> As Paul mentioned, the -minimal builds take a different approach and
>>> build the image from debootstrap, rather than modifying the upstream
>>> image.  They are generally well tested just as a side-effect of infra
>>> relying on them daily.  You can use DIB_DISTRIBUTION_MIRROR to set
>>> that to a local mirror and eliminate another source of instability
>>> (however, that leaves the mirror in the final image ... a known issue.
>>> Contributions welcome :)
>>>
>>> -i
>>>
>>> [1] https://bugs.launchpad.net/cloud-images/+bug/1699396
>>>
>>>
>>
>
__
OpenStack Development Mailing List (not for 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]: overcloud deploy --templates fails.

[Dnyaneshwar Pawar]

Hi Steve,
I have used ‘ocata’ bits to created tripleo setup. Because don’t have pike bits 
yet.
I am not sure only upgrading tripleo-common will be sufficient or not.

Is there any wan where I can upgrade my setup to ‘master’ ?

Thanks,
Dnyaneshwar

On 6/29/17, 1:56 PM, "Steven Hardy"  wrote:

On Thu, Jun 29, 2017 at 7:07 AM, Dnyaneshwar Pawar
 wrote:
> Hi,
>
>
>
> I am getting following error. Do I need to specify anything else in the
> command?
>
> This command was working fine before commit
> 3e6147dee4497bbb607e6377bd588e32f62be2b7 .

There is a Depends-On: I961624723d127aebbaacd0c2b481211d83dde3f6 -
have you updated tripleo-common and re-run openstack undercloud
install?

There is some coupling between changes in tripleo-heat-templates and
tripleo-common mistral actions/workbooks, so if you don't update both
parts it's likely things won't work as expected.

Steve

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


__
OpenStack Development Mailing List (not for 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] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

Howdy,

So I apologise if this has already been suggested/discussed (the long
threads are difficult to keep up with), but has it been considered to go
back to using a stackforge namespace?

It seems to me that the role of stackforge to provide a proving ground or
place for aligned projects/repos was quite clear and well understood
(although perhaps I'm wrong). There were some technical challenges in
moving between namespaces that were less than ideal, but have we A)
investigated what would be required to overcome or at least lessen the
technical challenges, and/or B) weighed them against the alternatives and
current proposals?

Cheers,
Josh

On Thu, Jun 29, 2017 at 6:17 PM, Thierry Carrez 
wrote:

> James E. Blair wrote:
> > Thierry Carrez  writes:
> >
> >> Removing the root cause would be a more radical move: stop offering
> >> hosting to non-OpenStack projects on OpenStack infrastructure
> >> altogether. We originally did that for a reason, though. The benefits of
> >> offering that service are:
> >>
> >> 1- it lets us set up code repositories and testing infrastructure before
> >> a project applies to be an official OpenStack project.
> >>
> >> 2- it lets us host things that are not openstack but which we work on
> >> (like abandoned Python libraries or GPL-licensed things) in a familiar
> >> environment
> >>
> >> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> >
> > I think this omits what I consider the underlying reason for why we did
> > it:
> >
> > It helps us build a community around OpenStack.
> >
> > Early on we had so many people telling us that we needed to support
> > "ecosystem" projects better.  That was the word they used at the time.
> > Many of us said "hey, you're free to use github" and they told us that
> > wasn't enough.
> >
> > We eventually got the message and invited them in, and it surpassed our
> > expectations and I think surprised even the most optimistic of us.  We
> > ended up in a place where anyone with an OpenStack related idea can try
> > it out and collaborate frictionlessly with everyone else in the
> > OpenStack community on it, and in doing so, become recognized in the
> > community for that.  The ability for someone to build something on top
> > of OpenStack as part of the OpenStack community has been empowering.
> >
> > I confess to being a skeptic and a convert.  I wasn't thrilled about the
> > unbounded additional responsibility when we started this, but now that
> > we're here, I think it's one of the best things about the project and I
> > would hate to cleave our community by ending it.
>
> I think that's a great point, Jim.
>
> I spent a lot of time last week analyzing the "negative space" (things
> that are on our project infrastructure but are not openstack), and there
> are indeed a number of projects which would qualify as "companion
> projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
> for some proprietary hardware that got kicked out of the Neutron
> stadium. There aren't so many of those, but keeping those close to us is
> definitely a good thing.
>
> Ideally we would find a way to continue to host those, without creating
> any doubt as to whether they are an official OpenStack project under TC
> governance. Such options to address the confusion at the edge exist, and
> they were explored in the previous thread (selective GitHub replication,
> aggressive tagging, active removal of obviously-dead things, separate
> branding/domains...). The main issue being, those options all involved a
> lot of work for the infra team, work that is not conceivable with its
> current limited resources. The only reason why I put the nuclear plan B
> on the table is that we can't get the plan A properly done...
>
> --
> 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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Steven Hardy]

On Thu, Jun 29, 2017 at 4:13 AM, Kaz Shinohara  wrote:
> Hi,
>
>> No, I think we still need this, because it is disabled by default -
>> this option allows you to enable defeating token expiry via trusts,
> My understanding for the current implementation is..
> `deferred_auth_method=trust` triggers getting trust_id and storing it in the 
> db.
> `reauthentication_method=trust` triggers getting trust scoped token by
> taking the trust id(Allow reauthentication)
> Those looks somehow duplicated because trust_id is required only when
> you want to get the trust scoped token, it's ok for heat to get
> trust_id when he need to get trust scoped token, isn't it ?

No they are two different uses for the trust_id;

1. reauthentication_method unset (default) - we can get a trust scoped
token for deferred operations such as autoscaling, but we cannot
defeat the token expiry set by keystone by reauthenticating.

2. reauthentication_method=trusts - we can get a trust scoped token
for any operation (including those initiated by a user with a real not
trust scoped token), such that the token expiry set by keystone can be
defeated.

(2) is not a safe default, but it's useful for certain use-cases such
as TripleO where stack operations can take many hours.

> In case of removing the password authentication, why don't we remove
> `deferred_auth_method` from heat.conf and unify
> 'reauthentication_method' to triggers getting trust_id and getting
> trust scoped token.

Yes as I said before, we could remove deferred_auth_method but we
cannot remove reauthentication_method.

HTH,

Steve

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

Re: [openstack-dev] [tripleo]: overcloud deploy --templates fails.

[Steven Hardy]

On Thu, Jun 29, 2017 at 7:07 AM, Dnyaneshwar Pawar
 wrote:
> Hi,
>
>
>
> I am getting following error. Do I need to specify anything else in the
> command?
>
> This command was working fine before commit
> 3e6147dee4497bbb607e6377bd588e32f62be2b7 .

There is a Depends-On: I961624723d127aebbaacd0c2b481211d83dde3f6 -
have you updated tripleo-common and re-run openstack undercloud
install?

There is some coupling between changes in tripleo-heat-templates and
tripleo-common mistral actions/workbooks, so if you don't update both
parts it's likely things won't work as expected.

Steve

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

James E. Blair wrote:
> Thierry Carrez  writes:
> 
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>> 1- it lets us set up code repositories and testing infrastructure before
>> a project applies to be an official OpenStack project.
>>
>> 2- it lets us host things that are not openstack but which we work on
>> (like abandoned Python libraries or GPL-licensed things) in a familiar
>> environment
>>
>> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I think this omits what I consider the underlying reason for why we did
> it:
> 
> It helps us build a community around OpenStack.
> 
> Early on we had so many people telling us that we needed to support
> "ecosystem" projects better.  That was the word they used at the time.
> Many of us said "hey, you're free to use github" and they told us that
> wasn't enough.
> 
> We eventually got the message and invited them in, and it surpassed our
> expectations and I think surprised even the most optimistic of us.  We
> ended up in a place where anyone with an OpenStack related idea can try
> it out and collaborate frictionlessly with everyone else in the
> OpenStack community on it, and in doing so, become recognized in the
> community for that.  The ability for someone to build something on top
> of OpenStack as part of the OpenStack community has been empowering.
> 
> I confess to being a skeptic and a convert.  I wasn't thrilled about the
> unbounded additional responsibility when we started this, but now that
> we're here, I think it's one of the best things about the project and I
> would hate to cleave our community by ending it.

I think that's a great point, Jim.

I spent a lot of time last week analyzing the "negative space" (things
that are on our project infrastructure but are not openstack), and there
are indeed a number of projects which would qualify as "companion
projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
for some proprietary hardware that got kicked out of the Neutron
stadium. There aren't so many of those, but keeping those close to us is
definitely a good thing.

Ideally we would find a way to continue to host those, without creating
any doubt as to whether they are an official OpenStack project under TC
governance. Such options to address the confusion at the edge exist, and
they were explored in the previous thread (selective GitHub replication,
aggressive tagging, active removal of obviously-dead things, separate
branding/domains...). The main issue being, those options all involved a
lot of work for the infra team, work that is not conceivable with its
current limited resources. The only reason why I put the nuclear plan B
on the table is that we can't get the plan A properly done...

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tripleo][kolla][puppet] DLRN maintenance on June 29, 8:00 AM UTC

[Javier Pena]

The DLRN server maintenance has been completed. If you had any issue in a CI 
job, you can recheck now.

Please contact me if you find any trouble accessing the RDO Trunk repos.

Regards,
Javier

- Original Message -
> This is also of interest for CI jobs in TripleO, kolla and
> puppet-openstack-integration.
> 
> Javier
> 
> - Forwarded Message -
> Hi,
> 
> We need to run some maintenance activities on the DLRN public instance on
> June 29, starting at 8:00 UTC time (10:00 CET). As a result, the
> repositories hosted by trunk.rdoproject.org will be intermittently
> unavailable. The maintenance is expected to last 1 hour.
> 
> Regards,
> Javier
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.com
> 

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

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Monty Taylor wrote:
> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>> [...] Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
> 
> I disagree that this is removing the root cause.
> 
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
> 
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It
> is suggested that the existence of git repos in the openstack/ github
> org is confusing to people. And our reaction to that is to cut off
> access to our Open Source tools that we set up to collaboratively
> develop cloud software and tell people to go use the thing that people
> suggest is one of the causes of people being confused?

I don't think I agree. GitHub is just one area where confusion spreads.
Going back to my example, searching for "openstack machine learning" on
Google will give you links to GitHub, but also the OpenStack wiki, and
our cgit farm. All of them corroborate that the two projects returned
are, by all means, official (while they aren't).

So the suggestion (to cut off access to openstack project infrastructure
for things that are not openstack and will never be) is not in reaction
to GitHub, it's in reaction to the confusion that having them on the
very same project infrastructure creates (on all of our online
presence), *and* how hard it is to address that confusion at the edge.

> * People are not 'confused' by what OpenStack is.
> 
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going
> to be unhappy with cloudkitty, congress and karbor.
> 
> Such people are under the misguided impression that kicking cloudkitty
> out of OpenStack will somehow cause Nova features to land quicker. I
> can't even begin to express all of the ways in which it's wrong. We
> aren't a top-down corporate structure and we can't 'reassign' humans -
> but even if we WERE - this flawed thinking runs afoul of the Mythical
> Man Month.

Sure, but you are missing my point. I totally agree that a lot of people
involved in OpenStack pretend to be confused, despite us being very
clear as to what's officially in OpenStack and what's not, and that's
their own way of complaining about how things turned out.

The confusion I'm talking about is not the passive-aggressive from
people involved in openstack. It's from our prospective new users, who
have no idea about our governance, making random searches on Google.
It's from people getting hit by marketing message from projects claiming
to be official OpenStack projects, while they are not. It's extremely
difficult for those to see clearly, especially with all our online
presence reinforcing the confusion.

> * Kicking non-official things out will not help
> 
> If I'm wrong about the above and it really is all just about not being
> able to navigate a set of repositories that are prefixed with the string
> 'openstack/', it STILL WON'T HELP.
> 
> There are 1049 official repos. There are only 1676 repos in gerrit.
> 
> Do we honestly think that people who are confused are going to be less
> confused by the number of repos in the sacred 'openstack/' namespace
> going from 1676 to 1049? Do we next tell projects they can only have
> their primary service managed? Kick out chef, puppet, juju and ansible,
> as well as the deb- repos? Because maybe the existence of
> openstack/deb-python-oslo.privsep is confusing someone?

Again, I agree, but I think you're missing my point. Kicking
non-official things is not about cutting the number of repositories, or
somehow making the git.openstack.org/cgit front page more navigable. We
are indeed past that.

Kicking non-official things is about stopping blurring the line between
what's "in" openstack and what's "out". It's about someone googling for
machine learning on openstack, finding Cognitive on git.openstack.org
and wiki.openstack.org, assuming it's an official openstack project
based on those domain names, trying to check it out, realizing it's only
4 commits and dead for two years, and assuming OpenStack has pretty low
standards and is a bunch of dead crap. How do you propose we address
*that* ?

> [...]
>> Thoughts on that ? Would you rather address the confusion at the edges,
>> or remove the root cause ?
> 
> The only reasonable action is actually addressing the confusion.
> 
> the confusion isn't just at the edges - the confusion is actually THE
> ONLY PROBLEM. There is no other problem that needs to be solved _other_
> than confusion in this area. The number of projects in gerrit is not a
> technical problem. 

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Sean McGinnis wrote:
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
> 
> Maybe this is a bit of a tangent from the overall discussion, but
> since a lot of confusion, and bad perception, can stem from dead
> projects - as a first small step, could we move dead projects
> out of openstack/* into closedstack/* and move or mark their wiki
> to indicate it is just for legacy reference?

It's difficult to do. From a governance perspective, the "hosted" (or
"unofficial") space has no rules, so it's nobody's job (and right) to
clean things up. From a technical perspective, it's painful due to
Gerrit requiring restarts for every rename.

It's doable -- we'd have to create some governance for the "hosted"
space (creating a bit more confusion, since this was previously defined
as the "ungoverned" space), and add more to the infra team pile of work.

Anyway, that's part of "addressing the confusion at the edges" option.

-- 
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] [nova] bug triage experimentation

[Markus Zoeller]

On 28.06.2017 16:50, Sean Dague wrote:
> On 06/28/2017 10:33 AM, Ben Nemec wrote:
>>
>>
>> On 06/23/2017 11:52 AM, Sean Dague wrote:
>>> The Nova bug backlog is just over 800 open bugs, which while
>>> historically not terrible, remains too large to be collectively usable
>>> to figure out where things stand. We've had a few recent issues where we
>>> just happened to discover upgrade bugs filed 4 months ago that needed
>>> fixes and backports.
>>>
>>> Historically we've tried to just solve the bug backlog with volunteers.
>>> We've had many a brave person dive into here, and burn out after 4 - 6
>>> months. And we're currently without a bug lead. Having done a big giant
>>> purge in the past
>>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
>>>
>>> I know how daunting this all can be.
>>>
>>> I don't think that people can currently solve the bug triage problem at
>>> the current workload that it creates. We've got to reduce the smart
>>> human part of that workload.
>>>
>>> But, I think that we can also learn some lessons from what active github
>>> projects do.
>>>
>>> #1 Bot away bad states
>>>
>>> There are known bad states of bugs - In Progress with no open patch,
>>> Assigned but not In Progress. We can just bot these away with scripts.
>>> Even better would be to react immediately on bugs like those, that helps
>>> to train folks how to use our workflow. I've got some starter scripts
>>> for this up at - https://github.com/sdague/nova-bug-tools
>>
>> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and
>> I don't agree that assigned but not in progress is an invalid state.  If
>> it persists for a period of time then sure, but to me assigning yourself
>> a bug is a signal that you're working on it and nobody else needs to.
>> Otherwise you end up with multiple people working a bug without
>> realizing someone else already was.  I've seen that happen more than once.
> 
> The other case, where folks assign themselves and never do anything,
> happens about 100 times a month.
> 
> We don't live in an exclusive lock environment, anyone can push a fix
> for a bug, and gerrit assigns it to them. I don't see why we'd treat LP
> any differently. Yes, this sometimes leads to duplicate fixes, however
> in the current model it's far more frequent for bugs to be blocked away
> as "assigned" when no one is working on them.
> 
> A future version might be smarter and give folks a 7 day window or
> something, but parsing back the history to understand the right logic
> there is tricky enough that it's a future enhancement at best.
> 
>   -Sean
> 

+1 That happened so frequently I made a query for that:
http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale

After poking people to get the actual state, 99% of the time the answer
was "I couldn't work on it, please remove my assignment.".

-- 
Regards, Markus Zoeller (markus_z)


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

[openstack-dev] [tripleo]: overcloud deploy --templates fails.

[Dnyaneshwar Pawar]

Hi,

I am getting following error. Do I need to specify anything else in the command?
This command was working fine before commit 
3e6147dee4497bbb607e6377bd588e32f62be2b7 .

---
$ openstack overcloud deploy --templates ~/tripleo-heat-templates 2>&1 |tee 
log.overcloud_deploy
Exception updating plan: capabilities-map.yaml missing key: 'root_template'
Removing the current plan files
Uploading new plan files
Started Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. 
Execution ID: cc14a7b6-835c-4867-9268-4c5466529c28
$
-

Following check in had removed ‘root_template’ from capabilities-map.yaml.
---
commit 3e6147dee4497bbb607e6377bd588e32f62be2b7
Author: Ana Krivokapic 
commit 3e6147dee4497bbb607e6377bd588e32f62be2b7
Author: Ana Krivokapic 
Date:   Fri Mar 3 11:56:27 2017 +0100

Remove root_template and root_environment from capabilities-map.yaml

These values now live in plan-environment.yaml.

Change-Id: I7a9448df7c9f84beaac9238f1278633c3ec5ad28
Closes-bug: #1668953
Depends-On: I961624723d127aebbaacd0c2b481211d83dde3f6

diff --git a/capabilities-map.yaml b/capabilities-map.yaml
index cc22ff9..d31e11f 100644
--- a/capabilities-map.yaml
+++ b/capabilities-map.yaml
@@ -2,12 +2,6 @@
# repository for deployment using puppet. It groups configuration by topic,
# describes possible combinations of environments and resource capabilities.

-# root_template: identifies repository's root template
-# root_environment: identifies root_environment, this one is special in terms 
of
-#   order in which the environments are merged before deploying. This one 
serves as
-#   a base and it's parameters/resource_registry gets overridden by other 
environments
-#   if used.
-
# topics:
# High Level grouping by purpose of environments
# Attributes:
@@ -38,8 +32,6 @@
# only when that given environment is used. (resource_type of that environment 
can
# be implemented using multiple templates).

-root_template: overcloud.yaml
-root_environment: overcloud-resource-registry-puppet.yaml
topics:
-


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