date:20180904


On 9/4/2018 4:27 PM, melanie witt wrote:
Yes, we should definitely trim the placement DB migrations to only 
things relevant to placement. And we can use this opportunity to get rid 
of cruft too and squash all of the placement migrations together to 
start at migration 1 for the placement repo. If anyone can think of a 
problem with doing that, please shout it out.


Umm, nova-manage db sync creates entries in a sqlalchemy-migrate 
versions table, something like that, to track per database what the 
latest migration sync version has been.


Based on that, and the fact I thought our DB extraction policy was to 
mostly tell operators to copy the nova_api database and throw it 
elsewhere in a placement database, then the migrate versions table is 
going to be saying you're at 061 and you can't start new migrations from 
1 at that point, unless you wipe out that versions table after you copy 
the API DB.


I could be wrong, but just copying the database, squashing/trimming the 
migration scripts and resetting the version to 1, and assuming things 
are going to be hunky dory doesn't sound like it will work to me.


--

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] No weekly meeting on Thursday September 13


On 9/4/2018 4:13 PM, melanie witt wrote:

The next meeting will be on Thursday September 20 at 1400 UTC [1].


I'm assuming we're going to have a meeting *this* week though, right?

--

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] non-candidacy for TC

2018-09-04 Thread Amy Marrich

Thanks for all your contributions while on the TC Paul!

Amy (spotz)

On Tue, Sep 4, 2018 at 4:46 PM, Paul Belanger  wrote:

> Greetings,
>
> After a year on the TC, I've decided not to run for another term. I'd
> like to thank the other TC members for helping bring me up to speed over
> the last year and community for originally voting.  There is always work
> to do, and I'd like to use this email to encourage everybody to strongly
> consider running for the TC if you are interested in the future of
> OpenStack.
>
> It is a great learning opportunity, great humans to work with and great
> project! Please do consider running if you are at all interested.
>
> Thanks again,
> Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] non-candidacy for TC

On 2018-09-04 19:46:30 -0400 (-0400), Paul Belanger wrote:
> After a year on the TC, I've decided not to run for another term.
[...]

Thank you for your service (past and future)!
-- 
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] [goals][upgrade-checkers] Week R-31 update


On 9/4/2018 6:39 PM, Ben Nemec wrote:
Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo PTG 
schedule for this but figured I should check if it's something we even 
want to pursue.


Yeah I'm not opposed to trying to pull the nova stuff into a common 
library for easier consumption in other projects, I just haven't devoted 
the time for it, nor will I probably have the time to do it. If others 
are willing to investigate that it would be great.


--

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] [Neutron] Tungsten Fabric (formally OpenContrail) at Denver PTG

2018-09-04 Thread Sukhdev Kapur

Folks,

This is a reminder of this event at OpenStack PTG in Denver. If you have
not already RSVP'd please use the link below to do so.
Couple of changes - this event is from 9-5 (not 9-6), and lunch is from
12:30-1:30pm (not 1:00-2:00).

Look forward to seeing you there.

regards
-Sukhdev


On Tue, Aug 28, 2018 at 6:36 PM Sukhdev Kapur 
wrote:

> The Tungsten Fabric community invites you to join us at the OpenStack
> 
>  PTG in Denver
> 
> to discuss and contribute to two great projects: Tungsten
> 
>  Fabric
> 
> and Networking-OpenContrail
> 
> .
>
>
> We’ll be meeting on Tuesday, September 11, in Room Telluride B of Renaissance
> Denver Stapleton Hotel from 9am - 6pm. Here’s the agenda:
>
>
> 9am - 1:00 pm: *Networking-OpenContrail*
>
>Networking-OpenContrail is the OpenStack Neutron ML2 driver to
> integrate Tungsten Fabric to OpenStack. It is designed to eventually
> replace the old monolithic driver.
>
>This session will provide an update on the project, and then we’ll
> discuss the next steps.
>
>
> 1:00-2:00: Lunch
>
>
> 2:00-6:00: *Tungsten **Fabric *
>
> In this session, we’ll start with a brief overview of Tungsten
> Fabric for the benefit of those who may be new to the project.
>
> Then we’ll dive in deeper, discussing the Tungsten Fabric
> architecture, developer workflow, getting patches into Gerrit, and building
> and testing TF for OpenStack and Kubernetes.
>
>
>
> We hope you’ll join us:
>
>
> *Register* for the PTG here
> ,
> and
>
> Please let us know if you’ll attend these sessions: RSVP
> 
>
>
>
> Sukhdev Kapur and TF Networking Team
>
> IRC - Sukhdev
>
> sukhdevka...@gmail.com
>
>
>
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] announcing candidacy

2018-09-04 Thread Julia Kreger

That is an excellent question John!

The most specific thing that is weighing on my mind is elevating and
supporting contributors. While this is not new, I think we as a
community need to refocus on it because they are very fibers that make
up the fabric of our community and ultimately the electorate.

I also feel that we focus a bit too much on what is new without having
the data to really back it up. With so many project teams and working
groups, it is going to take time for the TC to really digest and
attempt to draw any actionable direction from the health assessment
that has been underway over the past few months.

-Julia
On Tue, Sep 4, 2018 at 2:07 PM John Dickinson  wrote:
>
>
>
> On 4 Sep 2018, at 12:16, Julia Kreger wrote:
>
> > Greetings Stackers!
> >
> > I hereby announce my candidacy for a position on the OpenStack
> > Technical
> > Committee.
> >
> > In many respects I consider myself a maverick, except reality is
> > sometimes
> > entirely different than my own self perception, upon reflection.
> > I find self reflection and introspection to be powerful tools, along
> > with
> > passion and desire for the common good. That desire for the common
> > good
> > is the driving force behind my involvement in OpenStack, which I hope
> > to
> > see as a vibrant and thriving community for years to come.
> >
> > Have things changed? Yes, I think they are ever evolving. I think we
> > can only
> > take the logical paths that we see before us at the time. Does this
> > mean
> > we will make mistakes? Absolutely, but mistakes are also opportunities
> > to learn and evolve as time goes on; which perhaps is an unspoken
> > backbone
> > of our community. The key is that we must not fear change but embrace
> > it.
> >
> > Changing our community for the better is a process we can only take
> > one step at a time, and we must recognize our strength
> > is in our diversity. As we move forward, as we evolve, we need to keep
> > in
> > mind our goals and overall vision. In a sense, these things vary
> > across all
> > projects, but our central community vision and goal helps provide
> > direction.
> >
> > As we continue our journey, I believe we need to lift up new
> > contributors,
> > incorporate new thoughts, and new ideas. Embracing change while
> > keeping our
> > basic course so new contributors can better find and integrate with
> > our
> > community as we continue forward. We need to listen and take that as
> > feedback to better understand other perspectives, for it is not only
> > our singular personal perspective which helps give us direction,
> > but the community as a whole.
> >
> > For those who do not know me well my name is Julia Ashley Kreger.
> > Often
> > I can be found on IRC as TheJulia, in numerous OpenStack related
> > channels.
> > I have had the pleasure of serving the community this past year on the
> > Technical Committee. I have also served the ironic community quite a
> > bit
> > during my time in the OpenStack community, which began during the Juno
> > cycle.
> >
> > I am the current Project Team Lead for the Ironic team. I began
> > serving in that capacity starting with the Rocky cycle. Prior,
> > I served as the team's release liaison. You might have seen me as one
> > of those crazy people advocating for standalone usage. Prior lives
> > included deploying and operating complex systems, but that is enough
> > about me.
> >
> > Ultimately I believe I bring a different perspective to the TC and it
> > is for
> > this, and my many strong beliefs and experiences, I feel I am well
> > suited
> >
> > to serve the community for another year on the Technical Committee.
> >
> > Thank you for your consideration,
> >
> > Julia
> >
> > freenode: TheJulia
> > Twitter: @ashinclouds
> > https://www.openstack.org/community/members/profile/19088/julia-kreger
> > http://stackalytics.com/?release=all_id=juliaashleykreger
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Julia,
>
> Do you have any specific examples of new ideas you are wanting to
> propose or advocate for, should you be re-elected?
>
> --John
>
>
>
> __
> OpenStack Development Mailing 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] non-candidacy for TC

Excerpts from Paul Belanger's message of 2018-09-04 19:46:30 -0400:
> Greetings,
> 
> After a year on the TC, I've decided not to run for another term. I'd
> like to thank the other TC members for helping bring me up to speed over
> the last year and community for originally voting.  There is always work
> to do, and I'd like to use this email to encourage everybody to strongly
> consider running for the TC if you are interested in the future of
> OpenStack.
> 
> It is a great learning opportunity, great humans to work with and great
> project! Please do consider running if you are at all interested.
> 
> Thanks again,
> Paul
> 

Thank you for serving this year, Paul!

Doug

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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update

Excerpts from Ben Nemec's message of 2018-09-04 18:39:35 -0500:
> Would it be helpful to factor some of the common code out into an Oslo 
> library so projects basically just have to subclass, implement check 
> functions, and add them to the _upgrade_checks dict? It's not a huge 
> amount of code, but a bunch of it seems like it would need to be 
> copy-pasted into every project. I have a tentative topic on the Oslo PTG 
> schedule for this but figured I should check if it's something we even 
> want to pursue.

+1 if there's reusable bits.

