OpenStack Heat

[RFE] Extend attributes of Server and Port resource to client interface configuration data

Bug #1766946 reported by Harald Jensås
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
New
Undecided
Unassigned
OpenStack Heat no-milestone-taged-bugs

Bug Description

We had a discussion[1] on the list.

In the scenario where the network, subnet and/or port is not a heat resource. Nova and Neutron are making implicit resources with attributes that are not available to the user. For example, when creating a server specifying a network. Nova creates an implicit port. We can get the ip address from each network via attributes on the server resource in heat. But to configure a client interface we need more data, such as:
  * subnet mask
  * gateway
  * host_routes
  * dns_servers
  * mtu

These attributes are are available in neutron's subnet and network objects. Adding this data as attributes to OS::Nova::Server and OS::Neutron::Port resources would enable interface configuration using os-net-config, or some other mechanism. Replacing dynamic configuration from the DHCP service. (For example, the attributes could be written to config drive for some interface configuration tool in the image.)

As a user I would like to do somethin akin to:
  {get_attr: [<server>, addresses, <network name_or_id>, 0, client_config]}

And get get a map with something akin to:
  client_config:
    ip_address: <ip-address>
    subnet_cidr: <subnet_cidr>
    host_routes: <host_routes>
    dns_servers: <dns_servers>
    mtu: <mtu>
    < others >

We resolve these by querying neutrons api. The list below is what I think may be useful:
  /v2.0/networks/{network_id}/mtu
  /v2.0/networks/{network_id}/dns_domain
  /v2.0/subnets/{subnet_id}/dns_nameservers
  /v2.0/subnets/{subnet_id}/host_routes
  /v2.0/subnets/{subnet_id}/ip_version
  /v2.0/subnets/{subnet_id}/gateway_ip
  /v2.0/subnets/{subnet_id}/cidr
  /v2.0/subnets/{subnet_id}/ipv6_address_mode
  /v2.0/subnets/{subnet_id}/ipv6_ra_mode
  /v2.0/ports/{port_id}/description
  /v2.0/ports/{port_id}/dns_assignment
  /v2.0/ports/{port_id}/dns_domain
  /v2.0/ports/{port_id}/dns_name
  /v2.0/ports/{port_id}/fixed_ips
  /v2.0/ports/{port_id}/name

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129540.html

Thomas Herve (therve)
summary: - [RFE] Extend attributes of Server and Port resorce to client interface
+ [RFE] Extend attributes of Server and Port resource to client interface
configuration data
Revision history for this message
Thomas Herve (therve) wrote :

So, I think Zane agreed to the idea of adding attributes, but not in this form. I don't think exposing a blob is a good thing. What we want (if we do?) is a structured element with namespace.

{get_attr: [<server>, addresses, <network name_or_id>, 0, port}

gives you the port.

So, I *think* we could do:

{get_attr: [<server>, addresses, <network name_or_id>, 0, port, fixed_ips}

I'm not a super fan of the idea. Maybe Zane can clarify.

Revision history for this message
Harald Jensås (harald-jensas) wrote :

Thanks for the feedback Thomas.

If I get your right, this:
{get_attr: [<server>, addresses, <network name_or_id>, 0, port, fixed_ips}

Extends to:
  {get_attr: [<server>, addresses, <network name_or_id>, 0, subnet, gateway}
  {get_attr: [<server>, addresses, <network name_or_id>, 0, subnet, cidr}
  {get_attr: [<server>, addresses, <network name_or_id>, 0, network, mtu}
... and so on?

If so, then I agree, much better than my idea of a blob.

Rico Lin (rico-lin)
Changed in heat:
milestone: none → no-priority-tag-bugs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.