[Oslc-Automation] Thoughts on teardown scenarios
Charles Rankin
rankinc at us.ibm.com
Tue May 21 13:22:23 EDT 2013
This ended up being longer than I thought. Apologies up front.
Let me start by saying that I think the teardown scenarios have a lot of
value, and are something that we want to make sure that the OSLC
Automation spec supports. My biggest concern over the current proposals
for supporting these scenarios is the use of Automation Plans / Results as
surrogates for the deployed environments. As I view it, an Automation
Plan is nothing more than the definition of some action (or set of
actions, either explicitly or implicitly defined) that a provider can
execute. An Automation Request is the indication that a desired action
should be taken (along with any necessary data needed to successfully take
that action). And, an Automation Result is the "history" of what happened
when that action was taken. This, to me, is very opaque, in a good way.
Many many different things could have occurred as part of the action being
taken -- a build could have been generated, a software stack/topology
could have been instantiated, a car could have been fabricated, a valve
opened, etc. I think we should tread carefully before adding data
specific to one of these contexts to the core of the specification. The
notion of "profiles" came up as well as the idea of people building
"domain" specs on top of Automation. Both of those sound like plausible
and valuable ideas to me.
Turning specifically to the teardown scenarios. When I think about this,
I envision two predominant camps of providers. Those that are effectively
generic with no idea what their actions are doing, and those that are
purpose built which have an explicit understanding of what they are being
asked to do. In the generic case, I don't see any really viable way for
this to be handled without conscious intent by the users of the provider
in creating appropriate automation teardown plans (possibly dynamically)
to complement those that were created to instantiate the environment. So,
in the generic case, the coupling of multiple automation plans into a
cohesive group is user-defined. For the purpose-built case, my
expectation is there is a "resource" that exists that the provider knows
it can take a specific set of actions on (possibly with the ability to
have that set extended by the user). As a simple example, let's think of
a system for managing Virtual Machines. The VM is the resource here, and
the system likely knows how to instantiate one, (re)start/stop it, and
delete it. Technically, there are probably two resources, the VM image
and the live VM instance. You'd take the instantiation action on the
image and the (re)start/stop and delete actions on the instance. That
distinction will actually come in handy in a moment.
Keeping with the VM example. I would expect that the provider would
expose the VM image as a resource of some kind (but not as an Automation
Plan itself). In that resource there would be a link to the instantiate
action (i.e., the Automation Plan that knows how to instantiate an
instance of that image). A consumer could submit an Automation Request
for that Automation Plan. The Automation Result generated from that,
amongst other things, would have a link (probably through a Contribution)
to the resultant VM instance (which is, again, some other type of
resource, but not an Automation Result itself). That instance would have
links to various actions (Automation Plans) that could be taken on it
(e.g., the (re)start/stop and delete mentioned above). Note, the
"provider" I mentioned at the top of this paragraph is really two (or
more) providers. One for the VM resources (and whatever domain/spec they
belong to) and one for the Automation spec.
In the generic provider scenario, I would envision that further actions
that could be taken as a result of the completion of one Automation Plan
would show up as contributions on the first. Those contributions may be
dynamically generated by the first automation plan itself, or generated by
the provider due to (user-defined) metadata associated with the Automation
Plan. It seems like it could be useful for us to define this type of
contribution explicitly (mostly just an action name/type and a link to the
appropriate Automation Plan).
I think the whole discussion around registering "interest" (or
dependencies) is also very useful. However, I don't see that as
Automation specific. I think that is something that better belongs at
Core or a separate spec. Perhaps we do some work to scope and spec out
something initially and bring it forward? This is similar to how we would
handle the idea of Notifications that came up during the v2 spec work
around Automation.
If you made it this far, kudos! I'll be out of the office for a while (a
solid two weeks), but I'll be tracking responses and reply when I get
back.
Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130521/3195897c/attachment.html>
More information about the Oslc-Automation
mailing list