> 
> On 09/04/2018 04:29 PM, Matt Riedemann wrote:
> > Just a few updates this week.
> > 
> > 1. The story is now populated with a task per project that may have 
> > something to complete for this goal [1]. PTLs, or their liaison(s), 
> > should assign the task for their project to whomever is going to work on 
> > the goal. The goal document in governance is being updated with the 
> > appropriate links to storyboard [2].
> > 
> > 2. While populating the story and determining which projects to omit 
> > (like infra, docs, QA were obvious), I left in the deployment projects 
> > but those likely can/should opt-out of this goal for Stein since the 
> > goal is more focused on service projects like keystone/cinder/glance. I 
> > have pushed a docs updated to the goal with respect to deployment 
> > projects [3]. For deployment projects that don't plan on doing anything 
> > with this goal, feel free to just invalidate the task in storyboard for 
> > your project.
> > 
> > 3. I have a developer/contributor reference docs patch up for review in 
> > nova [4] which is hopefully written generically enough that it can be 
> > consumed by and used as a guide for other projects implementing these 
> > upgrade checks.
> > 
> > 4. I've proposed an amendment to the completion criteria for the goal 
> > [5] saying that projects with the "supports-upgrade" tag should 
> > integrate the checks from their project with their upgrade CI testing 
> > job. That could be grenade or some other upgrade testing framework, but 
> > it stands to reason that a project which claims to support upgrades and 
> > has automated checks for upgrades, should be running those in their CI.
> > 
> > Let me know if there are any questions. There will also be some time 
> > during a PTG lunch-and-learn session where I'll go over this goal at a 
> > high level, so feel free to ask questions during or after that at the 
> > PTG as well.
> > 
> > [1] https://storyboard.openstack.org/#!/story/2003657
> > [2] https://review.openstack.org/#/c/599759/
> > [3] https://review.openstack.org/#/c/599835/
> > [4] https://review.openstack.org/#/c/596902/
> > [5] https://review.openstack.org/#/c/599849/
> > 
> 

__
OpenStack Development Mailing 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] non-candidacy for TC

2018-09-04 Thread Paul Belanger

Greetings,

After a year on the TC, I've decided not to run for another term. I'd
like to thank the other TC members for helping bring me up to speed over
the last year and community for originally voting.  There is always work
to do, and I'd like to use this email to encourage everybody to strongly
consider running for the TC if you are interested in the future of
OpenStack.

It is a great learning opportunity, great humans to work with and great
project! Please do consider running if you are at all interested.

Thanks again,
Paul

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

[openstack-dev] [oslo] PTG Schedule

2018-09-04 Thread Ben Nemec


Hi,

I've added some tentative times to the planning etherpad[1]. This is all 
subject to change but I wanted to get something out there for people to 
look at. If you have other project responsibilities that day please let 
me know if anything conflicts. As you can see we have a fair amount of 
flexibility in our timing.


And of course if you have any last-minute topic additions feel free to 
make those as well.


1: https://etherpad.openstack.org/p/oslo-stein-ptg-planning

-Ben

__
OpenStack Development Mailing 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] [goals][upgrade-checkers] Week R-31 update

2018-09-04 Thread Ben Nemec

Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo PTG 
schedule for this but figured I should check if it's something we even 
want to pursue.


On 09/04/2018 04:29 PM, Matt Riedemann wrote:

Just a few updates this week.

1. The story is now populated with a task per project that may have 
something to complete for this goal [1]. PTLs, or their liaison(s), 
should assign the task for their project to whomever is going to work on 
the goal. The goal document in governance is being updated with the 
appropriate links to storyboard [2].


2. While populating the story and determining which projects to omit 
(like infra, docs, QA were obvious), I left in the deployment projects 
but those likely can/should opt-out of this goal for Stein since the 
goal is more focused on service projects like keystone/cinder/glance. I 
have pushed a docs updated to the goal with respect to deployment 
projects [3]. For deployment projects that don't plan on doing anything 
with this goal, feel free to just invalidate the task in storyboard for 
your project.


3. I have a developer/contributor reference docs patch up for review in 
nova [4] which is hopefully written generically enough that it can be 
consumed by and used as a guide for other projects implementing these 
upgrade checks.


4. I've proposed an amendment to the completion criteria for the goal 
[5] saying that projects with the "supports-upgrade" tag should 
integrate the checks from their project with their upgrade CI testing 
job. That could be grenade or some other upgrade testing framework, but 
it stands to reason that a project which claims to support upgrades and 
has automated checks for upgrades, should be running those in their CI.


Let me know if there are any questions. There will also be some time 
during a PTG lunch-and-learn session where I'll go over this goal at a 
high level, so feel free to ask questions during or after that at the 
PTG as well.


[1] https://storyboard.openstack.org/#!/story/2003657
[2] https://review.openstack.org/#/c/599759/
[3] https://review.openstack.org/#/c/599835/
[4] https://review.openstack.org/#/c/596902/
[5] https://review.openstack.org/#/c/599849/



__
OpenStack Development Mailing 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] Run for a seat on the TC (I am, and you can too!)

I'm standing for reelection to a third term on the OpenStack
Technical Committee. Rather than the usual platform where I drone on
and on about myself, I'm going to take this opportunity to run a
public service announcement instead.

Going into my second term I stated, "my personal vision for
OpenStack is that of a vibrant and diverse community" and I think
we've made progress on that front but still have a long way to go.
The diversity (personal, professional and cultural) of our community
has increased steadily, but we won't be able to sustain it if
similar diversity among elected leaders continues to lag behind. Our
leaders are frequently the faces of our community to those outside
it, and should set an example for others to follow. OpenStack is
built on a promise of representative leadership, and so we need
people from under-represented segments of our community to stand and
take up the challenge. There's just over 48 hours left to send in
your self-nomination for a seat on the TC. If you can't meet the
time commitments but know someone who can, encourage them to run.

And, of course, when the time comes, vote. Vote for the candidates
who best represent you, your beliefs, your ideals. Vote for those
who share your vision for who, how and what OpenStack should be. If
you've been paying attention these past years, you already know my
opinions. I'd rather hear some new opinions from you.
-- 
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] [election][tc] TC nomination

2018-09-04 Thread Lance Bragstad

Hi all,


I'd like to submit my candidacy to be a member of the OpenStack Technical
Committee.


My involvement with OpenStack began during the Diablo release. Since then
I've participated in various parts of the community, in both upstream and
downstream roles. Today I mainly focus on authorization and identity
management.


As your elected member of the Technical Committee, I plan to continue
advocating
for cross-project initiatives and easing cross-project collaboration
wherever possible.


One area where I'm heavily invested in this type of work is improving
OpenStack's
authorization system. For example, I've championed a community goal [0],
which eases policy maintenance and upgrades for operators. I've also
contributed
to the improvement of oslo libraries, making it easier for other services
to change policies and consume authorization attributes. I believe isolating
policy from service-specific logic is crucial in letting developers securely
implement system-level and project-level APIs. Finally, I worked to revive
a thread from 2015 [1] that allows us to deliver better support for default
roles out-of-the-box [2]. This will reduce custom policies found in most
deployments, enabling better interoperability between clouds and push OpenStack
to be more self-service than it is today. There is still more work to do,
but all of this makes API protection easier to implement while giving
more functionality
and security to end-users and operators.


Based upon the few examples shared above, I think it's imperative to
approach cross-project initiatives in a hands-on manner. As a member of the
TC, I plan to spend my time helping projects close the gap on goals
accepted by the TC by contributing to them directly. Additionally, I want
to use that experience to collaborate with others and find ways to make
achieving efforts across projects more common than it is today, as opposed
to monolithic efforts that commonly result in burnout and exhaustion for a
select few people.


Tracking Rocky community goals specifically shows that 50% of projects
are still
implementing, reviewing, or have yet to start mutable configuration. 61% are
in the same boat for removing usage of mox. Some efforts take years to
successfully
complete across projects (e.g. volume multi-attach, adopting new API
versions).


Whether the initiatives are a focused effort between two projects, or
a community-wide
goal, they provide significant value to everyone consuming, deploying, or
developing the software we write. I'm running for TC because I want to do
what I can to make cross-project interaction easier through contributing
and building necessary process as a TC member.


Thanks for reading through my candidacy. Safe travels to Denver and
hopefully I'll see you at the PTG.



Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html

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

[2] https://review.openstack.org/#/c/566377
__
OpenStack Development Mailing 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] [placement] extraction (technical) update


On Tue, 4 Sep 2018, Eric Fried wrote:


030 is okay as long as nothing goes wrong. If something does it
raises exceptions which would currently fail as the exceptions are
not there. See below for more about exceptions.


Maybe I'm misunderstanding what these migration thingies are supposed to
be doing, but 030 [1] seems like it's totally not applicable to
placement and should be removed. The placement database doesn't (and
shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in
the first place.

What am I missing?


Nothing, as far as I can tell, but as we hadn't had a clear
plan about how to proceed with the trimming of migrations, I've been
trying to point out where they form little speed bumps as we've
gone through this process and carried them with us. And tried to
annotate where there may present some more, until we trim them.

There are numerous limits to my expertise, and the db migrations is
one of several areas where I decided I wasn't going to hold the ball,
I'd just get us to the game and hope other people would find and
fill in the blanks. That seems to be working okay, so far.


* Presumably we can trim the placement DB migrations to just stuff
  that is relevant to placement


Yah, I would hope so. What possible reason could there be to do otherwise?


Mel's plans looks good to me.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [goals][upgrade-checkers] Week R-31 update


Just a few updates this week.

1. The story is now populated with a task per project that may have 
something to complete for this goal [1]. PTLs, or their liaison(s), 
should assign the task for their project to whomever is going to work on 
the goal. The goal document in governance is being updated with the 
appropriate links to storyboard [2].


2. While populating the story and determining which projects to omit 
(like infra, docs, QA were obvious), I left in the deployment projects 
but those likely can/should opt-out of this goal for Stein since the 
goal is more focused on service projects like keystone/cinder/glance. I 
have pushed a docs updated to the goal with respect to deployment 
projects [3]. For deployment projects that don't plan on doing anything 
with this goal, feel free to just invalidate the task in storyboard for 
your project.


3. I have a developer/contributor reference docs patch up for review in 
nova [4] which is hopefully written generically enough that it can be 
consumed by and used as a guide for other projects implementing these 
upgrade checks.


