Hi Brian, Michal, Jakub,
On Mon, 2019-07-01 at 08:57 -0700, Gix, Brian wrote:
> Hi Michal.
>
> > > We can perhaps "Overload" this functionality by allowing a
> > > minimal
> > > JSON with only Prov Data parts, if we are looking for a
> > > Provisioning
> > > shortcut, and always requiring the ObjectManager calls fetch the
> > > Composition (if the JSON was minimal) and to Sanity check the
> > > Composition (if the JSON contains a fully developed/configured
> > > Migrated node).
> >
> > Ok, that sounds better. We could start by implementing the
> > "Provisoining
> > shortcut" variant, and add full-blown migration when it's needed.
> >
> > Would that be OK from your POV?
>
> This would be OK for me. How about Inga?
>
> BR,
> Brian
So what is the final versionof the ImportLocalNode() will look like?
uint64 token ImportLocalNode(object app_path, array{byte} uuid, string
config_data)
or
uint64 token ImportLocalNode(object app_path, array{byte} uuid, byte
config_data_type, string config_data)
where config_data_type indicates the format of config_data (json, xml,
etc)
A bit clunky, but, if we want to keep everything wrapped in one method
call, I don't see a way around this.
Also, my feeling is that app_path = NULL shuold be allowed. In this
case node/app configuration is incurred solely from config_data, daemon
will check for the presence of all the mandatory settings.
In case both app_path and fully fleshed config_data are provided, a
series of checks will need to be performed to validate the coherncy of
the configuration.
Best regards,
Inga
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
