[openstack-dev] [glance] [cross-project] Austin summit summary: Microversions

[Nikhil Komawar]

Hello everyone,

Just wanted to send a brief summary of the discussions at the summit. This list 
is not holistic however, it covers the relevant aspects that
various stakeholders need to be aware of.

* The discussion in this session was informatory on what's existing today in 
the API_WG guidelines.

* The pieces of information given, relevant here are: Glance sort of does this 
but lacks the client negotiation part. The wsgi adapter in Glance should be 
capable of adding this functionality.

* It would be nice if we have this in Glance before making the bigger API 
impacting changes. This should be a relatively small change.

* Some research questions were posted: how can oslo.vo (versioned objects) can 
help? do we need an extra step for this to work with metadefs or will it work 
out of the box?

For more information please reach out to me on #openstack-glance, email, reply 
here etc.

-- 

Thanks,
Nikhil


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

[openstack-dev] [glance] [interop] [defcore] [tempest] [refstack] [docs] Austin summit summary: Import refactor implementation and updates

[Nikhil Komawar]

Hello everyone,

Just wanted to send a brief summary of the discussions at the summit.
This list is not holistic however, it covers the relevant aspects that
various stakeholders need to be aware of.

  * The team agreed to implement the refactor in 3 major steps. We will
start with a MVP that will allow the minimum required DefCore
capability to exist, follow up with some better persistent task
management system and then if needed allow operators to orchestrate
tasks. Second and the third step being implementation detail with no
relation to providing DefCore capabilities.

  * MVP is to be broken down in 4 parts viz. basic staging structure
that will pipe data to glance-api nodes and either stage it on
glance-api nodes (part 1), stage it in glance configured backend
store (part 2), user's swift account without data processing (part
3), user's swift account with data  processing on glance-api nodes
(part 4).

  * The import spec needs to be updated (currently patch proposed by
Brian Rosmaita and is review in progress). We identified some extra
headers that may be needed as a part of the work. Also, the return
values are being updated to convey more accurate info to the users.
You can find some other minor changes as well. (
https://review.openstack.org/#/c/311871 )

  * The plugin structure for the task scripts to be used by the
operators is a design in progress. We intend to decouple that
discussion with the API work as it becomes implementation detail at
that point. We may open a new spec for it so that we can have the
accurate design for the well defined and hence simple plugin scripts
of the tasks for introspection, conversion, etc.

  * There's action item for me (and anyone interested) in finding the
complexity to make checksum, size mutable until the image becomes
active.

  * We need volunteer(s) to add tempest tests for the above API and
workflow changes.

For more information please reach out to me on #openstack-glance, email,
reply here etc.

-- 

Thanks,
Nikhil


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

[openstack-dev] [tricircle] A number of dummy functions

[Shinobu Kinjo]

Team,

How many dummy, fake function does the Tricircle have?
I understood that we are now in pre-production, and will be in
production hopefully soon!
But I don't need surprise any more -;

e.g.,
# ./tricircle/cinder_apigw/controllers/volume.py
337 def _convert_header(self, t_release, b_release, header):
338
339 return header

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

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

[openstack-dev] [kolla][kubernetes] kolla-kubernetes underway

[Steven Dake (stdake)]

Hey folks,

There was a majority vote result on the separate repository vote and as a 
result voting was closed early.  We have voted to proceed with a separate 
repository for kolla-kubernetes.

The kolla-kubernetes repository is in progress of creation and being added to  
the governance repository.

If you have interest in this work, the #1 thing you can do to ensure the best 
outcome possible is make certain the spec our community produces is solid and 
fairly complete.  The specification is being iterated on here:

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

We will leave the spec open until there isn't much work that needs to be done 
on it and proceed with implementation based upon spec produced.

Regards
-steve

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

Re: [openstack-dev] [User-committee] [app-catalog] App Catalog IRC meeting Thursday May 5th

[David F Flanders]

For this who have not used IRC previously, here is a quick guide to get
your started:

http://docs.openstack.org/upstream-training/06-irc-meetings.html#1

Don't be afraid to ask questions as IRC is good fun in a meeting room as to
get to use the meeting room robot!  More than just tech, a reality useful
way to run an efficient async meeting!

See you'll on IRC #represent ;)

Kind Regards,

Flanders
On 5 May 2016 8:55 AM, "Christopher Aedo"  wrote:

> Join us Thursday for our weekly meeting, scheduled for May 5th at
> 17:00UTC in #openstack-meeting-3
>
> The agenda can be found here, and please add to if you want to get
> something on the agenda:
> https://wiki.openstack.org/wiki/Meetings/app-catalog
>
> Looking forward to seeing you there tomorrow!
>
> -Christopher
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
__
OpenStack Development Mailing 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] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

[Renat Akhmerov]

Cool, feel free to communicate with us on adding Mistral assets into the 
catalog.

Renat Akhmerov
@Nokia

> On 05 May 2016, at 06:43, Nikhil Komawar  wrote:
> 
> Thanks Christopher for a really nice summary!
> 
> 
> On 5/4/16 7:37 PM, Christopher Aedo wrote:
>> Hello!  At the summit I was excited to have many conversations with
>> folks who are already using the Community App Catalog regularly, and
>> many others who plan to increase their level of participation in the
>> months to come - I'm really happy to see the continued interest in
>> this effort.  For those that were unable to join us in Austin, I
>> wanted to provide a brief summary of what we covered and discussed
>> during our fishbowl and design sessions.  We tracked everything on an
>> etherpad[1] which captures the details.
>> 
>> During the fishbowl session we talked about some of the new things we
>> implemented in the last cycle including the addition of TOSCA assets
>> to the catalog and a bunch of new tests that we added to the Horizon
>> plugin.  We also had an opportunity to discuss our plans to integrate
>> Glare as a backend for the catalog and everything that will allow us
>> to do. The most visible bits will be the ability for users to provide
>> feedback and ratings for assets in addition to subscribing to an asset
>> so they can be notified when the asset is updated.  We are planning to
>> complete implementation of the Glare backend within the next four months.
>> 
>> Following the fishbowl session we had two work sessions during which
>> we agreed on a few notable things, and the one which will have the
>> most impact is closer coordination and integration with Murano.  This
>> will include coordinated efforts on the UI side as well as the OSC
>> work we've been doing.  The broader intention is to disambiguate the
>> two projects in order to make it clear the Community App Catalog is
>> the community run central repository for "things that run on OpenStack
>> clouds" while still aiming for tight integration where appropriate.
>> 
>> We will have two cross-project specs coming in the next month to
>> detail these efforts and make clear our intentions and where things
>> will overlap.
>> Thanks again to everyone who was able to attend our sessions, and to
>> all those who continue to help us build up the Community App Catalog!
>> 
>> -Christopher
>> [1]: https://etherpad.openstack.org/p/AUS-app-catalog
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> -- 
> 
> Thanks,
> Nikhil
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][mistral] Saga of process than ack and where can we go from here...

[Renat Akhmerov]

> On 05 May 2016, at 01:49, Mehdi Abaakouk  wrote:
> 
> 
> Le 2016-05-04 10:04, Renat Akhmerov a écrit :
>> No problem. Let’s not call it RPC (btw, I completely agree with that).
>> But it’s one of the messaging patterns and hence should be under
>> oslo.messaging I guess, no?
> 
> Yes and no, we currently have two APIs (rpc and notification). And
> personally I regret to have the notification part in oslo.messaging.
> 
> RPC and Notification are different beasts, and both are today limited
> in terms of feature because they share the same driver implementation.
> 
> Our RPC errors handling is really poor, for example Nova just put
> instance in ERROR when something bad occurs in oslo.messaging layer.
> This enforces deployer/user to fix the issue manually.
> 
> Our Notification system doesn't allow fine grain routing of message,
> everything goes into one configured topic/queue.
> 
> And now we want to add a new one... I'm not against this idea,
> but I'm not a huge fan.
> 
> Thoughts from folks (mistral and oslo)?
>>> Also, I was not at the Summit, should I conclude the Tooz+taskflow approach 
>>> (that ensure the idempotent of the application within the library API) have 
>>> not been accepted by mistral folks ?
>> Speaking about idempotency, IMO it’s not a central question that we
>> should be discussing here. Mistral users should have a choice: if they
>> manage to make their actions idempotent it’s excellent, in many cases
>> idempotency is certainly possible, btw. If no, then they know about
>> potential consequences.
> 
> You shouldn't mix the idempotency of the user task and the idempotency
> of a Mistral action (that will at the end run the user task).
> You can have your Mistral task runner implementation idempotent and just
> make the workflow to use configurable in case the user task is
> interrupted or badly finished even if the user task is idempotent or not.
> This makes the thing very predictable. You will know for example:
> * if the user task has started or not,
> * if the error is due to a node power cut when the user task runs,
> * if you can safely retry a not idempotent user task on an other node,
> * you will not be impacted by rabbitmq restart or TCP connection issues,
> * ...
> 
> With the oslo.messaging approach, everything will just end up in a
> generic MessageTimeout error.
> 
> The RPC API already have this kind of issue. Applications have unfortunately
> dealt with that (and I think they want something better now).
> I'm just not convinced we should add a new "working queue" API in
> oslo.messaging for tasks scheduling that have the same issue we already
> have with RPC.
> 
> Anyway, that's your choice, if you want rely on this poor structure, I will
> not be against, I'm not involved in Mistral. I just want everybody is aware
> of this.
> 
>> And even in this case there’s usually a number
>> of measures that can be taken to mitigate those consequences (reruning
>> workflows from certain points after manually fixing problems, rollback
>> scenarios etc.).
> 
> taskflow allows to describe and automate this kind of workflow really easily.
> 
>> What I’m saying is: let’s not make that crucial decision now about
>> what a messaging framework should support or not, let’s make it more
>> flexible to account for variety of different usage scenarios.
> 
> I think the confusion is in the "messaging" keyword, currently oslo.messaging
> is a "RPC" framework and a "Notification" framework on top of 'messaging'
> frameworks.
> 
> Messaging framework we uses are 'kombu', 'pika', 'zmq' and 'pingus'.
> 
>> It’s normal for frameworks to give more rather than less.
> 
> I disagree, here we mix different concepts into one library, all concepts
> have to be implemented by different 'messaging framework',
> So we fortunately give less to make thing just works in the same way with all
> drivers for all APIs.
> 
>> One more thing, at the summit we were discussing the possibility to
>> define at-most-once/at-least-once individually for Mistral tasks. This
>> is demanded because there cases where we need to do it, advanced users
>> may choose one or another depending on a task/action semantics.
>> However, it won’t be possible to implement w/o changes in the
>> underlying messaging framework.
> 
> If we goes that way, oslo.messaging users and Mistral users have to be aware
> that their job/task/action/whatever will perhaps not be called (at-most-once)
> or perhaps called twice (at-least-once).
> 
> The oslo.messaging/Mistral API and docs must be clear about this behavior to
> not having bugs open against oslo.messaging because script written via Mistral
> API is not executed as expected "sometimes".
> "sometimes" == when deployers have trouble with its rabbitmq (or whatever)
> broker and even just when a deployer restart a broker node or when a TCP
> issue occurs. At this end the backtrace in theses cases always trows only
> oslo.messaging trace (the well known 

[openstack-dev] [swift] specs are dead. long live ideas

[John Dickinson]

If you're working on an idea for Swift, you've probably already spent a lot of 
time thinking deeply about it. Working with other people in the community to 
further develop your idea is wonderful, and by the time we're all reviewing the 
code, it's really important that we all think deeply about the problem and 
proposed implementation. The challenge is figuring out how to share this 
information so we can all benefit from the time you've already spent thinking 
about it. When we're all in the same room, it's easy--we just grab a whiteboard 
and take some time. But when we're globally distributed, that's hard.

Previously, we've tried to use the swift-specs repo as a place to share this 
"brain dump" and collaborate on an idea. However, specs-as-code-review has some 
problems:
* spec review distracts from code review
* spec review devolves into bikeshedding at the earliest opportunity
* typos are not what's important in a spec
* specs take a long time to land (in part because of the above)
* once specs have landed, it becomes much harder to ask questions and have 
a conversation about the idea
* where there's some disagreement, no progress is made

The swift-specs repo has become a wasteland of partial ideas where hope goes to 
die.

Moving forward, we want to facilitate communication without encouraging 
despair. We will be stopping any further work in the swift-specs repo. It is, 
as of now, officially dead.

To replace the "shared brain dump" area, we have 
https://wiki.openstack.org/wiki/Swift/ideas where you can add

 Topic -- link to your document

That's it.

Currently-open patches to the swift-specs repo have been landed so they can be 
accessed through the http://specs.openstack.org site. If you write down your 
thoughts and want to share them so others in the community can help you write 
and merge it, add a line to the wiki page. It doesn't matter where you write 
down your thoughts. Use whatever you want. Etherpads, wikis, google docs, slide 
decks, anything. Use what works for you, and please include some contact info 
in your doc (IRC nick, email, etc). I'm looking forward to reading what you're 
thinking about and working with you to implement it.

--John




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

[openstack-dev] [horizon] Angular form framework

[Tripp, Travis S]

Hello everybody,

I sent a message about this direclty to a couple of people for their quick 
thoughts. It looks like there is enough interest that I should have just sent 
it to the whole ML from the start. I’d like to keep folks in the loop, so, I’m 
copying it all below with all of the responses To date.

Thanks,
Travis

From: "Borland, Matt" >

That sounds great, it would be good to use something we don’t have to maintain. 
 Timur, thanks for researching that!

Matt

From: Timur Sufiev [mailto:tsuf...@mirantis.com]

Folks,

I was going to research this library as the possible prerequisite to 
angularization murano-dashboard 'dynamic ui' feature. So i'm planning to start 
next week looking into it.

On Mon, 2 May 2016 at 20:21, Thai Q Tran 
> wrote:
I think that it will remove a lot of boilerplate HTML, and is much more 
extensible than the current way of creating forms. But we may need to extend 
the directive to do more things.

The options they provide does not cover the 2 cases that I brought up. 
hz-password and hz-if-* are both directives.
For example: 

This says that if some_rules passes, then show this input, otherwise, hide it. 
Essentially, what we need is the ability to inject additional attrs into each 
form field so that we can include our own directives. If we can somehow extend 
ngSchemaForm to support this, it should work.

Alternately, we can do the policy check in javascript instead. It just means we 
have to use the services directly rather than their directive counterparts 
(most of the directives we have are backed by a service, i.e. hz-if-policy uses 
the policy service). It's less nice but should also work.

Ultimately, I think going this direction is right, as the extensible benefits 
outweighs the declarative readability. There is still a separation of concerns, 
the forms can be declare like how we declare actions today (in a service that 
we can extend).

- Original message -
From: "Rob Cresswell (rcresswe)" >

I’m a pretty big fan of this idea, I’ve mentioned it at basically every meet up 
we’ve had. Building up content like this is a great way of preventing 
duplication.

Thai, the forms can take specific conditions to control their display: 
https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options
 as well as custom form fields, so it looks like that solves both of your 
issues?

Rob

On 27 Apr 2016, at 11:44, tsuf...@mirantis.com 
wrote:

I recall mentioning model-directed generation of forms layout (since they are 
pretty verbose) at Hillsboro midcycle, the response was that 'mixing 
logic/model and presentation is not the best pattern'.

On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran 
> wrote:
Looks interesting, but I'm not too sure it will work for all cases. I can think 
of a few cases where this might not work.

Case 1. We have custom directives that modify existing input forms such as 
hz-password. Not sure how we will be able to incorporate it if we use an 
auto-generated form.

Case 2. We have things like hz-if that we may use to control which form fields 
to show. Again, not sure how this will work if we are auto-generating the form. 
I suppose you would have to do the check in the controller and modify the JSON 
to reflect this. But that will make it less declarative.

- Original message -
From: "Tripp, Travis S" >

Alex Tivelkov at Mirantis mentioned this to me.  Has anybody looked at this to 
see if it is something we might want to incorporate. He said it allows using 
JSON schema definitions to generate forms.  As FYI, the Metadata Definitions in 
Glance are in JSON schema format and many of the services actually provide JSON 
schema of their fields.
ar form framework

http://schemaform.io



__
OpenStack Development Mailing 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] [swift] [searchlight] Swift Searchlight Integration Austin Summit Recap

[Tripp, Travis S]

Hello Swift team,

I sent out a summary of what I believe was discussed at our joint session to 
just [searchlight] and wanted to copy it to the [swift] thread so that we are 
on the same page.  Please take a look and reply with any comments, corrections, 
questions, etc.  Thanks!

Swift Integration

We agreed on the following components:

* Provide a middleware pipeline plugin with direct injection using ES library
* Provide a hook in the container sync work to also interact with the ES 
injection library

Swift Middleware pipeline plugin

We agreed with the team to continue building out the ES indexing library and it 
is okay to have a dependency on the ES client library.  In discussions about 
OSLO messaging, we explored the idea to build ES as a driver for the messaging 
(instead of rabbit). This would allow deployers with Rabbit to use Rabbit and 
those who don’t to go straight to ES. However, there was concern that the 
dependencies [8] that OSLO messaging pulls in are too much for the Swift-only 
deployers like Swiftstack to handle. Swiftstack in particular spoke of how they 
would have to package and support each of those libraries for 7 different OS 
distributions. They did say that if taking “rabbit” out as a default driver for 
oslo.messaging would remove most the dependencies, then this could be 
reconsidered.

Action: See how much the oslo.messaging dependencies are reduced when the 
rabbit driver isn’t included.

[8] https://pypi.python.org/pypi/oslo.messaging

There was discussion about increasing performance of indexing by only indexing 
in bulk. The idea was suggested to use Green threads to implement a very simple 
batch queuing system.  It would just collect incoming data requests and given a 
certain configurable number (e.g. 20, 200, etc) at which point it would flush 
the queue and send a batch of requests to ES.  It was agreed this could be a 
follow-on patch.

The spec [9] for this library will be updated appropriately.

[9] https://review.openstack.org/#/c/305404/

Swift Container Sync

This is something  which Timur Alperovich is working on and was originally just 
going to do internal swift-y things [10].  However, they’ve decided that they 
would make it a bit smarter and able to handle plugging the direct ES indexer 
library into it. It would then provide backup indexing to the middleware (cache 
coherency kind of concepts).

[10] 
http://docs.openstack.org/developer/swift/overview_container_sync.html#what-s-going-on-behind-the-scenes-in-the-cluster
__
OpenStack Development Mailing 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][osc] Use of openstack client for admin commands

[Edward Leafe]

On May 4, 2016, at 3:53 PM, Jay Pipes  wrote:

> My position is that if it's an HTTP API (as opposed to something like a 
> sqlalchemy-migrate sync command) then it belongs in a client that speaks the 
> OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a 
> difference between "admin" commands and "standard" commands.

Exactly. If it's an admin command and you're not an admin, you get an error. No 
need for a separate client.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] Austin summit cells v2 session recap

[Tripp, Travis S]

Thanks for these notes, Matt. Couple of comments inline.





On 5/2/16, 7:32 PM, "Matt Riedemann"  wrote:

>Andrew Laski led a double session for cells v2 on Wednesday afternoon. 
>The full session etherpad is here [1].
>
>Andrew started with an overview of what's done and what's in progress. 
>Note that some of the background on cells, what's been completed for 
>cells v2 and what's being worked on is also in a summit video from a 
>user conference talk that Andrew gave [2].
>
>Pagination
>--
>
>This took a significant portion of the second cells v2 session and is 
>one of the more complicated problems to sort out. There are problems 
>with listing all instances across all cells especially when we support 
>sorting. And we really have a latent bug in the API since we never 
>restricted the list of valid sort keys for listing instances, so you can 
>literally sort on anything in the instances table in the DB.
>
>There were some ideas about how to handle this:
>
>1. Don't support sorting in the API if you have multiple cells. Leave it 
>up to the caller to sort the results on their own. Obviously this isn't 
>a great solution for existing users that rely on this in the API.
>
>2. Each cell sorts the results individually, and the API merge sorts the 
>results from the cells. There is still overhead here.
>
>3. Don't split the database, or use a distributed database like Redis. 
>Since this wasn't brought up in person in the session, or on Friday, it 
>wasn't discussed. There is another thread about this though [4].
>
>4. Use the OpenStack Searchlight project for doing massive queries like 
>this. This would be optional for a cell of one but recommended/required 
>for anyone running multiple cells. The downside to this is it's a new 
>dependency, and requires Elasticsearch (but many deployments are 
>probably already running an ELK stack for monitoring their logs). It's 
>also unclear at an early stage how easy this would be to integrate into 
>Nova. Plus deployers would need to setup Searchlight to listen to 
>notifications emitted from Nova so the indexes are updated in ES. It is, 
>however, arguably a better tool for the job than Nova trying to deal 
>with filtering and sorting with python. There is general agreement 
>within the core team that this is the path forward, but it's going to 
>require investigation and testing before we get a better idea of how 
>feasible this is.


I’ve spoken about this with some members of the Searchlight team and we
would like to do whatever we can to support this effort, so please let us
know how we can best help out here.

From our standpoint, versioned notifications with enough data that we
don’t have to do any callbacks to fill in the gaps at indexing time has
been placed among our top priorities for Newton. We had a fishbowl
at the summit on notifications and Jay introduced a couple of us to
Gibi. So, we’ll be getting involved as consumers of that effort very
shortly.


>
>Related to paging, we also have an existing problem with the marker that 
>will need to be sorted out before we can support multiple cells with v2. 
>Flavors are now in the API DB, and we return a marker for paging, but it 
>doesn't have the cell context, so we have to work that in. The good news 
>is we control the marker and we never documented anywhere that it's a 
>specific resource uuid (although for instances it is the last instance 
>uuid processed). So this is fixable, but is a known issue right now.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] OSC transition

[Na Zhu]

Hi Darek,

Thanks your information, but the BGP commands are not list in here 
https://etherpad.openstack.org/p/osc-neutron-support :(



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Darek Smigiel 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   2016/05/05 02:34
Subject:Re: [openstack-dev] [neutron] OSC transition




On May 4, 2016, at 6:10 AM, Na Zhu  wrote:

Hi Richard,

I read the contents in the link, I think the discussion in Austin summit 
have not updated to the webpage.
But from here 
https://etherpad.openstack.org/p/newton-neutron-future-neutron-client, it 
mentions python-neutronclient provides OSC plugin for neutron-*aas,
does it mean all neutron-*aas CLIs still live in python-neutronclient 
repo? If yes, should every neutron-*aas owner updates the CLIs from 
neutron to openstack?

I found Dean Troyer set the [Blueprint neutron-client] implement neutron 
commandsstate to obsolete, does the OSC transition continue move along?


Transition is in progress. Here you have spec for it [1]. Probably the 
most important thing for you is this [2] where all required commands are 
described.


[1] 
http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html
[2] https://etherpad.openstack.org/p/osc-neutron-support

Darek Smigiel (dasm)
__
OpenStack Development Mailing 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] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Amrith Kumar]

As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.

To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.

I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I've logged that in Launchpad [4].

Thanks,

-amrith

