Open Stack

Alex,

The idea is to remove MOS DEB repo from the Fuel master node by default and
>> use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>>
>
> Is this a problem? How much disk space is saved If I have to go create a
> local mirror via fuel-createmirror?
>

It is not a problem at all, but still it is pro of the proposal.


> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>
> From the issues I've seen,  fuel-createmirror isn't very straight forward
> and has some issues making it a bad UX.
>

I'd say the whole approach of having such tool as fuel-createmirror is a
way too naive. Reliable internet connection is totally up to network
engineering rather than deployment. Even using proxy is much better that
creating local mirror. But this discussion is totally out of the scope of
this letter. Currently,  we have fuel-createmirror and it is pretty
straightforward (installed as rpm, has just a couple of command line
options). The quality of this script is also out of the scope of this
thread. BTW we have plans to improve it.


>
>> Many people still associate ISO with MOS, but it is not true when using
>> package based delivery approach.
>>
>> It is easy to define necessary repos during deployment and thus it is
>> easy to control what exactly is going to be installed on slave nodes.
>>
>> What do you guys think of it?
>>
>>
>>
> Reliance on internet connectivity has been an issue since 6.1. For many
> large users, complete access to the internet is not available or not
> desired.  If we want to continue down this path, we need to improve the
> tools to setup the local mirror and properly document what urls/ports/etc
> need to be available for the installation of openstack and any mirror
> creation process.  The ideal thing is to have an all-in-one CD similar to a
> live cd that allows a user to completely try out fuel wherever they want
> with out further requirements of internet access.  If we don't want to
> continue with that, we need to do a better job around providing the tools
> for a user to get up and running in a timely fashion.  Perhaps providing an
> net-only iso and an all-included iso would be a better solution so people
> will have their expectations properly set up front?
>

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

This thread is not about internet connectivity, it is about aligning things.



> -Alex
>
>
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
>> vkozhukalov at mirantis.com> wrote:
>>
>>> Dear colleagues,
>>>
>>> The idea is to remove MOS DEB repo from the Fuel master node by default
>>> and use online MOS repo instead. Pros of such an approach are:
>>>
>>> 0) Reduced requirement for the master node minimal disk space
>>> 1) There won't be such things in like [1] and [2], thus less complicated
>>> flow, less errors, easier to maintain, easier to understand, easier to
>>> troubleshoot
>>> 2) If one wants to have local mirror, the flow is the same as in case of
>>> upstream repos (fuel-createmirror), which is clrear for a user to
>>> understand.
>>>
>>> Many people still associate ISO with MOS
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>>> [2]
>>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150909/21ae6d53/attachment.html>