<HTML>
<HEAD>
<TITLE>Re: [Openstack] Please stop the devstack non-sense!</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Try:<BR>
<BR>
<a href="https://github.com/yahoo/Openstack-DevstackPy">https://github.com/yahoo/Openstack-DevstackPy</a><BR>
<BR>
Its our chance to make it right :-)<BR>
<BR>
Contributions welcome ;-)<BR>
<BR>
See features @ <a href="https://github.com/yahoo/Openstack-DevstackPy/wiki">https://github.com/yahoo/Openstack-DevstackPy/wiki</a><BR>
<BR>
And a beginner guide @ <a href="https://github.com/yahoo/Openstack-DevstackPy/wiki/Simple-Setup">https://github.com/yahoo/Openstack-DevstackPy/wiki/Simple-Setup</a><BR>
<BR>
Let the revolution begin! Haha :-P<BR>
<BR>
On 3/20/12 9:40 AM, "Thomas Goirand" <<a href="thomas@goirand.fr">thomas@goirand.fr</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi!<BR>
<BR>
I'm again and again always told that I should use Devstack. I don't<BR>
agree, and I'd like to share why. The use of devstack, IMO, has gone out<BR>
of proportions, and it shouldn't have go more far than a Jenkins job.<BR>
<BR>
I'm trying to be constructive and point out issues, hoping it will be<BR>
taken the correct way by the community. (I'm going counter-stream here.)<BR>
<BR>
Here's the kind of answer I got privately. And that's just as an<BR>
example, I could have taken it from someone else. In fact, the persons<BR>
who wrote that to me were *really* helpful, and I am very thankful for<BR>
their help. (note: removed names since it's of no use for the point I am<BR>
willing to make)<BR>
<BR>
Somebody wrote to me:<BR>
> I replied:<BR>
>> Somebody wrote to me:<BR>
>>> I just read in another post of yours that you do not use DevStack.<BR>
>>><BR>
>>> Unfortunately resources are tight, and we only work on a number of<BR>
>>> possible deployment scenarios and DevStack is one of them. Any<BR>
>>> reason why you do not use devstack?<BR>
>><BR>
>> Because I'm a Debian Developer working on the packaging of both<BR>
>> Openstack and XCP. I'm the one who uploaded XCP (and the other 7<BR>
>> packages it needs) in Debian.<BR>
><BR>
> I see...<BR>
><BR>
> but wouldn't be a better use of anyone's time if you get a hang of how<BR>
> things fit together by playing with what it's currently documented<BR>
> (albeit in a patchy way?), so that you can come on the mailing list<BR>
> with a more accurate description of what the problems are? We can't<BR>
> help otherwise.<BR>
><BR>
>> So what I want to test is the packaging, not to see if Devstack is<BR>
>> written properly...<BR>
><BR>
> Your strict attitude is not going to get you anywhere. I could say<BR>
> that I want to test DevStack/OpenStack on Ubuntu and I don't give a<BR>
> damn about your Debian problems, but I don't, because I care and want<BR>
> to help you getting on with OpenStack regardless. Using devstack is<BR>
> not the final goal, is just a mean for you to get where you wanna be.<BR>
<BR>
Let me explain.<BR>
<BR>
Devstack, and in my case, the XenServer part of it, makes very dangerous<BR>
assumptions. Here they are:<BR>
- running XenServer (and not Kronos)<BR>
- It will be XenServer 5.6 (and not the latest XCP or XenServer)<BR>
- dom0 is running CentOS<BR>
- locales are set to English (well, lucky that's the case, but it well<BR>
could be that the "ifconfig" call of devstack would fail...).<BR>
- running under Ubuntu, or be willing to use non-packaged stuff<BR>
<BR>
A few examples. There's yum calls in the XenServer dom0 scripts, as well<BR>
as (even more horrifying) getting a random git version from<BR>
googlecode.com, building and "make install", without even checking if my<BR>
build environment is sane. There's stuff like echo "FORWARD_IPV4=YES" >><BR>
/etc/sysconfig/network (in Debian, you'd edit /etc/sysctl.conf and run<BR>
"sysctl -p). Even the XCP calls are wrong: xe sr-list --minimal<BR>
name-label="Local storage" will not return anything on my setup, because<BR>
my name-label for the local storage is different (and frankly, why<BR>
imposing such name-label when there's a default SR thing?).<BR>
<BR>
Another example. Look at the first bit of the build_domU.sh. It does<BR>
start the create_network function, which does this:<BR>
<BR>
if [ ! $(xe network-list --minimal params=bridge | grep -w<BR>
--only-matching $br) ]<BR>
then<BR>
echo "Specified bridge $br does not exist"<BR>
echo "If you wish to use defaults, please keep the bridge name empty"<BR>
exit 1<BR>
<BR>
Unfortunately, Kronos, which is newer than XenServer 5.6, doesn't create<BR>
a bridge when you create a new network. It only creates it when you need<BR>
a new interface to join it.<BR>
<BR>
The consequence is very simple: it doesn't work!!!<BR>
<BR>
And that's just the first step, later it's the same kind. It's like this<BR>
all-over. Frankly, this is totally unusable in my configuration.<BR>
<BR>
All this is just a big a hack which works only in specific cases. When I<BR>
read in the openstack list that some want to make this hack official, I<BR>
am simply horrified. Even the very simple ifconfig call to get the IP<BR>
address is done wrongly (it's missing LC_ALL=C), and there's lots of<BR>
this kind of assumption.<BR>
<BR>
The same mess applies in the devstack not-for-XenServer. In some cases,<BR>
some tools are apt-get installed. I can see for example 'apt-get install<BR>
sudo'. But stack.sh assumes (god knows why) that "screen" is already<BR>
installed. For an unknown reason, stack.sh will also try to write<BR>
#includedir /etc/sudoers.d in the sudoers file (isn't it supposed to be<BR>
there by default?). I've been reading about "non-apt" distro, but I<BR>
believe that it's only Ubuntu centric in fact:<BR>
if [[ ! ${DISTRO} =~ (oneiric|precise) ]]; then<BR>
...<BR>
exit 1<BR>
which I think is going too far.<BR>
<BR>
Frankly, this devstack stuff is just a big hack. Nothing is really<BR>
structured with functions. It's not really possible to run the scripts<BR>
twice either (it's not idempotent, AFAIC).<BR>
<BR>
Yes, one can read the devstack scripts and try to understand how it<BR>
works. But it's not easy to follow when you don't know what it's<BR>
supposed to be doing. And let's say one could read and type what it<BR>
does, while adapting it to an environment (Openstack + Kronos in SID, in<BR>
my case), that doesn't give explanations of why things are like that,<BR>
and what kind of configuration choice the user may have. That doesn't<BR>
help either to write a proper documentation or explaining to users how<BR>
all this is supposed to work.<BR>
<BR>
What's making it even worse, is that many people are telling that this<BR>
non-sense scripting is supposed to be a *DOCUMENTATION* ?!? There's<BR>
absolutely *nothing* in the scripts that is explaining why things are<BR>
done. There's comments like this:<BR>
<BR>
# Create vlans for vm and management<BR>
create_vlan $PUB_DEV $PUB_VLAN $PUB_NET<BR>
create_vlan $VM_DEV $VM_VLAN $VM_NET<BR>
create_vlan $MGT_DEV $MGT_VLAN $MGT_NET<BR>
<BR>
or (in stack.sh):<BR>
# Install and start mysql-server<BR>
apt_get install mysql-server<BR>
<BR>
How about just removing the comment on top of the create_vlan calls?<BR>
They don't explain anything at all. Absolutely everything is like this<BR>
in the scripts. Things are done, but nothing explains what will be the<BR>
consequences, what can be done differently, etc.<BR>
<BR>
It's as if in C, you would write:<BR>
<BR>
a = b; // Move the content of b into a.<BR>
<BR>
Thanks, I know the C language, and I understand what I read. Now, *WHY*<BR>
are we moving the content b into a is the interesting bit which is missing.<BR>
<BR>
And I've been told again, again and again, please use Devstack, because<BR>
this is tested. I'd reply that it has been tested in a few cases, which<BR>
matches some of the developers. These scripts are broken in my<BR>
environment. Reading the scripts doesn't help me to understand. That<BR>
doesn't help me to test my packages. That doesn't help me to write<BR>
documentation.<BR>
<BR>
I also think that developers should be using a packaged installation,<BR>
and not just a local checkout. There are many things that can happen<BR>
between the packaged environment and the git checkout. What I<BR>
experienced with the Python script rights and the dhcpbridge script<BR>
being searched in /usr/share/python2.7/dists/bin (sic!) is a very good<BR>
example of this.<BR>
<BR>
I don't think anyway that if you are a developer, you will be working on<BR>
absolutely all packages (nova, glance, keystone, swift, quantum...) that<BR>
we have available in Openstack. In most cases, you'd be working on *one*<BR>
of the Git checkout, and the rest of could well be downloaded and<BR>
installed, either through the PPA, or from Ubuntu directly. So why using<BR>
devstack which will checkout absolutely all components from Github? This<BR>
doesn't make sense either. Also, if this continues, none of the<BR>
developers will be testing the final result (eg: the packages).<BR>
<BR>
And finally, absolutely nothing prevents you from using Git and using<BR>
the packaged version of all openstack modules. In Debian, we always use<BR>
git for packaging, and git-buildpackage, which uses the source code from<BR>
Github.<BR>
<BR>
Last, the attitude to say "please use devstack" to our users will stop<BR>
among the community. This is *not* an answer to our users either.<BR>
<BR>
Is Devstack helpful? I'm sure it is, but for developers only. It's just<BR>
bad to think about it as "self-documenting" Openstack, or to think that<BR>
it's the solution for everything. It has never been its purpose, and it<BR>
isn't taking that path, and thinking that it does is a huge mistake.<BR>
<BR>
Hoping that I will be heard and understood,<BR>
<BR>
Thomas Goirand (zigo)<BR>
<BR>
P.S: there's no aggressiveness intended above, I'm just trying to make a<BR>
point. And it's not directed to anyone in particular, but to everyone<BR>
pushing for devstack (IMO) too much, and making it very difficult for<BR>
both users, people writing documentation or packaging (I'm both 3 at<BR>
same time).<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>