[1] https://review.openstack.org/#/c/312805/
[2] https://review.openstack.org/#/c/312806/
[3] https://launchpad.net/trove-image-builder
[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454



From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical details of how image building happens and 
their nuances - assuming that ease of use & having a simple interface to build 
secure images matters most, I wonder if the end-users would be concerned about 
these details.

By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove guest 
agent code & configuration files
- managing environment variables better

I believe it will make a huge improvement in terms of simplifying and improving 
the ease of use for end users and hence could be the low hanging fruit that we 
can implement in the mean time. I agree that switching from DIB to any other 
tool is a big step and we need to put alot of thought into it like many others 
have suggested. Like Pete mentioned earlier in one of the links, there are 
couple of other tools available for building images. I am sure we could make 
the case for each of these tools and how it is easier/faster/better than the 
others. If we go down this route experimenting with libguestfs, is there 
anything stopping us couple of releases down the lane from wanting to 
experiment with some other tool because libguestfs doesn't perform well? The 
end user could use any tool they want to use to create images if they wish to 
do so but I agree and believe that Trove should support a standard way of 
building images (DIB being an OpenStack project, I would assume that would be 
the standard) and do it well keeping it simple and easy to use as opposed to 
what it is today.

I think we should split this into 2 tasks
- one for going forward with seperating image building into a seperate 
repository and putting all efforts into simplifying the current process, and
- second, to have a joint collaboration with the DIB/TripleO team to raise 
concerns regarding DIB and see if we can address them in turn OR if using a 
different tool like libguestfs makes sense at that point.

Thanks,
Mariam.

[Inactive hide details for Peter MacKinnon ---05/04/2016 12:39:15 PM---On 
5/4/16 12:52 PM, Gregory Haynes wrote: > On Wed, May 4]Peter MacKinnon 
---05/04/2016 12:39:15 PM---On 5/4/16 12:52 PM, Gregory Haynes wrote: > On Wed, 
May 4, 2016, at 08:55 AM, Flavio Percoco wrote:

From: Peter MacKinnon >
To: openstack-dev@lists.openstack.org
Date: 05/04/2016 12:39 PM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove





On 5/4/16 12:52 PM, Gregory Haynes wrote:
> On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
>> On 04/05/16 15:05 +, Amrith Kumar wrote:
>>> I'm emailing the ML on the subject of a review ongoing in the Trove project 
>>> regarding image building[1].
>>>
>>> TL;DR
>>>
>>> One of the most frequent questions that new users of Trove ask is how and 
>>> where to get guest images with which to experiment with Trove, and how to 
>>> build these images for themselves. While documentation about this exists in 
>>> multiple places (including [2], [3]) this is still something that can do 
>>> with 

[openstack-dev] [tricircle]PTL election of Tricircle for Newton release

[joehuang]

Hello,

As discussed in yesterday weekly meeting, PTL nomination period from May 9 ~ 
May 13, election from May 16 ~ May 20 if more than one nomination . If you want 
to be the PTL for Newton release of Tricircle, please send your self nomination 
letter in the mail-list. You can refer to the nomination letter of other 
projects, for example, Kuryr[1], Glance[2], Neutron[3], others can also be 
found in [4]


[1]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Kuryr/Gal_Sagie.txt
[2]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Glance/Nikhil_Komawar.txt
[3]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Neutron/Armando_Migliaccio.txt
[4]https://wiki.openstack.org/wiki/PTL_Elections_March_2016

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Wednesday, May 04, 2016 5:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] Requirements for becoming approved 
official project

Hi Team,

There is an additional work to become an official (approval) project.
Once we complete PTL election with everyone's consensus, we need to update 
projects.yaml. [1] I think that the OSPF to become approval project is to elect 
PTL, then talk to other PTLs of other projects.

[1] https://github.com/openstack/governance/blob/master/reference/projects.yaml

Cheers,
Shinobu


On Mon, May 2, 2016 at 10:40 PM, joehuang  wrote:
> Hi, Shinobu,
>
> Many thanks for the check for Tricircle to be an OpenStack project, and 
> Thierry for the clarification. glad to know that we are close to OpenStack 
> offical project criteria.
>
> Let's discuss the initial PTL election in weekly meeting, and start initial 
> PTL election after that if needed.
>
> Best Regards
> Chaoyi Huang ( joehuang )
> 
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 02 May 2016 18:48
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Requirements for becoming 
> approved official project
>
> Hi Thierry,
>
> On Mon, May 2, 2016 at 5:45 PM, Thierry Carrez  wrote:
>> Shinobu Kinjo wrote:
>>>
>>> I guess, it's usable. [1] [2] [3], probably and more...
>>>
>>> The reason why still I can just guess is that there is a bunch of 
>>> documentations!!
>>> It's one of great works but too much.
>>
>>
>> We have transitioned most of the documentation off the wiki, but 
>> there are still a number of pages that are not properly deprecated.
>>
>>> [1] https://wiki.openstack.org/wiki/PTL_Guide
>>
>>
>> This is now mostly replaced by the project team guide, so I marked 
>> this one as deprecated.
>
> Honestly, frankly we should clean up something deprecated since there 
> is a bunch of documentations -; It's really hard to read every singe 
> piece...
>
> Anyway better than nothing though.
>
>>
>> As far as initial election goes, if there is a single candidate no 
>> need to organize a formal election. If you need to run one, you can 
>> use CIVS
>> (http://civs.cs.cornell.edu/) since that is what we use for the 
>> official
>> elections: 
>> https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
>
> Thank you for pointing it out.
> That is really good advice.
>
>>
>> Regards,
>>
>> --
>> 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
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
>  OpenStack Development Mailing 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



--
Email:
shin...@linux.com
shin...@redhat.com

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

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

[openstack-dev] [nova][cinder] Austin summit nova/cinder cross-project session recap

[Matt Riedemann]

On Thursday morning the Nova and Cinder teams got together for a 
cross-project design summit session. The full etherpad is here [1].


This was all about volume multi-attach.

A subset of people from both teams were actually meeting weekly for four 
weeks leading up to the summit to hash out some details which we hoped 
to resolve at the summit. Unfortunately that didn't happen.


The first thing we wanted to settle was why do we actually want/need to 
support volume multi-attach? Because "Cinder added it to their API in 
Juno so Nova needs to support it" isn't a good reason. There are a few 
drivers for this feature:


* The need for active/active and active/hot standby scenarios which 
can't accept downtime due to attaching a new volume.


* Some database clusters, like Oracle RAC, require shared volumes. So 
Trove is a stakeholder for this feature also.


* Other legacy application use cases were brought up that essentially 
mean this is something they need to bridge a gap to adopting OpenStack.


So we agreed that while this is not really something we necessarily like 
(because of the non-cloud legacy application nature of it), it is 
necessary so we're going to continue trying to make it happen.


We then quickly went over what was completed in Mitaka and explained the 
detach issue we ran into. The problem is when you have more than one 
volume attached to the same instance on the same host, when you detach 
one of them, both of the volume connections actually get terminated on 
the host.


This problem is also complicated by the fact that some Cinder backends 
will create one attachment per export/volume, whereas others will 
multiplex all volumes onto one attachment.


Coming into the session we really had two competing solutions from the 
Cinder team, one from Walter Boring and one from John Griffith. However, 
during the session another idea was brought up from Dan Smith. The full 
details are in the etherpad, but it's really an idea to abstract the 
multiple volume attachments on the Cinder side that Nova only sees a 
single volume, so Nova wouldn't have to change any of it's API handling 
for Cinder volumes to be checking if they support multiattach or not, 
and thus have to have conditional logic spread all over Nova (API, 
compute, and virt drivers).


With Dan's idea we'd still have the disconnect/detach problem where Nova 
would need to check if it can disconnect from the host if there is only 
a single attachment left, but Nova has to do that regardless for all of 
the proposed solutions.


It sounded like John Griffith had a similar idea before when looking at 
this problem, and we spent a fair amount of time discussing it on both 
sides during the session.


At the end of the session, we (Nova) came away with the following next 
steps:


1. John Griffith (Cinder team) would work on a proof of concept for the 
abstracted volume idea.


2. Cinder would work on adding a volume migration test to Tempest to be 
run in the multi-node gate job (this needs to happen regardless). Scott 
D'Angelo is going to work on this.


3. Ildikó Váncsa was going to work on the Nova volume disconnect ref 
counting logic.


4. We'd meet on Friday during the Nova meetup session to discuss more 
details.


--

So what happened then was we met on Friday and found out that we were 
all speaking different languages on Thursday, because the Cinder team 
didn't think that they were going to be going with this new abstracted 
volume idea. After much wailing and gnashing of teeth we agreed to do a 
hangout shortly after the summit to try and get back on the same page. 
So we're doing that tomorrow (5/5) at 1600 UTC. This is going to be at 
least myself, Ildikó, Scott and Walter on the call. Walter has been 
creating diagrams of the flows through Nova and Cinder for various 
interactions like attach/detach of volumes and volume-backed live 
migration so that we can try to step back and see where the proposed 
changes fit in.


It's sounding like regardless of solution there will be changes to the 
Cinder API (at least for os-initialize_connection). There might be some 
new APIs too, for example, an API to get connection_info during live 
migration without Nova having to call os-initialize_connection to get it.


So we'll see what happens. We'll eventually figure out. After all, it's 
only code, right? :)


[1] https://etherpad.openstack.org/p/newton-nova-cinder

--

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] [tricircle]Proposing Shinobu Kinjo for Tricircle core reviewer

[Yipei Niu]

+1. He is experienced and helps me a lot. He is qualified to be a core
reviewer.


Best regards,

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

Re: [openstack-dev] [tc] supporting Go

[Anita Kuno]

On 05/04/2016 08:25 PM, Tom Fifield wrote:
> On 04/05/16 01:58, John Dickinson wrote:
>> TC,
>>
>> In reference to
>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and
>> Thierry's reply, I'm currently drafting a TC resolution to update
>> http://governance.openstack.org/resolutions/20150901-programming-languages.html
>> to include Go as a supported language in OpenStack projects.
>>
>> As a starting point, what would you like to see addressed in the
>> document I'm drafting?
> 
> Hi,
> 
> Not a TC member, and this might not even be the right place for this,
> but ... I think it would be nice if someone has a think about how moving
> from a primarily single language community to a
> multiple-languages-allowed-in-a-bigger-way community impacts the
> "people" side of the community. Then, possibly write that down, maybe
> even with things that we could do to address any badness foreseen.
> 
> 
> Regards,
> 
> Tom
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks Tom:

I think this is the place for that comment.

Thanks,
Anita.

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

Re: [openstack-dev] [tc] supporting Go

[Tom Fifield]

On 04/05/16 01:58, John Dickinson wrote:

TC,

In reference to 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
Thierry's reply, I'm currently drafting a TC resolution to update 
http://governance.openstack.org/resolutions/20150901-programming-languages.html 
to include Go as a supported language in OpenStack projects.

As a starting point, what would you like to see addressed in the document I'm 
drafting?


Hi,

Not a TC member, and this might not even be the right place for this, 
but ... I think it would be nice if someone has a think about how moving 
from a primarily single language community to a 
multiple-languages-allowed-in-a-bigger-way community impacts the 
"people" side of the community. Then, possibly write that down, maybe 
even with things that we could do to address any badness foreseen.



Regards,

Tom

__
OpenStack Development Mailing 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] Development track: completing the Mitaka backlog - report

[Armando M.]

Hi Neutrinos,

During session [1] we went over the following items:

a) specs in the backlog
b) any item that was targeted for M and rolled over automatically to N-1
c) RFE that were either approved, or expired

The objective of the session was to ensure that we took a moment to focus
on the stuff that was targeted for Mitaka or was on the Mitaka radar and
fell through the cracks for one reason or another.

We revived a few items, push a few others through the gate and put the last
nail on the coffin for some. If you have been unable to attend or
participate, please take a moment to see if there is anything that is still
relevant to you and update the respective links by either restoring gerrit
patches, unexpiring launchpad bugs, and providing a status update either on
Launchpad or this thread.

Happy hacking!
Armando

[1] https://etherpad.openstack.org/p/newton-neutron-core-mitaka-backlog
__
OpenStack Development Mailing 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] [kolla] xenial or trusty

[Emilien Macchi]

FYI all blockers that we have in puppet CI:
https://etherpad.openstack.org/p/puppet-openstack-xenial

HTH

On Wed, May 4, 2016 at 4:20 PM, Carlos Cesario - Tecnomega
 wrote:
> Hi folks,
>
> Based in that request, it follows a proposed patch to add support to Ubuntu 
> Xenial - 16.04.
>
> For while, instead to locking distro version in branches this can be used, 
> since Mitaka version is supported by Ubuntu Trusty and Xenial versions.
>
> http://paste.openstack.org/show/496142/
>
> Comments and tests are welcome. If is it ok, I can provide a patch set.
>
> Best regards,
>
> Carlos
>
> __
>
>
> 
> De: Emilien Macchi 
> Enviado: quarta-feira, 4 de maio de 2016 15:21:14
> Para: OpenStack Development Mailing List (not for usage questions)
> Assunto: Re: [openstack-dev] [kolla] xenial or trusty
>
> On Wed, May 4, 2016 at 1:52 PM, Jeffrey Zhang  wrote:
>> I'd like to lock the tag version in certain branch. One branch only support
>> one
>> distro release.
>>
>> For example, the mitaka branch only build on Trusty and the master/newton
>> branch
>> only build on Xenial.
>>
>> So, the branch and OS matrix should like ( fix me and the ?)
>>
>>   Ubuntu CentOS Debian  OracleLinux
>> Liberty14.047  ? ?
>> Mitaka 14.047  ? ?
>> Master 16.047  ? ?
>
> FWIW, this is what we plan to do in Puppet OpenStack CI (except we
> don't gate on OracleLinux & Debian).
>
>> this is enough and easy to maintain.
>>
>> On Thu, May 5, 2016 at 1:14 AM, Mauricio Lima 
>> wrote:
>>>
>>> Which will be the default when kolla begin to support xenial? Xenial or
>>> Trusty?
>>>
>>> One proposal is to support both, at least in this beginning and just do
>>> some checks to get which version that the user is using.
>>>
>>> Regards,
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

[Nikhil Komawar]

Thanks Christopher for a really nice summary!


On 5/4/16 7:37 PM, Christopher Aedo wrote:
> Hello!  At the summit I was excited to have many conversations with
> folks who are already using the Community App Catalog regularly, and
> many others who plan to increase their level of participation in the
> months to come - I'm really happy to see the continued interest in
> this effort.  For those that were unable to join us in Austin, I
> wanted to provide a brief summary of what we covered and discussed
> during our fishbowl and design sessions.  We tracked everything on an
> etherpad[1] which captures the details.
>  
> During the fishbowl session we talked about some of the new things we
> implemented in the last cycle including the addition of TOSCA assets
> to the catalog and a bunch of new tests that we added to the Horizon
> plugin.  We also had an opportunity to discuss our plans to integrate
> Glare as a backend for the catalog and everything that will allow us
> to do. The most visible bits will be the ability for users to provide
> feedback and ratings for assets in addition to subscribing to an asset
> so they can be notified when the asset is updated.  We are planning to
> complete implementation of the Glare backend within the next four months.
>  
> Following the fishbowl session we had two work sessions during which
> we agreed on a few notable things, and the one which will have the
> most impact is closer coordination and integration with Murano.  This
> will include coordinated efforts on the UI side as well as the OSC
> work we've been doing.  The broader intention is to disambiguate the
> two projects in order to make it clear the Community App Catalog is
> the community run central repository for "things that run on OpenStack
> clouds" while still aiming for tight integration where appropriate.
>  
> We will have two cross-project specs coming in the next month to
> detail these efforts and make clear our intentions and where things
> will overlap.
> Thanks again to everyone who was able to attend our sessions, and to
> all those who continue to help us build up the Community App Catalog!
>  
> -Christopher
> [1]: https://etherpad.openstack.org/p/AUS-app-catalog
>  
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


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

[openstack-dev] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

[Christopher Aedo]

Hello!  At the summit I was excited to have many conversations with folks who are already using the Community App Catalog regularly, and many others who plan to increase their level of participation in the months to come - I'm really happy to see the continued interest in this effort.  For those that were unable to join us in Austin, I wanted to provide a brief summary of what we covered and discussed during our fishbowl and design sessions.  We tracked everything on an etherpad[1] which captures the details.
 
During the fishbowl session we talked about some of the new things we implemented in the last cycle including the addition of TOSCA assets to the catalog and a bunch of new tests that we added to the Horizon plugin.  We also had an opportunity to discuss our plans to integrate Glare as a backend for the catalog and everything that will allow us to do. The most visible bits will be the ability for users to provide feedback and ratings for assets in addition to subscribing to an asset so they can be notified when the asset is updated.  We are planning to complete implementation of the Glare backend within the next four months.
 
Following the fishbowl session we had two work sessions during which we agreed on a few notable things, and the one which will have the most impact is closer coordination and integration with Murano.  This will include coordinated efforts on the UI side as well as the OSC work we've been doing.  The broader intention is to disambiguate the two projects in order to make it clear the Community App Catalog is the community run central repository for "things that run on OpenStack clouds" while still aiming for tight integration where appropriate.
 
We will have two cross-project specs coming in the next month to detail these efforts and make clear our intentions and where things will overlap.
Thanks again to everyone who was able to attend our sessions, and to all those who continue to help us build up the Community App Catalog!
 
-Christopher
[1]: https://etherpad.openstack.org/p/AUS-app-catalog
 


__
OpenStack Development Mailing 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] [puppet] Switch our CI to deploy on Ubuntu Xenial (new LTS)

[Emilien Macchi]

Hi,

I started to try deploying OpenStack on Ubuntu Xenial using our Puppet
modules and I hit a lot of issues, referenced in this etherpad:
https://etherpad.openstack.org/p/puppet-openstack-xenial

We need to solve them all as soon as possible, because we're going to
gate on Xenial starting from Newton (Newton won't be packaged in
Trusty).
If you're willing to work with us, please have a look at the etherpad
and feel free to put your name and take actions.

Thanks for your help,
-- 
Emilien Macchi

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

[openstack-dev] [app-catalog] App Catalog IRC meeting Thursday May 5th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for May 5th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing you there tomorrow!

-Christopher

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

Re: [openstack-dev] [neutron][stable] - exception for stable/kilo DVR back-ports

[Kevin Benton]

So I was doing some testing and this looks like it will happen very quickly
after an agent restarts.

The rule priorities are stored as a set and are allocated from by calling
.pop(). In local testing, it looks like that pretty consistently pulls the
first priority off of the range. http://paste.openstack.org/show/496168/

This means that after restarting an l3 agent, a newly associated floating
IP will likely have the same priority as another one already on the agent.
Then when either floating IP is disassociated, it will break the other one.

On Wed, May 4, 2016 at 3:20 PM, Armando M.  wrote:

>
>
> On 4 May 2016 at 14:26, Assaf Muller  wrote:
>
>> On Wed, May 4, 2016 at 4:54 PM, Kevin Benton  wrote:
>> > Hello,
>> >
>> > I would like to propose a freeze exception for
>> > https://review.openstack.org/#/c/312253/ and
>> > https://review.openstack.org/#/c/312254/ . They address a bug in DVR
>> that
>> > causes floating IPs to eventually break after an L3 agent has been
>> > restarted. It's a serious bug but it's very subtle because it takes a
>> busy
>> > system and bad luck to trigger it.
>> >
>> > If we decide against the back-port a workaround could be to advise all
>> > distros/operators to call the namespace cleanup script every time the l3
>> > agent is restarted, which would prevent this issue, but at the cost of
>> > disrupting traffic on the agent restart.
>>
>> That's not something I could seriously suggest to users, meaning that
>> said users will just cherry pick these patches anyway. Might as well
>> prevent the pain proactively and merge it to stable/kilo.
>>
>
> Bear in mind that we don't test DVR on kilo [1] and taking into
> consideration also the likelihood of the issue, I would advise against the
> backport.
>
> [1]
> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L2261
>
>
>>
>> >
>> >
>> > Cheers,
>> > Kevin Benton
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

[Steve Martinelli]

+100 Jay

On Wed, May 4, 2016 at 4:53 PM, Jay Pipes  wrote:

> On 05/04/2016 01:08 PM, Chris Dent wrote:
>
>>
>> The plans for generic resource pools[1] include a suite of new
>> commands for creating and updating resource pools. In today's Nova
>> API meeting[2] and afterwards in #openstack-nova[3] we discussed two
>> issues:
>>
>> * Since the placement API associated with resource pools is eventually
>>going to be hoisted out of nova it will be developed in a decoupled
>>fashion within the nova tree. It makes sense to also hoist the client
>>libraries in the same fashion. The canonical plan for CLIs is to
>>plug in to OSC.
>>
>> * There's some confusion on whether commands that are destined for
>>admins and services but not end users are "supposed" to be in OSC.
>>
>> Since then the spec has been updated to reflect using OSC but the
>> question of whether this is in fact the right place for this style
>> of commands remains open. Not just for this situation, but
>> generally.
>>
>> Is there an official word on this? If not, should we make one?
>>
>
> My position is that if it's an HTTP API (as opposed to something like a
> sqlalchemy-migrate sync command) then it belongs in a client that speaks
> the OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a
> difference between "admin" commands and "standard" commands.
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][stable] - exception for stable/kilo DVR back-ports

[Armando M.]

On 4 May 2016 at 14:26, Assaf Muller  wrote:

> On Wed, May 4, 2016 at 4:54 PM, Kevin Benton  wrote:
> > Hello,
> >
> > I would like to propose a freeze exception for
> > https://review.openstack.org/#/c/312253/ and
> > https://review.openstack.org/#/c/312254/ . They address a bug in DVR
> that
> > causes floating IPs to eventually break after an L3 agent has been
> > restarted. It's a serious bug but it's very subtle because it takes a
> busy
> > system and bad luck to trigger it.
> >
> > If we decide against the back-port a workaround could be to advise all
> > distros/operators to call the namespace cleanup script every time the l3
> > agent is restarted, which would prevent this issue, but at the cost of
> > disrupting traffic on the agent restart.
>
> That's not something I could seriously suggest to users, meaning that
> said users will just cherry pick these patches anyway. Might as well
> prevent the pain proactively and merge it to stable/kilo.
>

Bear in mind that we don't test DVR on kilo [1] and taking into
consideration also the likelihood of the issue, I would advise against the
backport.

[1]
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L2261


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

Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

[Fox, Kevin M]

I think part of the problem with the whole Swift situation is that it does 
something most other OpenStack projects don't do. Its both a control plane and 
a data plane.

For example, Cinder provides a unified api and provides plugins to allow 
vendors to plug in their particular special sauce in. Through flavors, multiple 
plugins can be supported at once and everyone can go about doing what they do 
best. It isolates the vendor specific stuff from the api users expect.

Swift is in a strange place where the api is implemented in a way to favor one 
particular vendor backend implementation. The vendor is in the tent which is 
good, but other vendors have legitimate reasons to implement their own variants 
and they can't plugin nicely to the existing thing, which is bad. So, vendors 
have been forced to clean room reimplement the api. This means sites can only 
choose one and only one Swift api endpoint, and OpenStacks can't be tested 
properly. There is a lot of variation in clouds here. Its a common problem, and 
its only going to get worse if we don't start addressing it.

I think one solution would be to formalize the api as part of a plugin api, and 
add a control/multi-flavors service on top that the keystone service catalog 
returns. Initial traffic goes through it to identify which flavor to go to, and 
then things are redirected directly to the endpoint for the particular flavor. 
The current Swift implementation then has a nice place to plugin, so does 
radosgw, and any other vendors too.

I'd love to be able to plugin Swift into our sites, but because we can only 
have one, the various tradoffs have lead us to deploy RadosGW most of the time.

Some legitimate, non conflicting use cases of each category:
 * Swift's great for its advanced features, open community, etc.
 * RadosGW is great if you have an investment in Ceph and don't want to split 
