Open Stack

>  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
>