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