<div dir="ltr">Igor<div><br></div><div>This is not the case to tell users if they are stupid are not. We are working for our users, not vice versa.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 1:18 PM, 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">Mike,<br>
<span class=""><br>
> still not exactly true for some large enterprises. Due to all the security, etc.,<br>
> there are sometimes VPNs / proxies / firewalls with very low throughput.<br>
<br>
</span>It's their problem, and their policies. We can't and shouldn't handle<br>
all possible cases. If some enterprise has "no Internet" policy, I bet<br>
it won't be a problem for their IT guys to create an intranet mirror<br>
for MOS packages. Moreover, I also bet they do have a mirror for<br>
Ubuntu or other Linux distributive. So it basically about approach how<br>
to consume our mirrors.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>> wrote:<br>
> Folks<br>
><br>
> I think, Mike is completely right here - we need an option to build<br>
> all-in-one ISO which can be tried-out/deployed unattendedly without internet<br>
> access. Let's let a user make a choice what he wants, not push him into<br>
> embarassing situation. We still have many parts of Fuel which make choices<br>
> for user that cannot be overriden. Let's not pretend that we know more than<br>
> user does about his environment.<br>
><br>
> On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> The reason people want offline deployment feature is not because of poor<br>
>> connection, but rather the enterprise intranets where getting subnet with<br>
>> external access sometimes is a real pain in various body parts.<br>
>><br>
>> --<br>
>> Best regards,<br>
>> Oleg Gelbukh<br>
>><br>
>> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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>
>>><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>><br>
>>> > 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<br>
>>> >>>>> understand,<br>
>>> >>>>> easier to troubleshoot<br>
>>> >>>>> 2) If one wants to have local mirror, the flow is the same as in<br>
>>> >>>>> case<br>
>>> >>>>> of upstream repos (fuel-createmirror), which is clrear for a user<br>
>>> >>>>> 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<br>
>>> >>> 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<br>
>>> >>> that<br>
>>> >>> creating local mirror. But this discussion is totally out of the<br>
>>> >>> 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<br>
>>> >> 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<br>
>>> >>>>> using<br>
>>> >>>>> package based delivery approach.<br>
>>> >>>>><br>
>>> >>>>> It is easy to define necessary repos during deployment and thus it<br>
>>> >>>>> is<br>
>>> >>>>> easy to control what exactly is going to be installed on slave<br>
>>> >>>>> 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<br>
>>> >>>> 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<br>
>>> >>>> the<br>
>>> >>>> tools to setup the local mirror and properly document what<br>
>>> >>>> urls/ports/etc<br>
>>> >>>> need to be available for the installation of openstack and any<br>
>>> >>>> mirror<br>
>>> >>>> creation process.  The ideal thing is to have an all-in-one CD<br>
>>> >>>> similar to a<br>
>>> >>>> live cd that allows a user to completely try out fuel wherever they<br>
>>> >>>> want<br>
>>> >>>> with out further requirements of internet access.  If we don't want<br>
>>> >>>> to<br>
>>> >>>> continue with that, we need to do a better job around providing the<br>
>>> >>>> tools<br>
>>> >>>> for a user to get up and running in a timely fashion.  Perhaps<br>
>>> >>>> providing an<br>
>>> >>>> net-only iso and an all-included iso would be a better solution so<br>
>>> >>>> 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<br>
>>> >>> than<br>
>>> >>> all other online repos. A user sees on the settings tab the list of<br>
>>> >>> repos<br>
>>> >>> one of which is local by default while others are online. It can make<br>
>>> >>> user a<br>
>>> >>> little bit confused, can't it? A user can be also confused by the<br>
>>> >>> fact, that<br>
>>> >>> some of the repos can be cloned locally by fuel-createmirror while<br>
>>> >>> 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<br>
>>> >> a<br>
>>> >> release.  Would it be better to provide the mirror on the ISO but not<br>
>>> >> have<br>
>>> >> it enabled by default for a release so that we can gather user<br>
>>> >> feedback on<br>
>>> >> this? This would include improved documentation and possibly allowing<br>
>>> >> 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<br>
>>> >>> convoluted.<br>
>>> >>> We are forced to have several directories with predefined names and<br>
>>> >>> we are<br>
>>> >>> forced to manage these directories in nailgun, in upgrade script,<br>
>>> >>> etc. Why?<br>
>>> >>> 3) When putting MOS mirror on ISO, we make people think that ISO is<br>
>>> >>> equal<br>
>>> >>> to MOS, which is not true. It is possible to implement really<br>
>>> >>> 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<br>
>>> >> an<br>
>>> >> ISO as a release is a common method of distributing software. Is this<br>
>>> >> a<br>
>>> >> messaging thing that needs to be addressed? Perhaps I'm not familiar<br>
>>> >> 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<br>
>>> >>> they<br>
>>> >>> need but first we need to have simple working scheme clear for<br>
>>> >>> everyone. I<br>
>>> >>> think dealing with all repos the same way is what is gonna makes<br>
>>> >>> 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<br>
>>> >> 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<br>
>>> >> repository<br>
>>> >> and only provide an internet based solution makes internet<br>
>>> >> connectivity<br>
>>> >> something that needs to be included in the discussion.  I just want to<br>
>>> >> make<br>
>>> >> sure that we properly evaluate this decision based on end user<br>
>>> >> 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<br>
>>> > deploy<br>
>>> > without Internet access, this is part of reason that people like it and<br>
>>> > it's<br>
>>> > better that other tools.<br>
>>> >><br>
>>> >><br>
>>> >> -Alex<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> __________________________________________________________________________<br>
>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>>> >> Unsubscribe:<br>
>>> >> <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>
>>> > __________________________________________________________________________<br>
>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>> > Unsubscribe:<br>
>>> > <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>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <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>
>> 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>
> 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.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a><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><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>