> As I already told deployment was finished, but bootstrap wasn't built.
Bootstrap building *is* a part of master node deployment. If you guys show "deployment is successful" before running building bootstrap, then it's something you have to fix. > Fuel deploying => WebUI blocked => deployment is failed due to some minor > thing => I fix it => Ooops how can I activate WebUI I see no problem here. You fix the problem, run deployment script again and it unblocks everything for you. Usually it won't be enough to fix something without re-running deployment, simply because a lot of steps may be skipped due to the error. > I really can't understand why is it bad to set error message by default So far I can provide two reasons: * What if user choose CentOS bootstrap? We ship it on ISO, so why do we need to show error message? * Nailgun should have good defaults, and showing error by default is bad practice (it's something unrelated to Nailgun itself). Moreover, it's a good practice to separate areas of responsibility, and it's building script who's responsible to show and hide error message if necessary. - Igor On Wed, Dec 16, 2015 at 3:31 PM, Artur Svechnikov <asvechni...@mirantis.com> wrote: >> We keep it As Is, and say "user should not use Fuel until Fuel >> Master deployment is finished". > > Yep deployment can be finished, but was it successful? As I already told > deployment was finished, but bootstrap wasn't built. Command for building > bootstrap wasn't called because of some reason. > >> We make API / Web UI unaccessible externally until Fuel Master is >> deployed (e.g. iptables rules or nginx ones). > > This approach seems too suspicious for me, due to the same reason as above. > I can imagine some workflow: Fuel deploying => WebUI blocked => deployment > is failed due to some minor thing => I fix it => Ooops how can I activate > WebUI... But maybe I'm wrong, anyway this approach required serious change > of nailgun by handling deployment process. > > I really can't understand why is it bad to set error message by default. By > default before all deployment is not finished master hasn't any valid > bootstrap image, hence this error message is not bad or weird, it's in right > place. Error message will be disabled by fuel-bootstrap-cli after building, > activation of bootstrap image. > > Best regards, > Svechnikov Artur > > On Wed, Dec 16, 2015 at 4:05 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> > I really don't like setting the error message as the default one in >> > the DB schema and consider it as a last resort solution. If >> > possible update the message to error one just before you start >> > to build the image. >> >> +1. >> >> > What about add some check or some message >> > "Fuel-master Deployment in progress, please wait %s" ? >> >> I don't like this idea, since I believe it's something that user >> shouldn't care at all. I see two possible *right* appraoch to handle >> this: >> >> 1. We keep it As Is, and say "user should not use Fuel until Fuel >> Master deployment is finished". >> 2. We make API / Web UI unaccessible externally until Fuel Master is >> deployed (e.g. iptables rules or nginx ones). >> >> What do you say? >> >> - Igor >> >> On Wed, Dec 16, 2015 at 12:00 PM, Aleksey Zvyagintsev >> <azvyagint...@mirantis.com> wrote: >> > Actually, its gloval problem : >> > UI accessible for user earlier then deployment has been done. I think we >> > should also handle this somehow - otherwise user can start doing "some >> > things" like spawning HW - and fail . >> > What about add some check or some message "Fuel-master Deployment in >> > progress, please wait %s" ? >> > >> > >> > >> > >> > On Tue, Dec 15, 2015 at 6:56 PM, Vitaly Kramskikh >> > <vkramsk...@mirantis.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> I really don't like setting the error message as the default one in the >> >> DB >> >> schema and consider it as a last resort solution. If possible update >> >> the >> >> message to error one just before you start to build the image. >> >> >> >> 2015-12-15 18:48 GMT+03:00 Artur Svechnikov <asvechni...@mirantis.com>: >> >>> >> >>> Hi folks, >> >>> Recently was introduced special notification about absented bootstrap >> >>> image. >> >>> >> >>> Currently this notification is sent from fuel-bootstrap-cli. It means >> >>> that error message will not be sent when failure occurs before first >> >>> building (like in [1]). I think it will be better to set error message >> >>> on >> >>> WebUI by default through fixtures and then remove it if first build is >> >>> successful. >> >>> >> >>> Please share your opinions about this issue. >> >>> >> >>> [1] https://bugs.launchpad.net/fuel/+bug/1526351 >> >>> >> >>> Best regards, >> >>> Svechnikov Artur >> >>> >> >>> >> >>> >> >>> __________________________________________________________________________ >> >>> 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 >> >>> >> >> >> >> >> >> >> >> -- >> >> Vitaly Kramskikh, >> >> Fuel UI Tech Lead, >> >> Mirantis, Inc. >> >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> >> >> > >> > >> > >> > -- >> > --- >> > Best regards, >> > Aleksey Zvyagintsev >> > >> > >> > __________________________________________________________________________ >> > 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