[openstack-dev] [nova][placement] openstack/placement governance switch plan

[melanie witt]

Howdy everyone,

Those of us involved in the placement extraction process sat down 
together today to discuss the plan for openstack/placement governance. 
We agreed on a set of criteria which we will use to determine when we 
will switch the openstack/placement governance from the compute project 
to its own project. I'd like to update everyone with a summary of the 
plan we agreed upon.


Attendees: Balázs Gibizer, Chris Dent, Dan Smith, Ed Leafe, Eric Fried, 
Jay Pipes, Matt Riedemann, Melanie Witt, Mohammed Naser, Sylvain Bauza


The targets we have set are:

- Devstack/grenade job that executes an upgrade which deploys the 
extracted placement code
- Support in one of the deployment tools to deploy extracted placement 
code (Tripleo)
- An upgrade job using any deployment tool (this might have to be a 
manual test by a deployment tool team member if none of the deployment 
tools have an upgrade job)
- Implementation of nested vGPU resource support in the xenapi and 
libvirt drivers
- Functional test with vGPU resources that verifies reshaping of flat 
vGPU resources to nested vGPU resources and successful scheduling to the 
same compute host after reshaping

- Lab test with real hardware of the same ^ (xenapi and libvirt)

Once we have achieved these targets, we will switch openstack/placement 
governance from the compute project to its own project. The 
placement-core team will flatten nova-core into individual members of 
placement-core so it may evolve, the PTL of openstack/placement will be 
the same as the openstack/nova PTL for the remainder of the release 
cycle, and the electorate for the openstack/placement PTL election for 
the next release cycle will be determined by the commit history of the 
extracted placement code repo, probably by date, to include contributors 
from the previous two release cycles, as per usual.


Thank you to Mohammed for facilitating the discussion, we really 
appreciate it.


Cheers,
-melanie





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

Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed

[Tony Breeds]

On Mon, Sep 10, 2018 at 05:58:21AM -0600, Doug Hellmann wrote:
 
> The python3 version of the job worked. I think both jobs ran because the
> repo is in the middle of its zuul settings transition and the cleanup
> patch hasn't merged yet. Since one of them worked, I think the published
> output should be OK.

Ahh okay.  Thanks Doug

Yours Tony.


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

Re: [openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Tony Breeds]

On Wed, Sep 05, 2018 at 10:03:09AM -0500, Matthew Thode wrote:

> The requirements team has gone ahead and made a aweful hack to get gate
> unwedged.  The commit message is a very good summary of our reasoning
> why it has to be this way for now.  My comment explains our plan going
> forward (there will be a revert prepared as soon as this merges for
> instance).
> 
> step 1. merge this

This == https://review.openstack.org/#/c/599277/ ; done and similar
versions on stable branches.

> step 2. look into and possibly fix our tooling (why was the gitref
> addition not rejected by gate)

Not done yet

> step 3. fix networking-odl (release ceilometer)

Done.  See:
 * https://review.openstack.org/#/c/601487/ ; and
 * https://review.openstack.org/#/c/601488/

> step 4. unmerge this

Done and marked as Depending on the reviews above.
https://review.openstack.org/#/c/600123/

So I think we have the required reviews lined up to fix master, but they
need votes from zuul and core teams.

We can handle stable later ;P

Yours Tony.


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

Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed

[Tony Breeds]

On Tue, Sep 11, 2018 at 07:39:39AM +1000, Ian Wienand wrote:
> > On Mon, Sep 10, 2018 at 05:13:35AM +, z...@openstack.org wrote:
> >> Build failed.
> >>
> >> - publish-openstack-releasenotes 
> >> http://logs.openstack.org/c8/c89ca61fdcaf603a10750b289228b7f9a3597290/tag/publish-openstack-releasenotes/fbbd0fa/
> >>  : FAILURE in 4m 03s
> 
> The line that is causing this is
> 
>   - Add OSC plugin support for the “Networking Service Function Chaining” ...
> 
> see if you can find the unicode :)
> 
> I did replicate it by mostly doing what the gate does; make a python2
> vitualenv and install everything, then run
> 
>  ./env/bin/sphinx-build -a -E -W -d releasenotes/build/doctrees/ \
>-b html releasenotes/source/ releasenotes/build/html/
> 
> In the gate, it doesn't use "tox -e releasenotes" ... which passes
> because it's python3 and everything is unicode already.
> 
> I think this is a reno problem, and I've proposed
> 
>   https://review.openstack.org/601432 Use unicode for debug string

Thanks Ian!

Yours Tony.


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

Re: [openstack-dev] [release][octavia]

[Doug Hellmann]

Excerpts from Michael Johnson's message of 2018-09-10 21:48:53 -0600:
> Octavia and Release teams,
> 
> I am adding Carlos Goncalves to the Octavia project release management
> liaison list for Stein.
> He will be assisting with regular stable branch release patches.
> 
> Let me know if you have any questions or concerns,
> Michael
> 

I see you've updated the wiki, too. Thanks for the heads-up!

Doug

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

[openstack-dev] [release][octavia]

[Michael Johnson]

Octavia and Release teams,

I am adding Carlos Goncalves to the Octavia project release management
liaison list for Stein.
He will be assisting with regular stable branch release patches.

Let me know if you have any questions or concerns,
Michael

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

Re: [openstack-dev] [TripleO] Plan management refactoring for Life cycle

[James Slagle]

On Mon, Sep 10, 2018 at 10:12 AM Jiri Tomasek  wrote:
>
> Hi Mathieu,
>
> Thanks for bringing up the topic. There are several efforts currently in 
> progress which should lead to solving the problems you're describing. We are 
> working on introducing CLI commands which would perform the deployment 
> configuration operations on deployment plan in Swift. This is a main step to 
> finally reach CLI and GUI compatibility/interoperability. CLI will perform 
> actions to configure deployment (roles, networks, environments selection, 
> parameters setting etc.) by calling Mistral workflows which store the 
> information in deployment plan in Swift. The result is that all the 
> information which define the deployment are stored in central place - 
> deployment plan in Swift and the deploy command is turned into simple 
> 'openstack overcloud  deploy'. Deployment plan then has 
> plan-environment.yaml which has the list of environments used and customized 
> parameter values, roles-data.yaml which carry roles definition and 
> network-data.yaml which carry networks definition. The information stored in 
> these files (and deployment plan in general) can then be treated as source of 
> information about deployment. The deployment can then be easily exported and 
> reliably replicated.
>
> Here is the document which we put together to identify missing pieces between 
> GUI,CLI and Mistral TripleO API. We'll use this to discuss the topic at PTG 
> this week and define work needed to be done to achieve the complete 
> interoperability. [1]
>
> Also there is a pending patch from Steven Hardy which aims to remove CLI 
> specific environments merging which should fix the problem with tracking of 
> the environments used with CLI deployment. [2]
>
> [1] https://gist.github.com/jtomasek/8c2ae6118be0823784cdafebd9c0edac 
> (Apologies for inconvenient format, I'll try to update this to 
> better/editable format. Original doc: 
> https://docs.google.com/spreadsheets/d/1ERfx2rnPq6VjkJ62JlA_E6jFuHt9vVl3j95dg6-mZBM/edit?usp=sharing)
> [2] https://review.openstack.org/#/c/448209/


Related to this work, I'd like to see us store the plan in git instead
of swift. I think this would reduce some of the complexity around plan
management, and move us closer to a simpler undercloud architecture.
It would be nice to see each change to the plan represented as new git
commit, so we can even see the changes to the plan as roles, networks,
services, etc, are selected.

I also think git would provide a familiar experience for both
developers and operators who are already accustomed to devops type
workflows. I think we could make these changes without it impact the
API too much or, hopefully, at all.

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] [Searchlight] Virtual PTG topic updating

[Trinh Nguyen]

Hi Searchlight team,

Because we don't have the team meeting this week so I'm planning to
organize the virtual PTG on 20th Sep, 12:00 UTC. Please join me on the IRC
channel (#openstack-searchlight) and find out an appropriate schedule. The
purposes of this meeting are:

   - Talk to the team face-to-face virtually (using Zoom) :)
   - Discuss about how we will release in Stein-1
   - Update project's progress.

Please put your discussion topics on the Etherpad link [1] so we can fix
the schedule accordingly.

[1] https://etherpad.openstack.org/p/searchlight-stein-ptg

Thanks,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
OpenStack Development Mailing 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] Fwd: [Openstack-operators] revamped ops meetup day 2

[Erik McCormick]

-- Forwarded message -
From: Chris Morgan 
Date: Mon, Sep 10, 2018, 5:55 PM
Subject: [Openstack-operators] revamped ops meetup day 2
To: OpenStack Operators , <
openstaack-...@lists.openstack.org>