your storage. It also reduces admin costs if you are Ceph already.
* Other vendors provide support for stuff like tape library storage, reducing 
costs for backend storage.

We should not be forcing operators to choose just one of these.

Would this kind of rearrangement help resolve some of the issues? Language 
choice and in tree vs out of tree are separate discussions to testing things 
and being inclusive at that point.

Thanks,
Kevin

From: Monty Taylor [mord...@inaugust.com]
Sent: Wednesday, May 04, 2016 12:47 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] supporting Go

On 05/04/2016 01:31 PM, Fox, Kevin M wrote:
> Explicitly, no. I agree. Implicitly... ? Why bother to even propose joining 
> when you know the rules clearly state that its not acceptable? I don't claim 
> to know what has gone on internally in such teams. I'm just saying just 
> because there hasn't been visible signs here of exclusion doesn't mean 
> exclusion hasn't happened.

At no point in time has the C++ nature of ceph EVER been even an
implicit blocker for any actions that were desired by either OpenStack
or Ceph.

There are other issues, such as it being an alternate/competing
implementation to an existing OpenStack service that was not done by the
existing OpenStack team. If the ceph team were to decide that they
wanted to be an OpenStack project instead of an independent project,
which to my knowledge has never been expressed by them as a desire, that
would be the important thing to discuss - and it's a thing that should
not be taken lightly.

As it is, the desire has not be expressed, nor has it be deflected, nor
has it been blocked. If any of those things _had_ happened, C++ would
not have been nor would it be a relevant or interesting part of the
discussion.


> Thanks,
> Kevin
> 
> From: Pete Zaitcev [zait...@redhat.com]
> Sent: Wednesday, May 04, 2016 10:40 AM
> To: Fox, Kevin M
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] supporting Go
>
> On Tue, 3 May 2016 22:37:30 +
> "Fox, Kevin M"  wrote:
>
>> RadosGW has been excluded from joining the OpenStack community in part
>> due to its use of c++.
>
> Sounds like sheer lunacy. Nothing like that ever happened, AFAIK.
>
> -- Pete
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

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

[openstack-dev] [release] prioritizing our task list for newton

[Doug Hellmann]

Team,

I've taken a stab at adding milestone-based priorities to our task list
in https://etherpad.openstack.org/p/newton-relmgt-plan by prepending N1,
N2, or N3 to the TODO items that I think we need to finish by one of
those milestones. This is a continuation of the discussion we started
Friday at the summit, so it's all still up for debate. Please review the
page and leave notes if you think something that isn't prioritized
should be or if a priority seems wrong. We'll discuss the results at the
meeting next week.

Thanks,
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] [neutron][stable] - exception for stable/kilo DVR back-ports

[Assaf Muller]

On Wed, May 4, 2016 at 4:54 PM, Kevin Benton  wrote:
> Hello,
>
> I would like to propose a freeze exception for
> https://review.openstack.org/#/c/312253/ and
> https://review.openstack.org/#/c/312254/ . They address a bug in DVR that
> causes floating IPs to eventually break after an L3 agent has been
> restarted. It's a serious bug but it's very subtle because it takes a busy
> system and bad luck to trigger it.
>
> If we decide against the back-port a workaround could be to advise all
> distros/operators to call the namespace cleanup script every time the l3
> agent is restarted, which would prevent this issue, but at the cost of
> disrupting traffic on the agent restart.

That's not something I could seriously suggest to users, meaning that
said users will just cherry pick these patches anyway. Might as well
prevent the pain proactively and merge it to stable/kilo.

>
>
> Cheers,
> Kevin Benton
>
> __
> OpenStack Development Mailing 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] API docs now publishing from our tree

[Ruby Loo]

Sweet. Thanks Jim (and everyone else that made this happen).

I do want to make sure there is one "source of truth" to the API
documentation. We are already generating REST API documentation at
http://docs.openstack.org/developer/ironic/webapi/v1.html. The info for
this comes from docstrings etc in our code files.

To make it easier and so that documentation doesn't get out of sync, I
don't really want people to have to remember to update the code/docstrings
as well as the new files that were added to generate this new api-ref
documentation.

--ruby


On Wed, May 4, 2016 at 5:10 PM, Jim Rollenhagen 
wrote:

> Hey y'all,
>
> I did the push this week to move the api-ref into our tree, and it's now
> publishing. \o/
>
> The docs are here: http://developer.openstack.org/api-ref/baremetal/
>
> The source is here:
> http://git.openstack.org/cgit/openstack/ironic/tree/api-ref/source
>
> I know devananda is doing a push to update some things there. If you'd
> like to help clean up and improve our docs, please sync with him. They
> need a lot of love, so all help is welcome. :)
>
> // jim
>
> __
> OpenStack Development Mailing 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] [ironic] API docs now publishing from our tree

[Jim Rollenhagen]

Hey y'all,

I did the push this week to move the api-ref into our tree, and it's now
publishing. \o/

The docs are here: http://developer.openstack.org/api-ref/baremetal/

The source is here:
http://git.openstack.org/cgit/openstack/ironic/tree/api-ref/source

I know devananda is doing a push to update some things there. If you'd
like to help clean up and improve our docs, please sync with him. They
need a lot of love, so all help is welcome. :)

// jim

__
OpenStack Development Mailing 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][stable] - exception for stable/kilo DVR back-ports

[Kevin Benton]

Hello,

I would like to propose a freeze exception for
https://review.openstack.org/#/c/312253/ and
https://review.openstack.org/#/c/312254/ . They address a bug in DVR that
causes floating IPs to eventually break after an L3 agent has been
restarted. It's a serious bug but it's very subtle because it takes a busy
system and bad luck to trigger it.

If we decide against the back-port a workaround could be to advise all
distros/operators to call the namespace cleanup script every time the l3
agent is restarted, which would prevent this issue, but at the cost of
disrupting traffic on the agent restart.


Cheers,
Kevin Benton
__
OpenStack Development Mailing 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][osc] Use of openstack client for admin commands

[Jay Pipes]

On 05/04/2016 01:08 PM, Chris Dent wrote:


The plans for generic resource pools[1] include a suite of new
commands for creating and updating resource pools. In today's Nova
API meeting[2] and afterwards in #openstack-nova[3] we discussed two
issues:

* Since the placement API associated with resource pools is eventually
   going to be hoisted out of nova it will be developed in a decoupled
   fashion within the nova tree. It makes sense to also hoist the client
   libraries in the same fashion. The canonical plan for CLIs is to
   plug in to OSC.

* There's some confusion on whether commands that are destined for
   admins and services but not end users are "supposed" to be in OSC.

Since then the spec has been updated to reflect using OSC but the
question of whether this is in fact the right place for this style
of commands remains open. Not just for this situation, but
generally.

Is there an official word on this? If not, should we make one?


My position is that if it's an HTTP API (as opposed to something like a 
sqlalchemy-migrate sync command) then it belongs in a client that speaks 
the OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a 
difference between "admin" commands and "standard" commands.


Best,
-jay

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

Re: [openstack-dev] [ironic] Newton priorities and primary contacts

[Jim Rollenhagen]

On Wed, May 04, 2016 at 02:29:34PM -0400, Ruby Loo wrote:
> Hi,
> 
> At the Austin summit, we had a session where we discussed and decided on
> what the top priorities would be for ironic, in the newton development
> cycle. The etherpad [1] captures that discussion, and there is a patch up
> to add the newton priorities to our specs [2].
> 
> Everyone, and in particular all ironic cores, should take a look at the
> priorities [2] because as a community, we should all have the same
> understanding and be working towards the same goals. Of course, side goals
> are fine too :D
> 
> I also wanted to mention the primary contacts for these priorities, because
> I'm not sure that I have the same understanding as others, as to what it
> means.
> 
> My understanding is that the primary contacts are the folks that would take
> the lead for an item. Their responsibilities would include knowing the
> status of it, and to do their 'best' to get it done, regardless of whether
> they themselves did the design, code, documentation, review, etc. Ideally,
> I'd prefer to see one primary contact per item, but if people want to work
> together, that is fine, as long as it works.

I agree with this description, and I would like folks to go back and
comment on the patch if their name is on something they want to be
responsible for by this definition.

However, I would like more than one person per thing, because 1) HA, and
2) they can help keep each other accountable.

// jim

> If you are interested in a particular feature on this list, or would like
> to contribute code towards that end, or would like to help review, or test,
> that is wonderful and I thank you so much for your interest and desire to
> contribute. However, I would really like to see primary contacts do more,
> as described above. To take responsibility and (try to) commit the
> time/effort it will take to see this priority items through.
> 
> Is this in line with what others think/expect from the primary contacts?
> 
> --ruby
> 
> 
> [1] https://etherpad.openstack.org/p/ironic-newton-summit-priorities
> [2] https://review.openstack.org/#/c/311530/

> __
> OpenStack Development Mailing 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] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Nikhil Komawar]

Comments inline.


On 5/4/16 2:58 PM, Tim Bell wrote:
>
> On 04/05/16 20:35, "Nikhil Komawar"  wrote:
>
>>
>> On 5/4/16 2:09 PM, Tim Bell wrote:
>>> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>>>
 Thanks for the summary and taking care of the setup, Vilobh!

 Pretty meticulously written on what was agreed at the session. Kudos!

 I wanted to add some points that were asked during the Glance
 contributors' meetup:

 * The quota limits will be set on the tables in the service that
 maintains the resources for each individual resource (not in keystone).
 The default value is what is picked from the config. I think over time
 we will come up with implementation detail on how the hierarchical
 default value should be set.

 * The quota allocation calculation will be based on the project
 hierarchy in consideration (given that driver is being used in such
 deployment scenario) and the usage for that resource recorded in the
 resource's quota table in that service. So, this will involve
 interaction with keystone and within the quota table in the project.

 * We will be working on a migration story separately (outside of the
 library). Delimiter does not own the quota limits and usage data so it
 will not deal with migrations.
>>> Given that Glance does not currently have a quota, it may be possible to 
>>> use this as the initial implementation. This would also avoid a later 
>>> migration effort.
>>>
>>> Tim
>>>
>>>
>> Thanks for the response Tim. I am of the same opinion but haven't really
>> internalized this migration path as I've not been on the deploy-er side
>> of managing quota yet. Intuitively migration for quotas seems like a
>> terrible experience, possibly going over days?
>>
>> I presume that nested quota support, if built in from get go, when the
>> tables are set is probably the best idea of hierarchical quota support.
>> Hoping that's not overly pessimistic assumption.
>
> With Glance not having quotas (and a reasonable set of defaults), I think we 
> can make the use of the delimiter functionalities
> optional for Glance at the beginning and thus is a much easier use case than 
> those who have to convert the existing combinations 
> of user/project/nested project quotas for production clouds. A release cycle 
> with Glance quotas in production would also encourage
> further adoption going forward.

I was of the differing opinion wrt to using delimiter's functionalities,
mostly because the lib can and should be configured by the service in a
way the service is setup to be used in keystone -- for nested lib's
nested driver would be used and for flat quotas it's flat driver. Given
the implementation will use some sort of if logic that will read
hierarchy, it would make sense to use the config in the service to use
hierarchical or non-hierarchical driver.

This would allow both existing deployments that do not have complex
hierarchy to use the library and to the new ones that have hierarchy
setup & prefer to use quota out of the box in hierarchical manner. From
the input I gather talking to a bunch of people, the difference between
adding simple quota or hierarchical quota is not significantly larger
than adding the entire functionality in a service (like Glance that
doesn't have quotas). As delimiter is an attempt to solve the
consistency, things should work pretty smoothly for services like Glance.

>
> I would like that nested quotas is not a special case as we deploy delimeter, 
> just business as usual. There are so many varied use cases and flexibility 
> for 
> those who do not need it to make it the standard deployment for delimeter. 
> Clearly, existing installs would need to find a migration
> path but generally, these would not be nested deployments.

I am not sure how far we can draw the line for seamless workflow for
delimiter. The spec [5] mentions on line 198 that default case would be
flat but the existing Glance deployments would be assuming 'Independent
quotas' (comment on line 86). Also, I am looking forward to next meeting
where we can get better picture of the layout of this library.

Basically, I'm saying we need to handle that logic in delimiter anyway
-- either today or later when the usage of the library happens. The risk
of having to migrate 100s of (tenants) projects and may be order of 100K
or more images is what is really scary. Operators do say they have a
massive amount of data in Glance tables -- that makes things worse as we
get requests for support of not just image-data storage quotas but of
#images, #properties, #members, etc. Looks to me like a impossible
migration :/

> A single oslo library gives a good chance to get a consistent implementation 
> across multiple OpenStack components. This would massively 
> simplify the operator and resource manager use cases.

+1

>
> Tim
>
>
 On 5/4/16 1:23 PM, Vilobh Meshram wrote:

Re: [openstack-dev] [tc] supporting Go

[Doug Hellmann]

Excerpts from Fox, Kevin M's message of 2016-05-04 16:49:42 +:
> Ok. Sure. More generically then. There are OpenStack compatible API 
> implementations existing in the world, deployed by a not insignificant number 
> of production clouds, that are currently outside the big tent that may have 
> not considered proposing joining the community because of the past history of 
> Python onlyness in the community. If we're considering Go, should we also be 
> considering C++? Go currently has no production level OpenStack code 
> finished. C++ does.

Independent of the implementation language question, we also have a
policy against "gratuitous" competition:

  Where it makes sense, the project cooperates with existing projects
  rather than gratuitously competing or reinventing the wheel [1]

So, a project that re-implements an existing official project is unlikely
to be a good candidate for official status, no matter what language it
was written in (especially if it was produced following processes that
don't follow the other 4 Open tenets that make up the foundation of our
policy). Although, we haven't had a real case of this, and there are
bound to be case-specific issues that could negate my generalization,
and I'm only one member of the TC.

The policy has, AIUI, always been that if someone wants to use something
other than one of our existing languages, they need to establish both
a really good reason why that is true (to overcome the objections based
on the amount of duplication that might be needed to do things currently
handled by libraries being shared between projects) *and* to step up to
establish the patterns and interfaces to be used to work within our CI
system for all appropriate testing. So, objections to the contrary, I'm
not sure it's useful to continue talking about this in the abstract. If
there's a project that wants to join, we should talk about that project
and whether it meets *all* of our criteria, not just what language it's
in. Hypothetical proposals about projects that aren't actually interested
in joining OpenStack aren't going to lead to useful discussion.

Doug

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



> 
> Thanks,
> Kevin
> 
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: Wednesday, May 04, 2016 3:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] supporting Go
> 
> - Could we kindly stop discussing radosgw at this moment?
> + Could we kindly stop discussing any particular application at this moment?
> 
> On Wed, May 4, 2016 at 7:02 PM, Shinobu Kinjo  wrote:
> > Could we kindly stop discussing radosgw at this moment?
> >
> > On Wed, May 4, 2016 at 6:47 PM, Thierry Carrez  
> > wrote:
> >> Fox, Kevin M wrote:
> >>>
> >>> RadosGW has been excluded from joining the OpenStack community in part due
> >>> to its use of c++.
> >>
> >>
> >> I'm not sure I'd use the word "excluded" since RadosGW was never actually
> >> proposed. Maybe our past Python-centricity discouraged them to apply, but
> >> that's conjecture.
> >>
> >>> Now that we're talking about alternate languages, that may be on the table
> >>> now?
> >>
> >>
> >> It's been a possibility for the last 8 months.
> >>
> >> That said, my personal view is that we should accept additional languages
> >> when the current set of accepted languages is suboptimal for something we
> >> want to write or create. A technical benefit to outweigh the community
> >> fragmentation and increase in infrastructure tasks that result from adding
> >> that language.
> >>
> >> I'm less convinced that we should add a language for the sole benefit of
> >> being able to absorb an existing project into OpenStack which happens to be
> >> written in a specific language. Especially if the then-supported set of
> >> languages could provide the same technical benefits.
> >>
> >> --
> >> 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
> >
> >
> >
> > --
> > Email:
> > shin...@linux.com
> > shin...@redhat.com
> 

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Mariam John]

The way I see this, these are the 2 main concerns I have been hearing
regarding image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the
database elements to a seperate repository and packaging and managing them
from there.

It looks like the case that we make for whether to use libguestfs or DIB
for image building are in the technical details of how image building
happens and their nuances - assuming that ease of use & having a simple
interface to build secure images matters most, I wonder if the end-users
would be concerned about these details.

By addressing some of the issues like:
  - moving the Trove elements to a new repository
  - adding support for new distros
  - creating a wrapper script for building an image -getting the Trove
guest agent code & configuration files
  - managing environment variables better

I believe it will make a huge improvement in terms of simplifying and
improving the ease of use for end users and hence could be the low hanging
fruit that we can implement in the mean time. I agree that switching from
DIB to any other tool is a big step and we need to put alot of thought into
it like many others have suggested. Like Pete mentioned earlier in one of
the links, there are couple of other tools available for building images. I
am sure we could make the case for each of these tools and how it is
easier/faster/better than the others. If we go down this route
experimenting with libguestfs, is there anything stopping us couple of
releases down the lane from wanting to experiment with some other tool
because libguestfs doesn't perform well? The end user could use any tool
they want to use to create images if they wish to do so but I agree and
believe that Trove should support a standard way of building images (DIB
being an OpenStack project, I would assume that would be the standard) and
do it well keeping it simple and easy to use as opposed to what it is
today.

I think we should split this into 2 tasks
  - one for going forward with seperating image building into a seperate
repository and putting all efforts into simplifying the current process,
and
  - second, to have a joint collaboration with the DIB/TripleO team to
raise concerns regarding DIB and see if we can address them in turn OR if
using a different tool like libguestfs makes sense at that point.

Thanks,
Mariam.



From:   Peter MacKinnon 
To: openstack-dev@lists.openstack.org
Date:   05/04/2016 12:39 PM
Subject:Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove



On 5/4/16 12:52 PM, Gregory Haynes wrote:
> On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
>> On 04/05/16 15:05 +, Amrith Kumar wrote:
>>> I'm emailing the ML on the subject of a review ongoing in the Trove
project regarding image building[1].
>>>
>>> TL;DR
>>>
>>> One of the most frequent questions that new users of Trove ask is how
and where to get guest images with which to experiment with Trove, and how
to build these images for themselves. While documentation about this exists
in multiple places (including [2], [3]) this is still something that can do
with some improvement.
>>>
>>> Trove currently uses diskimage-builder for building images used in
testing the product and these can serve as a good basis for anyone wishing
to build an image for their own use of Trove. The review [1] makes the
argument for the libguestfs based approach to building images and advocates
that Trove should use this instead of diskimage-builder.
>> At the summit we discussed the possibility of providing an
implementation
>> that
>> would allow for both DIB and libguestfs to be used but to give priority
>> to DIB.
>> Since there's no real intention of just switching tools at this point, I
>> believe
>> it'd be good to amend the spec so that it doesn't mention libguestfs
>> should be
>> used instead of DiB.
>>
>> The goal at this stage is to provide both and help these move forward.
>>
>>> I believe that a broader discussion of this is required and I
appreciate Greg Haynes' proposal at the design summit to have this
discussion on the ML. I took the action item to bring this discussion to
the ML.
>>>
>>> Details follow ...
>>>
>>> Before going further, I will state my views on these matters.
>>>
>>> 1. It is important for the Trove project to do things quickly to make
it easier for end users who wish to use Trove and who wish to build their
own images. I am not concerned what tool or tools a person will use to
build these images.
> ++. One of the biggest issues I see users of DIB hit is ease of use for
> 'just make me an image, I don't care about twiddling knobs'. A wrapper
> script in trove is one way to help with this, but I am sure there are
> other solutions as well... maybe by rethinking some of our fear about
> using elements as entry points to an 

Re: [openstack-dev] [kolla] xenial or trusty

[Carlos Cesario - Tecnomega]

Hi folks,

Based in that request, it follows a proposed patch to add support to Ubuntu 
Xenial - 16.04.

For while, instead to locking distro version in branches this can be used, 
since Mitaka version is supported by Ubuntu Trusty and Xenial versions.

http://paste.openstack.org/show/496142/

Comments and tests are welcome. If is it ok, I can provide a patch set.

Best regards,

Carlos

__



De: Emilien Macchi 
Enviado: quarta-feira, 4 de maio de 2016 15:21:14
Para: OpenStack Development Mailing List (not for usage questions)
Assunto: Re: [openstack-dev] [kolla] xenial or trusty

On Wed, May 4, 2016 at 1:52 PM, Jeffrey Zhang  wrote:
> I'd like to lock the tag version in certain branch. One branch only support
> one
> distro release.
>
> For example, the mitaka branch only build on Trusty and the master/newton
> branch
> only build on Xenial.
>
> So, the branch and OS matrix should like ( fix me and the ?)
>
>   Ubuntu CentOS Debian  OracleLinux
> Liberty14.047  ? ?
> Mitaka 14.047  ? ?
> Master 16.047  ? ?

FWIW, this is what we plan to do in Puppet OpenStack CI (except we
don't gate on OracleLinux & Debian).

> this is enough and easy to maintain.
>
> On Thu, May 5, 2016 at 1:14 AM, Mauricio Lima 
> wrote:
>>
>> Which will be the default when kolla begin to support xenial? Xenial or
>> Trusty?
>>
>> One proposal is to support both, at least in this beginning and just do
>> some checks to get which version that the user is using.
>>
>> Regards,
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Emilien Macchi

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

__
OpenStack Development Mailing 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] Nominate Major Hayden for core in openstack-ansible-security

[Kevin Carter]

+1 for me too.


--

Kevin Carter
IRC: cloudnull



From: Matthew Thode 
Sent: Tuesday, May 3, 2016 1:50 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-ansible] Nominate Major Hayden for core 
in openstack-ansible-security

On 05/03/2016 01:47 PM, Truman, Travis wrote:
> Major has made an incredible number of contributions of code and reviews
> to the OpenStack-Ansible community. Given his role as the primary author
> of the openstack-ansible-security project, I can think of no better
> addition to the core reviewer team.
>
> Travis Truman
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
+1 because it still means something to me

--
-- Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Amrith Kumar]

> -Original Message-
> From: Gregory Haynes [mailto:g...@greghaynes.net]
> Sent: Wednesday, May 04, 2016 3:52 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
> 
> On Wed, May 4, 2016, at 10:33 AM, Peter MacKinnon wrote:
> >
> > Well, certainly one downside in the case of Trove (and probably
> > elsewhere) with DIB is the src tree matrix of datastore-by-distro
> > elements required to support various guest image combinations, leading
> > to a proliferation of directories and files. We feel this can be greatly
> > simplified using a libguestfs approach using a minimal set of bash and
> > directly applicable data files (e.g., systemd unit files, conf files,
> > etc.).
> >
> 
> I am confused by this, so maybe I am just misunderstanding. Are you
> saying that DIB requires you to support more distro combinations? What
> combination of distros you support is entirely up to trove as a
> downstream and has absolutely nothing to do with the image build tool,
> or maybe you mean something else?
> 

The approach being proposed by Pete is something that is equally applicable to 
DIB, I think. I believe that he makes a valid observation and our current 
element design may in fact be bad.
 
The invocation of DIB[1] is

${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
-x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm heat-cfntools \
cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}

Observe that we include the ${DISTRO} element, and we prefix ${DISTRO} into the 
name of the guest and the database to get, for example,

... ubuntu ubuntu-guest ubuntu-mysql

The minimal set of bash and data files could be used instead and we won't have 
this matrix of datastore-by-distro proliferation that you speak of. That's why 
I believe that this solution is equally applicable to DIB.

