openstack team mailing list archive

[Thomas Goirand <thomas@xxxxxxxxxx>]

Hi!

I'm again and again always told that I should use Devstack. I don't
agree, and I'd like to share why. The use of devstack, IMO, has gone out
of proportions, and it shouldn't have go more far than a Jenkins job.

I'm trying to be constructive and point out issues, hoping it will be
taken the correct way by the community. (I'm going counter-stream here.)

Here's the kind of answer I got privately. And that's just as an
example, I could have taken it from someone else. In fact, the persons
who wrote that to me were *really* helpful, and I am very thankful for
their help. (note: removed names since it's of no use for the point I am
willing to make)

Somebody wrote to me:
> I replied:
>> Somebody wrote to me:
>>> I just read in another post of yours that you do not use DevStack.
>>>
>>> Unfortunately resources are tight, and we only work on a number of
>>> possible deployment scenarios and DevStack is one of them. Any
>>> reason why you do not use devstack?
>>
>> Because I'm a Debian Developer working on the packaging of both
>> Openstack and XCP. I'm the one who uploaded XCP (and the other 7
>> packages it needs) in Debian.
>
> I see...
>
> but wouldn't be a better use of anyone's time if you get a hang of how
> things fit together by playing with what it's currently documented
> (albeit in a patchy way?), so that you can come on the mailing list
> with a more accurate description of what the problems are? We can't
> help otherwise.
>
>> So what I want to test is the packaging, not to see if Devstack is
>> written properly...
>
> Your strict attitude is not going to get you anywhere. I could say
> that I want to test DevStack/OpenStack on Ubuntu and I don't give a
> damn about your Debian problems, but I don't, because I care and want
> to help you getting on with OpenStack regardless. Using devstack is
> not the final goal, is just a mean for you to get where you wanna be.

Let me explain.

Devstack, and in my case, the XenServer part of it, makes very dangerous
assumptions. Here they are:
- running XenServer (and not Kronos)
- It will be XenServer 5.6 (and not the latest XCP or XenServer)
- dom0 is running CentOS
- locales are set to English (well, lucky that's the case, but it well
could be that the "ifconfig" call of devstack would fail...).
- running under Ubuntu, or be willing to use non-packaged stuff

A few examples. There's yum calls in the XenServer dom0 scripts, as well
as (even more horrifying) getting a random git version from
googlecode.com, building and "make install", without even checking if my
build environment is sane. There's stuff like echo "FORWARD_IPV4=YES" >>
/etc/sysconfig/network (in Debian, you'd edit /etc/sysctl.conf and run
"sysctl -p). Even the XCP calls are wrong: xe sr-list --minimal
name-label="Local storage" will not return anything on my setup, because
my name-label for the local storage is different (and frankly, why
imposing such name-label when there's a default SR thing?).

Another example. Look at the first bit of the build_domU.sh. It does
start the create_network function, which does this:

if [ ! $(xe network-list --minimal params=bridge | grep -w
--only-matching $br) ]
then
  echo "Specified bridge $br does not exist"
  echo "If you wish to use defaults, please keep the bridge name empty"
  exit 1

Unfortunately, Kronos, which is newer than XenServer 5.6, doesn't create
a bridge when you create a new network. It only creates it when you need
a new interface to join it.

The consequence is very simple: it doesn't work!!!

And that's just the first step, later it's the same kind. It's like this
all-over. Frankly, this is totally unusable in my configuration.

All this is just a big a hack which works only in specific cases. When I
read in the openstack list that some want to make this hack official, I
am simply horrified. Even the very simple ifconfig call to get the IP
address is done wrongly (it's missing LC_ALL=C), and there's lots of
this kind of assumption.

The same mess applies in the devstack not-for-XenServer. In some cases,
some tools are apt-get installed. I can see for example 'apt-get install
sudo'. But stack.sh assumes (god knows why) that "screen" is already
installed. For an unknown reason, stack.sh will also try to write
#includedir /etc/sudoers.d in the sudoers file (isn't it supposed to be
there by default?). I've been reading about "non-apt" distro, but I
believe that it's only Ubuntu centric in fact:
if [[ ! ${DISTRO} =~ (oneiric|precise) ]]; then
	...
	exit 1
which I think is going too far.

Frankly, this devstack stuff is just a big hack. Nothing is really
structured with functions. It's not really possible to run the scripts
twice either (it's not idempotent, AFAIC).

Yes, one can read the devstack scripts and try to understand how it
works. But it's not easy to follow when you don't know what it's
supposed to be doing. And let's say one could read and type what it
does, while adapting it to an environment (Openstack + Kronos in SID, in
my case), that doesn't give explanations of why things are like that,
and what kind of configuration choice the user may have. That doesn't
help either to write a proper documentation or explaining to users how
all this is supposed to work.

What's making it even worse, is that many people are telling that this
non-sense scripting is supposed to be a *DOCUMENTATION* ?!? There's
absolutely *nothing* in the scripts that is explaining why things are
done. There's comments like this:

# Create vlans for vm and management
create_vlan $PUB_DEV $PUB_VLAN $PUB_NET
create_vlan $VM_DEV $VM_VLAN $VM_NET
create_vlan $MGT_DEV $MGT_VLAN $MGT_NET

or (in stack.sh):
# Install and start mysql-server
apt_get install mysql-server

How about just removing the comment on top of the create_vlan calls?
They don't explain anything at all. Absolutely everything is like this
in the scripts. Things are done, but nothing explains what will be the
consequences, what can be done differently, etc.

It's as if in C, you would write:

a = b; // Move the content of b into a.

Thanks, I know the C language, and I understand what I read. Now, *WHY*
are we moving the content b into a is the interesting bit which is missing.

And I've been told again, again and again, please use Devstack, because
this is tested. I'd reply that it has been tested in a few cases, which
matches some of the developers. These scripts are broken in my
environment. Reading the scripts doesn't help me to understand. That
doesn't help me to test my packages. That doesn't help me to write
documentation.

I also think that developers should be using a packaged installation,
and not just a local checkout. There are many things that can happen
between the packaged environment and the git checkout. What I
experienced with the Python script rights and the dhcpbridge script
being searched in /usr/share/python2.7/dists/bin (sic!) is a very good
example of this.

I don't think anyway that if you are a developer, you will be working on
absolutely all packages (nova, glance, keystone, swift, quantum...) that
we have available in Openstack. In most cases, you'd be working on *one*
of the Git checkout, and the rest of could well be downloaded and
installed, either through the PPA, or from Ubuntu directly. So why using
devstack which will checkout absolutely all components from Github? This
doesn't make sense either. Also, if this continues, none of the
developers will be testing the final result (eg: the packages).

And finally, absolutely nothing prevents you from using Git and using
the packaged version of all openstack modules. In Debian, we always use
git for packaging, and git-buildpackage, which uses the source code from
Github.

Last, the attitude to say "please use devstack" to our users will stop
among the community. This is *not* an answer to our users either.

Is Devstack helpful? I'm sure it is, but for developers only. It's just
bad to think about it as "self-documenting" Openstack, or to think that
it's the solution for everything. It has never been its purpose, and it
isn't taking that path, and thinking that it does is a huge mistake.

Hoping that I will be heard and understood,

Thomas Goirand (zigo)

P.S: there's no aggressiveness intended above, I'm just trying to make a
point. And it's not directed to anyone in particular, but to everyone
pushing for devstack (IMO) too much, and making it very difficult for
both users, people writing documentation or packaging (I'm both 3 at
same time).