4. I've proposed an amendment to the completion criteria for the goal 
[5] saying that projects with the "supports-upgrade" tag should 
integrate the checks from their project with their upgrade CI testing 
job. That could be grenade or some other upgrade testing framework, but 
it stands to reason that a project which claims to support upgrades and 
has automated checks for upgrades, should be running those in their CI.


Let me know if there are any questions. There will also be some time 
during a PTG lunch-and-learn session where I'll go over this goal at a 
high level, so feel free to ask questions during or after that at the 
PTG as well.


[1] https://storyboard.openstack.org/#!/story/2003657
[2] https://review.openstack.org/#/c/599759/
[3] https://review.openstack.org/#/c/599835/
[4] https://review.openstack.org/#/c/596902/
[5] https://review.openstack.org/#/c/599849/

--

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] [placement] extraction (technical) update

2018-09-04 Thread melanie witt


On Tue, 4 Sep 2018 16:16:31 -0500, Eric Fried wrote:

030 is okay as long as nothing goes wrong. If something does it
raises exceptions which would currently fail as the exceptions are
not there. See below for more about exceptions.

Maybe I'm misunderstanding what these migration thingies are supposed to
be doing, but 030 [1] seems like it's totally not applicable to
placement and should be removed. The placement database doesn't (and
shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in
the first place.

What am I missing?


* Presumably we can trim the placement DB migrations to just stuff
   that is relevant to placement

Yah, I would hope so. What possible reason could there be to do otherwise?


Yes, we should definitely trim the placement DB migrations to only 
things relevant to placement. And we can use this opportunity to get rid 
of cruft too and squash all of the placement migrations together to 
start at migration 1 for the placement repo. If anyone can think of a 
problem with doing that, please shout it out.


-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] [nova] [placement] extraction (technical) update

2018-09-04 Thread Eric Fried

> 030 is okay as long as nothing goes wrong. If something does it
> raises exceptions which would currently fail as the exceptions are
> not there. See below for more about exceptions.

Maybe I'm misunderstanding what these migration thingies are supposed to
be doing, but 030 [1] seems like it's totally not applicable to
placement and should be removed. The placement database doesn't (and
shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in
the first place.

What am I missing?

> * Presumably we can trim the placement DB migrations to just stuff
>   that is relevant to placement 

Yah, I would hope so. What possible reason could there be to do otherwise?

-efried

[1]
https://github.com/openstack/placement/blob/2f1267c8785138c8f2c9495bd97e6c2a96c7c336/placement/db/sqlalchemy/api_migrations/migrate_repo/versions/030_require_cell_setup.py

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

[openstack-dev] [nova] No weekly meeting on Thursday September 13

2018-09-04 Thread melanie witt


Hi everyone,

This is just a reminder we won't have a weekly Nova meeting on Thursday 
September 13 because of PTG week. The next meeting will be on Thursday 
September 20 at 1400 UTC [1].


Cheers,
-melanie

[1] https://wiki.openstack.org/wiki/Meetings/Nova

__
OpenStack Development Mailing 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] announcing candidacy

2018-09-04 Thread John Dickinson




On 4 Sep 2018, at 12:16, Julia Kreger wrote:


Greetings Stackers!

I hereby announce my candidacy for a position on the OpenStack 
Technical

Committee.

In many respects I consider myself a maverick, except reality is 
sometimes

entirely different than my own self perception, upon reflection.
I find self reflection and introspection to be powerful tools, along 
with
passion and desire for the common good. That desire for the common 
good
is the driving force behind my involvement in OpenStack, which I hope 
to

see as a vibrant and thriving community for years to come.

Have things changed? Yes, I think they are ever evolving. I think we 
can only
take the logical paths that we see before us at the time. Does this 
mean

we will make mistakes? Absolutely, but mistakes are also opportunities
to learn and evolve as time goes on; which perhaps is an unspoken 
backbone
of our community. The key is that we must not fear change but embrace 
it.


Changing our community for the better is a process we can only take
one step at a time, and we must recognize our strength
is in our diversity. As we move forward, as we evolve, we need to keep 
in
mind our goals and overall vision. In a sense, these things vary 
across all
projects, but our central community vision and goal helps provide 
direction.


As we continue our journey, I believe we need to lift up new 
contributors,
incorporate new thoughts, and new ideas. Embracing change while 
keeping our
basic course so new contributors can better find and integrate with 
our

community as we continue forward. We need to listen and take that as
feedback to better understand other perspectives, for it is not only
our singular personal perspective which helps give us direction,
but the community as a whole.

For those who do not know me well my name is Julia Ashley Kreger. 
Often
I can be found on IRC as TheJulia, in numerous OpenStack related 
channels.

I have had the pleasure of serving the community this past year on the
Technical Committee. I have also served the ironic community quite a 
bit

during my time in the OpenStack community, which began during the Juno
cycle.

I am the current Project Team Lead for the Ironic team. I began
serving in that capacity starting with the Rocky cycle. Prior,
I served as the team's release liaison. You might have seen me as one
of those crazy people advocating for standalone usage. Prior lives
included deploying and operating complex systems, but that is enough
about me.

Ultimately I believe I bring a different perspective to the TC and it 
is for
this, and my many strong beliefs and experiences, I feel I am well 
suited


to serve the community for another year on the Technical Committee.

Thank you for your consideration,

Julia

freenode: TheJulia
Twitter: @ashinclouds
https://www.openstack.org/community/members/profile/19088/julia-kreger
http://stackalytics.com/?release=all_id=juliaashleykreger

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

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


Julia,

Do you have any specific examples of new ideas you are wanting to 
propose or advocate for, should you be re-elected?


--John



__
OpenStack Development Mailing 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] [tc] [all] TC Report 18-36

HTML: https://anticdent.org/tc-report-18-36.html

It's been a rather busy day, so this TC Report will be a quick
update of some discussions that have happened in the past week.

# PEP 8002

