OK, I'm a little confused about this, but maybe I'm missing some piece of
information, so please excuse me if I've got it wrong here...
As I understand it, Alok, you were thinking of wrapping each finalizer script in
a "checkpoint" - I think that this could work quite simply...
Say that we define a "FinalizerCheckpoint" class, this class would be
instantiated for each possible finalizer script, where the finalizer is
specified in the XML manifest.
So when we parse in the manifest, we instantiate the FinalizerCheckpoint object
with a list of parameters taken from the XML, this could include a list of "data
pieces" that the finalizer would like passed to it from the DOC - of course
there would have to be a documented list of possible values here.
For example, the finalizer could be specified as something, roughly, like the
following:
<finalizer name="first_finalizer" script="script.sh">
<info_required="service_profiles" arg="true"/>
</finalizer>
So this would result in a the value of "service_profiles" being taken from the
DOC by the FinalizerCheckpoint object, and then it calling the script as
something like:
script.sh "profile1" "profile2"
we could make it more "complex", but probably more flexible by passing things as
environment variables too, so for example:
<finalizer name="first_finalizer" script="script.sh">
<info_required="service_profiles" env_var="SERVICE_PROFILES"/>
</finalizer>
SERVICE_PROFILES="profile1 profile2..."
export SERVICE_PROFILES
script.sh
infact if we did this, we could insist on using ksh, and using arrays for the
variables...
There are lots of ways we could do this, it's just a matter of defining the
interface... ;)
Thanks,
Darren.
On 05/12/10 01:08 AM, Sarah Jelinek wrote:
> On 05/11/10 04:54 PM, Alok Aggarwal wrote:
>>
>> On Tue, 11 May 2010, Sarah Jelinek wrote:
>>
>>> On 05/11/10 04:45 PM, Alok Aggarwal wrote:
>>>>
>>>> On Tue, 11 May 2010, Keith Mitchell wrote:
>>>>
>>>>> On 05/11/10 03:53 PM, Alok Aggarwal wrote:
>>>>>> Hi Darren,
>>>>>>
>>>>>> I'm looking into converting DC over to the engine
>>>>>> prototype that you guys worked on. And, I've run
>>>>>> into an interesting problem -
>>>>>>
>>>>>> A number of the DC checkpoints are implemented as
>>>>>> ksh scripts. That brings up the question of a) Can
>>>>>> the engine register shell scripts as checkpoints?
>>>>>> and, b) Is there a way these scripts can talk to
>>>>>> the DOC (which is a python object)?
>>>>>>
>>>>>> (b) is needed because these scripts need certain
>>>>>> values out of the DOC in order to perform their
>>>>>> function.
>>>>>>
>>>>>> I had initially planned on wrapping these shell scripts in python
>>>>>> program that interact with the DOC, extract the needed values out
>>>>>> of it and invoke the shell script with those values as arguments.
>>>>>> However,
>>>>>> that can become quite cumbersome for scripts that
>>>>>> look up more than a handful value and/or deal with
>>>>>> variable number of arguments. So, I'm looking for
>>>>>> an alternate approach.
>>>>>
>>>>> Since the DOC can register multiple things to the same "name" (the
>>>>> items get added as a list), could you simply add the series of
>>>>> arguments as "some_checkpoint_argv" in order by DC, then have the
>>>>> checkpoint pull those out, and execute the shell by passing those
>>>>> arguments? I believe the eventual desire is that the finalizers are
>>>>> all implemented in Python, but for a prototype, this seems like it
>>>>> would be sufficient. Or is there another interaction component for
>>>>> some finalizers that I'm glossing over?
>>>>
>>>> That was my initial thought as well. But it may not
>>>> work as easily for some finalizers without additional
>>>> hackery.
>>>>
>>>> Take for instance, boot_archive_configure. That script
>>>> pulls out a list of service profiles to apply and that
>>>> list can be arbitrary length. Sure, the length could
>>>> be hard coded for the purposes of the prototype but I'm
>>>> just wondering if there's a generic way get the list
>>>> out of the DOC from the finalier.
>>>
>>> How are these service profiles specified today? In the manifest?
>>
>> Yep. As an attribute of boot_archive/smf_service_profile.
>
> Well.. .then this will be stored in the DOC as part of manifest parsing.
> The checkpoint reads this data from the DOC when it needs it. We have to
> define the 'interface' by which we store this data, so that any
> checkpoint that needs it can get it from the data cache.
>
> So, this will work.
>
> sarah
>>
>> Alok
>
> _______________________________________________
> caiman-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
