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
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
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
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.
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
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
, 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
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
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.
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
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
@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
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
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
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
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
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
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
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
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
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,
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
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
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
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):
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:
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
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.
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
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
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
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
>
>
>__
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
/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
>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
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
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.
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
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-
>>
39 matches
Mail list logo