Hi All,
  We (ops meetups team) got several additional suggestions for ops meetups
session, so we've attempted to revamp day 2 to fit them in, please see

https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=981527336

Given the timing, we'll attempt to confirm the rest of the day starting at
9am over coffee. If you're moderating something tomorrow please check out
the adjusted times. If something doesn't work for you we'll try and swap
sessions to make it work.

Cheers
Chris, Erik, Sean

-- 
Chris Morgan 
___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
__
OpenStack Development Mailing 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] [upgrade] request for pre-upgrade check for db purge

[Matt Riedemann]

I created a nova bug [1] to track a request that came up in the upgrades 
SIG room at the PTG today [2] and would like to see if there is any 
feedback from other operators/developers that weren't part of the 
discussion.


The basic problem is that failing to archive/purge deleted records* from 
the database can make upgrades much slower during schema migrations. 
Anecdotes from the room mentioned that it can be literally impossible to 
complete upgrades for keystone and heat in certain scenarios if you 
don't purge the database first.


The request was that a configurable limit gets added to each service 
which is checked as part of the service's pre-upgrade check routine [3] 
and warn if the number of records to purge is over that limit.


For example, the nova-status upgrade check could warn if there are over 
10 deleted records total across all cells databases. Maybe cinder 
would have something similar for deleted volumes. Keystone could have 
something for revoked tokens.


Another idea in the room was flagging on records over a certain age 
limit. For example, if there are deleted instances in nova that were 
deleted >1 year ago.


How do people feel about this? It seems pretty straight-forward to me. 
If people are generally in favor of this, then the question is what 
would be sane defaults - or should we not assume a default and force 
operators to opt into this?


* nova delete doesn't actually delete the record from the instances 
table, it flips a value to hide it - you have to archive/purge those 
records to get them out of the main table.


[1] https://bugs.launchpad.net/nova/+bug/1791824
[2] https://etherpad.openstack.org/p/upgrade-sig-ptg-stein
[3] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html

--

Thanks,

Matt

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

Re: [openstack-dev] [election][tc] Opinion about 'PTL' tooling

[Lance Bragstad]

I agree in that it's dependent on what metrics you think accurately
showcase project health. Is it the number of contributions? The number of
unique contributors? Diversity across participating organizations?
Completion ratios of blueprints or committed fixes over bugs opened? I
imagine different projects will have different opinions on this, but it
would be interesting to know what those opinions are.

I think if you can reasonably justify a metric as an accurate
representation of health, then it makes sense to try and automate it.

This jogged my memory and it might not be a valid metric of health, but I
liked the idea after I heard another project doing it (I think it was
swift). If you could recognize contributions (loosely defined here to be
reviews, patches, bug triage) for an individual and if you noticed those
contributions dropping off after a period of time, then you (as a
maintainer or PTL of a project) could reach out to the individual directly.
This assumes the reason isn't obvious and feels like it is more meant to
track lost contributors.

On Mon, Sep 10, 2018 at 3:27 PM Samuel Cassiba  wrote:

> On Mon, Sep 10, 2018 at 6:07 AM, Jeremy Stanley  wrote:
> > On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote:
> >> I think something we should take into consideration is *what* you
> >> consider health because the way we’ve gone about it over health
> >> checks is not something that can become a toolkit because it was
> >> more of question asking, etc
> > [...]
> >
> > I was going to follow up with something similar. It's not as if the
> > TC has a toolkit of any sort at this point to come up with the
> > information we're assembling in the health tracker either. It's
> > built up from interviewing PTLs, reading meeting logs, looking at
> > the changes which merge to teams' various deliverable repositories,
> > asking around as to whether they've missed important deadlines such
> > as release milestones (depending on what release models they
> > follow) or PTL nominations, looking over cycle goals to see how far
> > along they are, and so on. Extremely time-consuming which is why
> > it's taken us most of a release cycle and we still haven't finished
> > a first pass.
> >
> > Assembling some of this information might be automatable if we make
> > adjustments to how the data/processes on which it's based are
> > maintained, but at this point we're not even sure which ones are
> > problem indicators at all and are just trying to provide the
> > clearest picture we can. If we come up with a detailed checklist and
> > some of the checks on that list can be automated in some way, that
> > seems like a good thing. However, the original data should be
> > publicly accessible so I don't see why it needs to be members of the
> > technical committee who write the software to collect that.
> > --
> > Jeremy Stanley
> >
>
> Things like tracking project health I see like organizing a trash
> pickup at the local park, or off the side of a road: dirty,
> unglamorous work. The results can be immediately visible to not only
> those doing the work, but passers-by. Eliminating the human factor in
> deeply human-driven interactions can have ramifications immediately
> noticed.
>
> As distributed as things exist today, reducing the conversation to a
> few methods or people can damage intent, without humans talking to
> humans in a more direct manner.
>
> Best,
> Samuel Cassiba (scas)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg][cinder][manila] Team Dinner Plan ...

[Jay S Bryant]

All,

We have landed on a decision for the Cinder/Manila Dinner plan.

Here are the details:

Location:  Casey's Bistro and Pub

 * 7:30 pm Tuesday after the Happy Hour

 * 7301 E 29th Ave, Denver, CO 80238

 * Reservation for Amit

See you all there!

Jay

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

Re: [openstack-dev] [Release-job-failures] Tag of openstack/python-neutronclient failed

[Ian Wienand]

> On Mon, Sep 10, 2018 at 05:13:35AM +, z...@openstack.org wrote:
>> Build failed.
>>
>> - publish-openstack-releasenotes 
>> http://logs.openstack.org/c8/c89ca61fdcaf603a10750b289228b7f9a3597290/tag/publish-openstack-releasenotes/fbbd0fa/
>>  : FAILURE in 4m 03s

The line that is causing this is

  - Add OSC plugin support for the “Networking Service Function Chaining” ...

see if you can find the unicode :)

I did replicate it by mostly doing what the gate does; make a python2
vitualenv and install everything, then run

 ./env/bin/sphinx-build -a -E -W -d releasenotes/build/doctrees/ \
   -b html releasenotes/source/ releasenotes/build/html/

In the gate, it doesn't use "tox -e releasenotes" ... which passes
because it's python3 and everything is unicode already.

I think this is a reno problem, and I've proposed

  https://review.openstack.org/601432 Use unicode for debug string

Thanks

-i

__
OpenStack Development Mailing 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] [election][tc] Opinion about 'PTL' tooling

[Samuel Cassiba]

On Mon, Sep 10, 2018 at 6:07 AM, Jeremy Stanley  wrote:
> On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote:
>> I think something we should take into consideration is *what* you
>> consider health because the way we’ve gone about it over health
>> checks is not something that can become a toolkit because it was
>> more of question asking, etc
> [...]
>
> I was going to follow up with something similar. It's not as if the
> TC has a toolkit of any sort at this point to come up with the
> information we're assembling in the health tracker either. It's
> built up from interviewing PTLs, reading meeting logs, looking at
> the changes which merge to teams' various deliverable repositories,
> asking around as to whether they've missed important deadlines such
> as release milestones (depending on what release models they
> follow) or PTL nominations, looking over cycle goals to see how far
> along they are, and so on. Extremely time-consuming which is why
> it's taken us most of a release cycle and we still haven't finished
> a first pass.
>
> Assembling some of this information might be automatable if we make
> adjustments to how the data/processes on which it's based are
> maintained, but at this point we're not even sure which ones are
> problem indicators at all and are just trying to provide the
> clearest picture we can. If we come up with a detailed checklist and
> some of the checks on that list can be automated in some way, that
> seems like a good thing. However, the original data should be
> publicly accessible so I don't see why it needs to be members of the
> technical committee who write the software to collect that.
> --
> Jeremy Stanley
>

Things like tracking project health I see like organizing a trash
pickup at the local park, or off the side of a road: dirty,
unglamorous work. The results can be immediately visible to not only
those doing the work, but passers-by. Eliminating the human factor in
deeply human-driven interactions can have ramifications immediately
noticed.

As distributed as things exist today, reducing the conversation to a
few methods or people can damage intent, without humans talking to
humans in a more direct manner.

Best,
Samuel Cassiba (scas)

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

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

[Jay S Bryant]

On 9/10/2018 11:14 AM, Zane Bitter wrote:

On 10/09/18 10:34 AM, Jeremy Stanley wrote:

On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
[...]

# Linking to projects by name

Keen observers might've noticed that StoryBoard recently grew the 
ability

to link to projects by name, rather than by ID number. All the links to
projects in the UI have been replaced with links in this form, and its
probably a good idea for folk to start using them in any documentation
they have. These links look like

https://storyboard.openstack.org/#!/project/openstack-infra/storyboard


Thanks for this!!!

+2  Thank you for addresing this!



[...]

Worth noting, this has made it harder to find the numeric project ID
without falling back on the API. Change
https://review.openstack.org/600893 merged to the releases
repository yesterday allowing deliverable repositories to be
referenced by their StoryBoard project name rather than only the ID
number. If there are other places in tooling and automation where we
relied on the project ID number, work should be done to update those
similarly.


In the docs configuration we use the ID for the generating the bugs 
link. We also rely on it being a numeric ID (as a string - it crashes 
if you use an int) rather than a string to determine whether the 
target is a launchpad project or a storyboard project.



# Finding stories from a task ID

It is now possible to navigate to a story given just a task ID, if for
whatever reason that's all the information you have available. A 
link like


   https://storyboard.openstack.org/#!/task/12389

will work. This will redirect to the story containing the task, and 
is the
first part of work to support linking directly to an individual task 
in a

story.

[...]

As an aside, I think this makes it possible now for us to start
hyperlinking Task footers in commit messages within the Gerrit
change view. I'll try and figure out what we need to adjust in our
Gerrit commentlink and its-storyboard plugin configs to make that
happen.


+1


__ 


OpenStack Development Mailing 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] [docs][cinder] about cinder volume qos

[Jay S Bryant]

On 9/10/2018 7:17 AM, Rambo wrote:

Hi,all

      At first,I find it is supported that we can define hard 
performance limits for each volume in doc.openstack.org[1].But only 
can define hard performance limits for each volume type in fact. 
Another, the note"As of the Nova 18.0.0 Rocky release, front end QoS 
settings are only supported when using the libvirt driver.",in fact, 
we have supported the front end QoS settings when using the libvirt 
driver previous. Is the document wrong?Can you tell me more about this 
?Thank you very much.


[1]https://docs.openstack.org/cinder/latest/admin/blockstorage-basic-volume-qos.html




Rambo,

The performance limits are limited to a volume type as you need to have 
a volume type to be able to associate a QoS type with it.  So, that 
makes sense.


As for the documentation, it is a little confusing the way that is 
worded but it isn't wrong.  So, QoS support thus far, including Nova 
18.0.0, front end QoS setting only works with the libvirt driver.  I 
don't interpret that as meaning that there wasn't QoS support before that.


Jay







Best Regards
Rambo


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


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

[openstack-dev] [goals][python3][nova] starting zuul migration for nova repos

[Doug Hellmann]

Melanie gave me the go-ahead to propose the patches, so here's the list
of patches for the zuul migration, doc job update, and python 3.6 unit
tests for the nova repositories.

+--++---+
| Subject  | Repo   
| Branch|
+--++---+
| remove job settings for nova repositories| openstack-infra/project-config 
| master|
| import zuul job settings from project-config | openstack/nova 
| master|
| switch documentation job to new PTI  | openstack/nova 
| master|
| add python 3.6 unit test job | openstack/nova 
| master|
| import zuul job settings from project-config | openstack/nova 
| stable/ocata  |
| import zuul job settings from project-config | openstack/nova 
| stable/pike   |
| import zuul job settings from project-config | openstack/nova 
| stable/queens |
| import zuul job settings from project-config | openstack/nova 
| stable/rocky  |
| import zuul job settings from project-config | openstack/nova-specs   
| master|
| import zuul job settings from project-config | openstack/os-traits
| master|
| switch documentation job to new PTI  | openstack/os-traits
| master|
| add python 3.6 unit test job | openstack/os-traits
| master|
| import zuul job settings from project-config | openstack/os-traits
| stable/pike   |
| import zuul job settings from project-config | openstack/os-traits
| stable/queens |
| import zuul job settings from project-config | openstack/os-traits
| stable/rocky  |
| import zuul job settings from project-config | openstack/os-vif   
| master|
| switch documentation job to new PTI  | openstack/os-vif   
| master|
| add python 3.6 unit test job | openstack/os-vif   
| master|
| import zuul job settings from project-config | openstack/os-vif   
| stable/ocata  |
| import zuul job settings from project-config | openstack/os-vif   
| stable/pike   |
| import zuul job settings from project-config | openstack/os-vif   
| stable/queens |
| import zuul job settings from project-config | openstack/os-vif   
| stable/rocky  |
| import zuul job settings from project-config | openstack/osc-placement
| master|
| switch documentation job to new PTI  | openstack/osc-placement
| master|
| add python 3.6 unit test job | openstack/osc-placement
| master|
| import zuul job settings from project-config | openstack/osc-placement
| stable/queens |
| import zuul job settings from project-config | openstack/osc-placement
| stable/rocky  |
| import zuul job settings from project-config | openstack/python-novaclient
| master|
| switch documentation job to new PTI  | openstack/python-novaclient
| master|
| add python 3.6 unit test job | openstack/python-novaclient
| master|
| add lib-forward-testing-python3 test job | openstack/python-novaclient
| master|
| import zuul job settings from project-config | openstack/python-novaclient
| stable/ocata  |
| import zuul job settings from project-config | openstack/python-novaclient
| stable/pike   |
| import zuul job settings from project-config | openstack/python-novaclient
| stable/queens |
| import zuul job settings from project-config | openstack/python-novaclient
| stable/rocky  |
+--++---+

__
OpenStack Development Mailing 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][cinder] about unified limits

[Ben Nemec]

We had an extensive discussion of this in the keystone room today: 
https://etherpad.openstack.org/p/keystone-stein-unified-limits


We had a couple of Nova people in the room, so if anyone from other 
teams can take a look at the outcomes on the etherpad and let us know if 
there are any issues with the current plan for other projects that would 
be good.


On 09/10/2018 09:25 AM, Ben Nemec wrote:
We had talked about Tuesday afternoon. I need to sync up with Lance and 
figure out exactly when will work best.


On 09/08/2018 10:58 AM, Jay S Bryant wrote:

Ben,

Ping me when you are planning on having this discussion if you think 
of it.  Since there is interest in this for Cinder I would like to try 
to be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if 
so that would be a good opportunity for some face-to-face discussion. 
I didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat 
enforcement [0]. During the Rocky PTG we sat down with other 
services and a few operators to explain the current status in 
keystone and if either developers or operators had feedback on the 
API specifically. Notes were captured in etherpad [1]. We spent the 
Rocky cycle fixing usability issues with the API [2] and 
implementing support for a hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as 
stable and it will likely stay that way until we have at least one 
project using unified limits. We can use that as an opportunity to 
do a final flush of any changes that need to be made to the API 
before fully supporting it. The keystone team expects that to be a 
quick transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is 
over it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the 
request claim is valid or not. There are patches up for this work, 
and reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services 
can officially pull it into their code as a dependency and we can 
work out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit 
API being experimental as we shake out usability issues in both 
pieces of software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between 
keystone, oslo, and service developers. I do have a patch up that 
adds a conceptual overview for developers consuming oslo.limit [5], 
which renders into [6].


To be honest, this is going to be a very large 

Re: [openstack-dev] [charms][ptg] Stein PTG team dinner

[Frode Nordahl]

Sounds great James.  Excellent choice of restaurant, I'm in! (My +1 will
probably be pre-occupied with other things that evening, so only count me
for the reservation)

On Mon, Sep 10, 2018 at 11:13 AM James Page 
wrote:

> Hi All
>
> As outgoing PTL I have the honour of organising the team dinner for the
> Stein PTG this week.
>
> I'm proposing Wednesday night at Russell's Smokehouse:
>
>   https://www.russellssmokehouse.com/
>
> Let me know if you will be along (and if you have a +1) by end of today
> and I'll make the reservation!
>
> Cheers
>
> James
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Frode Nordahl
Software Engineer
Canonical Ltd.
__
OpenStack Development Mailing 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] [charms][ptg] Stein PTG team dinner

[James Page]

Hi All

As outgoing PTL I have the honour of organising the team dinner for the
Stein PTG this week.

I'm proposing Wednesday night at Russell's Smokehouse:

  https://www.russellssmokehouse.com/

Let me know if you will be along (and if you have a +1) by end of today and
I'll make the reservation!

Cheers

James
__
OpenStack Development Mailing 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] [senlin] Nominations to Senlin Core Team

[Duc Truong]

Hi Senlin Core Team,

I would like to nominate 2 new core reviewers for Senlin:

[1] Jude Cross (jucr...@blizzard.com)
[2] Erik Olof Gunnar Andersson (eanders...@blizzard.com)

Jude has been doing a number of reviews and contributed some important
patches to Senlin during the Rocky cycle that resolved locking
problems.

Erik has the most number of reviews in Rocky and has contributed high
quality code reviews for some time.

[1] 
http://stackalytics.com/?module=senlin-group=marks=rocky_id=jucr...@blizzard.com
[2] 
http://stackalytics.com/?module=senlin-group=marks_id=eandersson=rocky

Voting is open for 7 days.  Please reply with your +1 vote in favor or
-1 as a veto vote.

Regards,

Duc (dtruong)

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

Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do

[Alex Schultz]

I just realized I booked the room and put it in the etherpad but
forgot to email out the time.

Time: Tuesday 09:00-10:45
Room: Big Thompson

https://etherpad.openstack.org/p/ansible-collaboration-denver-ptg

Thanks,
-Alex

On Tue, Sep 4, 2018 at 1:03 PM, Alex Schultz  wrote:
> On Thu, Aug 9, 2018 at 2:43 PM, Mohammed Naser  wrote:
>> Hi Alex,
>>
>> I am very much in favour of what you're bringing up.  We do have
>> multiple projects that leverage Ansible in different ways and we all
>> end up doing the same thing at the end.  The duplication of work is
>> not really beneficial for us as it takes away from our use-cases.
>>
>> I believe that there is a certain number of steps that we all share
>> regardless of how we deploy, some of the things that come up to me
>> right away are:
>>
>> - Configuring infrastructure services (i.e.: create vhosts for service
>> in rabbitmq, create databases for services, configure users for
>> rabbitmq, db, etc)
>> - Configuring inter-OpenStack services (i.e. keystone_authtoken
>> section, creating endpoints, etc and users for services)
>> - Configuring actual OpenStack services (i.e.
>> /etc//.conf file with the ability of extending
>> options)
>> - Running CI/integration on a cloud (i.e. common role that literally
>> gets an admin user, password and auth endpoint and creates all
>> resources and does CI)
>>
>> This would deduplicate a lot of work, and especially the last one, it
>> might be beneficial for more than Ansible-based projects, I can
>> imagine Puppet OpenStack leveraging this as well inside Zuul CI
>> (optionally)... However, I think that this something which we should
>> discus further for the PTG.  I think that there will be a tiny bit
>> upfront work as we all standarize but then it's a win for all involved
>> communities.
>>
>> I would like to propose that deployment tools maybe sit down together
>> at the PTG, all share how we use Ansible to accomplish these tasks and
>> then perhaps we can work all together on abstracting some of these
>> concepts together for us to all leverage.
>>
>
> I'm currently trying to get a spot on Tuesday morning to further
> discuss some of this items.  In the mean time I've started an
> etherpad[0] to start collecting ideas for things to discuss.  At the
> moment I've got the tempest role collaboration and some basic ideas
> for best practice items that we can discuss.  Feel free to add your
> own and I'll update the etherpad with a time slot when I get one
> nailed down.
>
> Thanks,
> -Alex
>
> [0] https://etherpad.openstack.org/p/ansible-collaboration-denver-ptg
>
>> I'll let others chime in as well.
>>
>> Regards,
>> Mohammed
>>
>> On Thu, Aug 9, 2018 at 4:31 PM, Alex Schultz  wrote:
>>> Ahoy folks,
>>>
>>> I think it's time we come up with some basic rules/patterns on where
>>> code lands when it comes to OpenStack related Ansible roles and as we
>>> convert/export things. There was a recent proposal to create an
>>> ansible-role-tempest[0] that would take what we use in
>>> tripleo-quickstart-extras[1] and separate it for re-usability by
>>> others.   So it was asked if we could work with the openstack-ansible
>>> team and leverage the existing openstack-ansible-os_tempest[2].  It
>>> turns out we have a few more already existing roles laying around as
>>> well[3][4].
>>>
>>> What I would like to propose is that we as a community come together
>>> to agree on specific patterns so that we can leverage the same roles
>>> for some of the core configuration/deployment functionality while
>>> still allowing for specific project specific customization.  What I've
>>> noticed between all the project is that we have a few specific core
>>> pieces of functionality that needs to be handled (or skipped as it may
>>> be) for each service being deployed.
>>>
>>> 1) software installation
>>> 2) configuration management
>>> 3) service management
>>> 4) misc service actions
>>>
>>> Depending on which flavor of the deployment you're using, the content
>>> of each of these may be different.  Just about the only thing that is
>>> shared between them all would be the configuration management part.
>>> To that, I was wondering if there would be a benefit to establishing a
>>> pattern within say openstack-ansible where we can disable items #1 and
>>> #3 but reuse #2 in projects like kolla/tripleo where we need to do
>>> some configuration generation.  If we can't establish a similar
>>> pattern it'll make it harder to reuse and contribute between the
>>> various projects.
>>>
>>> In tripleo we've recently created a bunch of ansible-role-tripleo-*
>>> repositories which we were planning on moving the tripleo specific
>>> tasks (for upgrades, etc) to and were hoping that we might be able to
>>> reuse the upstream ansible roles similar to how we've previously
>>> leverage the puppet openstack work for configurations.  So for us, it
>>> would be beneficial if we could maybe help align/contribute/guide the
>>> configuration management and maybe 

[openstack-dev] [senlin][stable] Nominating chenyb4 to Senlin Stable Maintainers Team

[Duc Truong]

Hi Senlin Stable Team,

I would like to nominate Yuanbin Chen (chenyb4) to the Senlin stable
review team. Yuanbin has been doing stable reviews and shown that he
understands the policy for merging stable patches [1].

Voting is open for 7 days. Please reply with your +1 vote in favor or
-1 as a veto vote.

[1] 
https://review.openstack.org/#/q/branch:%255Estable/.*+reviewedby:cybing4%2540gmail.com

Regards,

Duc (dtruong)

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

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

[Adam Coldrick]

On Mon, 2018-09-10 at 12:14 -0400, Zane Bitter wrote:
> On 10/09/18 10:34 AM, Jeremy Stanley wrote:
> > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
> > [...]
> > > # Linking to projects by name
> > > 
> > > Keen observers might've noticed that StoryBoard recently grew the
> > > ability
> > > to link to projects by name, rather than by ID number. All the links
> > > to
> > > projects in the UI have been replaced with links in this form, and
> > > its
> > > probably a good idea for folk to start using them in any
> > > documentation
> > > they have. These links look like
> > > 
> > >    https://storyboard.openstack.org/#!/project/openstack-infra/story
> > > board
> 
> Thanks for this!!!
> 
> > [...]
> > 
> > Worth noting, this has made it harder to find the numeric project ID
> > without falling back on the API. Change
> > https://review.openstack.org/600893 merged to the releases
> > repository yesterday allowing deliverable repositories to be
> > referenced by their StoryBoard project name rather than only the ID
> > number. If there are other places in tooling and automation where we
> > relied on the project ID number, work should be done to update those
> > similarly.
> 
> In the docs configuration we use the ID for the generating the bugs 
> link. We also rely on it being a numeric ID (as a string - it crashes
> if 
> you use an int) rather than a string to determine whether the target is 
> a launchpad project or a storyboard project.

If it'll be a big task to change this, I'm happy to make the ID more
discoverable from the StoryBoard web UI so that it isn't painful for folk
in the meantime.

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

Re: [openstack-dev] [QA] [all] QA Stein PTG Planning

[Ghanshyam Mann]

There are more Topic to discuss for QA at last movement [1]. I have added them 
in schedule and there are few topic has been re-scheduled due to that, please 
check the latest schedule for QA topic here[2]

I have created the dedicated Etherpad for each topic, links are in main 
Etherpad[1]. Request all the Topic owner to fill the details on respective 
Etherpads well before the Topic Schedule.  

[1] https://etherpad.openstack.org/p/qa-stein-ptg 
[2] https://ethercalc.openstack.org/Stein-PTG-QA-Schedule 


-gmann

  On Wed, 05 Sep 2018 17:34:27 +0900 Ghanshyam Mann 
 wrote  
 > Hi All,
 > 
 > As we are close to PTG, I have prepared the QA Stein PTG Schedule -
 > https://ethercalc.openstack.org/Stein-PTG-QA-Schedule 
 > 
 > Detail of each sessions can be found in this etherpad -
 > https://etherpad.openstack.org/p/qa-stein-ptg 
 > 
 > This time we will have QA Help Hour for 1 day only which is on Monday and 
 > next 3 days for specific topic discussion and code sprint. 
 > We still have space for more sessions or topic if any of you would like to 
 > add. If so please write those to etherpad with your irc name.
 > Sessions Scheduled is flexible and we can reschedule based on request but do 
 > let me know before 7th Sept.
 > 
 > If anyone cannot travel to PTG and would like to attend remotely, do let me 
 > know i can plan something for remote participation. 
 > 
 > -gmann
 > 
 > 
 > 
 > 
 > 
 > __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 > 



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

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

[Zane Bitter]

On 10/09/18 10:34 AM, Jeremy Stanley wrote:

On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
[...]

# Linking to projects by name

Keen observers might've noticed that StoryBoard recently grew the ability
to link to projects by name, rather than by ID number. All the links to
projects in the UI have been replaced with links in this form, and its
probably a good idea for folk to start using them in any documentation
they have. These links look like

   https://storyboard.openstack.org/#!/project/openstack-infra/storyboard


Thanks for this!!!


[...]

Worth noting, this has made it harder to find the numeric project ID
without falling back on the API. Change
https://review.openstack.org/600893 merged to the releases
repository yesterday allowing deliverable repositories to be
referenced by their StoryBoard project name rather than only the ID
number. If there are other places in tooling and automation where we
relied on the project ID number, work should be done to update those
similarly.


In the docs configuration we use the ID for the generating the bugs 
link. We also rely on it being a numeric ID (as a string - it crashes if 
you use an int) rather than a string to determine whether the target is 
a launchpad project or a storyboard project.



# Finding stories from a task ID

It is now possible to navigate to a story given just a task ID, if for
whatever reason that's all the information you have available. A link like

   https://storyboard.openstack.org/#!/task/12389

will work. This will redirect to the story containing the task, and is the
first part of work to support linking directly to an individual task in a
story.

[...]

As an aside, I think this makes it possible now for us to start
hyperlinking Task footers in commit messages within the Gerrit
change view. I'll try and figure out what we need to adjust in our
Gerrit commentlink and its-storyboard plugin configs to make that
happen.


+1


__
OpenStack Development Mailing 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 management refactoring for Life cycle

[Jiri Tomasek]

Hi Mathieu,

Thanks for bringing up the topic. There are several efforts currently in
progress which should lead to solving the problems you're describing. We
are working on introducing CLI commands which would perform the deployment
configuration operations on deployment plan in Swift. This is a main step
to finally reach CLI and GUI compatibility/interoperability. CLI will
perform actions to configure deployment (roles, networks, environments
selection, parameters setting etc.) by calling Mistral workflows which
store the information in deployment plan in Swift. The result is that all
the information which define the deployment are stored in central place -
deployment plan in Swift and the deploy command is turned into simple
'openstack overcloud  deploy'. Deployment plan then has
plan-environment.yaml which has the list of environments used and
customized parameter values, roles-data.yaml which carry roles definition
and network-data.yaml which carry networks definition. The information
stored in these files (and deployment plan in general) can then be treated
as source of information about deployment. The deployment can then be
easily exported and reliably replicated.

Here is the document which we put together to identify missing pieces
between GUI,CLI and Mistral TripleO API. We'll use this to discuss the
topic at PTG this week and define work needed to be done to achieve the
complete interoperability. [1]

Also there is a pending patch from Steven Hardy which aims to remove CLI
specific environments merging which should fix the problem with tracking of
the environments used with CLI deployment. [2]

[1] https://gist.github.com/jtomasek/8c2ae6118be0823784cdafebd9c0edac
(Apologies for inconvenient format, I'll try to update this to
better/editable format. Original doc:
https://docs.google.com/spreadsheets/d/1ERfx2rnPq6VjkJ62JlA_E6jFuHt9vVl3j95dg6-mZBM/edit?usp=sharing
)
[2] https://review.openstack.org/#/c/448209/

-- Jirka

On Mon, Sep 10, 2018 at 8:05 AM mathieu bultel  wrote:

> Hi folks,
>
> Last week I wrote a BluePrint and a spec [1] to propose to change the way
> we used and managed the Plan in TripleO for the Deployment and the Life
> cycle (update/upgrade and scale).
>
> While I was working on trying to simplified the implementation of the
> Update and Upgrade for a end user usage, I found very hard to follow all
> the calls that the TripleO Client was doing to the HeatClient and
> SwiftClient.
>
> I traced the calls and found that we can safely and easily decrease the
> number of calls and simplified the way that we are computing & rendering
> the TripleO Heat Templates files.
>
> I did a PoC to see what would be the problematic behind that and what we
> could do without breaking the "standard" usage and all the particular
> things that the current code handle (specific deployments and
> configurations & so on).
>
> By this refactoring I'm seeing another gain for the life cycle part of
> TripleO, where we used to try to make thing simpler & safer but we
> constantly failed due to this complexity and all the "special cases" that
> we faced during the testing.
>
> The result is that, when a user need to perform an update/upgrade of his
> deployment, he really have to be careful, to pay a lot of attention of all
> the options, -e environments files that he previously used  with the risk
> to make a simple mistake, and totally mess up the deployment.
>
> So my goals with this PoC and this BP is to try to addressed those points
> by:
>
> simplify  and reduce the number of calls between the clients,
>
> have a simple way for creating and updating the Plan, even by amending the
> plan with only a particular files / config or Playbooks,
>
> store all the in formations provided by the user by uploading all the
> files outsides of the plan,
>
> keep the track of the environment files passed to the CLI,
>
> trace the life cycle story of the deployment.
>
> So feel free to comment, add your concerns or feedback around this.
>
> Cheer,
>
> Mathieu
>
> [1]
>
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-plan-management
>
> https://review.openstack.org/599396
>
> [2]
>
>  https://review.openstack.org/583145
>
>
> __
> OpenStack Development Mailing 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] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Matt Riedemann]

On 9/9/2018 1:11 PM, Ghanshyam Mann wrote:

Yeah, Tempest would not fit as best location for such tagging or whitelist. I 
think nova may be better choice if nothing else.


OK I've thrown this on the nova ptg etherpad agenda [1] for a misc item 
to talk about.


[1] https://etherpad.openstack.org/p/nova-ptg-stein

--

Thanks,

Matt

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

Re: [openstack-dev] [nova][cinder] about unified limits

[Ben Nemec]

We had talked about Tuesday afternoon. I need to sync up with Lance and 
figure out exactly when will work best.


On 09/08/2018 10:58 AM, Jay S Bryant wrote:

Ben,

Ping me when you are planning on having this discussion if you think of 
it.  Since there is interest in this for Cinder I would like to try to 
be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes 
were captured in etherpad [1]. We spent the Rocky cycle fixing 
usability issues with the API [2] and implementing support for a 
hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick 
transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is over 
it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the request 
claim is valid or not. There are patches up for this work, and 
reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work 
out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit API 
being experimental as we shake out usability issues in both pieces of 
software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we 
can use the first couple iterations to generate some well-written 
usage documentation. Any questions coming from developers in this 
phase should probably be answered in documentation if we want to 
enable folks to pick this up and run with it. Otherwise, I could see 
the handful of people pushing the effort 

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

[Jeremy Stanley]

On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
[...]
> # Linking to projects by name
> 
> Keen observers might've noticed that StoryBoard recently grew the ability
> to link to projects by name, rather than by ID number. All the links to
> projects in the UI have been replaced with links in this form, and its
> probably a good idea for folk to start using them in any documentation
> they have. These links look like
> 
>   https://storyboard.openstack.org/#!/project/openstack-infra/storyboard
[...]

Worth noting, this has made it harder to find the numeric project ID
without falling back on the API. Change
https://review.openstack.org/600893 merged to the releases
repository yesterday allowing deliverable repositories to be
referenced by their StoryBoard project name rather than only the ID
number. If there are other places in tooling and automation where we
relied on the project ID number, work should be done to update those
similarly.

> # Finding stories from a task ID
> 
> It is now possible to navigate to a story given just a task ID, if for
> whatever reason that's all the information you have available. A link like
> 
>   https://storyboard.openstack.org/#!/task/12389
> 
> will work. This will redirect to the story containing the task, and is the
> first part of work to support linking directly to an individual task in a
> story.
[...]

As an aside, I think this makes it possible now for us to start
hyperlinking Task footers in commit messages within the Gerrit
change view. I'll try and figure out what we need to adjust in our
Gerrit commentlink and its-storyboard plugin configs to make that
happen.
-- 
Jeremy Stanley


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

[openstack-dev] [TripleO] Plan management refactoring for Life cycle

[mathieu bultel]

Hi folks,

Last week I wrote a BluePrint and a spec [1] to propose to change the
way we used and managed the Plan in TripleO for the Deployment and the
Life cycle (update/upgrade and scale).

While I was working on trying to simplified the implementation of the
Update and Upgrade for a end user usage, I found very hard to follow all
the calls that the TripleO Client was doing to the HeatClient and
SwiftClient.

