<div dir="ltr"><div>Thank you for the explanation!</div><div><br></div><div>Currently network_data.json doesn't contain ip addresses:</div><div>$ cat openstack/latest/network_data.json <br>{"services": [], "networks": [{"network_id": "39376584-af8a-4307-8cc3-dbf3474f0d52", "link": "tapde154f64-0c", "type": "ipv4_dhcp", "id": "network0"}], "links": [{"ethernet_mac_address": "fa:16:3e:9b:55:1d", "mtu": 1450, "type": "ovs", "id": "tapde154f64-0c", "vif_id": "de154f64-0cb3-4c71-b449-f3f67646eb2f"}]}<br></div><div>but they are available with ec2 metadata</div><div>$ cat ec2/latest/meta-data.json <br>{"reservation-id": "r-l1rethmm", "security-groups": ["c8xbg-master"], "public-ipv4": "10.0.79.125", "ami-manifest-path": "FIXME", "instance-type": "m1.xlarge", "instance-id": "i-017ae668", "local-ipv4": "10.0.128.15", "local-hostname": "mfedosin-c8xbg-bootstrap", "placement": {"availability-zone": "nova"}, "ami-launch-index": 0, "public-hostname": "mfedosin-c8xbg-bootstrap", "hostname": "mfedosin-c8xbg-bootstrap", "ami-id": "ami-00005ee4", "instance-action": "none", "block-device-mapping": {"ami": "vda", "root": "/dev/vda"}}<br></div><div><br></div><div>So far, in OpenStack metadata we don't have "security-groups", "public-ipv4",  "local-ipv4",  "instance-type", and I hope we can port them easily. I'm not sure about "instance-id" and "reservation-id", and how we can possibly use them in OpenStack, so I think we don't need them at all.</div><div><br></div><div>Well, my plan is to create a spec for Ussuri then :)</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 17, 2019 at 5:04 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/17/2019 9:10 AM, Artom Lifshitz wrote:<br>
>> Currently, we use EC2 metadata in our product to obtain public and private IP addresses, as well as the instance-type (flavor). Therefore, I would like to ask you a couple of questions.<br>
>> 1. Do you plan to ensure compatibility before removing EC2 metadata from the system, i.e. to add these fields to the OpenStack metadata, which is not yet available?<br>
<br>
I would think adding flavor info to meta_data.json should be trivial. <br>
It's an API change so it requires a spec though [1].<br>
<br>
As for the network addresses, those aren't in network_data.json? Are you <br>
using neutron?<br>
<br>
>> 2. When is it expected that EC2 metadata will be removed from the system?<br>
<br>
I wouldn't expect it anytime soon. The documentation that mentions this <br>
is a warning to not use something that is no longer maintained in nova <br>
(anything related to ec2), like a deprecation warning of sorts.<br>
<br>
If you have identified feature compatibility gaps to close in the <br>
openstack metadata API, please open a spec for Ussuri detailing what you <br>
need. Flavor should be pretty easy and the network addresses I would <br>
expect are already available in network_data.json but if something is <br>
missing there let's get it documented in the spec.<br>
<br>
> Nova's in-tree ec2-api has already been removed [2] (though I can't<br>
> find the commit that did it). That being said, the out-of-tree ec2-api<br>
> project [3] is still around and kicking (just barely, looking at the<br>
> commit history, but it's not inactive).<br>
> <br>
<br>
Mikhail isn't talking about the user-facing EC2 API shim, he's talking <br>
about the metadata API code [2].<br>
<br>
[1] <a href="https://specs.openstack.org/openstack/nova-specs/readme.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/readme.html</a><br>
[2] <br>
<a href="https://github.com/openstack/nova/blob/20.0.0/nova/api/metadata/base.py#L236" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/20.0.0/nova/api/metadata/base.py#L236</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div></div>