fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

wow, its interesting to know that the L3 isn't tested, in the verify
networks task. That is probably part of the problem i'm seeing and IMHO is
more important to verify than the VLAN range. We don't currently track
gateways, so at the moment we don't know who we can ping during the
pre-deployment checks.

however my idea is to also add a clause in puppet to force it to fail if it
can ping the primary controller, this will cause nodes after the first
controller to fail more rapidly (right after or during exec of l23networks
code there are already ping hooks there too) this will help spot nodes with
errors for which proceeding further is useless anyways.

now with the research we've been doing for multiple L3/L2 domains, we will
have to know gateways for each network, so we will have those available to
ping in cases that multi-l3 is used.

Andrew


On Fri, Jan 24, 2014 at 5:30 AM, Miroslav Anashkin
<manashkin@xxxxxxxxxxxx>wrote:

> 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 <%2B7%28495%29640-4944> (office receptionist)*
> *+1(650)587-5200 <%2B1%28650%29587-5200> (office receptionist, call from
> US)*
> *35b, Bld. 3, Vorontsovskaya St.*
> *Moscow**, Russia, 109147.*
>
> www.mirantis.com
>
> manashkin@xxxxxxxxxxxx
>
>
> --
> 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
>
>


-- 
If google has done it, Google did it right!