<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 20, 2013, at 3:13 PM, Joe Topjian <<a href="mailto:joe.topjian@cybera.ca">joe.topjian@cybera.ca</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Ed,<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
Well its certainly more basic in that it has fewer nodes...</div></blockquote><div><br></div><div style="">Only one less node. I felt that the Quantum controller parts make sense on the cloud controller -- especially for a basic install guide. </div>
<div style=""><br></div></div></div></div></blockquote><div><br></div><div>You could make the same point about compute nodes and just do an all in one install.</div><div><br></div><div>This goes to your point about opinions….</div><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">If one does have a good reason to do this, it will not be hard to describe in a separate document using the first as a reference. </div><div> </div></div></div></div></blockquote><div><br></div><div>well thats just it…you would have to copy and merge to accomplish this.. Crack open the previous nodes..uninstall software…</div><div>alter configs right down to the hosts files..</div><div><br></div><br><blockquote type="cite"><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 style="word-wrap:break-word"><div class="im"><span style="color:rgb(34,34,34)">well from the quantum side the answer would certainly be no. </span><br></div><div><br></div><div>No sep management network. </div>
</div></blockquote><div><br></div><div style="">I didn't feel there was a need for this in a basic install guide. This guide shows a "data network" which lays the groundwork for multiple other networks. For example, the data network can be a 10gb connection. The basic guide assumes one type of traffic, though it's not a far stretch to turn that into separated traffic using VLANs but still be on the physical network.</div>
<div> </div></div></div></div></blockquote><div><br></div><div>One data network lays the groundwork for multiple data networks…control/data separation is a different nut.</div><div><br></div><br><blockquote type="cite"><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 style="word-wrap:break-word"><div>No connection (even temporary for the compute nodes to reach the outside world to load packages)</div>
<div>muddling network and control functionality.</div></div></blockquote><div><br></div><div style="">Instances have NAT'd guest access at the end of this guide. The only thing missing is Floating IPs but that's because I felt I ran out of time. I can work on this in the next week.</div>
<div style=""><br></div><div style="">Regarding compute node connectivity, this is true and it's something I overlooked. I can easily modify this document to show how the cloud controller can NAT traffic for the compute node. Or the compute node could be given its own gateway - however, I'm not sure what the status of multi-host quantum networking is, so that's why I tunneled all instance traffic to the cloud controller.</div>
<div> </div></div></div></div></blockquote><div><br></div><div>Its there…and i haven't even read to the point of how you have configure quantum so won't comment on that.</div><div><br></div><br><blockquote type="cite"><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 style="word-wrap:break-word"><div>In the old form there was at least some room to say "Follow this guide except for the quantum bits"<br>
</div><div>Now that while you've accomplished your goal of lean and mean I'm going to need folks to go back </div><div>altering host files, altering the db and endpoints…as well as all the changes to re-create the mgmt network.</div>
</div></blockquote><div><br></div><div style="">This guide is all about foundation. It shows the reader how to install the various OpenStack components using the ubuntu cloud archive, what configuration files for each component need edited, how to make them all work together, and successfully launch an instance.</div>
<div style=""><br></div></div></div></div></blockquote><div><br></div><div>Yup (assume technical details are correct, having faith on that right now) and you have done that for foundational knowledge of how to</div><div>pull the packages and what files to edit.</div><div><br></div><div>Guess I was hoping for more a foundational basic TEMPLATE install that the various openstack packages could build their docs on top</div><div>of to show their features and use cases.</div><div>That in no way makes this doc useless/bad/harmful or any other negative. </div><div>Its just not what I was hoping would come out of this.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">After someone goes through this guide, I think it's safe to say that they will understand what you're trying to accomplish when you alter this installation and why you're doing it. </div>
<div><br></div></div></div></div></blockquote><div><br></div><div>Yeah but ill tell you joe..if I knew this was what you were after I probably would have suggested you just run people through a devstack install</div><div>and walk them through specifics of certain config files post install...</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">I fully understand that everyone has their own opinion about what an install guide should look like. This is an unfortunate effect of the lack of intelligent packages used to install OpenStack. This is my take on it. I tried to place myself in a new user's shoes when writing and if I felt that the user simply didn't need to know about a certain area at their novice stage, I took it out. </div>
<div><br></div></div></div></div></blockquote><div><br></div><div>So couldn't agree more about what your saying about opinions and ill be the first to admit i could be jaded with my networking </div><div>desires and use cases so if this is really the style install that novice users are looking for than awesome.</div><div><br></div><div>No knowledge is bad knowledge and barring any real technical mistakes (which hopefully will get fleshed out if they exist) its all good.</div><div><br></div><div>Worst case if people choose this guide by "mistake" for what they want or are hoping for they will still learn something and making the</div><div>guide as terse as you have will make their experience a very quick one.</div><div><br></div><div>Ed</div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">Thanks,</div><div style="">Joe</div><div><br></div></div><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca/" target="_blank">www.cybera.ca</a></div>
<div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
</div></div>
</blockquote></div><br></body></html>