Fox, Kevin M wrote:
I'm thinking more like this use case: I'm a cloud user, I want a new
Trac site. or an Elastic Search cluster. Or a Jenkins system for my
project. Why do I have to take a lot of time to deploy these things
myself? Ideally, one person, or a small group of folks provide
generic templates a common deployment of a given software that can
easily be discovered/launched by end users of any cloud. Docker is
starting to do this with the Docker Hub. Docker's too low level to do
it really nicely though. Say for an ElasticSearch cluster, you want
it scalable, with between M and N instances, with a load balancer and
a private network. Heat can do that... Murano is starting to enable
that ability, but requires the cloud admin to preload up all the bits
into it. That doesn't scale well though.
I guess the how of how that works is up for grabs. Murano might not
be the right place for it.
What other use cases for transferring resources between clouds can
you think of?
I have thought of the following:
* Swift - Users want to transfer objects or containers.
* Glance - Users want to transfer images and their associated metadata.
* Cinder - Users want to transfer block devices, though this could be
plausibly covered by Glance (vols -> images -> vols).
* Heat - Users want to transfer stack templates. I know we don't have
the ability to natively store these artifacts at this time (in the same
way Glance stores images).
* Manilla - Users want to transfer files or folder hierarchies.
Perhaps if the app store like functionality was simply http based,
the existing glance fetch image from http mechanism would already
work.
Seems reasonable, as long as you could give it a feed or endpoint to
poll on a regular interval.
Another option would be for it to work similarly to yum/apt. You have
a set of repo's. You can search though the enabled repo's and install
stuff. Perhaps it has a yum-cron like "update the images that are
'installed' daily" like feature...
I think you're touching on a lot of important (and really good) ideas
here, it seems like there are various plausible ways one could go about
You've also touched on something that I've never really understood,
which is why does Murano exist at all?
This is obviously off-topic in the context of this particular
discussion, but it seems to me like we already have something that can
store objects and metadata (Glance) and something that handles
application deployment and orchestration (Heat). It seems that the
functionality of Murano should've naturally fell into these two projects
with (a) Glance becoming a more general 'artifact' storage and metadata
service and (b) Heat gaining the 'catalog' capability of Murano. In this
way, specific applications would be represented by their own Heat
templates, those templates could then be combined in an ad hoc way to
build environments (which I believe is the terminology used in Murano)
and then the the resulting composition would be orchestrated by Heat.
Perhaps I am missing something fundamental which Murano does...
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
