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 <[email protected]> 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 <[email protected]> написав(ла): > > 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 <[email protected]> > 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 <[email protected]> написав(ла): >> >> 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 <[email protected]> >> 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: >>> [email protected]?subject:unsubscribe >>> <http://[email protected]/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected] >> ?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
