Thank you Roman for driving this!
Full list of nodes statuses is:
NODE_STATUSES = Enum(
'ready',
'discover',
'provisioning',
'provisioned',
'deploying',
'error',
'removing',
)
We could combine 'provisioning', 'provisioned', 'deploying' into one maybe
as cluster has only 'deployment' status for all of that now. It seems to be
enough for cluster management.
CLUSTER_STATUSES = Enum(
'new',
'deployment',
'stopped',
'operational',
'error',
'remove',
'update',
'update_error'
)
[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/consts.py
Aleksey Kasatkin
On Wed, May 27, 2015 at 4:00 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote:
> Excellent, nice to know that we're on the same page about this.
>
> Thank you!
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko <m...@romcheg.me>
> wrote:
>
>> Oleg,
>>
>> Thanks for the feedback. I have the following as a response:
>>
>> 1. This spec is just an excerpt for scoping in the proposed improvement
>> to the 7.0 release plan. If it get’s scope the full specification will go
>> through a standard review process so it will be possible to discuss names
>> along with the rest of details then.
>>
>> 2. It’s already noticed in the spec the status is is generated using an
>> aggregate query like you described so I don’t propose to store it. Storing
>> that data will require sophisticated algorithms to work with it and also
>> will lead to more locks or race conditions in the database. So yes, it’s
>> going to be a method.
>>
>>
>> - romcheg
>>
>>
>> 27 трав. 2015 о 08:19 Oleg Gelbukh <ogelb...@mirantis.com> написав(ла):
>>
>> Roman,
>>
>> This looks like a great solution to me, and I like your proposal very
>> much. The status of cluster derived directly from statuses of nodes is
>> exactly what I was thinking about.
>>
>> I have to notes to the proposal, and I can copy them to etherpad if you
>> think they deserve it:
>>
>> 1) status name 'operational' seem a bit unclear to me, as it sounds more
>> like something Monitoring should report: it implies that the actual
>> OpenStack environment is operational, which might or might not be a case,
>> and Fuel has no way to tell. I would really prefer if that status name was
>> 'Deployed' or something along those lines.
>>
>> 2) I'm not sure if we need to keep the complex status of the cluster
>> explicitly in 'cluster' table in the format you suggest. This information
>> can be taken directly from 'nodes' table in Nailgun DB. For example,
>> getting it in the second form you propose is as simple as:
>>
>> nailgun=> SELECT status,count(status) FROM nodes GROUP BY status;
>> discover|1
>> ready|5
>>
>> What do you think about making it a method rather then an element of data
>> model? Or that's exactly the complexity you want to get rid of?
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>>
>> On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko <m...@romcheg.me>
>> wrote:
>>
>>> Oleg,
>>>
>>> Aleksander also proposed a nice proposed a nice solution [1] which is to
>>> have a complex status for cluster. That, however, looks like a BP so I’ve
>>> created an excerpt [2] for it and we will try to discuss it scope it for
>>> 7.0, if there is a consensus.
>>>
>>>
>>> References:
>>>
>>> 1.
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html
>>> 2. https://etherpad.openstack.org/p/fuel-cluster-complex-status
>>>
>>>
>>> - romcheg
>>>
>>> 22 трав. 2015 о 22:32 Oleg Gelbukh <ogelb...@mirantis.com> написав(ла):
>>>
>>> Roman,
>>>
>>> I'm totally for fixing Nailgun. However, the status of environment is
>>> not simply function of statuses of nodes in it. Ideally, it should depend
>>> on whether appropriate number of nodes of certain roles are in 'ready'
>>> status. For the meantime, it would be enough if environment was set to
>>> 'operational' when all nodes in it become 'ready', no matter how they were
>>> deployed (i.e. via Web UI or CLI).
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh
>>>
>>> On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko <m...@romcheg.me>
>>> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> Recently I encountered an issue [1] that the Deploy Changes button in
>>>> the web ui is still active when a provisioning of single node is started
>>>> using the command line client.
>>>> The background for that issue is that the provisioning task does not
>>>> seem to update the cluster status correctly and Nailgun’s API returns it as
>>>> NEW even while some of the node are been provisioned.
>>>>
>>>> The reason for raising this thread in the mailing list is that
>>>> provisioning a node is a feature for developers and basically end-users
>>>> should not do that. What is the best solution for that: fix Nailgun to set
>>>> the correct status, or make this provisioning feature available only for
>>>> developers?
>>>>
>>>> 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
>>>>
>>>>
>>>> - romcheg
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> <http://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://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
>
>
__________________________________________________________________________
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
