Open Stack

Hi,

There was a discussion about the behaviour of "admin_state_up". You can
take a look at the following link:
https://bugs.launchpad.net/neutron/+bug/1237807

Changing admin_state_up from True to False will break dhcp. it will remove
dhcp service ports from the network but dhcp agent will be alive.

To see the difference between network's admin_state_up=True and
admin_state_up=False, you can run the following commands:

# neutron agent-list (write down dhcp_agent ID)
# neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command
when admin state True)
# neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command
when admin state False - wait a 1 min after you changed admin state from
True to False before running this command)

********** When admin state set to TRUE *******************
configurations  {
"subnets": 1,
"use_namespaces": true,
"dhcp_lease_duration": 86400,
"dhcp_driver": "neutron.agent.linux.dhcp.Dnsmasq",
"networks": 1,
"ports": 2
}

****** When admin state set to FALSE **********
configurations  {
"subnets": 0,
"use_namespaces": true,
"dhcp_lease_duration": 86400,
"dhcp_driver": "neutron.agent.linux.dhcp.Dnsmasq",
"networks": 0,
"ports": 0
}

Erhan,

On Tue, Jan 20, 2015 at 11:40 AM, Timur Nurlygayanov <
tnurlygayanov at mirantis.com> wrote:

> Hi Danny,
>
> I know that if we will set admin_state_up= false we will disable DHCP
> service for this network and new VMs will not get network settings by DHCP.
>
> On Wed, Dec 31, 2014 at 2:41 AM, Danny Choi (dannchoi) <dannchoi at cisco.com
> > wrote:
>
>>  Hi,
>>
>>  I have a VM with an interface attached to network “provider-net-1” and
>> assigned IP 66.0.0.8.
>>
>>  localadmin at qa4:~/devstack$ nova list
>>
>>
>> +--------------------------------------+------+--------+------------+-------------+--------------------------+
>>
>> | ID                                   | Name | Status | Task State |
>> Power State | Networks                 |
>>
>>
>> +--------------------------------------+------+--------+------------+-------------+--------------------------+
>>
>> | d4815a38-ea64-4189-95b2-fefe82a07b72 | vm-1 | ACTIVE | -          |
>> Running     | provider_net-1=66.0.0.8  |
>>
>>
>> +--------------------------------------+------+--------+------------+-------------+--------------------------+
>>
>>  Verify ping 66.0.0.8 from the router namespace is successful.
>>
>>  Then I set the admin_state_up = false for the network.
>>
>>  localadmin at qa4:~/devstack$ neutron net-update --admin_state_up=false
>> provider_net-1
>>
>> Updated network: provider_net-1
>>
>> localadmin at qa4:~/devstack$ neutron net-show provider_net-1
>>
>> +---------------------------+--------------------------------------+
>>
>> | Field                     | Value                                |
>>
>> +---------------------------+--------------------------------------+
>>
>> | admin_state_up            | False                                |
>>  <<<<<<<
>>
>> | id                        | 9532b759-68a2-4dc0-bcd4-b372fccabe3c |
>>
>> | name                      | provider_net-1                       |
>>
>> | provider:network_type     | vlan                                 |
>>
>> | provider:physical_network | physnet1                             |
>>
>> | provider:segmentation_id  | 399                                  |
>>
>> | router:external           | False                                |
>>
>> | shared                    | False                                |
>>
>> | status                    | ACTIVE                               |
>>
>> | subnets                   | 8e75c110-9b31-4268-ba5c-e130fa139d32 |
>>
>> | tenant_id                 | e217fbc20a3b4f4fab49ec580e9b6a15     |
>>
>> +---------------------------+--------------------------------------+
>>
>>  Afterwards, the ping is still successful.
>>
>>  I expect the ping to fail since the network admin_state_up= false.
>>
>>  What is the expected behavior?  What does it mean when a network's
>> admin_state_up = false?
>>
>>  Thanks,
>> Danny
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Timur,
> Senior QA Engineer
> OpenStack Projects
> Mirantis Inc
>
> My OpenStack summit schedule:
> http://kilodesignsummit.sched.org/timur.nurlygayanov#.VFSrD8mhhOI
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150120/64be55e2/attachment.html>