Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Vladimir Kozhukalov]

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

[openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Yuriy Taraday]

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

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Yuriy Taraday]

On Thu, Sep 10, 2015 at 4:43 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> > 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 
> wrote:
>
>> 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.
>>
>
As I've mentioned later in the initial mail (see above), I'm not talking
about using this approach to deploy Fuel (although it'd be great if we do).
I'm talking about using it to deploy Fuel and then MOS. We can download
some fixed part of the image that contains everything needed to deploy Fuel
and add all necessary repos and manifests to it, for example.

So to repeat the analogy, Fuel is like deb-installer that is present on any
Debian-based MiniCD and MOS (packages+manifests) is like packages that
present on DVD (and downloaded in MiniCD case). You don't want to dig into
deb-installer, but you might want to install different software from
different sources. Just like you don't want to mess with Fuel itself while
you might want to install customized MOS from local repo (or from resulting
image).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev