Re: [openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

2016-05-24 Thread Ryan Harper 
On Tue, May 24, 2016 at 4:20 PM, Joshua Harlow 
wrote:

> Hi there all,
>
> I am working through code/refactoring in cloud-init to enable translation
> of the network_data.json file[1] provided by openstack (via nova via
> neutron?) into the equivalent sysconfig files (ubuntu files should already
> *mostly* work and systemd files are underway as well).
>
> Code for this sysconfig (WIP) is @
> https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7
> (requires base branch
> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor
> which did some tweaks to make things easier to work with).
>
> Sadly there has been some questions around certain format conversion and
> what it means when certain formats are given, for example in the following
> example:
>
> {
>   "services": [
> {
>   "type": "dns",
>   "address": "172.19.0.12"
> }
>   ],
>   "networks": [
> {
>   "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
>   "type": "ipv4",
>   "netmask": "255.255.252.0",
>   "link": "tap1a81968a-79",
>   "routes": [
> {
>   "netmask": "0.0.0.0",
>   "network": "0.0.0.0",
>   "gateway": "172.19.3.254"
> }
>   ],
>   "ip_address": "172.19.1.34",
>   "id": "network0"
> }
>   ],
>   "links": [
> {
>   "ethernet_mac_address": "fa:16:3e:ed:9a:59",
>   "mtu": null,
>   "type": "bridge",
>   "id": "tap1a81968a-79",
>   "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
> }
>   ]
> }
>
> In the cloud-init code what happens is that the links get connected to the
> networks and this gets then internally parsed, but for the bridge type
> listed here it appears information is missing about exactly what to bridge
> to (eth0, ethX? something else)?
>
> Should the 'bridge' type just be ignored and it should just be treated as
> a physical device type (which will cause a different set of logic in
> cloud-init to apply); something else?
>

Thanks Josh,

In particular, I'm hoping to clarify that the spec is meant to describe
guest network configuration (be that a baremetal instance in Ironic or a
VM).  If that holds, then I think
exposing the compute node config (LinuxBridge in this case) into guest
network config is confusing, and instead the network_data.json should have
had type: vif or type: phys.

The same holds true for ovs setup's, we've seen this network_data.json:


http://paste.openstack.org/show/498749/

then ovs setups should emit type: vif  or type: phys to indicate a guest
'physical' interface.

Thanks,
Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

2016-05-24 Thread Mathieu Gagné 
I think there is an implementation error.
The spec mentions that link type can be "vif", "phy" or (future) "bond".
Nova passes the "raw" Neutron VIF type instead.
IMO, "bridge" should be "vif" as per spec.
--
Mathieu


On Tue, May 24, 2016 at 5:20 PM, Joshua Harlow  wrote:
> Hi there all,
>
> I am working through code/refactoring in cloud-init to enable translation of
> the network_data.json file[1] provided by openstack (via nova via neutron?)
> into the equivalent sysconfig files (ubuntu files should already *mostly*
> work and systemd files are underway as well).
>
> Code for this sysconfig (WIP) is @
> https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 (requires
> base branch
> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor
> which did some tweaks to make things easier to work with).
>
> Sadly there has been some questions around certain format conversion and
> what it means when certain formats are given, for example in the following
> example:
>
> {
>   "services": [
> {
>   "type": "dns",
>   "address": "172.19.0.12"
> }
>   ],
>   "networks": [
> {
>   "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
>   "type": "ipv4",
>   "netmask": "255.255.252.0",
>   "link": "tap1a81968a-79",
>   "routes": [
> {
>   "netmask": "0.0.0.0",
>   "network": "0.0.0.0",
>   "gateway": "172.19.3.254"
> }
>   ],
>   "ip_address": "172.19.1.34",
>   "id": "network0"
> }
>   ],
>   "links": [
> {
>   "ethernet_mac_address": "fa:16:3e:ed:9a:59",
>   "mtu": null,
>   "type": "bridge",
>   "id": "tap1a81968a-79",
>   "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
> }
>   ]
> }
>
> In the cloud-init code what happens is that the links get connected to the
> networks and this gets then internally parsed, but for the bridge type
> listed here it appears information is missing about exactly what to bridge
> to (eth0, ethX? something else)?
>
> Should the 'bridge' type just be ignored and it should just be treated as a
> physical device type (which will cause a different set of logic in
> cloud-init to apply); something else?
>
> Thoughts would be appreciated,
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

2016-05-24 Thread Joshua Harlow 

Hi there all,

I am working through code/refactoring in cloud-init to enable 
translation of the network_data.json file[1] provided by openstack (via 
nova via neutron?) into the equivalent sysconfig files (ubuntu files 
should already *mostly* work and systemd files are underway as well).


Code for this sysconfig (WIP) is @ 
https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 
(requires base branch 
https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor 
which did some tweaks to make things easier to work with).


Sadly there has been some questions around certain format conversion and 
what it means when certain formats are given, for example in the 
following example:


{
  "services": [
{
  "type": "dns",
  "address": "172.19.0.12"
}
  ],
  "networks": [
{
  "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
  "type": "ipv4",
  "netmask": "255.255.252.0",
  "link": "tap1a81968a-79",
  "routes": [
{
  "netmask": "0.0.0.0",
  "network": "0.0.0.0",
  "gateway": "172.19.3.254"
}
  ],
  "ip_address": "172.19.1.34",
  "id": "network0"
}
  ],
  "links": [
{
  "ethernet_mac_address": "fa:16:3e:ed:9a:59",
  "mtu": null,
  "type": "bridge",
  "id": "tap1a81968a-79",
  "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
}
  ]
}

In the cloud-init code what happens is that the links get connected to 
the networks and this gets then internally parsed, but for the bridge 
type listed here it appears information is missing about exactly what to 
bridge to (eth0, ethX? something else)?


Should the 'bridge' type just be ignored and it should just be treated 
as a physical device type (which will cause a different set of logic in 
cloud-init to apply); something else?


Thoughts would be appreciated,

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact


-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev