Re: [openstack-dev] [Magnum] Adding opensuse as new driver to Magnum

Michal, The right place for drivers is the /drivers folder. Take a look at the existing drivers as an examples. You'll also need to update this file https://github.com/openstack/magnum/blob/master/setup.cfg#L60 and add a new entry point for the driver. I would encourage you to hold off on

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

+1 Anything with default values should be ignored in the quickstart guide. -Murali From: Steven Dake (stdake) Sent: Thursday, October 8, 2015 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

[openstack-dev] [magnum] keystone pluggable model

?Hi All, In the IRC meeting yesterday, I brought up this new blueprint I opened. https://blueprints.launchpad.net/magnum/+spec/pluggable-keystone-model? The goal of this blueprint is to allow magnum operators to integrate with their version of keystone easily with downstream patches. The

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

swift downloads for operator languagepacks On Wed, Jun 17, 2015 at 12:53 PM, Murali Allada murali.all...@rackspace.com wrote: Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great

[openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a

Re: [openstack-dev] [Solum] Why do app names have to be unique?

I think app names should be unique per tenant. My opinion is that this should be solums default behavior and does not require an extra setting in the config file. I feel the pain of non unique names when I play with my own vagrant environment and deploy multiple 'test' apps. To identify the

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

I agree, users should have a mechanism to keep logs around. I implemented the logs deletion feature after we got a bunch of requests from users to delete logs once they delete an app, so they don't get charged for storage once the app is deleted. My implementation deletes the logs by default

Re: [openstack-dev] [Solum] Should app names be unique?

The only reason this came up yesterday is because we wanted Solums 'app create' behavior to be consistent with other openstack services. However, if heat has a unique stack name constraint and glance\nova don't, then the argument of consistency does not hold. I'm still of the opinion that we

Re: [openstack-dev] [Solum] Addition to solum core

+1 From: Pierre Padrixe pierre.padr...@gmail.commailto:pierre.padr...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, December 30, 2014 at 5:58 PM To: OpenStack Development

Re: [openstack-dev] [solum] reviews for the new API

Angus/Julien, I would disagree that we should expose the mistral DSL to end users. What if we decide to use something other than Mistral in the future? We should be able to plug in any workflow system we want without changing what we expose to the end user. To me, the pipeline DSL is similar

Re: [openstack-dev] [solum] reviews for the new API

not expect 99.9% (or more) of the users to deal with a generic workflow. From: Murali Allada [mailto:murali.all...@rackspace.commailto:murali.all...@rackspace.com] Sent: Wednesday, June 04, 2014 12:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev

Re: [openstack-dev] [solum] use of the plan for m1

+1 for using a simple plan file for M1. I agree, the language pack id would need to be part of the plan file. -Murali On Mar 4, 2014, at 9:20 PM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: I support this approach. Customization of build and deploy lifecycle actions depends

Re: [openstack-dev] [Solum] Proposed changes to solum-core

+1 On Jan 25, 2014, at 9:04 AM, Roshan Agrawal roshan.agra...@rackspace.com wrote: +1 From: Rajesh Ramchandani [rajesh.ramchand...@cumulogic.com] Sent: Friday, January 24, 2014 9:35 PM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Solum] Devstack gate is failing

I'm ok with making this non-voting for Solum until this gets fixed. -Murali On Jan 7, 2014, at 8:53 PM, Noorul Islam Kamal Malmiyoda noo...@noorul.com wrote: Hi team, After merging [1] devstack gate started failing. There is already a thread [2] related to this in mailing list. Until

[openstack-dev] [Solum] API worker architecture

Hi all, I'm working on a new blueprint to define the API service architecture. https://blueprints.launchpad.net/solum/+spec/api-worker-architecture It is still a draft for now. I've proposed a simple architecture for us to get started with implementing a few useful use cases. Please chime in

Re: [openstack-dev] [Solum] API worker architecture

to your comment in the blueprint “To start things off, we can implement workflow #1 shown above and make all requests synchronous” From: Murali Allada [mailto:murali.all...@rackspace.com] Sent: Wednesday, November 27, 2013 12:43 PM To: OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Solum] SFO Design Workshop

If you want to drive to the Rackspace office, here's a list of parking garages in the area. Street parking will be hard to find. http://goo.gl/maps/yuoWW On Nov 18, 2013, at 11:50 AM, Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: No, it does not have any

Re: [openstack-dev] [Solum] Version scheme

I'm not a big fan of using date information in the version number. Is there an advantage to doing that? Using a model like 0.0.1 makes it easier to communicate. A better approach might be to use Major.Minor.Revision.Build. If we want to use dates, Year.Month.Day.Build or

Re: [openstack-dev] [Solum] Version scheme

Thanks for the clear explanation Monty. -Murali On Nov 14, 2013, at 10:08 AM, Monty Taylor mord...@inaugust.com wrote: On 11/14/2013 10:36 AM, Murali Allada wrote: I'm not a big fan of using date information in the version number. Is there an advantage to doing that? Using a model