[1] trove-integration/scripts/files/functions_qemu



> > >
> > > What seemed very apparent to me in the summit session is that there
> are
> > > a set of issues for Trove relating to image building, mostly relating
> to
> > > reliability and ease of use. There was no one who even mentioned let
> > > alone strongly cared about the issues which actually differentiate the
> > > existing DIB build process from libguestfs (which is isolation). If
> that
> > > has changed for some reason, then my recommendation would be to use a
> > > tool like virt-dib which will allow for a single image building code
> > > base while solving all the raised issues in the spec. I suspect when
> > > this is tried out the downsides to booting a VM will highly outweigh
> the
> > > benefits for almost all users (especially in trove's gate),
> >
> > Anecdotally, it takes the same amount of time for a CentOS7 MySQL build
> > (~ 7 minutes) with either toolchain.
> >
> 
> I suspect this is actually "about the same amount of time with hardware
> virtualization", which the gate does not have. Otherwise, awesome - lets
> just use virt-dib / a libguestfs backend for DIB then.
> 
> > > but if the
> > > libguestfs docs are to be believed this should be trivial to try out.
> >
> > Not quite sure what you mean by "to be believed"?
> >
> 
> Just that it seems trivial to try out and there's no downsides
> mentioned.
> 
> >
> > The various image building frameworks have been noted here
> > http://docs.openstack.org/image-guide/create-images-automatically.html
> > including libguestfs. So it's not like it is an unknown quantity. In the
> > interest of innovation I'm not sure I understand the hearty reluctance
> > to explore this path. We are proposing simply another Trove repo with an
> > alternate (and recognized) image build method. This is not displacing
> > any established tool for Trove; such a tool doesn't exist today. The
> > elements in trove-integration don't really count since they are largely
> > developed for Ubuntu only, inject Trove guestagent src from git only,
> > and, beyond MySQL 5.6, are not tested by the gate.
> >
> 
> The reluctance is that, as you say, the existing set of scripts have
> deficiencies that need to be fixed. Rather than fix them, we are going
> to put effort in to rewriting them to use another tool which does not
> help the existing deficiencies. Distro support is still just as much of
> a trove issue as it is now - its up to the trove scripts to support the
> various distros. It seems a lot more reasonable to fix the problems in
> the scripts rather than rewrite to use another tool given that the
> problems mentioned have nothing to do with the image building tool.
> 
> __
> OpenStack Development Mailing 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] Nominating Michał Dulko to Cinder Core

[Walter A. Boring IV]

+1

Walt

Hey everyone,

I would like to nominate Michał Dulko to the Cinder core team. Michał's
contributions with both code reviews [0] and code contributions [1] have
been significant for some time now.

His persistence with versioned objects has been instrumental in getting
support in the Mitaka release for rolling upgrades.

If there are no objections from current cores by next week, I will add
Michał to the core group.

[0] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
[1]
https://review.openstack.org/#/q/owner:%22Michal+Dulko+%253Cmichal.dulko%2540intel.com%253E%22++status:merged

Thanks!

Sean McGinnis (smcginnis)


__
OpenStack Development Mailing 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] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Gregory Haynes]

On Wed, May 4, 2016, at 10:33 AM, Peter MacKinnon wrote:
> 
> Well, certainly one downside in the case of Trove (and probably 
> elsewhere) with DIB is the src tree matrix of datastore-by-distro 
> elements required to support various guest image combinations, leading 
> to a proliferation of directories and files. We feel this can be greatly 
> simplified using a libguestfs approach using a minimal set of bash and 
> directly applicable data files (e.g., systemd unit files, conf files, 
> etc.).
> 

I am confused by this, so maybe I am just misunderstanding. Are you
saying that DIB requires you to support more distro combinations? What
combination of distros you support is entirely up to trove as a
downstream and has absolutely nothing to do with the image build tool,
or maybe you mean something else?

> >
> > What seemed very apparent to me in the summit session is that there are
> > a set of issues for Trove relating to image building, mostly relating to
> > reliability and ease of use. There was no one who even mentioned let
> > alone strongly cared about the issues which actually differentiate the
> > existing DIB build process from libguestfs (which is isolation). If that
> > has changed for some reason, then my recommendation would be to use a
> > tool like virt-dib which will allow for a single image building code
> > base while solving all the raised issues in the spec. I suspect when
> > this is tried out the downsides to booting a VM will highly outweigh the
> > benefits for almost all users (especially in trove's gate),
> 
> Anecdotally, it takes the same amount of time for a CentOS7 MySQL build 
> (~ 7 minutes) with either toolchain.
> 

I suspect this is actually "about the same amount of time with hardware
virtualization", which the gate does not have. Otherwise, awesome - lets
just use virt-dib / a libguestfs backend for DIB then.

> > but if the
> > libguestfs docs are to be believed this should be trivial to try out.
> 
> Not quite sure what you mean by "to be believed"?
> 

Just that it seems trivial to try out and there's no downsides
mentioned.

> 
> The various image building frameworks have been noted here 
> http://docs.openstack.org/image-guide/create-images-automatically.html 
> including libguestfs. So it's not like it is an unknown quantity. In the 
> interest of innovation I'm not sure I understand the hearty reluctance 
> to explore this path. We are proposing simply another Trove repo with an 
> alternate (and recognized) image build method. This is not displacing 
> any established tool for Trove; such a tool doesn't exist today. The 
> elements in trove-integration don't really count since they are largely 
> developed for Ubuntu only, inject Trove guestagent src from git only, 
> and, beyond MySQL 5.6, are not tested by the gate.
> 

The reluctance is that, as you say, the existing set of scripts have
deficiencies that need to be fixed. Rather than fix them, we are going
to put effort in to rewriting them to use another tool which does not
help the existing deficiencies. Distro support is still just as much of
a trove issue as it is now - its up to the trove scripts to support the
various distros. It seems a lot more reasonable to fix the problems in
the scripts rather than rewrite to use another tool given that the
problems mentioned have nothing to do with the image building tool.

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

Re: [openstack-dev] [tc] supporting Go

[Monty Taylor]

On 05/04/2016 01:31 PM, Fox, Kevin M wrote:

Explicitly, no. I agree. Implicitly... ? Why bother to even propose joining 
when you know the rules clearly state that its not acceptable? I don't claim to 
know what has gone on internally in such teams. I'm just saying just because 
there hasn't been visible signs here of exclusion doesn't mean exclusion hasn't 
happened.


At no point in time has the C++ nature of ceph EVER been even an 
implicit blocker for any actions that were desired by either OpenStack 
or Ceph.


There are other issues, such as it being an alternate/competing 
implementation to an existing OpenStack service that was not done by the 
existing OpenStack team. If the ceph team were to decide that they 
wanted to be an OpenStack project instead of an independent project, 
which to my knowledge has never been expressed by them as a desire, that 
would be the important thing to discuss - and it's a thing that should 
not be taken lightly.


As it is, the desire has not be expressed, nor has it be deflected, nor 
has it been blocked. If any of those things _had_ happened, C++ would 
not have been nor would it be a relevant or interesting part of the 
discussion.




Thanks,
Kevin

From: Pete Zaitcev [zait...@redhat.com]
Sent: Wednesday, May 04, 2016 10:40 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

On Tue, 3 May 2016 22:37:30 +
"Fox, Kevin M"  wrote:


RadosGW has been excluded from joining the OpenStack community in part
due to its use of c++.


Sounds like sheer lunacy. Nothing like that ever happened, AFAIK.

-- Pete


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




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

Re: [openstack-dev] [tc] supporting Go

[Monty Taylor]

On 05/04/2016 11:49 AM, Fox, Kevin M wrote:

Ok. Sure. More generically then. There are OpenStack compatible API 
implementations existing in the world, deployed by a not insignificant number 
of production clouds, that are currently outside the big tent that may have not 
considered proposing joining the community because of the past history of 
Python onlyness in the community. If we're considering Go, should we also be 
considering C++? Go currently has no production level OpenStack code finished. 
C++ does.


To be really clear, we are not considering alternate API 
implementations. OpenStack is not and never has been an API standards 
body. We are an Open Source project that ships code.


This is a case of the swift team themselves being interested in 
replacing part of their implementation with go.


I expect that if someone came up and said "oh hai, I've written a C++ 
version of Nova and y'all should bring it in to the big tent", then my 
response would be much less accommodating.


We do not need to consider whatever languages people might want to use. 
We need to consider concrete things that our actual teams want to 
actually do today.


We are not in the market for OpenStack compatible API implementations. 
This is not us opening the door for those to all of a sudden be "ok"





From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: Wednesday, May 04, 2016 3:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

- Could we kindly stop discussing radosgw at this moment?
+ Could we kindly stop discussing any particular application at this moment?

On Wed, May 4, 2016 at 7:02 PM, Shinobu Kinjo  wrote:

Could we kindly stop discussing radosgw at this moment?

On Wed, May 4, 2016 at 6:47 PM, Thierry Carrez  wrote:

Fox, Kevin M wrote:


RadosGW has been excluded from joining the OpenStack community in part due
to its use of c++.



I'm not sure I'd use the word "excluded" since RadosGW was never actually
proposed. Maybe our past Python-centricity discouraged them to apply, but
that's conjecture.


Now that we're talking about alternate languages, that may be on the table
now?



It's been a possibility for the last 8 months.

That said, my personal view is that we should accept additional languages
when the current set of accepted languages is suboptimal for something we
want to write or create. A technical benefit to outweigh the community
fragmentation and increase in infrastructure tasks that result from adding
that language.

I'm less convinced that we should add a language for the sole benefit of
being able to absorb an existing project into OpenStack which happens to be
written in a specific language. Especially if the then-supported set of
languages could provide the same technical benefits.

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




--
Email:
shin...@linux.com
shin...@redhat.com




--
Email:
shin...@linux.com
shin...@redhat.com

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

__
OpenStack Development Mailing 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][osc] Use of openstack client for admin commands

[Dean Troyer]

On Wed, May 4, 2016 at 1:54 PM, Sean Dague  wrote:

> Given these constraints it was as much of an ask as anything else. Can
> OSC handle this? Should it handle it from a best practices perspective?
> How are commands exposed / hidden based on user permissions? The fact
> that we're going to need a service library mean that a dedicated admin
> API might be appropriate?
>

The only hiding/exposing of commands that OSC does is based on API
versions.  We have no plans to ever get into attempting to evaluate policy
even if/when that information becomes available via API.

That said, I think this belongs in a plugin in the client lib.  We do have
plans to extract the common shell bits of OSC into a library (osc-lib) that
could be used to also make stand-alone CLIs that look and act like OSC,
with only the plugin commands present.  Even assuming only the additional
dependency of the new lib, adding it to the OSC repo would also work, I
just think it makes more sense for these commands to not be present in the
default installation non-cloud-ops users would see.

dt

-- 

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

[openstack-dev] [Neutron] meeting topics for 5/5/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Confirm the CI maintenance ownership
* Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
* Requirement for reference Implementation on OVS driver and OVS Agent 
path for any API extension
* Add support for Querying Driver capability for SFC functionality 
support
* Use case documentation
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Define VNF type (l2 or l3) param in service-function-param
* Add "NSH" encap param in service-chain-param
* Networking-sfc SFC driver for OVN
* Networking-sfc SFC driver for ODL
* Networking-sfc integration with ONOS completion status update
* Tacker Driver for networking-sfc
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
OpenStack Development Mailing 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][osc] Use of openstack client for admin commands

[Tim Bell]

On 04/05/16 20:54, "Sean Dague"  wrote:

>On 05/04/2016 02:16 PM, Dean Troyer wrote:
>> On Wed, May 4, 2016 at 12:08 PM, Chris Dent > > wrote:
>> 
>> Since then the spec has been updated to reflect using OSC but the
>> question of whether this is in fact the right place for this style
>> of commands remains open. Not just for this situation, but
>> generally.
>> 
>> 
>> This came up again last week, and there is still no real consensus as to
>> whether admin-only stuff should be included in the repo or kept in
>> plugins. The things already in the OSC repo are likely to stay for the
>> forseeable future, new things could go either way.
>> 
>> If you are planning a separate client/lib, it would make sense to do the
>> OSC plugin as part of that lib.  That is also a chance to get a really
>> clean Python API that doesn't have the cruft of novaclient
>
>I think that in the case of the new "placement" API we really want to
>give it a fresh start. It will be a dedicated endpoint from day one, and
>the CLI interaction with it should definitely live outside of
>novaclient. First, because there is no need to take a lot of the gorp
>from novaclient forward. Second, because we want it really clear from
>day one that this effort is going to split from Nova, and you can use
>this thing even without Nova.
>
>This will, at some level, be pretty core infrastructure. Nova, Neutron,
>Cinder (at the least, I'm sure more will over time) will need to talk to
>it programatically, and administrators may need to do some hand tuning
>of resource pools to express things that are not yet automatically
>discovered and advertised (or that never really make sense to be).
>
>Given these constraints it was as much of an ask as anything else. Can
>OSC handle this? Should it handle it from a best practices perspective?
>How are commands exposed / hidden based on user permissions? The fact
>that we're going to need a service library mean that a dedicated admin
>API might be appropriate?
>
>   -Sean

As we implement nested projects, the ‘admin’ activities become much more
difficult to define. Typical use case would be if I was the project 
administrator
for the ATLAS project. I would want to be able to define new projects such
as “ATLAS Higgs” with appropriate membership and quota within the limits
defined by the cloud administrator.

My understanding from this transition is that the majority of the project
commands would be ‘standard’, and therefore OSC support is needed if
the universal client CLI goal is to be achieved.

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Jeremy Stanley]

On 2016-05-04 09:52:20 -0700 (-0700), Gregory Haynes wrote:
[...]
> One of the biggest issues I see users of DIB hit is ease of use
> for 'just make me an image, I don't care about twiddling knobs'. A
> wrapper script in trove is one way to help with this
[...]

For example, in openstack-infra/project-config we ship a wrapper
along these lines:

http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh

-- 
Jeremy Stanley

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

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Tim Bell]

On 04/05/16 20:35, "Nikhil Komawar"  wrote:

>
>
>On 5/4/16 2:09 PM, Tim Bell wrote:
>>
>> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>>
>>> Thanks for the summary and taking care of the setup, Vilobh!
>>>
>>> Pretty meticulously written on what was agreed at the session. Kudos!
>>>
>>> I wanted to add some points that were asked during the Glance
>>> contributors' meetup:
>>>
>>> * The quota limits will be set on the tables in the service that
>>> maintains the resources for each individual resource (not in keystone).
>>> The default value is what is picked from the config. I think over time
>>> we will come up with implementation detail on how the hierarchical
>>> default value should be set.
>>>
>>> * The quota allocation calculation will be based on the project
>>> hierarchy in consideration (given that driver is being used in such
>>> deployment scenario) and the usage for that resource recorded in the
>>> resource's quota table in that service. So, this will involve
>>> interaction with keystone and within the quota table in the project.
>>>
>>> * We will be working on a migration story separately (outside of the
>>> library). Delimiter does not own the quota limits and usage data so it
>>> will not deal with migrations.
>> Given that Glance does not currently have a quota, it may be possible to use 
>> this as the initial implementation. This would also avoid a later migration 
>> effort.
>>
>> Tim
>>
>>
>
>Thanks for the response Tim. I am of the same opinion but haven't really
>internalized this migration path as I've not been on the deploy-er side
>of managing quota yet. Intuitively migration for quotas seems like a
>terrible experience, possibly going over days?
>
>I presume that nested quota support, if built in from get go, when the
>tables are set is probably the best idea of hierarchical quota support.
>Hoping that's not overly pessimistic assumption.


With Glance not having quotas (and a reasonable set of defaults), I think we 
can make the use of the delimiter functionalities
optional for Glance at the beginning and thus is a much easier use case than 
those who have to convert the existing combinations 
of user/project/nested project quotas for production clouds. A release cycle 
with Glance quotas in production would also encourage
further adoption going forward.

I would like that nested quotas is not a special case as we deploy delimeter, 
just business as usual. There are so many varied use cases and flexibility for 
those who do not need it to make it the standard deployment for delimeter. 
Clearly, existing installs would need to find a migration
path but generally, these would not be nested deployments.

A single oslo library gives a good chance to get a consistent implementation 
across multiple OpenStack components. This would massively 
simplify the operator and resource manager use cases.

Tim


>
>>>
>>> On 5/4/16 1:23 PM, Vilobh Meshram wrote:
 Hi All,

 For people who missed the design summit session on Delimiter - Cross
 project Quota enforcement library here is a gist of what we discussed.
 Etherpad [1] captures the details. 

 1. Delimiter will not be responsible for rate-limiting.
 2. Delimiter will not maintain data for the projects.
 3. Delimiter will not have the concept of reservations.
 4. Delimiter will fetch information for project quotas from respective
 projects.
 5. Delimiter will consolidate utility code for quota related issues at
 common place. For example X, Y, Z companies might have different
 scripts to fix quota issues. Delimiter can be a single place for it
 and the scripts can be more generalized to suit everyones needs.
 6. The details of project hierarchy is maintained in Keystone but
 Delimiter while making calculations for available/free resource will
 take into consideration whether the project has flat or nested hierarchy.
 7. Delimiter will rely on the concept of generation-id to guarantee
 sequencing. Generation-id gives a point in time view of resource usage
 in a project. Project consuming delimiter will need to provide this
 information while checking or consuming quota. At present Nova [3] has
 the concept of generation-id.
 8. Spec [5] will be modified based on the design summit discussion.

 If you want to contribute to Delimiter, please join *#openstack-quota. *

 We have *meetings every Tuesday at 17:00 UTC. *Please join us !
 *
 *
 I am in the process of setting up a new repo for Delimiter. The
 launchpad page[4] is up.


 Thanks!

 -Vilobh

 [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
 [2] Slides
 : 
 http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
  
 [3] https://review.openstack.org/#/c/283253/
 [4] https://launchpad.net/delimiter
 [5] 

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

[Sean Dague]

On 05/04/2016 02:16 PM, Dean Troyer wrote:
> On Wed, May 4, 2016 at 12:08 PM, Chris Dent  > wrote:
> 
> Since then the spec has been updated to reflect using OSC but the
> question of whether this is in fact the right place for this style
> of commands remains open. Not just for this situation, but
> generally.
> 
> 
> This came up again last week, and there is still no real consensus as to
> whether admin-only stuff should be included in the repo or kept in
> plugins. The things already in the OSC repo are likely to stay for the
> forseeable future, new things could go either way.
> 
> If you are planning a separate client/lib, it would make sense to do the
> OSC plugin as part of that lib.  That is also a chance to get a really
> clean Python API that doesn't have the cruft of novaclient

I think that in the case of the new "placement" API we really want to
give it a fresh start. It will be a dedicated endpoint from day one, and
the CLI interaction with it should definitely live outside of
novaclient. First, because there is no need to take a lot of the gorp
from novaclient forward. Second, because we want it really clear from
day one that this effort is going to split from Nova, and you can use
this thing even without Nova.

This will, at some level, be pretty core infrastructure. Nova, Neutron,
Cinder (at the least, I'm sure more will over time) will need to talk to
it programatically, and administrators may need to do some hand tuning
of resource pools to express things that are not yet automatically
discovered and advertised (or that never really make sense to be).

Given these constraints it was as much of an ask as anything else. Can
OSC handle this? Should it handle it from a best practices perspective?
How are commands exposed / hidden based on user permissions? The fact
that we're going to need a service library mean that a dedicated admin
API might be appropriate?

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

[Mehdi Abaakouk]

Le 2016-05-04 10:04, Renat Akhmerov a écrit :

No problem. Let’s not call it RPC (btw, I completely agree with that).
But it’s one of the messaging patterns and hence should be under
oslo.messaging I guess, no?


Yes and no, we currently have two APIs (rpc and notification). And
personally I regret to have the notification part in oslo.messaging.

RPC and Notification are different beasts, and both are today limited
in terms of feature because they share the same driver implementation.

Our RPC errors handling is really poor, for example Nova just put
instance in ERROR when something bad occurs in oslo.messaging layer.
This enforces deployer/user to fix the issue manually.

Our Notification system doesn't allow fine grain routing of message,
everything goes into one configured topic/queue.

And now we want to add a new one... I'm not against this idea,
but I'm not a huge fan.


Thoughts from folks (mistral and oslo)?


Also, I was not at the Summit, should I conclude the Tooz+taskflow 
approach (that ensure the idempotent of the application within the 
library API) have not been accepted by mistral folks ?



Speaking about idempotency, IMO it’s not a central question that we
should be discussing here. Mistral users should have a choice: if they
manage to make their actions idempotent it’s excellent, in many cases
idempotency is certainly possible, btw. If no, then they know about
potential consequences.


You shouldn't mix the idempotency of the user task and the idempotency
of a Mistral action (that will at the end run the user task).
You can have your Mistral task runner implementation idempotent and just
make the workflow to use configurable in case the user task is
interrupted or badly finished even if the user task is idempotent or 
not.

This makes the thing very predictable. You will know for example:
* if the user task has started or not,
* if the error is due to a node power cut when the user task runs,
* if you can safely retry a not idempotent user task on an other node,
* you will not be impacted by rabbitmq restart or TCP connection issues,
* ...

With the oslo.messaging approach, everything will just end up in a
generic MessageTimeout error.

The RPC API already have this kind of issue. Applications have 
unfortunately

dealt with that (and I think they want something better now).
I'm just not convinced we should add a new "working queue" API in
oslo.messaging for tasks scheduling that have the same issue we already
have with RPC.

Anyway, that's your choice, if you want rely on this poor structure, I 
will
not be against, I'm not involved in Mistral. I just want everybody is 
aware

of this.


And even in this case there’s usually a number
of measures that can be taken to mitigate those consequences (reruning
workflows from certain points after manually fixing problems, rollback
scenarios etc.).


taskflow allows to describe and automate this kind of workflow really 
easily.



What I’m saying is: let’s not make that crucial decision now about
what a messaging framework should support or not, let’s make it more
flexible to account for variety of different usage scenarios.


I think the confusion is in the "messaging" keyword, currently 
oslo.messaging
is a "RPC" framework and a "Notification" framework on top of 
'messaging'

frameworks.

Messaging framework we uses are 'kombu', 'pika', 'zmq' and 'pingus'.


It’s normal for frameworks to give more rather than less.


I disagree, here we mix different concepts into one library, all 
concepts

have to be implemented by different 'messaging framework',
So we fortunately give less to make thing just works in the same way 
with all

drivers for all APIs.


One more thing, at the summit we were discussing the possibility to
define at-most-once/at-least-once individually for Mistral tasks. This
is demanded because there cases where we need to do it, advanced users
may choose one or another depending on a task/action semantics.
However, it won’t be possible to implement w/o changes in the
underlying messaging framework.


If we goes that way, oslo.messaging users and Mistral users have to be 
aware
that their job/task/action/whatever will perhaps not be called 
(at-most-once)

or perhaps called twice (at-least-once).

The oslo.messaging/Mistral API and docs must be clear about this 
behavior to
not having bugs open against oslo.messaging because script written via 
Mistral

API is not executed as expected "sometimes".
"sometimes" == when deployers have trouble with its rabbitmq (or 
whatever)

broker and even just when a deployer restart a broker node or when a TCP
issue occurs. At this end the backtrace in theses cases always trows 
only

oslo.messaging trace (the well known MessageTimeout...).


Also oslo.messaging is already a fragile brick used by everybody that a 
very small subset of people maintain (thanks to them).


I'm afraid that adding such new API will increase the needed maintenance 
for this lib while currently not many people 

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Gregory Haynes]

 
On Wed, May 4, 2016, at 09:57 AM, Ethan Gafford wrote:
>
> Sahara has support for several image generation-related cases:
> 1) Packing an image pre-cluster spawn in Nova.
> 2) Building clusters from a "clean" OS image post-Nova spawn, by
>downloading and installing Hadoop/Spark/Storm/WhatHaveYou.
> 3) Validating images after Nova spawn (to ensure that they're up to
>spec for the plugin in question.)
> Because of this, we are pulling image generation logic into the
> plugins themselves, from a monolithic sahara-image-elements
> repository. This will aid us in our eventual hope to pull plugins
> out of the Sahara tree entirely; more immediately, it will allow us
> to define logic for all of these cases in one place, written
> eventually in Python. In our Sahara session at summit, which was
> also attended by several members of the Ironic team (thanks all), we
> discussed our current plan to use libguestfs rather than DIB as our
> toolchain; our intent to define a linear, idempotent set of steps to
> pack images for any plugin lends itself much more neatly to
> libguestfs' API than to DIB's.
 