I traced the calls and found that we can safely and easily decrease the
number of calls and simplified the way that we are computing & rendering
the TripleO Heat Templates files.

I did a PoC to see what would be the problematic behind that and what we
could do without breaking the "standard" usage and all the particular
things that the current code handle (specific deployments and
configurations & so on).

By this refactoring I'm seeing another gain for the life cycle part of
TripleO, where we used to try to make thing simpler & safer but we
constantly failed due to this complexity and all the "special cases"
that we faced during the testing.

The result is that, when a user need to perform an update/upgrade of his
deployment, he really have to be careful, to pay a lot of attention of
all the options, -e environments files that he previously used  with the
risk to make a simple mistake, and totally mess up the deployment.

So my goals with this PoC and this BP is to try to addressed those
points by:

simplify  and reduce the number of calls between the clients,

have a simple way for creating and updating the Plan, even by
amending the plan with only a particular files / config or Playbooks,

store all the in formations provided by the user by uploading all
the files outsides of the plan,

keep the track of the environment files passed to the CLI,

trace the life cycle story of the deployment.

So feel free to comment, add your concerns or feedback around this.

Cheer,

Mathieu

[1]

https://blueprints.launchpad.net/tripleo/+spec/tripleo-plan-management

https://review.openstack.org/599396 

[2]

 https://review.openstack.org/583145


__
OpenStack Development Mailing 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] [StoryBoard] Project Update/Some New Things

[Adam Coldrick]

Hi all,

Its been a long while since a "project update" type email about
StoryBoard, but over the past few months we merged some patches which
either are worth mentioning or changed things in ways that would benefit
from some explanation.


# Linking to projects by name

Keen observers might've noticed that StoryBoard recently grew the ability
to link to projects by name, rather than by ID number. All the links to
projects in the UI have been replaced with links in this form, and its
probably a good idea for folk to start using them in any documentation
they have. These links look like

  https://storyboard.openstack.org/#!/project/openstack-infra/storyboard


# Linking to project groups by name

More recently (yesterday) it also became possible to similarly link to
project groups by name rather than ID number. Links to project groups in
the UI have been replaced with links in this form, and again if you have
any documentation using the ID links it might be nice to update to using
the name. These links look like

  https://storyboard.openstack.org/#!/project_group/storyboard


# Finding stories from a task ID

It is now possible to navigate to a story given just a task ID, if for
whatever reason that's all the information you have available. A link like

  https://storyboard.openstack.org/#!/task/12389

will work. This will redirect to the story containing the task, and is the
first part of work to support linking directly to an individual task in a
story.


# UI updates

There have been some visual changes in the webclient's user interface to
attempt to make things generally feel nicer. This work is also not totally
finished and there are further changes planned.

One big change is that the "Profile" button in the sidebar used for
setting preferences and managing access tokens has gone away. The URLs
used to access this functionality are unchanged, but the links in the UI
can now be found by clicking the user name in the top-right to open the
dropdown menu, which previously only contained the log out button.


# Bugfixes

Various minor bugs and annoyances have also been addressed. For example
search should behave somewhat more predictably than it did at the start of
the year, syntax highlighting actually works again, and the markdown
parser should be less aggressive in its swallowing of line breaks.


Stay tuned in the future for more fixes and features, and feel free to pop
into #storyboard with any questions or comments you may have. We're always
open to suggestions and even more open to patches!

We also have a PTG session on Tuesday afternoon, currently intended to be
in Blanca Peak. Feel free to drop by to join the discussions and/or add to
the etherpad[0].

Best regards,

Adam (SotK)

[0]: https://etherpad.openstack.org/p/sb-stein-ptg-planning

__
OpenStack Development Mailing 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] quickstart for humans

[Bogdan Dobrelya]

On 8/31/18 6:03 PM, Raoul Scarazzini wrote:

On 8/31/18 12:07 PM, Jiří Stránský wrote:
[...]

* "for humans" definition differs significantly based on who you ask.
E.g. my intention with [2] was to readily expose *more* knobs and tweaks
and be more transparent with the underlying workings of Ansible, because
i felt like quickstart.sh hides too much from me. In my opinion [2] is
sufficiently "for humans", yet it does pretty much the opposite of what
you're looking for.


Hey Jiri,
I think that "for humans" means simply that you launch the command with
just one parameter (i.e. the virthost), and then you have something.


yes, this ^^
I'd also add one more thing: if you later remove that something while 
having the virthost as your localhost, and the non root user as your 
current logged-in user, you remain operational :) Teardown is quite 
destructive for CI, which might be not applicable for devboxes running 
on a laptop. I have a few changes [0] in work for addressing that case.


[0] 
https://review.openstack.org/#/q/topic:localcon+(status:open+OR+status:merged)



And because of this I think here is just a matter of concentrate the
efforts to turn back quickstart.sh to its original scope: making you
launch it with just one parameter and have an available environment
after a while (OK, sometimes more than a while).
Since part of the recent discussions were around the hypotheses of
removing it, maybe we can think about make it useful again. Mostly
because it is right that the needs of everyone are different, but on the
other side with a solid starting point (the default) you can think about
customizing depending on your needs.
I'm for recycling what we have, planet (and me) will enjoy it!

My 0,002 cents.




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [election][tc] Opinion about 'PTL' tooling

[Jeremy Stanley]

On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote:
> I think something we should take into consideration is *what* you
> consider health because the way we’ve gone about it over health
> checks is not something that can become a toolkit because it was
> more of question asking, etc
[...]

I was going to follow up with something similar. It's not as if the
TC has a toolkit of any sort at this point to come up with the
information we're assembling in the health tracker either. It's
built up from interviewing PTLs, reading meeting logs, looking at
the changes which merge to teams' various deliverable repositories,
asking around as to whether they've missed important deadlines such
as release milestones (depending on what release models they
follow) or PTL nominations, looking over cycle goals to see how far
along they are, and so on. Extremely time-consuming which is why
it's taken us most of a release cycle and we still haven't finished
a first pass.

Assembling some of this information might be automatable if we make
adjustments to how the data/processes on which it's based are
maintained, but at this point we're not even sure which ones are
problem indicators at all and are just trying to provide the
clearest picture we can. If we come up with a detailed checklist and
some of the checks on that list can be automated in some way, that
seems like a good thing. However, the original data should be
publicly accessible so I don't see why it needs to be members of the
technical committee who write the software to collect that.
-- 
Jeremy Stanley


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] [election][tc] Opinion about 'PTL' tooling

[Mohammed Naser]

I think something we should take into consideration is *what* you consider 
health because the way we’ve gone about it over health checks is not something 
that can become a toolkit because it was more of question asking, etc

Sent from my iPhone

> On Sep 10, 2018, at 6:29 AM, Rico Lin  wrote:
> 
> 
> 
>> On Mon, Sep 10, 2018 at 5:31 AM Doug Hellmann  wrote:
>> Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02 +0200:
>> > Hello everyone,
>> > 
>> > In my candidacy [1], I mentioned that the TC should provide more tools to 
>> > help the PTLs at their duties, for example to track community health.
>> > 
>> > I have questions for the TC candidates:
>> > - What is your opinion about said toolkit? Do you see a purpose for it?
>> > - Do you think said toolkit should fall under the TC umbrella?
>> > 
>> > After my discussion with Rico Lin (PTL of the Heat project, and TC 
>> > candidate) yesterday, I am personally convinced that it would be a good 
>> > idea, and that we should have those tools: As a PTL (but also any person 
>> > interested to see health of projects) I wanted it and I am not alone. PTLs 
>> > are focusing on their duties and, as a day is only composed of so few 
>> > hours, it is possible they won't have the focus to work on said tools to 
>> > track, in the longer term, the community.
>> > 
>> > For me, tracking community health (and therefore a toolkit for the 
>> > PTLs/community) is something TC should cover for good governance, and I am 
>> > not aware of any tooling extracting metrics that can be easily visible and 
>> > used by anyone. If each project started to have their own implementation 
>> > of tools, it would be opposite to one of my other goals, which is the 
>> > simplification of OpenStack.
>> > 
>> > Thanks for reading me, and do not hesitate to ask me questions on the 
>> > mailing lists, or in real life during the PTG!
>> > 
>> > Regards,
>> > Jean-Philippe Evrard (evrardjp)
>> > 
>> > [1]: 
>> > https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
>> > 
>> 
>> We've had several different sets of scripts at different times to
>> extract review statistics from gerrit. Is that the sort of thing you
>> mean?
>> 
>> What information would you find useful?
> 
> First of all, I know I'm awake because jet lag, but it's surprise to see you 
> all are too! Are you guys really in Denver!? or just some cardboard cut-out I 
> saw!
> 
> Okay, let's back to the mail.
> As a PTL (not like a good one, but try to do what I can and learn from 
> others), I do see the benifit to have tool kit
> to properly alarm (or show to) PTL about how people been in projects. As 
> checking the health of projects been a big task for TCs for last cycle, I 
> believe this might be something we can further discussion in that TCs task.
> 
> Right now we're asking TCs to asisit team to get a health report. But if we 
> can provide a list of tools that mgith help PTLs (or cores) to generate some 
> information to see the health situation. so PTLs can see how's things going 
> after they adjust their strategies. For toolkits, I believe there're already 
> something we can collect for PTLs? So we can use what already there and make 
> sure we don't over taken everyone's time for this task.
> I aware there are challenges when we talk about how to make nwe-join people 
> feel good and how can we help PTLs (with experiences or not) to adjust their 
> way or to get better communications cross projects so PTLs will get a chances 
> to share and learn from others if they see any improvement also applied to 
> their team as well.
> 
> 
> Also I agree with Doug that it's improtant to bring this idea on table and 
> discuss about what exactly information we want to get from data. And what 
> information TCs feel helpful to track health condition.
> 
> 
> Now this bring me some idea of suggestion for all that I think it's time to 
> renew some documentation in 
> https://docs.openstack.org/project-team-guide/ptl.html 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] Opinion about 'PTL' tooling

