Open Stack

> Vladimir's proposal was to use smth similar to MiniCD

Just to clarify. My proposal is to remove DEB MOS repo from the master node
by default and thus from the ISO. That is it.
My proposal does not assume having internet connection during installing
the master node. Fuel RPM packages together with their dependencies are
still there on ISO, thus the master node can be installed w/o internet
connection. Cloud/OpenStack can not be deployed out of the box anyway. It
is because we don't put Ubuntu upstream on ISO. Anyway a user is forced to
make Ubuntu upstream mirror available on the master node (cloning it
locally or via internet connection).

IMO, Fuel in this case is like a browser or bittorrent client. Packages are
available on Linux DVDs but it makes little sense to use them w/o internet
connection.


Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:

> 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.
>
> __________________________________________________________________________
> 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/20150910/77f2107e/attachment.html>