Igor This is not the case to tell users if they are stupid are not. We are working for our users, not vice versa.
On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > 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 <vkuk...@mirantis.com> > 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 <ogelb...@mirantis.com> > > 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 < > ikalnit...@mirantis.com> > >> 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 <yt...@mirantis.com> > wrote: > >>> > > >>> > > >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz <aschu...@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-requ...@lists.openstack.org?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: > >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > > >>> > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?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 > > vkuk...@mirantis.com > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?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 <http://www.mirantis.ru/> www.mirantis.ru vkuk...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
