Vladimir, Different users have different requirements. If start covering all of them, the project will become complex, buggy and unsupportable.
It's a common practice to choose just one path and follow it. Obviously, some "recipes" how to achieve something could be provided, but I believe we should focus on most important feature of Fuel - How to deploy reliable OpenStack environment, and this has nothing in common where and how to fetch packages. Thanks, Igor On Thu, Sep 10, 2015 at 3:25 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > 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 > 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