On Fri, Jul 24, 2015 at 2:12 AM Evgeniy L 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 re
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 li
The problem is that hostnames of nodes appear in /etc/hosts files, and
entries in those files have to be unique to make any sense. Thus, we either
need to provide a user with ability to create their own generators of node
names (not sure that's makes sense), require a user to provide a name for
eve
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
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev 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 prov
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 wit
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'
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.
On Tue, Jul 21, 2015 at 5:38 AM Fedor Zhadaev wrote:
> Hi all,
>
> The next issue was found during implementation
> https://blueprints.launchpad.net/fuel/+spec/node-naming :
>
> User may change node hostname to any another, including default-like
> 'node-{№}', where № may be bigger than maximum
Hi Fedor,
> Use 'node-{ID}-{#}' format, where {#} we'll chose in loop till the first
> unique.
I don't like this approach by many reasons. Here's some of them:
* With a loop you're going to perform N SQL queries in order to check
for uniqueness, and that's a bad design and it'd be better to avo
Hi all,
The next issue was found during implementation
https://blueprints.launchpad.net/fuel/+spec/node-naming :
User may change node hostname to any another, including default-like
'node-{№}', where № may be bigger than maximum nodeID existing at that
moment.
Later when node with ID == № wil
11 matches
Mail list logo