4:42 a.m.
Hi,
this has been discussed for a while, so I'd like to set automatic
restart for OpenStack services as a goal for Mitaka - milestone 1.
These are easy fixes, and by setting it to milestone 1, we'll have
more than enough time to test this and optimize.
I already created a trello card to track that effort, but I'd like to
get your feedback first.
https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
Your thoughts?
Regards,
H.
6:07 a.m.
Hi,
this has been discussed for a while, so I'd like to set automatic
restart for OpenStack services as a goal for Mitaka - milestone 1.
These are easy fixes, and by setting it to milestone 1, we'll have
more than enough time to test this and optimize.
I already created a trello card to track that effort, but I'd like to
get your feedback first.
https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
Your thoughts?
+1, for me this is a good idea.
Javier
Regards,
H.
_______________________________________________
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
7 a.m.
On 11/12/2015 05:42 AM, Haïkel wrote:
Hi,
this has been discussed for a while, so I'd like to set automatic
restart for OpenStack services as a goal for Mitaka - milestone 1.
These are easy fixes, and by setting it to milestone 1, we'll have
more than enough time to test this and optimize.
I already created a trello card to track that effort, but I'd like to
get your feedback first.
https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
can you describe what you mean here by automatic restart for services?
I'm worried what the implications would be for things that are running
under Pacemaker control in an HA environment, so I think we need more
details here
7:06 a.m.
2015-11-12 14:00 GMT+01:00 Perry Myers <pmyers(a)redhat.com>:
can you describe what you mean here by automatic restart for
services?
I'm worried what the implications would be for things that are running
under Pacemaker control in an HA environment, so I think we need more
details here
Can we have more details what "under Pacemaker control" means?
Haikel's proposal is about modifying systemd service unit files but
afaik Pacemaker is not using them but what they call "resource agents"
?
Cheers,
Alan
7:30 a.m.
On 11/12/2015 08:06 AM, Alan Pevec wrote:
2015-11-12 14:00 GMT+01:00 Perry Myers <pmyers(a)redhat.com>:
> can you describe what you mean here by automatic restart for services?
>
> I'm worried what the implications would be for things that are running
> under Pacemaker control in an HA environment, so I think we need more
> details here
Can we have more details what "under Pacemaker control" means?
Haikel's proposal is about modifying systemd service unit files but
afaik Pacemaker is not using them but what they call "resource agents"
?
Not correct... not every service _has_ a resource agent. Mariadb/galera
and rabbitmq do, but all other services are controlled via Pacemaker via
their systemd scripts
So when you tell pacemaker to stop nova-api, it does so via systemd
If something outside of pacemaker knowledge (like user from command
line, or rpm %post or whatever) uses systemd directly to stop nova-api,
pacemaker says "OMG the service died" and tries to recover
Perry
8:05 a.m.
2015-11-12 14:30 GMT+01:00 Perry Myers <pmyers(a)redhat.com>:
On 11/12/2015 08:06 AM, Alan Pevec wrote:
> 2015-11-12 14:00 GMT+01:00 Perry Myers <pmyers(a)redhat.com>:
>> can you describe what you mean here by automatic restart for services?
>>
>> I'm worried what the implications would be for things that are running
>> under Pacemaker control in an HA environment, so I think we need more
>> details here
>
> Can we have more details what "under Pacemaker control" means?
> Haikel's proposal is about modifying systemd service unit files but
> afaik Pacemaker is not using them but what they call "resource agents"
> ?
Not correct... not every service _has_ a resource agent. Mariadb/galera
and rabbitmq do, but all other services are controlled via Pacemaker via
their systemd scripts
So when you tell pacemaker to stop nova-api, it does so via systemd
This is ok, if you stop normally services, they won't be restarted.
If something outside of pacemaker knowledge (like user from command
line, or rpm %post or whatever) uses systemd directly to stop nova-api,
pacemaker says "OMG the service died" and tries to recover
Perry
If Andrew (or anyone else) could confirm, but from my understanding,
Pacemaker already disable systemd auto-respawn since 1.1.10 (which is
quite old, RHEL7 ship 1.1.12 at least)
https://github.com/ClusterLabs/pacemaker/commit/37c6efae3b9d1db18d8d782bd...
https://github.com/ClusterLabs/pacemaker/blob/master/lib/services/systemd...
<= the code generating the override file shows that it does disable
that feature/
Concerning the changes, they will considerably improve reliability for
people not relying on Pacemaker, so I guess we're good in that aspect.
Regards,
H.
7:38 a.m.
On 11/12/2015 2:06 PM, Alan Pevec wrote:
2015-11-12 14:00 GMT+01:00 Perry Myers <pmyers(a)redhat.com>:
> can you describe what you mean here by automatic restart for services?
>
> I'm worried what the implications would be for things that are running
> under Pacemaker control in an HA environment, so I think we need more
> details here
Can we have more details what "under Pacemaker control" means?
Haikel's proposal is about modifying systemd service unit files but
afaik Pacemaker is not using them but what they call "resource agents"
?
Pacemaker doesn´t use resource agents for everything. Some services as
managed/monitored by pacemaker by using systemd unit files.
You can have a random application that´s part of the OS (via systemd
unit file) and still manage it in cluster mode via pacemaker.
Fabio
9:55 a.m.
----- Original Message -----
On 11/12/2015 05:42 AM, Haïkel wrote:
> Hi,
>
> this has been discussed for a while, so I'd like to set automatic
> restart for OpenStack services as a goal for Mitaka - milestone 1.
> These are easy fixes, and by setting it to milestone 1, we'll have
> more than enough time to test this and optimize.
>
> I already created a trello card to track that effort, but I'd like to
> get your feedback first.
> https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
can you describe what you mean here by automatic restart for services?
I'm worried what the implications would be for things that are running
under Pacemaker control in an HA environment, so I think we need more
details here
FWIW, this option is already enabled in some services, such as nova-api
(https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...)
where Restart=always. I've checked a Juno deployment, and that option was already set
back then.
Regards,
Javier
_______________________________________________
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
9:56 a.m.
On 11/12/2015 4:55 PM, Javier Pena wrote:
----- Original Message -----
> On 11/12/2015 05:42 AM, Haïkel wrote:
>> Hi,
>>
>> this has been discussed for a while, so I'd like to set automatic
>> restart for OpenStack services as a goal for Mitaka - milestone 1.
>> These are easy fixes, and by setting it to milestone 1, we'll have
>> more than enough time to test this and optimize.
>>
>> I already created a trello card to track that effort, but I'd like to
>> get your feedback first.
>> https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
>
> can you describe what you mean here by automatic restart for services?
>
> I'm worried what the implications would be for things that are running
> under Pacemaker control in an HA environment, so I think we need more
> details here
>
FWIW, this option is already enabled in some services, such as nova-api
(https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...)
where Restart=always. I've checked a Juno deployment, and that option was already set
back then.
It shouldn´t affect pacemaker deployment, because we do override some of
those values via dbus config.
Fabio
Regards,
Javier
> _______________________________________________
> 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:01 a.m.
Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
On 11/12/2015 4:55 PM, Javier Pena wrote:
> ----- Original Message -----
>> On 11/12/2015 05:42 AM, Haïkel wrote:
>>> Hi,
>>>
>>> this has been discussed for a while, so I'd like to set automatic
>>> restart for OpenStack services as a goal for Mitaka - milestone 1.
>>> These are easy fixes, and by setting it to milestone 1, we'll have
>>> more than enough time to test this and optimize.
>>>
>>> I already created a trello card to track that effort, but I'd like to
>>> get your feedback first.
>>> https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
>>
>> can you describe what you mean here by automatic restart for services?
>>
>> I'm worried what the implications would be for things that are running
>> under Pacemaker control in an HA environment, so I think we need more
>> details here
>
> FWIW, this option is already enabled in some services, such as nova-api
>
(https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...)
> where Restart=always. I've checked a Juno deployment, and that option
> was already set back then.
It shouldn´t affect pacemaker deployment, because we do override some of
those values via dbus config.
To clarify things, doesn’t it affect just nova-api because you have some
special treatment for the service? or it would not affect you if applied to
other units? [In that case we could go forward and set automatic restart
policy there, while you could stick to your hooks to influence service
restart behaviour.]
Ihar
10:04 a.m.
On 11/12/2015 5:01 PM, Ihar Hrachyshka wrote:
Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
>
>
> On 11/12/2015 4:55 PM, Javier Pena wrote:
>> ----- Original Message -----
>>> On 11/12/2015 05:42 AM, Haïkel wrote:
>>>> Hi,
>>>>
>>>> this has been discussed for a while, so I'd like to set automatic
>>>> restart for OpenStack services as a goal for Mitaka - milestone 1.
>>>> These are easy fixes, and by setting it to milestone 1, we'll have
>>>> more than enough time to test this and optimize.
>>>>
>>>> I already created a trello card to track that effort, but I'd like
to
>>>> get your feedback first.
>>>> https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
>>>
>>> can you describe what you mean here by automatic restart for services?
>>>
>>> I'm worried what the implications would be for things that are running
>>> under Pacemaker control in an HA environment, so I think we need more
>>> details here
>>
>> FWIW, this option is already enabled in some services, such as
>> nova-api
>>
(https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...)
>> where Restart=always. I've checked a Juno deployment, and that option
>> was already set back then.
>
> It shouldn´t affect pacemaker deployment, because we do override some of
> those values via dbus config.
To clarify things, doesn’t it affect just nova-api because you have some
special treatment for the service? or it would not affect you if applied
to other units? [In that case we could go forward and set automatic
restart policy there, while you could stick to your hooks to influence
service restart behaviour.]
all services in pacemaker that are managed/monitored via systemd gets a
set of overrides to avoid those kind of issues.
Fabio
Ihar
10:06 a.m.
Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
On 11/12/2015 5:01 PM, Ihar Hrachyshka wrote:
> Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
>
>> On 11/12/2015 4:55 PM, Javier Pena wrote:
>>> ----- Original Message -----
>>>> On 11/12/2015 05:42 AM, Haïkel wrote:
>>>>> Hi,
>>>>>
>>>>> this has been discussed for a while, so I'd like to set
automatic
>>>>> restart for OpenStack services as a goal for Mitaka - milestone 1.
>>>>> These are easy fixes, and by setting it to milestone 1, we'll
have
>>>>> more than enough time to test this and optimize.
>>>>>
>>>>> I already created a trello card to track that effort, but I'd
like to
>>>>> get your feedback first.
>>>>> https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
>>>>
>>>> can you describe what you mean here by automatic restart for services?
>>>>
>>>> I'm worried what the implications would be for things that are
running
>>>> under Pacemaker control in an HA environment, so I think we need more
>>>> details here
>>>
>>> FWIW, this option is already enabled in some services, such as
>>> nova-api
>>>
(https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...)
>>> where Restart=always. I've checked a Juno deployment, and that option
>>> was already set back then.
>>
>> It shouldn´t affect pacemaker deployment, because we do override some of
>> those values via dbus config.
>
> To clarify things, doesn’t it affect just nova-api because you have some
> special treatment for the service? or it would not affect you if applied
> to other units? [In that case we could go forward and set automatic
> restart policy there, while you could stick to your hooks to influence
> service restart behaviour.]
all services in pacemaker that are managed/monitored via systemd gets a
set of overrides to avoid those kind of issues.
Then we should be safe to proceed with the feature.
Thanks,
Ihar
10:13 a.m.
Typically if you manage services with pacemaker, you would put the affected
service into unmanaged state before you run `yum update`, so that RPM can
do its thing. Afterwards, just mark the services managed.
On Thu, Nov 12, 2015 at 7:06 PM, Ihar Hrachyshka <ihrachys(a)redhat.com>
wrote:
Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
>
> On 11/12/2015 5:01 PM, Ihar Hrachyshka wrote:
>
>> Fabio M. Di Nitto <fdinitto(a)redhat.com> wrote:
>>
>> On 11/12/2015 4:55 PM, Javier Pena wrote:
>>>
>>>> ----- Original Message -----
>>>>
>>>>> On 11/12/2015 05:42 AM, Haïkel wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this has been discussed for a while, so I'd like to set
automatic
>>>>>> restart for OpenStack services as a goal for Mitaka - milestone
1.
>>>>>> These are easy fixes, and by setting it to milestone 1, we'll
have
>>>>>> more than enough time to test this and optimize.
>>>>>>
>>>>>> I already created a trello card to track that effort, but I'd
like to
>>>>>> get your feedback first.
>>>>>>
https://trello.com/c/HfXMLSTD/106-set-automatic-restart-for-service
>>>>>>
>>>>>
>>>>> can you describe what you mean here by automatic restart for
services?
>>>>>
>>>>> I'm worried what the implications would be for things that are
running
>>>>> under Pacemaker control in an HA environment, so I think we need
more
>>>>> details here
>>>>>
>>>>
>>>> FWIW, this option is already enabled in some services, such as
>>>> nova-api
>>>> (
>>>>
https://github.com/openstack-packages/nova/blob/rpm-master/openstack-nova...
>>>> )
>>>> where Restart=always. I've checked a Juno deployment, and that
option
>>>> was already set back then.
>>>>
>>>
>>> It shouldn´t affect pacemaker deployment, because we do override some of
>>> those values via dbus config.
>>>
>>
>> To clarify things, doesn’t it affect just nova-api because you have some
>> special treatment for the service? or it would not affect you if applied
>> to other units? [In that case we could go forward and set automatic
>> restart policy there, while you could stick to your hooks to influence
>> service restart behaviour.]
>>
>
> all services in pacemaker that are managed/monitored via systemd gets a
> set of overrides to avoid those kind of issues.
>
Then we should be safe to proceed with the feature.
Thanks,
Ihar
_______________________________________________
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
12:09 p.m.
New subject: [Rdo-list] Attempt to reproduce https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md
Working on this task I was able to build 3 node HAProxy/Keepalived Controller's
cluster , create compute node , launch CirrOS VM,
However, I cannot ping floating IP of VM running on compute ( total 4 CentOS 7.1 VMs,
nested kvm enabled )
Looks like provider external networks doesn't work for me.
But , to have eth0 without IP (due to `ovs-vsctl add-port br-eth0 eth0 ) still allowing to
ping 10.10.10.1,
I need NetworkManager active, rather then network.service
[root@hacontroller1 network-scripts]# systemctl status NetworkManager
NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
Active: active (running) since Fri 2015-11-13 20:39:21 MSK; 12min ago
Main PID: 808 (NetworkManager)
CGroup: /system.slice/NetworkManager.service
├─ 808 /usr/sbin/NetworkManager --no-daemon
└─2325 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
/var/run/dhclient-eth0...
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info>
NetworkManager state is n...L
Nov 13 20:39:22 hacontroller1.example.com dhclient[2325]: bound to 10.10.10.216 -- renewal
in 1...s.
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info> (eth0):
Activation: succe....
Nov 13 20:39:25 hacontroller1.example.com NetworkManager[808]: <info> startup
complete
[root@hacontroller1 network-scripts]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: inactive (dead)
[root@hacontroller1 network-scripts]# cat ifcfg-eth0
TYPE="Ethernet"
BOOTPROTO="static"
NAME="eth0"
DEVICE=eth0
ONBOOT="yes"
[root@hacontroller1 network-scripts]# ping -c 3 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=0.128 ms
64 bytes from 10.10.10.1: icmp_seq=3 ttl=64 time=0.117 ms
--- 10.10.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.087/0.110/0.128/0.021 ms
If I disable NetworkManager and enable network this feature will be lost. Eth0 would have
to have static IP or dhcp lease,
to provide route to 10.10.10.0/24.
Thank you.
Boris.
1:38 p.m.
New subject: [Rdo-list] Attempt to reproduce https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md
I understand that in usual situation , creating ifcfg-br-ex and ifcfg-eth2 ( as OVS bridge
and OVS port) ,
`service network restart` should be run to make eth2 (no IP) OVS port of br-ex (any IP
which belongs ext net and is available)
What bad does NetworkManager when external network provider is used ?
Disabling it, I break routing via eth0's interfaces of cluster nodes to 10.10.10.0/24
( ext net),
so nothing is supposed to work :-
http://blog.oddbit.com/2014/05/28/multiple-external-networks-wit/
http://dbaxps.blogspot.com/2015/10/multiple-external-networks-with-single...
Either I am missing something here.
________________________________________
From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com> on behalf of Boris
Derzhavets <bderzhavets(a)hotmail.com>
Sent: Friday, November 13, 2015 1:09 PM
To: Javier Pena
Cc: rdo-list(a)redhat.com
Subject: [Rdo-list] Attempt to reproduce
https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md
Working on this task I was able to build 3 node HAProxy/Keepalived Controller's
cluster , create compute node , launch CirrOS VM,
However, I cannot ping floating IP of VM running on compute ( total 4 CentOS 7.1 VMs,
nested kvm enabled )
Looks like provider external networks doesn't work for me.
But , to have eth0 without IP (due to `ovs-vsctl add-port br-eth0 eth0 ) still allowing to
ping 10.10.10.1,
I need NetworkManager active, rather then network.service
[root@hacontroller1 network-scripts]# systemctl status NetworkManager
NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
Active: active (running) since Fri 2015-11-13 20:39:21 MSK; 12min ago
Main PID: 808 (NetworkManager)
CGroup: /system.slice/NetworkManager.service
├─ 808 /usr/sbin/NetworkManager --no-daemon
└─2325 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
/var/run/dhclient-eth0...
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info>
NetworkManager state is n...L
Nov 13 20:39:22 hacontroller1.example.com dhclient[2325]: bound to 10.10.10.216 -- renewal
in 1...s.
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info> (eth0):
Activation: succe....
Nov 13 20:39:25 hacontroller1.example.com NetworkManager[808]: <info> startup
complete
[root@hacontroller1 network-scripts]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: inactive (dead)
[root@hacontroller1 network-scripts]# cat ifcfg-eth0
TYPE="Ethernet"
BOOTPROTO="static"
NAME="eth0"
DEVICE=eth0
ONBOOT="yes"
[root@hacontroller1 network-scripts]# ping -c 3 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=0.128 ms
64 bytes from 10.10.10.1: icmp_seq=3 ttl=64 time=0.117 ms
--- 10.10.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.087/0.110/0.128/0.021 ms
If I disable NetworkManager and enable network this feature will be lost. Eth0 would have
to have static IP or dhcp lease,
to provide route to 10.10.10.0/24.
Thank you.
Boris.
1:46 p.m.
New subject: [Rdo-list] Attempt to reproduce https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md
On 11/13/2015 11:38 AM, Boris Derzhavets wrote:
I understand that in usual situation , creating ifcfg-br-ex and
ifcfg-eth2 ( as OVS bridge and OVS port) ,
`service network restart` should be run to make eth2 (no IP) OVS port of br-ex (any IP
which belongs ext net and is available)
What bad does NetworkManager when external network provider is used ?
Disabling it, I break routing via eth0's interfaces of cluster nodes to
10.10.10.0/24 ( ext net),
so nothing is supposed to work :-
http://blog.oddbit.com/2014/05/28/multiple-external-networks-wit/
http://dbaxps.blogspot.com/2015/10/multiple-external-networks-with-single...
Either I am missing something here.
________________________________________
From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com> on behalf of Boris
Derzhavets <bderzhavets(a)hotmail.com>
Sent: Friday, November 13, 2015 1:09 PM
To: Javier Pena
Cc: rdo-list(a)redhat.com
Subject: [Rdo-list] Attempt to reproduce
https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md
Working on this task I was able to build 3 node HAProxy/Keepalived Controller's
cluster , create compute node , launch CirrOS VM,
However, I cannot ping floating IP of VM running on compute ( total 4 CentOS 7.1 VMs,
nested kvm enabled )
Looks like provider external networks doesn't work for me.
But , to have eth0 without IP (due to `ovs-vsctl add-port br-eth0 eth0 ) still allowing
to ping 10.10.10.1,
I need NetworkManager active, rather then network.service
[root@hacontroller1 network-scripts]# systemctl status NetworkManager
NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
Active: active (running) since Fri 2015-11-13 20:39:21 MSK; 12min ago
Main PID: 808 (NetworkManager)
CGroup: /system.slice/NetworkManager.service
├─ 808 /usr/sbin/NetworkManager --no-daemon
└─2325 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
/var/run/dhclient-eth0...
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info>
NetworkManager state is n...L
Nov 13 20:39:22 hacontroller1.example.com dhclient[2325]: bound to 10.10.10.216 --
renewal in 1...s.
Nov 13 20:39:22 hacontroller1.example.com NetworkManager[808]: <info> (eth0):
Activation: succe....
Nov 13 20:39:25 hacontroller1.example.com NetworkManager[808]: <info> startup
complete
[root@hacontroller1 network-scripts]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: inactive (dead)
[root@hacontroller1 network-scripts]# cat ifcfg-eth0
TYPE="Ethernet"
BOOTPROTO="static"
NAME="eth0"
DEVICE=eth0
ONBOOT="yes"
[root@hacontroller1 network-scripts]# ping -c 3 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=0.128 ms
64 bytes from 10.10.10.1: icmp_seq=3 ttl=64 time=0.117 ms
--- 10.10.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.087/0.110/0.128/0.021 ms
If I disable NetworkManager and enable network this feature will be lost. Eth0 would have
to have static IP or dhcp lease,
to provide route to 10.10.10.0/24.
Thank you.
Boris.
_______________________________________________
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
OK, a few things here. First of all, you don't actually need to have an
IP address on the host system to use a VLAN or interface as an external
provider network. The Neutron router will have an IP on the right
network, and within its namespace will be able to reach the 10.10.10.x
network.
It looks to me like NetworkManager is running dhclient for eth0, even
though you have BOOTPROTO="static". This is causing an IP address to be
added to eth0, so you are able to ping 10.10.10.x from the host. When
you turn off NetworkManager, this unexpected behavior goes away, *but
you should still be able to use provider networks*.
Try creating a Neutron router with an IP on 10.10.10.x, and then you
should be able to ping that network from the router namespace.
If you want to be able to ping 10.10.10.x from the host, then you
should put either a static IP or DHCP on the bridge, not on eth0. This
should work whether you are running NetworkManager or network.service.
--
Dan Sneddon | Principal OpenStack Engineer
dsneddon(a)redhat.com | redhat.com/openstack
650.254.4025 | dsneddon:irc @dxs:twitter
3088
days inactive
3089
days old
16 comments
9 participants
participants (9)
-
Alan Pevec -
Boris Derzhavets -
Dan Sneddon -
Fabio M. Di Nitto -
Haïkel -
Ihar Hrachyshka -
Javier Pena -
Matthew Mosesohn -
Perry Myers