Yeah, this is similar to what I am proposing. I think we just about have just
about everything we need already.
Thread started out discussing a slightly different use case then below. The use
case is processing events like:
User performs "backup database B" in Trove UI, Trove sends event
"backup-database" with params B to the vm, vm response sometime later with
"done" "backup database B", Trove UI updates.
The idea is we need a unified agent to receive the messages, perform the action
and respond back to the event,.
The main issues are, as I see it:
* The VM might be on a private neutron network only. This is desirable for
increased security.
* We want the agent to be minimal so as not to have to maintain much in the
VM's. Its hard to keep all those ducks in a row.
* There is a desire not to have the agent allow arbitrary commands to execute
in the VM for security reasons.
Thanks,
Kevin
________________________________________
From: Robert Collins [robe...@robertcollins.net]
Sent: Sunday, December 15, 2013 6:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Unified Guest Agent proposal
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
