On 2014/15/01 22:33, Jay Dobies wrote:
On 01/15/2014 08:07 AM, James Slagle wrote:
[snip]
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.
I didn't mean to imply that Tuskar would be building images, just
kicking them off.
Definitely not at the moment.
As for whether or not it should, that's an interesting question. You and
I are both on the same page on not having a generic image and having the
services be configured outside of that, so I'll ignore that idea for now.
I've always thought of Tuskar as providing the user with everything
they'd need. My gut reaction is that I don't like the idea of saying
they have to go through a separate step of creating the image and then
configuring the resource category in Tuskar and attaching the image to it.
That said, I suspect my gut is wrong, or at very least not in line with
the OpenStack way of thinking.
Well, I think you are right. We should be able to provide as much as
possible. I don't think that Tuskar has to do everything. Image builder
would be amazing feature. And I don't think it has to be Tuskar-UI
business. There can be UI separate from Tuskar, which is part of Horizon
umbrella, dealing only with building images. I think it has enough
reasons to become a separate project in the future.
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.
+1, the more I've been thinking about this, the more I like it. We can't
assume changes will be immediately applied to all provisioned instances,
so we need some sort of record of what an instance was actually built
against.
Does it need to be new version of the whole Resource Category? The image
information might be part of the node. And we can only display in the UI
that certain amount of nodes are running based on different image than
is actually available.
= Regarding immediate changes =
For me, Resource Category is indicating some role of the node. It is
given by certain behavior and I expect all the nodes behave the same way.
If I change some settings of the role which change the behavior (set of
services, config), I would expect all nodes behave the same way - new
nodes as well as old ones - so it indicates the immediate change for me.
Otherwise, if I expect old nodes to behave one way and new nodes to
behave differently, I need to create another role.
On the other hand, if I only update image OS, packages, or whatever, but
the behavior of the node remains the same (same set of services, same
configuration), I do expect to have those nodes with old image working
along with nodes containing new image and apply the upgrade when I want to.
[snip]
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).
It was not agreed which way to go. I agree that first step should be to
have specific images and don't deal with enabling/disabling services.
It's outside the Icehouse timeframe, but for future direction, I am
removing the enable/disable functionality from wireframes.
[snip]
If the image is immediately created, what happens if the user tries to
change the resource category counts while it's still being generated?
That
question applies both if we automatically update existing nodes as
well as
if we don't and the user is just quick moving around the UI.
This should never happen. Once heat stack is updating, you shouldn't be
able to apply for other change.
What do we do with old images from previous configurations of the
resource
category? If we don't clean them up, they can grow out of hand. If we
automatically delete them when the new one is generated, what happens if
there is an existing deployment in process and the image is deleted
while it
runs?
Both these points are not as relevant given my earlier statement.
But, if I turn out to be wrong about that :), then I'd say that we
don't want to clean up old images automatically. I don't like
surprises, even if I can configure how many old images to keep. I
think that deleting should require manual intervention.
It should be easy enough for us to resolve which resource categories
(and their versions) have instances deployed against them and providing
a UI for the user to clean up.
So, there is planned whole section called 'Image Management', where user
will be able to manage images which are stored in Glance.
I think it is safe to say that we can immediately remove the association
of image <> resource category (you just need to keep the image
information on node level, what image was deployed). The image
information at resource category level is relevant only for newly
deployed nodes (to say what image is going to be provisioned), right?
Is resource category the same as role? Sorry :), I probably need to
go back and re-read the terminology thread. If so, I think versioning
them in the Tuskar db makes sense. That way you know what's been
deployed and what hasn't, as well as any differences.
Yes, it is the same thing (Role == Resource Category). Huge confusion
about terminology lately :)
Thanks guys
-- Jarda
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
