drift: Golden Images

Jay Shaughnessy jshaughn at redhat.com
Fri Sep 9 15:02:45 UTC 2011



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 at redhat.com
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>



More information about the rhq-devel mailing list