On 15 December 2013 21:17, Clint Byrum <cl...@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.
trove-agent:
- 'backup':
db-id: '52'
- 'backup':
db-id: '43'
- 'create':
db-id: '93'
initial-schema: [.....]
etc.
?
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
