<div dir="ltr">> Vladimir's proposal was to use smth similar to MiniCD<br><div><br></div><div>Just to clarify. My proposal is to remove DEB MOS repo from the master node by default and thus from the ISO. That is it.</div><div>My proposal does not assume having internet connection during installing the master node. Fuel RPM packages together with their dependencies are still there on ISO, thus the master node can be installed w/o internet connection. Cloud/OpenStack can not be deployed out of the box anyway. It is because we don't put Ubuntu upstream on ISO. Anyway a user is forced to make Ubuntu upstream mirror available on the master node (cloning it locally or via internet connection).  </div><div><br></div><div>IMO, Fuel in this case is like a browser or bittorrent client. Packages are available on Linux DVDs but it makes little sense to use them w/o internet connection.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday <span dir="ltr"><<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello, thread!<div><br></div><div>First let me address some of the very good points Alex raised in his email.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz <<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Fair enough, I just wanted to raise the UX issues around these types of things as they should go into the decision making process.</div></div></div></div></blockquote><div><br></div><div>UX issues is what we definitely should address even for ourselves: number of things that need to happen to deploy Master with just one small change is enormous.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Let me explain why I think having local MOS mirror by default is bad:</div><div>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.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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?</div></div></div></div></blockquote><div><br></div><div>I think instead of relying on average user of spherical Fuel we should let user decide what goes to ISO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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?</div><div>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.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div>It is so common that some people think it's very broken. But we can fix that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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?</div></div></div></div></blockquote><div><br></div><div>How about user building ISO on one's workstation?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This thread is not about internet connectivity, it is about aligning things.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div>We can use Internet connectivity not only in target DC.</div><div><br></div><div>Now what do I mean by all that? Let's make Fuel distribution that's easier to develop and distribute while making it more comfortable to use in the process.</div><div><br></div><div>As Alex pointed out, the common way to distribute an OS is to put some number of packages from some snapshot of golden repo on ISO and let user install that. Let's say, it's a DVD way (although there was time OS could fit CD). The other less common way of distributing OS is a small minimal ISO and use online repo to install everything. Let's say, it's a MiniCD way.</div><div><br></div><div>Fuel is now using a DVD way: we put everything user will ever need to an ISO and give it to user. Vladimir's proposal was to use smth similar to MiniCD way: put only Fuel on ISO and keep online repo running.</div><div><br></div><div>Note that I'll speak of Fuel as an installer people put on MiniCD. It's a bit bigger, but it deploys clouds, not just separate machines. Packages and OS then translate to everything needed to deploy OpenStack: packages and deploy scripts (puppet manifests, could be packaged as well). We could apply the same logic to distribution of Fuel itself though, but let's not get into it right now. </div><div><br></div><div>Let's compare these ways from distributor (D) and user (U) point of view.</div><div><br></div><div>DVD way.</div><div>Pros:</div><div>- (D) a single piece to deliver to user;</div><div>- (D,U) a snapshot of repo put on ISO is easier to cover with QA and so it's better tested;</div><div>- (U) one-time download for everything;</div><div>- (U) no need for Internet connectivity when you're installing OS;</div><div>- (U) you can store ISO and reuse it any number of times.</div><div>Cons:</div><div>- (D) you still have to maintain online repo for updates;</div><div>- (D,U) it's hard to create a custom ISO if customer needs it, so one of them have to take the burden of this on one's shoulders (usually as well as in our case it's user);</div><div>- (U) huge download that pulls everything even if you'll never need it;</div><div>- (U) after installation one have outdated versions of everything, so you'll have to go online and upgrade everything.</div><div><br></div><div>MiniCD way.</div><div>Pros:</div><div>- (D) ISO creation is simple as it doesn't depend on current state of repos;</div><div>- (D,U) small one-time download;</div><div>- (U) one can customize everything, install only what is needed, use different repos;</div><div>- (U) up-to-date software is installed straight away.</div><div>Cons:</div><div>- (D) installer has to deal with any state of online repo;</div><div>- (U) you have to have Internet connection wherever you want to install;</div><div>- (U) download time is added to install process;</div><div>- (U) you have to download all packages for each install.</div><div><br></div><div>How about we define another way that combines these pros and overcomes cons?</div><div><br></div><div>From user point of view we have two stages: downloading and installing. In MiniCD way part of downloading stage is melted into installing stage. Installing stage can be configured: you can use different repos and opt in for using online repo when installing from DVD even. Downloading stage is fixed unless you're going to build your own ISO in which case you just don't use upstream distribution, you create your own.</div><div><br></div><div>Let's shift customization to download stage, so user will have this workflow:</div><div>- download some archive (ISO, USB stick image or even just some archive);</div><div>- unpack it;</div><div>- run a script from that archive that downloads all software user is going to install, including MOS from our repos or one's custom repo;</div><div>- run another script (unless the previous one does this) that bundles everything to one image (or stores it on USB stick);</div><div>- go to datacenter (via iKVM or via iLegs) and deploy Fuel and MOS from your image.</div><div><br></div><div>Note that all steps (except the last one) can be done on one's workstation with shiny Internet access and comfortable chair available and datacenter doesn't require any access to Internet or custom mirrors.</div><div><br></div><div>The ideal UX would be like this (replace USB stick with empty disc or just ISO image if you like):</div><div>- plug in USB stick;</div><div>- download some app, run it;</div><div>- fill some forms;</div><div>- wait a bit;</div><div>- take this USB stick to datacenter.</div><div>App should download and put all necessary components on USB stick.</div><div><br></div><div>Now let's break down pros and cons for this approach.</div><div>Pros:</div><div>- (D) creation of source archive is simple as it doesn't depend on current state of repos;</div><div>- (U) download only what you need and from where you're free to download anything;</div><div>- (D,U) customization is built into the process;</div><div>- (U) no need for Internet access from datacenter;</div><div>- (U) but if you have one, you can freshen packages on Fuel master afterwards without need to download everything;</div><div>- (U) all packages are as fresh as they are when you're preparing the image;</div><div>- (U) image can be reused on as many clouds as you like.</div><div>Cons:</div><div>- (D) installer have to deal with any state of the repo (although with customization it's user's fault if one uses bad repos);</div><div>- (U) you have to do some preparation steps on your workstation (although if you don't need any customization it would take the same amount of time as downloading MiniCD and "burning" it);</div><div>- I'm out of ideas.</div><div><br></div><div>Note that this customization phase is where developers can inject their modified packages.</div><div><br></div><div>PS: It's not my idea, I've read/heard it somewhere.</div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>