Open Stack

>
> > 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 <asvechnikov at 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 <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
>>
>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151216/a1807c7a/attachment.html>