With Guido van Rossum stepping back from his role as the BDFL of
Python, there's work in progress to review different methods of
governance used in other communities to come up with some ideas for
the future of Python. Those reviews are being gathered in PEP 8002.
Doug Hellman has been helping with those conversations and asked for
[input on a
draft](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-28.log.html#t2018-08-28T20:40:41).

There was some good conversation, especially the bits about the
differences between ["direct democracy" and whatever what we do here
in
OpenStack](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-29.log.html#t2018-08-29T11:00:50).

The result of the draft was quickly merged into
[PEP 8002](https://www.python.org/dev/peps/pep-8002/).

# Summit Sessions

There was discussion about concerns some people experience with some
[summit sessions feeling like
advertising](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-29.log.html#t2018-08-29T18:21:08).

# PTG Coming Soon

The PTG is next week! TC sessions are described on [this
etherpad](https://etherpad.openstack.org/p/tc-stein-ptg).

# Elections Reminder

TC [election season](https://governance.openstack.org/election/) is
right now. Nomination period ends at the end of the day (UTC) 6th of
September so there isn't much time left. If you're toying with the idea,
nominate yourself, the community wants your input. If you have any
questions please feel free to ask.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [goals][python3] week 4 update

2018-09-04 Thread Sean McGinnis

> 
> +-+--+---+-++
> | Team| Open | Total | Status 
>  | Champion   |
> +-+--+---+-++
>
> | cinder  |0 | 0 | not started, 6 repos   
>  ||
>
> +-+--+---+-++
> 
> == Next Steps ==
> 
> If your team shows up in the above list as "not started" please let
> us know when you are ready to begin the transition. As you can see,
> it involves quite a few patches for some teams and it will be better
> to propose those early in the cycle during a relatively quiet period,
> rather than waiting until a time when having large batches of changes
> proposed together disrupts work.
> 

Jay has been out lately, so I will speak for Cinder for now. We should be at a
good point to proceed with the transition.

Sean

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

[openstack-dev] [election][tc] announcing candidacy

2018-09-04 Thread Julia Kreger

Greetings Stackers!

I hereby announce my candidacy for a position on the OpenStack Technical
Committee.

In many respects I consider myself a maverick, except reality is sometimes
entirely different than my own self perception, upon reflection.
I find self reflection and introspection to be powerful tools, along with
passion and desire for the common good. That desire for the common good
is the driving force behind my involvement in OpenStack, which I hope to
see as a vibrant and thriving community for years to come.

Have things changed? Yes, I think they are ever evolving. I think we can only
take the logical paths that we see before us at the time. Does this mean
we will make mistakes? Absolutely, but mistakes are also opportunities
to learn and evolve as time goes on; which perhaps is an unspoken backbone
of our community. The key is that we must not fear change but embrace it.

Changing our community for the better is a process we can only take
one step at a time, and we must recognize our strength
is in our diversity. As we move forward, as we evolve, we need to keep in
mind our goals and overall vision. In a sense, these things vary across all
projects, but our central community vision and goal helps provide direction.

As we continue our journey, I believe we need to lift up new contributors,
incorporate new thoughts, and new ideas. Embracing change while keeping our
basic course so new contributors can better find and integrate with our
community as we continue forward. We need to listen and take that as
feedback to better understand other perspectives, for it is not only
our singular personal perspective which helps give us direction,
but the community as a whole.

For those who do not know me well my name is Julia Ashley Kreger. Often
I can be found on IRC as TheJulia, in numerous OpenStack related channels.
I have had the pleasure of serving the community this past year on the
Technical Committee. I have also served the ironic community quite a bit
during my time in the OpenStack community, which began during the Juno
cycle.

I am the current Project Team Lead for the Ironic team. I began
serving in that capacity starting with the Rocky cycle. Prior,
I served as the team's release liaison. You might have seen me as one
of those crazy people advocating for standalone usage. Prior lives
included deploying and operating complex systems, but that is enough
about me.

Ultimately I believe I bring a different perspective to the TC and it is for
this, and my many strong beliefs and experiences, I feel I am well suited

to serve the community for another year on the Technical Committee.

Thank you for your consideration,

Julia

freenode: TheJulia
Twitter: @ashinclouds
https://www.openstack.org/community/members/profile/19088/julia-kreger
http://stackalytics.com/?release=all_id=juliaashleykreger

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

2018-09-04 Thread Alex Schultz

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 misc service action portions of the
>> openstack-ansible roles, but be able to disable the actual software
>> install/service management as that would be managed via our
>> ansible-role-tripleo-* roles.
>>
>> Is this something that would be beneficial to further discuss at the
>> PTG? Anyone have any additional suggestions/thoughts?
>>
>> My personal thoughts for tripleo would be that

Re: [openstack-dev] [tripleo-ansible] Future plans

2018-09-04 Thread Jill Rouleau

Hi Martin,On Mon, 2018-09-03 at 21:16 +0200, Martin Magr wrote:
> Gretings,
> 
>   since I did not find any blueprint regarding proper usage of
> tripleo-ansible, I would like to ask how exactly we plan to use
> tripleo-ansible project, what should be the proper structure of
> roles/playbooks, etc. Given the discussion in [1] it is the best place
> for backup and restore playbooks and I'd like to start preparing
> patches for B Currently the development being done in [2], but I
> hope that is only temporary location.

I've added the backup task example to the ansible roles blueprint[0].

Generally you'll want to add your tasks, variables, role-specific
handlers, etc to the appropriate ansible role repo (in this
case ansible-role-openstack-operations) and the playbooks for using
those role tasks to the tripleo-ansible project repo.

TripleO-specific shared handlers/libraries/etc - things your playbooks
will use that are not specific to one single role - would also go in the
tripleo-ansible repo.

[0] https://blueprints.launchpad.net/tripleo/+spec/ansible-tasks-to-role

> 
> Thanks in advance for answers,
> Martin
> 
> [1] https://review.openstack.org/#/c/582453/
> [2] https://github.com/centos-opstools/os-backup-ansible
> 
> -- 
> Martin Mágr
> Senior Software Engineer
> Red Hat Czech
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> ribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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] week 4 update

Subject: [goal][python3] week 4 update

This is the 4th week of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html). 

== What we learned last week ==

We have discovered a few repositories with tests defined in
project-config so that they run on all branches, even though they
are not supported on all branches. We will need project teams to
help identify those cases, and edit the scripted patches to remove
any jobs that are not appropriate on stable branches. If they pass,
you might want to consider keeping them, but if they are failing
and never worked then it's OK to remove them.

A few reviewers have suggested using some YAML features that allow
repeated sections to be inserted by reference, instead of copying
and pasting content in different parts of the Zuul configuration.
We can do this, but need to do it after the migration. See
http://lists.openstack.org/pipermail/openstack-dev/2018-August/134065.html
for details.

A surprising (to me) number of stable branches don't pass their
tests reliably.

It is possible to configure Storyboard to not show all of the events
(comments, changes, etc.) associated with a story by default. Doing
this fixes the slow rendering problem for the tracking story, and
the data is still available for normal stories by clicking on the
detail tabs at the bottom of the page. Go to
https://storyboard.openstack.org/#!/profile/preferences and select the
"Timeline events" you want to see by default.

== Ongoing and Completed Work ==

Here is the current status of the Zuul migration portion of the
goal (not including patches to add new python 3.6 unit test jobs,
change the documentation jobs, etc.).

+-+--+---+-++
| Team| Open | Total | Status   
   | Champion   |
+-+--+---+-++
| adjutant|4 | 4 | migration in progress
   | Doug Hellmann  |
| barbican|   13 |13 | migration in progress
   | Doug Hellmann  |
| blazar  |   16 |16 | migration in progress
   | Nguyen Hai |
| Chef OpenStack  |0 | 1 | DONE 
   | Doug Hellmann  |
| cinder  |0 | 0 | not started, 6 repos 
   ||
| cloudkitty  |0 |17 | waiting for cleanup 
https://review.openstack.org/#/c/598929 | Doug Hellmann  |
| congress|0 |16 | DONE 
   | Nguyen Hai |
| cyborg  |0 | 9 | DONE 
   | Nguyen Hai |
| designate   |0 |17 | DONE 
   | Nguyen Hai |
| Documentation   |0 |12 | DONE 
   | Doug Hellmann  |
| dragonflow  |4 | 4 | migration in progress
   | Nguyen Hai |
| ec2-api |2 | 7 | migration in progress
   ||
| freezer |   17 |28 | migration in progress
   ||
| glance  |   16 |16 | migration in progress
   | Nguyen Hai |
| heat|8 |27 | migration in progress
   | Doug Hellmann  |
| horizon |0 | 8 | DONE 
   | Nguyen Hai |
| I18n|0 | 0 | not started, 2 repos 
   | Doug Hellmann  |
| Infrastructure  |0 | 0 | not started, 158 repos   
   | Doug Hellmann  |
| InteropWG   |0 | 4 | DONE 
   | Doug Hellmann  |
| ironic  |   15 |60 | migration in progress
   | Doug Hellmann  |
| karbor  |   22 |22 | migration in progress
   | Nguyen Hai |
| keystone|   23 |30 | migration in progress
   | Doug Hellmann  |
| kolla   |1 | 8 | migration in progress
   ||
| kuryr   |   14 |24 | migration in progress

Re: [openstack-dev] better name for placement

2018-09-04 Thread Ed Leafe

On Sep 4, 2018, at 12:44 PM, Chris Dent  wrote:
> 
> Changing the name, again, is painful. Please, let's not do it.

I was in favor of coming up with a project name for placement. It was 
discussed, and the decision was made not to do so. We have since moved forward 
with the outcome of that decision. Revisiting it now would be painful, as Chris 
notes, and do nothing to advance the progress we have been making. Let’s focus 
on the work in front of us, and not waste time revisiting past decisions.

-- Ed Leafe

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

Re: [openstack-dev] better name for placement


On Tue, 4 Sep 2018, Jay Pipes wrote:

I wasn't in YVR, which explains why I's never heard of it. There's a number 
of misconceptions in the above document about the placement service that 
don't seem to have been addressed. I'm wondering if its worth revisiting the 
topic in Denver with the Cinder team or whether the Cinder team isn't 
interested in working with the placement service?


It was also discussed as part of the reshaper spec and implemented
for future use by a potential fast forward upgrade tool:


http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#direct-placement

https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/placement/direct.py

I agree, talking to Cinder some more in denver about use of
placement, either over HTTP or direct, whatever form, is good.

But I don't think any of that should impact the naming situation.
It's placement now, and placement is not really any less unique than
a lot of the other words we use, the direct situation is a very
special and edge case (likely in containers anyway, so naming not as
much of a big deal). Changing the name, again, is painful. Please,
let's not do it.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTG agenda

2018-09-04 Thread Miguel Lavalle

Dear Neutron Team,

I have scheduled all the topics that were proposed for the PTG in Denver
here: https://etherpad.openstack.org/p/neutron-stein-ptg. Please go to line
128 and onwards to see the detailed schedule. Please reach out to me should
we need to make any changes or adjustments

Best regards

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

[openstack-dev] [neutron] Weekly meeting canceled on Tuesday 11th

2018-09-04 Thread Miguel Lavalle

Dear Neutron Team,

Due to the PTG in Denver, the Neutron weekly team on Tuesday 11th at 1400
UTC is canceled. We will resume our meeting on Monday September 17th at
2100 UTC

Best regards

Miguel
__
OpenStack Development Mailing 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] better name for placement


On 09/04/2018 01:17 PM, Balázs Gibizer wrote:

On Tue, Sep 4, 2018 at 7:01 PM, Jay Pipes  wrote:

On 09/04/2018 12:59 PM, Balázs Gibizer wrote:

On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes  wrote:

On 09/04/2018 12:17 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:

On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:

Is there a reason we couldn't have 
openstack-placement be the package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level 
import, but I think
the only real risk is that the placement service couldn't be 
installed
at the same time as another package owned by someone 
else that used that

top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the package 
name

"placement"?

The alternative would be to make the top-level package something like
os_placement instead?


Either one works for me. Though I'm pretty sure that it isn't 
necessary. The reason it isn't necessary is because the stuff 
in the top-level placement package isn't meant to be imported by 
anything at all. It's the placement server code.


What about placement direct and the effort to allow cinder to 
import placement instead of running it as a separate service?


I don't know what placement direct is. Placement wasn't designed to be 
imported as a module. It was designed to be a (micro-)service with a 
REST API for interfacing.


In Vancouver we talked about allowing cinder to import placement as a 
library. See https://etherpad.openstack.org/p/YVR-cinder-placement L47


I wasn't in YVR, which explains why I's never heard of it. There's a 
number of misconceptions in the above document about the placement 
service that don't seem to have been addressed. I'm wondering if its 
worth revisiting the topic in Denver with the Cinder team or whether the 
Cinder team isn't interested in working with the placement service?


-jay

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

[openstack-dev] Retiring openstack-infra/odsreg and openstack-infra/puppet-odsreg

2018-09-04 Thread Andreas Jaeger

Puppet-odsreg is unused nowadays and it seems that odsreg is unused as 
well. I'll propose changes to retire them with topic "retire-odsreg",


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


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

Re: [openstack-dev] better name for placement




On Tue, Sep 4, 2018 at 7:01 PM, Jay Pipes  wrote:

On 09/04/2018 12:59 PM, Balázs Gibizer wrote:

On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes  wrote:

On 09/04/2018 12:17 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:

On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:

Is there a reason we couldn't have openstack-placement be the 
package name?


I would hope we'd be able to do that, and probably should do 
that.

'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level import, but 
I think
the only real risk is that the placement service couldn't be 
installed
at the same time as another package owned by someone else that 
used that

top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the 
package name

"placement"?

The alternative would be to make the top-level package something 
like

os_placement instead?


Either one works for me. Though I'm pretty sure that it isn't 
necessary. The reason it isn't necessary is because the stuff in 
the top-level placement package isn't meant to be imported by 
anything at all. It's the placement server code.


What about placement direct and the effort to allow cinder to import 
placement instead of running it as a separate service?


I don't know what placement direct is. Placement wasn't designed to 
be imported as a module. It was designed to be a (micro-)service with 
a REST API for interfacing.


In Vancouver we talked about allowing cinder to import placement as a 
library. See https://etherpad.openstack.org/p/YVR-cinder-placement L47


Cheers,
gibi



Best,
-jay

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

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



__
OpenStack Development Mailing 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] better name for placement


On 09/04/2018 12:59 PM, Balázs Gibizer wrote:

On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes  wrote:

On 09/04/2018 12:17 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:

On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:

Is there a reason we couldn't have openstack-placement be the 
package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level import, but I 
think

the only real risk is that the placement service couldn't be installed
at the same time as another package owned by someone else that used 
that

top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the package name
"placement"?

The alternative would be to make the top-level package something like
os_placement instead?


Either one works for me. Though I'm pretty sure that it isn't 
necessary. The reason it isn't necessary is because the stuff in the 
top-level placement package isn't meant to be imported by anything at 
all. It's the placement server code.


What about placement direct and the effort to allow cinder to import 
placement instead of running it as a separate service?


I don't know what placement direct is. Placement wasn't designed to be 
imported as a module. It was designed to be a (micro-)service with a 
REST API for interfacing.


Best,
-jay

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

Re: [openstack-dev] better name for placement




On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes  wrote:

On 09/04/2018 12:17 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:

On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:

Is there a reason we couldn't have openstack-placement be the 
package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level import, but I 
think
the only real risk is that the placement service couldn't be 
installed
at the same time as another package owned by someone else that 
used that

top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the package 
name

"placement"?

The alternative would be to make the top-level package something 
like

os_placement instead?


Either one works for me. Though I'm pretty sure that it isn't 
necessary. The reason it isn't necessary is because the stuff in the 
top-level placement package isn't meant to be imported by anything at 
all. It's the placement server code.


What about placement direct and the effort to allow cinder to import 
placement instead of running it as a separate service?


Cheers,
gibi



Nothing is going to be adding openstack-placement into its 
requirements.txt file or doing:


 from placement import blah

If some part of the server repo is meant to be imported into some 
other system, say nova, then it will be pulled into a separate lib, 
ala ironiclib or neutronlib.


Best,
-jay

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

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



__
OpenStack Development Mailing 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] kolla-ansible 7.0.0.0rc1 (rocky)

2018-09-04 Thread no-reply


Hello everyone,

A new release candidate for kolla-ansible for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/rocky

Release notes for kolla-ansible can be found at:

https://docs.openstack.org/releasenotes/kolla-ansible/




__
OpenStack Development Mailing 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] better name for placement


