<div dir="ltr">That's exactly why I proposed Marconi :<div> - Notifications ('Marconi') is already an incubated Openstack program and consequently we need to envisage any already existing solutions in the Openstack ecosystem before writing a new one (aka. "silos"...)</div>
<div> - Salt and other any other solutions are good but not perfect as we would then have only one broker for a solution, with all the disagreements it could raise (releases roll-out and backwards compatibility, vendor lock-in, light integration with Openstack...)</div>
<div><br></div><div>Is there an Etherpad for discussing this btw ? Meetings are great but pretty useless if we need to discuss such of design keypoints right there.</div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/12/13 Fox, Kevin M <span dir="ltr"><<a href="mailto:kevin.fox@pnnl.gov" target="_blank">kevin.fox@pnnl.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's a great idea. How about the proposal below be changed such that the metadata-proxy forwards the /connect like calls to marconi queue A, and the response like ur's go to queue B.<br>
<br>
The agent wouldn't need to know which queue's in marconi its talking to then, and could always talk to it.<br>
<br>
Any of the servers (savana/trove) that wanted to control the agents would then just have to push marconi into queue A and get responses from queue B.<br>
<br>
http is then used all the way through the process, which should make things easy to implement and scale.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________________<br>
From: Sylvain Bauza [<a href="mailto:sylvain.bauza@gmail.com">sylvain.bauza@gmail.com</a>]<br>
Sent: Thursday, December 12, 2013 11:43 PM<br>
To: OpenStack Development Mailing List, (not for usage questions)<br>
<div class="im">Subject: Re: [openstack-dev] Unified Guest Agent proposal<br>
<br>
</div><div class="im">Why the notifications couldn't be handled by Marconi ?<br>
<br>
That would be up to Marconi's team to handle security issues while it is part of their mission statement to deliver a messaging service in between VMs.<br>
<br>
</div>Le 12 déc. 2013 22:09, "Fox, Kevin M" <<a href="mailto:kevin.fox@pnnl.gov">kevin.fox@pnnl.gov</a><mailto:<a href="mailto:kevin.fox@pnnl.gov">kevin.fox@pnnl.gov</a>>> a écrit :<br>
<div class="im">Yeah, I think the extra nic is unnecessary too. There already is a working route to 169.254.169.254, and a metadata proxy -> server running on it.<br>
<br>
So... lets brainstorm for a minute and see if there are enough pieces already to do most of the work.<br>
<br>
We already have:<br>
* An http channel out from private vm's, past network namespaces all the way to the node running the neutron-metadata-agent.<br>
<br>
We need:<br>
* Some way to send a command, plus arguments to the vm to execute some action and get a response back.<br>
<br>
OpenStack has focused on REST api's for most things and I think that is a great tradition to continue. This allows the custom agent plugins to be written in any language that can speak http (All of them?) on any platform.<br>
<br>
A REST api running in the vm wouldn't be accessible from the outside though on a private network.<br>
<br>
Random thought, can some glue "unified guest agent" be written to bridge the gap?<br>
<br>
How about something like the following:<br>
<br>
</div>The "unified guest agent" starts up, makes an http request to <a href="http://169.254.169.254/unified-agent/" target="_blank">169.254.169.254/unified-agent/</a><<a href="http://169.254.169.254/unified-agent/" target="_blank">http://169.254.169.254/unified-agent/</a>><cnc_type_from_configfile>/connect<br>
<div class="im">If at any time the connection returns, it will auto reconnect.<br>
It will block as long as possible and the data returned will be an http request. The request will have a special header with a request id.<br>
</div>The http request will be forwarded to localhost:<someportfromconfigfile> and the response will be posted to <a href="http://169.254.169.254/unified-agent/cnc_type/response/" target="_blank">169.254.169.254/unified-agent/cnc_type/response/</a><<a href="http://169.254.169.254/unified-agent/cnc_type/response/" target="_blank">http://169.254.169.254/unified-agent/cnc_type/response/</a>><response_id><br>
<div class="im"><br>
The neutron-proxy-server would need to be modified slightly so that, if it sees a /unified-agent/<cnc_type>/* request it:<br>
looks in its config file, unified-agent section, and finds the ip/port to contact for a given <cnc_type>', and forwards the request to that server, instead of the regular metadata one.<br>
<br>
Once this is in place, savana or trove can have their webapi registered with the proxy as the server for the "savana" or "trove" cnc_type. They will be contacted by the clients as they come up, and will be able to make web requests to them, an get responses back.<br>
<br>
What do you think?<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________________<br>
</div>From: Ian Wells [<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a><mailto:<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>>]<br>
<div class="im">Sent: Thursday, December 12, 2013 11:02 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] Unified Guest Agent proposal<br>
<br>
</div><div class="im">On 12 December 2013 19:48, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>>>> wrote:<br>
Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800:<br>
> On 12/10/2013 03:49 PM, Ian Wells wrote:<br>
> > On 10 December 2013 20:55, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>>><br>
</div><div class="im">> > <mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>>>>> wrote:<br>
> I've read through this email thread with quite a bit of curiosity, and I<br>
> have to say what Ian says above makes a lot of sense to me. If Neutron<br>
> can handle the creation of a "management vNIC" that has some associated<br>
> iptables rules governing it that provides a level of security for guest<br>
> <-> host and guest <-> $OpenStackService, then the transport problem<br>
> domain is essentially solved, and Neutron can be happily ignorant (as it<br>
> should be) of any guest agent communication with anything else.<br>
><br>
<br>
Indeed I think it could work, however I think the NIC is unnecessary.<br>
<br>
Seems likely even with a second NIC that said address will be something<br>
like 169.254.169.254 (or the ipv6 equivalent?).<br>
<br>
There *is* no ipv6 equivalent, which is one standing problem. Another is that (and admittedly you can quibble about this problem's significance) you need a router on a network to be able to get to 169.254.169.254 - I raise that because the obvious use case for multiple networks is to have a net which is *not* attached to the outside world so that you can layer e.g. a private DB service behind your app servers.<br>
<br>
Neither of these are criticisms of your suggestion as much as they are standing issues with the current architecture.<br>
--<br>
Ian.<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
</div><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>