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