On Tue, 4 Sep 2018, Jay Pipes wrote:

Either one works for me. Though I'm pretty sure that it isn't necessary. The 
reason it isn't necessary is because the stuff in the top-level placement 
package isn't meant to be imported by anything at all. It's the placement 
server code.


Yes.

If some part of the server repo is meant to be imported into some other 
system, say nova, then it will be pulled into a separate lib, ala ironiclib 
or neutronlib.


Also yes.

At this stage I _really_ don't want to go through the trouble of
doing a second rename: we're in the process of finishing a rename
now.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] better name for placement


On 09/04/2018 12:17 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:

On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:


Is there a reason we couldn't have openstack-placement be the package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level import, but I think
the only real risk is that the placement service couldn't be installed
at the same time as another package owned by someone else that used that
top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the package name
"placement"?

The alternative would be to make the top-level package something like
os_placement instead?


Either one works for me. Though I'm pretty sure that it isn't necessary. 
The reason it isn't necessary is because the stuff in the top-level 
placement package isn't meant to be imported by anything at all. It's 
the placement server code.


Nothing is going to be adding openstack-placement into its 
requirements.txt file or doing:


 from placement import blah

If some part of the server repo is meant to be imported into some other 
system, say nova, then it will be pulled into a separate lib, ala 
ironiclib or neutronlib.


Best,
-jay

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

Re: [openstack-dev] better name for placement

Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:
> On 09/04/2018 11:44 AM, Doug Hellmann wrote:
> > Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
> >> On Tue, 4 Sep 2018, Jay Pipes wrote:
> >>
> >>> Is there a reason we couldn't have openstack-placement be the package 
> >>> name?
> >>
> >> I would hope we'd be able to do that, and probably should do that.
> >> 'openstack-placement' seems a find pypi package name for a think
> >> from which you do 'import placement' to do some openstack stuff,
> >> yeah?
> > 
> > That's still a pretty generic name for the top-level import, but I think
> > the only real risk is that the placement service couldn't be installed
> > at the same time as another package owned by someone else that used that
> > top-level name. I'm not sure how much of a risk that really is.
> 
> You mean if there was another Python package that used the package name 
> "placement"?
> 
> The alternative would be to make the top-level package something like 
> os_placement instead?

Yes.

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] [heat] Heat PTG

2018-09-04 Thread Rico Lin

Dear all

As PTG is near.
It's time to settle down the PTG format for Heat.

Here is the *PTG etherpad*:
https://etherpad.openstack.org/p/2018-Denver-PTG-Heat

This time we will run with *physical + online for all sessions*.
The online link for sessions will post on etherpad before the session
begins.

*We will only use Wednesday and Thursday, and our discussion will try to be
Asia friendly*, which means any sessions require the entire team effort
needs to happen in the morning.

Also* feel free to add topic suggestion* if you would like to raise any
discussion.
Otherwise, I see you at PTG(physical/online).

I'm *welcome any User/Ops feedbacks* as well, so feel free to leave any
message for us.



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] better name for placement


On 09/04/2018 11:44 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:

On Tue, 4 Sep 2018, Jay Pipes wrote:


Is there a reason we couldn't have openstack-placement be the package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?


That's still a pretty generic name for the top-level import, but I think
the only real risk is that the placement service couldn't be installed
at the same time as another package owned by someone else that used that
top-level name. I'm not sure how much of a risk that really is.


You mean if there was another Python package that used the package name 
"placement"?


The alternative would be to make the top-level package something like 
os_placement instead?


Best,
-jay

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

Re: [openstack-dev] better name for placement

On 2018-09-04 11:44:41 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
[...]
> > I would hope we'd be able to do that, and probably should do that.
> > 'openstack-placement' seems a find pypi package name for a think
> > from which you do 'import placement' to do some openstack stuff,
> > yeah?
> 
> That's still a pretty generic name for the top-level import, but I think
> the only real risk is that the placement service couldn't be installed
> at the same time as another package owned by someone else that used that
> top-level name. I'm not sure how much of a risk that really is.
[...]

Well, it goes further than just the local system. For example, if
there was another project unrelated to OpenStack which also had a
module named "placement" in the default import path, then Debian
wouldn't be able to carry packages for both projects without
modifying. At least one would need the module renamed or would need
to put it in a private path and then any consumers would need to be
adjusted to suit.
-- 
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

Excerpts from Ade Lee's message of 2018-09-04 08:21:51 -0400:
> Barbican is ready.
> 
> Thanks,
> Ade

Here you go:

+---+---+-+---+
| Subject   | Repo  
| URL | Branch|
+---+---+-+---+
| remove job settings for barbican repositories | 
openstack-infra/project-config| https://review.openstack.org/599663 | 
master|
| import zuul job settings from project-config  | openstack/barbican
| https://review.openstack.org/599644 | master|
| switch documentation job to new PTI   | openstack/barbican
| https://review.openstack.org/599645 | master|
| add python 3.6 unit test job  | openstack/barbican
| https://review.openstack.org/599646 | master|
| import zuul job settings from project-config  | openstack/barbican
| https://review.openstack.org/599655 | stable/ocata  |
| import zuul job settings from project-config  | openstack/barbican
| https://review.openstack.org/599657 | stable/pike   |
| import zuul job settings from project-config  | openstack/barbican
| https://review.openstack.org/599659 | stable/queens |
| import zuul job settings from project-config  | openstack/barbican
| https://review.openstack.org/599661 | stable/rocky  |
| import zuul job settings from project-config  | openstack/barbican-specs  
| https://review.openstack.org/599647 | master|
| import zuul job settings from project-config  | 
openstack/barbican-tempest-plugin | https://review.openstack.org/599648 | 
master|
| import zuul job settings from project-config  | openstack/castellan-ui
| https://review.openstack.org/599649 | master|
| switch documentation job to new PTI   | openstack/castellan-ui
| https://review.openstack.org/599650 | master|
| import zuul job settings from project-config  | 
openstack/python-barbicanclient   | https://review.openstack.org/599652 | 
master|
| switch documentation job to new PTI   | 
openstack/python-barbicanclient   | https://review.openstack.org/599653 | 
master|
| add python 3.6 unit test job  | 
openstack/python-barbicanclient   | https://review.openstack.org/599654 | 
master|
| import zuul job settings from project-config  | 
openstack/python-barbicanclient   | https://review.openstack.org/599656 | 
stable/ocata  |
| import zuul job settings from project-config  | 
openstack/python-barbicanclient   | https://review.openstack.org/599658 | 
stable/pike   |
| import zuul job settings from project-config  | 
openstack/python-barbicanclient   | https://review.openstack.org/599660 | 
stable/queens |
| import zuul job settings from project-config  | 
openstack/python-barbicanclient   | https://review.openstack.org/599662 | 
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

[openstack-dev] [tripleo] Posibilities to aggregate/merge configs across templates

2018-09-04 Thread Kamil Sambor

