[openstack-dev] Unified Guest Agent proposal
robertc at robertcollins.net
Mon Dec 16 02:44:11 UTC 2013
On 15 December 2013 21:17, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Steven Dake's message of 2013-12-14 09:00:53 -0800:
>> On 12/13/2013 01:13 PM, Clint Byrum wrote:
>> > Excerpts from Dmitry Mescheryakov's message of 2013-12-13 12:01:01 -0800:
>> >> Still, what about one more server process users will have to run? I see
>> >> unified agent as library which can be easily adopted by both exiting and
>> >> new OpenStack projects. The need to configure and maintain Salt server
>> >> process is big burden for end users. That idea will definitely scare off
>> >> adoption of the agent. And at the same time what are the gains of having
>> >> that server process? I don't really see to many of them.
>> I tend to agree, I don't see a big advantage to using something like
>> salt, when the current extremely simplistic cfn-init + friends do the job.
>> What specific problem does salt solve? I guess I missed that context in
>> this long thread.
> Yes you missed the crux of the thread. There is a need to have agents that
> are _not_ general purpose like cfn-init and friends. They specifically
> need to be narrow in focus and not give the higher level service operator
> backdoor access to everything via SSH-like control.
So, just spitballing, but:
We have a metadata service.
We want low-latency updates there (e.g. occ listening on long-poll).
Ignore implementation for now.
I assert that agent restrictness is really up to the agent. For
instance, an agent that accepts one command 'do something' with args
'something', is clearly not restricted.
So - mainly to tease requirements out:
How would salt be different to:
- heat-metadata with push notification of updates
- an ORC script that looks for a list of requests in post-configure.d
and executes them.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev