9:59 a.m.
Hi,
I would like to test my VNF on an openstack environment deployed using
TripleO.
For that I need to setup flat provider networks that go only to the compute
node.
I tried deploying an overcoud with additional neutron bridge mappings as
following
- Added NeutronBridgeMappings:
" datacentre:br-ex,physdown;br-down,physup:br-up" to network environment
file
- Added following resources to compute.yaml file
-
type: ovs_bridge
name: br-down
mtu: 9000
members:
-
type: interface
name: ens4f0
# force the MAC address of the bridge to this interface
primary: true
-
type: ovs_bridge
name: br-up
mtu: 9000
members:
-
type: interface
name: ens4f1
# force the MAC address of the bridge to this interface
primary: true
This will create the intended OVS bridges on the the compute node with the
interfaces connected.
The unwanted side effect it that ii also created the bridges on the
controller node without any interfaces connected to it
Is there a way to have the undercloud create the bridges only on the
compute nodes and not on the controller nodes???
Samuel
5:01 a.m.
Hi Samuel,
Could you please share the nic template used for the controller node?
The bridges should be created according to the nic template so I would
like to see how it looks.
Thanks!
On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
<smonderer(a)vasonanetworks.com> wrote:
Hi,
I would like to test my VNF on an openstack environment deployed using
TripleO.
For that I need to setup flat provider networks that go only to the compute
node.
I tried deploying an overcoud with additional neutron bridge mappings as
following
Added NeutronBridgeMappings: "
datacentre:br-ex,physdown;br-down,physup:br-up" to network environment file
Added following resources to compute.yaml file
-
type: ovs_bridge
name: br-down
mtu: 9000
members:
-
type: interface
name: ens4f0
# force the MAC address of the bridge to this interface
primary: true
-
type: ovs_bridge
name: br-up
mtu: 9000
members:
-
type: interface
name: ens4f1
# force the MAC address of the bridge to this interface
primary: true
This will create the intended OVS bridges on the the compute node with the
interfaces connected.
The unwanted side effect it that ii also created the bridges on the
controller node without any interfaces connected to it
Is there a way to have the undercloud create the bridges only on the compute
nodes and not on the controller nodes???
Samuel
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
8:03 a.m.
Hi Marius,
Attached is the controller node template.
I've also added below the ovs-vsct show results for both the compute and
control node
For some reason there is also a bridge called "undef" in both the
controller and the compute
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-vsctl show
00ce4561-418d-4161-b907-3b2222930f35
Manager "ptcp:6640:127.0.0.1"
Bridge br-int
Controller "tcp:127.0.0.1:6633"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
Bridge br-mng
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port br-mng
Interface br-mng
type: internal
Port "vlan203"
tag: 203
Interface "vlan203"
type: internal
Port "eno2"
Interface "eno2"
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Bridge br-up
Port br-up
Interface br-up
type: internal
Bridge br-ex
fail_mode: standalone
Port br-ex
Interface br-ex
type: internal
Port "eno3"
Interface "eno3"
ovs_version: "2.5.0"
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show
2f6bccd5-9653-42df-a1db-8cb5c3b0293a
Manager "ptcp:6640:127.0.0.1"
Bridge br-down
fail_mode: standalone
Port br-down
Interface br-down
type: internal
Port "em3"
Interface "em3"
Bridge br-up
fail_mode: standalone
Port br-up
Interface br-up
type: internal
Port "em4"
Interface "em4"
Bridge br-ex
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Port br-ex
Interface br-ex
type: internal
Port "em2"
Interface "em2"
Bridge br-int
Controller "tcp:127.0.0.1:6633"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
ovs_version: "2.5.0"
[heat-admin@overcloud-compute-0 ~]$
On Fri, Mar 31, 2017 at 1:01 PM Marius Cornea <marius(a)remote-lab.net> wrote:
Hi Samuel,
Could you please share the nic template used for the controller node?
The bridges should be created according to the nic template so I would
like to see how it looks.
Thanks!
On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
<smonderer(a)vasonanetworks.com> wrote:
> Hi,
>
> I would like to test my VNF on an openstack environment deployed using
> TripleO.
> For that I need to setup flat provider networks that go only to the
compute
> node.
> I tried deploying an overcoud with additional neutron bridge mappings as
> following
>
> Added NeutronBridgeMappings: "
> datacentre:br-ex,physdown;br-down,physup:br-up" to network environment
file
> Added following resources to compute.yaml file
>
> -
> type: ovs_bridge
> name: br-down
> mtu: 9000
> members:
> -
> type: interface
> name: ens4f0
> # force the MAC address of the bridge to this interface
> primary: true
> -
> type: ovs_bridge
> name: br-up
> mtu: 9000
> members:
> -
> type: interface
> name: ens4f1
> # force the MAC address of the bridge to this interface
> primary: true
>
> This will create the intended OVS bridges on the the compute node with
the
> interfaces connected.
>
> The unwanted side effect it that ii also created the bridges on the
> controller node without any interfaces connected to it
>
> Is there a way to have the undercloud create the bridges only on the
compute
> nodes and not on the controller nodes???
>
> Samuel
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
10:47 a.m.
Thanks, Samuel. I see the controller contains a br-up bridge which I
couldn't find in the template. Could you also please paste the
/etc/os-net-config/config.json file from these nodes?
Marius
On Mon, Apr 3, 2017 at 3:03 PM, Samuel Monderer
<smonderer(a)vasonanetworks.com> wrote:
Hi Marius,
Attached is the controller node template.
I've also added below the ovs-vsct show results for both the compute and
control node
For some reason there is also a bridge called "undef" in both the controller
and the compute
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-vsctl show
00ce4561-418d-4161-b907-3b2222930f35
Manager "ptcp:6640:127.0.0.1"
Bridge br-int
Controller "tcp:127.0.0.1:6633"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
Bridge br-mng
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port br-mng
Interface br-mng
type: internal
Port "vlan203"
tag: 203
Interface "vlan203"
type: internal
Port "eno2"
Interface "eno2"
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Bridge br-up
Port br-up
Interface br-up
type: internal
Bridge br-ex
fail_mode: standalone
Port br-ex
Interface br-ex
type: internal
Port "eno3"
Interface "eno3"
ovs_version: "2.5.0"
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show
2f6bccd5-9653-42df-a1db-8cb5c3b0293a
Manager "ptcp:6640:127.0.0.1"
Bridge br-down
fail_mode: standalone
Port br-down
Interface br-down
type: internal
Port "em3"
Interface "em3"
Bridge br-up
fail_mode: standalone
Port br-up
Interface br-up
type: internal
Port "em4"
Interface "em4"
Bridge br-ex
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Port br-ex
Interface br-ex
type: internal
Port "em2"
Interface "em2"
Bridge br-int
Controller "tcp:127.0.0.1:6633"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
ovs_version: "2.5.0"
[heat-admin@overcloud-compute-0 ~]$
On Fri, Mar 31, 2017 at 1:01 PM Marius Cornea <marius(a)remote-lab.net> wrote:
>
> Hi Samuel,
>
> Could you please share the nic template used for the controller node?
> The bridges should be created according to the nic template so I would
> like to see how it looks.
>
> Thanks!
>
> On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
> <smonderer(a)vasonanetworks.com> wrote:
> > Hi,
> >
> > I would like to test my VNF on an openstack environment deployed using
> > TripleO.
> > For that I need to setup flat provider networks that go only to the
> > compute
> > node.
> > I tried deploying an overcoud with additional neutron bridge mappings as
> > following
> >
> > Added NeutronBridgeMappings: "
> > datacentre:br-ex,physdown;br-down,physup:br-up" to network environment
> > file
> > Added following resources to compute.yaml file
> >
> > -
> > type: ovs_bridge
> > name: br-down
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f0
> > # force the MAC address of the bridge to this
> > interface
> > primary: true
> > -
> > type: ovs_bridge
> > name: br-up
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f1
> > # force the MAC address of the bridge to this
> > interface
> > primary: true
> >
> > This will create the intended OVS bridges on the the compute node with
> > the
> > interfaces connected.
> >
> > The unwanted side effect it that ii also created the bridges on the
> > controller node without any interfaces connected to it
> >
> > Is there a way to have the undercloud create the bridges only on the
> > compute
> > nodes and not on the controller nodes???
> >
> > Samuel
> >
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
2:03 p.m.
On 04/03/2017 06:03 AM, Samuel Monderer wrote:
Hi Marius,
Attached is the controller node template.
I've also added below the ovs-vsct show results for both the compute and
control node
For some reason there is also a bridge called "undef" in both the
controller and the compute
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-vsctl show
00ce4561-418d-4161-b907-3b2222930f35
Manager "ptcp:6640:127.0.0.1"
Bridge br-int
Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
Bridge br-mng
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port br-mng
Interface br-mng
type: internal
Port "vlan203"
tag: 203
Interface "vlan203"
type: internal
Port "eno2"
Interface "eno2"
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Bridge br-up
Port br-up
Interface br-up
type: internal
Bridge br-ex
fail_mode: standalone
Port br-ex
Interface br-ex
type: internal
Port "eno3"
Interface "eno3"
ovs_version: "2.5.0"
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show
2f6bccd5-9653-42df-a1db-8cb5c3b0293a
Manager "ptcp:6640:127.0.0.1"
Bridge br-down
fail_mode: standalone
Port br-down
Interface br-down
type: internal
Port "em3"
Interface "em3"
Bridge br-up
fail_mode: standalone
Port br-up
Interface br-up
type: internal
Port "em4"
Interface "em4"
Bridge br-ex
fail_mode: standalone
Port "vlan204"
tag: 204
Interface "vlan204"
type: internal
Port "vlan202"
tag: 202
Interface "vlan202"
type: internal
Port "vlan201"
tag: 201
Interface "vlan201"
type: internal
Port br-ex
Interface br-ex
type: internal
Port "em2"
Interface "em2"
Bridge br-int
Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge undef
Port undef
Interface undef
type: internal
ovs_version: "2.5.0"
[heat-admin@overcloud-compute-0 ~]$
On Fri, Mar 31, 2017 at 1:01 PM Marius Cornea <marius(a)remote-lab.net
<mailto:marius@remote-lab.net>> wrote:
Hi Samuel,
Could you please share the nic template used for the controller node?
The bridges should be created according to the nic template so I would
like to see how it looks.
Thanks!
On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
<smonderer(a)vasonanetworks.com <mailto:smonderer@vasonanetworks.com>>
wrote:
> Hi,
>
> I would like to test my VNF on an openstack environment deployed using
> TripleO.
> For that I need to setup flat provider networks that go only to
the compute
> node.
> I tried deploying an overcoud with additional neutron bridge
mappings as
> following
>
> Added NeutronBridgeMappings: "
> datacentre:br-ex,physdown;br-down,physup:br-up" to network
environment file
> Added following resources to compute.yaml file
>
> -
> type: ovs_bridge
> name: br-down
> mtu: 9000
> members:
> -
> type: interface
> name: ens4f0
> # force the MAC address of the bridge to this
interface
> primary: true
> -
> type: ovs_bridge
> name: br-up
> mtu: 9000
> members:
> -
> type: interface
> name: ens4f1
> # force the MAC address of the bridge to this
interface
> primary: true
>
> This will create the intended OVS bridges on the the compute node
with the
> interfaces connected.
>
> The unwanted side effect it that ii also created the bridges on the
> controller node without any interfaces connected to it
>
> Is there a way to have the undercloud create the bridges only on
the compute
> nodes and not on the controller nodes???
>
> Samuel
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com <mailto:rdo-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
<mailto:rdo-list-unsubscribe@redhat.com>
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
You've got a syntax error in your bridge_mappings (semicolon instead of
colon). This is causing your "undef" bridge.
Also, it is expected behavior that if you define a bridge in a bridge
mapping, but you don't include that bridge in the NIC template, that you
will end up with a bridge with no interfaces attached. It shouldn't hurt
anything.
--
Dan Sneddon | Senior Principal Software Engineer
dsneddon(a)redhat.com | redhat.com/openstack
dsneddon:irc | @dxs:twitter
3:49 p.m.
I've fixed the semicolon issue and below are the
/etc/os-net-config/config.json files of the nodes
[heat-admin@overcloud-controller-0 ~]$ cat /etc/os-net-config/config.json |
python -m json.tool
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.0.2.16/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"name": "nic1",
"routes": [
{
"ip_netmask": "169.254.169.254/32",
"next_hop": "192.0.2.1"
}
],
"type": "interface",
"use_dhcp": false
},
{
"dns_servers": [
"192.168.60.100"
],
"members": [
{
"name": "nic2",
"primary": true,
"type": "interface"
},
{
"addresses": [
{
"ip_netmask": "172.16.0.10/24"
}
],
"type": "vlan",
"vlan_id": 201
},
{
"addresses": [
{
"ip_netmask": "172.18.0.14/24"
}
],
"type": "vlan",
"vlan_id": 202
},
{
"addresses": [
{
"ip_netmask": "172.19.0.12/24"
}
],
"type": "vlan",
"vlan_id": 203
},
{
"addresses": [
{
"ip_netmask": "172.17.0.11/24"
}
],
"type": "vlan",
"vlan_id": 204
}
],
"name": "br-mng",
"type": "ovs_bridge"
},
{
"addresses": [
{
"ip_netmask": "192.168.60.66/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"members": [
{
"name": "nic3",
"primary": true,
"type": "interface"
}
],
"name": "br-ex",
"routes": [
{
"default": true,
"next_hop": "192.168.60.1"
}
],
"type": "ovs_bridge",
"use_dhcp": false
}
]
}
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-compute-0 ~]$ cat /etc/os-net-config/config.json |
python -m json.tool
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.0.2.6/24"
}
],
"dns_servers": [
"192.168.60.100"
],
"name": "nic1",
"routes": [
{
"ip_netmask": "169.254.169.254/32",
"next_hop": "192.0.2.1"
},
{
"default": true,
"next_hop": "192.0.2.1"
}
],
"type": "interface",
"use_dhcp": false
},
{
"members": [
{
"name": "nic2",
"primary": true,
"type": "interface"
},
{
"addresses": [
{
"ip_netmask": "172.16.0.11/24"
}
],
"type": "vlan",
"vlan_id": 201
},
{
"addresses": [
{
"ip_netmask": "172.18.0.10/24"
}
],
"type": "vlan",
"vlan_id": 202
},
{
"addresses": [
{
"ip_netmask": "172.17.0.10/24"
}
],
"type": "vlan",
"vlan_id": 204
}
],
"name": "br-ex",
"type": "ovs_bridge"
},
{
"members": [
{
"mtu": 9000,
"name": "nic3",
"primary": true,
"type": "interface"
}
],
"mtu": 9000,
"name": "br-down",
"type": "ovs_bridge"
},
{
"members": [
{
"mtu": 9000,
"name": "nic4",
"primary": true,
"type": "interface"
}
],
"mtu": 9000,
"name": "br-up",
"type": "ovs_bridge"
}
]
}
[heat-admin@overcloud-compute-0 ~]$
On Mon, Apr 3, 2017 at 10:03 PM Dan Sneddon <dsneddon(a)redhat.com> wrote:
On 04/03/2017 06:03 AM, Samuel Monderer wrote:
> Hi Marius,
>
> Attached is the controller node template.
> I've also added below the ovs-vsct show results for both the compute and
> control node
> For some reason there is also a bridge called "undef" in both the
> controller and the compute
>
> [heat-admin@overcloud-controller-0 ~]$ sudo ovs-vsctl show
> 00ce4561-418d-4161-b907-3b2222930f35
> Manager "ptcp:6640:127.0.0.1"
> Bridge br-int
> Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Bridge undef
> Port undef
> Interface undef
> type: internal
> Bridge br-mng
> fail_mode: standalone
> Port "vlan204"
> tag: 204
> Interface "vlan204"
> type: internal
> Port "vlan202"
> tag: 202
> Interface "vlan202"
> type: internal
> Port br-mng
> Interface br-mng
> type: internal
> Port "vlan203"
> tag: 203
> Interface "vlan203"
> type: internal
> Port "eno2"
> Interface "eno2"
> Port "vlan201"
> tag: 201
> Interface "vlan201"
> type: internal
> Bridge br-up
> Port br-up
> Interface br-up
> type: internal
> Bridge br-ex
> fail_mode: standalone
> Port br-ex
> Interface br-ex
> type: internal
> Port "eno3"
> Interface "eno3"
> ovs_version: "2.5.0"
> [heat-admin@overcloud-controller-0 ~]$
>
>
> [heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show
> 2f6bccd5-9653-42df-a1db-8cb5c3b0293a
> Manager "ptcp:6640:127.0.0.1"
> Bridge br-down
> fail_mode: standalone
> Port br-down
> Interface br-down
> type: internal
> Port "em3"
> Interface "em3"
> Bridge br-up
> fail_mode: standalone
> Port br-up
> Interface br-up
> type: internal
> Port "em4"
> Interface "em4"
> Bridge br-ex
> fail_mode: standalone
> Port "vlan204"
> tag: 204
> Interface "vlan204"
> type: internal
> Port "vlan202"
> tag: 202
> Interface "vlan202"
> type: internal
> Port "vlan201"
> tag: 201
> Interface "vlan201"
> type: internal
> Port br-ex
> Interface br-ex
> type: internal
> Port "em2"
> Interface "em2"
> Bridge br-int
> Controller "tcp:127.0.0.1:6633 <http://127.0.0.1:6633>"
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Bridge undef
> Port undef
> Interface undef
> type: internal
> ovs_version: "2.5.0"
> [heat-admin@overcloud-compute-0 ~]$
>
>
>
>
> On Fri, Mar 31, 2017 at 1:01 PM Marius Cornea <marius(a)remote-lab.net
> <mailto:marius@remote-lab.net>> wrote:
>
> Hi Samuel,
>
> Could you please share the nic template used for the controller node?
> The bridges should be created according to the nic template so I
would
> like to see how it looks.
>
> Thanks!
>
> On Thu, Mar 30, 2017 at 4:59 PM, Samuel Monderer
> <smonderer(a)vasonanetworks.com
<mailto:smonderer@vasonanetworks.com>>
> wrote:
> > Hi,
> >
> > I would like to test my VNF on an openstack environment deployed
using
> > TripleO.
> > For that I need to setup flat provider networks that go only to
> the compute
> > node.
> > I tried deploying an overcoud with additional neutron bridge
> mappings as
> > following
> >
> > Added NeutronBridgeMappings: "
> > datacentre:br-ex,physdown;br-down,physup:br-up" to network
> environment file
> > Added following resources to compute.yaml file
> >
> > -
> > type: ovs_bridge
> > name: br-down
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f0
> > # force the MAC address of the bridge to this
> interface
> > primary: true
> > -
> > type: ovs_bridge
> > name: br-up
> > mtu: 9000
> > members:
> > -
> > type: interface
> > name: ens4f1
> > # force the MAC address of the bridge to this
> interface
> > primary: true
> >
> > This will create the intended OVS bridges on the the compute node
> with the
> > interfaces connected.
> >
> > The unwanted side effect it that ii also created the bridges on the
> > controller node without any interfaces connected to it
> >
> > Is there a way to have the undercloud create the bridges only on
> the compute
> > nodes and not on the controller nodes???
> >
> > Samuel
> >
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list(a)redhat.com <mailto:rdo-list@redhat.com>
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
> <mailto:rdo-list-unsubscribe@redhat.com>
>
>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>
You've got a syntax error in your bridge_mappings (semicolon instead of
colon). This is causing your "undef" bridge.
Also, it is expected behavior that if you define a bridge in a bridge
mapping, but you don't include that bridge in the NIC template, that you
will end up with a bridge with no interfaces attached. It shouldn't hurt
anything.
--
Dan Sneddon | Senior Principal Software Engineer
dsneddon(a)redhat.com | redhat.com/openstack
dsneddon:irc | @dxs:twitter
2602
days inactive
2606
days old
5 comments
3 participants
participants (3)
-
Dan Sneddon -
Marius Cornea -
Samuel Monderer