[sdk] specify mac address when creating ports with nova
When using connection.compute.create_server(), what is the structure of the networks parameter? I see in the example is a list of objects with a single key in the list being the uuid of the network. I know there are other parameters that could be in this list though. The os-migrate ansible playbooks add fixed_ip to this. fixed_ip is not a Network or a Port class parameter. Port has fixed_ips, but that would be a list. I want to add mac address to this port, but I'm not sure if that's possible or what key I would need to add. Is the structure of the networks object documented somewhere? Thanks --- John Ratliff Systems Automation Engineer GlobalNOC @ Indiana University
On Tue, 2022-06-07 at 09:51 -0400, jdratlif@globalnoc.iu.edu wrote:
When using connection.compute.create_server(), what is the structure of the networks parameter?
I see in the example is a list of objects with a single key in the list being the uuid of the network. I know there are other parameters that could be in this list though. The os-migrate ansible playbooks add fixed_ip to this. fixed_ip is not a Network or a Port class parameter. Port has fixed_ips, but that would be a list. I want to add mac address to this port, but I'm not sure if that's possible or what key I would need to add.
this is not something that shoudl be added to the sdk or nova. id you want to create a vm with a set of ports with specific mac or fixed ips you shoudl first precreate the port in neutron with the relevent setting applied and then create teh server with a list of neutron port uuids. nova has legacy proxy apis for create vms with interfaces on spefic neturon networks or subnets but we do not plan to extend them to allow any finer grained contol then is there today https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-mor... """ No more API Proxies¶ Nova API current has some APIs that are now (in kilo) mostly just a proxy to other OpenStack services. If it were possible to remove a public API, these are some we might start with. As such, we don’t want to add any more. The first example is the API that is a proxy to the Glance v1 API. As Glance moves to deprecate its v1 API, we need to translate calls from the old v1 API we expose, to Glance’s v2 API. The next API to mention is the networking APIs, in particular the security groups API. Most of these APIs exist from when nova-network existed and the proxies were added during the transition. However, security groups has a much richer Neutron API, and if you use both Nova API and Neutron API, the mismatch can lead to some very unexpected results, in certain cases. Our intention is to avoid adding to the problems we already have in this area. """ the sdk shoudl likel avoid introduceding simiarl proxy apis. os-migrate shoudl simple use the neutron port apis in the sdk to create the ports on the migrate neutron netowrks with the fixed ips and macs that are required and then boot the vms with those ports instead of encodeign this in the sdk. this is they type of logic that shoudl live in the calling application (os-migrate) not in the sdk its self.
Is the structure of the networks object documented somewhere?
Thanks
---
John Ratliff
Systems Automation Engineer
GlobalNOC @ Indiana University
I'm looking at these docs here. https://docs.openstack.org/openstacksdk/xena/user/proxies/compute.html There is a create_server() function for the compute object on the connection. It says to pass attrs, which is comprised of properties of the Server class. When I go to the server class, all I see for ports is the networks property, which I can't find any description of. Assuming I already used neutron to create the ports, how would I tell the create_server function to use those ports? Is this the proxy function you said I shouldn't use anymore? I'm not clear on that. Thanks --- John Ratliff Systems Automation Engineer GlobalNOC @ Indiana University -----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, June 7, 2022 10:26 AM To: jdratlif@globalnoc.iu.edu; openstack-discuss@lists.openstack.org Cc: Ratliff, John <jdratlif@iu.edu> Subject: Re: [sdk] specify mac address when creating ports with nova On Tue, 2022-06-07 at 09:51 -0400, jdratlif@globalnoc.iu.edu wrote:
When using connection.compute.create_server(), what is the structure of the networks parameter?
I see in the example is a list of objects with a single key in the list being the uuid of the network. I know there are other parameters that could be in this list though. The os-migrate ansible playbooks add fixed_ip to this. fixed_ip is not a Network or a Port class parameter. Port has fixed_ips, but that would be a list. I want to add mac address to this port, but I'm not sure if that's possible or what key I would need to add.
this is not something that shoudl be added to the sdk or nova. id you want to create a vm with a set of ports with specific mac or fixed ips you shoudl first precreate the port in neutron with the relevent setting applied and then create teh server with a list of neutron port uuids. nova has legacy proxy apis for create vms with interfaces on spefic neturon networks or subnets but we do not plan to extend them to allow any finer grained contol then is there today https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-mor... """ No more API Proxies¶ Nova API current has some APIs that are now (in kilo) mostly just a proxy to other OpenStack services. If it were possible to remove a public API, these are some we might start with. As such, we don’t want to add any more. The first example is the API that is a proxy to the Glance v1 API. As Glance moves to deprecate its v1 API, we need to translate calls from the old v1 API we expose, to Glance’s v2 API. The next API to mention is the networking APIs, in particular the security groups API. Most of these APIs exist from when nova-network existed and the proxies were added during the transition. However, security groups has a much richer Neutron API, and if you use both Nova API and Neutron API, the mismatch can lead to some very unexpected results, in certain cases. Our intention is to avoid adding to the problems we already have in this area. """ the sdk shoudl likel avoid introduceding simiarl proxy apis. os-migrate shoudl simple use the neutron port apis in the sdk to create the ports on the migrate neutron netowrks with the fixed ips and macs that are required and then boot the vms with those ports instead of encodeign this in the sdk. this is they type of logic that shoudl live in the calling application (os-migrate) not in the sdk its self.
Is the structure of the networks object documented somewhere?
Thanks
---
John Ratliff
Systems Automation Engineer
GlobalNOC @ Indiana University
On Tue, 2022-06-07 at 11:12 -0400, jdratlif@globalnoc.iu.edu wrote:
I'm looking at these docs here. https://docs.openstack.org/openstacksdk/xena/user/proxies/compute.html
There is a create_server() function for the compute object on the connection. It says to pass attrs, which is comprised of properties of the Server class. When I go to the server class, all I see for ports is the networks property, which I can't find any description of.
Assuming I already used neutron to create the ports, how would I tell the create_server function to use those ports? Is this the proxy function you said I shouldn't use anymore? I'm not clear on that.
i think you would use the networks object https://docs.openstack.org/openstacksdk/xena/user/resources/compute/v2/serve... based on https://docs.openstack.org/openstacksdk/xena/user/guides/compute.html#create... and https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#cr... you woudl change there default example form server = conn.compute.create_server( name=SERVER_NAME, image_id=image.id, flavor_id=flavor.id, networks=[{"uuid": network.id}], key_name=keypair.name) to server = conn.compute.create_server( name=SERVER_NAME, image_id=image.id, flavor_id=flavor.id, networks=[{"port": port.id}], key_name=keypair.name) where port is a https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/netwo... object that you previously created via https://docs.openstack.org/openstacksdk/xena/user/proxies/network.html#port-... or https://docs.openstack.org/openstacksdk/xena/user/resources/network/v2/port.... depending on if you want to use the service proxies https://docs.openstack.org/openstacksdk/xena/user/index.html#service-proxies or resource interface https://docs.openstack.org/openstacksdk/xena/user/index.html#resource-interf... im kind of surprised there isnt an example fo this already.
Thanks
--- John Ratliff Systems Automation Engineer GlobalNOC @ Indiana University
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Tuesday, June 7, 2022 10:26 AM To: jdratlif@globalnoc.iu.edu; openstack-discuss@lists.openstack.org Cc: Ratliff, John <jdratlif@iu.edu> Subject: Re: [sdk] specify mac address when creating ports with nova
On Tue, 2022-06-07 at 09:51 -0400, jdratlif@globalnoc.iu.edu wrote:
When using connection.compute.create_server(), what is the structure of the networks parameter?
I see in the example is a list of objects with a single key in the list being the uuid of the network. I know there are other parameters that could be in this list though. The os-migrate ansible playbooks add fixed_ip to this. fixed_ip is not a Network or a Port class parameter. Port has fixed_ips, but that would be a list. I want to add mac address to this port, but I'm not sure if that's possible or what key I would need to add.
this is not something that shoudl be added to the sdk or nova.
id you want to create a vm with a set of ports with specific mac or fixed ips you shoudl first precreate the port in neutron with the relevent setting applied and then create teh server with a list of neutron port uuids.
nova has legacy proxy apis for create vms with interfaces on spefic neturon networks or subnets but we do not plan to extend them to allow any finer grained contol then is there today https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-mor...
""" No more API Proxies¶
Nova API current has some APIs that are now (in kilo) mostly just a proxy to other OpenStack services. If it were possible to remove a public API, these are some we might start with. As such, we don’t want to add any more.
The first example is the API that is a proxy to the Glance v1 API. As Glance moves to deprecate its v1 API, we need to translate calls from the old v1 API we expose, to Glance’s v2 API.
The next API to mention is the networking APIs, in particular the security groups API. Most of these APIs exist from when nova-network existed and the proxies were added during the transition. However, security groups has a much richer Neutron API, and if you use both Nova API and Neutron API, the mismatch can lead to some very unexpected results, in certain cases.
Our intention is to avoid adding to the problems we already have in this area. """
the sdk shoudl likel avoid introduceding simiarl proxy apis.
os-migrate shoudl simple use the neutron port apis in the sdk to create the ports on the migrate neutron netowrks with the fixed ips and macs that are required and then boot the vms with those ports instead of encodeign this in the sdk. this is they type of logic that shoudl live in the calling application (os-migrate) not in the sdk its self.
Is the structure of the networks object documented somewhere?
Thanks
---
John Ratliff
Systems Automation Engineer
GlobalNOC @ Indiana University
participants (2)
-
jdratlif＠globalnoc.iu.edu
-
Sean Mooney