Open Stack

> 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 <ikalnitsky at 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
> <asvechnikov at 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 <ikalnitsky at 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
> >> <azvyagintsev at 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
> >> > <vkramskikh at 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 <
> asvechnikov at 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-request at 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-request at 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-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
> >
> >
> >
> >
> __________________________________________________________________________
> > 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/20151216/ea498ddf/attachment.html>