Ok, there is clearly some kind of communication breakdown between DIB
and some of its users that we *really* need to solve. AFAIK the primary
set of DIB developers had no idea this was going on. I am going to push
up a patch to our docs to make it a lot more clear where to find us
(#tripleo or the ML). I'm not really sure what else we could do to make
it easier for users to find us / raise issues with us so we can explore
ways to solve them, but any suggestions would be a huge help.
 
The idea that a linear set of idempotent steps is mutually exclusive
with DIB's API is really interesting. IIUC this is something we
grappled with in TripleO when creating the tool and simply never spent
time looking in to solving for the existing distro elements, although
that is an element issue not an API issue. DIB's API is just a linear
set of commands you opt in to (by way of elements), if you make those
commands idempotent then you have what you want, the problem is that
the upstream element's themselves are not written in that way so you
couldn't depend on them.  I think there are some pretty obvious ways to
solve this, potentially by making an element which provides the same
API as libguestfs virt-customize (this would be very simple to do, I
just haven't heard of anyone wanting it) or by hacking on some of the
in-tree elements. Could you go in to some more detail on how you use
this feature?
 
> Beyond that, the Sahara team has certainly seen profound difficulty in
> the field when customers attempt to generate their own images, and
> even for Sahara cores, building images is occasionally quite
> harrowing. These issues are seldom based on real issues in the scripts
> themselves, but are frequently the result of bleed between the host
> and guest; when these issues occur for a customer, they become
> extremely difficult to diagnose remotely. Still, it's entirely
> possible that DIB has answers to these problems, and it'd be a
> universal good to identify real flaws in DIB, or just to educate the
> uninitiated into how DIB can be made to work more cleanly if the
> features are already there (which they may well be; far be it from me
> to claim exhaustive mastery of DIB.) The technical reasons we like
> libguestfs over DIB are:
 
It would be *extremely* helpful to know about these issues when they
come up. There's definitely some things we can do to prevent this but
again, there hasn't been a lot of feedback that this is an issue people
are running in to. There's a few different ways to prevent these types
of problems ranging from doing something like virt-dib to having dib use
another chroot during the image building process but I would really like
to hear about some specific issues to get a better idea of what the root
cause is. Hopefully we could even get these filed as bugs.
 
> 1) Libguestfs manipulates images in a clean helper VM created by
>libguestfs in a predictable way. As such, no mounts are made on the
>host, no scripts can affect the host system, and no variables on
>the host system are likely to affect the image packing process. See
>http://libguestfs.org/guestfs-security.1.html for information on
>libguestfs security.
 
Yep, isolation is definitely something DIB currently gives up in order
to provide speed/lower resource usage. That being said, there are lots
of things that could be done to either mitigate these issues or remove
them altogether (by compromising on speed/resource requirements). My
biggest concern is that we are creating two sets of code to perform the
same task due to a false dichotomy - the obvious case being that at a
minimum we could still be using something compatible with DIB while
utilizing a vm/libguestfs. This would then have the benefits of having a
common toolset among the community without the raised issues.
 
> 2) In-place image manipulation means that 

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Nikhil Komawar]

On 5/4/16 2:09 PM, Tim Bell wrote:
>
> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>
>> Thanks for the summary and taking care of the setup, Vilobh!
>>
>> Pretty meticulously written on what was agreed at the session. Kudos!
>>
>> I wanted to add some points that were asked during the Glance
>> contributors' meetup:
>>
>> * The quota limits will be set on the tables in the service that
>> maintains the resources for each individual resource (not in keystone).
>> The default value is what is picked from the config. I think over time
>> we will come up with implementation detail on how the hierarchical
>> default value should be set.
>>
>> * The quota allocation calculation will be based on the project
>> hierarchy in consideration (given that driver is being used in such
>> deployment scenario) and the usage for that resource recorded in the
>> resource's quota table in that service. So, this will involve
>> interaction with keystone and within the quota table in the project.
>>
>> * We will be working on a migration story separately (outside of the
>> library). Delimiter does not own the quota limits and usage data so it
>> will not deal with migrations.
> Given that Glance does not currently have a quota, it may be possible to use 
> this as the initial implementation. This would also avoid a later migration 
> effort.
>
> Tim
>
>

Thanks for the response Tim. I am of the same opinion but haven't really
internalized this migration path as I've not been on the deploy-er side
of managing quota yet. Intuitively migration for quotas seems like a
terrible experience, possibly going over days?

I presume that nested quota support, if built in from get go, when the
tables are set is probably the best idea of hierarchical quota support.
Hoping that's not overly pessimistic assumption.

>>
>> On 5/4/16 1:23 PM, Vilobh Meshram wrote:
>>> Hi All,
>>>
>>> For people who missed the design summit session on Delimiter - Cross
>>> project Quota enforcement library here is a gist of what we discussed.
>>> Etherpad [1] captures the details. 
>>>
>>> 1. Delimiter will not be responsible for rate-limiting.
>>> 2. Delimiter will not maintain data for the projects.
>>> 3. Delimiter will not have the concept of reservations.
>>> 4. Delimiter will fetch information for project quotas from respective
>>> projects.
>>> 5. Delimiter will consolidate utility code for quota related issues at
>>> common place. For example X, Y, Z companies might have different
>>> scripts to fix quota issues. Delimiter can be a single place for it
>>> and the scripts can be more generalized to suit everyones needs.
>>> 6. The details of project hierarchy is maintained in Keystone but
>>> Delimiter while making calculations for available/free resource will
>>> take into consideration whether the project has flat or nested hierarchy.
>>> 7. Delimiter will rely on the concept of generation-id to guarantee
>>> sequencing. Generation-id gives a point in time view of resource usage
>>> in a project. Project consuming delimiter will need to provide this
>>> information while checking or consuming quota. At present Nova [3] has
>>> the concept of generation-id.
>>> 8. Spec [5] will be modified based on the design summit discussion.
>>>
>>> If you want to contribute to Delimiter, please join *#openstack-quota. *
>>>
>>> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
>>> *
>>> *
>>> I am in the process of setting up a new repo for Delimiter. The
>>> launchpad page[4] is up.
>>>
>>>
>>> Thanks!
>>>
>>> -Vilobh
>>>
>>> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
>>> [2] Slides
>>> : 
>>> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>>>  
>>> [3] https://review.openstack.org/#/c/283253/
>>> [4] https://launchpad.net/delimiter
>>> [5] Spec : https://review.openstack.org/#/c/284454
>>>
>>>
>>>  
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [tc] supporting Go

[Fox, Kevin M]

Explicitly, no. I agree. Implicitly... ? Why bother to even propose joining 
when you know the rules clearly state that its not acceptable? I don't claim to 
know what has gone on internally in such teams. I'm just saying just because 
there hasn't been visible signs here of exclusion doesn't mean exclusion hasn't 
happened.

Thanks,
Kevin

From: Pete Zaitcev [zait...@redhat.com]
Sent: Wednesday, May 04, 2016 10:40 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

On Tue, 3 May 2016 22:37:30 +
"Fox, Kevin M"  wrote:

> RadosGW has been excluded from joining the OpenStack community in part
> due to its use of c++.

Sounds like sheer lunacy. Nothing like that ever happened, AFAIK.

-- Pete


__
OpenStack Development Mailing 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] [ironic] Newton priorities and primary contacts

[Ruby Loo]

Hi,

At the Austin summit, we had a session where we discussed and decided on
what the top priorities would be for ironic, in the newton development
cycle. The etherpad [1] captures that discussion, and there is a patch up
to add the newton priorities to our specs [2].

Everyone, and in particular all ironic cores, should take a look at the
priorities [2] because as a community, we should all have the same
understanding and be working towards the same goals. Of course, side goals
are fine too :D

I also wanted to mention the primary contacts for these priorities, because
I'm not sure that I have the same understanding as others, as to what it
means.

My understanding is that the primary contacts are the folks that would take
the lead for an item. Their responsibilities would include knowing the
status of it, and to do their 'best' to get it done, regardless of whether
they themselves did the design, code, documentation, review, etc. Ideally,
I'd prefer to see one primary contact per item, but if people want to work
together, that is fine, as long as it works.

If you are interested in a particular feature on this list, or would like
to contribute code towards that end, or would like to help review, or test,
that is wonderful and I thank you so much for your interest and desire to
contribute. However, I would really like to see primary contacts do more,
as described above. To take responsibility and (try to) commit the
time/effort it will take to see this priority items through.

Is this in line with what others think/expect from the primary contacts?

--ruby


[1] https://etherpad.openstack.org/p/ironic-newton-summit-priorities
[2] https://review.openstack.org/#/c/311530/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] OSC transition

[Darek Smigiel]

> On May 4, 2016, at 6:10 AM, Na Zhu  wrote:
> 
> Hi Richard,
> 
> I read the contents in the link, I think the discussion in Austin summit have 
> not updated to the webpage.
> But from here 
> https://etherpad.openstack.org/p/newton-neutron-future-neutron-client 
> , it 
> mentions python-neutronclient provides OSC plugin for neutron-*aas,
> does it mean all neutron-*aas CLIs still live in python-neutronclient repo? 
> If yes, should every neutron-*aas owner updates the CLIs from neutron to 
> openstack?
> 
> I found Dean Troyer set the [Blueprint neutron-client] implement neutron 
> commandsstate to obsolete, does the OSC transition continue move along?
> 

Transition is in progress. Here you have spec for it [1]. Probably the most 
important thing for you is this [2] where all required commands are described.


[1] 
http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html
 

[2] https://etherpad.openstack.org/p/osc-neutron-support 


Darek Smigiel (dasm)

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

[Clint Byrum]

Excerpts from Mark Doffman's message of 2016-05-03 17:05:54 -0700:
> This thread has been a depressing read.
> 

First, I apologize if any of my actions have caused you any undue stress.

> I understand that the content is supposed to be distributed databases 
> but for me it has become an inquisition of cellsV2.
> 

That word, inquisition, is a bit loaded with cultural significance,
though I think the sterile definition applies accurately. It's not my
intend to bring any of the unfortunate aspects of it into this process
though. My main concern is that the actual details haven't even been
thought through at a high level, and we maybe shouldn't be pinning all
our scaling hopes on something that may well end up changing radically
in practice.

> Our question has clearly become "Should we continue efforts on 
> cellsV2?", which I will address head-on.
> 
> We shouldn't be afraid to abandon CellsV2. If there are designs that are 
> proven to be a better solution then our current momentum shouldn't keep 
> us from an abrupt change. As someone who is working on this I have an 
> attachment to the current design, but Its important for me to keep an 
> open mind.
> 
> Here are my *main* reasons for continuing work on CellsV2.
> 
> 1. It provides a proven solution to an immediate message queue problem.
> 
> Yes CellsV2 is different to CellsV1, but the previous solution showed 
> that application-level sharding of the message queue can work. CellsV2 
> provides this solution with a (moderately) easy upgrade path for 
> existing deployments. These deployments may not be comfortable with 
> changing MQ technologies or may already be using CellsV1. Application 
> level sharding of the message queue is not pretty, but will work.
> 

Indeed, one advantage of using a broker for RPC is that you only have
to ensure connectivity from nodes -> brokers. I can totally understand
a hesitance to ask people to ensure connectivity from (class of
nodes)<->(class of nodes), for each class of nodes that need it. That is
what 0mq asks one to do.

I was witness to a brief presentation from one of the QPID community
members about how they've addressed brokerless comms with a very simple,
non-broker "router daemon", and it was impressive how it straddled this
line nicely, allowing one to basically replace a broker with a set of
relatively stupid daemons that simply pass messages along in realtime,
using some clever techniques borrowed from OSPF and the like.

Both of these, 0mq, and brokerless AMQP 1.0, can be taken advantage of
_today_ with oslo.messaging drivers that exist already. However, they
require some battle hardening, so I respect that there are some who'd
rather we change OpenStack around its own battle tested choices than
start experimenting with new solutions that are outside of OpenStack.

The point of my persistence here is to make it clear that I don't think
Cells V2 is settled, and I don't think it will be a generally consumable
solution any time soon. I think for those of us with immediate concerns,
who are not interested in taking on cells v1 at this time, we should
look to experiment with these other options.

> 2. The 'complexity' of CellsV2 is vastly overstated.
> 
> Sure there is a-lot of *work* to do for cellsv2, but this doesn't imply 
> increased complexity: any refactoring requires work. CellsV1 added 
> complexity to our codebase, Cellsv2 does not. In-fact by clearly 
> separating data that is 'owned'by the different services we have I 
> believe that we are improving the modularity and encapsulation present 
> in Nova.
> 

I think the complexity is entirely unknown, and that the design should
fill its gaps, even at high levels, so that we can actually reason about
the complexity. Right now, there's hand waving in places that concern
me.

> 3. CellsV2 does not prohibit *ANY* of the alternative scaling methods
> mentioned in this thread.
> 
> Really, it doesn't. Both message queue and database switching are 
> completely optional. Both in the sense of running a single cell, and 
> even when running multiple cells. If anything, the ability to run 
> separate message queues and database connections could give us the 
> ability to trial these alternative technologies within a real, running, 
> cloud.
> 
> Just imagine the ability to set up a cell in your existing cloud that 
> runs 0mq rather than rabbit. How about a NewSQL database integrated in 
> to an existing cloud? Both of these things may (With some work) be possible.
> 

Prohibit is definitely not the word I would use either. But I'm not sure
I'd get too excited about enabling multiple drivers across cells either.
What I'd really like is a simple solution, and I truly do hope that
cells v2 becomes that some day.

> 
> 
> I could go on, but I won't. These are my main reasons and I'll stick to 
> them.
> 
> Its difficult to be proven wrong, but sometimes necessary to get the 
> best product that we can. I don't think that the existence of 
> alternative 

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

[Sheena Conant]

Hi all –



I think this might’ve gotten buried a bit in the pre-summit and summit
madness.



I just wanted to kick the thread – I think this is a really good idea.
Dogpiling all plugins into a single LP project makes it really difficult to
pick out which bugs affect which plugins – and the ecosystem is only
getting bigger.



Irina, please add this to the SDK as a best practice when you have time.
I’ll talk to plugin teams I’m working with to make sure they know about
this, as well.



Sheena



*From:* Irina Povolotskaya [mailto:ipovolotsk...@mirantis.com]
*Sent:* Tuesday, April 19, 2016 9:49 AM
*To:* openstack-dev@lists.openstack.org
*Subject:* [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad
project



Hi to everyone,



as you possibly know (at least, those dev. teams working on their Fuel
plugins) we have a fuel-plugins Launchpad project [1] which serves as
all-in-one entry point for filing bugs, related

to plugin-specific problems.



nevertheless, this single project is a bad idea in terms of providing
granularity and visibility for each plugin:

- it's not possible to make up milestones, unique for every plugin that
would coincide with the plugin's version (which is specified in
metadata.yaml file)

- it's not possible to provide every dev. team with exclusive rights on
managing importance, milestones etc.



therefore, I would like to propose the following:

- if you have your own fuel plugin, create a separate LP project for it
e.g.[2] [3]and make up all corresponding groups for managing release cycle
of your plugin

- if you have some issues with fuel plugin framework itself, please
consider filing bugs in fuel project [4] as usual.



I would appreciate getting feedback on this idea.

if it seems fine, then I'll follow-up with adding instructions into our SDK
[5] and the list of already existing LP projects.



thanks.





[1] https://launchpad.net/fuel-plugins

[2] https://launchpad.net/lma-toolchain

[3] https://launchpad.net/fuel-plugin-nsxv

[4] https://launchpad.net/fuel

[5] https://wiki.openstack.org/wiki/Fuel/Plugins




-- 

Best regards,


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

Re: [openstack-dev] [neutron] OSC transition

[Dean Troyer]

On Wed, May 4, 2016 at 6:10 AM, Na Zhu  wrote:

> I found Dean Troyer set the *[Blueprint neutron-client] implement neutron
> commands*state to obsolete, does the OSC transition continue move along?


Other BPs are being used to track the specific work being performed, that
BP was nearly empty and was not being used to track any work.

dt

-- 

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

Re: [openstack-dev] [kolla] xenial or trusty

[Emilien Macchi]

On Wed, May 4, 2016 at 1:52 PM, Jeffrey Zhang  wrote:
> I'd like to lock the tag version in certain branch. One branch only support
> one
> distro release.
>
> For example, the mitaka branch only build on Trusty and the master/newton
> branch
> only build on Xenial.
>
> So, the branch and OS matrix should like ( fix me and the ?)
>
>   Ubuntu CentOS Debian  OracleLinux
> Liberty14.047  ? ?
> Mitaka 14.047  ? ?
> Master 16.047  ? ?

FWIW, this is what we plan to do in Puppet OpenStack CI (except we
don't gate on OracleLinux & Debian).

> this is enough and easy to maintain.
>
> On Thu, May 5, 2016 at 1:14 AM, Mauricio Lima 
> wrote:
>>
>> Which will be the default when kolla begin to support xenial? Xenial or
>> Trusty?
>>
>> One proposal is to support both, at least in this beginning and just do
>> some checks to get which version that the user is using.
>>
>> Regards,
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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][osc] Use of openstack client for admin commands

[Matt Riedemann]

On 5/4/2016 12:08 PM, Chris Dent wrote:


The plans for generic resource pools[1] include a suite of new
commands for creating and updating resource pools. In today's Nova
API meeting[2] and afterwards in #openstack-nova[3] we discussed two
issues:

* Since the placement API associated with resource pools is eventually
  going to be hoisted out of nova it will be developed in a decoupled
  fashion within the nova tree. It makes sense to also hoist the client
  libraries in the same fashion. The canonical plan for CLIs is to
  plug in to OSC.

* There's some confusion on whether commands that are destined for
  admins and services but not end users are "supposed" to be in OSC.

Since then the spec has been updated to reflect using OSC but the
question of whether this is in fact the right place for this style
of commands remains open. Not just for this situation, but
generally.

Is there an official word on this? If not, should we make one?

Thanks.

[1] https://review.openstack.org/#/c/300176/
[2]
http://eavesdrop.openstack.org/meetings/nova_api/2016/nova_api.2016-05-04-13.00.log.html#l-205

[3] http://p.anticdent.org/xWd




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



FWIW this was the design summit session etherpad [1] but it doesn't 
mention anything about admin-only CLIs.


[1] https://etherpad.openstack.org/p/state-of-osc-plugins

--

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][osc] Use of openstack client for admin commands

[Dean Troyer]

On Wed, May 4, 2016 at 12:08 PM, Chris Dent  wrote:

> Since then the spec has been updated to reflect using OSC but the
> question of whether this is in fact the right place for this style
> of commands remains open. Not just for this situation, but
> generally.
>

This came up again last week, and there is still no real consensus as to
whether admin-only stuff should be included in the repo or kept in plugins.
The things already in the OSC repo are likely to stay for the forseeable
future, new things could go either way.

If you are planning a separate client/lib, it would make sense to do the
OSC plugin as part of that lib.  That is also a chance to get a really
clean Python API that doesn't have the cruft of novaclient

dt

-- 

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

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Tim Bell]

On 04/05/16 19:41, "Nikhil Komawar"  wrote:

>Thanks for the summary and taking care of the setup, Vilobh!
>
>Pretty meticulously written on what was agreed at the session. Kudos!
>
>I wanted to add some points that were asked during the Glance
>contributors' meetup:
>
>* The quota limits will be set on the tables in the service that
>maintains the resources for each individual resource (not in keystone).
>The default value is what is picked from the config. I think over time
>we will come up with implementation detail on how the hierarchical
>default value should be set.
>
>* The quota allocation calculation will be based on the project
>hierarchy in consideration (given that driver is being used in such
>deployment scenario) and the usage for that resource recorded in the
>resource's quota table in that service. So, this will involve
>interaction with keystone and within the quota table in the project.
>
>* We will be working on a migration story separately (outside of the
>library). Delimiter does not own the quota limits and usage data so it
>will not deal with migrations.

Given that Glance does not currently have a quota, it may be possible to use 
this as the initial implementation. This would also avoid a later migration 
effort.

Tim



>
>
>On 5/4/16 1:23 PM, Vilobh Meshram wrote:
>> Hi All,
>>
>> For people who missed the design summit session on Delimiter - Cross
>> project Quota enforcement library here is a gist of what we discussed.
>> Etherpad [1] captures the details. 
>>
>> 1. Delimiter will not be responsible for rate-limiting.
>> 2. Delimiter will not maintain data for the projects.
>> 3. Delimiter will not have the concept of reservations.
>> 4. Delimiter will fetch information for project quotas from respective
>> projects.
>> 5. Delimiter will consolidate utility code for quota related issues at
>> common place. For example X, Y, Z companies might have different
>> scripts to fix quota issues. Delimiter can be a single place for it
>> and the scripts can be more generalized to suit everyones needs.
>> 6. The details of project hierarchy is maintained in Keystone but
>> Delimiter while making calculations for available/free resource will
>> take into consideration whether the project has flat or nested hierarchy.
>> 7. Delimiter will rely on the concept of generation-id to guarantee
>> sequencing. Generation-id gives a point in time view of resource usage
>> in a project. Project consuming delimiter will need to provide this
>> information while checking or consuming quota. At present Nova [3] has
>> the concept of generation-id.
>> 8. Spec [5] will be modified based on the design summit discussion.
>>
>> If you want to contribute to Delimiter, please join *#openstack-quota. *
>>
>> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
>> *
>> *
>> I am in the process of setting up a new repo for Delimiter. The
>> launchpad page[4] is up.
>>
>>
>> Thanks!
>>
>> -Vilobh
>>
>> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
>> [2] Slides
>> : 
>> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>>  
>> [3] https://review.openstack.org/#/c/283253/
>> [4] https://launchpad.net/delimiter
>> [5] Spec : https://review.openstack.org/#/c/284454
>>
>>
>>  
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>-- 
>
>Thanks,
>Nikhil
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] supporting Go

[Pete Zaitcev]

On Tue, 3 May 2016 22:37:30 +
"Fox, Kevin M"  wrote:

> RadosGW has been excluded from joining the OpenStack community in part
> due to its use of c++.

Sounds like sheer lunacy. Nothing like that ever happened, AFAIK.

-- Pete

__
OpenStack Development Mailing 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] [kolla] xenial or trusty

[Jeffrey Zhang]

I'd like to lock the tag version in certain branch. One branch only support
one
distro release.

For example, the mitaka branch only build on Trusty and the master/newton
branch
only build on Xenial.

So, the branch and OS matrix should like ( fix me and the ?)

  Ubuntu CentOS Debian  OracleLinux
Liberty14.047  ? ?
Mitaka 14.047  ? ?
Master 16.047  ? ?

this is enough and easy to maintain.

On Thu, May 5, 2016 at 1:14 AM, Mauricio Lima 
wrote:

> Which will be the default when kolla begin to support xenial? Xenial or
> Trusty?
>
> One proposal is to support both, at least in this beginning and just do
> some checks to get which version that the user is using.
>
> Regards,
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [tc] supporting Go

[Flavio Percoco]

On 04/05/16 11:38 +0200, Thierry Carrez wrote:

Hayes, Graham wrote:

[...]
Designate is looking to move a single component of ours to Go - and we
were wondering what was the best way to do it.

The current policy does allow for the TC to bless different languages
on a case by case basis - do we need to go from just python and JS to
allowing all projects to use go, or should the TC approve (or
disapprove) the swift and designate requests?


If we add Go as a supported language, then all projects could use it 
(without requiring case-by-case TC blessing). As the resolution[1] 
explains, we want to standardize on a limited number of supported 
languages so that we can use the right tool for the right job, while 
limiting the impact on infrastructure and community fragmentation. But 
once a language is accepted, the more we use it the better.


++ This!


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Nikhil Komawar]

Thanks for the summary and taking care of the setup, Vilobh!

Pretty meticulously written on what was agreed at the session. Kudos!

I wanted to add some points that were asked during the Glance
contributors' meetup:

* The quota limits will be set on the tables in the service that
maintains the resources for each individual resource (not in keystone).
The default value is what is picked from the config. I think over time
we will come up with implementation detail on how the hierarchical
default value should be set.

* The quota allocation calculation will be based on the project
hierarchy in consideration (given that driver is being used in such
deployment scenario) and the usage for that resource recorded in the
resource's quota table in that service. So, this will involve
interaction with keystone and within the quota table in the project.

* We will be working on a migration story separately (outside of the
library). Delimiter does not own the quota limits and usage data so it
will not deal with migrations.


On 5/4/16 1:23 PM, Vilobh Meshram wrote:
> Hi All,
>
> For people who missed the design summit session on Delimiter - Cross
> project Quota enforcement library here is a gist of what we discussed.
> Etherpad [1] captures the details. 
>
> 1. Delimiter will not be responsible for rate-limiting.
> 2. Delimiter will not maintain data for the projects.
> 3. Delimiter will not have the concept of reservations.
> 4. Delimiter will fetch information for project quotas from respective
> projects.
> 5. Delimiter will consolidate utility code for quota related issues at
> common place. For example X, Y, Z companies might have different
> scripts to fix quota issues. Delimiter can be a single place for it
> and the scripts can be more generalized to suit everyones needs.
> 6. The details of project hierarchy is maintained in Keystone but
> Delimiter while making calculations for available/free resource will
> take into consideration whether the project has flat or nested hierarchy.
> 7. Delimiter will rely on the concept of generation-id to guarantee
> sequencing. Generation-id gives a point in time view of resource usage
> in a project. Project consuming delimiter will need to provide this
> information while checking or consuming quota. At present Nova [3] has
> the concept of generation-id.
> 8. Spec [5] will be modified based on the design summit discussion.
>
> If you want to contribute to Delimiter, please join *#openstack-quota. *
>
> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
> *
> *
> I am in the process of setting up a new repo for Delimiter. The
> launchpad page[4] is up.
>
>
> Thanks!
>
> -Vilobh
>
> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
> [2] Slides
> : 
> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>  
> [3] https://review.openstack.org/#/c/283253/
> [4] https://launchpad.net/delimiter
> [5] Spec : https://review.openstack.org/#/c/284454
>
>
>  
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Flavio Percoco]

On 04/05/16 09:46 -0700, Clark Boylan wrote:

On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:

On 04/05/16 15:05 +, Amrith Kumar wrote:
>I'm emailing the ML on the subject of a review ongoing in the Trove project 
regarding image building[1].
>
>TL;DR
>
>One of the most frequent questions that new users of Trove ask is how and 
where to get guest images with which to experiment with Trove, and how to build 
these images for themselves. While documentation about this exists in multiple 
places (including [2], [3]) this is still something that can do with some 
improvement.
>
>Trove currently uses diskimage-builder for building images used in testing the 
product and these can serve as a good basis for anyone wishing to build an image 
for their own use of Trove. The review [1] makes the argument for the libguestfs 
based approach to building images and advocates that Trove should use this instead 
of diskimage-builder.

At the summit we discussed the possibility of providing an implementation
that
would allow for both DIB and libguestfs to be used but to give priority
to DIB.
Since there's no real intention of just switching tools at this point, I
believe
it'd be good to amend the spec so that it doesn't mention libguestfs
should be
used instead of DiB.

The goal at this stage is to provide both and help these move forward.


I disagree, as someone that has tried and failed in the past to build
trove images the goal should be to make that process easy for the user.
Maybe we can finally get rid of redstack years after it was supposed to
go away.


Well, that's part of what the spec under discussion is going to address. Pulling
out the DiB bits out of trove-integration aims to provide a way for users to
build their images. The priority is to get this to a state where users can build
images easily and then work in parallel on adding support for an alternative.

This is what was said in the Trove session last week.


>I believe that a broader discussion of this is required and I appreciate Greg 
Haynes' proposal at the design summit to have this discussion on the ML. I took 
the action item to bring this discussion to the ML.
>
>Details follow ...
>
>Before going further, I will state my views on these matters.
>
>1. It is important for the Trove project to do things quickly to make it 
easier for end users who wish to use Trove and who wish to build their own images. 
I am not concerned what tool or tools a person will use to build these images.
>
>2. If we provide multiple alternatives to image building as part of the Trove 
project, we should make sure that images built with all sets of tools are 
equivalent and usable interchangeably. Failing to do this will make it harder for 
users to use Trove because we will be providing them with a false choice (i.e. the 
alternatives aren't really alternatives). This is harder than it sounds given the 
combination of tools, operating systems, and the source(s) from which you can get 
database software.

Maintaining both in the long run will be harder especially because, as
you
mentioned, the output must be usable interchangeably. However, I think
we're at
a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
and
some other folks that it'd be beneficial for us to have this discussion
and to
also experiment/test other options.

The Sahara team seems to be going in a direction that differs with the
one used
by the infra team and the one we're headed to (although they overlap in
some
areas).


Has Sahara expressed their needs somewhere too? This is the first I am
hearing of them having trouble with image builds (I had thought they
were using DIB successfully).


I believe Ethan has replied to this in another email.


>3. Trove already has elements for all supported databases using DIB in the 
trove-integration project but these elements are not packaged for customer use. 
Making them usable by customers is a relatively small effort including providing a 
wrapper script (derived from redstack[4]) and providing an element to install the 
guest agent software from a fixed location in addition to the development and 
testing version that is better suited to Trove development [5] and [6].
>
>4. My comments on various patch sets in the review[1].
>
>I agree with Monty and Greg Haynes that we should understand the deficiencies if any in 
DIB, and if it is in fact the case that they are "intractable/unsolvable", we 
should switch toolchains. This discussion should include issues faced by the Trove team as 
well as other teams that may have faced problems with DIB (such as the sahara team who 
described some of them in the past).

++

Agreed with the above. I'm think collaboration should be the preferred
way. I
don't think I've enough technical insight on this topic to provide a
detailed
list of things that are good/bad on either of these tools but I wanted to
mention that I believe providing support for both in the short run is
good for
us and it 

Re: [openstack-dev] [tc] supporting Go

[Pete Zaitcev]

On Tue, 3 May 2016 22:11:06 +
"Fox, Kevin M"  wrote:

> If we let go in, and there are no pluggable middleware, where does
> RadosGW and other Swift api compatible implementations then stand?

They remain where they are now.

> Should we bless c++ too? As I understand it, there are a lot of clouds
> deployed with the RadosGW but Refstack rejects them.

RadosGW is not trying to become a part of the OpenStack, while Hummingbird is.
This is why we're discussing Go and nog C++ in this thread.

-- Pete

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Peter MacKinnon]

On 5/4/16 12:52 PM, Gregory Haynes wrote:

On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:

On 04/05/16 15:05 +, Amrith Kumar wrote:

I'm emailing the ML on the subject of a review ongoing in the Trove project 
regarding image building[1].

TL;DR

One of the most frequent questions that new users of Trove ask is how and where 
to get guest images with which to experiment with Trove, and how to build these 
images for themselves. While documentation about this exists in multiple places 
(including [2], [3]) this is still something that can do with some improvement.

Trove currently uses diskimage-builder for building images used in testing the 
product and these can serve as a good basis for anyone wishing to build an 
image for their own use of Trove. The review [1] makes the argument for the 
libguestfs based approach to building images and advocates that Trove should 
use this instead of diskimage-builder.

At the summit we discussed the possibility of providing an implementation
that
would allow for both DIB and libguestfs to be used but to give priority
to DIB.
Since there's no real intention of just switching tools at this point, I
believe
it'd be good to amend the spec so that it doesn't mention libguestfs
should be
used instead of DiB.

The goal at this stage is to provide both and help these move forward.


I believe that a broader discussion of this is required and I appreciate Greg 
Haynes' proposal at the design summit to have this discussion on the ML. I took 
the action item to bring this discussion to the ML.

Details follow ...

Before going further, I will state my views on these matters.

1. It is important for the Trove project to do things quickly to make it easier 
for end users who wish to use Trove and who wish to build their own images. I 
am not concerned what tool or tools a person will use to build these images.

++. One of the biggest issues I see users of DIB hit is ease of use for
'just make me an image, I don't care about twiddling knobs'. A wrapper
script in trove is one way to help with this, but I am sure there are
other solutions as well... maybe by rethinking some of our fear about
using elements as entry points to an image build, or by simply making
element's with better defaults.


2. If we provide multiple alternatives to image building as part of the Trove 
project, we should make sure that images built with all sets of tools are 
equivalent and usable interchangeably. Failing to do this will make it harder 
for users to use Trove because we will be providing them with a false choice 
(i.e. the alternatives aren't really alternatives). This is harder than it 
sounds given the combination of tools, operating systems, and the source(s) 
from which you can get database software.

Maintaining both in the long run will be harder especially because, as
you
mentioned, the output must be usable interchangeably. However, I think
we're at
a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
and
some other folks that it'd be beneficial for us to have this discussion
and to
also experiment/test other options.

The Sahara team seems to be going in a direction that differs with the
one used
by the infra team and the one we're headed to (although they overlap in
some
areas).


I would highly recommend against having two sets of image building code
for Trove - given DIB's current design there should not be any need for
this and there's a HUGE downside to maintaining two sets of code to do
the same thing in-tree. Ideally a single set of code would be used while
being able to be run in different environments if there are mutually
exclusive requirements being proposed by users.


Well, certainly one downside in the case of Trove (and probably 
elsewhere) with DIB is the src tree matrix of datastore-by-distro 
elements required to support various guest image combinations, leading 
to a proliferation of directories and files. We feel this can be greatly 
simplified using a libguestfs approach using a minimal set of bash and 
directly applicable data files (e.g., systemd unit files, conf files, 
etc.).




What seemed very apparent to me in the summit session is that there are
a set of issues for Trove relating to image building, mostly relating to
reliability and ease of use. There was no one who even mentioned let
alone strongly cared about the issues which actually differentiate the
existing DIB build process from libguestfs (which is isolation). If that
has changed for some reason, then my recommendation would be to use a
tool like virt-dib which will allow for a single image building code
base while solving all the raised issues in the spec. I suspect when
this is tried out the downsides to booting a VM will highly outweigh the
benefits for almost all users (especially in trove's gate),


Anecdotally, it takes the same amount of time for a CentOS7 MySQL build 
(~ 7 minutes) with either toolchain.



but if the
libguestfs docs are to be believed this 

Re: [openstack-dev] [nova] Austin summit versioned notification

[Tripp, Travis S]

Thanks, Jay! We’re looking through everything and will be attending these 
meetings moving forward.

-Travis



On 5/3/16, 6:17 AM, "Jay Pipes"  wrote:

>cc'ing Travis and Steve directly, since they will likely be very 
>interested in this effort from the Project Searchlight perspective. :)
>
>On 05/03/2016 04:10 AM, Balázs Gibizer wrote:
>> Hi,
>>
>> Last week Friday in Austin we discussed the way forward with the versioned
>> notification transformation in Nova.
>>
>> We agreed that when we separate the object model use for notifications from
>> the nova object model we still use the NovaObject as a base class to avoid
>> change in the wire format and the major version bump it would cause.
>> However we won't register the notification object into the 
>> NovaObjectRegistry.
>> In general we agreed that we move forward with the transformation according
>> to the spec [1].
>>
>> Regarding the schema generation for the notifications we agreed to
>> propose a general JSON Schema generation implementation to
>> oslo.versionedobjects [2] that can be used in Nova later to generate
>> schemas for the notification object model.
>>
>> To have a way to synchronize our effort I'd like to restart the weekly
>> subteam meeting [5]. As the majority of the subteam is in US and EU I propose
>> to continue the currently existing time slot UTC 17:00 every Tuesday.
>> I proposed the frequency increase from biweekly to weekly here [3].
>> This means that we can meet today 17:00 UTC [4] on #openstack-meeting-4.
>>
>> Cheers,
>> Gibi
>>
>> [1] https://review.openstack.org/#/c/286675/ Versioned notification 
>> transformation
>> [2] https://review.openstack.org/#/c/311194/ versionedobjects: add json 
>> schema generation
>> [3] https://review.openstack.org/#/c/311948/
>> [4] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160503T17
>> [5] https://wiki.openstack.org/wiki/Meetings/NovaNotification
>>
>>
>> __
>> OpenStack Development Mailing 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] Distributed Database

[Tim Bell]

On 04/05/16 19:00, "Edward Leafe"  wrote:

>On May 3, 2016, at 7:05 PM, Mark Doffman  wrote:
>
>> This thread has been a depressing read.
>> 
>> I understand that the content is supposed to be distributed databases but 
>> for me it has become an inquisition of cellsV2.
>
>Thanks for bringing this up, and I feel a lot of the responsibility for this 
>direction. To make how I see things clearer, I wrote a follow-up blog post 
>[0], but for those who aren’t inclined to read it, I think that Cells V2 is a 
>great idea and could be very helpful for many deployments. My only concern was 
>the choice of fragmenting the data. I would hope that any further discussion 
>focuses on that.
>
>[0] http://blog.leafe.com/index.php/2016/05/04/mea-culpa-and-clarification/
>
>
>-- Ed Leafe
>
>

From the perspective of an operator who is running more than 30 cells with over 
6,000 hypervisors, we are strongly supporting the Cells V2 work, including 
investing significant effort with the CERN collaboration with BARC in Mumbai. 
The roadmap seems very concrete which is key for us as a production cloud at 
scale.  In particular, inclusion of blocking tests in the gate will be key to 
address current functional limitations such as flavors, server groups and 
security groups with cells v1.

OpenStack provides lots of opportunities for investigating alternative 
approaches but we do need to be careful to not end up with a Horizon Effect 
(https://en.wikipedia.org/wiki/Horizon_effect) where potential new solutions 
cause a postponing of solutions for solid production solution at scale which is 
needed by an increasingly large number of deployments.

Tim
>
>
>
>
>__
>OpenStack Development Mailing 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] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Vilobh Meshram]

Hi All,

For people who missed the design summit session on Delimiter - Cross
project Quota enforcement library here is a gist of what we discussed.
Etherpad [1] captures the details.

1. Delimiter will not be responsible for rate-limiting.
2. Delimiter will not maintain data for the projects.
3. Delimiter will not have the concept of reservations.
4. Delimiter will fetch information for project quotas from respective
projects.
5. Delimiter will consolidate utility code for quota related issues at
common place. For example X, Y, Z companies might have different scripts to
fix quota issues. Delimiter can be a single place for it and the scripts
can be more generalized to suit everyones needs.
6. The details of project hierarchy is maintained in Keystone but Delimiter
while making calculations for available/free resource will take into
consideration whether the project has flat or nested hierarchy.
7. Delimiter will rely on the concept of generation-id to guarantee
sequencing. Generation-id gives a point in time view of resource usage in a
project. Project consuming delimiter will need to provide this information
while checking or consuming quota. At present Nova [3] has the concept of
generation-id.
8. Spec [5] will be modified based on the design summit discussion.

If you want to contribute to Delimiter, please join *#openstack-quota. *

We have *meetings every Tuesday at 17:00 UTC. *Please join us !

I am in the process of setting up a new repo for Delimiter. The launchpad
page[4] is up.


Thanks!

-Vilobh

[1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
[2] Slides :
http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal


[3] https://review.openstack.org/#/c/283253/
[4] https://launchpad.net/delimiter
[5] Spec : https://review.openstack.org/#/c/284454
__
OpenStack Development Mailing 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] Distributed Database

[Matt Riedemann]

On 5/4/2016 12:00 PM, Edward Leafe wrote:

On May 3, 2016, at 7:05 PM, Mark Doffman  wrote:


This thread has been a depressing read.

I understand that the content is supposed to be distributed databases but for 
me it has become an inquisition of cellsV2.


Thanks for bringing this up, and I feel a lot of the responsibility for this 
direction. To make how I see things clearer, I wrote a follow-up blog post [0], 
but for those who aren’t inclined to read it, I think that Cells V2 is a great 
idea and could be very helpful for many deployments. My only concern was the 
choice of fragmenting the data. I would hope that any further discussion 
focuses on that.

[0] http://blog.leafe.com/index.php/2016/05/04/mea-culpa-and-clarification/


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



Can we please just let this thread die already? I realize that by 
replying I'm making that impossible, but FFS, enough already.


Sending out blogs and contentious dev list threads right before the 
summit and then not actually bringing any of these issues up in person 
in the specific sessions (or the Friday meetup) we have is just causing 
a huge distraction.


I get that people are concerned about this, it's a big change in Nova. 
But what is really frustrating to me is the amount of noise from left 
field by people that aren't actually working on the development of any 
of this.


And that's fine, but if you're going to say let's scrap the work that's 
been done and do something completely different, I have zero patience to 
read about that over and over again until you've stood up and operated a 
production public cloud using all of these other ideas and can come back 
to say, yup, I was right, this is awesome and you guys were all idiots. 
Because, and I might be going out on a limb here, but I bet that once 
anyone gets 1/3 of the way into changing Nova to use one of these other 
things, like 0mq or Vitess for example, there are going to be new hairy 
issues to work out.


For the record, I love the performance and scaling work that Clint is 
doing, and I sincerely hope we can get enough concrete information out 
of those to make actionable changes in OpenStack to benefit everyone. 
But right now we don't even gate on 0mq, let alone know of a large 
production cloud successfully running with it. So until that starts 
happening, I feel like this thread is going nowhere and we need to just 
start ignoring it and moving on.


--

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] solving API case sensitivity issues

[Sean Dague]

On 02/24/2016 07:48 AM, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
> 
> On mysql the following will explode with a 500:
> 
>> nova aggregate-create agg1
>> nova aggregate-set-metadata agg1 abc=1
>> nova aggregate-set-metadata agg1 ABC=2
> 
> mysql (by default) treats abc == ABC. However the python code does not.

This is reviving an old thread, because we ended up deadlocked on the
case folding issue. Late in the day on Friday at the summit we revisited
this issue in the Nova room, and came up with a new approach:

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

The TL;DR is to change the input validation in a microversion, provide
and audit / fix tool to adminstrators, and close bugs using uppercase
metadata keys and seeing issues as Won't Fix.

Anyone with strong opinions should spend some time looking there.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [kolla] xenial or trusty

[Mauricio Lima]

Which will be the default when kolla begin to support xenial? Xenial or
Trusty?

One proposal is to support both, at least in this beginning and just do
some checks to get which version that the user is using.

Regards,
__
OpenStack Development Mailing 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][osc] Use of openstack client for admin commands

[Chris Dent]

The plans for generic resource pools[1] include a suite of new
commands for creating and updating resource pools. In today's Nova
API meeting[2] and afterwards in #openstack-nova[3] we discussed two
issues:

* Since the placement API associated with resource pools is eventually
  going to be hoisted out of nova it will be developed in a decoupled
  fashion within the nova tree. It makes sense to also hoist the client
  libraries in the same fashion. The canonical plan for CLIs is to
  plug in to OSC.

* There's some confusion on whether commands that are destined for
  admins and services but not end users are "supposed" to be in OSC.

Since then the spec has been updated to reflect using OSC but the
question of whether this is in fact the right place for this style
of commands remains open. Not just for this situation, but
generally.

Is there an official word on this? If not, should we make one?

Thanks.

[1] https://review.openstack.org/#/c/300176/
[2] 
http://eavesdrop.openstack.org/meetings/nova_api/2016/nova_api.2016-05-04-13.00.log.html#l-205
[3] http://p.anticdent.org/xWd


--
Chris Dent   (╯°□°)╯︵┻━┻http://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] [magnum] Add support for using Keystone in k8s bay

[Fox, Kevin M]

+1. Thanks for starting the discussion.

We may need a spec for it. The support in k8s currently is marked experimental 
(thankfully) and is insufficient. It currently only supports username/password 
authentication via keystone v2. There's an issue in the works to fix it in k8s:
https://github.com/kubernetes/kubernetes/issues/24982

tl:dr; To fix it, we will need keystone token authentication, which will 
require v3 token authentication. v3 token auth today requires a service account 
with an admin credential, so the magnum support will need to provision one of 
those accounts and copy the appropriate config/credentials to the controllers 
as well as set the config options.

I've talked to the keystone team and they believe that the v3 validate token 
api can be done without an admin credential if a new role was introduced and 
the policy for that api call was changed to specify the new role. This would 
make things more secure, but wouldn't change what magnum would need to do, just 
which role it would attach to the user it provisions. So I think these two 
activities can be done in parallel.

Thanks,
Kevin


From: Hongbin Lu [hongbin...@huawei.com]
Sent: Wednesday, May 04, 2016 8:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Add support for using Keystone in k8s bay

Hi team,

Based on requests, I propose to add support for Keystone authentication for k8s 
bay. A blueprint was created for that:

https://blueprints.launchpad.net/magnum/+spec/keystone-for-k8s-bay

A goal is to enable other OpenStack services to access the APIs of k8s bays. So 
far, I received a use case from a under-developing Horizon k8s plugin. I 
believe there will be more similar use cases from other services. For the 
implementation, I think it is straightforward. Keystone authentication is 
already supported in k8s upstream [1]. Magnum could simply add an option for 
users to turn it on. As an initial step, I suggest to support passing the auth 
option via labels (e.g. ‘–labels k8s-auth=keystone’). If Keystone is supported 
by other COEs in the future, we could promote this option as a baymodel 
attribute. Thoughts?

[1] http://kubernetes.io/docs/admin/authentication/

Best regards,
Hongbin
__
OpenStack Development Mailing 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] Distributed Database

[Edward Leafe]

On May 3, 2016, at 7:05 PM, Mark Doffman  wrote:

> This thread has been a depressing read.
> 
> I understand that the content is supposed to be distributed databases but for 
> me it has become an inquisition of cellsV2.

Thanks for bringing this up, and I feel a lot of the responsibility for this 
direction. To make how I see things clearer, I wrote a follow-up blog post [0], 
but for those who aren’t inclined to read it, I think that Cells V2 is a great 
idea and could be very helpful for many deployments. My only concern was the 
choice of fragmenting the data. I would hope that any further discussion 
focuses on that.

