Hi Jean,
So, let's take the case of DC explicitly since you use it in the example
below. It happens to be today that the targets that are created are
hardcoded in the DC client, not in the user specified manifest. This
doesn't really matter.. my point is that DC knows that it needs to
create multiple targets to do its processing. T1, T2, T3... initial
dataset for build area, pkg image dataset, and bootroot. The point is
that these three values can and should be stored as individual values in
the DOC, and with unique names.
I don't foresee the application having to read data after every
checkpoint.
The problem is that only the application really knows what it wants to
have done. Most of the checkpoint node
data is known immediately. Seems like the concern is really the target
because in some cases we don't know
the target until the user selects it after a discovery. In the cases
we know it in advance this become a non-issue.
In the case where user selection occurs we're pausing anyway. After
this pause for user input, we could update
the checkpoint nodes and then execute.
I get that there are times we don't have checkpoint data up front. That
we require user input to provide this to us. But, the checkpoint gets
registered but isn't instantiated until we are ready to execute it
right? So, not having the data up front in this case, but having it
stored in the DOC as a result of execution is fine. We pause anyway,
waiting for user input, and the engine knows this. TI isn't executed
until the appropriate data is provided.
If we hardcode the checkpoints to always grab data from a predefined
place for something like target my concern
is that we are making assumptions. Take DC as an example, there are 2
targets to be instantiated and transferred
Sure, there are 3 targets created by DC today. However, these are all
based on the initial user input for the build dataset. DC knows this and
can do the right thing. It seems to me that a TI checkpoint must be able
to handle multiple types of targets, and that it instantiates the
sub-class TI that knows how to say create the bootroot area.
I am a little confused about the need to store things such as DIRS to
create as special in the DOC. These are simply data objects, as defined
in the architecture, and must be stored in that way in the DOC. So, what
DC would do is, after the initial storage of the user specified build
location from Manifest Parser, it would then create the other targets,
ZFS dataset, which is a child of the build area dataset, and the boot
root, again a child of the parent, build, dataste, as the appropriate
objects and store them in the DOC in the appropriate place(under the
correct parent) in the DOC.
Target instantiation then reads the target info from the DOC, and this
drives it operations. The parent/child relationship built in the DOC
drives the ordering of the targets created. So, we have multiple types
of targets to be instantiated, but the layout in the DOC drives that.
I don't see a need to store this type of data separately. There are
certainly some things that we must store that are not defined as a
target object, such as the altroot, but those are managed and are
published via a keyword, which Transfer uses later, and which is stored
in the DOC by TI. But in general the model is that we store the data
objects based on the model defined as objects and the checkpoints read
and write this data as required. As do the clients.
Am I missing something here?
sarah
****
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
