Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Octave J. Orgeron]

Hi Doug,

Comments below..

On 2/3/2017 8:21 AM, Doug Hellmann wrote:

Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:

On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:

That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.

A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_status, which by
default are 255 chars.


let me give you a tip on IF blocks, that they are a bit of an
anti-pattern.  If you want a column type to do one thing in one case,
and another in another case, create an object that does the thing you want:


some_table = Table(
  'some_table', metadata,
  Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)

I wonder if we want to do either, though. Shouldn't we try to use
the same (smaller) column size all the time? Otherwise we end up
with another incompatibility between different deployments, since
sometimes things like names might have different sizes in different
clouds.


I think we would all benefit from columns being sized for the actual 
content instead of blindly using strings of 255 when the only possible 
values are less than 10 chars. Also capturing entire command line 
outputs from OVS and hypervisors seems a bit of a waste to, instead of 
processing the output first and extracting the key values for storage in 
the database.


Doing this would significantly reduce the amount of code on my end. If 
we only had to change the columns sizes and types globally for InnoDB 
and NDB, that would simplify things a great deal. We could also develop 
some guidelines on how to structure tables to prevent them from going 
over 14k or any other value we deem appropriate to support multiple 
MySQL engines.





I think we might want to look into creating a stub dialect called 'ndb'
that subclasses mysql+pymysql.   Treating ndb as a whole different
database means there's no longer the need for a flag in oslo.db, the
'ndb' name would instead be interpreted as a new backend - the main
thing would be ensuring all the mysql-appropriate hooks in oslo.db are
also emitted for ndb, but this also gives us a way to pick and choose
which hooks apply.   It seems like there may be enough different about
it to separate it at this level.

Not sure if people on the list are seeing that we are simultaneously
talking about getting rid of Postgresql in the efforts to support only
"one database", while at the same time adding one that is in many ways a
new database.

Yes, that does seem a bit ironic. That's also why I was pointing
out that we're going to want to have people lined up to support the
work before starting. The lack of help with Postresql testing
resulted in removing it from the gate, and possibly to dropping
support entirely.

For reference, the discussion in [1] led to this proposed TC
resolution [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111357
[2] https://review.openstack.org/427880





So to determine a more appropriate size, I look

through the Cinder code to find where the possible options/states are
for those columns. Then I cut it down to a more reasonable size. I'm
very careful when I cut the size of a string column to ensure that all
of the possible values can be contained.

In cases where a column is extremely large for capturing the outputs of
a command, I will change the type to Text or TinyText depending on the
length required. A good example of this is in the agents table of
Neutron where there is a column for configurations that has a string
length of 4096 characters, which I change to Text. Text blobs are stored
differently and do not count against the row length.

I've also observed differences between Kilo, Mitaka, and tip where even
for InnoDB some of these tables are getting wider than can be supported.
So in the case of Cinder, some of the columns have been shifted to
separate tables to fit within 65k. I've seen the same thing in Neutron.
So I fully expect that some of the services that have table bloat will
have to cut the lengths or break the tables up over time anyways. As
that happens, it reduces the amount of work for me, which is a good thing.

The most complicated database schemas to patch up are cinder, glance,
neutron, and nova due to the size and complexity of their tables. Those
also have a lot of churn between releases where the schema changes more
often. Other services like keystone, heat, and ironic are considerably
easier to work with and have well laid out tables that don't change much.

Thanks,
Octave

On 2/2/2017 1:25 PM, Mike Bayer wrote:


On 02/02/2017 02:52 PM, Mike Bayer wrote:

But more critically I noticed you referred to altering the names of
columns to suit NDB.  How will this be accomplished?   Changing a column
name in an openstack application is no longer trivial, because online

Re: [openstack-dev] [TripleO] FFE for novajoin in TripleO's undercloud

[Ben Nemec]

On 02/03/2017 10:21 AM, Juan Antonio Osorio wrote:



On Fri, Feb 3, 2017 at 5:31 PM, Ben Nemec > wrote:



On 02/02/2017 06:27 PM, Juan Antonio Osorio wrote:

Hello,

I would like to request an FFE to properly support the novajoin
vendordata plugin in TripleO. Most of the work has landed,
however, we
still need to add it to TripleO's CI in order to have it officially
supported.

This is crucial for TLS-everywhere configuration's usability,
since it
makes it easier to populate the required field's in the CA
(which in our
case is FreeIPA). I'm currently working on a patch to add it to the
fakeha-caserver OVB job; which, after this is done, I hope to
move from
the experimental queue, to the periodic one.


I thought we had bumped TLS everywhere to next release.  Is there
still a use case for novajoin in Ocata?


Well, one can deploy most base services with TLS in the internal network
already. So one can actually try it out.


Okay, so to use a downstream-ism it's tech preview in Ocata and will be 
supported in Pike?


To be clear, I don't have any major objection to the FFE, I just want to 
understand the status of this work.


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

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

[Ken'ichi Ohmichi]

2017-02-03 9:56 GMT-08:00 Chris Dent :
> On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:
>>>
>>> In today's meeting [0] after briefly covering old business we spent
>>> nearly
>>> 50 minutes going round in circles discussing the complex interactions of
>>> expectations of API stability, the need to fix bugs and the costs and
>>> benefits of microversions. We didn't make a lot of progress on the
>>> general
>>> issues, but we did #agree that a glance issue [4] should be treated as a
>>> code bug (not a documentation bug) that should be fixed. In some ways
>>> this
>>> position is not aligned with the ideal presented by stability guidelines
>>> but
>>> it is aligned with an original goal of the API-WG: consistency. It's
>>> unclear
>>> how to resolve this conflict, either in this specific instance or in the
>>> guidelines that the API-WG creates. As stated in response to one of the
>>> related reviews [5]: "If bugs like this don't get fixed properly in the
>>> code, OpenStack risks going down the path of Internet Explorer and people
>>> wind up writing client code to the bugs and that way lies madness."
>>
>>
>> I am not sure the code change can avoid the madness.
>
>
> Just for the record, I'm not the speaker of that quote. I included
> it because I think it does a good job of representing the complexity
> and confusion that we have going on or at least in inspiring
> responses that help to do so.
>
> Which is a round about way of saying: Thank you very much for
> responding.

Haha, I see.

>> If we change the success status code (200 ->204) without any version
>> bumps, OpenStack clouds return different status codes on the same API
>> operations.
>> That will break OpenStack interoperability and clients' APPs need to
>> be changed for accepting 204 also as success operation.
>> That could make APPs code mudness.
>> I also think this is basically code bug, but this is hard to fix
>> because of big impact against the existing users.
>
>
> There have been lots of different opinions and perspective on this
> (in the reviews and elsewhere), all of which are pretty sensible but
> as a mass are hard to reconcile. The below is reporting evidence, not
> supporting a plan:
>
>   The API-WG is striving for OpenStack APIs to be consistent within
>   themselves, with each other and with the HTTP RFCs. This particular
>   issue is an example where none of those are satisfied.
>
> Yet it is true that if client code is specifically looking for a
> 200 response this change, without a version signal, will break
> that code.
>
>   But glance isn't set up with microversions or something like.
>
>   But isn't checking specifically for 200 as "success" unusual so
>   this is unlikely to be as bad as changing a 4xx to some other
>   4xx.
>
>   But correcting the docs so they indicate this one request out of
>   several in a group breaks the 204 pattern set by the rest of
>   the group and could easily be perceived as a typo and thus need
>   to be annotated as "special".
>
> How do we reconcile that?

This API has been implemented since 2 years ago, and it is easy to
imagine many users are using the API.
If changing success status code like this, we send a message "status
code could be changed anytime" to users and users would recognize "the
success status code is unstable and it is better to check status code
range(20X) instead of a certain code(200, 201, etc) for long-term
maintenance".

If the above is we expect/hope, why should we fix/change success code
to ideal one?
On the above scenario, we are expecting users should not check a certain code.
So even if changing status code, users would not be affected by the change.
Whom we are changing the status code for?
That seems a dilemma.

Thanks
Ken Ohmichi

---

> Some opinions of my own:
>
> I worry that we're making it ever harder to fix bugs and technical
> debt in many areas of OpenStack. Sure, there are very good reasons
> for the constraints we build in, but how much tech debt are we
> making ourselves carry? We have the versioning concepts to help (for
> those projects that use them) but we haven't yet agreed how to
> cleanly deprecate past stuff or even if we can or should.
>
> I don't feel too bad about that worry, because I know there are
> plenty of people who worry about other things that balance it out
> for a reasonable compromise.
>
>
> --
> 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 Development Mailing List (not for usage questions)

[openstack-dev] [nova] nova 15.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for nova for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/

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

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

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/ocata

Release notes for nova can be found at:

http://docs.openstack.org/releasenotes/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] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Steve Lewis]

On Fri, Feb 3, 2017 at 5:33 AM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> I’d like to propose Marc Gariepy [1] as a core reviewer for
> OpenStack-Ansible.
>

+1.
-- 
SteveL
__
OpenStack Development Mailing 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] Config option cleanup burndown

[Matt Riedemann]

This is sort of a direct question to Markus, but how accurate is this 
burndown chart now?


http://45.55.105.55:8082/config-options.html

I think there is still work for this in Pike, but would like to get an 
idea of how much of the work is left from those more involved (maybe 
johnthetubaguy or sfinucan can respond to that?).


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] [ironic] New mascot design

[Clint Byrum]

I'm only barely an Ironic contributor these days, but what about having
the bear do David Lee Roth's famous jump?

http://www.vhnd.com/wp-content/uploads/2015/01/kick_fb.jpg

Doesn't require props, and no hand gestures.

Alternatively, you could have the bear playing air guitar... if that can
be captured in the level of detail the logos allow.

Excerpts from Mathieu Mitchell's message of 2017-02-02 13:21:06 -0500:
> Oh...
> 
> I'm with the group here.
> 
> Let's find something that looks nice and is not offensive to anyone.
> 
> Mathieu
> 
> On 2017-02-02 11:52 AM, Jay Faulkner wrote:
> > https://en.wikipedia.org/wiki/Sign_of_the_horns came up in IRC, as the sign 
> > the bear is making. Obviously to me, I read it as the heavy metal gesture. 
> > Apparently it is offensive in some cultures, so I change my vote to -1, 
> > since I don’t want to offend folks in other parts of the world :).
> >
> > -Jay
> >
> >> On Feb 1, 2017, at 12:38 PM, Jay Faulkner  wrote:
> >>
> >> Of the options presented, I think the new 3.0 version most brings to mind 
> >> a rocking bear.  It’s still tough to be OK with a new logo, given that 
> >> pixie boots is beloved by our team partially because Lucas took the time 
> >> to make us one — but it seems like not accepting a new logo created by the 
> >> foundation would lead to Ironic getting less marketing and resources, so 
> >> I’m not keen to go down that path. With that in mind, I’m +1 to version 
> >> 3.0 of the bear.
> >>
> >> -Jay
> >>
> >>> On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway  
> >>> wrote:
> >>>
> >>> Hi Ironic team,
> >>>
> >>> I’m sorry our second proposal again missed the mark. It wasn’t the 
> >>> illustrator’s intention to mimic the Bear Surprise painting that gained 
> >>> popularity in Russia as a meme. Our illustrator created a face-forward 
> >>> bear with paws shaped as if it had index and ring “fingers" down, like a 
> >>> hand gesture popular at a heavy metal concert. It was not meant to mimic 
> >>> the painting of a side-facing bear with paws and all “fingers" up to 
> >>> surprise. That said, once it’s seen, it’s tough to expect the community 
> >>> to un-see it, so we’ll take another approach.
> >>>
> >>> The issue with your old mascot is twofold: it doesn’t fit the 
> >>> illustration style for the entire suite of 60+ mascots, and it contains a 
> >>> human-made element (drumsticks). As part of our overall guidelines, 
> >>> human-made objects and symbols were not allowed, and we applied these 
> >>> standards to all projects.
> >>>
> >>> Your team told us you want a heavy metal bear, so we used the Kiss 
> >>> band-style makeup and the hand gesture to suggest metal without using an 
> >>> instrument or symbol. We tried to mimic your original logo’s expression. 
> >>> After releasing v1, we listened to your team’s comment that the first 
> >>> version was too angry looking, so you’ll see a range of expressions from 
> >>> fierce to neutral to happy.
> >>>
> >>>
> >>> 
> >>> I’d love to find a compromise with your team that will be in keeping with 
> >>> the style of the project logo suite. I’ll watch your ML for additional 
> >>> concerns about this proposed v3:
> >>> 
> >>>
> >>> Our illustration team’s next step is to parse the community feedback from 
> >>> the Ironic team (note that there is a substantial amount of conflicting 
> >>> feedback from 21 members of your team) and determine if we have majority 
> >>> support for a single direction.
> >>>
> >>> While new project logos are optional, virtually every project asked be 
> >>> represented in our family of logos. Only logos in this new style will be 
> >>> used on the project navigator and in other promotional ways.
> >>>
> >>> Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
> >>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
> >>> Or iPhone one-tap (US Toll): +16465588656,5038169769# or 
> >>> +14086380968,5038169769#
> >>> Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
> >>> Meeting ID: 503 816 9769
> >>> International numbers available: 
> >>> https://zoom.us/zoomconference?m=E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> Heidi Joy Tretheway
> >>> Senior Marketing Manager, OpenStack Foundation
> >>> 503 816 9769 | Skype: heidi.tretheway
> >>>
> >>>
> >>>
> >>>
> >>> __
> >>> OpenStack Development Mailing 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
> >> 

