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