[Rico Lin]

On Mon, Sep 10, 2018 at 5:31 AM Doug Hellmann  wrote:

> Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02
> +0200:
> > Hello everyone,
> >
> > In my candidacy [1], I mentioned that the TC should provide more tools
> to help the PTLs at their duties, for example to track community health.
> >
> > I have questions for the TC candidates:
> > - What is your opinion about said toolkit? Do you see a purpose for it?
> > - Do you think said toolkit should fall under the TC umbrella?
> >
> > After my discussion with Rico Lin (PTL of the Heat project, and TC
> candidate) yesterday, I am personally convinced that it would be a good
> idea, and that we should have those tools: As a PTL (but also any person
> interested to see health of projects) I wanted it and I am not alone. PTLs
> are focusing on their duties and, as a day is only composed of so few
> hours, it is possible they won't have the focus to work on said tools to
> track, in the longer term, the community.
> >
> > For me, tracking community health (and therefore a toolkit for the
> PTLs/community) is something TC should cover for good governance, and I am
> not aware of any tooling extracting metrics that can be easily visible and
> used by anyone. If each project started to have their own implementation of
> tools, it would be opposite to one of my other goals, which is the
> simplification of OpenStack.
> >
> > Thanks for reading me, and do not hesitate to ask me questions on the
> mailing lists, or in real life during the PTG!
> >
> > Regards,
> > Jean-Philippe Evrard (evrardjp)
> >
> > [1]:
> https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
> >
>
> We've had several different sets of scripts at different times to
> extract review statistics from gerrit. Is that the sort of thing you
> mean?
>
> What information would you find useful?
>

First of all, I know I'm awake because jet lag, but it's surprise to see
you all are too! Are you guys really in Denver!? or just some cardboard
cut-out I saw!

Okay, let's back to the mail.
As a PTL (not like a good one, but try to do what I can and learn from
others), I do see the benifit to have tool kit
to properly alarm (or show to) PTL about how people been in projects. As
checking the health of projects been a big task for TCs for last cycle, I
believe this might be something we can further discussion in that TCs task.

Right now we're asking TCs to asisit team to get a health report. But if we
can provide a list of tools that mgith help PTLs (or cores) to generate
some information to see the health situation. so PTLs can see how's things
going after they adjust their strategies. For toolkits, I believe there're
already something we can collect for PTLs? So we can use what already there
and make sure we don't over taken everyone's time for this task.
I aware there are challenges when we talk about how to make nwe-join people
feel good and how can we help PTLs (with experiences or not) to adjust
their way or to get better communications cross projects so PTLs will get a
chances to share and learn from others if they see any improvement also
applied to their team as well.


Also I agree with Doug that it's improtant to bring this idea on table and
discuss about what exactly information we want to get from data. And what
information TCs feel helpful to track health condition.


Now this bring me some idea of suggestion for all that I think it's time to
renew some documentation in
https://docs.openstack.org/project-team-guide/ptl.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] Opinion about 'PTL' tooling

[Ghanshyam Mann]

  On Mon, 10 Sep 2018 20:31:11 +0900 Doug Hellmann  
wrote  
 > Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02 +0200:
 > > Hello everyone,
 > > 
 > > In my candidacy [1], I mentioned that the TC should provide more tools to 
 > > help the PTLs at their duties, for example to track community health.
 > > 
 > > I have questions for the TC candidates:
 > > - What is your opinion about said toolkit? Do you see a purpose for it?
 > > - Do you think said toolkit should fall under the TC umbrella?
 > > 
 > > After my discussion with Rico Lin (PTL of the Heat project, and TC 
 > > candidate) yesterday, I am personally convinced that it would be a good 
 > > idea, and that we should have those tools: As a PTL (but also any person 
 > > interested to see health of projects) I wanted it and I am not alone. PTLs 
 > > are focusing on their duties and, as a day is only composed of so few 
 > > hours, it is possible they won't have the focus to work on said tools to 
 > > track, in the longer term, the community.
 > > 
 > > For me, tracking community health (and therefore a toolkit for the 
 > > PTLs/community) is something TC should cover for good governance, and I am 
 > > not aware of any tooling extracting metrics that can be easily visible and 
 > > used by anyone. If each project started to have their own implementation 
 > > of tools, it would be opposite to one of my other goals, which is the 
 > > simplification of OpenStack.
 > > 
 > > Thanks for reading me, and do not hesitate to ask me questions on the 
 > > mailing lists, or in real life during the PTG!
 > > 
 > > Regards,
 > > Jean-Philippe Evrard (evrardjp)
 > > 
 > > [1]: 
 > > https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
 > > 
 > 
 > We've had several different sets of scripts at different times to
 > extract review statistics from gerrit. Is that the sort of thing you
 > mean?
 > 
 > What information would you find useful?

Yeah, if we can have exact requirement or Action items PTL miss then, it will 
be more clear about having such tooling. Overall I like the idea of giving more 
awareness about PTL work but that is more kind of teaching and guiding the PTL. 
Before we think of tool to manage  PTL responsibility, we need to list down the 
issues it will solve. 

Personally as PTL, I have gone through PTL responsibility guide[1] and filtered 
the PTL tagged email which i daily check on priority. Further I follow the TODO 
things PTL has to do in release, PTG, Summit etc. which work perfectly for me. 
I find this more PTL responsibility than TC track those for PTL. 

That's my point of view as PTL and as TC candidate but i would like to hear 
from other PTLs  on this if they need help on their responsibility tracking  
and why. 


[1] https://docs.openstack.org/project-team-guide/ptl.html

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



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

[openstack-dev] [docs][cinder] about cinder volume qos

[Rambo]

Hi,all


  At first,I find it is supported that we can define hard performance 
limits for each volume in doc.openstack.org[1].But only can define hard 
performance limits for each volume type in fact. Another, the note"As of the 
Nova 18.0.0 Rocky release, front end QoS settings are only supported when using 
the libvirt driver.",in fact, we have supported the front end QoS settings when 
using the libvirt driver previous. Is the document wrong?Can you tell me more 
about this ?Thank you very much.


[1]https://docs.openstack.org/cinder/latest/admin/blockstorage-basic-volume-qos.html
















Best Regards
Rambo__
OpenStack Development Mailing 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] [keystone][adjutant] Sync with adjutant team

[Adrian Turjak]

As I'm not attending the PTG, I thought I might help put some words
against these questions for when you're having the meeting. Plus even if
I did want to be online, it would be something like 4am my time.

Stein will likely see a lot of Adjutant refactor work as I get myself
back onto the project full swing, and onboard a new dev who will be
helping me. As that work happens I'll be in a better place to reevaluate
exactly where Adjutant sits around Keystone, so I'll be updating you all
as much as I can, but for now have some answers that may help.



## They are building on top of keystone, is there anything we can do to
make those interactions easier?

Most of the admin level APIs we interact with do the work well enough
and the 'primitives' in Keystone work as a base layer for us to build
account management logic on top of. I think there was something with
querying roles up and down a tree that was awkward, but I think I found
ways of doing that which didn't amount to silly numbers of API calls.

