Open Stack

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 [robertc at 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 <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.

trove-agent:
 - 'backup':
      db-id: '52'
 - 'backup':
      db-id: '43'
 - 'create':
      db-id: '93'
      initial-schema: [.....]

etc.

?


--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev