savanna-all team mailing list archive

[Philip Langdale <philipl@xxxxxxxxxxxx>]

Dmitry,

Sorry - so the intention of convert() is to turn the plugin specific
configuration into Savanna configurations - and not to actually set up a
cluster? So if a user wants to configure capabilities that cannot be
expressed by Savanna they would have to bootstrap the cluster somehow and
then talk directly to CM or Ambari, or something along those lines?

Perhaps not surprisingly, I have no problem with the applicable_target
approach to describing config fields, with the caveat that I'd like the see
the field expanded in the longer term as discussed in the previous thread.

Thanks,

--phil


On 5 June 2013 06:11, Dmitry Mescheryakov <dmescheryakov@xxxxxxxxxxxx>wrote:

> Philip,
>
> AFAIU, John is speaking of 'cluster/cluster_configs' and
> 'cluster/node_groups/node_configs' fields. They contain only configs
> defined by plugin's get_configs(...) call. So actually plugin could set any
> of them.
>
> John,
>
> Agree, plugin needs ability to set these fields during convert(...) call.
> Another thing we want to discuss is the structure of these fields. After an
> internal discussion we see it as follows:
> {config_applicable_target: {config_name: value}}
> For example:
> {"service:mapreduce": {"task_tracker_heap_size": "512",
> "mapred.task.timeout": "10000"}, "service:hdfs": .....}
>
> Here applicable_target and config_name serve as config 'coordinates'. In
> that way configs structure becomes lightweight and easy-readable. Obviously
> it will be easy for plugin to populate such fields.
>
> Note that there is no reference to the original 'config' object here.
> Right now we use a single object to both persist and provide config value
> via SPI. If we add a reference to 'config' object, we'll need to
> introduce unnecessary crunches to avoid persisting these references. On the
> other side, having applicable_target/config_name plugin can uniquely
> identify the config and hence easily find related config object and
> required information.
>
> Thanks,
>
> Dmitry
>
>
>
> 2013/6/4 Philip Langdale <philipl@xxxxxxxxxxxx>
>
>> My understanding was that this would be questionable exercise. It's
>> certain that the native configuration will be a strict superset of what
>> Savanna is capable of expressing, so it's not going to be possible to
>> provide a complete Savanna representation of it. Essentially, you're opting
>> out of Savanna handling the configuration by going this route, with the
>> advantage that you get the full capability of the underlying platform.
>> You'd presumably use native tools to inspect and do ongoing configuration
>> in this model.
>>
>> --phil
>>
>>
>> On 3 June 2013 13:54, John Speidel <jspeidel@xxxxxxxxxxxxxxx> wrote:
>>
>>> I am looking at the doc:
>>> https://wiki.openstack.org/**wiki/Savanna/**PluggableProvisioning/**
>>> ClusterLifecycle<https://wiki.openstack.org/wiki/Savanna/PluggableProvisioning/ClusterLifecycle>
>>>
>>> I am confused as to why the hadoop plugin will not set
>>> cluster/cluster_configs during the convert call.  Considering that the
>>> purpose of this call is to normalize a hadoop plugin configuration to a
>>> cluster template, I would expect to set the configuration information on
>>> the passed in cluster instance. According to the above doc, cluster_configs
>>> is never modifiable by the plugin.  Is this a mistake in the doc or do I
>>> completely misunderstand the purpose of the convert function?
>>>
>>> Thanks,
>>> John
>>>
>>> --
>>> Mailing list: https://launchpad.net/~**savanna-all<https://launchpad.net/~savanna-all>
>>> Post to     : savanna-all@lists.launchpad.**net<savanna-all@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~**savanna-all<https://launchpad.net/~savanna-all>
>>> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>
>>
>>
>> --
>> Mailing list: https://launchpad.net/~savanna-all
>> Post to     : savanna-all@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~savanna-all
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>