[openstack-dev] [nova] placement/resource providers update 10

[Chris Dent]

It's been a busy week and it is getting into my Friday evening, so
I'm not sure I can adequately summarize where things are in the
universe of resource providers and the placement API, so instead I'm
going to give a bit of summary of what we managed get into Ocata.

The effective summary is that we hit the main goal of getting the
nova-scheduler limiting the hosts it will filter by requesting a set
of resource providers from the placement API. This was not without
several difficulties, mostly dealing with ensuring safe upgrades.
The end result is that the scheduler will check to see that all
compute nodes are Ocata. If they are then limiting via the placement
API will happen. Otherwise the old method will be used.

The above may sound small, but an enormous amount of work happened,
especially in the last two weeks to catch lots of problems (big and
small), clear out confusions, and get things working with CI and a
variety of deployment scenarious. Thanks to everyone who helped out.

The concept of custom resource classes now exists in the placement
API but the work to have the resource tracker use it to track Ironic
inventory in a sensible fashion at

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

is not likely to be included in Ocata. There's hope that some
mid-cycle jiggery pokery can be done to make it meaningfully
available in Pike.

Testing of all this stuff exposed a fairly significant bug when
compute nodes are deleted. This is fixed by

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

I mention it here not because it was the only bug found (not in the
slightest) but because the discussion surrounding it (and trying to
understand the custom resource class changes) suggested there is a
lot we could and should be doing to clear up not just the code in
the compute manager and its resource tracker friend but also our
human understanding of that code[1]. We also know from

http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html

that sometimes the resource tracker is duplicating work more than we
might like, resulting in excessive requests to the placement API.

A main action from the discussions surrounding that confusion was
that we need much more complete functional (and probably integration
too, but the emphasis is on functional for the sake of developer
oriented short feedback loops) testing of the compute manager and
resource tracker, including stuff that exercises Ironic.  Which
leads to...

What's Next
===

Besides fixing bugs that are going to come rolling in we've got:

* Evaluating and as necessary tidying up the many rushed fixes that
  we made there at the end.
* Adding the more complete functional testing.
* Building the scheduling side of the ironic custom resource classes
  (flavor extra_spec?) and fun things like
  "hash ring + placement-based scheduling + host aggregates / AZs"
* Making use of the aggregate map that the resource tracker now has.
* Figuring out how to make more effective use of tracked_instances
  dict in resource tracker.
* Making progress on the plan for making resource requests and claims
  simultaneously via the placement API.
* Nested resource providers.
* Resource traits.
* All the extra bits that people are working on or thinking about
  that usually show up in these reports.

Next week I will endeavor to gather enough information to make these
messages something actionable again. In the meantime thanks and
congrats to everyone for pushing things forward.

[1] This is probably a universal truth of any code, so perhaps
redundant to mention.

--
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] [nova] Moving long-running efforts to Pike

[Matt Riedemann]

We have a few multi-release efforts going on in Nova and we've had 
release-specific blueprints to track those. Since Ocata is closed for 
those now, I've started created blueprints for Pike so people can target 
their remaining (and new) changes at the Pike blueprint.


Those would be:

https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-pike

https://blueprints.launchpad.net/nova/+spec/centralize-config-options-pike

https://blueprints.launchpad.net/nova/+spec/remove-mox-pike

https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-pike

--

The py35 support work will continue in this blueprint in Pike:

https://blueprints.launchpad.net/nova/+spec/goal-python35

That's because the community is going to use that same blueprint/topic 
branch name in Pike:


https://governance.openstack.org/tc/goals/pike/python35.html#gerrit-topic

So it's fine to just continuing on that one.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Config option cleanup burndown

[Singh, Sarafraj]

Matt,
This chart is quite accurate. We are almost finished with this work. We have 
~10 outstanding patches that did not land in Ocata. There are few more TODO’s 
left in the code to clean up and that should be it.

-Raj

On 2/3/17, 2:08 PM, "Matt Riedemann"  wrote:

This is sort of a direct question to Markus, but how accurate is this 
burndown chart now?

http://45.55.105.55:8082/config-options.html

I think there is still work for this in Pike, but would like to get an 
idea of how much of the work is left from those more involved (maybe 
johnthetubaguy or sfinucan can respond to that?).

-- 

Thanks,

Matt Riedemann


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


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

Re: [openstack-dev] [nova] Config option cleanup burndown

[Szankin, Maciej]

On 2/3/17 2:26 PM, Singh, Sarafraj wrote:
> Matt,
> This chart is quite accurate. We are almost finished with this work. We have 
> ~10 outstanding patches that did not land in Ocata. There are few more TODO’s 
> left in the code to clean up and that should be it.
>
> -Raj
>
> On 2/3/17, 2:08 PM, "Matt Riedemann"  wrote:
>
> This is sort of a direct question to Markus, but how accurate is this 
> burndown chart now?
> 
> http://45.55.105.55:8082/config-options.html
> 
> I think there is still work for this in Pike, but would like to get an 
> idea of how much of the work is left from those more involved (maybe 
> johnthetubaguy or sfinucan can respond to that?).
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing 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
>
It is up-to-date for the categories/tags that it tracks, but there is
still a bit more underneath - there are few TODOs left in comments that
still require resolving, but we are close. I did not decide to put a
burndown chart up for them as there can be multiple reviews per file and
the whole thing can be messy. We have an etherpad [0] that tries to keep
track of every work item that is left for this bp. TODOs are up-to-date,
deprecation list requires an update (which I will do this evening or
Monday morning).

There are 50 TODOs left in code (10 [it is not a 1-1 relation, this is a
coincidence] of them resolved in outstanding patches that Raj
mentioned), so it leaves 40 to resolve. Some of them are invalid, as the
code base has changed infinite number of times during this release, so I
have a WIP patch that tries to remove all no longer valid TODOs.

[0] https://etherpad.openstack.org/p/config-options

Cheers,
macsz


__
OpenStack Development Mailing 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] [ironic] New mascot design

[Rochelle Grober]

Well, uh, how about Jazz hands?  Open, waving hands are pretty universally 
friendly and it would look more like a dancing bear which brings the music 
aspect bac a bit.

Sorry for butting in, but I couldn resist...

--Rocky

-Original Message-
From: Miles Gould [mailto:mgo...@redhat.com] 
Sent: Friday, February 03, 2017 10:30 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] New mascot design

On 02/02/17 16:55, Loo, Ruby wrote:
>  I guess a 'peace sign' wouldn't work?

That also has several meanings:

https://en.wikipedia.org/wiki/V_sign

On the other hand, the palm-forward version has no offensive meanings that I 
can see (the offensive version is palm-backwards).

I like the proposed logo v3.0, but I could get behind a version 3.1 in which 
the bear was flashing a peace/victory sign.

Miles

__
OpenStack Development Mailing 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] [oslo][oslo.db] MySQL Cluster support

[Octave J. Orgeron]

Comments below..

On 2/3/2017 8:34 AM, Mike Bayer wrote:



On 02/03/2017 10:21 AM, Doug Hellmann wrote:

Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:


On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:

That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.

A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns 
types

that are vastly oversized such as status and attach_status, which by
default are 255 chars.



let me give you a tip on IF blocks, that they are a bit of an
anti-pattern.  If you want a column type to do one thing in one case,
and another in another case, create an object that does the thing 
you want:



some_table = Table(
 'some_table', metadata,
 Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)


I wonder if we want to do either, though. Shouldn't we try to use
the same (smaller) column size all the time? Otherwise we end up
with another incompatibility between different deployments, since
sometimes things like names might have different sizes in different
clouds.


in that case you have to do a migration which as you know these days 
means the "old" column remains for a whole release cycle and the 
application must undergo significant complexity, either at the app 
level or in triggers, to keep data between "old" and "new" columns 
simultaneously.   So one advantage to keeping this at the "create for 
NDB" level is that we don't need to get into schema migrations.


Unless we changed the value in the application and its migration files 
completely, and *didnt* migrate old applications, and just hope/ensure 
that they aren't writing larger data values.   Maybe that's possible 
though it seems a little scary.   Perhaps some kind of annotated type 
like VARCHAR(50, unmigrated=255) to note what's going on.





This is one of the things that I worried about and why I took the 
approach of doing the logic for NDB and keeping the default logic there 
based on the mysql_storage_engine setting. Perhaps it makes sense to do 
things this way first and then in a future release do the migrations of 
the column sizes and types as a second phase. Then as a third phase we 
can remove the column size and type logic changes? At that point, the 
only real change left will be the substitution of the 
"mysql_engine=InnoDB" with a value that we could abstract from somewhere 
(oslo.db or a dialect stub).


As for the foreign key, constraints, and index ordering, it's good 
practice to do things in the right order and doesn't impact any 
functionality in InnoDB. So that's actually a plus that I'll fix those 
with my patches.


Then that will just leave the logic for dealing with savepoints and 
nested operations. Then when NDB adds those features, we can drop that 
logic down the road.








I think we might want to look into creating a stub dialect called 'ndb'
that subclasses mysql+pymysql.   Treating ndb as a whole different
database means there's no longer the need for a flag in oslo.db, the
'ndb' name would instead be interpreted as a new backend - the main
thing would be ensuring all the mysql-appropriate hooks in oslo.db are
also emitted for ndb, but this also gives us a way to pick and choose
which hooks apply.   It seems like there may be enough different about
it to separate it at this level.

Not sure if people on the list are seeing that we are simultaneously
talking about getting rid of Postgresql in the efforts to support only
"one database", while at the same time adding one that is in many 
ways a

new database.


Yes, that does seem a bit ironic. That's also why I was pointing
out that we're going to want to have people lined up to support the
work before starting. The lack of help with Postresql testing
resulted in removing it from the gate, and possibly to dropping
support entirely.

For reference, the discussion in [1] led to this proposed TC
resolution [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111357

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






So to determine a more appropriate size, I look

through the Cinder code to find where the possible options/states are
for those columns. Then I cut it down to a more reasonable size. I'm
very careful when I cut the size of a string column to ensure that all
of the possible values can be contained.

In cases where a column is extremely large for capturing the 
outputs of

a command, I will change the type to Text or TinyText depending on the
length required. A good example of this is in the agents table of
Neutron where there is a column for configurations that has a string
length of 4096 characters, which I change to Text. Text blobs are 
stored

differently and do not count against the row length.

I've also observed differences between Kilo, Mitaka, and tip where 
even
for InnoDB some of these tables are getting wider than can 

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Doug Hellmann]

