Open Stack

On 12/16/2013 10:29 AM, Fox, Kevin M wrote:
> 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.
If security is a concern of the unified agent, the best way to reduce 
the attack surface is to limit the number of interactions the agent can 
actually do.  Special purpose code for each operation could easily be 
implemented.

I know salt was mentioned as a possibility to solving this problem, but 
brings a whole host of new problems to content with.

Having a unified agent doesn't mean we can't put special-purpose code 
for each service (eg trove) for each operation (eg backup) in said 
unified agent.  We could even do this using cloud-init using the 
part-handler logic.

We really need someone from the community to step up and drive this 
effort, as opposed to beating this thread into too much complexity, as 
mentioned previously by Clint.

Regards
-steve

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev