Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Aleksey Kasatkin]

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  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 
> 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  написав(ла):
>>
>> 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 
>> 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  написав(ла):
>>>
>>> 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 
>>> 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 De

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Oleg Gelbukh]

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  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  написав(ла):
>
> 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 
> 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  написав(ла):
>>
>> 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 
>> 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://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
>> 

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

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  написав(ла):
> 
> 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  > 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 > > написав(ла):
>> 
>> 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 > > 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://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] Setting cluster status when provisioning a node

[Oleg Gelbukh]

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  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  написав(ла):
>
> 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 
> 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://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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

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  написав(ла):
> 
> 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  > 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://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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Aleksey,
thank you for your feedback.

The first thing I’d like to highlight is that both web ui and the cli use the 
same Nailgun API to perform the same actions so basically we must not treat the 
command line client any differently.

The idea of having a complex status for environment actually seems to be pretty 
good one. However, that requires a BP so I’ve created an excerpt [1] which I’d 
like to share.
If this feature is scoped, it will get life of many folks easier since it will 
allow to discard some sophisticated algorithms.


- romcheg

1. https://etherpad.openstack.org/p/fuel-cluster-complex-status 


> 25 трав. 2015 о 10:39 Aleksey Kasatkin  написав(ла):
> 
> AFAIC, there are several problems (in API) here:
> 1. We cannot stop/reset particular nodes.
> 2. Cluster status doesn't address changes which were done via CLI.
> 3. Cluster status in its current form is not enough to manage cluster (i.e. 
> to determine actions what can be applied to cluster at the moment). It 
> doesn't reflect the fact that some nodes can be in 'provisioned' state, some 
> are in 'provisioning', 'deploying', 'ready' statuses.
> 
> First two seem clear enough. We could add ability to stop/reset particular 
> nodes and reflect CLI-driven changes in the cluster status.
> To address the last point my proposal was (bug/1449086/comments/7 
> ) to break 
> status into several binary states, i.e. binaries: 'new', 'deployment', 
> 'ready', etc., each of which is set to true when cluster has at least one 
> node in corresponding status (I united 'provisioning', 'provisioned' and 
> 'deploying' into one as it is done now).
> 
> Now it looks more reasonable to me to keep the original status as is and add 
> bitwise one mentioned above (to address states of different nodes) because 
> 'error' state is determinative for cluster (when cluster is in 'error' state 
> it is no matter that some nodes are in 'ready' state).
> So,
> cluster is in 'new' state when all nodes are in 'discover' state,
> it is in 'operational' state when all nodes are in 'ready' state,
> cluster is in 'deployment' state when not all of its nodes are in 'discover' 
> or 'ready' state but there are no nodes in 'error' and 'removing' states.
> New bitwise status is actual in 'deployment' state of cluster. It gives to 
> UI/CLI sufficient data to determine what actions can be applied to cluster at 
> the moment.
> 
> I've combined some of the states combinations into the table:
> 'new' flag
> 
> 'deployment' flag
> 
> 'ready' flag
> 
> description, actions allowed
> false
> 
> false
> 
> false
> 
> There are no nodes in cluster or all nodes are in 'error'/'removing' state. 
> Cluster is in 'new'/'error'/'remove' state here so we don't care about these 
> flags.
> 
> false
> 
> true
> 
> false
> 
> All nodes are under provisioning/deployment. Deployment can be stopped.
> 
> true
> 
> true
> 
> false
> 
> Part of nodes is in 'discover' state, remaining part is under 
> provisioning/deployment. Deployment can be started for the first part 
> or/and stopped for the second part of nodes.
> 
> true
> 
> false
> 
> true
> 
> Part of nodes is in 'discover' state, remaining part is in 'ready' state. 
> Deployment can be started for the first part and second part can be reset.
> 
> true
> 
> true
> 
> true
> 
> We have some nodes in every of the states: 'discover', 
> provisioning/deployment, 'ready'. So, we can allow different actions for 
> nodes in different states.
> 
> false
> 
> true
> 
> true
> 
> Part of nodes is under provisioning/deployment, remaining part is in 'ready' 
> state. Deployment can be stopped for the first part and second part can be 
> reset.
> 
> I didn't show another 2 combinations here as they aren't related to 
> 'deployment' state of cluster (as well as the first one in the table).
> 
> Also, we should be careful with the order of nodes deployment/reset. I'm not 
> sure whether it is written in our docs that cluster may be non-functional if 
> user tries to deploy nodes in the wrong order (e.g. computes first). We could 
> show some warnings about that. Same applies to selective reset if we will 
> implement it.
> 
> 
> 
> Aleksey Kasatkin
> 
> 
> On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko  > 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

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Aleksey Kasatkin]

AFAIC, there are several problems (in API) here:
1. We cannot stop/reset particular nodes.
2. Cluster status doesn't address changes which were done via CLI.
3. Cluster status in its current form is not enough to manage cluster (i.e.
to determine actions what can be applied to cluster at the moment). It
doesn't reflect the fact that some nodes can be in 'provisioned' state,
some are in 'provisioning', 'deploying', 'ready' statuses.

First two seem clear enough. We could add ability to stop/reset particular
nodes and reflect CLI-driven changes in the cluster status.
To address the last point my proposal was (bug/1449086/comments/7
) to break
status into several binary states, i.e. binaries: 'new', 'deployment',
'ready', etc., each of which is set to true when cluster has at least one
node in corresponding status (I united 'provisioning', 'provisioned' and
'deploying' into one as it is done now).

Now it looks more reasonable to me to keep the original status as is and
add bitwise one mentioned above (to address states of different nodes)
because 'error' state is determinative for cluster (when cluster is in
'error' state it is no matter that some nodes are in 'ready' state).
So,
cluster is in 'new' state when all nodes are in 'discover' state,
it is in 'operational' state when all nodes are in 'ready' state,
cluster is in 'deployment' state when not all of its nodes are in 'discover'
or 'ready' state but there are no nodes in 'error' and 'removing' states.
New bitwise status is actual in 'deployment' state of cluster. It gives to
UI/CLI sufficient data to determine what actions can be applied to cluster
at the moment.

I've combined some of the states combinations into the table:

'new' flag

'deployment' flag

'ready' flag

description, actions allowed

false

false

false

There are no nodes in cluster or all nodes are in 'error'/'removing' state.
Cluster is in 'new'/'error'/'remove' state here so we don't care about
these flags.

false

true

false

All nodes are under provisioning/deployment. Deployment can be stopped.

true

true

false

Part of nodes is in 'discover' state, remaining part is under
provisioning/deployment. Deployment can be started for the first part
or/and stopped for the second part of nodes.

true

false

true

Part of nodes is in 'discover' state, remaining part is in 'ready' state.
Deployment can be started for the first part and second part can be reset.

true

true

true

We have some nodes in every of the states: 'discover',
provisioning/deployment, 'ready'. So, we can allow different actions for
nodes in different states.

false

true

true

Part of nodes is under provisioning/deployment, remaining part is in
'ready' state. Deployment can be stopped for the first part and second part
can be reset.
I didn't show another 2 combinations here as they aren't related to
'deployment'
state of cluster (as well as the first one in the table).

Also, we should be careful with the order of nodes deployment/reset. I'm
not sure whether it is written in our docs that cluster may be
non-functional if user tries to deploy nodes in the wrong order (e.g.
computes first). We could show some warnings about that. Same applies to
selective reset if we will implement it.



Aleksey Kasatkin


On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko  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://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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Setting cluster status when provisioning a node

[Oleg Gelbukh]

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  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://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] Setting cluster status when provisioning a node

[Mike Scherbakov]

OpenStack operator should be provided with an option to just provision
nodes. We want to provide flexibility for sophisticated users, and I
consider this as normal use case. So I disagree that we should treat
provisioning as just developers feature.

For newbies / simplest clouds, we want to keep the easiest way of
installation possible, i.e. just Deploy button. We can claim that we've
succeeded with this once 6-year kid is able to deploy OpenStack with Fuel.

On Fri, May 22, 2015 at 7:33 AM, Roman Prykhodchenko  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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
__
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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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