Re: [Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

Unfortunately Neutron doesn't know anything about the hypervisor to make
that type of call. That will require support in Nova to listen for the port
admin state change from Neutron and reflect it in the loaded hypervisor.

It's worth filing a request with Nova to see if that's something they would
accept.

Nova already listens for port data plane status to unpause the VM on boot
so that communication channel is already in place.

On Aug 11, 2017 01:21, "Volodymyr Litovka"  wrote:

>
> On 8/8/17 7:18 PM, Kevin Benton wrote:
>
> The best way to completely ensure the instance isn't trying to use it is
> to detach it from the instance using the 'nova interface-detach' command.
>
> Sure, but this introduces additional complexity in complex environments
> when it's required to have predictable interface naming accordingly to
> roles (e.g. eth0 is always WAN connection, eth1 is always LAN1, eth2 is
> always control/mgmt, etc etc). Attaching/detaching interfaces changes this
> and requires to manage udev rules, which adds issues when creating new VM
> from snapshot, ... :-)
>
> Not too critical, everything can be handled using more or less complex
> workarounds, but, since libvirt has support to set interface state (using 
> '*virsh
> domif-setlink domain interface-device state*'), why don't use this call
> to reflect interface state according to Openstack's settings?
>
> Thanks.
>
>
> On Tue, Aug 8, 2017 at 7:49 AM, Volodymyr Litovka  wrote:
>
>> Hi Kevin,
>> see below
>>
>> On 8/8/17 1:06 AM, Kevin Benton wrote:
>>
>> What backend are you using? That bug is about the port showing ACTIVE
>> when admin_state_up=False but it's still being disconnected from the
>> dataplane. If you are seeing dataplane traffic with admin_state_up=False,
>> then that is a separate bug.
>>
>> I'm using OVS
>>
>> Also, keep in mind that marking the port down will still not be reflected
>> inside of the VM via ifconfig or ethtool. It will always show active in
>> there. So even after we fix bug 1672629, you are going to see the port is
>> connected inside of the VM.
>>
>> Is there way to disconnect port, thus putting it into DOWN state on VM,
>> using Openstack API ? This is important for *public clouds* when it can
>> be necessary to shutdown port of unmanaged (customer's) VM. The only idea I
>> have is to set admin_state_up to False and, actually, it's the only
>> command, which control port state.
>>
>> As I mentioned earlier, it seems it was working in Kilo ("I have checked
>> the behavior of admin_state_up of Kilo version, when port admin-state-up is
>> set to False, the port status will be DOWN.") but Ocata shows another
>> behaviour, ignoring this parameter.
>>
>> So, any ideas on how to shutdown port on VM using Openstack API?
>>
>> Thank you!
>>
>>
>> On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka 
>> wrote:
>>
>>> Hi colleagues,
>>>
>>> am I the only who care about this case? - https://bugs.launchpad.net/neu
>>> tron/+bug/1672629
>>>
>>> The problem is when I set port admin_state_up to False, it still UP on
>>> the VM thus continuing to route statically configured networks (e.g.
>>> received from DHCP host_routes), sending DHCP reqs, etc
>>>
>>> As people discovered, in Kilo everything was ok - "I have checked the
>>> behavior of admin_state_up of Kilo version, when port admin-state-up is set
>>> to False, the port status will be DOWN." - but at least in Ocata it is
>>> broken.
>>>
>>> Anybody facing this problem too? Any ideas on how to work around it?
>>>
>>> Thank you.
>>>
>>> --
>>> Volodymyr Litovka
>>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>> --
>> Volodymyr Litovka
>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Volodymyr Litovka]

On 8/8/17 7:18 PM, Kevin Benton wrote:

The best way to completely ensure the instance isn't trying to use it 
is to detach it from the instance using the 'nova interface-detach' 
command.
Sure, but this introduces additional complexity in complex environments 
when it's required to have predictable interface naming accordingly to 
roles (e.g. eth0 is always WAN connection, eth1 is always LAN1, eth2 is 
always control/mgmt, etc etc). Attaching/detaching interfaces changes 
this and requires to manage udev rules, which adds issues when creating 
new VM from snapshot, ... :-)


Not too critical, everything can be handled using more or less complex 
workarounds, but, since libvirt has support to set interface state 
(using '*virsh domif-setlink domain interface-device state*'), why don't 
use this call to reflect interface state according to Openstack's settings?


Thanks.


On Tue, Aug 8, 2017 at 7:49 AM, Volodymyr Litovka > wrote:


Hi Kevin,

see below

On 8/8/17 1:06 AM, Kevin Benton wrote:

What backend are you using? That bug is about the port showing
ACTIVE when admin_state_up=False but it's still being
disconnected from the dataplane. If you are seeing dataplane
traffic with admin_state_up=False, then that is a separate bug.

I'm using OVS

Also, keep in mind that marking the port down will still not be
reflected inside of the VM via ifconfig or ethtool. It will
always show active in there. So even after we fix bug 1672629,
you are going to see the port is connected inside of the VM.

Is there way to disconnect port, thus putting it into DOWN state
on VM, using Openstack API ? This is important for *public clouds*
when it can be necessary to shutdown port of unmanaged
(customer's) VM. The only idea I have is to set admin_state_up to
False and, actually, it's the only command, which control port state.

As I mentioned earlier, it seems it was working in Kilo ("I have
checked the behavior of admin_state_up of Kilo version, when port
admin-state-up is set to False, the port status will be DOWN.")
but Ocata shows another behaviour, ignoring this parameter.

So, any ideas on how to shutdown port on VM using Openstack API?

Thank you!


On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka
> wrote:

Hi colleagues,

am I the only who care about this case? -
https://bugs.launchpad.net/neutron/+bug/1672629


The problem is when I set port admin_state_up to False, it
still UP on the VM thus continuing to route statically
configured networks (e.g. received from DHCP host_routes),
sending DHCP reqs, etc

As people discovered, in Kilo everything was ok - "I have
checked the behavior of admin_state_up of Kilo version, when
port admin-state-up is set to False, the port status will be
DOWN." - but at least in Ocata it is broken.

Anybody facing this problem too? Any ideas on how to work
around it?

Thank you.

-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators






-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison




--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

Once that bug is fixed, the port status will show DOWN in the Neutron API,
but that doesn't affect how it appears inside of the instance.

The best way to completely ensure the instance isn't trying to use it is to
detach it from the instance using the 'nova interface-detach' command.

On Tue, Aug 8, 2017 at 7:49 AM, Volodymyr Litovka  wrote:

> Hi Kevin,
> see below
>
> On 8/8/17 1:06 AM, Kevin Benton wrote:
>
> What backend are you using? That bug is about the port showing ACTIVE when
> admin_state_up=False but it's still being disconnected from the dataplane.
> If you are seeing dataplane traffic with admin_state_up=False, then that is
> a separate bug.
>
> I'm using OVS
>
> Also, keep in mind that marking the port down will still not be reflected
> inside of the VM via ifconfig or ethtool. It will always show active in
> there. So even after we fix bug 1672629, you are going to see the port is
> connected inside of the VM.
>
> Is there way to disconnect port, thus putting it into DOWN state on VM,
> using Openstack API ? This is important for *public clouds* when it can
> be necessary to shutdown port of unmanaged (customer's) VM. The only idea I
> have is to set admin_state_up to False and, actually, it's the only
> command, which control port state.
>
> As I mentioned earlier, it seems it was working in Kilo ("I have checked
> the behavior of admin_state_up of Kilo version, when port admin-state-up is
> set to False, the port status will be DOWN.") but Ocata shows another
> behaviour, ignoring this parameter.
>
> So, any ideas on how to shutdown port on VM using Openstack API?
>
> Thank you!
>
>
> On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka  wrote:
>
>> Hi colleagues,
>>
>> am I the only who care about this case? - https://bugs.launchpad.net/neu
>> tron/+bug/1672629
>>
>> The problem is when I set port admin_state_up to False, it still UP on
>> the VM thus continuing to route statically configured networks (e.g.
>> received from DHCP host_routes), sending DHCP reqs, etc
>>
>> As people discovered, in Kilo everything was ok - "I have checked the
>> behavior of admin_state_up of Kilo version, when port admin-state-up is set
>> to False, the port status will be DOWN." - but at least in Ocata it is
>> broken.
>>
>> Anybody facing this problem too? Any ideas on how to work around it?
>>
>> Thank you.
>>
>> --
>> Volodymyr Litovka
>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Volodymyr Litovka]

Hi Kevin,

see below

On 8/8/17 1:06 AM, Kevin Benton wrote:
What backend are you using? That bug is about the port showing ACTIVE 
when admin_state_up=False but it's still being disconnected from the 
dataplane. If you are seeing dataplane traffic with 
admin_state_up=False, then that is a separate bug.

I'm using OVS
Also, keep in mind that marking the port down will still not be 
reflected inside of the VM via ifconfig or ethtool. It will always 
show active in there. So even after we fix bug 1672629, you are going 
to see the port is connected inside of the VM.
Is there way to disconnect port, thus putting it into DOWN state on VM, 
using Openstack API ? This is important for *public clouds* when it can 
be necessary to shutdown port of unmanaged (customer's) VM. The only 
idea I have is to set admin_state_up to False and, actually, it's the 
only command, which control port state.


As I mentioned earlier, it seems it was working in Kilo ("I have checked 
the behavior of admin_state_up of Kilo version, when port admin-state-up 
is set to False, the port status will be DOWN.") but Ocata shows another 
behaviour, ignoring this parameter.


So, any ideas on how to shutdown port on VM using Openstack API?

Thank you!


On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka > wrote:


Hi colleagues,

am I the only who care about this case? -
https://bugs.launchpad.net/neutron/+bug/1672629


The problem is when I set port admin_state_up to False, it still
UP on the VM thus continuing to route statically configured
networks (e.g. received from DHCP host_routes), sending DHCP reqs, etc

As people discovered, in Kilo everything was ok - "I have checked
the behavior of admin_state_up of Kilo version, when port
admin-state-up is set to False, the port status will be DOWN." -
but at least in Ocata it is broken.

Anybody facing this problem too? Any ideas on how to work around it?

Thank you.

-- 
Volodymyr Litovka

   "Vision without Execution is Hallucination." -- Thomas Edison


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Kevin Benton]

What backend are you using? That bug is about the port showing ACTIVE when
admin_state_up=False but it's still being disconnected from the dataplane.
If you are seeing dataplane traffic with admin_state_up=False, then that is
a separate bug.

Also, keep in mind that marking the port down will still not be reflected
inside of the VM via ifconfig or ethtool. It will always show active in
there. So even after we fix bug 1672629, you are going to see the port is
connected inside of the VM.

On Mon, Aug 7, 2017 at 5:21 AM, Volodymyr Litovka  wrote:

> Hi colleagues,
>
> am I the only who care about this case? - https://bugs.launchpad.net/
> neutron/+bug/1672629
>
> The problem is when I set port admin_state_up to False, it still UP on the
> VM thus continuing to route statically configured networks (e.g. received
> from DHCP host_routes), sending DHCP reqs, etc
>
> As people discovered, in Kilo everything was ok - "I have checked the
> behavior of admin_state_up of Kilo version, when port admin-state-up is set
> to False, the port status will be DOWN." - but at least in Ocata it is
> broken.
>
> Anybody facing this problem too? Any ideas on how to work around it?
>
> Thank you.
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] port state is UP when admin-state-up is False (neutron/+bug/1672629)

[Volodymyr Litovka]

Hi colleagues,

am I the only who care about this case? - 
https://bugs.launchpad.net/neutron/+bug/1672629


The problem is when I set port admin_state_up to False, it still UP on 
the VM thus continuing to route statically configured networks (e.g. 
received from DHCP host_routes), sending DHCP reqs, etc


As people discovered, in Kilo everything was ok - "I have checked the 
behavior of admin_state_up of Kilo version, when port admin-state-up is 
set to False, the port status will be DOWN." - but at least in Ocata it 
is broken.


Anybody facing this problem too? Any ideas on how to work around it?

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators