Open Stack

Evgeniy,

The replacement node use case seems significantly different from node
renaming
case to me. It's not only about the hostname of the node. I guess that
eventually
we'll have to invent a way to retain other metadata of the original node,
not only
a hostname. The described use case is more like 'node reinstallation'
feautre [1].

[1] https://blueprints.launchpad.net/fuel/+spec/mos-node-reinstallation

--
Best regards,
Oleg Gelbukh

On Fri, Jul 24, 2015 at 12:07 PM, 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/368cb2ac/attachment.html>