<div dir="ltr">The reason people want offline deployment feature is not because of poor connection, but rather the enterprise intranets where getting subnet with external access sometimes is a real pain in various body parts.<div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I agree with Vladimir - the idea of online repos is a right way to<br>
move. In 2015 I believe we can ignore this "poor Internet connection"<br>
reason, and simplify both Fuel and UX. Moreover, take a look at Linux<br>
distributives - most of them fetch needed packages from the Internet<br>
during installation, not from CD/DVD. The netboot installers are<br>
popular, I can't even remember when was the last time I install my<br>
Debian from the DVD-1 - I use netboot installer for years.<br>
<br>
Thanks,<br>
Igor<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang <<a href="mailto:ytang@mirantis.com">ytang@mirantis.com</a>> wrote:<br>
><br>
><br>
> On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz <<a href="mailto:aschultz@mirantis.com">aschultz@mirantis.com</a>> wrote:<br>
>><br>
>><br>
>> Hey Vladimir,<br>
>><br>
>>><br>
>>><br>
>>>>><br>
>>>>> 1) There won't be such things in like [1] and [2], thus less<br>
>>>>> complicated flow, less errors, easier to maintain, easier to understand,<br>
>>>>> easier to troubleshoot<br>
>>>>> 2) If one wants to have local mirror, the flow is the same as in case<br>
>>>>> of upstream repos (fuel-createmirror), which is clrear for a user to<br>
>>>>> understand.<br>
>>>><br>
>>>><br>
>>>> From the issues I've seen,  fuel-createmirror isn't very straight<br>
>>>> forward and has some issues making it a bad UX.<br>
>>><br>
>>><br>
>>> I'd say the whole approach of having such tool as fuel-createmirror is a<br>
>>> way too naive. Reliable internet connection is totally up to network<br>
>>> engineering rather than deployment. Even using proxy is much better that<br>
>>> creating local mirror. But this discussion is totally out of the scope of<br>
>>> this letter. Currently,  we have fuel-createmirror and it is pretty<br>
>>> straightforward (installed as rpm, has just a couple of command line<br>
>>> options). The quality of this script is also out of the scope of this<br>
>>> thread. BTW we have plans to improve it.<br>
>><br>
>><br>
>><br>
>> Fair enough, I just wanted to raise the UX issues around these types of<br>
>> things as they should go into the decision making process.<br>
>><br>
>><br>
>>><br>
>>>>><br>
>>>>><br>
>>>>> Many people still associate ISO with MOS, but it is not true when using<br>
>>>>> package based delivery approach.<br>
>>>>><br>
>>>>> It is easy to define necessary repos during deployment and thus it is<br>
>>>>> easy to control what exactly is going to be installed on slave nodes.<br>
>>>>><br>
>>>>> What do you guys think of it?<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>> Reliance on internet connectivity has been an issue since 6.1. For many<br>
>>>> large users, complete access to the internet is not available or not<br>
>>>> desired.  If we want to continue down this path, we need to improve the<br>
>>>> tools to setup the local mirror and properly document what urls/ports/etc<br>
>>>> need to be available for the installation of openstack and any mirror<br>
>>>> creation process.  The ideal thing is to have an all-in-one CD similar to a<br>
>>>> live cd that allows a user to completely try out fuel wherever they want<br>
>>>> with out further requirements of internet access.  If we don't want to<br>
>>>> continue with that, we need to do a better job around providing the tools<br>
>>>> for a user to get up and running in a timely fashion.  Perhaps providing an<br>
>>>> net-only iso and an all-included iso would be a better solution so people<br>
>>>> will have their expectations properly set up front?<br>
>>><br>
>>><br>
>>> Let me explain why I think having local MOS mirror by default is bad:<br>
>>> 1) I don't see any reason why we should treat MOS  repo other way than<br>
>>> all other online repos. A user sees on the settings tab the list of repos<br>
>>> one of which is local by default while others are online. It can make user a<br>
>>> little bit confused, can't it? A user can be also confused by the fact, that<br>
>>> some of the repos can be cloned locally by fuel-createmirror while others<br>
>>> can't. That is not straightforward, NOT fuel-createmirror UX.<br>
>><br>
>><br>
>><br>
>> I agree. The process should be the same and it should be just another<br>
>> repo. It doesn't mean we can't include a version on an ISO as part of a<br>
>> release.  Would it be better to provide the mirror on the ISO but not have<br>
>> it enabled by default for a release so that we can gather user feedback on<br>
>> this? This would include improved documentation and possibly allowing a user<br>
>> to choose their preference so we can collect metrics?<br>
>><br>
>><br>
>>> 2) Having local MOS mirror by default makes things much more convoluted.<br>
>>> We are forced to have several directories with predefined names and we are<br>
>>> forced to manage these directories in nailgun, in upgrade script, etc. Why?<br>
>>> 3) When putting MOS mirror on ISO, we make people think that ISO is equal<br>
>>> to MOS, which is not true. It is possible to implement really flexible<br>
>>> delivery scheme, but we need to think of these things as they are<br>
>>> independent.<br>
>><br>
>><br>
>><br>
>> I'm not sure what you mean by this. Including a point in time copy on an<br>
>> ISO as a release is a common method of distributing software. Is this a<br>
>> messaging thing that needs to be addressed? Perhaps I'm not familiar with<br>
>> people referring to the ISO as being MOS.<br>
>><br>
>><br>
>>> For large users it is easy to build custom ISO and put there what they<br>
>>> need but first we need to have simple working scheme clear for everyone. I<br>
>>> think dealing with all repos the same way is what is gonna makes things<br>
>>> simpler.<br>
>>><br>
>><br>
>><br>
>> Who is going to build a custom ISO? How does one request that? What<br>
>> resources are consumed by custom ISO creation process/request? Does this<br>
>> scale?<br>
>><br>
>><br>
>>><br>
>>> This thread is not about internet connectivity, it is about aligning<br>
>>> things.<br>
>>><br>
>><br>
>> You are correct in that this thread is not explicitly about internet<br>
>> connectivity, but they are related. Any changes to remove a local repository<br>
>> and only provide an internet based solution makes internet connectivity<br>
>> something that needs to be included in the discussion.  I just want to make<br>
>> sure that we properly evaluate this decision based on end user feedback not<br>
>> because we don't want to manage this from a developer standpoint.<br>
><br>
><br>
><br>
>  +1, whatever the changes is, please keep Fuel as a tool that can deploy<br>
> without Internet access, this is part of reason that people like it and it's<br>
> better that other tools.<br>
>><br>
>><br>
>> -Alex<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Yaguang Tang<br>
> Technical Support, Mirantis China<br>
><br>
> Phone: +86 15210946968<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>