fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00327
Re: network verification (use case)
My 5c.
1. Full network verification may take hours in case there are hundreds of
VLANs configured. So, to avoid timeouts, divide the verification process
into smaller batches. Make timeout configurable - as I remember Cyan case,
their timeouts were 1+ minute to start up and calibrate connection for each
optical NIC.
2. Network verification is fully independent feature and even not mandatory
- so, make it background process. Let it show the current verification
progress and report errors as soon as it get some.
3. Add feature to allow network verification against selected node or
interface - with priority over common background verification. Make the
green/gray/red network port icon a button.
4. 95% of network misconfiguration errors can be found on single node
verification. Let us check network settings against single node first.
Kind regards,
Miroslav
On Fri, Jan 24, 2014 at 2:56 PM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx>wrote:
> Network verification will fail, if any required interfaces are down.
>
> Let's discuss here first any improvements we could do for this feature,
> before creating the blueprint. I'm all in for finding out what we can do
> better here, as network issues looks to be the most frequent thing which
> happens in real deployments.
>
>
> On Fri, Jan 24, 2014 at 1:06 PM, Andrey Danin <adanin@xxxxxxxxxxxx> wrote:
>
>> Gleb, to get interfaces' states from DB you can do this:
>>> http://paste.openstack.org/show/61805/
>>>
>>>
>>> On Fri, Jan 24, 2014 at 4:30 AM, Roman Alekseenkov <
>>> ralekseenkov@xxxxxxxxxxxx> wrote:
>>>
>>>> Gleb - thanks for bringing this up. I like the proposal, actually.
>>>> Whatever makes the life of deployment engineers easier...
>>>>
>>>> Evgeny - the thing you mentioned cannot be a full solution for two
>>>> reasons. The first is scale (nobody will click on each node to check the
>>>> status of its NICs), the second is mass configuration (people are likely to
>>>> configure NICs for multiple nodes at once and again won't go into
>>>> individual nodes). You can imagine how bad it's going to be with 100+
>>>> nodes...
>>>>
>>>> Andrew Woodward and Alex Shaposhnikov also have some specific
>>>> suggestions on how to improve network verification and make it more
>>>> meaningful. Guys - please speak up.
>>>>
>>>> I'd like to see a consolidated blueprint on launchpad from you guys
>>>> (Gleb, Andrew, and Alex), which David and I can take and prioritize.
>>>>
>>>> Thanks,
>>>> Roman
>>>>
>>>>
>>>> On Thu, Jan 23, 2014 at 7:50 AM, Mike Scherbakov <
>>>> mscherbakov@xxxxxxxxxxxx> wrote:
>>>>
>>>>> Our verify network feature (activated by corresponding button on
>>>>> networks tab) verifies L2 connectivity of OpenStack networks. It configures
>>>>> desired networking on bootstrap nodes, and runs UDP packets on required
>>>>> interfaces.
>>>>> We also check for unwanted DHCP traffic. There are no checks on L3
>>>>> layer at the moment.
>>>>>
>>>>> Thanks,
>>>>> On Jan 23, 2014 7:10 PM, "Evgeniy L" <eli@xxxxxxxxxxxx> wrote:
>>>>>
>>>>>> Hi Gleb,
>>>>>>
>>>>>> Regarding state of interfaces, we have such feature right now.
>>>>>> It was merged and should be available in 4.0 release
>>>>>>
>>>>>> https://github.com/stackforge/fuel-web/commit/0e60ff862d75d8d2ef37d2b0f8d834260f8349b6
>>>>>>
>>>>>> But as far as I know it doesn't work correctly in virtual box.
>>>>>>
>>>>>> [image: Inline image 2]
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 23, 2014 at 12:05 PM, Gleb Galkin <ggalkin@xxxxxxxxxxxx>wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello, all
>>>>>>>
>>>>>>> Right now I have a bunch of nodes and each has 4 network interfaces.
>>>>>>> How can I check that every interface on every node is UP,
>>>>>>> that all switch ports are configured properly and there are no
>>>>>>> connectivity problem?
>>>>>>>
>>>>>>> We have network verification in GUI but it can't provide me with
>>>>>>> detail information about all network issues, can it?
>>>>>>> I'd like to got detail information like
>>>>>>>
>>>>>>> on the node number X interface eth2 (xx:xx:xx:xx:xx:xx) has link
>>>>>>> status 'down'.
>>>>>>> or
>>>>>>> on the node number X interface eth3 (xx:xx:xx:xx:xx:xx) is up but it
>>>>>>> can't ping fuel node
>>>>>>>
>>>>>>> and so on
>>>>>>>
>>>>>>> It's good to have this information BEFORE you press Deploy button.
>>>>>>>
>>>>>>> Maybe we already have something like this? Maybe our network
>>>>>>> verification write some report about the network issues?
>>>>>>>
>>>>>>> If we don't have this feature we should consider it. It'll save a
>>>>>>> lot of time for deployers.
>>>>>>> We can use mcollective to up all network interfaces on all nodes and
>>>>>>> make arping the fuel node or something.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Gleb Galkin
>>>>>>> OpenStack Deployment Engineer
>>>>>>>
>>>>>>> Mirantis Inc.
>>>>>>> www.mirantis.com
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>>>>> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>>>> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>>> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrey Danin
>>> adanin@xxxxxxxxxxxx
>>> skype: gcon.monolake
>>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help : https://help.launchpad.net/ListHelp
>
>
--
*Kind Regards*
*Miroslav Anashkin**L2 support engineer**,*
*Mirantis Inc.*
*+7(495)640-4944 (office receptionist)*
*+1(650)587-5200 (office receptionist, call from US)*
*35b, Bld. 3, Vorontsovskaya St.*
*Moscow**, Russia, 109147.*
www.mirantis.com
manashkin@xxxxxxxxxxxx
Follow ups
References