Excerpts from Octave J. Orgeron's message of 2017-02-03 09:54:53 -0700:
> Comments below..
> 
> On 2/2/2017 6:22 PM, Doug Hellmann wrote:
> >> Yes, this is major undertaking and major driver for Oracle to setup a
> >> 3rd party CI so that we can automate regression testing against MySQL
> >> Cluster. On the flip side, it helps solve some of the challenges with
> > I'm not sure we would want to gate projects on CI run outside of
> > our infrastructure community. We've had some bad experiences with
> > that in the past. What are the options for running MySQL Cluster
> > on nodes upstream?
> 
> It shouldn't be too bad to setup MySQL Cluster. I haven't worked with 
> the CI infrastructure upstream. What would it take to get it configured?

You'll need to approach the infrastructure team (#openstack-infra, or
here on the list) about that.

> >> larger deployments where an active/passive solution for MySQL DB is not
> >> sufficient. So the pay-off is pretty big from an availability and
> >> scale-out perspective.
> >>
> >> But I do realize that I'll have to maintain this long-term and hopefully
> >> get others to help out as more services are added to OpenStack.
> > Given the scope of the work being proposed, and the level of expertise
> > needed to do it, we're going to need to have more than one person
> > available to debug issues before we go to far ahead with it.
> >
> > It might help to have an example or two of the sorts of migration
> > script changes you've described elsewhere. Maybe you can prepare a
> > sample patch for a project?
> >
> > Are there tools that can look at a table definition and tell if it
> > meets the criteria for the cluster backend (the row size, types
> > used, whatever else)? Or is it something one has to do by hand?
> 
> I'm working on updating my keystone patches and will put that up for 
> review early next week. I'll send the link for that. Then I'll work on 
> cinder next. So those two should provide good examples of what the 
> patches look like.

That should help.

> 
> I've been doing things by hand, but I think a tool could be developed.
> 
> > So what do you envision that I'll have to add to the oslo.db library to
> > make things work as you describe? What would be the best example for me
> > to build from?
> > You need a function that takes the cfg.CONF instance as an argument. It
> > should call register_opts() to register the option or options it uses,
> > and then it can return the value. Something like:
> >
> > from oslo_db import options
> >
> > def get_db_engine_type(conf):
> >  conf.register_opts(options.database_opts)
> > return conf.database.mysql_storage_engine
> 
> I'll work on this and submit an update to the patch for oslo.db.
> 
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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

Re: [openstack-dev] [ux] Future of the OpenStack UX team

[Thierry Carrez]

Shamail wrote:
> Hi Thierry,
> 
>> On Jan 31, 2017, at 7:10 AM, Thierry Carrez  wrote:
>>
>> Shamail wrote:
 Sorry for not noticing this thread and replying earlier.

 I've now reviewed the minutes from the meeting, and I support thingee's 
 suggestion of having a UX working group. This way, UX can get the 
 attention it rightly deserves. Without the research and guidelines 
 provided by the UX team, user-facing projects (such as Docs) will be 
 poorer. I believe that it's in Foundations best interests to ensure that 
 UX work is ongoing, and adequately supported, in the same way as Marketing 
 and other user outreach services. 
>>> +1

 I am happy to work with Foundation (on behalf of the Docs team) to 
 determine how this would work in practice.
>>> I'm happy to help as well.  The Product working group recently started 
>>> using Personas in our user stories and I also participated in the Personas 
>>> workshop with the UX team.
>>
>> This working group will need a driver/leader/steward to set up at least
>> the first meetings and see who would be ready to do what in UX land.
>>
>> Any volunteer ?
> I'll be glad to schedule the initial discussions/meetings to determine our 
> refined scope and to identify participants.  I think the team will have a 
> quorum to continue the persona and research work but we will need to find if 
> there are people in the community with actual UX design experience that are 
> willing to also participate.  Does the TC envision this as a UC or TC 
> governed WG?  I'll submit the patches according to your response.

We don't really have a process to vet for workgroups on the TC side
(they just form organically). It feels like a group that could straddle
both sides. If you think it would help the group to be formally
recognized as a UC workgroup, please go ahead and create it.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Octave J. Orgeron]

Comments below..

On 2/2/2017 6:22 PM, Doug Hellmann wrote:

Yes, this is major undertaking and major driver for Oracle to setup a
3rd party CI so that we can automate regression testing against MySQL
Cluster. On the flip side, it helps solve some of the challenges with

I'm not sure we would want to gate projects on CI run outside of
our infrastructure community. We've had some bad experiences with
that in the past. What are the options for running MySQL Cluster
on nodes upstream?


It shouldn't be too bad to setup MySQL Cluster. I haven't worked with 
the CI infrastructure upstream. What would it take to get it configured?





larger deployments where an active/passive solution for MySQL DB is not
sufficient. So the pay-off is pretty big from an availability and
scale-out perspective.

But I do realize that I'll have to maintain this long-term and hopefully
get others to help out as more services are added to OpenStack.

Given the scope of the work being proposed, and the level of expertise
needed to do it, we're going to need to have more than one person
available to debug issues before we go to far ahead with it.

It might help to have an example or two of the sorts of migration
script changes you've described elsewhere. Maybe you can prepare a
sample patch for a project?

Are there tools that can look at a table definition and tell if it
meets the criteria for the cluster backend (the row size, types
used, whatever else)? Or is it something one has to do by hand?


I'm working on updating my keystone patches and will put that up for 
review early next week. I'll send the link for that. Then I'll work on 
cinder next. So those two should provide good examples of what the 
patches look like.


I've been doing things by hand, but I think a tool could be developed.


So what do you envision that I'll have to add to the oslo.db library to
make things work as you describe? What would be the best example for me
to build from?
You need a function that takes the cfg.CONF instance as an argument. It
should call register_opts() to register the option or options it uses,
and then it can return the value. Something like:

from oslo_db import options

def get_db_engine_type(conf):
 conf.register_opts(options.database_opts)
return conf.database.mysql_storage_engine


I'll work on this and submit an update to the patch for oslo.db.




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



--

Oracle 
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure 

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Octave J. Orgeron]

Hi Mike,

It might be easier to reduce the size of certain columns today. We have 
an enormous amount of wasted space in the tables today. Reducing them 
would make things more efficient regardless of the database engine being 
used. On the flip side, if we were using SQL Alchemy properly and not 
hard coding SQL statements, we could make the database back-end more 
agnostic. It would be a major project to fix this across all of the 
services today, but that may be the right thing to do in the long term. 
InnoDB has it's own scaling issues and at some point a larger shop 
(telco or cloud provider) will want other options.


Thanks,
Octave

On 2/3/2017 8:16 AM, Roman Podoliaka wrote:

On Fri, Feb 3, 2017 at 4:41 PM, Mike Bayer  wrote:

Not sure if people on the list are seeing that we are simultaneously talking
about getting rid of Postgresql in the efforts to support only "one
database", while at the same time adding one that is in many ways a new
database.

++

and, FWIW, moving columns between tables and changing of column types
in order to make NDB storage engine happy both seem to be a way more
intrusive than what we've had to do so far in the code of OpenStack
projects in order to support PostgreSQL.

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



--

Oracle 
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure 

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


__
OpenStack Development Mailing 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] Large Contributing OpenStack Operators working group?

[Dean Troyer]

On Fri, Feb 3, 2017 at 8:28 AM, Sean M. Collins  wrote:
> I suppose I am also philosophically opposed to having all these special
> snowflake working groups. If you want to get things done in OpenStack
> the best thing to do is roll up your sleeves and start participating
> directly in the project where you need work done. I know for a fact that
> in the Neutron community, we had RFE bugs and other processes so that
> operators could submit requirements, and they weren't expected to do all
> the work by themselves.

I read through the LCOO[0] etherpad meeting notes last night and it
does appear that this group is bringing some resources to "do work",
there was a 2 FTE per member requirement initially.  From reading the
notes I got the feel of a very corporate-style project in that there
is still a lot of planning and organizing going on but there were
notes pointing to things being proposed and merged into existing
projects in addition to the aspirations of new ones.

My primary concern in this instance is the model being used here.  The
members of the group want to control the scope (approval to add a
topic) and membership (justification and approval of members).  Often
this is done to prevent scope creep and maintaining focus.  But it
contrary to the founding principles of OpenStack.  The notes talked
about getting Foundation buy-in but I didn't see anything of the
outcomes of that.

LCOO also appears to be a collection of companies that have brought
some internal projects out into the twilight (searching for sunlight?)
and looking for a way to upstream that work.  Even today many
companies that have names familiar in the Open Source/Free Software
world struggle with how to actually operate in this world.  We need to
help them, both from the community side and from within.

I do think there needs to be a lot of encouragement for LCOO and other
groups that are actually more like trade associations to fully commit
to an open development model, specifically OpenStack's established
model since there is an explicit desire for their work product to be
included in OpenStack directly. They will greatly benefit form
starting out in our development and operation style.

[[There is another entirely separate subject regarding the direction
that LCOO wants to go and the sustainability in making a single
OpenStack fit all sizes and types of deployments.  I'll leave that for
$SUMMIT_COLD_BEVERAGE conversations for now.]]

dt

[0] Am I the only one who simply can not read 'LCOO' as anything other
than 'loco'? :)

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Octave J. Orgeron]

Hi Mike,

Comments below..

Thanks,
Octave

On 2/3/2017 7:41 AM, Mike Bayer wrote:



On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:

That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.

A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_status, which by
default are 255 chars.



let me give you a tip on IF blocks, that they are a bit of an 
anti-pattern.  If you want a column type to do one thing in one case, 
and another in another case, create an object that does the thing you 
want:



some_table = Table(
'some_table', metadata,
Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)


I think we might want to look into creating a stub dialect called 
'ndb' that subclasses mysql+pymysql.   Treating ndb as a whole 
different database means there's no longer the need for a flag in 
oslo.db, the 'ndb' name would instead be interpreted as a new backend 
- the main thing would be ensuring all the mysql-appropriate hooks in 
oslo.db are also emitted for ndb, but this also gives us a way to pick 
and choose which hooks apply. It seems like there may be enough 
different about it to separate it at this level.


Not sure if people on the list are seeing that we are simultaneously 
talking about getting rid of Postgresql in the efforts to support only 
"one database", while at the same time adding one that is in many ways 
a new database.





This is an interesting approach as it would significantly reduce the 
amount of code in my patches today. Do you have any pointers on where 
this should be implemented as a stub? Would we have to take different 
approaches for SQL Alchemy vs. Alembic?



--

Oracle 
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure 

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


__
OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Jeremy Stanley]

On 2017-02-03 11:12:04 +0100 (+0100), Miguel Angel Ajo Pelayo wrote:
[...]
> So, would it be realistic to bump the flavors RAM to favor our stability in
> the short term? (considering that the less amount of workload our clouds
> will be able to take is fewer, but the failure rate will also be fewer, so
> the rechecks will be reduced).

It's an option of last resort, I think. The next consistent flavor
up in most of the providers donating resources is double the one
we're using (which is a fairly typical pattern in public clouds). As
aggregate memory constraints are our primary quota limit, this would
effectively halve our current job capacity.
-- 
Jeremy Stanley

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

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 5 - for real now)

[Attila Darazs]

As always, if these topics interest you and you want to contribute to 
the discussion, feel free to join the next meeting:


Time: Thursdays, 15:30-16:30 UTC
Place: https://bluejeans.com/4113567798/

Note: last two weeks I used the incorrect week number. Getting back on 
track, this is the 5th week of 2017.


Yesterday's meeting focused almost entirely on figuring out what's the 
"feature delta" between the current TripleO CI and the functionality of 
our Quickstart based CI. In the spirit of aviation we call this 
"preflight checklist"[1].


It contains:

* the various variables that turn functionality on and off in upstream tests

* a short description of the variables

* a "Quickstart" section for each, describing if it's supported or not 
currently. If yes, usually there's a link at the respective part, if 
not, we add a Trello card to track the work, or a bug if we plan to take 
care of it a bit later


