Agree, we should understand taht this is not engineering decision but rather political/business related and fully functional ISO or ISO+some QCOW2/whatever is a strong requirement.
regards, A. On Thu, Sep 10, 2015 at 8:53 AM, Yaguang Tang <yt...@mirantis.com> wrote: > > > On Thu, Sep 10, 2015 at 1:52 PM, 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. >> > > You are think in a way of developers, but the fact is that Fuel are widely > used by various enterprises in the world wide, there are many security > policies for enterprise to have no internet connection. > > > >> 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 >> > > > > -- > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc.
__________________________________________________________________________ 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