Open Stack

Hello, thread!

First let me address some of the very good points Alex raised in his email.

On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz <aschultz at mirantis.com> wrote:

> Fair enough, I just wanted to raise the UX issues around these types of
> things as they should go into the decision making process.
>

UX issues is what we definitely should address even for ourselves: number
of things that need to happen to deploy Master with just one small change
is enormous.


> Let me explain why I think having local MOS mirror by default is bad:
>> 1) I don't see any reason why we should treat MOS  repo other way than
>> all other online repos. A user sees on the settings tab the list of repos
>> one of which is local by default while others are online. It can make user
>> a little bit confused, can't it? A user can be also confused by the fact,
>> that some of the repos can be cloned locally by fuel-createmirror while
>> others can't. That is not straightforward, NOT fuel-createmirror UX.
>>
>
> I agree. The process should be the same and it should be just another
> repo. It doesn't mean we can't include a version on an ISO as part of a
> release.  Would it be better to provide the mirror on the ISO but not have
> it enabled by default for a release so that we can gather user feedback on
> this? This would include improved documentation and possibly allowing a
> user to choose their preference so we can collect metrics?
>

I think instead of relying on average user of spherical Fuel we should let
user decide what goes to ISO.

2) Having local MOS mirror by default makes things much more convoluted. We
>> are forced to have several directories with predefined names and we are
>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
>> to MOS, which is not true. It is possible to implement really flexible
>> delivery scheme, but we need to think of these things as they are
>> independent.
>>
>
> I'm not sure what you mean by this. Including a point in time copy on an
> ISO as a release is a common method of distributing software. Is this a
> messaging thing that needs to be addressed? Perhaps I'm not familiar with
> people referring to the ISO as being MOS.
>

It is so common that some people think it's very broken. But we can fix
that.

For large users it is easy to build custom ISO and put there what they need
>> but first we need to have simple working scheme clear for everyone. I think
>> dealing with all repos the same way is what is gonna makes things simpler.
>>
>
> Who is going to build a custom ISO? How does one request that? What
> resources are consumed by custom ISO creation process/request? Does this
> scale?
>

How about user building ISO on one's workstation?

This thread is not about internet connectivity, it is about aligning things.
>>
>
> You are correct in that this thread is not explicitly about internet
> connectivity, but they are related. Any changes to remove a local
> repository and only provide an internet based solution makes internet
> connectivity something that needs to be included in the discussion.  I just
> want to make sure that we properly evaluate this decision based on end user
> feedback not because we don't want to manage this from a developer
> standpoint.
>

We can use Internet connectivity not only in target DC.

Now what do I mean by all that? Let's make Fuel distribution that's easier
to develop and distribute while making it more comfortable to use in the
process.

As Alex pointed out, the common way to distribute an OS is to put some
number of packages from some snapshot of golden repo on ISO and let user
install that. Let's say, it's a DVD way (although there was time OS could
fit CD). The other less common way of distributing OS is a small minimal
ISO and use online repo to install everything. Let's say, it's a MiniCD way.

Fuel is now using a DVD way: we put everything user will ever need to an
ISO and give it to user. Vladimir's proposal was to use smth similar to
MiniCD way: put only Fuel on ISO and keep online repo running.

Note that I'll speak of Fuel as an installer people put on MiniCD. It's a
bit bigger, but it deploys clouds, not just separate machines. Packages and
OS then translate to everything needed to deploy OpenStack: packages and
deploy scripts (puppet manifests, could be packaged as well). We could
apply the same logic to distribution of Fuel itself though, but let's not
get into it right now.

Let's compare these ways from distributor (D) and user (U) point of view.

DVD way.
Pros:
- (D) a single piece to deliver to user;
- (D,U) a snapshot of repo put on ISO is easier to cover with QA and so
it's better tested;
- (U) one-time download for everything;
- (U) no need for Internet connectivity when you're installing OS;
- (U) you can store ISO and reuse it any number of times.
Cons:
- (D) you still have to maintain online repo for updates;
- (D,U) it's hard to create a custom ISO if customer needs it, so one of
them have to take the burden of this on one's shoulders (usually as well as
in our case it's user);
- (U) huge download that pulls everything even if you'll never need it;
- (U) after installation one have outdated versions of everything, so
you'll have to go online and upgrade everything.

MiniCD way.
Pros:
- (D) ISO creation is simple as it doesn't depend on current state of repos;
- (D,U) small one-time download;
- (U) one can customize everything, install only what is needed, use
different repos;
- (U) up-to-date software is installed straight away.
Cons:
- (D) installer has to deal with any state of online repo;
- (U) you have to have Internet connection wherever you want to install;
- (U) download time is added to install process;
- (U) you have to download all packages for each install.

How about we define another way that combines these pros and overcomes cons?

>From user point of view we have two stages: downloading and installing. In
MiniCD way part of downloading stage is melted into installing stage.
Installing stage can be configured: you can use different repos and opt in
for using online repo when installing from DVD even. Downloading stage is
fixed unless you're going to build your own ISO in which case you just
don't use upstream distribution, you create your own.

Let's shift customization to download stage, so user will have this
workflow:
- download some archive (ISO, USB stick image or even just some archive);
- unpack it;
- run a script from that archive that downloads all software user is going
to install, including MOS from our repos or one's custom repo;
- run another script (unless the previous one does this) that bundles
everything to one image (or stores it on USB stick);
- go to datacenter (via iKVM or via iLegs) and deploy Fuel and MOS from
your image.

Note that all steps (except the last one) can be done on one's workstation
with shiny Internet access and comfortable chair available and datacenter
doesn't require any access to Internet or custom mirrors.

The ideal UX would be like this (replace USB stick with empty disc or just
ISO image if you like):
- plug in USB stick;
- download some app, run it;
- fill some forms;
- wait a bit;
- take this USB stick to datacenter.
App should download and put all necessary components on USB stick.

Now let's break down pros and cons for this approach.
Pros:
- (D) creation of source archive is simple as it doesn't depend on current
state of repos;
- (U) download only what you need and from where you're free to download
anything;
- (D,U) customization is built into the process;
- (U) no need for Internet access from datacenter;
- (U) but if you have one, you can freshen packages on Fuel master
afterwards without need to download everything;
- (U) all packages are as fresh as they are when you're preparing the image;
- (U) image can be reused on as many clouds as you like.
Cons:
- (D) installer have to deal with any state of the repo (although with
customization it's user's fault if one uses bad repos);
- (U) you have to do some preparation steps on your workstation (although
if you don't need any customization it would take the same amount of time
as downloading MiniCD and "burning" it);
- I'm out of ideas.

Note that this customization phase is where developers can inject their
modified packages.

PS: It's not my idea, I've read/heard it somewhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150910/d6c82870/attachment.html>