Hi all,

I want to start discussion on: how to solve issue with merging environment
values in TripleO.

Description:
In TripleO we experience some issues related to setting parameters in heat
templates. First, it isn't possible to set some params as ultimate source
of truth (disallow to overwrite param in other heat templates). Second it
isn't possible to merge values from different templates [0][1].
Both features are implemented in heat and can be easly used in templates.[2][3]
This doesn't work in TripleO because we overwrite all values in template in
python client instead of aggregating them etc. orsimply let heat do the
job .[4][5]

Solution:
Example solutions are: we can fix how python tripleo client works with env
and templates and enable heat features or we can write some puppet code
that will work similar to firewall code [6] and will support aggregate and
merge values that we point out. Both solutions have pros and cons but IMHO
solution which give heat to do job is preferable. But solution with merging
give us possibilities to have full control on merging of environments.

Problems:
Only few as a start: With both solutions we will have the same problem,
porting new patches which will use this functionalities to older version of
rhel. Also upgrades can be really problematic to new version. Also changes
which will enable heat feature will totally change how templates work and we
will need to change all templates and change default behavior (which is merge
params) to override behavior and also add posibilities to run temporaly old
behavior.

On the end, I prepared two patchsets with two PoC in progress. First one with
merging env in tripleo client but with using heat merging functionality:
https://review.openstack.org/#/c/599322/ . And second where we ignore merget
env and move all files and add them into deployment plan enviroments.
https://review.openstack.org/#/c/599559/

What do you think about each of solution?Which solution should be used
in TripleO?

Best,
Kamil Sambor

[0] https://bugs.launchpad.net/tripleo/+bug/1716391
[1] https://bugs.launchpad.net/heat/+bug/1635409
[2] 
https://docs.openstack.org/heat/pike/template_guide/environment.html#restrict-update-or-replace-of-a-given-resource
[3] 
https://docs.openstack.org/heat/pike/template_guide/environment.html#environment-merging
[4] 
https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/utils.py#L1019
[5] 
https://github.com/openstack/python-heatclient/blob/f73c2a4177377b710a02577feea38560b00a24bf/heatclient/common/template_utils.py#L191
[6] https://github.com/openstack/puppet-tripleo/tree/master/manifests/firewall

__
OpenStack Development Mailing 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] better name for placement

Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
> On Tue, 4 Sep 2018, Jay Pipes wrote:
> 
> > Is there a reason we couldn't have openstack-placement be the package name?
> 
> I would hope we'd be able to do that, and probably should do that.
> 'openstack-placement' seems a find pypi package name for a think
> from which you do 'import placement' to do some openstack stuff,
> yeah?

That's still a pretty generic name for the top-level import, but I think
the only real risk is that the placement service couldn't be installed
at the same time as another package owned by someone else that used that
top-level name. I'm not sure how much of a risk that really is.

> 
> Last I checked the concept of the package name is sort of put off
> until we have passing tests, but we're nearly there on that.
> 

__
OpenStack Development Mailing 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] better name for placement

Excerpts from Jay Pipes's message of 2018-09-04 10:05:28 -0400:
> On 09/04/2018 09:37 AM, Jeremy Stanley wrote:
> > On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote:
> > [...]
> >> it allowed for the possibility that there could be another project
> >> which provided the same service-type. That hasn't really come to
> >> pass
> > [...]
> > 
> > It still might make sense to attempt to look at this issue from
> > outside the limited scope of the OpenStack community. Is the
> > expectation that the project when packaged (on PyPI, in Linux
> > distributions and so on) will just be referred to as "placement"
> > with no further context?
> 
> I don't see any reason why the package name needs to be identical to the 
> repo name.
> 
> Is there a reason we couldn't have openstack-placement be the package name?

That would work fine. The package name is set in setup.cfg and we
have several examples where the value there and repo name don't
match.

Doug

> 
> Best,
> -jay
> 

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

[openstack-dev] [tripleo] VFs not configured in SR-IOV role

2018-09-04 Thread Samuel Monderer

Hi,

Attached is the used to deploy an overcloud with SR-IOV role.
The deployment completed successfully but the VFs aren't configured on the
host.
Can anyone have a look at what I missed.

Thanks
Samuel
<>
__
OpenStack Development Mailing 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

2018-09-04 Thread Luka Peschke

All changes on cloudkitty projects have been merged, so we're ready for 
https://review.openstack.org/#/c/598929. Thank you again!


--
Luka Peschke
Développeur
+33 (0) 5 82 95 65 36
5 rue du Moulin Bayard - 31000 Toulouse
www.objectif-libre.com

Le 2018-08-31 15:04, Doug Hellmann a écrit :
Excerpts from Christophe Sauthier's message of 2018-08-31 11:20:33 
+0200:



We are ready to start on the cloudkitty's team !

Christophe


Here are the patches:

+-+-+-+---+
| Subject | Repo
 | URL | Branch
|
+-+-+-+---+
| remove job settings for cloudkitty repositories |
openstack-infra/project-config  |
https://review.openstack.org/598929 | master|
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598884 | master|
| switch documentation job to new PTI |
openstack/cloudkitty|
https://review.openstack.org/598885 | master|
| add python 3.6 unit test job|
openstack/cloudkitty|
https://review.openstack.org/598886 | master|
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598900 | stable/ocata  |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598906 | stable/pike   |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598912 | stable/queens |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598918 | stable/rocky  |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/59 | master|
| switch documentation job to new PTI |
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598889 | master|
| add python 3.6 unit test job|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598890 | master|
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598902 | stable/ocata  |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598908 | stable/pike   |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598914 | stable/queens |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598920 | stable/rocky  |
| import zuul job settings from project-config|
openstack/cloudkitty-specs  |
https://review.openstack.org/598893 | master|
| import zuul job settings from project-config|
openstack/cloudkitty-tempest-plugin |
https://review.openstack.org/598895 | master|
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598897 | master|
| add python 3.6 unit test job|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598898 | master|
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598904 | stable/ocata  |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598910 | stable/pike   |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598917 | stable/queens |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598923 | 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


__
OpenStack Development Mailing 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] [publiccloud-wg] Meeting tomorrow for Public Cloud WG

2018-09-04 Thread Tobias Rydberg


Hi folks,

Time for a new meeting for the Public Cloud WG. Agenda draft can be 
found at https://etherpad.openstack.org/p/publiccloud-wg, feel free to 
add items to that list.


See you all tomorrow at 0700 UTC - IRC channel #openstack-publiccloud

Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


__
OpenStack Development Mailing 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] better name for placement


On Tue, 4 Sep 2018, Jay Pipes wrote:


Is there a reason we couldn't have openstack-placement be the package name?


I would hope we'd be able to do that, and probably should do that.
'openstack-placement' seems a find pypi package name for a think
from which you do 'import placement' to do some openstack stuff,
yeah?

Last I checked the concept of the package name is sort of put off
until we have passing tests, but we're nearly there on that.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] using multiple roles

2018-09-04 Thread Alex Schultz

On Tue, Sep 4, 2018 at 8:15 AM, Samuel Monderer
 wrote:
> Is it possible to have the roles_data.yaml file generated when running
> "openstack overcloud deploy"??
>

Not at this time.  That is something we'd like to get to, but is not
currently prioritized.

Thanks,
-Alex

> On Tue, Sep 4, 2018 at 4:52 PM Alex Schultz  wrote:
>>
>> On Tue, Sep 4, 2018 at 2:31 AM, Samuel Monderer
>>  wrote:
>> > Hi,
>> >
>> > Due to many different HW in our environment we have multiple roles.
>> > I would like to place each role definition if a different file.
>> > Is it possible to refer to all the roles from roles_data.yaml to all the
>> > different files instead of having a long roles_data.yaml file?
>> >
>>
>> So you can have them in different files for general management,
>> however in order to actually consume them  they need to be in a
>> roles_data.yaml file for the deployment. We offer a few cli commands
>> to help with this management.  The 'openstack overcloud roles
>> generate' command can be used to generate a roles_data.yaml for your
>> deployment. You can store the individual roles in a folder and use the
>> 'openstack overcloud roles list --roles-path /your/folder' to view the
>> available roles.  This workflow is described in the roles README[0]
>>
>> Thanks,
>> -Alex
>>
>> [0]
>> http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/roles/README.rst
>>
>> > Regards,
>> > Samuel
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [tripleo] using multiple roles

2018-09-04 Thread Samuel Monderer

Is it possible to have the roles_data.yaml file generated when running
"openstack overcloud deploy"??

On Tue, Sep 4, 2018 at 4:52 PM Alex Schultz  wrote:

> On Tue, Sep 4, 2018 at 2:31 AM, Samuel Monderer
>  wrote:
> > Hi,
> >
> > Due to many different HW in our environment we have multiple roles.
> > I would like to place each role definition if a different file.
> > Is it possible to refer to all the roles from roles_data.yaml to all the
> > different files instead of having a long roles_data.yaml file?
> >
>
> So you can have them in different files for general management,
> however in order to actually consume them  they need to be in a
> roles_data.yaml file for the deployment. We offer a few cli commands
> to help with this management.  The 'openstack overcloud roles
> generate' command can be used to generate a roles_data.yaml for your
> deployment. You can store the individual roles in a folder and use the
> 'openstack overcloud roles list --roles-path /your/folder' to view the
> available roles.  This workflow is described in the roles README[0]
>
> Thanks,
> -Alex
>
> [0]
> http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/roles/README.rst
>
> > Regards,
> > Samuel
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] better name for placement


On 09/04/2018 09:37 AM, Jeremy Stanley wrote:

On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote:
[...]

it allowed for the possibility that there could be another project
which provided the same service-type. That hasn't really come to
pass

[...]

It still might make sense to attempt to look at this issue from
outside the limited scope of the OpenStack community. Is the
expectation that the project when packaged (on PyPI, in Linux
distributions and so on) will just be referred to as "placement"
with no further context?


