Mike, > still not exactly true for some large enterprises. Due to all the security, > etc., > there are sometimes VPNs / proxies / firewalls with very low throughput.
It's their problem, and their policies. We can't and shouldn't handle all possible cases. If some enterprise has "no Internet" policy, I bet it won't be a problem for their IT guys to create an intranet mirror for MOS packages. Moreover, I also bet they do have a mirror for Ubuntu or other Linux distributive. So it basically about approach how to consume our mirrors. On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin <[email protected]> wrote: > Folks > > 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. > > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh <[email protected]> > wrote: >> >> 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. >> >> -- >> Best regards, >> Oleg Gelbukh >> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <[email protected]> >> wrote: >>> >>> Hello, >>> >>> I agree with Vladimir - the idea of online repos is a right way to >>> move. In 2015 I believe we can ignore this "poor Internet connection" >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux >>> distributives - most of them fetch needed packages from the Internet >>> during installation, not from CD/DVD. The netboot installers are >>> popular, I can't even remember when was the last time I install my >>> Debian from the DVD-1 - I use netboot installer for years. >>> >>> Thanks, >>> Igor >>> >>> >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang <[email protected]> wrote: >>> > >>> > >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz <[email protected]> >>> > 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: >>> >> [email protected]?subject:unsubscribe >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> > >>> > >>> > >>> > -- >>> > Yaguang Tang >>> > Technical Support, Mirantis China >>> > >>> > Phone: +86 15210946968 >>> > >>> > >>> > >>> > >>> > __________________________________________________________________________ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> > [email protected]?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com > www.mirantis.ru > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
