Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
every node and validate that every name is unique (which I guess the
blueprint in question implies), or provide ability to generate node
hostname by some user-defined template (prefix) suffixed with ID-based
iterator. We should choose one of options for every environment and don't
mix them, as Fedor pointed out.
-Oleg
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:
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
On Fri, Jul 24, 2015 at 2:12 AM 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.
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 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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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.
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
On Tue, Jul 21, 2015 at 5:38 AM Fedor Zhadaev fzhad...@mirantis.com 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 nodeID existing at that
moment.
Later when node with ID == № will be created it's default name
'node-{ID}' will break hostnames uniqueness.
To avoid this now it was decided to generate in such situation another
default hostname.
The current solution is to generate hostname '*node-{UUID}*'. It works,
but may look terribly.
There are a few another possible solutions:
- Use '*node-{ID}-{#}*' format, where *{#} *we'll chose in loop till
the first unique.
- Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
I think the only solution here is to a) ensure that every hostname is
unique or refuse to update the value b)In cases that the user wants to use
our format, the only allowed format is node-{ID} where ID must be equal to
this nodes ID. we don't need to come up with some scheme to rescue the
format. We do however need some value/method that will make it reset back
to the default.
Please share you opinion - what is better?
Also you can propose your own solutions.
--
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
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 avoid
it.
* What if user wants to use exactly the same schema? For instance, he
use the first number as a rack id and the second one as a node id in
this rack. The proposed approach will implicitly set some wrong
hostname, and detecting it may be a challenge.
Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
Usually, it's incredibly rare situation, so solving it by adding UUID
is a more than enough. Moreover, it will take attention of the cloud
operator, so he will easily detect a conflicting node and fix its name
as he wishes. And that's probable what he wants to do almost all the
time - to fix its hostname, none want to work with names like: node-1,
node-2, node-2-2, node-3, because what is the node-2-2? Does it store
some backup or what? It confuses.
So, I think current approach - node-UUID - is the way we should do.
Thanks,
Igor
On Tue, Jul 21, 2015 at 3:38 PM, Fedor Zhadaev fzhad...@mirantis.com 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 nodeID existing at that
moment.
Later when node with ID == № will be created it's default name 'node-{ID}'
will break hostnames uniqueness.
To avoid this now it was decided to generate in such situation another
default hostname.
The current solution is to generate hostname 'node-{UUID}'. It works, but
may look terribly.
There are a few another possible solutions:
Use 'node-{ID}-{#}' format, where {#} we'll chose in loop till the first
unique.
Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
Please share you opinion - what is better?
Also you can propose your own solutions.
--
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
__
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-dev] [Fuel] Question about unique default hostname for node
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 == № will be created it's default name
'node-{ID}' will break hostnames uniqueness.
To avoid this now it was decided to generate in such situation another
default hostname.
The current solution is to generate hostname '*node-{UUID}*'. It works, but
may look terribly.
There are a few another possible solutions:
- Use '*node-{ID}-{#}*' format, where *{#} *we'll chose in loop till the
first unique.
- Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
Please share you opinion - what is better?
Also you can propose your own solutions.
--
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
