Re: [Openstack] Please stop the devstack non-sense!
Hi, we are facing two differents problems here. We have developers and final users, and both of them with different expectations about what to get from OpenStack. Developers wants an easy way to test untested code, new cool-probably-broken features and be able to change immediately - devstack is the perfect tool for this . On the other hand, final users just want a working easy to deploy system, without care if the latest cool-probably-broken feature is included (I bet they prefer it to not be). But the truth is that OpenStack can't ignore any of them. Nobody will use a program which is hard to install, deploy, test or develop on it. Some consensus will be necessary in the user side (I think we all agree that development is ok with devstack) As Justin pointed before, http://summit.openstack.org/sessions/view/26, can be a good starting point, defining a common set of minimums that every package should comply with (file/dir locations and perms, minimal contents of config files, users created, python external modules requiriments/ minimal versions, ...), so when someone complaint about something, we know that the installation has some minimal standards that it follows (just a quick idea that just came to my mind to help debugging users installations, a simple script, that use paste.openstack.org, and post there the config files, daemons runnings, last lines of some logs, version of pkgs installed...) Ghe Rivero On Wed, Mar 21, 2012 at 5:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Another idea: *http://meego.gitorious.org/meego-developer-tools/spectacle * That python code seems to be able to take a yaml defintion and generate either rpm specfiles or debian pkg files. It might be forked or extended (or both) and used to generate the initial set of package definitions for openstack in a non-pkg specific format... On 3/20/12 11:01 AM, Justin Santa Barbara jus...@fathomdb.com wrote: Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is next on my list - I was facing the problem that the number of replicas isn't changeable, though I have a patch for that now. If you'd like to work together, I'd love to collaborate (and that holds for anyone doing packaging). I'm hanging out in #openstack-packaging Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe Rivero *OpenStack Distribution Engineer **www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com ** | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante
Re: [Openstack] Please stop the devstack non-sense!
Ghe, while you're right that these two workloads are different, deployers need developers to use a representative environment during development, or the code doesn't work when it hits real deployments. We've now been bitten during our initial deployment of cactus, our upgrade to diablo, and our recent tests preparing for the essex upgrade because we can't run our management infrastructure on a single system. During cactus, we had issues when we tried to run multiple nova-network servers distinctly from the api service. IIRC during the diablo release, we had issues with keystone and horizon. This time, we had issues with glance/keystone integration. I'm not saying that things haven't improved, it just seems that each release has a new issue caused by the assumption that all services will be running on the same host. As we get more users with large deployments, these sorts of issues will only become a bigger deal, and will hinder large scale adoption. -nld On Wed, Mar 21, 2012 at 3:26 AM, Ghe Rivero ghe.riv...@stackops.com wrote: Hi, we are facing two differents problems here. We have developers and final users, and both of them with different expectations about what to get from OpenStack. Developers wants an easy way to test untested code, new cool-probably-broken features and be able to change immediately - devstack is the perfect tool for this . On the other hand, final users just want a working easy to deploy system, without care if the latest cool-probably-broken feature is included (I bet they prefer it to not be). But the truth is that OpenStack can't ignore any of them. Nobody will use a program which is hard to install, deploy, test or develop on it. Some consensus will be necessary in the user side (I think we all agree that development is ok with devstack) As Justin pointed before, http://summit.openstack.org/sessions/view/26, can be a good starting point, defining a common set of minimums that every package should comply with (file/dir locations and perms, minimal contents of config files, users created, python external modules requiriments/ minimal versions, ...), so when someone complaint about something, we know that the installation has some minimal standards that it follows (just a quick idea that just came to my mind to help debugging users installations, a simple script, that use paste.openstack.org, and post there the config files, daemons runnings, last lines of some logs, version of pkgs installed...) Ghe Rivero On Wed, Mar 21, 2012 at 5:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Another idea: *http://meego.gitorious.org/meego-developer-tools/spectacle * That python code seems to be able to take a yaml defintion and generate either rpm specfiles or debian pkg files. It might be forked or extended (or both) and used to generate the initial set of package definitions for openstack in a non-pkg specific format... On 3/20/12 11:01 AM, Justin Santa Barbara jus...@fathomdb.com wrote: Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is next on my list - I was facing the problem that the number of replicas isn't changeable, though I have a patch for that now. If you'd like to work together, I'd love to collaborate (and that holds for anyone doing packaging). I'm hanging out in #openstack-packaging Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe
Re: [Openstack] Please stop the devstack non-sense!
On 03/21/2012 08:48 PM, Narayan Desai wrote: Ghe, while you're right that these two workloads are different, deployers need developers to use a representative environment during development, or the code doesn't work when it hits real deployments. We've now been bitten during our initial deployment of cactus, our upgrade to diablo, and our recent tests preparing for the essex upgrade because we can't run our management infrastructure on a single system. During cactus, we had issues when we tried to run multiple nova-network servers distinctly from the api service. IIRC during the diablo release, we had issues with keystone and horizon. This time, we had issues with glance/keystone integration. I'm not saying that things haven't improved, it just seems that each release has a new issue caused by the assumption that all services will be running on the same host. As we get more users with large deployments, these sorts of issues will only become a bigger deal, and will hinder large scale adoption. -nld With my Debian Developer hat on, I'd like to send a reminder ... When Wheezy will be released, we'll have Essex in (if everything goes as planned). Then when Wheezy +1 gets out, will will also need to allow an upgrade path for Openstack (otherwise, it's considered an RC bug in Debian). And I believe that Ubuntu will have the issue as well (since 2012.4 will be an LTS, right?). I just hope that Openstacker will keep in mind how much of a commitment it is to allow upgrade from release to release + 4 (or +5) in a project like Openstack which goes so fast. :) Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
Narayan, I completely agree with you. Developers are our first line of defense, but they are not the only one. I would love to have different environments (development, SMB deployments, large scale deployments), where all of them have the same behavior, but i'm afraid there is already a long road that needs time. We will work on it and try to avoid problem like the one's you are facing from transitions from one release to another. Ghe Rivero On Wed, Mar 21, 2012 at 1:48 PM, Narayan Desai narayan.de...@gmail.comwrote: Ghe, while you're right that these two workloads are different, deployers need developers to use a representative environment during development, or the code doesn't work when it hits real deployments. We've now been bitten during our initial deployment of cactus, our upgrade to diablo, and our recent tests preparing for the essex upgrade because we can't run our management infrastructure on a single system. During cactus, we had issues when we tried to run multiple nova-network servers distinctly from the api service. IIRC during the diablo release, we had issues with keystone and horizon. This time, we had issues with glance/keystone integration. I'm not saying that things haven't improved, it just seems that each release has a new issue caused by the assumption that all services will be running on the same host. As we get more users with large deployments, these sorts of issues will only become a bigger deal, and will hinder large scale adoption. -nld On Wed, Mar 21, 2012 at 3:26 AM, Ghe Rivero ghe.riv...@stackops.comwrote: Hi, we are facing two differents problems here. We have developers and final users, and both of them with different expectations about what to get from OpenStack. Developers wants an easy way to test untested code, new cool-probably-broken features and be able to change immediately - devstack is the perfect tool for this . On the other hand, final users just want a working easy to deploy system, without care if the latest cool-probably-broken feature is included (I bet they prefer it to not be). But the truth is that OpenStack can't ignore any of them. Nobody will use a program which is hard to install, deploy, test or develop on it. Some consensus will be necessary in the user side (I think we all agree that development is ok with devstack) As Justin pointed before, http://summit.openstack.org/sessions/view/26, can be a good starting point, defining a common set of minimums that every package should comply with (file/dir locations and perms, minimal contents of config files, users created, python external modules requiriments/ minimal versions, ...), so when someone complaint about something, we know that the installation has some minimal standards that it follows (just a quick idea that just came to my mind to help debugging users installations, a simple script, that use paste.openstack.org, and post there the config files, daemons runnings, last lines of some logs, version of pkgs installed...) Ghe Rivero On Wed, Mar 21, 2012 at 5:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Another idea: *http://meego.gitorious.org/meego-developer-tools/spectacle * That python code seems to be able to take a yaml defintion and generate either rpm specfiles or debian pkg files. It might be forked or extended (or both) and used to generate the initial set of package definitions for openstack in a non-pkg specific format... On 3/20/12 11:01 AM, Justin Santa Barbara jus...@fathomdb.com wrote: Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is
[Openstack] Please stop the devstack non-sense!
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
Re: [Openstack] Please stop the devstack non-sense!
Try:
https://github.com/yahoo/Openstack-DevstackPy
Its our chance to make it right :-)
Contributions welcome ;-)
See features @ https://github.com/yahoo/Openstack-DevstackPy/wiki
And a beginner guide @
https://github.com/yahoo/Openstack-DevstackPy/wiki/Simple-Setup
Let the revolution begin! Haha :-P
On 3/20/12 9:40 AM, Thomas Goirand tho...@goirand.fr wrote:
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
Re: [Openstack] Please stop the devstack non-sense!
Hi Thomas, On Tue, Mar 20, 2012 at 4:40 PM, Thomas Goirand tho...@goirand.fr wrote: 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 screen is installed via packages and devstack don't assume it's already installed : https://github.com/openstack-dev/devstack/blob/master/files/apts/general 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). I haven't tested the xen support but for the default install, I have quickly spawned a VM on my laptop, downloaded devstack and ran it twice and except having to kill screen[1] between the two run it was actually the right thing (ie: redone the configuration). 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). we have the ENABLED_SERVICES= variable for that and we have lately fixed a lot of those bugs. (albeit it does indeed check-in nova currently for all services which is a bug that need to be fixed). Chmouel. [1] Which devstack had kindly advised me to do. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is next on my list - I was facing the problem that the number of replicas isn't changeable, though I have a patch for that now. If you'd like to work together, I'd love to collaborate (and that holds for anyone doing packaging). I'm hanging out in #openstack-packaging Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
On 03/21/2012 01:35 AM, Mark McLoughlin wrote: However, I do think devstack is seriously useful for upstream developers I have never denied that fact. :) Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
* Joshua Harlow (harlo...@yahoo-inc.com) wrote: https://github.com/yahoo/Openstack-DevstackPy Its our chance to make it right :-) Hopefully your session, or a joint session will make the Common development track so we can at least put to rest the best way to handle distro agnostic devstack. thanks, -chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
Yours might make sense to be added on to devstackPY. We have a concept of a persona (thanks! to dreamhost pep's) that might be what you want/use for this also: Features: Supports more than one distribution Currently RHEL 6.2 (with epel), Ubuntu 11.10 (12 WIP), Fedora 16 (WIP) Supports dry-run mode (to see what would happen) Supports varying installation personas (see conf/personas/devstack.sh.yaml) A single stack.ini file that shows configuration used/applied Supports install/uninstall/starting/stopping of OpenStack components. In various styles (daemonizing via forking, screen, upstart) Written in python so it matches the style of other OpenStack components. Extensively documented distribution specifics (see conf/distros/) Packages and pip (with versions known to work!) dependencies Any needed distribution specific actions (ie service names...) Follows standard software development practices (for everyones sanity). Functions, classes, objects and more (oh my!) Still readable by someone with limited python knowledge. The ability to be unit-tested! -Josh On 3/20/12 11:01 AM, Justin Santa Barbara jus...@fathomdb.com wrote: Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The background: I want a semi-production deployment, but as a developer I still want to be able to edit the code (which makes packages inconvenient). devstack is orientated towards e.g. wiping the databases. I'm hoping that all the various OS packagers can work together, or at least tell us what sucks. As a community, we should solve these problems once, and the OpenStack project shouldn't treat them as externalities. I've been doing some initial coding here: https://github.com/justinsb/openstack-simple-config The first use case I'm trying to solve is single node installation of OpenStack that is as easy as possible, but also isn't painting the user into the corner. Think apt-get openstack, then the user finds they like it and grows to a 4 node cluster, all the way up to a 100 node cluster. So it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is still quite opinionated! I have Keystone, Glance Nova installing. I'm using supervisord to avoid any OS dependencies/flamewars, but I would imagine that any OS packager could move it to their preferred init.d flavor easily. Swift is next on my list - I was facing the problem that the number of replicas isn't changeable, though I have a patch for that now. If you'd like to work together, I'd love to collaborate (and that holds for anyone doing packaging). I'm hanging out in #openstack-packaging Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
This is, indeed, the crux of the matter. The release cycle, for both diablo and essex, has been that all kinds of incompatible changes are made right until the end. During the critical month before release when we need as many people ad possible to deploy and test real clusters, documentation is not available. Devstack was a huge step forward in essex because it allowed people who already understood the differences between single and multi-node to understand and cope with the incompatible changes to the components in a way that was known (mostly) to be working. I would guess that for every person brave enough to publish their struggles on this list, there are many more who do not. The only ways I know to deal with this are: 1. More stability. Fewer incompatible changes. This will come over time. 2. Require blueprints, tagged as such, for every API and configuration change. Maintain a highly visible list. The other is longer release cycles with longer freeze periods but that is not going to happen. -David On 3/20/2012 2:57 PM, Michael Pittaro wrote: 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) I think you have hit the real issue of documentation right here. Devstack has become a lightning rod for install and configuration problems. However, I think the real problem is lack of detailed configuration and installation information - for development, packagers, and real world installations. devstack is just not appropriate as a complete replacement for documentation and dependencies. Install and configuration documentation is an area we need to focus on more, and it will need much more community involvement to really make a difference. The situation is currently much better than it was back in September 2011, so progress _is_ being made. Having said that, the Devstack-Py [1] is an alternative project which is progressing along nicely. It is intended to support multiple distributions, with a focus on developer installs. Not 100% there yet for all scenarios, but usable and definitely more hackable. [1] https://launchpad.net/devstackpy Mike ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
On Tue, Mar 20, 2012 at 3:14 PM, Chris Wright chr...@sous-sol.org wrote: * Joshua Harlow (harlo...@yahoo-inc.com) wrote: https://github.com/yahoo/Openstack-DevstackPy Its our chance to make it right :-) Hopefully your session, or a joint session will make the Common development track so we can at least put to rest the best way to handle distro agnostic devstack. thanks, -chris Not sure what the intent here is, but putting to rest sounds ominous ;-) As members of a large and diverse open source project and members of the larger open source ecosystem, innovation should be embraced. Just because a decision is made in one cycle, doesn't mean that's the best way to do something from then on. I would encourage us, as a group, not to seek (or get chased into) the rut of dogmatism... But, perhaps you just meant: let's get some consensus from project leaders on the recommended way for now -- and that sounds great to me ;-) d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
* Duncan McGreggor (dun...@dreamhost.com) wrote: But, perhaps you just meant: let's get some consensus from project leaders on the recommended way for now -- and that sounds great to me ;-) Yup, nothing ominous, just community concensus ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
