<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hey Vladimir,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div><br></div><div>The idea is to remove MOS DEB repo from the Fuel master node by default and use online MOS repo instead. Pros of such an approach are:</div><div><br></div><div>0) Reduced requirement for the master node minimal disk space</div></span></div></blockquote><div><br></div><div>Is this a problem? How much disk space is saved If I have to go create a local mirror via fuel-createmirror?</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><span class=""><div>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</div><div>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. </div></span></div></div></blockquote><div><br></div><div>From the issues I've seen, fuel-createmirror isn't very straight forward and has some issues making it a bad UX.</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><span class=""><div><br></div></span><div>Many people still associate ISO with MOS, but it is not true when using package based delivery approach. <br></div></div><div><br></div><div>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.</div><div><br></div><div>What do you guys think of it? </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div></font></span></div></blockquote><div><br></div><div>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?</div><div><br></div><div>-Alex</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div></div></font></span><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.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"><div>Dear colleagues,</div><div><br></div><div>The idea is to remove MOS DEB repo from the Fuel master node by default and use online MOS repo instead. Pros of such an approach are:</div><div><br></div><div>0) Reduced requirement for the master node minimal disk space</div><div>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</div><div>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. </div><div><br></div><div>Many people still associate ISO with MOS</div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div>[1] <a href="https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419" target="_blank">https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419</a></div><div>[2] <a href="https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115" target="_blank">https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115</a></div><span><font color="#888888"><div><br></div><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div>
</font></span></div>
</blockquote></div><br></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></div>