I think the only real thing I can think of which was awkward is that
Keystone doesn't have a concept for quota in regards to how many
projects a subtree can have (and how deep that tree can be). In my WIP
HMT management code I'm faking it by sticking a key=value in the root
project extras blob and doing the checking in my code, and I guess I can
potentially switch to using the limits API once that's considered
stable, although I don't know how far Keystone itself wants to go down
the route of actually implementing quota checking on its own resources.
My WIP code has quota checking implemented in Adjutant and because of
how it works it likely will stay there as right now that code does quota
as: "allowed to create x number of projects across the whole tree within
a period of y days, to a depth of z" where x, y, and z have default
values in Adjutant or key=values present in the root project extras blob
if a project tree needs custom quotas. As for checking quotas, that's
done against total project creations across a whole tree based on the
number of previous subproject creation tasks in Adjutant in the same tree.


## Is there anything we should incorporate into keystone? maybe after
all the scope work lands in Stein?

There are indeed places where with some work the Keystone APIs (with
proper policy and roles) could provide a replacement for some of the
work in Adjutant, and some cases where it just doesn't make sense
because the parts of that workflow aren't things Keystone is meant to do
(anything with emails or that may need to talk to external systems). The
annoying part here though is that while there are definitely things
Adjutant can do, or will do that make sense to have in Keystone, other
parts of that which a deployer may want to link with external systems or
add more workflow logic on top of don't make sense in Keystone. I'm torn
because there are a lot of small features I could propose we add to
Keystone, but then I doubt I'd be able to use them because I'd need to
still keep elements of them pluggable in Adjutant itself, or would still
write logic around, at which stage working with the primitives is
somewhat easier.

What I might do is make a list and see what 'could' work in Keystone,
and if I could find a way to still use it in Adjutant. If I can still
use it, great, if not, we can evaluated it anyway and consider it as a
minor quality of life improvement to Keystone without an Adjutant. That
way Keystone potentially gains features that makes sense for it, but if
Adjutant is around they can be disabled (or blocked with policy) and
Adjutant's more flexible/complex variants can be configured by the
deployer. The worry though is that you end up with two cloud variants
with slightly similar features, but that's always going to be the case
(Keystone + Adjutant vs just Keystone), the question is if adding
similar overlapping features may prove too confusing.


## Is there anything we need to be aware of with the scope work in Stein
that needs to be communicated to them?

Not that I'm entirely aware of? Maybe some of the internals of Adjutant
will need to change as to how Adjutant's admin user interacts with
Keystone (as it likely will use system scope to have access to
everything), but all the assignments that Adjutant manages for users are
in project scope. Need to really play with and figure this out, not sure
how much is really changing that will cause us pain.

__
OpenStack Development Mailing 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] [election][tc] Opinion about 'PTL' tooling

[Doug Hellmann]

Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02 +0200:
> Hello everyone,
> 
> In my candidacy [1], I mentioned that the TC should provide more tools to 
> help the PTLs at their duties, for example to track community health.
> 
> I have questions for the TC candidates:
> - What is your opinion about said toolkit? Do you see a purpose for it?
> - Do you think said toolkit should fall under the TC umbrella?
> 
> After my discussion with Rico Lin (PTL of the Heat project, and TC candidate) 
> yesterday, I am personally convinced that it would be a good idea, and that 
> we should have those tools: As a PTL (but also any person interested to see 
> health of projects) I wanted it and I am not alone. PTLs are focusing on 
> their duties and, as a day is only composed of so few hours, it is possible 
> they won't have the focus to work on said tools to track, in the longer term, 
> the community.
> 
> For me, tracking community health (and therefore a toolkit for the 
> PTLs/community) is something TC should cover for good governance, and I am 
> not aware of any tooling extracting metrics that can be easily visible and 
> used by anyone. If each project started to have their own implementation of 
> tools, it would be opposite to one of my other goals, which is the 
> simplification of OpenStack.
> 
> Thanks for reading me, and do not hesitate to ask me questions on the mailing 
> lists, or in real life during the PTG!
> 
> Regards,
> Jean-Philippe Evrard (evrardjp)
> 
> [1]: 
> https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
> 

We've had several different sets of scripts at different times to
extract review statistics from gerrit. Is that the sort of thing you
mean?

What information would you find useful?

Doug

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

[openstack-dev] [election][tc] Opinion about 'PTL' tooling

[jean-philippe]

Hello everyone,

In my candidacy [1], I mentioned that the TC should provide more tools to help 
the PTLs at their duties, for example to track community health.

I have questions for the TC candidates:
- What is your opinion about said toolkit? Do you see a purpose for it?
- Do you think said toolkit should fall under the TC umbrella?

After my discussion with Rico Lin (PTL of the Heat project, and TC candidate) 
yesterday, I am personally convinced that it would be a good idea, and that we 
should have those tools: As a PTL (but also any person interested to see health 
of projects) I wanted it and I am not alone. PTLs are focusing on their duties 
and, as a day is only composed of so few hours, it is possible they won't have 
the focus to work on said tools to track, in the longer term, the community.

For me, tracking community health (and therefore a toolkit for the 
PTLs/community) is something TC should cover for good governance, and I am not 
aware of any tooling extracting metrics that can be easily visible and used by 
anyone. If each project started to have their own implementation of tools, it 
would be opposite to one of my other goals, which is the simplification of 
OpenStack.

Thanks for reading me, and do not hesitate to ask me questions on the mailing 
lists, or in real life during the PTG!

Regards,
Jean-Philippe Evrard (evrardjp)

[1]: 
https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me


__
OpenStack Development Mailing 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] [QA][PTG] QA Dinner Night

[Ghanshyam Mann]

Hi All,

I'd like to propose a QA Dinner night for the QA team at the Dublin PTG. I 
initiated a doodle vote [1] to choose Tuesday or Wednesday night.  

NOTE: Anyone engaged in QA activities (not necessary to be QA core)  are 
welcome to join. 


[1] https://doodle.com/poll/68fudz937v22ghnv

-gmann





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

Re: [openstack-dev] [monasca]

[Bedyk, Witold]

Hi Amal,


The status buttons in the monitoring tab correspond to the alarm states for a 
given service or node. After installing devstack plugin no alarms are defined 
yet. You have to do it manually and alarms should appear.


Take care

Witek



From: amal kammoun 
Sent: Monday, September 10, 2018 10:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [monasca]

Hello,

I'm using devstack to have openstack. I installed also monasca using the 
following link: https://github.com/openstack/monasca-api/tree/master/devstack

The problem is that when I log in from horizon, The openstack services and 
servers are empty on the monitoring tab.

What should I do in order to get information about all my openstack servers and 
services?

Thank you!

Amal.
__
OpenStack Development Mailing 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] [monasca]

[amal kammoun]

Hello,

I'm using devstack to have openstack. I installed also monasca using the
following link:
https://github.com/openstack/monasca-api/tree/master/devstack

The problem is that when I log in from horizon, The openstack services and
servers are empty on the monitoring tab.

What should I do in order to get information about all my openstack servers
and services?

Thank you!

Amal.
__
OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

[Tony Breeds]

On Mon, Sep 10, 2018 at 08:40:28AM +0200, Julien Danjou wrote:
> On Mon, Sep 10 2018, Tony Breeds wrote:
> 
> > It looks like in August this was already setup 
> > https://review.openstack.org/#/c/591682/
> > So releases going forward will be on pypi.
> >
> > Julien, Do you mind me arranging for at least the following versions to
> > be published to pypi?
> >
> > [tony@thor ceilometer]$ for branch in 
> > origin/stable/{ocata,pike,queens,rocky} ; do printf "%-25s: %s\n" $branch 
> > "$(git describe --abbrev=0 $branch)" ; done
> > origin/stable/ocata  : 8.1.5
> > origin/stable/pike   : 9.0.6
> > origin/stable/queens : 10.0.1
> > origin/stable/rocky  : 11.0.0
> 
> Sure, go ahead!

Thanks!

Yours Tony.


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

Re: [openstack-dev] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

[Julien Danjou]

On Mon, Sep 10 2018, Tony Breeds wrote:

> It looks like in August this was already setup 
> https://review.openstack.org/#/c/591682/
> So releases going forward will be on pypi.
>
> Julien, Do you mind me arranging for at least the following versions to
> be published to pypi?
>
> [tony@thor ceilometer]$ for branch in origin/stable/{ocata,pike,queens,rocky} 
> ; do printf "%-25s: %s\n" $branch "$(git describe --abbrev=0 $branch)" ; done
> origin/stable/ocata  : 8.1.5
> origin/stable/pike   : 9.0.6
> origin/stable/queens : 10.0.1
> origin/stable/rocky  : 11.0.0

Sure, go ahead!

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

[openstack-dev] [Kuryr] Meeting cancelled

[Daniel Mellado Area]

Due to folks being at the Denver PTG (including myself virtually at  odd
hours x) we'll be cancelling today's weekly meeting.

Best!

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