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 <e...@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 <xar...@gmail.com> wrote: > >> >> >> On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev <fzhad...@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 <ikalnit...@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 >>>> <sgolovat...@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-requ...@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-requ...@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: fzhad...@mirantis.com >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
