<div dir="ltr"><div class="gmail_extra"><div>Murray, Paul (HP Cloud Services)  wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">






<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span><br></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Multicast is not generally used over the internet, so the comment about removing multicast is not really justified, and any of the approaches that work there
 could be used. </span></p></div></div></blockquote><div><br></div><div>I think multicast/broadcast is commonly used 'behind the firewall', but I'm happy to hear of any other alternatives that you would recommend - particularly if they can work on the cloud!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I agree that the metadata service is a sensible alternative. Do you imagine your instances all having access to the same metadata service? Is there something
 more generic and not tied to the architecture of a single openstack deployment?</span></p></div></div></blockquote><div><br></div><div><br class="">Not sure I understand - doesn't every Nova instance has access to the metadata service, and they all connect to the same back-end database?  Has anyone not deployed the metadata service?  It is not cross-region / cross-provider - is that what you mean?  In terms of implementation (<a href="https://review.openstack.org/#/c/68825/">https://review.openstack.org/#/c/68825/</a>) it is supposed to be the same as if you had done a list-instances call on the API provider.  I know there's been talk of federation here; when this happens it would be awesome to have a cross-provider view (optionally, probably).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Although this is a simple example, it is also the first of quite a lot of useful primitives that are commonly provided by configuration services. As it is possible to do what you want by other means (including using an implementation that has multicast within subnets – I’m sure neutron does actually have this), it seems that this makes less of a special case and rather a requirement for a more general notification service?</span></p>
</div></blockquote><div><br></div><div>I don't see any other solution offering as easy a solution for users (either the developer of the application or the person that launches the instances).  If every instance had an automatic keystone token/trust with read-only access to its own project, that would be great.  If Heat intercepted every Nova call and added metadata, that would be great.  If Marconi offered every instance a 'broadcast' queue where it could reach all its peers, and we had a Keystone trust for that, that would be great.  But, those are all 12 month projects, and even if you built them and they were awesome they still wouldn't get deployed on all the major clouds, so I _still_ couldn't rely on them as an application developer.</div>
<div><br></div><div>My hope is to find something that every cloud can be comfortable deploying, that solves discovery just as broadcast/multicast solves it on typical LANs.  It may be that anything other than IP addresses will make e.g. HP public cloud uncomfortable; if so then I'll tweak it to just be IPs.  Finding an acceptable solution for everyone is the most important thing to me.  I am very open to any alternatives that will actually get deployed!</div>
<div><br></div><div>One idea I had: I could return a flat list of IPs, as JSON objects:</div><div><br></div><div>[</div><div><div>{ ip: '1.2.3.4' },</div></div><div><div>{ ip: '1.2.3.5' },</div></div><div>
<div>{ ip: '1.2.3.6' }</div></div><div>]</div><div><br></div><div>If e.g. it turns out that security groups are really important, then we can just pop the extra attribute into the same data format without breaking the API:</div>
<div><br></div><div>...</div><div>{ ip: '1.2.3.4', security_groups: [ 'sg1', 'sg2' ] }</div><div>...</div><div><br></div><div>Justin</div></div></div></div>