On 9/9/2011 9:40 AM, Alan Santos wrote:
On Sep 8, 2011, at 6:21 PM, Charles Crouch wrote:
> Today our drift configurations are all "Resource Drift Configurations
(RDC)". Meaning they are only specific to a single resource. And at the moment we
don't support pinned changesets. By default we apply a "rolling
changeset", meaning we look for drift compared with the most recent snapshot, the
snapshot being the initial changeset plus all changes since that time. If we were to
allow pinning it would mean the user could select a changeset and pin it for the
configuration. And after that point all drift detection for that configuration would be
against that changeset. With that in mind, we could allow a new option on a
configuration: "pin initial changeset", which would mean that the initial
changeset (version 0) is immediately pinned and variations from that changeset would
trigger drift entries. In this way reverting back to a pinned version of a file (or
removal of an unwanted file) would not generate any more drift entries.
> [ccrouch:what's so important about pinning the initial changeset? why
wouldn't you want to pin an arbitrary change set?
> From a workflow perspective, I believe the initial change set is important but
otherwise I have the same question.
> Before we talk about group-level or type-level pinning we may want to make a
fundamental decision. Do pinned changesets always originate from an existing resource,
or can they be defined external to any existing resource?
> [ccrouch:If this is a simplifying assumption then it seems reasonable for now]
An external definition is very interesting and I hadn't considered it. I agree with
Charles again - seems like an internal understanding of a the concept would be a necessary
precursor to import a variety of external definitions. Export of the definition as well.
> Then, at the resource (or eventually, the group) level, when adding a drift
configuration, one could optionally select from the available golden configurations for
the type.
> I think it will better enable us to do drift management on a larger scale.
That sounds right
> If we wanted to align golden configurations like templates, we could add an option
to apply it to every member of a type on import, like today.
>
> In the GUI I think this would require either a top menu Drift item or be worked into
Administration. The former seems the most flexible, but the latter may be less
cumbersome and may play better with the idea of templates.
My vote is under administration.
[jshaughn] I think I agree. Lots of similarities
with templates.
> As for [compatible] resource groups, I think perhaps the idea of golden
configurations may work well. Associating a golden config across the group members
makes, I think, more sense than having a lot of resource specific configurations.
>
> [ccrouch: I think have a single read-only golden configuration across multiple
resources, is a good simplifying assumption]
>
So I understand - a single 'gold' template may be applied to multiple resources
and will have one pinned change (is that the right term for the initial set of files
chosen by the user?) per resource?
[jshaughn] That's right, "golden"
basically means a fixed file-set for
a specific base directory and set of filters (i.e. the drift config).
That file-set would be pinned to the individual group (or type)
resources, in a read-only way, so that it can't be changed at the
resource level (maybe we would allow itto be detachedin the future,
maybe not).
> We will, I think in any pinned changeset impl, need to be able to supply to the
agent the pinned changeset file. This may need to be reverse-engineered from the drift
entries. We can probably make this such that the agent performs all drift detection and
the server is relieved of that need. But we also need to consider the implications of
sending perhaps large changeset files to the agent (along with the new configuration).
I'm not sure I follow here - are you saying that you'd store a single pinned
change set to be overlaid on resources that one applies the golden image to? Because that
sounds like a bundle. Up until now I had assumed that the golden image defined which files
(for now) were to be 'watched', not necessarily the content of the files.
[jshaughn] No, you're initial thinking is correct. There is no pushing
of file bits to the agent, only the pushing of the file info (path/sha
hash) necessary to do the watching.
Alan Santos
JBoss Product Manager
617.818.7735
alan.santos(a)redhat.com
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel