<div dir="ltr">Folks<div><br></div><div>I think, Mike is completely right here - we need an option to build all-in-one ISO which can be tried-out/deployed unattendedly without internet access. Let's let a user make a choice what he wants, not push him into embarassing situation. We still have many parts of Fuel which make choices for user that cannot be overriden. Let's not pretend that we know more than user does about his environment. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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><div><br>
<br>
On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang <<a href="mailto:ytang@mirantis.com" target="_blank">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" target="_blank">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>
</div></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>