[0] http://blog.leafe.com/index.php/2016/05/04/mea-culpa-and-clarification/


-- 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-dev] [nova] Austin summit API session recap

[Matt Riedemann]

On Thursday morning Sean Dague led a double session for work in the Nova
API. The full etherpad is here [1].

There were four main focus areas for discussion:

1. Policy defaults in code
2. Policy discoverability
3. api-ref documentation
4. Deprecating/deleting things from the API

Policy defaults in code
---

Andrew Laski has a spec up for review for policy defaults in code [2].
This would allow us to ship an empty policy.json file and then operators
only need to change the policy.json file when overriding any defaults.
Note that this wouldn't impact the ability to live update/reload the
policy file.

This is mostly agreed on by the Nova team, but the Oslo team has some
concerns around implementation detail which are being worked out in the
spec review.

The next steps for this are:

* The Oslo team needs to review/approve Andrew's specs for the
oslo.policy changes [3].

* Land and release the oslo.policy changes and make the Nova changes
depend on that released version of oslo.policy.

* There will be a patch/review grind in Nova for converting the code to
define the policy defaults in code and use the new construct. This could
be part of the low-hanging-fruit / getting started work.

* We'll most likely provide a nova-manage CLI for dumping the effective
policy and providing a way to diff your policy against the defaults to
see what defaults you already have specified and can clean out of the
policy.json file.

For backports to stable branches, we'll treat this like config options.

Policy discoverability
--

Claudiu Belu has a Nova spec up for review for API policy
discoverability [4].

We asked if we should actually expose the policy over the wire in Newton
and came to the conclusion that we won't. There are a few reasons why:

* Policy is a weird new domain-specific language for consumers and if 
we're going to make it better in the future, we shouldn't expose a rough 
version now since we'll have to honor it in the code and via 
microversions (so it's hard to change once it's available).


* There was a general concern about making sure we have a consistent 
model for this across the OpenStack projects. However, it's unclear 
right now if any other projects are already doing something like this so 
Nova can learn from them.


* This is not just about Nova permissions, it's also about things that 
Nova calls, like creating images in Glance, attaching volumes in Cinder, 
and creating ports in Neutron. The first iteration of this doesn't solve 
that problem.


So ultimately we decided to build the infrastructure for discoverable 
API policy in Nova in Newton but not expose it over the REST API. And we 
don't want to munge permissions (what am I allowed to do on this cloud?) 
with capabilities (what is available on this cloud?). We're strictly 
focusing on permissions right now.


We will, however, provide an evaluation tool via nova-manage that will 
return the calculated policy (permissions) for a given project id and 
the ability to check if a given project id would be able to perform an 
action.


api-ref documentation
-

You can see what the Nova API subteam has converted and cleaned up today 
in the new site built from the in-tree api-ref docs [5].


We agreed on a few things during the session:

* We're going to have an initial docs sprint on Monday 5/9 and Wednesday 
5/11 [6].


* We're not going to expose policy in the api-ref docs in Newton, only 
via the nova-manage tool mentioned above.


* The REST method URL won't include project_id or version, only 
{endpoint} since the user can get that from their service catalog, and 
in Mitaka we made the project_id optional (v2.18). Users can get the 
version via discovery on the root of the API endpoint.


Deprecating/deleting things from the API


We agreed to delete the legacy_v2 code stack within Nova. It's been 
deprecated since Liberty and we've had some weird wrinkles with the v2.1 
on v2.0 compat validation, but those have been sorted out. There is a 
specless blueprint for tracking that work here [7]. Note that this isn't 
dropping the v2.0 REST API, only the legacy v2 code. You'll still be 
able to use openstack_compute_api_v21_legacy_v2_compatible from 
api-paste.ini.


We're going to add a microversion (or set of microversions) that 
deprecate the proxy APIs to Ironic/Cinder/Glance/Neutron. Sean has a 
spec for that here [8]. The idea is after that microversion, users of a 
proxy API will get an error response. Then when we eventually raise the 
minimum microversion high enough we can simply delete these APIs. Each 
API is going to have to be handled on a case by case basis, since they 
aren't all straight proxies. For example, the os-limits API returns some 
resources from compute and some from network, and it has to continue 
working while we have nova-network. But for the network resources when 
using neutron, we'll add a microversion 

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Ethan Gafford]

On Wed, May 4, 2016 at 11:55 AM, Flavio Percoco  wrote:

> On 04/05/16 15:05 +, Amrith Kumar wrote:
>
>> I'm emailing the ML on the subject of a review ongoing in the Trove
>> project regarding image building[1].
>>
>> TL;DR
>>
>> One of the most frequent questions that new users of Trove ask is how and
>> where to get guest images with which to experiment with Trove, and how to
>> build these images for themselves. While documentation about this exists in
>> multiple places (including [2], [3]) this is still something that can do
>> with some improvement.
>>
>> Trove currently uses diskimage-builder for building images used in
>> testing the product and these can serve as a good basis for anyone wishing
>> to build an image for their own use of Trove. The review [1] makes the
>> argument for the libguestfs based approach to building images and advocates
>> that Trove should use this instead of diskimage-builder.
>>
>
> At the summit we discussed the possibility of providing an implementation
> that
> would allow for both DIB and libguestfs to be used but to give priority to
> DIB.
> Since there's no real intention of just switching tools at this point, I
> believe
> it'd be good to amend the spec so that it doesn't mention libguestfs
> should be
> used instead of DiB.
>
> The goal at this stage is to provide both and help these move forward.
>
> I believe that a broader discussion of this is required and I appreciate
>> Greg Haynes' proposal at the design summit to have this discussion on the
>> ML. I took the action item to bring this discussion to the ML.
>>
>> Details follow ...
>>
>> Before going further, I will state my views on these matters.
>>
>> 1. It is important for the Trove project to do things quickly to make it
>> easier for end users who wish to use Trove and who wish to build their own
>> images. I am not concerned what tool or tools a person will use to build
>> these images.
>>
>> 2. If we provide multiple alternatives to image building as part of the
>> Trove project, we should make sure that images built with all sets of tools
>> are equivalent and usable interchangeably. Failing to do this will make it
>> harder for users to use Trove because we will be providing them with a
>> false choice (i.e. the alternatives aren't really alternatives). This is
>> harder than it sounds given the combination of tools, operating systems,
>> and the source(s) from which you can get database software.
>>
>
> Maintaining both in the long run will be harder especially because, as you
> mentioned, the output must be usable interchangeably. However, I think
> we're at
> a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
> and
> some other folks that it'd be beneficial for us to have this discussion
> and to
> also experiment/test other options.
>
> The Sahara team seems to be going in a direction that differs with the one
> used
> by the infra team and the one we're headed to (although they overlap in
> some
> areas).
>

Sahara has support for several image generation-related cases:
1) Packing an image pre-cluster spawn in Nova.
2) Building clusters from a "clean" OS image post-Nova spawn, by
downloading and installing Hadoop/Spark/Storm/WhatHaveYou.
3) Validating images after Nova spawn (to ensure that they're up to spec
for the plugin in question.)

Because of this, we are pulling image generation logic into the plugins
themselves, from a monolithic sahara-image-elements repository. This will
aid us in our eventual hope to pull plugins out of the Sahara tree
entirely; more immediately, it will allow us to define logic for all of
these cases in one place, written eventually in Python. In our Sahara
session at summit, which was also attended by several members of the Ironic
team (thanks all), we discussed our current plan to use libguestfs rather
than DIB as our toolchain; our intent to define a linear, idempotent set of
steps to pack images for any plugin lends itself much more neatly to
libguestfs' API than to DIB's.


> 3. Trove already has elements for all supported databases using DIB in the
>> trove-integration project but these elements are not packaged for customer
>> use. Making them usable by customers is a relatively small effort including
>> providing a wrapper script (derived from redstack[4]) and providing an
>> element to install the guest agent software from a fixed location in
>> addition to the development and testing version that is better suited to
>> Trove development [5] and [6].
>>
>> 4. My comments on various patch sets in the review[1].
>>
>> I agree with Monty and Greg Haynes that we should understand the
>> deficiencies if any in DIB, and if it is in fact the case that they are
>> "intractable/unsolvable", we should switch toolchains. This discussion
>> should include issues faced by the Trove team as well as other teams that
>> may have faced problems with DIB (such as the sahara team who described
>> some of them in the past).

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Monty Taylor]

On 05/04/2016 11:46 AM, Clark Boylan wrote:

On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:

On 04/05/16 15:05 +, Amrith Kumar wrote:

I'm emailing the ML on the subject of a review ongoing in the Trove project 
regarding image building[1].

TL;DR

One of the most frequent questions that new users of Trove ask is how and where 
to get guest images with which to experiment with Trove, and how to build these 
images for themselves. While documentation about this exists in multiple places 
(including [2], [3]) this is still something that can do with some improvement.

Trove currently uses diskimage-builder for building images used in testing the 
product and these can serve as a good basis for anyone wishing to build an 
image for their own use of Trove. The review [1] makes the argument for the 
libguestfs based approach to building images and advocates that Trove should 
use this instead of diskimage-builder.


At the summit we discussed the possibility of providing an implementation
that
would allow for both DIB and libguestfs to be used but to give priority
to DIB.
Since there's no real intention of just switching tools at this point, I
believe
it'd be good to amend the spec so that it doesn't mention libguestfs
should be
used instead of DiB.

The goal at this stage is to provide both and help these move forward.


I disagree, as someone that has tried and failed in the past to build
trove images the goal should be to make that process easy for the user.
Maybe we can finally get rid of redstack years after it was supposed to
go away.


I believe that a broader discussion of this is required and I appreciate Greg 
Haynes' proposal at the design summit to have this discussion on the ML. I took 
the action item to bring this discussion to the ML.

Details follow ...

Before going further, I will state my views on these matters.

1. It is important for the Trove project to do things quickly to make it easier 
for end users who wish to use Trove and who wish to build their own images. I 
am not concerned what tool or tools a person will use to build these images.

2. If we provide multiple alternatives to image building as part of the Trove 
project, we should make sure that images built with all sets of tools are 
equivalent and usable interchangeably. Failing to do this will make it harder 
for users to use Trove because we will be providing them with a false choice 
(i.e. the alternatives aren't really alternatives). This is harder than it 
sounds given the combination of tools, operating systems, and the source(s) 
from which you can get database software.


Maintaining both in the long run will be harder especially because, as
you
mentioned, the output must be usable interchangeably. However, I think
we're at
a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
and
some other folks that it'd be beneficial for us to have this discussion
and to
also experiment/test other options.

The Sahara team seems to be going in a direction that differs with the
one used
by the infra team and the one we're headed to (although they overlap in
some
areas).


Has Sahara expressed their needs somewhere too? This is the first I am
hearing of them having trouble with image builds (I had thought they
were using DIB successfully).


3. Trove already has elements for all supported databases using DIB in the 
trove-integration project but these elements are not packaged for customer use. 
Making them usable by customers is a relatively small effort including 
providing a wrapper script (derived from redstack[4]) and providing an element 
to install the guest agent software from a fixed location in addition to the 
development and testing version that is better suited to Trove development [5] 
and [6].

4. My comments on various patch sets in the review[1].

I agree with Monty and Greg Haynes that we should understand the deficiencies if any in 
DIB, and if it is in fact the case that they are "intractable/unsolvable", we 
should switch toolchains. This discussion should include issues faced by the Trove team 
as well as other teams that may have faced problems with DIB (such as the sahara team who 
described some of them in the past).


++

Agreed with the above. I'm think collaboration should be the preferred
way. I
don't think I've enough technical insight on this topic to provide a
detailed
list of things that are good/bad on either of these tools but I wanted to
mention that I believe providing support for both in the short run is
good for
us and it helps to make a better decision on what tool works best for the
project.

There's someone willing to do the job and spend sometime doing the
research.
This same person will provide feedback in addition to the one already
provided
in [1].

Sorry for not providing much technical details now but I did want to
share the
above. Thanks for starting this thread, I believe this discussion in the
ML will
be beneficial.


This is the problem. We need 

[openstack-dev] [stable] Requesting exception for stable/kilo

[Sukhdev Kapur]

Hi Stable Maintainers,

We have a critical bug impacting customers production network. This is a
minor fix.
I would like to request an exception so that the customers do not have to
baby
sit this patch.

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

Please allow this to be merged.

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Gregory Haynes]

On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
> On 04/05/16 15:05 +, Amrith Kumar wrote:
> >I'm emailing the ML on the subject of a review ongoing in the Trove project 
> >regarding image building[1].
> >
> >TL;DR
> >
> >One of the most frequent questions that new users of Trove ask is how and 
> >where to get guest images with which to experiment with Trove, and how to 
> >build these images for themselves. While documentation about this exists in 
> >multiple places (including [2], [3]) this is still something that can do 
> >with some improvement.
> >
> >Trove currently uses diskimage-builder for building images used in testing 
> >the product and these can serve as a good basis for anyone wishing to build 
> >an image for their own use of Trove. The review [1] makes the argument for 
> >the libguestfs based approach to building images and advocates that Trove 
> >should use this instead of diskimage-builder.
> 
> At the summit we discussed the possibility of providing an implementation
> that
> would allow for both DIB and libguestfs to be used but to give priority
> to DIB.
> Since there's no real intention of just switching tools at this point, I
> believe
> it'd be good to amend the spec so that it doesn't mention libguestfs
> should be
> used instead of DiB.
> 
> The goal at this stage is to provide both and help these move forward.
> 
> >I believe that a broader discussion of this is required and I appreciate 
> >Greg Haynes' proposal at the design summit to have this discussion on the 
> >ML. I took the action item to bring this discussion to the ML.
> >
> >Details follow ...
> >
> >Before going further, I will state my views on these matters.
> >
> >1. It is important for the Trove project to do things quickly to make it 
> >easier for end users who wish to use Trove and who wish to build their own 
> >images. I am not concerned what tool or tools a person will use to build 
> >these images.

++. One of the biggest issues I see users of DIB hit is ease of use for
'just make me an image, I don't care about twiddling knobs'. A wrapper
script in trove is one way to help with this, but I am sure there are
other solutions as well... maybe by rethinking some of our fear about
using elements as entry points to an image build, or by simply making
element's with better defaults.

> >
> >2. If we provide multiple alternatives to image building as part of the 
> >Trove project, we should make sure that images built with all sets of tools 
> >are equivalent and usable interchangeably. Failing to do this will make it 
> >harder for users to use Trove because we will be providing them with a false 
> >choice (i.e. the alternatives aren't really alternatives). This is harder 
> >than it sounds given the combination of tools, operating systems, and the 
> >source(s) from which you can get database software.
> 
> Maintaining both in the long run will be harder especially because, as
> you
> mentioned, the output must be usable interchangeably. However, I think
> we're at
> a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
> and
> some other folks that it'd be beneficial for us to have this discussion
> and to
> also experiment/test other options.
> 
> The Sahara team seems to be going in a direction that differs with the
> one used
> by the infra team and the one we're headed to (although they overlap in
> some
> areas).
> 

I would highly recommend against having two sets of image building code
for Trove - given DIB's current design there should not be any need for
this and there's a HUGE downside to maintaining two sets of code to do
the same thing in-tree. Ideally a single set of code would be used while
being able to be run in different environments if there are mutually
exclusive requirements being proposed by users.

What seemed very apparent to me in the summit session is that there are
a set of issues for Trove relating to image building, mostly relating to
reliability and ease of use. There was no one who even mentioned let
alone strongly cared about the issues which actually differentiate the
existing DIB build process from libguestfs (which is isolation). If that
has changed for some reason, then my recommendation would be to use a
tool like virt-dib which will allow for a single image building code
base while solving all the raised issues in the spec. I suspect when
this is tried out the downsides to booting a VM will highly outweigh the
benefits for almost all users (especially in trove's gate), but if the
libguestfs docs are to be believed this should be trivial to try out.


> >3. Trove already has elements for all supported databases using DIB in the 
> >trove-integration project but these elements are not packaged for customer 
> >use. Making them usable by customers is a relatively small effort including 
> >providing a wrapper script (derived from redstack[4]) and providing an 
> >element to install the guest agent software from a fixed location in 
> 

Re: [openstack-dev] [tc] supporting Go

[Fox, Kevin M]

Ok. Sure. More generically then. There are OpenStack compatible API 
implementations existing in the world, deployed by a not insignificant number 
of production clouds, that are currently outside the big tent that may have not 
considered proposing joining the community because of the past history of 
Python onlyness in the community. If we're considering Go, should we also be 
considering C++? Go currently has no production level OpenStack code finished. 
C++ does.

Thanks,
Kevin

From: Shinobu Kinjo [shinobu...@gmail.com]
Sent: Wednesday, May 04, 2016 3:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

- Could we kindly stop discussing radosgw at this moment?
+ Could we kindly stop discussing any particular application at this moment?

On Wed, May 4, 2016 at 7:02 PM, Shinobu Kinjo  wrote:
> Could we kindly stop discussing radosgw at this moment?
>
> On Wed, May 4, 2016 at 6:47 PM, Thierry Carrez  wrote:
>> Fox, Kevin M wrote:
>>>
>>> RadosGW has been excluded from joining the OpenStack community in part due
>>> to its use of c++.
>>
>>
>> I'm not sure I'd use the word "excluded" since RadosGW was never actually
>> proposed. Maybe our past Python-centricity discouraged them to apply, but
>> that's conjecture.
>>
>>> Now that we're talking about alternate languages, that may be on the table
>>> now?
>>
>>
>> It's been a possibility for the last 8 months.
>>
>> That said, my personal view is that we should accept additional languages
>> when the current set of accepted languages is suboptimal for something we
>> want to write or create. A technical benefit to outweigh the community
>> fragmentation and increase in infrastructure tasks that result from adding
>> that language.
>>
>> I'm less convinced that we should add a language for the sole benefit of
>> being able to absorb an existing project into OpenStack which happens to be
>> written in a specific language. Especially if the then-supported set of
>> languages could provide the same technical benefits.
>>
>> --
>> 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
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



--
Email:
shin...@linux.com
shin...@redhat.com

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

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Clark Boylan]

On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
> On 04/05/16 15:05 +, Amrith Kumar wrote:
> >I'm emailing the ML on the subject of a review ongoing in the Trove project 
> >regarding image building[1].
> >
> >TL;DR
> >
> >One of the most frequent questions that new users of Trove ask is how and 
> >where to get guest images with which to experiment with Trove, and how to 
> >build these images for themselves. While documentation about this exists in 
> >multiple places (including [2], [3]) this is still something that can do 
> >with some improvement.
> >
> >Trove currently uses diskimage-builder for building images used in testing 
> >the product and these can serve as a good basis for anyone wishing to build 
> >an image for their own use of Trove. The review [1] makes the argument for 
> >the libguestfs based approach to building images and advocates that Trove 
> >should use this instead of diskimage-builder.
> 
> At the summit we discussed the possibility of providing an implementation
> that
> would allow for both DIB and libguestfs to be used but to give priority
> to DIB.
> Since there's no real intention of just switching tools at this point, I
> believe
> it'd be good to amend the spec so that it doesn't mention libguestfs
> should be
> used instead of DiB.
> 
> The goal at this stage is to provide both and help these move forward.

I disagree, as someone that has tried and failed in the past to build
trove images the goal should be to make that process easy for the user.
Maybe we can finally get rid of redstack years after it was supposed to
go away.

> >I believe that a broader discussion of this is required and I appreciate 
> >Greg Haynes' proposal at the design summit to have this discussion on the 
> >ML. I took the action item to bring this discussion to the ML.
> >
> >Details follow ...
> >
> >Before going further, I will state my views on these matters.
> >
> >1. It is important for the Trove project to do things quickly to make it 
> >easier for end users who wish to use Trove and who wish to build their own 
> >images. I am not concerned what tool or tools a person will use to build 
> >these images.
> >
> >2. If we provide multiple alternatives to image building as part of the 
> >Trove project, we should make sure that images built with all sets of tools 
> >are equivalent and usable interchangeably. Failing to do this will make it 
> >harder for users to use Trove because we will be providing them with a false 
> >choice (i.e. the alternatives aren't really alternatives). This is harder 
> >than it sounds given the combination of tools, operating systems, and the 
> >source(s) from which you can get database software.
> 
> Maintaining both in the long run will be harder especially because, as
> you
> mentioned, the output must be usable interchangeably. However, I think
> we're at
> a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
> and
> some other folks that it'd be beneficial for us to have this discussion
> and to
> also experiment/test other options.
> 
> The Sahara team seems to be going in a direction that differs with the
> one used
> by the infra team and the one we're headed to (although they overlap in
> some
> areas).

Has Sahara expressed their needs somewhere too? This is the first I am
hearing of them having trouble with image builds (I had thought they
were using DIB successfully).

> >3. Trove already has elements for all supported databases using DIB in the 
> >trove-integration project but these elements are not packaged for customer 
> >use. Making them usable by customers is a relatively small effort including 
> >providing a wrapper script (derived from redstack[4]) and providing an 
> >element to install the guest agent software from a fixed location in 
> >addition to the development and testing version that is better suited to 
> >Trove development [5] and [6].
> >
> >4. My comments on various patch sets in the review[1].
> >
> >I agree with Monty and Greg Haynes that we should understand the 
> >deficiencies if any in DIB, and if it is in fact the case that they are 
> >"intractable/unsolvable", we should switch toolchains. This discussion 
> >should include issues faced by the Trove team as well as other teams that 
> >may have faced problems with DIB (such as the sahara team who described some 
> >of them in the past).
> 
> ++
> 
> Agreed with the above. I'm think collaboration should be the preferred
> way. I
> don't think I've enough technical insight on this topic to provide a
> detailed
> list of things that are good/bad on either of these tools but I wanted to
> mention that I believe providing support for both in the short run is
> good for
> us and it helps to make a better decision on what tool works best for the
> project.
> 
> There's someone willing to do the job and spend sometime doing the
> research.
> This same person will provide feedback in addition to the one already
> provided
> in [1].
> 
> Sorry 

[openstack-dev] [designate] Reminder - IRC meeting postponed this week

[Hayes, Graham]

As discussed in the design summit - we are skipping the IRC meeting
today.

Talk to you all in a week / #openstack-dns

- Graham

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

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Flavio Percoco]

On 04/05/16 15:05 +, Amrith Kumar wrote:

I'm emailing the ML on the subject of a review ongoing in the Trove project 
regarding image building[1].

TL;DR

One of the most frequent questions that new users of Trove ask is how and where 
to get guest images with which to experiment with Trove, and how to build these 
images for themselves. While documentation about this exists in multiple places 
(including [2], [3]) this is still something that can do with some improvement.

Trove currently uses diskimage-builder for building images used in testing the 
product and these can serve as a good basis for anyone wishing to build an 
image for their own use of Trove. The review [1] makes the argument for the 
libguestfs based approach to building images and advocates that Trove should 
use this instead of diskimage-builder.


At the summit we discussed the possibility of providing an implementation that
would allow for both DIB and libguestfs to be used but to give priority to DIB.
Since there's no real intention of just switching tools at this point, I believe
it'd be good to amend the spec so that it doesn't mention libguestfs should be
used instead of DiB.

The goal at this stage is to provide both and help these move forward.


I believe that a broader discussion of this is required and I appreciate Greg 
Haynes' proposal at the design summit to have this discussion on the ML. I took 
the action item to bring this discussion to the ML.

Details follow ...

Before going further, I will state my views on these matters.

1. It is important for the Trove project to do things quickly to make it easier 
for end users who wish to use Trove and who wish to build their own images. I 
am not concerned what tool or tools a person will use to build these images.

2. If we provide multiple alternatives to image building as part of the Trove 
project, we should make sure that images built with all sets of tools are 
equivalent and usable interchangeably. Failing to do this will make it harder 
for users to use Trove because we will be providing them with a false choice 
(i.e. the alternatives aren't really alternatives). This is harder than it 
sounds given the combination of tools, operating systems, and the source(s) 
from which you can get database software.


Maintaining both in the long run will be harder especially because, as you
mentioned, the output must be usable interchangeably. However, I think we're at
a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and
some other folks that it'd be beneficial for us to have this discussion and to
also experiment/test other options.

The Sahara team seems to be going in a direction that differs with the one used
by the infra team and the one we're headed to (although they overlap in some
areas).


3. Trove already has elements for all supported databases using DIB in the 
trove-integration project but these elements are not packaged for customer use. 
Making them usable by customers is a relatively small effort including 
providing a wrapper script (derived from redstack[4]) and providing an element 
to install the guest agent software from a fixed location in addition to the 
development and testing version that is better suited to Trove development [5] 
and [6].

4. My comments on various patch sets in the review[1].

I agree with Monty and Greg Haynes that we should understand the deficiencies if any in 
DIB, and if it is in fact the case that they are "intractable/unsolvable", we 
should switch toolchains. This discussion should include issues faced by the Trove team 
as well as other teams that may have faced problems with DIB (such as the sahara team who 
described some of them in the past).


++

Agreed with the above. I'm think collaboration should be the preferred way. I
don't think I've enough technical insight on this topic to provide a detailed
list of things that are good/bad on either of these tools but I wanted to
mention that I believe providing support for both in the short run is good for
us and it helps to make a better decision on what tool works best for the 
project.

There's someone willing to do the job and spend sometime doing the research.
This same person will provide feedback in addition to the one already provided
in [1].

Sorry for not providing much technical details now but I did want to share the
above. Thanks for starting this thread, I believe this discussion in the ML will
be beneficial.

Flavio


Thanks,

-amrith


[1] https://review.openstack.org/#/c/295274/
[2] http://docs.openstack.org/developer/trove/dev/building_guest_images.html
[3] 
https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element
[4] 
http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack
[5] 
http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf
[6] 

Re: [openstack-dev] [Cinder] Nominating Michał Dulko to Cinder Core

[yang, xing]

+1.  Michal will be a great addition to the core team.

Thanks,
Xing

> On May 3, 2016, at 2:19 PM, Sean McGinnis  wrote:
> 
> Hey everyone,
> 
> I would like to nominate Michał Dulko to the Cinder core team. Michał's
> contributions with both code reviews [0] and code contributions [1] have
> been significant for some time now.
> 
> His persistence with versioned objects has been instrumental in getting
> support in the Mitaka release for rolling upgrades.
> 
> If there are no objections from current cores by next week, I will add
> Michał to the core group.
> 
> [0] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
> [1]
> https://review.openstack.org/#/q/owner:%22Michal+Dulko+%253Cmichal.dulko%2540intel.com%253E%22++status:merged
> 
> Thanks!
> 
> Sean McGinnis (smcginnis)
> 
> 
> __
> OpenStack Development Mailing 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] [infra][neutron][nova] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

Hi all,

in case you are wondering what's the progress of this, I am happy to say
that we finally have a link in reviewday [1] that points to the Neutron
dashboard that it's constantly updated. It took some effort to get
there, thanks to the infra team for the help and especially to AJaeger.
Now that the groundwork is done, I think this strategy can be easily
adopted by other projects.

cheers,

Rossella

[1] http://status.openstack.org//reviews/

On 03/23/2016 05:40 PM, Rossella Sblendido wrote:
> 
> 
> On 03/22/2016 02:28 PM, Markus Zoeller wrote:
>>> From: Jeremy Stanley 
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> Date: 02/18/2016 02:05 AM
>>> Subject: Re: [openstack-dev] [infra][neutron] publish and update 
>>> Gerrit dashboard link automatically
>>>
>>> On 2016-02-16 14:52:04 -0700 (-0700), Carl Baldwin wrote:
>>> [...]
 No matter how it is done, there is the problem of where to host such a
 page which can be automatically updated daily (or more often) by this
 script.

 Any thoughts from infra on this?
>>>
>>> A neat idea, and sounds like an evolution of/replacement for
>>> reviewday[1][2]. Our community already has all the tools it needs
>>> for running scripts and publishing the results in an automated
>>> fashion (based on a timer, triggered by merged commits in a Git
>>> repo, et cetera), as well as running Web servers... you could just
>>> add a vhost to the openstack_project::static class[3] and then a job
>>> in our project configuration[4] to update it.
>>>
>>> [1] http://status.openstack.org/reviews/
>>> [2] http://git.openstack.org/cgit/openstack-infra/reviewday/
>>> [3] http://git.openstack.org/cgit/openstack-infra/system-config/tree/
>>> modules/openstack_project/manifests/static.pp
>>> [4] http://git.openstack.org/cgit/openstack-infra/project-config/tree/
>>> jenkins/jobs/
>>> -- 
>>> Jeremy Stanley
>>
>> I didn't see this thread back then when it started. I think Nova would
>> benefit from that too. I didn't find a Neutron related change in [1]
>> as Jeremy suggested. I'm mainly interested in bug fix changes, ordered
>> by bug report importance.
>>
>> @Rossella: 
>> Are you still working on this or is this solved in another way?
> 
> Hi Markus,
> 
> yes I am still working on this. The idea is to use Gerrit project
> dashboard as suggested by jeblair[1]. I pushed a patch for Neutron [2],
> it's still work in progress, waiting for feedback from infra.
> 
> cheers,
> 
> Rossella
> 
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-11.log.html#t2016-03-11T14:47:06
> [2] https://review.openstack.org/#/c/284284/
> 
>>
>> References:
>> [1] 
>> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> __
> OpenStack Development Mailing 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] [magnum] Add support for using Keystone in k8s bay

[Hongbin Lu]

Hi team,

Based on requests, I propose to add support for Keystone authentication for k8s 
bay. A blueprint was created for that:

https://blueprints.launchpad.net/magnum/+spec/keystone-for-k8s-bay

A goal is to enable other OpenStack services to access the APIs of k8s bays. So 
far, I received a use case from a under-developing Horizon k8s plugin. I 
believe there will be more similar use cases from other services. For the 
implementation, I think it is straightforward. Keystone authentication is 
already supported in k8s upstream [1]. Magnum could simply add an option for 
users to turn it on. As an initial step, I suggest to support passing the auth 
option via labels (e.g. '-labels k8s-auth=keystone'). If Keystone is supported 
by other COEs in the future, we could promote this option as a baymodel 
attribute. Thoughts?

[1] http://kubernetes.io/docs/admin/authentication/

Best regards,
Hongbin
__
OpenStack Development Mailing 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] summit fishbowl summary

[Doug Hellmann]

Last week we had a retrospective for the Mitaka release and a planning
session for the Newton release. The notes are in the etherpad [1],
and this email is a summary based on those notes. As usual, if I've left
out something important or mis-remembered something, please post a
follow-up.

Doug


Retrospective
-

The overall sentiment expressed by distro folks in the room was that the
Mitaka release went well and was somewhat less stressful than the Liberty
release. In particular with the shorter release candidate period we had
fewer feature freeze exceptions requested and granted, which in turn
resulted in fewer release candidates. It's great to hear the positive
outcome, and we hope to eliminate some of the remaining friction this
cycle through more automation and education of project teams.

Regarding that education, one of the main sources of issues is PTLs and
liaisons not seeing or reading emails from the release team. There's a
lot of volume on this mailing list, so we're going to make a few changes
to make it easier to see the important notices. For instance, we agreed
that mixing release announcement emails and release team notices by using
the same [release] tag wasn't optimal. We'll be changing the tag used for
release announcements, since that should ultimately introduce the least
amount of confusion for PTLs and liaisons who are already subscribed to
the [release] topic (you *are* already subscribed, right?). More details
on that will come soon when we make the change.

Another issue we ran into late in the cycle was teams not understanding
the ramifications of the independent release model. We have added the
cycle-trailing model and are encouraging some other teams to use the
cycle-with-intermediary model to address those concerns.

Final Release Process Changes
-

>From a process perspective, one of the most manually intensive tasks we
have left is tracking release candidates from project teams. We discussed
various options for building a dashboard to track that information, but
pulling the information together automatically can be difficult because
sometimes the artifact we would use for tracking doesn't exist (there's
not a bug yet, etc.). We're going to be experimenting with having the
project teams manage their status directly this cycle, with the release
team facilitating but not trying to track each project ourselves. We need
to document the process for this, so we'll have more details closer to
the end of the cycle when the changes come into play. In the mean time,
we will continue to follow date-based deadlines for the major milestones
on the schedule [2], and expect PTLs/liaisons to submit tag requests on
their own as they did for Mitaka.

Freezes
---

A few folks brought up the issue of communication about release freeze
periods, and in fact enforcing those periods at appropriate times such
as before major holidays. We will be adding details about freeze dates
to the schedule for dates we know in advance, and doing a better job of
communicating freezes (scheduled or otherwise, such as this week). Aside
from full freezes, keep in mind that we tend not to perform releases on
Thursday or Friday (as defined in the western hemisphere).

Expanding Automation


During the Mitaka cycle we took major steps in automating the release
review process, giving us the ability to manage releases the way we do
most everything else in the community, with someone to double-check
our work. We plan to further automate the process during Newton,
and as a result the release team is comfortable expanding beyond the
release:managed projects to any project using a cycle-based release
model. The changes needed for that expansion have already been made in
the project-config repository. If you used to have the ability to tag
releases directly, but cannot now, that's why. Drop by #openstack-release
if you need help getting set up with the openstack/releases repository.

Requirements Team
-

We had several discussions throughout the week about spinning out a
separate team to manage the openstack/requirements repository. Without
a volunteer to lead the team, we agreed to spend the first few months
mentoring some new reviewers and to have another discussion about a new
team somewhere mid-cycle. If you are interested in getting involved in
that work, please add your name to the list on [3] and start participating
in reviews.


[1] https://etherpad.openstack.org/p/newton-release-fishbowl
[2] http://releases.openstack.org/newton/schedule.html
[3] https://etherpad.openstack.org/p/newton-relmgt-plan

__
OpenStack Development Mailing 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] [kolla] better solution for the non-ini format configure file

[Mauricio Lima]

I agree with your approach Jeffrey, although this is not ideal, this is an
approach already used in kolla.

2016-05-04 12:01 GMT-03:00 Jeffrey Zhang :

> Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to the
> globals.yml file.
> Because there is no chance to change the horizon/apache configure file now.
>
> The root cause is that: Kolla do not support non-ini format configure
> file. for the
> ini-format file, we use a merge_config module[1] to merge all the found
> file. But it
> will be not work for configure file for apache, rabbitmq and so on.
>
> I would like to the current merge_config implementation. It is directly
> and easy to use.
> Not like the puppet, we have to remember the variable name defined in the
> module. we have
> no chance to add some user-defined variable.
>
> Export the variable to global is very bad and ugly. It will became a
> disaster when more
> and more variables is exported.
>
> So we should catch up a better solution to handle the configure file.
>
> One solution I have is use overwrite mechanism. for example when there is
> a file in
> /etc/kolla/config/apache.conf, it will overwrite the templates in the
> roles. But this
> is still not ideal.
>
> Any body has better solution?
>
> [0] https://review.openstack.org/306928
> [1]
> http://git.openstack.org/cgit/openstack/kolla/tree/ansible/action_plugins/merge_configs.py
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [dib][trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Amrith Kumar]

Adding [dib] to the subject line.

-amrith

> -Original Message-
> From: Amrith Kumar [mailto:amr...@tesora.com]
> Sent: Wednesday, May 04, 2016 11:05 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
> 
> I'm emailing the ML on the subject of a review ongoing in the Trove
> project regarding image building[1].
> 
> TL;DR
> 
> One of the most frequent questions that new users of Trove ask is how and
> where to get guest images with which to experiment with Trove, and how to
> build these images for themselves. While documentation about this exists
> in multiple places (including [2], [3]) this is still something that can
> do with some improvement.
> 
> Trove currently uses diskimage-builder for building images used in testing
> the product and these can serve as a good basis for anyone wishing to
> build an image for their own use of Trove. The review [1] makes the
> argument for the libguestfs based approach to building images and
> advocates that Trove should use this instead of diskimage-builder.
> 
> I believe that a broader discussion of this is required and I appreciate
> Greg Haynes' proposal at the design summit to have this discussion on the
> ML. I took the action item to bring this discussion to the ML.
> 
> Details follow ...
> 
> Before going further, I will state my views on these matters.
> 
> 1. It is important for the Trove project to do things quickly to make it
> easier for end users who wish to use Trove and who wish to build their own
> images. I am not concerned what tool or tools a person will use to build
> these images.
> 
> 2. If we provide multiple alternatives to image building as part of the
> Trove project, we should make sure that images built with all sets of
> tools are equivalent and usable interchangeably. Failing to do this will
> make it harder for users to use Trove because we will be providing them
> with a false choice (i.e. the alternatives aren't really alternatives).
> This is harder than it sounds given the combination of tools, operating
> systems, and the source(s) from which you can get database software.
> 
> 3. Trove already has elements for all supported databases using DIB in the
> trove-integration project but these elements are not packaged for customer
> use. Making them usable by customers is a relatively small effort
> including providing a wrapper script (derived from redstack[4]) and
> providing an element to install the guest agent software from a fixed
> location in addition to the development and testing version that is better
> suited to Trove development [5] and [6].
> 
> 4. My comments on various patch sets in the review[1].
> 
> I agree with Monty and Greg Haynes that we should understand the
> deficiencies if any in DIB, and if it is in fact the case that they are
> "intractable/unsolvable", we should switch toolchains. This discussion
> should include issues faced by the Trove team as well as other teams that
> may have faced problems with DIB (such as the sahara team who described
> some of them in the past).
> 
> Thanks,
> 
> -amrith
> 
> 
> [1] https://review.openstack.org/#/c/295274/
> [2]
> http://docs.openstack.org/developer/trove/dev/building_guest_images.html
> [3] https://git.openstack.org/cgit/openstack/diskimage-
> builder/tree/README.rst#writing-an-element
> [4] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/redstack
> [5] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/files/trove-guest.systemd.conf
> [6] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/files/trove-guest.upstart.conf
> 
> __
> OpenStack Development Mailing 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] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Amrith Kumar]

I'm emailing the ML on the subject of a review ongoing in the Trove project 
regarding image building[1].

TL;DR

One of the most frequent questions that new users of Trove ask is how and where 
to get guest images with which to experiment with Trove, and how to build these 
images for themselves. While documentation about this exists in multiple places 
(including [2], [3]) this is still something that can do with some improvement.

Trove currently uses diskimage-builder for building images used in testing the 
product and these can serve as a good basis for anyone wishing to build an 
image for their own use of Trove. The review [1] makes the argument for the 
libguestfs based approach to building images and advocates that Trove should 
use this instead of diskimage-builder.

I believe that a broader discussion of this is required and I appreciate Greg 
Haynes' proposal at the design summit to have this discussion on the ML. I took 
the action item to bring this discussion to the ML.

Details follow ...

Before going further, I will state my views on these matters.

1. It is important for the Trove project to do things quickly to make it easier 
for end users who wish to use Trove and who wish to build their own images. I 
am not concerned what tool or tools a person will use to build these images.

2. If we provide multiple alternatives to image building as part of the Trove 
project, we should make sure that images built with all sets of tools are 
equivalent and usable interchangeably. Failing to do this will make it harder 
for users to use Trove because we will be providing them with a false choice 
(i.e. the alternatives aren't really alternatives). This is harder than it 
sounds given the combination of tools, operating systems, and the source(s) 
from which you can get database software.

3. Trove already has elements for all supported databases using DIB in the 
trove-integration project but these elements are not packaged for customer use. 
Making them usable by customers is a relatively small effort including 
providing a wrapper script (derived from redstack[4]) and providing an element 
to install the guest agent software from a fixed location in addition to the 
development and testing version that is better suited to Trove development [5] 
and [6].

4. My comments on various patch sets in the review[1].

I agree with Monty and Greg Haynes that we should understand the deficiencies 
if any in DIB, and if it is in fact the case that they are 
"intractable/unsolvable", we should switch toolchains. This discussion should 
include issues faced by the Trove team as well as other teams that may have 
faced problems with DIB (such as the sahara team who described some of them in 
the past).

Thanks,

-amrith


[1] https://review.openstack.org/#/c/295274/
[2] http://docs.openstack.org/developer/trove/dev/building_guest_images.html
[3] 
https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element
[4] 
http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack
[5] 
http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf
[6] 
http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.upstart.conf

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

[openstack-dev] [kolla] better solution for the non-ini format configure file

[Jeffrey Zhang]

Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to the
globals.yml file.
Because there is no chance to change the horizon/apache configure file now.

The root cause is that: Kolla do not support non-ini format configure file.
for the
ini-format file, we use a merge_config module[1] to merge all the found
file. But it
will be not work for configure file for apache, rabbitmq and so on.

I would like to the current merge_config implementation. It is directly and
easy to use.
Not like the puppet, we have to remember the variable name defined in the
module. we have
no chance to add some user-defined variable.

Export the variable to global is very bad and ugly. It will became a
disaster when more
and more variables is exported.

So we should catch up a better solution to handle the configure file.

One solution I have is use overwrite mechanism. for example when there is a
file in
/etc/kolla/config/apache.conf, it will overwrite the templates in the
roles. But this
is still not ideal.

Any body has better solution?

[0] https://review.openstack.org/306928
[1]
http://git.openstack.org/cgit/openstack/kolla/tree/ansible/action_plugins/merge_configs.py

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

Re: [openstack-dev] [oslo] config: deduce related options for config generator?

[Markus Zoeller]

> From: Doug Hellmann 
> To: openstack-dev 
> Date: 05/03/2016 07:04 PM
> Subject: Re: [openstack-dev] [oslo] config: deduce related options for
> config generator?
> 
> Excerpts from Markus Zoeller's message of 2016-05-03 18:26:50 +0200:
> > While working on [1] I came across a config option ("pybasedir")
> > which gets used as a base for many other options, for example
> > "state_path". The option "state_path" shows then a default value
> > "state_path = $pybasedir".
> > My question here is, is it possible/reasonable to enhance oslo.config
> > to add an information to "pybasedir" that is used as a base for other
> > config options?
> > My concern is, that one could change "pybasedir" and expect that only
> > this one single value changes, but actually one changes multiple other
> > config options as well. Making it explicit that "pybasedir" gets used
> > multiple times as a base could prevent confusion.
> > 
> > References:
> > [1] https://review.openstack.org/#/c/299236/7/nova/conf/paths.py
> > 
> > Regards, Markus Zoeller (markus_z)
> > 
> 
> (Sorry if this is a dupe, I'm having mail client issues.)
> 
> We can detect interpolated values in defaults, but those can also appear
> in user-provided values. There are also plenty of options that are
> related to each other without using interpolation.
> 
> Given that we have to handle the explicit cases anyway, and that
> interpolation isn't used all that often, I think it likely makes more
> sense to start with the explicit implementation and see how far that
> takes us before adding any automation.
> 
> Doug
> 

Yeah, interpolation is rarely used (at least in Nova). I only had the 
usage of interpolation in default values in mind. If the effort in 
oslo.config would be too big, it probably isn't reasonable to push
this. Thank you Doug, for checking the possibilities.

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [glance] [glare] [heat] [tosca] [tacker] [murano] [magnum] [app-catalog] Austin summit summary: Generic cataloging and Glare v1 API

[Nikhil Komawar]

Hi Bob,

Thanks for reaching out!

We're in the process of finalizing the API and the team is working hard
on getting the code ready; atm with near to complete functionality WIP
patches. Please be mindful of the fact that there is currently an
experimental API in glance and code that will change completely. As we
do not want to document these things, they are missing from the search
results of advanced search engines.

A good reference document is [1] . This spec has evolved over time and
has input from many a standards so I do not expect drastic changes
unless some security loophole is found during testing (Probability ~0.1).

Hope that helps.

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

On 5/4/16 10:08 AM, HADDLETON, Robert W (Bob) wrote:
> Hi Nikhil:
> The Tacker project may also be interested in using Glare during
> this cycle.  Is there any API or other documentation/examples that we
> could use to start?
>
> Thanks
>
> Bob
>
> On 5/3/2016 2:40 PM, EXT Nikhil Komawar wrote:
>> Comment inline.
>>
>> On 5/3/16 3:21 PM, Flavio Percoco wrote:
>>> On 02/05/16 19:09 -0400, Nikhil Komawar wrote:
>>>
 Added a few more tags to the subject line.



 On 5/2/16 7:05 PM, Nikhil Komawar wrote:

> Hello everyone,
>
>
>
> Just wanted to send a brief summary of the discussions at the summit.
>
> This list is not holistic however, it covers the relevant aspects
> that
>
> various stakeholders need to be aware of.
>
>
>
>* Glare is useful for different use cases in OpenStack including
>
>  currently being asked for in Heat, Murano and TOSCA
>
>* Heat needs something for usage in Newton
>
>* Murano needs the stable API to adapt the changes as they
> currently
>
>  use experimental version
>
>* Glance team will continue to make progress on this effort and
> plan
>
>  to have POC after Newton R-16 [1]
>
>* The initial plan is to focus on base artifact (no data asset
>
>  associated) and then support at least one artifact type
>
>* The first artifact can be Murano application catalogs or Heat
>
>  templates depending on either team's priorities when Glare is
> ready
>
>  for consumption
>
>* In Newton, we will focus on the adoption of this service in
> at least
>
>  the above mentioned two projects and getting the API in good
> shape
>
>* Images compatibility is deferred for now
>
>* Glare will be a side-priority for Newton meaning most of the
> cores
>
>  are currently not expected to prioritize reviews on it except
> for
>
>  those who want to focus on cross project initiatives and those
>
>  involved in its adoption
>
>>>
>>> Does this mean there will be some sort of "Fast Track" again? I'm
>>> asking because
>> No, we won't have the FastTrack model. But at the same time, we want to
>> iterate over the code once that is consumed by the first service so that
>> the behavioral changes found during that phase can be corrected before
>> m-3. The end goal is to have a good API that can be consumed by other
>> services (and something compliant with OpenStack standards).
>>
>>> I believe this model polarizes the community a bit as far as picking
>>> reviews go.
>>>
>>> We voted to remove it in Mitaka and I was hoping we would workout a
>>> way to bring
>>>
>>> the community together in the Glare reviews.
>> My goal is to have champions for each module that is being worked on in
>> Newton (import, micro-versions, glare, documentation, etc) . This does
>> have a little bit of effect in creating tribal knowledge but we do have
>> that even today. The iterative plan though (yet to be formalized) is
>> that we need some sort of knowledge sharing model. I have been trying to
>> do that using the dedicated Glare meetings but we may need other models
>> of KT (knowledge transfer) here.
>>
>>>
>>>
>>> Please, don't get me wrong. As far as priorities go, I agree with what
>>> you've
>> Thanks for bringing this up. Refines the thought process for sure.
>>
>>> said in the last point but review wise, I'm worried this would
>>> implicitly bring
>>>
>>> back some kind of fast track model.
>>>
>>>
>> Let's not go with the FastTrack model :-)
>>
>>> Cheers,
>>>
>>> Flavio
>>>
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing 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: