Re: [openstack-dev] [Fuel] network_metadata hash keys on astute.yaml

2016-03-15 Thread Sergey Vasilenko 
Keys should be immutable.

If keys are not immutable -- it can lead to the situation, when
network_metadata/nodes contains two records for same nodes (with same UID),
but with different information.

/sv
__
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] network_metadata hash keys on astute.yaml

2016-03-15 Thread Aleksey Kasatkin 
Hi,

I'm agree with Alex, keys should remain immutable. 'node-{uid}' is Okay, we
have a method for this in Nailgun already. It should be a very simple fix
in Nailgun.

Thanks,


Aleksey Kasatkin


On Tue, Mar 15, 2016 at 3:19 PM, Kyrylo Galanov 
wrote:

> Hi,
>
> I would like to remind that we are close to code freeze and bug is still
> there. Moreover, new bug reports continue to be submitted [3].
> Please, do not ignore the discussion.
>
> [3] https://bugs.launchpad.net/fuel/+bug/1557417
>
> On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko  > wrote:
>
>> Hi,
>>
>> some additional info on the problem: if I create some Hiera override for
>> the nodes list and use node key which is hostname bond, then after node
>> rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
>> override will create a "ghost" node in the list and will not change
>> settings I wanted to change. So node keys in that hash should remain
>> immutable.
>>
>> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
>> was working before (and does not require new patches like [0]) and we're
>> too late in the release cycle to change keys to '{uid}'.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/284046/
>>
>> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
>> wrote:
>>
>>> Hi,
>>>
>>> Currently nailgun and puppet process network_metadata hash slightly
>>> different.
>>> Nailgun uses short hostname as a hash key for each node, while library
>>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>>> deployment failure.
>>>
>>> During code review[0] it turned out that there are two points of view,
>>> which approach is correct [1].
>>> Both are one-line fixes, however it have been lasting too long with no
>>> result.
>>>
>>> I would like to start a discussion with a hope to close the issue
>>> shortly.
>>>
>>> Best regards.
>>> Kyrylo
>>>
>>> [0] https://review.openstack.org/#/c/284046/
>>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>>
>>>
>>> __
>>> 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
>
>
__
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] network_metadata hash keys on astute.yaml

2016-03-15 Thread Kyrylo Galanov 
Hi,

I would like to remind that we are close to code freeze and bug is still
there. Moreover, new bug reports continue to be submitted [3].
Please, do not ignore the discussion.

[3] https://bugs.launchpad.net/fuel/+bug/1557417

On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko 
wrote:

> Hi,
>
> some additional info on the problem: if I create some Hiera override for
> the nodes list and use node key which is hostname bond, then after node
> rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
> override will create a "ghost" node in the list and will not change
> settings I wanted to change. So node keys in that hash should remain
> immutable.
>
> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
> was working before (and does not require new patches like [0]) and we're
> too late in the release cycle to change keys to '{uid}'.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/284046/
>
> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
> wrote:
>
>> Hi,
>>
>> Currently nailgun and puppet process network_metadata hash slightly
>> different.
>> Nailgun uses short hostname as a hash key for each node, while library
>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>> deployment failure.
>>
>> During code review[0] it turned out that there are two points of view,
>> which approach is correct [1].
>> Both are one-line fixes, however it have been lasting too long with no
>> result.
>>
>> I would like to start a discussion with a hope to close the issue shortly.
>>
>> Best regards.
>> Kyrylo
>>
>> [0] https://review.openstack.org/#/c/284046/
>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>
>> __
>> 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

Re: [openstack-dev] [Fuel] network_metadata hash keys on astute.yaml

2016-03-15 Thread Aleksandr Didenko 
Hi,

some additional info on the problem: if I create some Hiera override for
the nodes list and use node key which is hostname bond, then after node
rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
override will create a "ghost" node in the list and will not change
settings I wanted to change. So node keys in that hash should remain
immutable.

Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it was
working before (and does not require new patches like [0]) and we're too
late in the release cycle to change keys to '{uid}'.

Regards,
Alex

[0] https://review.openstack.org/#/c/284046/

On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
wrote:

> Hi,
>
> Currently nailgun and puppet process network_metadata hash slightly
> different.
> Nailgun uses short hostname as a hash key for each node, while library
> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
> deployment failure.
>
> During code review[0] it turned out that there are two points of view,
> which approach is correct [1].
> Both are one-line fixes, however it have been lasting too long with no
> result.
>
> I would like to start a discussion with a hope to close the issue shortly.
>
> Best regards.
> Kyrylo
>
> [0] https://review.openstack.org/#/c/284046/
> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>
> __
> 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] network_metadata hash keys on astute.yaml

2016-03-15 Thread Kyrylo Galanov 
Hi,

Currently nailgun and puppet process network_metadata hash slightly
different.
Nailgun uses short hostname as a hash key for each node, while library code
assumes that key is always 'node-{uid}'. Sometimes it can result in a
deployment failure.

During code review[0] it turned out that there are two points of view,
which approach is correct [1].
Both are one-line fixes, however it have been lasting too long with no
result.

I would like to start a discussion with a hope to close the issue shortly.

Best regards.
Kyrylo

[0] https://review.openstack.org/#/c/284046/
[1] https://bugs.launchpad.net/fuel/+bug/1538220
__
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