Robert, On Jul 18, 2013, at 3:08 AM, Robert Collins <[email protected]> wrote:
> On 18 July 2013 08:53, Gabriel Hurley <[email protected]> wrote: >> I spent a bunch of time working with and understanding Heat in H2, and I >> find myself with one overarching question which I wonder if anyone's thought >> about or even answered already... >> >> At present, the CloudFormation template format is the first-class means of >> doing things in Heat. CloudFormation was created for Amazon, and Amazon has >> this massive convenience of having a (more or less) static list of images >> and flavors that they control. Therefore in CloudFormation everything is >> specified by a unique, specific name. >> >> OpenStack doesn't have this luxury. We have as many image and flavor names >> as we have deployments. Now, there are simple answers... >> >> 1. Name everything the way Amazon does, or >> 2. Alter your templates. >> >> But personally, I don't like either of these options. I think in the long >> term we win at platform/ecosystem by making it possible to take a template >> off the internet and having it work on *any* OpenStack cloud. >> >> To get there, we need a system that chooses images based on metadata >> (platform, architecture, distro) and flavors based on actual minimum >> requirements. > > We do? Why do we? One of our goals with the HOT approach (rather than CloudFormation templates) is to make templates portable between different OpenStack clouds. We'd like to get it to a point where whether you are using a public or private cloud, or different public clouds, that you just use the same template and it just works. This is what we refer to when we talk about making orchestration Declarative. We want it to be declarative for the things that will differ between clouds. It can have aspects that are Imperative for the things that we can expect to remain the same between clouds. This way we get to a point whee we can have a thriving ecosystem of templates that don't need to be fooled with in order to use them. Note that we don't expect to necessarily get there in the first iteration, but I think this vision is important so we know where to head through our refinements. > Note that your characterisation of Amazon is in my experience > inaccurate - a very common pattern there is uploading custom images > (such as those that we build for OpenStack using diskimage-builder). > An OpenStack cloud should let users upload their own images to glance > in the same way, and then you have 3): use golden images, name your > personal images the same in every cloud you burst to; done. This amounts to roughly the same amount of fooling/adjusting as you would need to do if you just changed the image name in the template file. We want to eliminate this entire category of fooling around. If you have orchestration, and a CM system integrated together, the reliance on custom images diminishes considerably. > Also note that the presence of golden images makes a 'just fit the > broad characteristics' a more complex problem than perhaps you think > it is... You need some additional 'is it the right built image' aspect > too. > > So I would tackle this using 4) provide a mapping layer that bridges > template to cloud and lets you translate: > - image names > - flavors > - keypair > - perhaps volumes and other things Mappings is one of the high level concepts in CFN that I think can be completely eliminated with auto-discovery. Respectfully, Adrian Otto _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
