Open Stack

On 11/04/13 18:49, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2013-04-11 04:38:07 -0700:
>> Essentially Heat is designed as a declarative interface to the OpenStack
>> APIs. Deploying an interdependent collection of resources - and
>> especially making changes to that collection - by hand or with a custom
>> script can be complex and error-prone, and every user has to do it every
>> time they want to make a change. There's a big advantage in having a
>> description of the old state and the state you want to get to and
>> letting an orchestration engine figure how to get there. Even better if
>> you can keep that description in version control and easily do diffs to
>> see what changed and when.
>>
>
> This is a side tangent, but you actually need to also store the parameters
> and diff those too, or you run the risk of making unintended changes. I've
> been working out in my head how to write some CLI helpers for automating
> things so that developers can encode "this is what I expect to change
> when we update the stack" and automation systems can stop the presses
> if there are unintended changes.

Yeah, and there is more we could do to help that. I think the 
CloudFormation design assumes you'll be doing everything through the 
GUI, which is not a good assumption IMO. I've just created a blueprint 
that might improve things somewhat: 
https://blueprints.launchpad.net/heat/+spec/auditing
>
>> What we have _not_ tried to do is anything that is not part of the
>> OpenStack API, except for some temporary resource types for things that
>> should be in OpenStack but weren't at the time - e.g. LBaaS, DBaaS). So
>> the UserData is passed straight through because it's passed straight
>> through in the Nova API as well. It's worth noting that the UserData is
>> extremely constrained in size - in general the point is not to put all
>> of your application in there, it's to put just enough bootstrap to tell
>> the instance to e.g. grab a Chef recipe and go from there, so that you
>> don't have to build it into a custom image.
>>
>
> Right, if you build an image with heat-cfntools installed that runs
> cfn-init and cfn-hup, you don't need UserData at all and can just pass
> in declarative Metadata to get things done.
>
> We're taking that a step further with os-config-applier in the tripleo
> project by just passing in declarative values which the image knows how
> to interpert into config file changes. This way the template only encodes
> orchestration, and not config file or software management of any kind.
>
> https://github.com/openstack-ops/templates/blob/master/mysql.yaml
>
> Note the hint to OpenStack::ImageBuilder::Elements, which is just a hint
> that this template wants an image built with the mysql-migration element.
> This is an alternative way to use Heat without cfn-init, and without
> having to specify file paths or service names or anything in the template,
> those things all remain in the image as part of the software.

<snip>

>> I agree that long-term we need to have a better story on configuring
>> what runs inside Nova instances. But I'm also wary of scope creep.
>> During the incubation discussions around Heat, there were a lot of folks
>> expressing concern about blessing one particular orchestration engine as
>> an official OpenStack project and, while I disagree with that view when
>> it comes to orchestrating OpenStack APIs, I think it's a very good point
>> when it comes to dealing with non-OpenStack tools.
>>
>
> As I stated above, this line needs to be clear. Things inside the
> instances are not at all "Heat". We should provide minimalistic tools,
> but if those tools get too deep, we will actually make it harder to
> adopt Heat.
>
>> There are multiple, Open Source PaaS solutions that can run on top of
>> OpenStack (e.g. OpenShift Origin, CloudFoundry). I think where OpenStack
>> in general, and Heat in particular, can add the most value is to be the
>> best IaaS base on which to layer the PaaS. (BTW the hosted version of
>> OpenShift currently uses CloudFormation templates.)
>>
>
> I think there is far too much attention given to "is this PaaS or IaaS".

That's fair, and if I'm understanding the case for e.g. CAMP correctly, 
the argument is that folks who only have one application still need the 
kind of features that a PaaS gives you when it's hosting multiple 
applications?

I guess my point was that I don't think it's up to OpenStack to endorse 
One Way of doing this. It seems like there's plenty of room in this 
space for innovation, and OpenStack should be trying to enable that 
rather than shut it out.
>
> Applications need a platform that gives them access to the infrastructure.
> We can see that in the industry where pure PaaS solutions are not nearly
> as popular as those that give you the ability to get out to the OS when
> you need to.
>
> Heat should orchestrate OpenStack APIs in its core. If TOSCA apps can't
> get their jobs done with just the OpenStack APIs, then the pieces they
> need should be on the same level as the heat-cfntools.
>
>> That's obviously not the only use case though. I would be in favour of
>> supporting some ways to generate the UserData for an instance in some
>> simpler manner than a shell script. One idea that has been kicked around
>> is Juju integration, and I think that would be a really interesting one
>
> Zane you kind of just blew my mind a little. Being intimiately familiar
> with how Juju works, I'm not sure this makes any sense at all.

I'm not familiar with it at all, so you are probably correct. I was 
under the impression that you could choose to either use it standalone 
or have it fire up Nova instances. It was actually considered as a 
starting point for Heat, but CloudFormation was chosen instead because 
Juju doesn't support orchestration of any other resource types.

So the idea here would presumably be that a Juju application appears as 
a resource, perhaps, and slots into the template at a higher level of 
abstraction than just a Nova instance, but can still integrate with the 
other aspects of the template.
>
> Any attempt to make juju charms work on heat is basically reimplementing
> the entire juju charm CLI API (relation-{get,set,list}, unit-get,
> config-get) to work using Heat's API tools. Juju doesn't just install
> things. It sets up juju's own agents to do what Heat already does (spin
> up instances, communicate changes between them).

I'm really not in a position to comment on how hard this would be, but 
I'm interested in knowing if it would be valuable.
>
>> to look at. Another would be some sort of (pluggable) layer to add
>> native ways of configuring the likes of Puppet and Chef. (Those two
>> ideas are not mutually exclusive, either.)
>>
>
> Puppet and Chef can do this without changing anything in Heat. Just teach
> them how to read the Metadata. IIRC, chef already has an ohai plugin to
> do just that. Then just have something like:
>
>      Metadata:
>        Puppet:
>          master-host: xxxxxx
>          roles: [x, y, z]

Good point, I always forget about the metadata.

cheers,
Zane.