I don't see any reason why the package name needs to be identical to the 
repo name.


Is there a reason we couldn't have openstack-placement be the package name?

Best,
-jay

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

[openstack-dev] [horizon][stable] Removing Inactive Cores

2018-09-04 Thread Ivan Kolodyazhny

Hi team,

Since we're at the beginning of Stein release cycle, I think it's a good
time to do some cleanup in our core teams.

First of all, I would like to say a big Thank you to everybody who
contributed as Core Reviewer to Horizon.

Unfortunately, some people became inactive as reviewers during the last few
cycles, that's why I propose to remove them from Horizon Core and Horizon
Stable Core teams. I'm pretty sure that you could be added to the teams
again once your contribution will be active again.

Changes to horizon-core team:
- Kenji Ishii
- Tatiana Ovchinnikova
- Ying Zuo

Changes to horizon-stable-maint team:
- Doug Fish
- Lin Hua Cheng
- Matthias Runge
- Richard Jones
- Rob Cresswell
- Thai Tran
- Ying Zuo





Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing 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][searchlight][designate][telemetry][mistral][blazar][watcher][masakari][vitrage]Possible deprecation of Nova's legacy notification interface




On Tue, Sep 4, 2018 at 3:04 PM, Ifat Afek  wrote:

Hi,

Vitrage also uses the Nova legacy notifications.
Unfortunately I will not attend the PTG, but I added the relevant 
information in the etherpad.


Thanks for the pad update.

Cheers,
gibi



Thanks,
Ifat

On Tue, Aug 28, 2018 at 5:31 PM Balázs Gibizer 
 wrote:

Thanks for all the responses. I collected them on the nova ptg
discussion etherpad [1] (L186 at the moment). The nova team will talk
about deprecation of the legacy interface on Friday on the PTG. If 
you

want participate in the discussion but you are not planning to sit in
the nova room whole day then let me know and I will try to ping you
over IRC when we about to start the item.

Cheers,
gibi

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





__
OpenStack Development Mailing 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] using multiple roles

2018-09-04 Thread Alex Schultz

On Tue, Sep 4, 2018 at 2:31 AM, Samuel Monderer
 wrote:
> Hi,
>
> Due to many different HW in our environment we have multiple roles.
> I would like to place each role definition if a different file.
> Is it possible to refer to all the roles from roles_data.yaml to all the
> different files instead of having a long roles_data.yaml file?
>

So you can have them in different files for general management,
however in order to actually consume them  they need to be in a
roles_data.yaml file for the deployment. We offer a few cli commands
to help with this management.  The 'openstack overcloud roles
generate' command can be used to generate a roles_data.yaml for your
deployment. You can store the individual roles in a folder and use the
'openstack overcloud roles list --roles-path /your/folder' to view the
available roles.  This workflow is described in the roles README[0]

Thanks,
-Alex

[0] 
http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/roles/README.rst

> Regards,
> Samuel
>
> __
> OpenStack Development Mailing 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] better name for placement (was:Nominating Chris Dent for placement-core)

On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote:
[...]
> it allowed for the possibility that there could be another project
> which provided the same service-type. That hasn't really come to
> pass
[...]

It still might make sense to attempt to look at this issue from
outside the limited scope of the OpenStack community. Is the
expectation that the project when packaged (on PyPI, in Linux
distributions and so on) will just be referred to as "placement"
with no further context?
-- 
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] [tempest][CI][nova compute] Skipping non-compute-driver tests

2018-09-04 Thread Eric Fried

Folks-

The other day, I posted an experimental patch [1] with an effectively
empty ComputeDriver (just enough to make n-cpu actually start) to see
how much of our CI would pass. The theory being that any tests that
still pass are tests that don't touch our compute driver, and are
therefore not useful to run in our CI environment. Because anything that
doesn't touch our code should already be well covered by generic
dsvm-tempest CIs. The results [2] show that 707 tests still pass.

So I'm wondering whether there might be a way to mark tests as being
"compute driver-specific" such that we could switch off all the other
ones [3] via a one-line conf setting. Because surely this has potential
to save a lot of CI resource not just for us but for other driver
vendors, in tree and out.

Thanks,
efried

[1] https://review.openstack.org/#/c/599066/
[2]
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz
[3] I get that there's still value in running all those tests. But it
could be done like once every 10 or 50 or 100 runs instead of every time.

__
OpenStack Development Mailing 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][searchlight][designate][telemetry][mistral][blazar][watcher][masakari][vitrage] Possible deprecation of Nova's legacy notification interface

2018-09-04 Thread Ifat Afek

Hi,

Vitrage also uses the Nova legacy notifications.
Unfortunately I will not attend the PTG, but I added the relevant
information in the etherpad.

Thanks,
Ifat

On Tue, Aug 28, 2018 at 5:31 PM Balázs Gibizer 
wrote:

> Thanks for all the responses. I collected them on the nova ptg
> discussion etherpad [1] (L186 at the moment). The nova team will talk
> about deprecation of the legacy interface on Friday on the PTG. If you
> want participate in the discussion but you are not planning to sit in
> the nova room whole day then let me know and I will try to ping you
> over IRC when we about to start the item.
>
> Cheers,
> gibi
>
> [1] https://etherpad.openstack.org/p/nova-ptg-stein
__
OpenStack Development Mailing 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] announcing candidacy

I am announcing my candidacy for a position on the OpenStack
Technical Committee.

I started contributing to OpenStack in 2012, not long after joining
Dreamhost, and I am currently employed by Red Hat to work on OpenStack
with a focus on long-term project concerns. I have served on the
Technical Committee for the last five years, including as Chair during
the last term. I have also been PTL of the Oslo and Release Management
teams at different points in the past.

I have spent most of my time in all of those roles over the last few
years making incremental improvements in our ability to collaborate
while building OpenStack, including initiatives such as leading the
current community goal to run CI jobs under Python 3 by default [1];
coordinating last year's documentation migration; and updating our
dependency management system to make it easier for projects to run
stand-alone.

During my time serving as TC Chair, I have tried to update the way the
group works with the community. We started by performing a "health
check" for all of our project teams [2], as a way to spot potential
issues teams are experiencing that we can help with, and to encourage TC
members to learn more about teams they may not interact with on a
daily basis. We will be reviewing the results at the PTG [3], and
continuing to refine that process.

I have also had a few opportunities this year to share our governance
structure with other communities [4][5]. It's exciting to be able to
talk to them about how the ideals and principles that hold our
community together can also apply to their projects.

The OpenStack community continues to be the most welcoming group I
have interacted with in more than 25 years of contributing to open
source projects. I look forward to another opportunity to serve the
project through the Technical Committee over the coming year.

Thank you,
Doug

Candidacy submission: https://review.openstack.org/599582
Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
Commit history: https://review.openstack.org/#/q/owner:2472,n,z
Foundation Profile:
http://www.openstack.org/community/members/profile/359
Freenode: dhellmann
Website: https://doughellmann.com

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://wiki.openstack.org/wiki/OpenStack_health_tracker
[3] https://etherpad.openstack.org/p/tc-stein-ptg
[4] https://doughellmann.com/blog/2018/08/21/planting-acorns/
[5] https://www.python.org/dev/peps/pep-8002/

__
OpenStack Development Mailing 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

2018-09-04 Thread Ade Lee

Barbican is ready.

Thanks,
Ade

On Thu, 2018-08-30 at 19:24 -0400, Doug Hellmann wrote:
> Below is the list of project teams that have not yet started
> migrating
> their zuul configuration. If you're ready to go, please respond to
> this
> email to let us know so we can start proposing patches.
> 
> Doug
> 
> > adjutant| 3 repos   |
> > barbican| 5 repos   |
> > Chef OpenStack  | 19 repos  |
> > cinder  | 6 repos   |
> > cloudkitty  | 5 repos   |
> > I18n| 2 repos   |
> > Infrastructure  | 158 repos |
> > loci| 1 repos   |
> > nova| 6 repos   |
> > OpenStack Charms| 80 repos  |
> > Packaging-rpm   | 4 repos   |
> > Puppet OpenStack| 47 repos  |
> > Quality Assurance   | 22 repos  |
> > Telemetry   | 8 repos   |
> > trove   | 5 repos   |
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [TC][Searchlight] Searchlight project missing from the OpenStack website

2018-09-04 Thread Trinh Nguyen

Dear TC,

I'm not sure if I missed something but Searchlight is not listed in the
Software section of the OpenStack website [1]. Is it because Searchlight
has missed the Rocky cycle?

Bests,

[1]
https://www.openstack.org/software/project-navigator/openstack-components#operations-services


*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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

2018-09-04 Thread Dmitry Tantsur

Hi,

On 08/29/2018 08:36 AM, Edison Xiang wrote:

Hi team,

As we know, Open API 3.0 was released on July, 2017, it is about one year ago.
Open API 3.0 support some new features like anyof, oneof and allof than Open API
2.0(Swagger 2.0).

Now OpenStack projects do not support Open API.
Also I found some old emails in the Mail List about supporting Open API 2.0 in
OpenStack.

Some limitations are mentioned in the Mail List for OpenStack API:
1. The POST */action APIs.
These APIs are exist in lots of projects like nova, cinder.
These APIs have the same URI but the responses will be different when the
request is different.

2. Micro versions.
These are controller via headers, which are sometimes used to describe
behavioral changes in an API, not just request/response schema changes.

About the first limitation, we can find the solution in the Open API 3.0.
The example [2] shows that we can define different request/response in the same
URI by anyof feature in Open API 3.0.

This is a good first step, but if I get it right it does not specify which
response corresponds to which request.

About the micro versions problem, I think it is not a limitation related a
special API Standard.

We can list all micro versions API schema files in one directory like nova/V2,

