Re: [openstack-dev] [Murano] Need a new DSL for Murano

Can someone elaborate further on the things that Murano is intended to solve within the OpenStack ecosystem? My observation has been that Murano has changed from a Windows focused Deployment Service to a Metadata Application Catalog Workflow thing (I fully admit this may be an invalid

Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications

Have you considered writing Heat resource plug-ins that perform (or configure within other services) instance snapshots, backups, or whatever other maintenance workflow possibilities you want that don't exist? Then these maintenance workflows you mention could be expressed in the Heat template

Re: [openstack-dev] [heat]Policy on upgades required config changes

I want to echo Clint's responses... We do run close to Heat master here at Rackspace, and we'd be happy to set up a non-voting job to notify when a review would break Heat on our cloud if that would be beneficial. Some of the breaks we have seen have been things that simply weren't caught in code

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

Georgy, In consideration of the can you express it instead of the who will generate it, I see Heat's HOT evolving to support the expression of complex multi-tier architectures and applications (I would argue you can already do this today, perhaps with some additional features desired, e.g.

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

Hi Ruslan, I did not intend to suggest that definition of things like billing rules should necessarily be supported syntax in Heat. Murano is certainly able to develop whatever features it would like, including an alternative DSL. I have a preference towards minimizing DSLs across the OpenStack

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

On 3/25/14 11:55 AM, Ruslan Kamaldinov rkamaldi...@mirantis.com wrote: * Murano DSL will focus on: a. UI rendering One of the primary reasons I am opposed to using a different DSL/project to accomplish this is that the person authoring the HOT template is usually the system architect, and

Re: [openstack-dev] [heat] metadata for a HOT

, April 3, 2014 10:30 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [heat] metadata for a HOT On 04/02/2014 08:41 PM, Keith Bray wrote: https://wiki.openstack.org/wiki/Heat

Re: [openstack-dev] [Heat] HOT Software configuration proposal

Hi Thomas, here's my opinion: Heat and Solum contributors will work closely together to figure out where specific feature implementations belong... But, in general, Solum is working at a level above Heat. To write a Heat template, you have to know about infrastructure setup and configuration

Re: [openstack-dev] [Heat] HOT Software configuration proposal

In-line comments. On 10/28/13 5:43 PM, Steve Baker sba...@redhat.com wrote: On 10/26/2013 05:25 AM, Clint Byrum wrote: Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700: On 24/10/13 11:54 +0200, Patrick Petit wrote: Hi Clint, Thank you! I have few replies/questions in-line.

Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration

The way I view 2 vs. 4 is that 2 is more complicated and you don't gain any benefit of availability. If, in 2, your global heat endpoint is down, you can't update the whole stack. You have to work around it by talking to Heat (or the individual service endpoints) in the region that is still

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800: Hi Steve, As one of the UI developers driving the requirements behind these new blueprints I wanted to take a moment to assure you and the rest of the Openstack

Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap

@lists.openstack.org Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements roadmap On 11/26/2013 03:26 PM, Keith Bray wrote: On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.commailto:cl...@fewbar.com wrote: Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800: Hi

Re: [openstack-dev] [Heat]Heat template parameters encryption

On 6/11/14 2:43 AM, Steven Hardy sha...@redhat.com wrote: IMO, when a template author marks a parameter as hidden/secret, it seems incorrect to store that information in plain text. Well I'd still question why we're doing this, as my previous questions have not been answered: - AFAIK nova

Re: [openstack-dev] [Heat] How the autoscale API should control scaling in Heat

There is context missing here. heat==trove interaction is through the trove API. trove==heat interaction is a _different_ instance of Heat, internal to trove's infrastructure setup, potentially provisioning instances. Public Heat wouldn't be creating instances and then telling trove to make

Re: [openstack-dev] [Heat] How the autoscale API should control scaling in Heat

for scale and performance. The cool part is, I think Heat and all these general services can work in a variety of cool configurations! -Keith On 9/12/13 2:30 AM, Steven Hardy sha...@redhat.com wrote: On Thu, Sep 12, 2013 at 01:07:03AM +, Keith Bray wrote: There is context missing here

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

I think this picture is relevant to Heat context: https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o 0R9U/edit As more and more types of compute (containers, VMs, bare metal) and other resources (geographically dispersed) become available from the cloud with boarder

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

Dev, thanks for bringing up the item about Heat enforcing unique stack names.. My mistake on thinking it supported non-unique stack names. I remember it working early on, but probably got changed/fixed somewhere along the way. My argument in IRC was one based on consistency with

[openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging

Hi folks, I had to leave the app-catalog IRC meeting early today, but I read back through the logs. I wanted to bring up a point about Apps vs. Components, and determination of what is an app and tagging. I don't think it's any more black and white with Solum language packs than it is with

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

Isn't that what the SDK is for? To chip in with a Product Management type hat on, I'd think the CLI should be primarily focused on user experience interaction, and the SDK should be primarily targeted for developer automation needs around programmatically interacting with the service. So, I

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

to suppress those prompts for folks that want to shell script. On Jun 16, 2015, at 4:42 PM, Keith Bray keith.b...@rackspace.com wrote: Isn't that what the SDK is for? To chip in with a Product Management type hat on, I'd think the CLI should be primarily focused on user experience interaction

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

Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway,

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

From: Keith Bray [keith.b...@rackspace.commailto:keith.b...@rackspace.com] Sent: Tuesday, June 16, 2015 4:47 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app? Kevin, I agree with your break

[openstack-dev] [Solum] Roadmap additions

Hi Adrian, As an FYI, I took a shot at updating the OpenStack wiki view of the Roadmap for Solum per IRC and developer collaboration, where good progress has been made over the last cycle delivering on features that make Solum usable in a production OpenStack system environment. This is, of

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

logs be deleted when we delete an app? -1. There are developers and there are users/admins. The former tend to write in python. the latter, shell. Thanks, Kevin From: Keith Bray [keith.b...@rackspace.commailto:keith.b...@rackspace.com] Sent: Tuesday, June 16, 2015

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

Regardless of what the API defaults to, could we have the CLI prompt/warn so that the user easily knows that both options exist? Is there a precedent within OpenStack for a similar situation? E.g. solum app delete MyApp Do you want to also delete your logs? (default is Yes):

Re: [openstack-dev] [App-Catalog] Planning/working session Wednesday in Vancouver

Chris, I am interested in getting more involved. Is there any effort already in place to run this like a regular project, with IRC meetings, etc.? What are the channels, etc., by which I can get involved. Thanks, -Keith On 5/20/15 7:24 AM, Christopher Aedo d...@aedo.net wrote:

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

In-line responses. Thanks for chipping in Monty. -Keith On 5/27/15 6:03 PM, Monty Taylor mord...@inaugust.com wrote: On 05/27/2015 06:35 PM, Keith Bray wrote: Joe, regarding apps-catalog for any app deployable on OpenStack (regardless of deployment technology), my two cents is that is a good

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Kevin, I like your vision. Today we have images, heat templates, Murano packages. What are your thoughts on how to manage additions? Should it be restricted to things in the OpenStack namespace under the big tent? E.g., I'd like to see Solum language packs get added to the app-catalog.

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

From: Keith Bray [keith.b...@rackspace.com] Sent: Wednesday, May 27, 2015 4:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps In-line responses. Thanks for chipping in Monty

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Joe, regarding apps-catalog for any app deployable on OpenStack (regardless of deployment technology), my two cents is that is a good idea. I also believe, however, that the app-catalog needs to evolve first with features that make it super simple to understand which artifacts will work on

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Has an email been posted to the [heat] community for their input? Maybe I missed it. Thanks, -Keith On 6/2/16, 9:42 AM, "Hongbin Lu" wrote: >Madhuri, > >It looks both of us agree the idea of having heterogeneous set of nodes. >For the implementation, I am open to

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

ces are several >orders of magnitude greater then the numbers that can manually deploy >something ala the procedure in the previous paragraph. More of that is >good for Users, Developers, and Operators. > >Does that help? > >Thanks, >Kevin > > >__

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

If you don¹t want a user to have to choose a COE, can¹t we just offer an option for the operator to mark a particular COE as the ³Default COE² that could be defaulted to if one isn¹t specified in the Bay create call? If the operator didn¹t specify a default one, then the CLI/UI must submit one in

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

/c/307883/4 >[2] >https://www.openstack.org/summit/austin-2016/summit-schedule/events/9150 > >> -Original Message- >> From: Keith Bray [mailto:keith.b...@rackspace.com] >> Sent: Thursday, April 21, 2016 5:11 PM >> To: OpenStack Development Mailing List (not f

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

>is an addition, not a replacement. > >Best regards, >Hongbin > >> -Original Message- >> From: Keith Bray [mailto:keith.b...@rackspace.com] >> Sent: April-19-16 7:17 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subj

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I would recommend against implementing a lowest common denominator API for the COEs ³right now.² It¹s too early to tell if the COEs are going to be seen as a commodity (where in the long run they may all perform relatively equal for the majority of workloads ‹ in which case why do you care to

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Magnum doesn¹t have to preclude tight integration for single COEs you speak of. The heavy lifting of tight integration of the COE in to OpenStack (so that it performs optimally with the infra) can be modular (where the work is performed by plug-in models to Magnum, not performed by Magnum itself.

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

chestrations. It looks like most of the current Magnum functionality is provided by Heat. Magnum focus on deployment will potentially lead to another Heat-like API. Unless Magnum is really focused on containers its value will be minimal for OpenStack users who already use Heat/Orchestration. On

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

allows for leverage of work by non-Magnum contributors and re-use of Chef/Ansible/Heat/PickYourFavoriteHere tool for infra configuration and orchestration. -Keith On 4/20/16, 6:03 PM, "Hongbin Lu" <hongbin...@huawei.com> wrote: > > >> -Original Message- >>