On 11/25/13 5:46 PM, "Clint Byrum" 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 community
: 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" <mailto:cl...@fewbar.com>
wrote:
Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
Hi Steve,
Jay, I don't see reduction. I count -Glance and +Murano in your email, which
is net zero addition of projects I think. Did I miss something? Template
catalog functionality could go into Heat in the short term with no new project
additions. It could be built in a way that it would be easy to br
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 observa
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
Hey, yeah, so I started the Convection wiki and discussed that idea at the
Portland summit in 2013. Mirantis picked up the Convection proposal and
decided to run with it in a project named Mistral from what I understand...
Their was apparently some concerns over name infringement, which is why
On 6/11/14 2:43 AM, "Steven Hardy" 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 user-data i
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
ec
On 3/25/14 11:55 AM, "Ruslan Kamaldinov" 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 this is the same perso
https://wiki.openstack.org/wiki/Heat/StackMetadata
https://wiki.openstack.org/wiki/Heat/UI
-Keith
From: Lingxian Kong mailto:anlin.k...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 2, 2014
s.openstack.org>>
Date: Thursday, April 3, 2014 10:30 AM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto: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.
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 t
t to run the system
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" wrote:
>On Thu, Sep 12, 2013 at 01:07:03AM +, Keith Bray wrote:
>>
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 capa
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 sett
In-line comments.
On 10/28/13 5:43 PM, "Steve Baker" 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
alive
I tend toward this shelving feature having general use and applicability
to the Nova service. If this shelving feature existed in Nova, users of
Heat could certainly make use of it through operations on their Stack, but
if something has applicability to a specific service, that feature should
exis
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 alternative (I supported the
>
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
hav
ement.
>
>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)
>> Subject: Re: [openstack-dev] [magnum][
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.
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 Wed, Apr 20, 2016 at 3:12 PM, Keith Bray
mailto:keith.b...@rackspace.com>> w
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" wrote:
>
>
>> -Original Message-----
>> From: Keith Bray [mai
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
gt;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
>
>
>
&
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 for usage question
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" wrote:
>[Cross-posting to both d
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 whic
In-line responses. Thanks for chipping in Monty.
-Keith
On 5/27/15 6:03 PM, "Monty Taylor" 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 t
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. Solu
orks kind of like that...
>
>Thanks,
>Kevin
>____
>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 Cat
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): [YES/no
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
ably also want to have the ability to suppress those
>prompts for folks that want to shell script.
>
>On Jun 16, 2015, at 4:42 PM, Keith Bray
> wrote:
>
>> Isn't that what the SDK is for? To chip in with a Product Management
>>type hat on, I'd think the CLI shou
pp?
-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.com<mailto:keith.b...@rackspace.com>]
Sent: Tuesday, June 16, 2015 2:42 PM
To: OpenStack
sily solved
problem. Best way I can think of is fix it in the new unified openstack client,
and give the interactive binary a new name to run interactive mode. Shell
scripts can continue to use the existing stuff without fear of breakage.
Thanks,
Kevin
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 co
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,
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 G
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 related/similar
43 matches
Mail list logo