I don't think this approach will scale if you plan to generate anything based on
these schemes. If you generate client code from separate schema files, you'll
essentially end up with dozens of major versions.

or we can list the schema changes between micro versions as tempest project did
[3].

Based on Open API 3.0, it can bring lots of benefits for OpenStack Community and
does not impact the current features the Community has.
For example, we can automatically generate API documents, different language
Clients(SDK) maybe for different micro versions,

From my experience with writing an SDK, I don't believe generating a complete
SDK from API schemes is useful. Maybe generating low-level protocol code to base
an SDK on, but even that may be easier to do by hand.

Dmitry

and generate cloud tool adapters for OpenStack, like ansible module, terraform
providers and so on.
Also we can make an API UI to provide an online and visible API search, API
Calling for every OpenStack API.

3rd party developers can also do some self-defined development.

[1] https://github.com/OAI/OpenAPI-Specification
[2]
https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
[3]
https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute

Best Regards,
Edison Xiang

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

2018-09-04 Thread mathieu bultel

Hi

On 08/30/2018 04:28 PM, Honza Pokorny wrote:
> Hello!
>
> Over the last few months, it seems that tripleo-quickstart has evolved
> into a CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of feature sets.  However, it's become less useful for
> setting up development environments by humans.  For example, devmode.sh
> was recently deprecated without a user-friendly replacement. Moreover,
> during some informal irc conversations in #oooq, some developers even
> mentioned the plan to merge tripleo-quickstart and tripleo-ci.
>
> I think it would be beneficial to create a set of defaults for
> tripleo-quickstart that can be used to spin up new environments; a set
> of defaults for humans.  This can either be a well-maintained script in
> tripleo-quickstart itself, or a brand new project, e.g.
> tripleo-quickstart-humans.  The number of settings, knobs, and flags
> should be kept to a minimum.
>
> This would accomplish two goals:
>
> 1.  It would bring uniformity to the team.  Each environment is
> installed the same way.  When something goes wrong, we can
> eliminate differences in setup when debugging.  This should save a
> lot of time.
>
> 2.  Quicker and more reliable environment setup.  If the set of defaults
> is used by many people, it should container fewer bugs because more
> people using something should translate into more bug reports, and
> more bug fixes.
>
> These thoughts are coming from the context of tripleo-ui development.  I
> need an environment in order to develop, but I don't necessarily always
> care about how it's installed.  I want something that works for most
> scenarios.
>
> What do you think?  Does this make sense?  Does something like this
> already exist?
I'm agree with the fact that quickstart has turned into a CI tool, more
than a human tool.
I still use quickstart to deploy and work on TripleO but I feel a bit
lost when I have to grep into the config/ dirctory to see which
featureset match to my needs and, if not, try to tweak the config and
pray that the tweaked options will work as expected.

I also discovered the ci reproducer script recently. The script probably
need to be a bit more robust, but it's a real gain when you have to
reproduce CI environments.

I think a first less effort for now would be to bring a set of
Quickstart commands and "human readable config files" to improve the
situation.

> Thanks for listening!
>
> Honza
>
> __
> OpenStack Development Mailing 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] Dose anyone have use Vitrage to build a mature project for RCA or any other purpose?

2018-09-04 Thread Ifat Afek

On Tue, Sep 4, 2018 at 11:41 AM zhangwenqing <18800173...@163.com> wrote:

> I want to use Vitrage for my AIOps project, but i can't get any relative
> information, and I think this is not a mature project.Does anyone have
> relative experience?Would you please give me some advice?
>

Hi,

Vitrage is used in production environments as part of Nokia CloudBand
Infrastructure Software and CloudBand Network Director products. The
project exists for three years now, and it is mature.
I'll be happy to help if you have other questions.

Br,
Ifat
__
OpenStack Development Mailing 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] Automating role generation

2018-09-04 Thread Steven Hardy

On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský  wrote:
> On 4.9.2018 08:13, Janki Chhatbar wrote:
>>
>> Hi
>>
>> I am looking to automate role file generation in TripleO. The idea is
>> basically for an operator to create a simple yaml file (operator.yaml,
>> say)
>> listing services that are needed and then TripleO to generate
>> Controller.yaml enabling only those services that are mentioned.
>>
>> For example:
>> operator.yaml
>> services:
>>  Glance
>>  OpenDaylight
>>  Neutron ovs agent
>
>
> I'm not sure it's worth introducing a new file format as such, if the
> purpose is essentially to expand e.g. "Glance" into
> "OS::TripleO::Services::GlanceApi" and
> "OS::TripleO::Services::GlanceRegistry"? It would be another layer of
> indirection (additional mental work for the operator who wants to understand
> how things work), while the layer doesn't make too much difference in
> preparation of the role. At least that's my subjective view.
>
>>
>> Then TripleO should
>> 1. Fail because ODL and OVS agent are either-or services
>
>
> +1 i think having something like this would be useful.
>
>> 2. After operator.yaml is modified to remove Neutron ovs agent, it should
>> generate Controller.yaml with below content
>>
>> ServicesDefault:
>> - OS::TripleO::Services::GlanceApi
>> - OS::TripleO::Services::GlanceRegistry
>> - OS::TripleO::Services::OpenDaylightApi
>> - OS::TripleO::Services::OpenDaylightOvs
>>
>> Currently, operator has to manually edit the role file (specially when
>> deployed with ODL) and I have seen many instances of failing deployment
>> due
>> to variations of OVS, OVN and ODL services enabled when they are actually
>> exclusive.
>
>
> Having validations on the service list would be helpful IMO, e.g. "these
> services must not be in one deployment together", "these services must not
> be in one role together", "these services must be together", "we recommend
> this service to be in every role" (i'm thinking TripleOPackages, Ntp, ...)
> etc. But as mentioned above, i think it would be better if we worked
> directly with the "OS::TripleO::Services..." values rather than a new layer
> of proxy-values.
>
> Additional random related thoughts:
>
> * Operator should still be able to disobey what the validation suggests, if
> they decide so.
>
> * Would be nice to have the info about particular services (e.g what can't
> be together) specified declaratively somewhere (TripleO's favorite thing in
> the world -- YAML?).
>
> * We could start with just one type of validation, e.g. the mutual
> exclusivity rule for ODL vs. OVS, but would be nice to have the solution
> easily expandable for new rule types.

This is similar to how the UI uses the capabilities-map.yaml, so
perhaps we can use that as the place to describe service dependencies
and conflicts?

https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml

Currently this isn't used at all for the CLI, but I can imagine some
kind of wizard interface being useful, e.g you could say enable
"Glance" group and it'd automatically pull in all glance dependencies?

Another thing to mention is this doesn't necessarily have to generate
a new role (although it could), the *Services parameter for existing
roles can be overridden, so it might be simpler to generate an
environment file instead.

Steve

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

[openstack-dev] [nova]Notification subteam meeting cancelled


Hi,

This week's and next week's notification subteam meeting has been 
cancelled. See you in Denver.


Cheers,
gibi


__
OpenStack Development Mailing 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] Automating role generation

2018-09-04 Thread Jiří Stránský


On 4.9.2018 08:13, Janki Chhatbar wrote:

Hi

I am looking to automate role file generation in TripleO. The idea is
basically for an operator to create a simple yaml file (operator.yaml, say)
listing services that are needed and then TripleO to generate
Controller.yaml enabling only those services that are mentioned.

For example:
operator.yaml
services:
 Glance
 OpenDaylight
 Neutron ovs agent


I'm not sure it's worth introducing a new file format as such, if the 
purpose is essentially to expand e.g. "Glance" into 
"OS::TripleO::Services::GlanceApi" and 
"OS::TripleO::Services::GlanceRegistry"? It would be another layer of 
indirection (additional mental work for the operator who wants to 
understand how things work), while the layer doesn't make too much 
difference in preparation of the role. At least that's my subjective view.




Then TripleO should
1. Fail because ODL and OVS agent are either-or services


+1 i think having something like this would be useful.


2. After operator.yaml is modified to remove Neutron ovs agent, it should
generate Controller.yaml with below content

ServicesDefault:
- OS::TripleO::Services::GlanceApi
- OS::TripleO::Services::GlanceRegistry
- OS::TripleO::Services::OpenDaylightApi
- OS::TripleO::Services::OpenDaylightOvs

Currently, operator has to manually edit the role file (specially when
deployed with ODL) and I have seen many instances of failing deployment due
to variations of OVS, OVN and ODL services enabled when they are actually
exclusive.


Having validations on the service list would be helpful IMO, e.g. "these 
services must not be in one deployment together", "these services must 
not be in one role together", "these services must be together", "we 
recommend this service to be in every role" (i'm thinking 
TripleOPackages, Ntp, ...) etc. But as mentioned above, i think it would 
be better if we worked directly with the "OS::TripleO::Services..." 
values rather than a new layer of proxy-values.


Additional random related thoughts:

* Operator should still be able to disobey what the validation suggests, 
if they decide so.


* Would be nice to have the info about particular services (e.g what 
can't be together) specified declaratively somewhere (TripleO's favorite 
thing in the world -- YAML?).


* We could start with just one type of validation, e.g. the mutual 
exclusivity rule for ODL vs. OVS, but would be nice to have the solution 
easily expandable for new rule types.


Thanks for looking into this :)

Jirka



I am willing to spend some cycle on this. What I ask is some clearity on
its feasibility and any other ideas to make this idea into a feature.



__
OpenStack Development Mailing 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] Dose anyone have use Vitrage to build a mature project for RCA or any other purpose?

2018-09-04 Thread zhangwenqing

I want to use Vitrage for my AIOps project, but i can't get any relative 
information, and I think this is not a mature project.Does anyone have relative 
experience?Would you please give me some advice?__
OpenStack Development Mailing 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] better name for placement (was:Nominating Chris Dent for placement-core)