fuel-dev team mailing list archive

[Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>]

May be we should assume reusage of neutron somehow as our network manager,
thus it will allow us to configure switches and overlapping internal
networks easily, leaving public addresses not overlapping.


On Fri, Mar 7, 2014 at 11:34 AM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> Just saw this thread, so I'll re-iterate what went into the review.
>
> This is absolutely not what we want do. This will make it easy for users
>> to deploy multiple clouds with conflicting networking information. There is
>> no use case where a user will ever want to deploy duplicate public
>> addresses.
>>
>
>
>> There are a small set of cases where I could envision a user deploying
>> duplicate storage and management ranges but, there is almost no chance for
>> them to be managed by the same fuel server. Even in these cases, additional
>> attributes need to be established to ensure that the networks are in-fact
>> separate such as vlan-tag or positive assertion from the user that this is
>> desired.
>>
>
>
>> As the patch currently stands it should not be accepted as it creates
>> unnecessary risk that we are currently preventing.
>
>
> That said, putting in some proper controls may be acceptable, as noted
> above, however the behavior should not be warn, it should block until
> confirmed, enabled and forced by the user. Regardless I'd like to
> understand some user cases where this is actually a need to support instead
> of a problem waiting to happen.
>
> As to Andrey's bug case, it will be addressed with
> multiple-cluster-networks [1] which will remove the association of the
> network directly to the cluster, as laid out and specified in
> multiple-cluster-networks it would be further difficult to create duplicate
> networks as nodes would associate with networks based on their relation to
> the fuelweb_admin network and the NodeGroup that ties them together. In
> this case it would require manually changing the nodes NodeGroup
> association.
>
> [1] https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks
>
>
> On Thu, Mar 6, 2014 at 9:47 AM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>wrote:
>
>> I also agree, warning would be great. We need to design where warning
>> should be though.
>>
>>
>> On Thu, Mar 6, 2014 at 7:59 PM, Aleksey Kasatkin <akasatkin@xxxxxxxxxxxx>wrote:
>>
>>> Agree to allow IP overlapping and warn the user when it take place.
>>> We planned to add corresponding verification also (not for this case
>>> only): https://bugs.launchpad.net/fuel/+bug/1275641
>>>
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>> S. Software Developer | Mirantis, Inc. | http://www.mirantis.com
>>> cell: +380938330852 | skype: alexeyk_ru
>>>
>>>
>>> On Thu, Mar 6, 2014 at 5:49 PM, Andrey Danin <adanin@xxxxxxxxxxxx>wrote:
>>>
>>>> Hi, folks.
>>>> We have a hot discussion in comments here:
>>>> https://review.openstack.org/#/c/78232/
>>>> Now we silently allow to deploy clusters with same VLANs and networks,
>>>> but an IP assignment mechanism in Nailgun doesn't allow to duplicate IPs
>>>> for two nodes in different clusters. I filed a bug about it:
>>>> https://bugs.launchpad.net/fuel/+bug/1287021 I think we have wrong
>>>> behaviur now, but also I understand Andrew's concern.
>>>> I think the best way to fix the problem is to allow IP overlapping but
>>>> warn a user before deployment if there are overlapped VLANs, networks or
>>>> IPs with other clusters.
>>>>
>>>> What do you think?
>>>>
>>>> --
>>>> Andrey Danin
>>>> adanin@xxxxxxxxxxxx
>>>> skype: gcon.monolake
>>>>
>>>> --
>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> If google has done it, Google did it right!
>
> --
> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Senior Deployment Engineer,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin@xxxxxxxxxxxx