fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

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!