* proposed new Quickstart jobs, where we combine the existing features 
into fewer jobs with same coverage


* the existing upstream jobs with the features they currently cover

If you're somewhat familiar with the current CI system, please look over 
these and let us know if there's any mistake in it.


Other than this, the new nodepool and OVB Quickstart jobs are working, 
apart from the OVB HA job -- Sagi is working on it.


I'm not sure the link for the checklist is accessible for everyone, so 
I'm going to paste it here after the link. Probably the formatting is 
not perfect, so if you can, check the google doc.


Best regards,
Attila

[1] 
https://docs.google.com/document/d/1Mb_t5Qe-Lnh0uaXy0ubX9y4k65Q4D_aw-49eZOqoviQ/edit?pli=1#


---

TripleO CI Quickstart Transition

Preflight Checklist - All the items must be ready by 10th March



This document describes:

* Existing features in the current TripleO CI

* Their support in Quickstart

* The current CI job feature sets (what features are tested in specific 
jobs)


* The new proposed job feature sets (to reduce the amount of jobs while 
keeping the same coverage)


Feature index





Each list item represents a “toci_gate_test.sh” variable that 
enable/disable features in the CI jobs.




* 1-CONTROLLER

   * Use 1 controller (and maybe other type of nodes)

   * Quickstart: supported

* 3-CONTROLLERS

   * Use 3 controllers (and maybe other type of nodes)

   * Quickstart: supported

* 1-COMPUTE

   * Use 1 compute node (and maybe other type of nodes)

   * Quickstart: supported

* 1-CEPH

   * Use 1 ceph node (and maybe other type of nodes)

   * Quickstart: supported

* CONTAINERS

   * Container based undercloud (feature under development)

   * Container based overcloud

   * Quickstart: supported (undercloud in progress)[a]

* DISABLE_IRONIC

   * This is just a label that denotes the ability to skip ironic steps 
entirely during multinode based jobs


   * Quickstart: not needed, implemented elsewhere

* DELOREAN_HTTP_URLS

   * We can't use squid to cache https urls, so don't use them

   * Quickstart: make sure we use only http in build-test-package [card]

* IRONIC_DRIVERS_DEPLOY_HTTPPORT

   * sets http port unconditionally to 
ironic::drivers::deploy::http_port: 3816 in undercloud overrides


   * Quickstart: not supported [card]

* IMAGE_CACHE_SELECT

   * This feature enables to select whether or not using an image from 
cache when gating specific project (i.e. projects that alter the image 
creation process)


   * TODO(gcerami) propose a change to unify the list of project for 
every image to build (specific project gated -> all images will be 
recreated from scratch)


   * Quickstart: work in progress (trown, image build role) [card]

* IMAGE_CACHE_UPLOAD

   * Ability to promote image, uploading it to the image cache server

   * We can leave the current implementation in bash, but work on which 
job type combination will activate the upload


   * Quickstart: not needed, can be handled up the current script

* INTROSPECT

   * perform overcloud nodes introspection

   * Quickstart: supported, but we are still performing bulk 
introspection while we should use new format as in 
http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/scripts/tripleo.sh#n608 
instead of 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2#L90


   * [card]

* METRICS

   * Tripleo ci is sprinkled with metric sections, surrounded with 
start_metric - stop_metric primitives that gather section duration 
informations throughout various steps of the deployment. (they really 
just set timers). This metrics are then sent to graphite host for graph 
rendering at the end of the run


   * Quickstart: not needed

* MULTINODE_SETUP

* MULTINODE_NODES_BOOTSTRAP

   * multiple nodes are consumed from openstack nodes pool

   * A setup to create a network between nodepool nodes is needed

   * All nodes must contain proper nodepool configurations in /etc/nodepool

   * 

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

[Chris Dent]

On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:

2017-02-02 9:38 GMT-08:00 Chris Dent :


Greetings OpenStack community,

In today's meeting [0] after briefly covering old business we spent nearly
50 minutes going round in circles discussing the complex interactions of
expectations of API stability, the need to fix bugs and the costs and
benefits of microversions. We didn't make a lot of progress on the general
issues, but we did #agree that a glance issue [4] should be treated as a
code bug (not a documentation bug) that should be fixed. In some ways this
position is not aligned with the ideal presented by stability guidelines but
it is aligned with an original goal of the API-WG: consistency. It's unclear
how to resolve this conflict, either in this specific instance or in the
guidelines that the API-WG creates. As stated in response to one of the
related reviews [5]: "If bugs like this don't get fixed properly in the
code, OpenStack risks going down the path of Internet Explorer and people
wind up writing client code to the bugs and that way lies madness."


I am not sure the code change can avoid the madness.


Just for the record, I'm not the speaker of that quote. I included
it because I think it does a good job of representing the complexity
and confusion that we have going on or at least in inspiring
responses that help to do so.

Which is a round about way of saying: Thank you very much for
responding.


If we change the success status code (200 ->204) without any version
bumps, OpenStack clouds return different status codes on the same API
operations.
That will break OpenStack interoperability and clients' APPs need to
be changed for accepting 204 also as success operation.
That could make APPs code mudness.
I also think this is basically code bug, but this is hard to fix
because of big impact against the existing users.


There have been lots of different opinions and perspective on this
(in the reviews and elsewhere), all of which are pretty sensible but
as a mass are hard to reconcile. The below is reporting evidence, not
supporting a plan:

  The API-WG is striving for OpenStack APIs to be consistent within
  themselves, with each other and with the HTTP RFCs. This particular
  issue is an example where none of those are satisfied.

Yet it is true that if client code is specifically looking for a
200 response this change, without a version signal, will break
that code.

  But glance isn't set up with microversions or something like.

  But isn't checking specifically for 200 as "success" unusual so
  this is unlikely to be as bad as changing a 4xx to some other
  4xx.

  But correcting the docs so they indicate this one request out of
  several in a group breaks the 204 pattern set by the rest of
  the group and could easily be perceived as a typo and thus need
  to be annotated as "special".

How do we reconcile that?

Some opinions of my own:

I worry that we're making it ever harder to fix bugs and technical
debt in many areas of OpenStack. Sure, there are very good reasons
for the constraints we build in, but how much tech debt are we
making ourselves carry? We have the versioning concepts to help (for
those projects that use them) but we haven't yet agreed how to
cleanly deprecate past stuff or even if we can or should.

I don't feel too bad about that worry, because I know there are
plenty of people who worry about other things that balance it out
for a reasonable compromise.

--
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] [ironic] New mascot design

[Miles Gould]

On 01/02/17 01:28, arkady.kanev...@dell.com wrote:

I think Russian already owns the bear.


AIUI, trademark law allows for use of the same mark by different 
entities provided they operate in different enough spheres to prevent 
confusion. Hence the long-running litigation between Apple Music and 
Apple Computer. So I think we'd be OK using a bear as well.


For the record, I'd -1 a spec proposing statehood for Ironic.

Miles

__
OpenStack Development Mailing 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] [watcher] Watcher release v1.0.0

[Pradeep Singh]

Congratulations, +1 :)

On Fri, Feb 3, 2017 at 10:04 PM, Ed Leafe  wrote:

> On Feb 3, 2017, at 4:27 AM, Antoine Cabot 
> wrote:
>
> > I'm very proud to announce today the availability of Watcher in version
> 1.0.0.
>
> Congratulations!
>
>
> -- 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
>
__
OpenStack Development Mailing 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] [ironic] New mascot design

[Miles Gould]

On 02/02/17 16:55, Loo, Ruby wrote:

 I guess a 'peace sign' wouldn't work?


That also has several meanings:

https://en.wikipedia.org/wiki/V_sign

On the other hand, the palm-forward version has no offensive meanings 
that I can see (the offensive version is palm-backwards).


I like the proposed logo v3.0, but I could get behind a version 3.1 in 
which the bear was flashing a peace/victory sign.


Miles

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

[openstack-dev] [searchlight] searchlight-ui 2.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for searchlight-ui for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight-ui/

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

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

http://git.openstack.org/cgit/openstack/searchlight-ui/log/?h=stable/ocata

Release notes for searchlight-ui can be found at:

http://docs.openstack.org/releasenotes/searchlight-ui/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/searchlight

and tag it *ocata-rc-potential* to bring it to the searchlight-ui
release crew's attention.

__
OpenStack Development Mailing 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] Ocata blueprint burndown chart

[Matt Riedemann]

For those that like charts, I was keeping track of our progress with 
approving and then completing blueprints targeted to Ocata over the 
release. It's pretty unscientific. I basically had a spreadsheet with a 
cell per day and I'd just plug in numbers from launchpad based on the 
total number of targeted blueprints, the number that were approved (i.e. 
spec was merged) and when they were completed. I also had milestone 
markers in there for reference.


The resulting chart is here [1].

Some observations:

- There is an obvious correlation between ramping up targeted 
blueprint/specs and approving them toward the spec freeze with a jump at 
the end. That shouldn't be a surprise.


- We started getting more approved blueprints merged/completed after the 
spec freeze, but the rate on that was still very low until about 
January. The spec freeze was on November 17th so it's not terribly 
surprising to me that even after that, completion rates were slow until 
January since we were hitting the end of the year when a lot of people 
were taking time off for holidays.


- We had a blueprint code review sprint on January 11th at which point 
completed blueprints spiked up a bit. After that it was a dash to 
feature freeze.


- Just a general note that the targeted/approved lines drop off and meet 
the completed line at the end due to me deferring blueprints that didn't 
make Ocata.


- At the peak we had 78 targeted blueprints and 70 approved blueprints. 
That's less than Newton but Ocata was also a shorter cycle and we had 
fewer resources on hand for reviews in this release. Comparing final 
numbers to Newton, we had 47 completed or partially completed blueprints 
in Ocata compared to 64 in Newton (at one point we had 100 approved 
blueprints for Newton too I think). So rate-wise those releases were 
about the same (67% completed in Ocata vs 64% completed in Newton). And 
really, that's surprising to me personally given we had pretty much 3 
less major nova core reviewers in Ocata (danpb, alaski and sdague).


I haven't fully digested this all yet, or really had too much time to 
reflect on it in detail because this has been a hectic past few weeks.


We'll do a retrospective for Ocata like we did for Newton and go through 
that at the PTG.


I just wanted to get this chart out as it's something I've been tracking 
for the past 5 months and I'm happy to finally post it.


[1] 
https://docs.google.com/spreadsheets/d/1Wt7IrSTzSOgC7683FtpjWgYY7lZCHxslYGFUZlpnljI/pubhtml?gid=128173249=true


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] neutron-dynamic-routing 10.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for neutron-dynamic-routing for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-dynamic-routing/

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

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


http://git.openstack.org/cgit/openstack/neutron-dynamic-routing/log/?h=stable/ocata

Release notes for neutron-dynamic-routing can be found at:

http://docs.openstack.org/releasenotes/neutron-dynamic-routing/



__
OpenStack Development Mailing 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] networking-ovn 2.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for networking-ovn for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-ovn/

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

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

http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/ocata

Release notes for networking-ovn can be found at:

http://docs.openstack.org/releasenotes/networking-ovn/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-ovn

and tag it *ocata-rc-potential* to bring it to the networking-ovn
release crew's attention.

__
OpenStack Development Mailing 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] [ux] Future of the OpenStack UX team

[Shamail]

> On Feb 3, 2017, at 2:16 PM, Thierry Carrez  wrote:
> 
> Shamail wrote:
>> Hi Thierry,
>> 
>>> On Jan 31, 2017, at 7:10 AM, Thierry Carrez  wrote:
>>> 
>>> Shamail wrote:
> Sorry for not noticing this thread and replying earlier.
> 
> I've now reviewed the minutes from the meeting, and I support thingee's 
> suggestion of having a UX working group. This way, UX can get the 
> attention it rightly deserves. Without the research and guidelines 
> provided by the UX team, user-facing projects (such as Docs) will be 
> poorer. I believe that it's in Foundations best interests to ensure that 
> UX work is ongoing, and adequately supported, in the same way as 
> Marketing and other user outreach services. 
 +1
> 
> I am happy to work with Foundation (on behalf of the Docs team) to 
> determine how this would work in practice.
 I'm happy to help as well.  The Product working group recently started 
 using Personas in our user stories and I also participated in the Personas 
 workshop with the UX team.
>>> 
>>> This working group will need a driver/leader/steward to set up at least
>>> the first meetings and see who would be ready to do what in UX land.
>>> 
>>> Any volunteer ?
>> I'll be glad to schedule the initial discussions/meetings to determine our 
>> refined scope and to identify participants.  I think the team will have a 
>> quorum to continue the persona and research work but we will need to find if 
>> there are people in the community with actual UX design experience that are 
>> willing to also participate.  Does the TC envision this as a UC or TC 
>> governed WG?  I'll submit the patches according to your response.
> 
> We don't really have a process to vet for workgroups on the TC side
> (they just form organically). It feels like a group that could straddle
> both sides. If you think it would help the group to be formally
> recognized as a UC workgroup, please go ahead and create it.
Thanks Thierry.  I'll send a doodle poll next week to determine a new meeting 
time and who's interested in participating.
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron] neutron 10.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for neutron for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron/

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

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

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/ocata

Release notes for neutron can be found at:

http://docs.openstack.org/releasenotes/neutron/



__
OpenStack Development Mailing 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] neutron-fwaas 10.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for neutron-fwaas for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-fwaas/

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

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

http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/ocata

Release notes for neutron-fwaas can be found at:

http://docs.openstack.org/releasenotes/neutron-fwaas/



__
OpenStack Development Mailing 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] [barbican] barbican 4.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for barbican for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/barbican/

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

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

http://git.openstack.org/cgit/openstack/barbican/log/?h=stable/ocata

Release notes for barbican can be found at:

http://docs.openstack.org/releasenotes/barbican/



__
OpenStack Development Mailing 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] [Shaker] Shaker Image Builder fails in Ocata due to OS::Glance::Image deprecation

[Ilya Shakhat]

>
> Starting Ocata, looks like only glance v2 is enabled by default. This
> breaks the shaker image builder template since we make use of the resource
> type OS::Glance::Image and creating images from url links is not
> supported in v2. How do we want deal with this? Maybe have the user pass in
> the name/image-id and pass them as properties to the shaker image builder
> template or instead advise the use to turn on the v1 API?
> Thoughts/suggestions?
>
>
Looks like the only way to deal with that is to build the image manually
and then pass its name via --image-name parameter (or name the image
'shaker-image').

Thanks,
Ilya
__
OpenStack Development Mailing 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] FFE request for composable upgrades

[Emilien Macchi]

On Feb 3, 2017 5:26 AM, "Steven Hardy"  wrote:

Hi all,

There's been some discussion on IRC about this, but I wanted to formally
request a FFE for the remaining composable upgrades work and provide a
status update:

https://blueprints.launchpad.net/tripleo/+spec/overcloud-
upgrades-per-service

We've made pretty good progress on this, and the ansible based upgrade
architecture, along with tasks for most overcloud services has landed.

However we've been blocked for a while due to the complexity of upgrading
nova - some work was required to get puppet support for cellsv2, and to
figure out the required steps related to the placement API integration.

I think that's all close now, and folks have been testing locally with some
success:

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

The other missing piece is pacemaker support, which again has been locally
tested but not yet proven via CI:

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

The final part is deploying the upgrade script for operator driven upgrades
when automated upgrades are disabled (this is similar to previous releases,
but required some rework due to the new architecture):

https://review.openstack.org/#/c/424905/
https://review.openstack.org/#/c/419886/

There are also a few other various fixes and cleanups outstanding:

https://review.openstack.org/#/c/428309
https://review.openstack.org/#/c/428310/
https://review.openstack.org/#/c/428348/
https://review.openstack.org/#/c/428349/
https://review.openstack.org/#/c/424715/

I think that's all of the outstanding work, but we're still testing and
trying to flush out any remaining issues - if I've missed anything
hopefully other folks on the upgrades squad can follow up with more
details.

Overall I think this is OK for the final release, but we should aim to land
the patches above ASAP so we can focus on testing and any remaining
bugfixes.

Thanks!


Of course this is granted, as upgrades are essential to us.

Thanks for this outstanding work.
Emilien.


--
Steve Hardy
Red Hat Engineering, Cloud

__
OpenStack Development Mailing 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] FFE for tripleo collectd integration

[Lars Kellogg-Stedman]

On Thu, Feb 02, 2017 at 01:37:20PM -0500, Emilien Macchi wrote:
> Could you patch your THT patch to Depends-On the tripleo-ci patch, so
> we can see if the package gets installed and if there is no blocker we
> might have missed.

I've added the Depends-On to the review.  Will that be sufficient such
that it will use images generated with the dependent patch?

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



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

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

[Matthew Booth]

On Thu, Feb 2, 2017 at 4:42 PM, Sean Dague  wrote:

> On 02/02/2017 10:33 AM, Mike Bayer wrote:
> >
> >
> > On 02/01/2017 10:22 AM, Monty Taylor wrote:
> >>
> >> I personally continue to be of the opinion that without an explicit
> >> vocal and well-staffed champion, supporting postgres is more trouble
> >> than it is worth. The vast majority of OpenStack deployments are on
> >> MySQL - and what's more, the code is written with MySQL in mind.
> >> Postgres and MySQL have different trade offs, different things each are
> >> good at and different places in which each has weakness. By attempting
> >> to support Postgres AND MySQL, we prevent ourselves from focusing
> >> adequate attention on making sure that our support for one of them is
> >> top-notch and in keeping with best practices for that database.
> >>
> >> So let me state my opinion slightly differently. I think we should
> >> support one and only one RDBMS backend for OpenStack, and we should open
> >> ourselves up to use advanced techniques for that backend. I don't
> >> actually care whether that DB is MySQL or Postgres - but the corpus of
> >> existing deployments on MySQL and the existing gate jobs I think make
> >> the choice one way or the other simple.
> >
> >
> > well, let me blow your mind and agree, but noting that this means, *we
> > drop SQLite also*.   IMO every openstack developer should have
> > MySQL/MariaDB running on their machine and that is part of what runs if
> > you expect to run database-related unit tests.   Targeting just one
> > database is very handy but if you really want to use the features
> > without roadblocks, you need to go all the way.
>
> That's all fine and good, we just need to rewrite about 100,000 unit
> tests to do that. I'm totally cool with someone taking that task on, but
> making a decision about postgresql shouldn't be filibustered on
> rewriting all the unit tests in OpenStack because of the ways we use
> sqlite.
>

I wrote a patch series to optionally run all our unit tests using MySQL
instead of sqlite a couple of years ago, and it wasn't that hard at the
time. The biggest issue I recall was fixing up tests which assumed
sub-second timestamp granularity which MySQL did not support at the time
(but may now).

IIRC the series died because we killed the fixture I was using in oslo.db
without replacement before my series finished landing. Fundamentally wasn't
that hard, though.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
OpenStack Development Mailing 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] Deployment plan management efforts sync up

[Dougal Matthews]

On 2 February 2017 at 11:56, Jiri Tomasek  wrote:

> Hello all,
>
> there has been several ongoing efforts in TripleO regarding Deployment
> Plans management and Deployment configuration itself. A lot of this work is
> done to satisfy certain individual requirements but I think some further
> discussion needs to happen to make sure the solutions we create are
> effective for all parts of TripleO.
>
> There are several goals / features we currently aim for:
> - Define and manage custom Roles (GUI/CLI)
> - Define and manage networks (CLI/GUI)
> - Import/Export Deployment plans so it is possible to reuse them or use
> them as a reference/starting point
>
> Currently the Deployment plan stored in Swift consist of:
> - tripleo heat templates
> - roles_data.yaml - meta file used as an input to define roles (and assign
> networks to roles [1])
> - network_data.yaml - meta file used as input to define networks [2]
> - capabilities-map.yaml - meta file to describe THT environment files
> capabilities
> - mistral environment - json structure in Mistral which we use as a
> backend store accessible by mistral actions and workflows (tripleo-common)
>
> Currently, only possibility to configure roles and networks is by creating
> or updating the plan with changed meta files. We need to create Mistral
> actions to handle manipulating roles and networks so GUI (also CLI) can
> retrieve current roles/networks configuration and update it, which in turn
> will regenerate related templates. Now, the question arises: Do we want to
> use roles_data.yaml in Swift container as a storage for this information? I
> thought we agreed on using Mistral environment to store plan related data.
> (See here for additional context [3] )
>

We did agree that, I do wonder if we should revisit that decision. Nobody
else uses Mistral as a permanent, long term store. It wasn't designed for
that purpose and I am not aware of anyone else using it like this. It also
doesn't really give us any advantages (in reality, Mistral environments
have far less features than Swift). Accessing Swift is just probably just
as easy if not easier. So I think it might be worth considering moving
everything to Swift and keeping everything in one place.

This means that on plan creation, we use roles_data.yaml (and
> network_data.yaml etc.) to populate Mistral environment and generate
> templates using this data. roles_data.yaml (and others) then need to be
> discarded because from this point on, the data will be updated in Mistral
> environment through tripleo-common actions. roles_data.yaml is therefore
> used just as a default which is used when plan is created (or updated).
>

I think one of the mistakes we have made is to never fully model the data,
we don't have any code in tripleo-common that abstracts the storage and
defines how everything is stored. Instead we have a collection of actions
that understand how the structure should look in different places. This
means that as we have added new features, they all do everything a bit
differently and I can see it becoming hard to maintain and update.


Now, plan export comes into play [4]. We want to be able to pull down the
> plan and deploy it using CLI directly (which creates/updates plan as far as
> during deploy command), We want to be able to reuse the plan in other
> deployments or use it as a reference architecture for subsequent
> deployments. This means we don't only want to download the contents of
> Swift container, but also configuration stored in Mistral environment.
>

If we did put everything in Swift, this bit would be much easier.


>
> So Plan export action pulls down files from Swift container, adds meta
> files: roles_data.yaml, network_data.yaml... which it populates by looking
> at appropriate keys in Mistral environment + plan_environment.yaml which
> includes remaining data from Mistral environment such as parameter values,
> environments etc. All of those are then returned in a single tarball.
> Question to consider is whether to split all this data into separate files
> or keep it in single one.
>
> Plan Import [5] then allows to provide plan_environment.yaml to enable
> populating parameter values and environments selection during plan creation.
>
>
> Alternative solution is to store meta files (roles_data.yaml,
> network_data.yaml...) in Swift container and use those files as a data
> store which IMHO does not comply with decision to use Mistral environment
> as a plan data store. In that case we should probably get rid of using
> Mistral environment altogether and use plan_environment.yaml file in Swift
> container to store data which we currently store in Mistral environment. I
> am quite convinced that there have been good reasons to not to do this and
> use Mistral environment.
>

I am not convinced. Can you remember any of these reasons? I can't?


>
>
> [1] https://review.openstack.org/#/c/409920/
> [2] https://review.openstack.org/#/c/409921/
> [3] 

[openstack-dev] [TripleO] FFE request for composable upgrades

[Steven Hardy]

Hi all,

There's been some discussion on IRC about this, but I wanted to formally
request a FFE for the remaining composable upgrades work and provide a
status update:

https://blueprints.launchpad.net/tripleo/+spec/overcloud-upgrades-per-service

We've made pretty good progress on this, and the ansible based upgrade
architecture, along with tasks for most overcloud services has landed.

However we've been blocked for a while due to the complexity of upgrading
nova - some work was required to get puppet support for cellsv2, and to
figure out the required steps related to the placement API integration.

I think that's all close now, and folks have been testing locally with some
success:

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

The other missing piece is pacemaker support, which again has been locally
tested but not yet proven via CI:

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

The final part is deploying the upgrade script for operator driven upgrades
when automated upgrades are disabled (this is similar to previous releases,
but required some rework due to the new architecture):

