Hi Tal,
Thanks for the explanation.
So we have 2 options when the reqs-caps are not met within the same
service-template
Option 1:
To look at satisfying nodes present in a substituting service, Have
these nodes part of the newly created service and remove the substituting
service(node
Here’s your digest for today!
#ariatosca
undefined: [UPDATE] a little bit of progress. fixes to the installation of the
live tests (had to fight a bit with rvm, which is kinda like virtualenv for
ruby).
for a sanity check, i tried to run the live tests on the clearwater all-in-one
image suppli
Well, DJ, it's all just opinion at this stage and feedback is welcome!
Option 1:
> To look at satisfying nodes present in a substituting service,
> Have these nodes part of the newly created service and remove the
> substituting service(nodes with different ID's. Also we are very much in
>
To my eyes, the spec doesn't speak of runtime service substituion, but
parsetime template composition. IOW, substitution mapping is a fancy
"include", or the equivalent of an interface definition. Is it understood
by the ARIA team that this includes proxying of running services? IOW, if
my templ
OK, let me try to organize this differently. Three potential conceptions
here:
1) A "fancy include," as you say. All that would happen here is that the
TOSCA parser would automatically find the service template to include from
some kind of repository of recognized service templates, and just inclu
Good stuff. Obviously a "fancy include" was the wrong metaphor. The
lifecycles are linked though. When a create the referencing service (aria
service create), ARIA will match the other service template, and run create
service on it, and then continue on. Uninstall of the referencer will
destroy
In my opinion, the new composite service should indeed be a single service,
so the ARIA CLI will show it as one (if a substituting service already
existed, it would be "dissolved" into the new top-level service). The
composition will show its traces if you look more deeply, because you'll
see that
For the "resource realization" part, I was not even considering
multicloud/vim. I was considering single cloud even outside of
composition. Just reqs and caps. If my node "requires" a compute node
with Suse Linux version X with a minimum of 4GB RAM, how does the
orchestrator match that without
OK, that's a whole different can of worms. :)
TOSCA's Compute capabilities (Container and OperatingSystem) are explicit.
You specify which OS you want, how much RAM you want, how many CPUs, etc.
ARIA's explicit node types (for example, the AWS Compute node) are likewise
explicit. So there is not q
Interesting. Take Openstack (please ). If you model a compute
OS as explicitly as you like, there still has to be a "match" to an
Openstack image ID. Or are you saying you must supply the image ID for
OSs. Likewise, you can't supply RAM and CPUs without a flavor ID.
Openstack does allow for cu
You are correct -- to participate in this "multi-VIM" scenario, the
Openstack plugin would have to know how to translate the TOSCA properties
to a flavor ID. This could all be done in 100% TOSCA via policies (say, an
aria.Openstack).
Doing this automatically might not be a good idea, or even neces
11 matches
Mail list logo
