<div class="im">This is continuity on a thread I was having with Scott Moser about his blueprint on config drive improvements:<br><br><a href="https://blueprints.launchpad.net/nova/+spec/config-drive-v2">https://blueprints.launchpad.net/nova/+spec/config-drive-v2</a><br>
<br>I had suggested adding the current keystone API url path ( from flags ) to metadata api response.<br><br>The fundamental logic on my part is that it provides instances a known static path for finding out the dynamic value of the keystone API.  With that it can perform any function in openstack it may need to ( so long as it has valid auth credentials to do so ).<br>
<br>The concern however raised is that this may not be considered metadata and is more of a user data thing.  And thus it would have no place being in metadata.  Certainly I understand that argument.<br><br>I however can think of no other way to make this available to instances in an automated fashion that does not involve external configuration management.  And while I generally have no problem with the "so what?" answer to that.  In this case, the problem relates specifically to functionality of openstack core applications.  So it's sitting on the dividing line.<br>
<br>I feel like this is useful functionality for openstack and its users.  I think that metadata is the right place for it.  But maybe I am in a minority in wanting to see this happen.  Or maybe I am simply wrong about where it should / could be placed.<br>
<br>Example usage:<br><br>In my case, the specific use case I wish to achieve is having fully portable images that can authenticate against keystone ( via pam auth module ) and provide environment data from the nova APIs.  With this functionality I could simply query the metadata API... lookup the keystone API.  Authenticate with credentials and discover tenancy / owner of instance to deny or allow access.  <br>
<br>Pretty simple.  <br><br>Would love input from others...<br><br>Here is a dissenting opinion from Scott :<br><br>-------- Begin Paste --------<br><br>> >   Regarding 'tenant' or 'keystone_api' being present in the metadata<br>

> > service I have the following thoughts:<br>
> >  * in general we should not put data there that provides no added<br>
> >    benefit. For example, is there a benefit to having keystone server<br>
> >    information available in the metadata service versus being passed in<br>
> >    in user-data, and a initialization script in the instance reading the<br>
> >    information from user-data rather than meta-data.<br>
> ><br>
> ><br>
> I disagree here.  Having just the address of the current cluster's keystone<br>
> API server available at meta-data means that any application can figure out<br>
> it's environment data on the fly to a fairly high degree.  Coupled with a<br>
> pam auth it can fully populate env data for the cluster in which it is in<br>
> with nothing other than the username and password or hash pass.<br>
><br>
> I think it's highly beneficial for making instances that can be directly<br>
> ported between clusters and require no modification or injection.  More to<br>
<br>
</div>I have a bad connotation for the term 'injection'.  user-data is not injection.<br>
user-data is information about an instance's purpose provided to the<br>
instance at launch time by the entity that requested its creation.<br>
<br>
This data may include information such as:<br>
 * location of package mirror<br>
 * location of puppet / chef master server<br>
 * location of juju's zookeeper node<br>
 * users to add, or public keys to import<br>
 * code to run on first boot<br>
<br>
There are numerous existing complex and successful examples of using<br>
user-data with such information.  The first items above can be simplified<br>
to "location of an external service to integrate with".<br>
<br>
Compare the above with the list of things that are inside the existing EC2<br>
metadata (see <a href="http://paste.ubuntu.com/1027440/" target="_blank">http://paste.ubuntu.com/1027440/</a> for a full crawl):<br>
 * ami-id<br>
 * ami-launch-index<br>
 * block-device-mapping<br>
 * network information<br>
 * public-keys<br>
 * reservation id<br>
 * public-ipv4<br>
 * instance-id<br>
 * public-keys<br>
<br>
The information there is almost entirely composed of information that the<br>
entity launching the instance could not know at request time (when<br>
user-data is provided).  It is information that is filled in by the cloud.<br>
There are exactly zero external services mentioned.<br>
<br>
I'm not sure why "keystone api server" is special when compared to puppet<br>
master or juju zookeeper node.  The only difference I see is that<br>
openstack knows what the keystone server is for a given tenant and thus<br>
could provide it, while it has no knowledge at all of juju-server or<br>
puppet server.<br>
<br>
Between the two locations of 'user-data' and 'meta-data' it seems fairly<br>
obvious to me that 'keystone api server' fits more in line with user-data<br>
than meta-data.<br>
<div class="im"><br>
> the point it can make interfacing with the APIs from within user space<br>
> substantially easier.  Usability wise I think it has definite benefits.<br>
<br>
</div>I'm honestly not sure what those benefits are.  It would be trivial to<br>
write a openstack-instance-launch tool that does:<br>
 * get keystone-api server and tenant information of user doing the launch<br>
 * create user-data with:<br>
   keystone-api-server: ....<br>
   tenant-id: abcdefg<br>
 * launch instance<br>
<br>
This is < 100 lines of code that would then provide the information to the<br>
instance using existing infrastructure, and would also work on EC2,<br>
existing HP cloud, rackspace ....<br>
<div class="im"><br>
> >    Basically, user-data is free and uncontrolled.  But if something goes<br>
> >    into the metadata service, then Nova is involved and will potentially<br>
> >    have to maintain this code path indefinitely.  If there is no benefit<br>
> >    to nova involvement, then it should not really be involved.<br>
> ><br>
><br>
> I feel like this piece is worth the effort and I am willing to write and<br>
> maintain it.<br>
><br>
><br>
> >    Separation from Nova is also a good thing from the clients perspective<br>
> >    because it means it does not depend on openstack.  If the keystone_api<br>
> >    and tenant are instead passed in via user-data, the implementation is<br>
> >    more easily moved to another cloud provider.  You could even launch an<br>
> >    ec2 instance and point it at a keystone server running on a openstack<br>
> >    node.<br>
> ><br>
><br>
> I think that's a case by case thing.  In this case we're providing a<br>
> feature that I think people will use.  However, it's not ALWAYS the best<br>
> choice.  That's fine.  Different strokes for different folks.<br>
<br>
</div>The key is that you need to have a good reason why a bit of information is<br>
necessary to be exposed in the metadata service.  What does it enable that<br>
cannot be done equally well without it?<br>
<br>
The metadata service is basically an API from openstack to the instance.<br>
We need to treat it as such and scrutinize changes to it.<br>
<br>
This conversation is probably best suited for the openstack mailing list.<br>
<br>
Maybe we should re-play it there?<br><br><br><br>