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 this
Hi,
Several of us have already asked this question in the IRC channel and have not
got a response yet.
Can someone from HPE give us the exact location of the HPE office in Sunnyvale
where the midcycle meetup will be held? This will help us book hotel rooms
close to the venue.
Thanks,
Mura
+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] Docum
?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 g
for operator languagepacks
On Wed, Jun 17, 2015 at 12:53 PM, Murali Allada
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
> place to store metadata
, are you suggesting that we could use swift client for both
>>private and public LP uses? That sounds like a good suggestion to me.
>>
>> Adrian
>>
>>> On Jun 17, 2015, at 11:10 AM, Randall Burt
>>> wrote:
>>>
>>> Can't an operator ma
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 us
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 rig
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 an
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
+1
From: Pierre Padrixe mailto:pierre.padr...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, December 30, 2014 at 5:58 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:open
uld not
expect 99.9% (or more) of the users to deal with a generic workflow.
From: Murali Allada
[mailto:murali.all...@rackspace.com<mailto:murali.all...@rackspace.com>]
Sent: Wednesday, June 04, 2014 12:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: R
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 t
+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
wrote:
> I support this approach.
>
> Customization of build and deploy lifecycle actions depends on
> the ability to register
+1
> On Jan 25, 2014, at 9:04 AM, "Roshan Agrawal"
> 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 questions)
> Cc: OpenSt
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
wrote:
> Hi team,
>
> After merging [1] devstack gate started failing. There is already a
> thread [2] related to this in mailing list. Until this gets fixed
>
ing 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 question
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 o
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
mailto:adrian.o...@rackspace.com>>
wrote:
No, it does not have any parking. I suggest coming
Thanks for the clear explanation Monty.
-Murali
> On Nov 14, 2013, at 10:08 AM, "Monty Taylor" 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 a
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 Year.Minor.Revision.B
21 matches
Mail list logo
