Open Stack

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 <me at 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 <ogelbukh at 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 <me at 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 <ogelbukh at 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 <me at 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-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150527/3b5f9efa/attachment.html>