Steps 1 and 2 are really CI's responsibility in a CD cloud. The end of
the testing phase is "new images in glance!" For a stable release cloud,
a tool for pulling new released images from elsewhere into Glance would
be really useful, but worst case an admin downloads the new images and
loads them manually.
I may be misinterpreting, but let me say that I don't think Tuskar
should be building images. There's been a fair amount of discussion
around a Nova native image building service [1][2]. I'm actually not
sure what the status/concensus on that is, but maybe longer term,
Tuskar might call an API to kick off an image build.
Tuskar should just deploy what it has available. I definitely could
see value in having an image updating service separate from Tuskar,
but I think there are many different answers for "how do images arrive
in Glance?".
Ok, so given that frame of reference, I'll reply inline:
On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies <jason.dob...@redhat.com> wrote:
I'm pulling this particular discussion point out of the Wireframes thread so
it doesn't get lost in the replies.
= Background =
It started with my first bulletpoint:
- When a role is edited, if it has existing nodes deployed with the old
version, are the automatically/immediately updated? If not, how do we
reflect that there's a difference between how the role is currently
configured and the nodes that were previously created from it?
I would think Roles need to be versioned, and the deployed version
recorded as Heat metadata/attribute. When you make a change to a Role,
it's a new version. That way you could easily see what's been
deployed, and if there's a newer version of the Role to deploy.
Could Tuskar version the whole deployment, but only when you want to
"make it so" ? If it gets too granular, it becomes pervasive to try and
keep track of or to roll back. I think that would work well with a goal
I've always hoped Tuskar would work toward which would be to mostly just
maintain deployment as a Heat stack that nests the real stack with the
parameters realized. With Glance growing Heat template storage capability,
you could just store these versions in Glance.
Replies:
I know you quoted the below, but I'll reply here since we're in a new thread.
"I would expect any Role change to be applied immediately. If there is some
change where I want to keep older nodes how they are set up and apply new
settings only to new added nodes, I would create new Role then."
-1 to applying immediately.
When you edit a Role, it gets a new version. But nodes that are
deployed with the older version are not automatically updated.
"We will have to store image metadata in tuskar probably, that would map to
glance, once the image is generated. I would say we need to store the list
of the elements and probably the commit hashes (because elements can
change). Also it should be versioned, as the images in glance will be also
versioned.
I'm not sure why this image metadata would be in Tuskar. I definitely
like the idea of knowing the versions/commit hashes of the software
components in your images, but that should probably be in Glance.
Glance is also growing more capabilities to store metadata and be
searchable. Tuskar doesn't need to reinvent this any more than Murano
or Heat do.
We can't probably store it in the Glance, cause we will first store the
metadata, then generate image. Right?
I'm not sure I follow this point. But, mainly, I don't think Tuskar
should be automatically generating images.
Then we could see whether image was created from the metadata and whether
that image was used in the heat-template. With versions we could also see
what has changed.
We'll be able to tell what image was used in the heat template, and
thus the deployment, based on it's UUID.
I love the idea of seeing differences between images, especially
installed software versions, but I'm not sure that belongs in Tuskar.
That sort of utility functionality seems like it could apply to any
image you might want to launch in OpenStack, not just to do a
deployment. So, I think it makes sense to have that as Glance
metadata or in Glance somehow. For instance, if I wanted to launch an
image that had a specific version of apache, it'd be nice to be able
to see that when I'm choosing an image to launch.
But there was also idea that there will be some generic image, containing
all services, we would just configure which services to start. In that case
we would need to version also this.
-1 to this. I think we should stick with specialized images per role.
I replied on the wireframes thread, but I don't see how
enabling/disabling services in a prebuilt image should work. Plus, I
don't really think it fits with the TripleO model of having an image
created based on it's specific "role" (I hate to use that term and
muddy the water....i mean in the generic sense here).
A generic image just requires more state management and configuration.
That seems like a net loss in efficiency, as both of those things move
failure modes into production instead of keeping them firmly rooted in
test/dev.
<snip>
- For the comment on a generic image with service configuration, the first
thing that came to mind was the thread on creating images from packages [1].
It's not the exact same problem, but see Clint Byrum's comments in there
about drift. My gut feeling is that having specific images for each res-cat
will be easier to manage than trying to edit what services are running on a
node.
+1.
Perhaps obviously, +1 as well. :)
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
