[nova][metadata] EC2 compatible metadata deprecation
Hello! In the documentation I noticed that EC2 metadata may soon be removed from Nova [1]. 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. 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? 2. When is it expected that EC2 metadata will be removed from the system? Best regards, Mikhail Fedosin [1] https://docs.openstack.org/nova/latest/user/metadata.html#general-guidelines
On Tue, Dec 17, 2019 at 9:49 AM Mikhail Fedosin <mfedosin@redhat.com> wrote:
Hello!
In the documentation I noticed that EC2 metadata may soon be removed from Nova [1]. 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. 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? 2. When is it expected that EC2 metadata will be removed from the system?
Nova's in-tree ec2-api has already been removed [2] (though I can't find the commit that did it). That being said, the out-of-tree ec2-api project [3] is still around and kicking (just barely, looking at the commit history, but it's not inactive).
Best regards, Mikhail Fedosin
[1] https://docs.openstack.org/nova/latest/user/metadata.html#general-guidelines
[2] https://opendev.org/openstack/nova/src/branch/master/nova/api [3] https://opendev.org/openstack/ec2-api
On 12/17/2019 9:10 AM, Artom Lifshitz wrote:
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. 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?
I would think adding flavor info to meta_data.json should be trivial. It's an API change so it requires a spec though [1]. As for the network addresses, those aren't in network_data.json? Are you using neutron?
2. When is it expected that EC2 metadata will be removed from the system?
I wouldn't expect it anytime soon. The documentation that mentions this is a warning to not use something that is no longer maintained in nova (anything related to ec2), like a deprecation warning of sorts. If you have identified feature compatibility gaps to close in the openstack metadata API, please open a spec for Ussuri detailing what you need. Flavor should be pretty easy and the network addresses I would expect are already available in network_data.json but if something is missing there let's get it documented in the spec.
Nova's in-tree ec2-api has already been removed [2] (though I can't find the commit that did it). That being said, the out-of-tree ec2-api project [3] is still around and kicking (just barely, looking at the commit history, but it's not inactive).
Mikhail isn't talking about the user-facing EC2 API shim, he's talking about the metadata API code [2]. [1] https://specs.openstack.org/openstack/nova-specs/readme.html [2] https://github.com/openstack/nova/blob/20.0.0/nova/api/metadata/base.py#L236 -- Thanks, Matt
Thank you for the explanation! Currently network_data.json doesn't contain ip addresses: $ cat openstack/latest/network_data.json {"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"}]} but they are available with ec2 metadata $ cat ec2/latest/meta-data.json {"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"}} 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. Well, my plan is to create a spec for Ussuri then :) On Tue, Dec 17, 2019 at 5:04 PM Matt Riedemann <mriedemos@gmail.com> wrote:
Currently, we use EC2 metadata in our product to obtain public and
On 12/17/2019 9:10 AM, Artom Lifshitz wrote: private IP addresses, as well as the instance-type (flavor). Therefore, I would like to ask you a couple of questions.
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?
I would think adding flavor info to meta_data.json should be trivial. It's an API change so it requires a spec though [1].
As for the network addresses, those aren't in network_data.json? Are you using neutron?
2. When is it expected that EC2 metadata will be removed from the system?
I wouldn't expect it anytime soon. The documentation that mentions this is a warning to not use something that is no longer maintained in nova (anything related to ec2), like a deprecation warning of sorts.
If you have identified feature compatibility gaps to close in the openstack metadata API, please open a spec for Ussuri detailing what you need. Flavor should be pretty easy and the network addresses I would expect are already available in network_data.json but if something is missing there let's get it documented in the spec.
Nova's in-tree ec2-api has already been removed [2] (though I can't find the commit that did it). That being said, the out-of-tree ec2-api project [3] is still around and kicking (just barely, looking at the commit history, but it's not inactive).
Mikhail isn't talking about the user-facing EC2 API shim, he's talking about the metadata API code [2].
[1] https://specs.openstack.org/openstack/nova-specs/readme.html [2]
https://github.com/openstack/nova/blob/20.0.0/nova/api/metadata/base.py#L236
--
Thanks,
Matt
On 17 Dec 2019, at 19:14, Mikhail Fedosin <mfedosin@redhat.com<mailto:mfedosin@redhat.com>> wrote: Thank you for the explanation! Currently network_data.json doesn't contain ip addresses: $ cat openstack/latest/network_data.json {"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"}]} but they are available with ec2 metadata $ cat ec2/latest/meta-data.json {"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"}} 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. Well, my plan is to create a spec for Ussuri then :) Can we also have the ipv6 info in the Nova spec too ? Tim On Tue, Dec 17, 2019 at 5:04 PM Matt Riedemann <mriedemos@gmail.com<mailto:mriedemos@gmail.com>> wrote: On 12/17/2019 9:10 AM, Artom Lifshitz wrote:
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. 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?
I would think adding flavor info to meta_data.json should be trivial. It's an API change so it requires a spec though [1]. As for the network addresses, those aren't in network_data.json? Are you using neutron?
2. When is it expected that EC2 metadata will be removed from the system?
I wouldn't expect it anytime soon. The documentation that mentions this is a warning to not use something that is no longer maintained in nova (anything related to ec2), like a deprecation warning of sorts. If you have identified feature compatibility gaps to close in the openstack metadata API, please open a spec for Ussuri detailing what you need. Flavor should be pretty easy and the network addresses I would expect are already available in network_data.json but if something is missing there let's get it documented in the spec.
Nova's in-tree ec2-api has already been removed [2] (though I can't find the commit that did it). That being said, the out-of-tree ec2-api project [3] is still around and kicking (just barely, looking at the commit history, but it's not inactive).
Mikhail isn't talking about the user-facing EC2 API shim, he's talking about the metadata API code [2]. [1] https://specs.openstack.org/openstack/nova-specs/readme.html [2] https://github.com/openstack/nova/blob/20.0.0/nova/api/metadata/base.py#L236 -- Thanks, Matt
On 12/17/2019 12:14 PM, Mikhail Fedosin wrote:
Currently network_data.json doesn't contain ip addresses: $ cat openstack/latest/network_data.json {"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"}]}
This seems to be something in the setup of the network(s) attached to the server. Looking at the code that builds the network_data.json payload, it's returning here for you [1]. But if you look further down the network info dict would contain an IP address [2]. Maybe this is a limitation of the subnet that is chosen if there are multiple per network [3]. I want to say I've seen a bug about that recently but can't track it down. [1] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930... [2] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930... [3] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930... -- Thanks, Matt
On Tue, Dec 17, 2019 at 1:59 PM Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/17/2019 12:14 PM, Mikhail Fedosin wrote:
Currently network_data.json doesn't contain ip addresses: $ cat openstack/latest/network_data.json {"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"}]}
This seems to be something in the setup of the network(s) attached to the server.
Looking at the code that builds the network_data.json payload, it's returning here for you [1]. But if you look further down the network info dict would contain an IP address [2]. Maybe this is a limitation of the subnet that is chosen if there are multiple per network [3]. I want to say I've seen a bug about that recently but can't track it down.
There was a spec to add all subnets to network_data.json: https://review.opendev.org/#/c/580742/ I unfortunately don't have time anymore to work on it. I don't know the impact on installation using DHCP instead of static IP.
[1] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930... [2] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930... [3] https://github.com/openstack/nova/blob/f236c62d2eabc39b9f3301eea3be19389a930...
participants (5)
-
Artom Lifshitz
-
Mathieu Gagné
-
Matt Riedemann
-
Mikhail Fedosin
-
Tim Bell