Open Stack

On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz <aschultz at mirantis.com> wrote:

>
> Hey Vladimir,
>
>
>>
>>
>>> 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.
>>
>
>
> Fair enough, I just wanted to raise the UX issues around these types of
> things as they should go into the decision making process.
>
>
>
>>
>>>
>>>> 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.
>>
>
>
> 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?
>
>
> 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.
>
>
> 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?
>
>
>
>> 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.
>


 +1, whatever the changes is, please keep Fuel as a tool that can deploy
without Internet access, this is part of reason that people like it and
it's better that other tools.

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


-- 
Yaguang Tang
Technical Support, Mirantis China

*Phone*: +86 15210946968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150910/7c15f7df/attachment.html>