> > > What if user choose CentOS bootstrap? We ship it on ISO, so why do > > we need to show error message? > > CentOS bootstrap still is not activated >
Its pretty simple case-flow: If selected ubuntu: - Try build -- Notify if build and activate fail -- Notify if build and activate ok If selected centos: - Call "fuel-bootstrap activate centos" - and remove message (activating centos bootstrap still supports, with "deprecated message in CLI") If selected ubuntu+skip - do nothing On Wed, Dec 16, 2015 at 4:30 PM, Artur Svechnikov <asvechni...@mirantis.com> wrote: > > Bootstrap building *is* a part of master node deployment. > > Not always, user can set flag `skip_default_img_build` then building > bootstrap will not executed. > > > If you guys show "deployment is successful" before running building > bootstrap, > > then it's something you have to fix. > > fuel-bootstrap-cli is only responsible for remove error and set it in case > activation is failed. > > > What if user choose CentOS bootstrap? We ship it on ISO, so why do > > we need to show error message? > > CentOS bootstrap still is not activated > > > it's something unrelated to Nailgun itself > > I think that notifying user about errors or something else is related to > Nailgun itself. > > Ok, It's looks like workaround for me, but we can set error message in > the beginning of deployment. > But it shouldn't be made by using fuel-bootstrap-cli. It can be curl or > something else. > > > > Best regards, > Svechnikov Artur > > On Wed, Dec 16, 2015 at 4:48 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> > 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 >> > > > __________________________________________________________________________ > 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