https://review.openstack.org/#/c/424905/
https://review.openstack.org/#/c/419886/

There are also a few other various fixes and cleanups outstanding:

https://review.openstack.org/#/c/428309
https://review.openstack.org/#/c/428310/
https://review.openstack.org/#/c/428348/
https://review.openstack.org/#/c/428349/
https://review.openstack.org/#/c/424715/

I think that's all of the outstanding work, but we're still testing and
trying to flush out any remaining issues - if I've missed anything
hopefully other folks on the upgrades squad can follow up with more
details.

Overall I think this is OK for the final release, but we should aim to land
the patches above ASAP so we can focus on testing and any remaining
bugfixes.

Thanks!

-- 
Steve Hardy
Red Hat Engineering, Cloud

__
OpenStack Development Mailing 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] [cinder]Using DEFAULT section to configure drivers is not supported since Ocata

[Gorka Eguileor]

On 02/02, Gyorgy Szombathelyi wrote:
> Hi!
>
> Because of the deprecated driver configuration in the DEFAULT section doesn't 
> work anymore in Ocata, I would like to ask if any migration tool exists for 
> using the previously created volumes?
>
> E.g. if the existing volumes have the attribute os-vol-host-attr:host like 
> hostname#RBD, cinder operations won't work until one doesn't do a database 
> update to the format like hostname#ceph#ceph (if the new backend section name 
> is ceph).
> It is not that hard to do a UPDATE SQL on the database, but I think it is not 
> a good thing to force users to do it. Maybe a migration script, or a fallback 
> code in cinder-volume would be appreciated.
> Thinking about the migration script, maybe it should update the old style 
> host attribute to the first defined backend. Or am I just oversighting 
> something obvious?
>
> Br,
> György
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi György,

There is a manage command that allows you to change the host without
using SQL:

 cinder-manage volume update_host --currenthost CURRENTHOST --newhost NEWHOST


If you are using consistency groups you'll also have to change those:

 cinder-manage cg update_cg_host --currenthost CURRENTHOST --newhost NEWHOST


I hope these help.

Cheers,
Gorka.

__
OpenStack Development Mailing 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] [watcher] Watcher release v1.0.0

[Antoine Cabot]

I'm very proud to announce today the availability of Watcher in version 1.0.0.
It has been a long way since the initial proposition in Vancouver almost
2 years ago. The project has received a lot of good feedback already thanks
to the amazing group of developers working on it. I would like to take the
opportunity to thank all of them today, from small doc contributions to larger
patches, everything is important and makes Watcher ready for production today.
Now that Watcher is ready, we need to build more advanced optimization
strategies to demonstrate the real value of our project. I will let alexchadin
leads this as our new appointed PTL for the Pike cycle.

Thanks a lot everyone for this great job, we made it !

Antoine

__
OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Miguel Angel Ajo Pelayo]

On Fri, Feb 3, 2017 at 7:55 AM, IWAMOTO Toshihiro 
wrote:

> At Wed, 1 Feb 2017 16:24:54 -0800,
> Armando M. wrote:
> >
> > Hi,
> >
> > [TL;DR]: OpenStack services have steadily increased their memory
> > footprints. We need a concerted way to address the oom-kills experienced
> in
> > the openstack gate, as we may have reached a ceiling.
> >
> > Now the longer version:
> > 
> >
> > We have been experiencing some instability in the gate lately due to a
> > number of reasons. When everything adds up, this means it's rather
> > difficult to merge anything and knowing we're in feature freeze, that
> adds
> > to stress. One culprit was identified to be [1].
> >
> > We initially tried to increase the swappiness, but that didn't seem to
> > help. Then we have looked at the resident memory in use. When going back
> > over the past three releases we have noticed that the aggregated memory
> > footprint of some openstack projects has grown steadily. We have the
> > following:
>
> Not sure if it is due to memory shortage, VMs running CI jobs are
> experiencing sluggishness, which may be the cause of ovs related
> timeouts[1]. Tempest jobs run dstat to collect system info every
> second. When timeouts[1] happen, dstat outputs are also often missing
> for several seconds, which means a VM is having trouble scheduling
> both ovs related processes and the dstat process.
> Those ovs timeouts affect every project and happen much often than the
> oom-kills.
>
> Some details are on the lp bug page[2].
>
> Correlation of such sluggishness and VM paging activities are not
> clear. I wonder if VM hosts are under high load or if increasing VM
> memory would help. Those VMs have no free ram for file cache and file
> pages are read again and again, leading to extra IO loads on VM hosts
> and adversely affecting other VMs on the same host.
>
>
Iwamoto, that makes a lot of sense to me.

That makes me think that increasing the available RAM per instance could be
beneficial, even if we'd be able to run less workloads simultaneously.
Compute hosts would see their pressure reduced (since they can accommodate
less workload), instances would run more smoothly, because they'd have more
room for caching and buffers, and we may also see the OOM issues alleviated.

BUT, if that's even a suitable approach for all those problems which could
very well be inter-related, it still means that we should keep pursuing
finding the culprit of our memory footprint growth and taking counter
measures where reasonable.

Sometimes more RAM is just the cost of progress (new features, ability to
do online upgrades, better synchronisation patterns based in caching,
etc...), sometimes we'd be able to slash down the memory usage by
converting some of our small-repeatable services into other things (I'm
thinking of the neutron-ns-metadata proxy being converted to haproxy or
nginx + a neat piece of config).

So, would it be realistic to bump the flavors RAM to favor our stability in
the short term? (considering that the less amount of workload our clouds
will be able to take is fewer, but the failure rate will also be fewer, so
the rechecks will be reduced).




>
> [1] http://logstash.openstack.org/#dashboard/file/logstash.json?
> query=message%3A%5C%22no%20response%20to%20inactivity%20probe%5C%22
> [2] https://bugs.launchpad.net/neutron/+bug/1627106/comments/14
>
> --
> IWAMOTO Toshihiro
>
> __
> OpenStack Development Mailing 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] [Cinder] BlockDeviceDriver deprecated?

[Gorka Eguileor]

On 03/02, Pieter Baele wrote:
> Red Hat tells me the Cinder BlockDeviceDriver is going to be deprecated
> upstream. It isn't supported in RHOSP in any case.
> Is this true?

Yes, that is correct, it's in the release notes:

 
https://github.com/openstack/cinder/blob/master/releasenotes/notes/deprecate-block-device-driver-d30232547a31fe1e.yaml

>
> Bakground information:
> BDD is one of the things I would have used for important HDFS DataNodes in
> a private cloud.
> Red Hat proposes Ceph, but running a replicated HDFS on top of Ceph RBD
> which also replicated.?
>
> So my only option left is bare-metal Hadoop DataNodes (?)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


The first thing that would come to mind in this case would be to remove
the replication from one of the 2 filesystems, since both of them allow
this:

 - You can create the ceph pool for the volumes with a replication size
   of 1
 - Set your HDFS file replication to 1

I haven't done tests or analyzed your specific case, so I wouldn't be
able to say which one is the most appropriate for your case.

You could always go with LVM nodes, although I'm not sure that's such a
great idea; and you probably already know that Red Hat doesn't support
it for production environments, as it's only approved for PoC
deployments.

Cheers,
Gorka.

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

[openstack-dev] [glance] glance 14.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for glance for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/glance/

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

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

http://git.openstack.org/cgit/openstack/glance/log/?h=stable/ocata

Release notes for glance can be found at:

http://docs.openstack.org/releasenotes/glance/



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

[John Garbutt]

On 3 February 2017 at 02:59, Matt Riedemann  wrote:
> The Foundation wants to have the mascots finalized before the PTG. This is
> just an opportunity for people to raise issues with it if they have any.

Honestly it looks a bit aggressive / sharp / pointy.
Maybe less spikes on the outside? I duno.

But asking for a friendlier looking supernova seems a bit... unscientific.

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] [watcher] Boston CFP

[Antoine Cabot]

Hi Watcher team,

A quick reminder about CFP for Boston that ends on Sunday.
Please look at talks proposals [1] and submit them before the deadline
(11:59PM PST on February 6, 2017). I have added a submitter and a target
category for each proposal.

Thank you,

Antoine

[1] https://etherpad.openstack.org/p/Watcher_abstracts_boston2017

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

[Davanum Srinivas]

Reminded me of the indian traditional colored patterns :)
https://www.google.com/search?q=rangoli+star=lnms=isch
https://www.google.com/search?tbm=isch=1=rangoli

-- Dims

On Fri, Feb 3, 2017 at 6:03 AM, John Garbutt  wrote:
> On 3 February 2017 at 02:59, Matt Riedemann  wrote:
>> The Foundation wants to have the mascots finalized before the PTG. This is
>> just an opportunity for people to raise issues with it if they have any.
>
> Honestly it looks a bit aggressive / sharp / pointy.
> Maybe less spikes on the outside? I duno.
>
> But asking for a friendlier looking supernova seems a bit... unscientific.
>
> 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



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

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

Re: [openstack-dev] [TripleO] FFE for novajoin in TripleO's undercloud

[Ben Nemec]

On 02/02/2017 06:27 PM, Juan Antonio Osorio wrote:

Hello,

I would like to request an FFE to properly support the novajoin
vendordata plugin in TripleO. Most of the work has landed, however, we
still need to add it to TripleO's CI in order to have it officially
supported.

This is crucial for TLS-everywhere configuration's usability, since it
makes it easier to populate the required field's in the CA (which in our
case is FreeIPA). I'm currently working on a patch to add it to the
fakeha-caserver OVB job; which, after this is done, I hope to move from
the experimental queue, to the periodic one.


I thought we had bumped TLS everywhere to next release.  Is there still 
a use case for novajoin in Ocata?




BR

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



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



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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Mike Bayer]

On 02/03/2017 10:21 AM, Doug Hellmann wrote:

Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:


On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:

That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.

A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_status, which by
default are 255 chars.



let me give you a tip on IF blocks, that they are a bit of an
anti-pattern.  If you want a column type to do one thing in one case,
and another in another case, create an object that does the thing you want:


some_table = Table(
 'some_table', metadata,
 Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)


I wonder if we want to do either, though. Shouldn't we try to use
the same (smaller) column size all the time? Otherwise we end up
with another incompatibility between different deployments, since
sometimes things like names might have different sizes in different
clouds.


in that case you have to do a migration which as you know these days 
means the "old" column remains for a whole release cycle and the 
application must undergo significant complexity, either at the app level 
or in triggers, to keep data between "old" and "new" columns 
simultaneously.   So one advantage to keeping this at the "create for 
NDB" level is that we don't need to get into schema migrations.


Unless we changed the value in the application and its migration files 
completely, and *didnt* migrate old applications, and just hope/ensure 
that they aren't writing larger data values.   Maybe that's possible 
though it seems a little scary.   Perhaps some kind of annotated type 
like VARCHAR(50, unmigrated=255) to note what's going on.








I think we might want to look into creating a stub dialect called 'ndb'
that subclasses mysql+pymysql.   Treating ndb as a whole different
database means there's no longer the need for a flag in oslo.db, the
'ndb' name would instead be interpreted as a new backend - the main
thing would be ensuring all the mysql-appropriate hooks in oslo.db are
also emitted for ndb, but this also gives us a way to pick and choose
which hooks apply.   It seems like there may be enough different about
it to separate it at this level.

Not sure if people on the list are seeing that we are simultaneously
talking about getting rid of Postgresql in the efforts to support only
"one database", while at the same time adding one that is in many ways a
new database.


Yes, that does seem a bit ironic. That's also why I was pointing
out that we're going to want to have people lined up to support the
work before starting. The lack of help with Postresql testing
resulted in removing it from the gate, and possibly to dropping
support entirely.

For reference, the discussion in [1] led to this proposed TC
resolution [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111357
[2] https://review.openstack.org/427880






So to determine a more appropriate size, I look

through the Cinder code to find where the possible options/states are
for those columns. Then I cut it down to a more reasonable size. I'm
very careful when I cut the size of a string column to ensure that all
of the possible values can be contained.

In cases where a column is extremely large for capturing the outputs of
a command, I will change the type to Text or TinyText depending on the
length required. A good example of this is in the agents table of
Neutron where there is a column for configurations that has a string
length of 4096 characters, which I change to Text. Text blobs are stored
differently and do not count against the row length.

I've also observed differences between Kilo, Mitaka, and tip where even
for InnoDB some of these tables are getting wider than can be supported.
So in the case of Cinder, some of the columns have been shifted to
separate tables to fit within 65k. I've seen the same thing in Neutron.
So I fully expect that some of the services that have table bloat will
have to cut the lengths or break the tables up over time anyways. As
that happens, it reduces the amount of work for me, which is a good thing.

The most complicated database schemas to patch up are cinder, glance,
neutron, and nova due to the size and complexity of their tables. Those
also have a lot of churn between releases where the schema changes more
often. Other services like keystone, heat, and ironic are considerably
easier to work with and have well laid out tables that don't change much.

Thanks,
Octave

On 2/2/2017 1:25 PM, Mike Bayer wrote:



On 02/02/2017 02:52 PM, Mike Bayer wrote:


But more critically I noticed you referred to altering the names of
columns to suit NDB.  How will this be accomplished?   Changing a column
name in an openstack application is no longer trivial, because online

Re: [openstack-dev] [TripleO] FFE for novajoin in TripleO's undercloud

[Emilien Macchi]

On Thu, Feb 2, 2017 at 7:27 PM, Juan Antonio Osorio  wrote:
> Hello,
>
> I would like to request an FFE to properly support the novajoin vendordata
> plugin in TripleO. Most of the work has landed, however, we still need to
> add it to TripleO's CI in order to have it officially supported.

"Most of the work has landed": do we still have some patches (beside CI things)?

> This is crucial for TLS-everywhere configuration's usability, since it makes
> it easier to populate the required field's in the CA (which in our case is
> FreeIPA). I'm currently working on a patch to add it to the fakeha-caserver
> OVB job; which, after this is done, I hope to move from the experimental
> queue, to the periodic one.

I'm ok to add the job as long as it's non voting for now.

> BR
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@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
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [cinder]Using DEFAULT section to configure drivers is not supported since Ocata

[Gyorgy Szombathelyi]

Hello!
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Hi György,
> 
> There is a manage command that allows you to change the host without
> using SQL:
> 
>  cinder-manage volume update_host --currenthost CURRENTHOST --
> newhost NEWHOST
> 
> 
> If you are using consistency groups you'll also have to change those:
> 
>  cinder-manage cg update_cg_host --currenthost CURRENTHOST --newhost
> NEWHOST
> 
> 
> I hope these help.

Definitely! So nothing has to be written, it is already done. 

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

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

[openstack-dev] [release] skipping meeting today

[Doug Hellmann]

With several members of the team unavailable today, and the release
candidates still slowly trickling in, I think it makes more sense
for us to catch up with each other Monday than to have our regular
meeting today.

I'll look for folks in #openstack-release around 14:00 UTC Monday.

Doug

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

Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Truman, Travis]

+1 for Marc joining the core reviewer team. His work on CentOS support has been 
impressive.

Travis Truman

From: Jesse Pretorius 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, February 3, 2017 at 8:33 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core 
reviewer

Hi everyone,

I'd like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it's important that 
he's able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the 
original message. Your cooperation is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Roman Podoliaka]

On Fri, Feb 3, 2017 at 4:41 PM, Mike Bayer  wrote:
> Not sure if people on the list are seeing that we are simultaneously talking
> about getting rid of Postgresql in the efforts to support only "one
> database", while at the same time adding one that is in many ways a new
> database.

++

and, FWIW, moving columns between tables and changing of column types
in order to make NDB storage engine happy both seem to be a way more
intrusive than what we've had to do so far in the code of OpenStack
projects in order to support PostgreSQL.

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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Doug Hellmann]

Excerpts from Mike Bayer's message of 2017-02-03 09:41:11 -0500:
> 
> On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
> > That refers to the total length of the row. InnoDB has a limit of 65k
> > and NDB is limited to 14k.
> >
> > A simple example would be the volumes table in Cinder where the row
> > length goes beyond 14k. So in the IF logic block, I change columns types
> > that are vastly oversized such as status and attach_status, which by
> > default are 255 chars.
> 
> 
> let me give you a tip on IF blocks, that they are a bit of an 
> anti-pattern.  If you want a column type to do one thing in one case, 
> and another in another case, create an object that does the thing you want:
> 
> 
> some_table = Table(
>  'some_table', metadata,
>  Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
> )

I wonder if we want to do either, though. Shouldn't we try to use
the same (smaller) column size all the time? Otherwise we end up
with another incompatibility between different deployments, since
sometimes things like names might have different sizes in different
clouds.

> I think we might want to look into creating a stub dialect called 'ndb' 
> that subclasses mysql+pymysql.   Treating ndb as a whole different 
> database means there's no longer the need for a flag in oslo.db, the 
> 'ndb' name would instead be interpreted as a new backend - the main 
> thing would be ensuring all the mysql-appropriate hooks in oslo.db are 
> also emitted for ndb, but this also gives us a way to pick and choose 
> which hooks apply.   It seems like there may be enough different about 
> it to separate it at this level.
> 
> Not sure if people on the list are seeing that we are simultaneously 
> talking about getting rid of Postgresql in the efforts to support only 
> "one database", while at the same time adding one that is in many ways a 
> new database.

Yes, that does seem a bit ironic. That's also why I was pointing
out that we're going to want to have people lined up to support the
work before starting. The lack of help with Postresql testing
resulted in removing it from the gate, and possibly to dropping
support entirely.

For reference, the discussion in [1] led to this proposed TC
resolution [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111357
[2] https://review.openstack.org/427880

> 
> 
> 
> 
> So to determine a more appropriate size, I look
> > through the Cinder code to find where the possible options/states are
> > for those columns. Then I cut it down to a more reasonable size. I'm
> > very careful when I cut the size of a string column to ensure that all
> > of the possible values can be contained.
> >
> > In cases where a column is extremely large for capturing the outputs of
> > a command, I will change the type to Text or TinyText depending on the
> > length required. A good example of this is in the agents table of
> > Neutron where there is a column for configurations that has a string
> > length of 4096 characters, which I change to Text. Text blobs are stored
> > differently and do not count against the row length.
> >
> > I've also observed differences between Kilo, Mitaka, and tip where even
> > for InnoDB some of these tables are getting wider than can be supported.
> > So in the case of Cinder, some of the columns have been shifted to
> > separate tables to fit within 65k. I've seen the same thing in Neutron.
> > So I fully expect that some of the services that have table bloat will
> > have to cut the lengths or break the tables up over time anyways. As
> > that happens, it reduces the amount of work for me, which is a good thing.
> >
> > The most complicated database schemas to patch up are cinder, glance,
> > neutron, and nova due to the size and complexity of their tables. Those
> > also have a lot of churn between releases where the schema changes more
> > often. Other services like keystone, heat, and ironic are considerably
> > easier to work with and have well laid out tables that don't change much.
> >
> > Thanks,
> > Octave
> >
> > On 2/2/2017 1:25 PM, Mike Bayer wrote:
> >>
> >>
> >> On 02/02/2017 02:52 PM, Mike Bayer wrote:
> >>>
> >>> But more critically I noticed you referred to altering the names of
> >>> columns to suit NDB.  How will this be accomplished?   Changing a column
> >>> name in an openstack application is no longer trivial, because online
> >>> upgrades must be supported for applications like Nova and Neutron.  A
> >>> column name can't just change to a new name, both columns have to exist
> >>> and logic must be added to keep these columns synchronized.
> >>>
> >>
> >> correction, the phrase was "Row character length limits 65k -> 14k" -
> >> does this refer to the total size of a row?  I guess rows that store
> >> JSON or tables like keystone tokens are what you had in mind here, can
> >> you give specifics ?
> >>
> >>
> >>
> >> 

Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Andy McCrae]

Definite +1 from me.
Thanks for all the work on CentOS Marc, looking forward to improving upon
that with your help!

On 3 February 2017 at 13:33, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Hi everyone,
>
>
>
> I’d like to propose Marc Gariepy [1] as a core reviewer for
> OpenStack-Ansible. His tireless effort to get CentOS as a supported
> platform in the last two cycles is getting very close to completion, and I
> feel that it’s important that he’s able to safeguard this work and help
> grow the maintenance community for it.
>
>
>
> [1] http://stackalytics.com/?module=openstackansible-group;
> user_id=mgariepy=ocata=person-day
>
>
>
> Best regards,
>
>
>
> Jesse
>
> IRC: odyssey4me
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Propose Marc Gariepy as core reviewer

[Alexandra Settle]

+1 from me ☺

Thanks for all your hard work, Marc!

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

Date: Friday, February 3, 2017 at 1:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core 
reviewer

Hi everyone,

I’d like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it’s important that 
he’s able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Jean-Philippe Evrard]

Hello,

Great!
+1

Best regards,
JP

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

Date: Friday, 3 February 2017 at 13:33
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core 
reviewer

Hi everyone,

I’d like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it’s important that 
he’s able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Large Contributing OpenStack Operators working group?

[Sean M. Collins]

Jay Pipes wrote:
> 4) I see a lot of agenda items around projects like Gluon, Craton, Watcher,
> and Blazar. I don't see any concrete ideas about talking with the developers
> of the key infrastructure services that OpenStack is built around. How does
> the LCOO plan on reaching out to the developers of the long-standing
> OpenStack projects like Nova, Neutron, Cinder, and Keystone to drive their
> shared agenda?

To expand on this point:

How effective are these teams at actually communicating with the
developers of OpenStack components? My concern is that all these working
teams collect a lot of information, then it is left in these silos and
never makes their way back to projects like Neutron, Nova, etc...

I suppose I am also philosophically opposed to having all these special
snowflake working groups. If you want to get things done in OpenStack
the best thing to do is roll up your sleeves and start participating
directly in the project where you need work done. I know for a fact that
in the Neutron community, we had RFE bugs and other processes so that
operators could submit requirements, and they weren't expected to do all
the work by themselves.

I didn't emerge from the void, fully formed, as a Neutron developer. I
was part of a team that had pain points in Neutron that we needed to
alleviate, so we jumped into the Neutron community, participated in
the weekly IRC meetings, filed bugs, started contributing patches,
etc...

So why have these groups?

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [octavia] neutron-lbaas 10.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for neutron-lbaas for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas/

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

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

http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/ocata

Release notes for neutron-lbaas can be found at:

http://docs.openstack.org/releasenotes/neutron-lbaas/



__
OpenStack Development Mailing 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] [zaqar] zaqar-ui 2.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for zaqar-ui for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/zaqar-ui/

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

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

http://git.openstack.org/cgit/openstack/zaqar-ui/log/?h=stable/ocata

Release notes for zaqar-ui can be found at:

http://docs.openstack.org/releasenotes/zaqar-ui/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/zaqar-ui

and tag it *ocata-rc-potential* to bring it to the zaqar-ui
release crew's attention.

__
OpenStack Development Mailing 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] FFE for tripleo collectd integration

[Emilien Macchi]

On Fri, Feb 3, 2017 at 7:55 AM, Lars Kellogg-Stedman  wrote:
> On Thu, Feb 02, 2017 at 01:37:20PM -0500, Emilien Macchi wrote:
>> Could you patch your THT patch to Depends-On the tripleo-ci patch, so
>> we can see if the package gets installed and if there is no blocker we
>> might have missed.
>
> I've added the Depends-On to the review.  Will that be sufficient such
> that it will use images generated with the dependent patch?

Yes, it should.
Thanks, FFE granted.

> --
> Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
> Cloud Engineering / OpenStack  | http://blog.oddbit.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
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [nova] Final mascot

[Matt Riedemann]

On 2/3/2017 5:03 AM, John Garbutt wrote:

On 3 February 2017 at 02:59, Matt Riedemann  wrote:

The Foundation wants to have the mascots finalized before the PTG. This is
just an opportunity for people to raise issues with it if they have any.


Honestly it looks a bit aggressive / sharp / pointy.
Maybe less spikes on the outside? I duno.

But asking for a friendlier looking supernova seems a bit... unscientific.

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



Yeah it made me think of some dude's tattoo - who that dude is I don't 
know, but he's a dude with an 8-bit NES bomb tattoo so he's not someone 
to be messed with.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Jesse Pretorius]

Hi everyone,

I’d like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it’s important that 
he’s able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Logan V.]

+1 awesome work on the CentOS support! And lots of helpful reviews on
things not CentOS too. Thanks Marc

Logan

On Fri, Feb 3, 2017 at 7:52 AM, Jean-Philippe Evrard
 wrote:
> Hello,
>
>
>
> Great!
>
> +1
>
>
>
> Best regards,
>
> JP
>
>
>
> From: Jesse Pretorius 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Friday, 3 February 2017 at 13:33
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core
> reviewer
>
>
>
> Hi everyone,
>
>
>
> I’d like to propose Marc Gariepy [1] as a core reviewer for
> OpenStack-Ansible. His tireless effort to get CentOS as a supported platform
> in the last two cycles is getting very close to completion, and I feel that
> it’s important that he’s able to safeguard this work and help grow the
> maintenance community for it.
>
>
>
> [1]
> http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day
>
>
>
> Best regards,
>
>
>
> Jesse
>
> IRC: odyssey4me
>
>
>
> 
>
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington Road,
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
> contain confidential or privileged information intended for the recipient.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited. If you receive this transmission in error, please notify us
> immediately by e-mail at ab...@rackspace.com and delete the original
> message. Your cooperation is appreciated.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [oslo][oslo.db] MySQL Cluster support

[Mike Bayer]

On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:

That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.

A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_status, which by
default are 255 chars.



let me give you a tip on IF blocks, that they are a bit of an 
anti-pattern.  If you want a column type to do one thing in one case, 
and another in another case, create an object that does the thing you want:



some_table = Table(
'some_table', metadata,
Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)


I think we might want to look into creating a stub dialect called 'ndb' 
that subclasses mysql+pymysql.   Treating ndb as a whole different 
database means there's no longer the need for a flag in oslo.db, the 
'ndb' name would instead be interpreted as a new backend - the main 
thing would be ensuring all the mysql-appropriate hooks in oslo.db are 
also emitted for ndb, but this also gives us a way to pick and choose 
which hooks apply.   It seems like there may be enough different about 
it to separate it at this level.


Not sure if people on the list are seeing that we are simultaneously 
talking about getting rid of Postgresql in the efforts to support only 
"one database", while at the same time adding one that is in many ways a 
new database.





So to determine a more appropriate size, I look

through the Cinder code to find where the possible options/states are
for those columns. Then I cut it down to a more reasonable size. I'm
very careful when I cut the size of a string column to ensure that all
of the possible values can be contained.

In cases where a column is extremely large for capturing the outputs of
a command, I will change the type to Text or TinyText depending on the
length required. A good example of this is in the agents table of
Neutron where there is a column for configurations that has a string
length of 4096 characters, which I change to Text. Text blobs are stored
differently and do not count against the row length.

I've also observed differences between Kilo, Mitaka, and tip where even
for InnoDB some of these tables are getting wider than can be supported.
So in the case of Cinder, some of the columns have been shifted to
separate tables to fit within 65k. I've seen the same thing in Neutron.
So I fully expect that some of the services that have table bloat will
have to cut the lengths or break the tables up over time anyways. As
that happens, it reduces the amount of work for me, which is a good thing.

The most complicated database schemas to patch up are cinder, glance,
neutron, and nova due to the size and complexity of their tables. Those
also have a lot of churn between releases where the schema changes more
often. Other services like keystone, heat, and ironic are considerably
easier to work with and have well laid out tables that don't change much.

Thanks,
Octave

On 2/2/2017 1:25 PM, Mike Bayer wrote:



On 02/02/2017 02:52 PM, Mike Bayer wrote:


But more critically I noticed you referred to altering the names of
columns to suit NDB.  How will this be accomplished?   Changing a column
name in an openstack application is no longer trivial, because online
upgrades must be supported for applications like Nova and Neutron.  A
column name can't just change to a new name, both columns have to exist
and logic must be added to keep these columns synchronized.



correction, the phrase was "Row character length limits 65k -> 14k" -
does this refer to the total size of a row?  I guess rows that store
JSON or tables like keystone tokens are what you had in mind here, can
you give specifics ?



__

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



--

Oracle 
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure

Green Oracle  Oracle is committed to
developing practices and products that help protect the environment



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

Re: [openstack-dev] [TripleO] FFE for novajoin in TripleO's undercloud

[Juan Antonio Osorio]

On Fri, Feb 3, 2017 at 4:54 PM, Emilien Macchi  wrote:

> On Thu, Feb 2, 2017 at 7:27 PM, Juan Antonio Osorio 
> wrote:
> > Hello,
> >
> > I would like to request an FFE to properly support the novajoin
> vendordata
> > plugin in TripleO. Most of the work has landed, however, we still need to
> > add it to TripleO's CI in order to have it officially supported.
>
> "Most of the work has landed": do we still have some patches (beside CI
> things)?
>

Well, the latest FreeIPA client code broke our connection code for
novajoin. So either we're fixing that. It shouldn't be too bad.


>
> > This is crucial for TLS-everywhere configuration's usability, since it
> makes
> > it easier to populate the required field's in the CA (which in our case
> is
> > FreeIPA). I'm currently working on a patch to add it to the
> fakeha-caserver
> > OVB job; which, after this is done, I hope to move from the experimental
> > queue, to the periodic one.
>
> I'm ok to add the job as long as it's non voting for now.
>
> > BR
> >
> > --
> > Juan Antonio Osorio R.
> > e-mail: jaosor...@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
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed

[Bence Romsics]

Hi All,

I'd like to add support for Neutron Trunks [1][2] into Horizon
together with a few colleagues in the Pike cycle. We thought of
writing a new Horizon plugin [3] for that purpose. That way I hope to
keep it optional for deployment and minimize the maintenance cost for
the Horizon core team. Of course we'd welcome all review feedback,
especially from the Horizon and Neutron teams.

To host the work I'd like create a new project: openstack/neutron-trunk-ui

Following the Project Creator's Guide, here's a proposed new project config:

https://review.openstack.org/428730

And the corresponding governance change:

https://review.openstack.org/428796

Please review them and if you agree approve. Or guide me to a better change.

Thanks in advance,
Bence Romsics

[1] 
https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst
[2] https://wiki.openstack.org/wiki/Neutron/TrunkPort
[3] http://docs.openstack.org/developer/horizon/tutorials/plugin.html

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

[openstack-dev] [glance] priorities for the coming week (02/03-02/09)

[Brian Rosmaita]

Congratulations to the Glance team for delivering Ocata RC-1!


As discussed at yesterday's Glance meeting, here are the weekly priorities:

1.  RC-1 Testing
Glance Ocata RC-1 (14.0.0.0rc1) is available and the stable/ocata branch
has been created.  Please test and create bugs for any anomalies you
find, and tag them as 'ocata-rc-potential'.  The big new feature in this
release is Community Images and its associated image visibility changes,
so please give those a close look.  The documentation is up-to-date, but
it would be worth looking over the api-ref and dev docs to make sure
everything is clear.  Also, don't forget the "narrative" api-docs in the
glance-specs repo.

2. Nominate bugfixes for backport
Nominate any appropriate current bugs for backport to Ocata using the
'ocata-rc-potential' tag in Launchpad.  Put out a shout in
#openstack-glance to alert us to take a look and approve.

3. Work on ocata-rc-potential bugs
Bugs approved for backport take priority over all other bugs (except for
security bugs).  Make sure you assign yourself to the bug so everyone
knows it's being worked on.
- https://bugs.launchpad.net/glance/+bugs?field.tag=ocata-rc-potential
(Ask in #openstack-glance if you have any questions.)

4. Show glance_store some love
If you've done the above and are still looking for something to do, Ian
has picked through the glance_store bugs.  Here's the list of open bugs
to work on:
- https://bugs.launchpad.net/glance-store
If you pick one up, make sure you assign it to yourself before working
on it.


Reminder: propose topics for discussion at the PTG in the etherpad.
We'll be discussing the PTG at the next weekly Glance meeting.
- https://etherpad.openstack.org/p/glance-pike-ptg-planning


cheers,
brian

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

Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Major Hayden]

+1

Anyone who gets into the SELinux trenches with me that many times is
worth having as a core. ;)

--
Major Hayden


On Fri, Feb 3, 2017 at 7:33 AM, Jesse Pretorius
 wrote:
> I’d like to propose Marc Gariepy [1] as a core reviewer for
> OpenStack-Ansible. His tireless effort to get CentOS as a supported platform
> in the last two cycles is getting very close to completion, and I feel that
> it’s important that he’s able to safeguard this work and help grow the
> maintenance community for it.

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

Re: [openstack-dev] [nova] Final mascot

[Szankin, Maciej]

On 2/3/17 7:56 AM, Matt Riedemann wrote:
> On 2/3/2017 5:03 AM, John Garbutt wrote:
>> On 3 February 2017 at 02:59, Matt Riedemann  wrote:
>>> The Foundation wants to have the mascots finalized before the PTG. This is
>>> just an opportunity for people to raise issues with it if they have any.
>> Honestly it looks a bit aggressive / sharp / pointy.
>> Maybe less spikes on the outside? I duno.
>>
>> But asking for a friendlier looking supernova seems a bit... unscientific.
>>
>> 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
>>
> Yeah it made me think of some dude's tattoo - who that dude is I don't 
> know, but he's a dude with an 8-bit NES bomb tattoo so he's not someone 
> to be messed with.
>
We can go with light version and all on PTG have a haircut in the shape
of this logo.

I liked the previous version, though without the label I would say that
it is an atom.

-- macsz

__
OpenStack Development Mailing 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] FFE for novajoin in TripleO's undercloud

[Juan Antonio Osorio]

On Fri, Feb 3, 2017 at 5:31 PM, Ben Nemec  wrote:

>
>
> On 02/02/2017 06:27 PM, Juan Antonio Osorio wrote:
>
>> Hello,
>>
>> I would like to request an FFE to properly support the novajoin
>> vendordata plugin in TripleO. Most of the work has landed, however, we
>> still need to add it to TripleO's CI in order to have it officially
>> supported.
>>
>> This is crucial for TLS-everywhere configuration's usability, since it
>> makes it easier to populate the required field's in the CA (which in our
>> case is FreeIPA). I'm currently working on a patch to add it to the
>> fakeha-caserver OVB job; which, after this is done, I hope to move from
>> the experimental queue, to the periodic one.
>>
>
> I thought we had bumped TLS everywhere to next release.  Is there still a
> use case for novajoin in Ocata?
>

Well, one can deploy most base services with TLS in the internal network
already. So one can actually try it out.


>
>> BR
>>
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com 
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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] [watcher] Watcher release v1.0.0

[Ed Leafe]

On Feb 3, 2017, at 4:27 AM, Antoine Cabot  wrote:

> I'm very proud to announce today the availability of Watcher in version 1.0.0.

Congratulations!


-- 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] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Amy Marrich]

+1 from me too!

Amy
IRC: spotz

On Fri, Feb 3, 2017 at 7:33 AM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Hi everyone,
>
>
>
> I’d like to propose Marc Gariepy [1] as a core reviewer for
> OpenStack-Ansible. His tireless effort to get CentOS as a supported
> platform in the last two cycles is getting very close to completion, and I
> feel that it’s important that he’s able to safeguard this work and help
> grow the maintenance community for it.
>
>
>
> [1] http://stackalytics.com/?module=openstackansible-group;
> user_id=mgariepy=ocata=person-day
>
>
>
> Best regards,
>
>
>
> Jesse
>
> IRC: odyssey4me
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev