Open Stack

On Fri, Jul 24, 2015 at 2:12 AM Evgeniy L <eli at mirantis.com> wrote:

> Hi Andrew,
>
> I don't agree with you, user should be able to name the node any way he
> wants why there should be a constraint which is related to some internal id
> in Nailgun database? For example if he deleted node-5 and then he wants
> to replace this node with another one, he can and should be able to provide
> for this replacement node hostname node-5, even if node's id in the
> database
> is 6.
>

No, its easier to just change the node id in the database to 5 if that is
what they want. We own the namespace 'node-<node.id>' schema. If they want
to use that schema then they have to update node.id in the database. We
have multiple areas in the code where we do special things based on the ID
of the node (like primary member of role). If they wanted to replace the
node and get the old host-name back then there is a very high chance that
the expect it to continue to have these special functions applied to them

I don't know why we want to create a custom conflict resolution scheme here
when we can reasonably say its not allowed.

There are things we have to check now which increases the complication when
we allow this.

A) As a pre-requisite to setting any hostname, we must now generate all of
the hostnames so that we can check if there is a node-<node.id> conflict.
B) After (A) and we find that there are no conflicts we can now set the
host name
C) New node is added to the cluster with id that now conflicts with the
node.id format for this name (higher or lower is possible) how do we want
to generate new nodes hostname. We dont want to fail the deployment because
of it so we have to resort to some weird naming scheme like discussed here.
But what happens if user doesn't want that ugly name if we do this
automatically then they could end up with some ugly name that they then
have to erase the node before they can change.

Seems like a waste of time to me. We can avoid this all by simply asking
the user to change the node.id in the database so that this complicated
stuff can be avoided


>
Thanks,
>
> On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward <xarses at gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev <fzhadaev at mirantis.com>
>> wrote:
>>
>>> Thanks for your answers.
>>>
>>> Let me clarify some points:
>>>
>>> Sure, we have to validate hostnames during node renaming. And sure we do
>>> it. This issue appears when we already have node with name 'node-X' and new
>>> node is created without providing custom name. I'll give you the example:
>>>
>>> 1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
>>> with ID > 4) ;
>>> 2. He renames it in 'node-5' (this name is correct and unique. OK)
>>> 3. He adds new node without providing custom hostname.
>>>     New node gets ID = 5 (it's primary key and increments automatically)
>>> and default hostname 'node-5'. (Here we have a problem with uniqueness.)
>>>
>>> It will be strange if we refuse to create node with default name if
>>> somebody has renamed another node using this name.
>>>
>>> About nodes hostnames. Actually we can't refuse to use custom hostnames
>>> in format 'node-{#}' because it is one of the main use cases. So we need to
>>> find the solution which accepts such renaming.
>>>
>> How is this a main use case? This is exactly what we should not support.
>> If they want the node to have 'node-5' as it's hostname we need them to be
>> node.id = 5 (IE the node id in the DB is 5) They would not need custom
>> node naming in this case.
>>
>>>
>>> 2015-07-22 12:42 GMT+03:00 Igor Kalnitsky <ikalnitsky at mirantis.com>:
>>>
>>>> Hi guys,
>>>>
>>>> @Sergii, it looks like you misunderstood something. `node-uuid` is not
>>>> a general use case. It's only about conflicting nodes, and I'm sure
>>>> everyone's going to change such a hostname in order to avoid
>>>> confusion.
>>>>
>>>> @Andrew,
>>>>
>>>> a) Database refuses hostnames that break unique constraint, sot it'll
>>>> work out-of-box.
>>>>
>>>> b) I like this idea. I think refusing `node-id` where `id` is not
>>>> actually a node id is good idea. It solves our problem.
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
>>>> <sgolovatiuk at mirantis.com> wrote:
>>>> > node-uuid is very terrible from UX perspective of view. Ask support
>>>> people
>>>> > if they are comfortable to ssh such nodes or telling the name in phone
>>>> > conversation with customer. If we cannot validate FQDN of hostname I
>>>> would
>>>> > slip this feature to next release where we can pay more attention to
>>>> > details.
>>>> >
>>>> > --
>>>> > Best regards,
>>>> > Sergii Golovatiuk,
>>>> > Skype #golserge
>>>> > IRC #holser
>>>> >
>>>> >
>>>> __________________________________________________________________________
>>>> > 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
>>>> >
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Kind Regards,
>>> Fedor Zhadaev
>>> Junior Software Engineer, Mirantis Inc.
>>> Skype: zhadaevfm
>>> E-mail: fzhadaev at mirantis.com
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>> --
>>
>> --
>>
>> Andrew Woodward
>>
>> Mirantis
>>
>> Fuel Community Ambassador
>>
>> Ceph Community
>>
>> __________________________________________________________________________
>> 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
>>
>>
> __________________________________________________________________________
> 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/4f560081/attachment.html>