Re: [Openstack] Proposal for new devstack (v2?)
On 01/24/2012 12:35 AM, Joshua Harlow wrote: So some of the issues after doing a comparison might be the following: For RHEL6 + EPEL a lot of the packages are there (yippe!). Yes there has been lots of work in this area. See here for details: https://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pkgs Some issues which the EPEL people’s might be able to resolve: db.json Seems ok. general.json euca2ools is much newer in ubuntu (2.0.0~bzr464-0ubuntu2 vs 1.3.1-12.el6). python-coverage does not seem to exist in EPEL (or at least my repo setup). That would be useful to have for testing (and CI). python-pip versions (1.0-1 vs 0.8-1.el6) python-nose versions (1.0.0-1ubuntu1 vs 0.10.4-3.1.el6) glance.json python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) Note EPEL has parallel installable versions, so that there is no clash with RHEL versions. The openstack packages within EPEL explicitly select the parallel versions like: http://pkgs.fedoraproject.org/gitweb/?p=openstack-nova.git;a=blob_plain;f=openstack-nova-newdeps.patch;hb=el6 You can see the corresponding python-sqlalchemy0.7 and python-webob1.0 packages within EPEL. python-wsgiref does not seem to exist in rhel6 (?) Well it's not used by openstack-glance in EPEL at least. python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-httplib2 versiosn (0.7.1-1ubuntu1 vs 0.4.0-5.el6) horizon.json mod_wsgi versions (3.3-2ubuntu3 vs 3.2-1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) Parallel versions in EPEL as mentioned python-cherrypy3 does not exist python-django-mailer does not exist python-django-nose does not exist Yes, these 3 might be candidates for EPEL. python-migrate versions (0.7.1-1 vs 0.6-6.el6) 0.6-6.el6 has been patched to support sqlalchemy 0.7 keystone-client.json/nova-client.json Should be ok. keystone.json python-lxml versions (2.3-0.1build1 vs 2.2.3-1.1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-sqlite2 versions (2.6.3-2 vs 2.3.5-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) libldap2-dev and libsasl2-dev equivalents?? n-cpu.json/n-vol.json (nova cpu/volume) Should be ok n-vnc.json (nova novnc) python-numpy does not seem to exist nova.json python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-lxml versions (2.7.8.dfsg-4 vs 2.2.3-1.1.el6) libvirt versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) vlan package? python-migrate versions (0.7.1-1 vs 0.6-6.el6) python-gflags versions (1.5.1-1 vs 1.4-3.el6) libvirt-python versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-tempita versions (0.5.1-1 vs 0.4-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) I will start to get the tests going to see if the version differences are actually a problem. I am assuming large version differences will be an issue. But its hard to tell how much of an issue yet. But it would be really great if we could just get all those up to the same versions. Then possibly in the future we can get RHEL6 (or equiv) hooked into the CI pipeline to ensure that new versions/packages work on all distributions that openstack wants to support. That way it ensures that packages and versions are uniform (or as close to possible to uniform) and will work with the supported code. glance and nova should work well on RH6.2 + EPEL at least. cheers, Pádraig. ___ 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] Proposal for new devstack (v2?)
On 01/17/2012 08:20 PM, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: 1. Add in enough abstraction so that you can look at how each component is installed/uninstalled/started/stopped by looking at a single file (maybe 2 files) 2. Have the ability to start/stop in different manners (not always screen) 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) 4. Increase the level of documentation (probably not going to be in the end, inline like what is in devstack, since that just doesn't seem maintainable in the long-term) * This may mean having documentation created similar to nova, glance, as a separate documentation document/page Still be simple enough to run and use so that the non-python dev can install from trunk without having to understand what is going on. -Josh I was looking into how easy it would be to support openSUSE / SLES in devstack v2 and saw that there are currently 17 json files containing package names (with 293 versions) for ubuntu-oneiric and rhel-6. Shouldn't there be some better way than to list all this redundant information there, which makes it hard to maintain/extend? E.g. the distro's package manager already knows about dependencies and usually has just one version of a package for a given distribution anyway. And there was even one project about mapping package-names of one Linux distribution to another: http://enricozini.org/2011/debian/distromatch/ So it should be possible to build upon it, and just list packages once. Ciao Bernhard M. ___ 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] Proposal for new devstack (v2?)
Ok, I was using 6.1. Is there any reason that it isn't available for 6.1 and 6.2 (technically?) It would be nice to not have to distinguish (6.1 vs 6.2) in the new devstack v2. My guess is the list I created then was using the 6.1 repo, which may not have those pkgs (darn it). mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6arch=$basearch -Josh On 1/24/12 2:33 AM, Pádraig Brady pbr...@redhat.com wrote: On 01/24/2012 12:35 AM, Joshua Harlow wrote: So some of the issues after doing a comparison might be the following: For RHEL6 + EPEL a lot of the packages are there (yippe!). Yes there has been lots of work in this area. See here for details: https://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pkgs Some issues which the EPEL people's might be able to resolve: db.json Seems ok. general.json euca2ools is much newer in ubuntu (2.0.0~bzr464-0ubuntu2 vs 1.3.1-12.el6). python-coverage does not seem to exist in EPEL (or at least my repo setup). That would be useful to have for testing (and CI). python-pip versions (1.0-1 vs 0.8-1.el6) python-nose versions (1.0.0-1ubuntu1 vs 0.10.4-3.1.el6) glance.json python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) Note EPEL has parallel installable versions, so that there is no clash with RHEL versions. The openstack packages within EPEL explicitly select the parallel versions like: http://pkgs.fedoraproject.org/gitweb/?p=openstack-nova.git;a=blob_plain;f=openstack-nova-newdeps.patch;hb=el6 You can see the corresponding python-sqlalchemy0.7 and python-webob1.0 packages within EPEL. python-wsgiref does not seem to exist in rhel6 (?) Well it's not used by openstack-glance in EPEL at least. python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-httplib2 versiosn (0.7.1-1ubuntu1 vs 0.4.0-5.el6) horizon.json mod_wsgi versions (3.3-2ubuntu3 vs 3.2-1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) Parallel versions in EPEL as mentioned python-cherrypy3 does not exist python-django-mailer does not exist python-django-nose does not exist Yes, these 3 might be candidates for EPEL. python-migrate versions (0.7.1-1 vs 0.6-6.el6) 0.6-6.el6 has been patched to support sqlalchemy 0.7 keystone-client.json/nova-client.json Should be ok. keystone.json python-lxml versions (2.3-0.1build1 vs 2.2.3-1.1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-sqlite2 versions (2.6.3-2 vs 2.3.5-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) libldap2-dev and libsasl2-dev equivalents?? n-cpu.json/n-vol.json (nova cpu/volume) Should be ok n-vnc.json (nova novnc) python-numpy does not seem to exist nova.json python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-lxml versions (2.7.8.dfsg-4 vs 2.2.3-1.1.el6) libvirt versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) vlan package? python-migrate versions (0.7.1-1 vs 0.6-6.el6) python-gflags versions (1.5.1-1 vs 1.4-3.el6) libvirt-python versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-tempita versions (0.5.1-1 vs 0.4-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) I will start to get the tests going to see if the version differences are actually a problem. I am assuming large version differences will be an issue. But its hard to tell how much of an issue yet. But it would be really great if we could just get all those up to the same versions. Then possibly in the future we can get RHEL6 (or equiv) hooked into the CI pipeline to ensure that new versions/packages work on all distributions that openstack wants to support. That way it ensures that packages and versions are uniform (or as close to possible to uniform) and will work with the supported code. glance and nova should work well on RH6.2 + EPEL at least. cheers, Pádraig. ___ 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] Proposal for new devstack (v2?)
On 01/24/2012 06:39 PM, Joshua Harlow wrote: Ok, I was using 6.1. Is there any reason that it isn’t available for 6.1 and 6.2 (technically?) Well it's not been tested on 6.1 currently. One issue with 6.1 is the version of libvirt is too old I think. cheers, Pádraig. ___ 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] Proposal for new devstack (v2?)
Ok dokie, Let me see what I can do to get a 6.2 system. Thx. On 1/24/12 1:53 PM, Pádraig Brady p...@draigbrady.com wrote: On 01/24/2012 06:39 PM, Joshua Harlow wrote: Ok, I was using 6.1. Is there any reason that it isn't available for 6.1 and 6.2 (technically?) Well it's not been tested on 6.1 currently. One issue with 6.1 is the version of libvirt is too old I think. cheers, Pádraig. ___ 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] Proposal for new devstack (v2?)
On Sat, Jan 21, 2012 at 5:47 AM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Note rhel6 isn’t fully there yet. But in progress ;)
Anyone working on fedora version of it? Any known major issues
preventing it? I quickly added fedora labels next to RHEL6 in the
code, and added db.py stuff. By quick test it does nova mysql config,
and then stops at rabbitmq password change for command returning exit
code2.
diff --git a/conf/pkgs/db.json b/conf/pkgs/db.json
index b044d10..d684551 100644
--- a/conf/pkgs/db.json
+++ b/conf/pkgs/db.json
@@ -66,5 +66,35 @@
}
]
}
+},
+fedora-16: {
+mysql: {
+version: 5.5.18-1.fc16,
+allowed: =,
+removable: true
+},
+mysql-server: {
+version: 5.5.18-1.fc16,
+allowed: =,
+removable: true,
+post-install: [
+{
+# Make sure it'll start on reboot
+run_as_root: true,
+cmd : [ chkconfig, mysqld, on]
+},
+{
+# Start the mysql service
+run_as_root: true,
+cmd : [ service, mysqld, start]
+},
+{
+# Set the root password
+run_as_root: true,
+cmd : [ mysqladmin, -u, root,
+ password, %PASSWORD% ]
+}
+]
+}
}
}
diff --git a/devstack/components/db.py b/devstack/components/db.py
index b694397..9895e0b 100644
--- a/devstack/components/db.py
+++ b/devstack/components/db.py
@@ -28,10 +28,10 @@ MYSQL = 'mysql'
DB_ACTIONS = {
MYSQL: {
#hopefully these are distro independent, these should be since they are invoking system init scripts
-'start': [service, mysql, 'start'],
-'stop': [service, 'mysql', stop],
-'status': [service, 'mysql', status],
-'restart': [service, 'mysql', status],
+'start': [service, mysqld, 'start'],
+'stop': [service, 'mysqld', stop],
+'status': [service, 'mysqld', status],
+'restart': [service, 'mysqld', status],
#
'create_db': ['mysql', '--user=%USER%', '--password=%PASSWORD%', '-e', 'CREATE DATABASE %DB%;'],
'drop_db': ['mysql', '--user=%USER%', '--password=%PASSWORD%', '-e', 'DROP DATABASE IF EXISTS %DB%;'],
diff --git a/devstack/progs/actions.py b/devstack/progs/actions.py
index 7478a52..9bf17ff 100644
--- a/devstack/progs/actions.py
+++ b/devstack/progs/actions.py
@@ -43,6 +43,7 @@ LOG = logging.getLogger(devstack.progs.actions)
_PKGR_MAP = {
settings.UBUNTU11: apt.AptPackager,
settings.RHEL6: yum.YumPackager,
+settings.FEDORA16: yum.YumPackager,
}
# This is used to map an action to a useful string for
diff --git a/devstack/settings.py b/devstack/settings.py
index 305ad55..534b6dd 100644
--- a/devstack/settings.py
+++ b/devstack/settings.py
@@ -25,6 +25,7 @@ LOG = logging.getLogger(devstack.settings)
# ie in the pkg/pip listings so update there also!
UBUNTU11 = ubuntu-oneiric
RHEL6 = rhel-6
+FEDORA16 = fedora-16
# What this program is called
PROG_NICE_NAME = DEVSTACK
@@ -36,7 +37,8 @@ POST_INSTALL = 'post-install'
# Default interfaces for network ip detection
IPV4 = 'IPv4'
IPV6 = 'IPv6'
-DEFAULT_NET_INTERFACE = 'eth0'
+#DEFAULT_NET_INTERFACE = 'eth0'
+DEFAULT_NET_INTERFACE = 'br_iscsi'
DEFAULT_NET_INTERFACE_IP_VERSION = IPV4
# Component name mappings
@@ -120,6 +122,7 @@ STACK_CONFIG_LOCATION = os.path.join(STACK_CONFIG_DIR, stack.ini)
KNOWN_DISTROS = {
UBUNTU11: re.compile('Ubuntu(.*)oneiric', re.IGNORECASE),
RHEL6: re.compile('redhat-6\.(\d+)', re.IGNORECASE),
+FEDORA16: re.compile('fedora-16(.*)verne', re.IGNORECASE),
}
___
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] Proposal for new devstack (v2?)
Hmmm, what was the error for rabbitmq? U should get a trace hopefully (with some stderr/stdout). Darn commands that are supposed to be distro independent I guess really aren't. Hmmph. PWD_CMD = ['rabbitmqctl', 'change_password', 'guest'] -Josh On 1/23/12 5:50 AM, ikke i...@iki.fi wrote: On Sat, Jan 21, 2012 at 5:47 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Note rhel6 isn't fully there yet. But in progress ;) Anyone working on fedora version of it? Any known major issues preventing it? I quickly added fedora labels next to RHEL6 in the code, and added db.py stuff. By quick test it does nova mysql config, and then stops at rabbitmq password change for command returning exit code2. ___ 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] Proposal for new devstack (v2?)
No major issues preventing fedora. In fact we might have to get packages from fedora (dependencies) and get those into rhel (if possible). Or create something like grid dynamics has (a dependency repo) and use that for development purposes for rhel *like* systems (possibly hosted by yahoo??) On 1/23/12 5:50 AM, ikke i...@iki.fi wrote: On Sat, Jan 21, 2012 at 5:47 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Note rhel6 isn't fully there yet. But in progress ;) Anyone working on fedora version of it? Any known major issues preventing it? I quickly added fedora labels next to RHEL6 in the code, and added db.py stuff. By quick test it does nova mysql config, and then stops at rabbitmq password change for command returning exit code2. ___ 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] Proposal for new devstack (v2?)
On Mon, Jan 23, 2012 at 7:18 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: No major issues preventing fedora. In fact we might have to get packages from fedora (dependencies) and get those into rhel (if possible). Or create something like grid dynamics has (a dependency repo) and use that for development purposes for rhel *like* systems (possibly hosted by yahoo??) What are those deps? I'd be happy to help add them to EPEL. Thanks, Alan ___ 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] Proposal for new devstack (v2?)
Working on getting that list committed ;) Hopefully today or tomorrow. On 1/23/12 10:46 AM, Alan Pevec ape...@gmail.com wrote: On Mon, Jan 23, 2012 at 7:18 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: No major issues preventing fedora. In fact we might have to get packages from fedora (dependencies) and get those into rhel (if possible). Or create something like grid dynamics has (a dependency repo) and use that for development purposes for rhel *like* systems (possibly hosted by yahoo??) What are those deps? I'd be happy to help add them to EPEL. Thanks, Alan ___ 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] Proposal for new devstack (v2?)
So some of the issues after doing a comparison might be the following: For RHEL6 + EPEL a lot of the packages are there (yippe!). https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pkgs Some issues which the EPEL people's might be able to resolve: db.json Seems ok. general.json euca2ools is much newer in ubuntu (2.0.0~bzr464-0ubuntu2 vs 1.3.1-12.el6). python-coverage does not seem to exist in EPEL (or at least my repo setup). That would be useful to have for testing (and CI). python-pip versions (1.0-1 vs 0.8-1.el6) python-nose versions (1.0.0-1ubuntu1 vs 0.10.4-3.1.el6) glance.json python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-wsgiref does not seem to exist in rhel6 (?) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-httplib2 versiosn (0.7.1-1ubuntu1 vs 0.4.0-5.el6) horizon.json mod_wsgi versions (3.3-2ubuntu3 vs 3.2-1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) python-cherrypy3 does not exist python-django-mailer does not exist python-django-nose does not exist python-migrate versions (0.7.1-1 vs 0.6-6.el6) keystone-client.json/nova-client.json Should be ok. keystone.json python-lxml versions (2.3-0.1build1 vs 2.2.3-1.1.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-paste versions (1.7.5.1-4ubuntu1 vs 1.7.4-1.el6) python-sqlite2 versions (2.6.3-2 vs 2.3.5-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) python-webob versions (1.0.8-1 vs 0.9.6.1-3.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) libldap2-dev and libsasl2-dev equivalents?? n-cpu.json/n-vol.json (nova cpu/volume) Should be ok n-vnc.json (nova novnc) python-numpy does not seem to exist nova.json python-xattr versions (0.6-1ubuntu2 vs 0.5.0-1.el6) python-lxml versions (2.7.8.dfsg-4 vs 2.2.3-1.1.el6) libvirt versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) vlan package? python-migrate versions (0.7.1-1 vs 0.6-6.el6) python-gflags versions (1.5.1-1 vs 1.4-3.el6) libvirt-python versions (0.9.2-4ubuntu15.1 vs 0.8.7-18.el6) python-routes versions (1.12.3-1 vs 1.10.3-2.el6) python-paste-deploy versions (1.5.0-2 vs 1.3.3-2.1.el6) python-tempita versions (0.5.1-1 vs 0.4-2.el6) python-sqlalchemy versions (0.6.8-1 vs 0.5.5-2.1.el6) I will start to get the tests going to see if the version differences are actually a problem. I am assuming large version differences will be an issue. But its hard to tell how much of an issue yet. But it would be really great if we could just get all those up to the same versions. Then possibly in the future we can get RHEL6 (or equiv) hooked into the CI pipeline to ensure that new versions/packages work on all distributions that openstack wants to support. That way it ensures that packages and versions are uniform (or as close to possible to uniform) and will work with the supported code. Josh On 1/23/12 10:46 AM, Alan Pevec ape...@gmail.com wrote: On Mon, Jan 23, 2012 at 7:18 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: No major issues preventing fedora. In fact we might have to get packages from fedora (dependencies) and get those into rhel (if possible). Or create something like grid dynamics has (a dependency repo) and use that for development purposes for rhel *like* systems (possibly hosted by yahoo??) What are those deps? I'd be happy to help add them to EPEL. Thanks, Alan ___ 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] Proposal for new devstack (v2?)
For those that want to try it glance should be working! Since glance has dependencies on keystone, and the database both of these will be installed and started automatically (uninstall and starting and such should work!) How to accomplish this can be seen at the github page readme. https://github.com/yahoo/Openstack-Devstack2#readme I will write up some documents on the github twiki sometime soon with more details! Nova and the rest should be coming along soon. Hopefully this will make everyones lives easier in the end :-) Please try it out, feedback welcome :-) -Josh On 1/18/12 10:17 PM, Gary Kotton ga...@radware.com wrote: Brilliant! From: openstack-bounces+garyk=radware@lists.launchpad.net [mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: Wednesday, January 18, 2012 9:21 PM To: Mark McLoughlin Cc: Andy Smith; openstack Subject: Re: [Openstack] Proposal for new devstack (v2?) Sweet, we are working on getting functionality for rhel and ubuntu up and going and then hopefully some docs (and code comments) can be added in so other people can know exactly what is going on (without the typical go read the code response). But the idea is the following: Have a set of json files (+ I added the ability to have simple comments) that specify the needed dependencies + versions (+ other metadata) for each distribution. https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/general.json Have those different sections be handled by a class specific to a distribution (or possibly shared, ie fedora and rhel). https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packaging (WIP as we work with the rhel peoples to get the dependencies flushed out) Similar with pip installs (if any): https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips Then this information can be updated as needed for each release of openstack (with exact dependencies, y a win for everyone!) so that this whole pkg process becomes better for everyone. Of course also we are allowing other types of running besides screen (I like just having it in the background via a fork with output going to files...) That's whats going on so far :-) Thx, -Josh On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ 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] Proposal for new devstack (v2?)
Sweet. Will do next week. ~sean On Jan 20, 2012, at 7:25 PM, Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote: For those that want to try it glance should be working! Since glance has dependencies on keystone, and the database both of these will be installed and started automatically (uninstall and starting and such should work!) How to accomplish this can be seen at the github page readme. https://github.com/yahoo/Openstack-Devstack2#readme I will write up some documents on the github twiki sometime soon with more details! Nova and the rest should be coming along soon. Hopefully this will make everyones lives easier in the end :-) Please try it out, feedback welcome :-) -Josh On 1/18/12 10:17 PM, Gary Kotton ga...@radware.com wrote: Brilliant! From: openstack-bounces+garyk=radware@lists.launchpad.net [mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: Wednesday, January 18, 2012 9:21 PM To: Mark McLoughlin Cc: Andy Smith; openstack Subject: Re: [Openstack] Proposal for new devstack (v2?) Sweet, we are working on getting functionality for rhel and ubuntu up and going and then hopefully some docs (and code comments) can be added in so other people can know exactly what is going on (without the typical “go read the code” response). But the idea is the following: Have a set of json files (+ I added the ability to have simple comments) that specify the needed dependencies + versions (+ other metadata) for each distribution. https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/general.json Have those different sections be handled by a class specific to a distribution (or possibly shared, ie fedora and rhel). https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packaging (WIP as we work with the rhel peoples to get the dependencies flushed out) Similar with pip installs (if any): https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips Then this information can be updated as needed for each release of openstack (with exact dependencies, y a win for everyone!) so that this whole pkg process becomes better for everyone. Of course also we are allowing other types of running besides screen (I like just having it in the background via a fork with output going to files...) That’s whats going on so far :-) Thx, -Josh On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Proposal for new devstack (v2?)
Note rhel6 isn't fully there yet. But in progress ;) On 1/20/12 7:33 PM, Sean Roberts sean...@yahoo-inc.com wrote: Sweet. Will do next week. ~sean On Jan 20, 2012, at 7:25 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Re: [Openstack] Proposal for new devstack (v2?) For those that want to try it glance should be working! Since glance has dependencies on keystone, and the database both of these will be installed and started automatically (uninstall and starting and such should work!) How to accomplish this can be seen at the github page readme. https://github.com/yahoo/Openstack-Devstack2#readme I will write up some documents on the github twiki sometime soon with more details! Nova and the rest should be coming along soon. Hopefully this will make everyones lives easier in the end :-) Please try it out, feedback welcome :-) -Josh On 1/18/12 10:17 PM, Gary Kotton ga...@radware.com wrote: Brilliant! From: openstack-bounces+garyk=radware@lists.launchpad.net [mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: Wednesday, January 18, 2012 9:21 PM To: Mark McLoughlin Cc: Andy Smith; openstack Subject: Re: [Openstack] Proposal for new devstack (v2?) Sweet, we are working on getting functionality for rhel and ubuntu up and going and then hopefully some docs (and code comments) can be added in so other people can know exactly what is going on (without the typical go read the code response). But the idea is the following: Have a set of json files (+ I added the ability to have simple comments) that specify the needed dependencies + versions (+ other metadata) for each distribution. https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/general.json Have those different sections be handled by a class specific to a distribution (or possibly shared, ie fedora and rhel). https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packaging (WIP as we work with the rhel peoples to get the dependencies flushed out) Similar with pip installs (if any): https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips Then this information can be updated as needed for each release of openstack (with exact dependencies, y a win for everyone!) so that this whole pkg process becomes better for everyone. Of course also we are allowing other types of running besides screen (I like just having it in the background via a fork with output going to files...) That's whats going on so far :-) Thx, -Josh On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ 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] Proposal for new devstack (v2?)
On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ 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] Proposal for new devstack (v2?)
On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Please check it out @ https://github.com/yahoo/Openstack-Devstack2 To stave off confusion it might be a good idea to rename this from 2 to alt or similar, or even as forks tend to in the WordPress world ultimate or all in one ;-) It should be labeled version 2 by consensus. Very cool work, Lloyd ___ 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] Proposal for new devstack (v2?)
In this case, I must take a step forward and start planing Debian support asap. Ghe Rivero On Wed, Jan 18, 2012 at 12:45 PM, Mark McLoughlin mar...@redhat.com wrote: Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org www.hispalinux.es GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ 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] Proposal for new devstack (v2?)
Sweet, we are working on getting functionality for rhel and ubuntu up and going and then hopefully some docs (and code comments) can be added in so other people can know exactly what is going on (without the typical go read the code response). But the idea is the following: Have a set of json files (+ I added the ability to have simple comments) that specify the needed dependencies + versions (+ other metadata) for each distribution. https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/general.json Have those different sections be handled by a class specific to a distribution (or possibly shared, ie fedora and rhel). https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packaging (WIP as we work with the rhel peoples to get the dependencies flushed out) Similar with pip installs (if any): https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips Then this information can be updated as needed for each release of openstack (with exact dependencies, y a win for everyone!) so that this whole pkg process becomes better for everyone. Of course also we are allowing other types of running besides screen (I like just having it in the background via a fork with output going to files...) That's whats going on so far :-) Thx, -Josh On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ 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] Proposal for new devstack (v2?)
Sure, this was just a name I picked. It can be renamed to anything, works for me. I just needed a name for a github project (and it seemed to make sense at the time, haha). -Josh On 1/18/12 9:10 AM, Lloyd Dewolf lloydost...@gmail.com wrote: On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Please check it out @ https://github.com/yahoo/Openstack-Devstack2 To stave off confusion it might be a good idea to rename this from 2 to alt or similar, or even as forks tend to in the WordPress world ultimate or all in one ;-) It should be labeled version 2 by consensus. Very cool work, Lloyd ___ 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] Proposal for new devstack (v2?)
devstack-pi (play on version numbers and python) On Wed, Jan 18, 2012 at 11:22 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Sure, this was just a name I picked. It can be renamed to anything, works for me. I just needed a name for a github project (and it seemed to make sense at the time, haha). -Josh On 1/18/12 9:10 AM, Lloyd Dewolf lloydost...@gmail.com wrote: On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Please check it out @ https://github.com/yahoo/Openstack-Devstack2 To stave off confusion it might be a good idea to rename this from 2 to alt or similar, or even as forks tend to in the WordPress world ultimate or all in one ;-) It should be labeled version 2 by consensus. Very cool work, Lloyd ___ 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 ___ 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] Proposal for new devstack (v2?)
I +3.14159265 that! On Wed, Jan 18, 2012 at 11:55 AM, Jesse Andrews anotherje...@gmail.com wrote: devstack-pi (play on version numbers and python) On Wed, Jan 18, 2012 at 11:22 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Sure, this was just a name I picked. It can be renamed to anything, works for me. I just needed a name for a github project (and it seemed to make sense at the time, haha). -Josh On 1/18/12 9:10 AM, Lloyd Dewolf lloydost...@gmail.com wrote: On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Please check it out @ https://github.com/yahoo/Openstack-Devstack2 To stave off confusion it might be a good idea to rename this from 2 to alt or similar, or even as forks tend to in the WordPress world ultimate or all in one ;-) It should be labeled version 2 by consensus. ___ 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] Proposal for new devstack (v2?)
Brilliant! From: openstack-bounces+garyk=radware@lists.launchpad.net [mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: Wednesday, January 18, 2012 9:21 PM To: Mark McLoughlin Cc: Andy Smith; openstack Subject: Re: [Openstack] Proposal for new devstack (v2?) Sweet, we are working on getting functionality for rhel and ubuntu up and going and then hopefully some docs (and code comments) can be added in so other people can know exactly what is going on (without the typical go read the code response). But the idea is the following: Have a set of json files (+ I added the ability to have simple comments) that specify the needed dependencies + versions (+ other metadata) for each distribution. https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/gener al.json Have those different sections be handled by a class specific to a distribution (or possibly shared, ie fedora and rhel). https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packag ing (WIP as we work with the rhel peoples to get the dependencies flushed out) Similar with pip installs (if any): https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips Then this information can be updated as needed for each release of openstack (with exact dependencies, y a win for everyone!) so that this whole pkg process becomes better for everyone. Of course also we are allowing other types of running besides screen (I like just having it in the background via a fork with output going to files...) That's whats going on so far :-) Thx, -Josh On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote: My goals were/are/(may continue to be, haha) the following: ... 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) Serious kudos to you guys on this part. IMHO, having a devstack that supports multiple distros is a massive win for OpenStack generally. Hopefully we can dig in and help with Fedora support soonish Cheers, Mark. ___ 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] Proposal for new devstack (v2?)
Looks cool :) I've been trying to plant the seed of switching devstack to python (heavily utilizing fabric and cuisine) in my team's head for a while now. We are heavily dependent on devstack for our development and testing workflows so it would be a pretty big decision for us to switch tools, and we'd be doing very active development on whatever new tool we switched to. The general flow and goals of the tool seem appropriate, and it looks like it could be a good starting place for work in this direction. The style of the code is pretty far from most of the common openstack style guides, but that's pretty easily solvable, as are the other small things to get the project looking more openstack-y. I'd still be interested in using fabric and cuisine as the underlying layer because of having a well-tested, built-in way of dealing with remote servers allows for some more versatility. --andy On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Hi all, I would just like to propose a new devstack (v2?) that we have been starting to work on that uses python throughout as well as has componentized installs (for glance, nova...) and a nice object oriented design and the like (including having a json format for defining package and pip dependencies that allows simple comments so people can know what the pkgs are). We are currently trying to get equivalence going for ubuntu (and at the same time rhel6.x) and I would like it if we could get peoples initial thoughts on this. I know the current devstack shell script is starting to explode (LOC wise) and it seems like it is a good time to stop that from exploding by creating something a little more flexible (and maintainable imho). Please check it out @ https://github.com/yahoo/Openstack-Devstack2 Comments welcome! We are working on getting as much equivalence as we can (while still maintaining a “clean” design). Thx, Josh ___ 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] Proposal for new devstack (v2?)
Thx, Yes we haven't been 100% doing the style stuff yet (which is ok I think for now). My idea for not using an underlying fabric was just to keep it as simple as possible (but not to simple). Not always an easy choice :-) On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote: Looks cool :) I've been trying to plant the seed of switching devstack to python (heavily utilizing fabric and cuisine) in my team's head for a while now. We are heavily dependent on devstack for our development and testing workflows so it would be a pretty big decision for us to switch tools, and we'd be doing very active development on whatever new tool we switched to. The general flow and goals of the tool seem appropriate, and it looks like it could be a good starting place for work in this direction. The style of the code is pretty far from most of the common openstack style guides, but that's pretty easily solvable, as are the other small things to get the project looking more openstack-y. I'd still be interested in using fabric and cuisine as the underlying layer because of having a well-tested, built-in way of dealing with remote servers allows for some more versatility. --andy On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Hi all, I would just like to propose a new devstack (v2?) that we have been starting to work on that uses python throughout as well as has componentized installs (for glance, nova...) and a nice object oriented design and the like (including having a json format for defining package and pip dependencies that allows simple comments so people can know what the pkgs are). We are currently trying to get equivalence going for ubuntu (and at the same time rhel6.x) and I would like it if we could get peoples initial thoughts on this. I know the current devstack shell script is starting to explode (LOC wise) and it seems like it is a good time to stop that from exploding by creating something a little more flexible (and maintainable imho). Please check it out @ https://github.com/yahoo/Openstack-Devstack2 Comments welcome! We are working on getting as much equivalence as we can (while still maintaining a clean design). Thx, Josh ___ 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] Proposal for new devstack (v2?)
I think a goal would be to have easy fabric integration.
Right now our fabric scripts for devstack look like:
@task
@parallel
def stop():
Kill devstack and all VMs running
run(killall -9 screen || true)
run(screen -wipe || true)
# note we can probably remove this once devstack supports removing instances
# which anthony is working on
sudo(rm -rf /etc/libvirt/qemu/inst*)
sudo(virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh
destroy; true)
@task
def reserve_ips():
Remove IPs from nova's fixed ip pool for use by hosts
This is needed for both the compute hosts and the VPN instances
if env.host == config.master:
with cd('%s/nova' % config.dest):
for n in xrange(2, 10):
ip = 10.4.128.%s % n
run(bin/nova-manage fixed reserve %s % ip)
# reserve VPN client IPs too
for n in xrange(240, 254):
ip = 10.4.143.%s % n
run(bin/nova-manage fixed reserve %s % ip)
@task
@parallel
def users():
ensure our users exist
if env.host == config.master:
for name, password in config.users.iteritems():
# add_user(username, password)
with cd(config.dest + '/keystone'):
if not name in run(bin/keystone-manage tenant list):
run(bin/keystone-manage tenant add %s % name)
run(bin/keystone-manage user add %s %s % (name, password))
run(bin/keystone-manage credentials add %s EC2 %s
%s %s % (name, name, password, name))
run(bin/keystone-manage role grant sysadmin %s
%s % (name, name))
run(bin/keystone-manage role grant netadmin %s
%s % (name, name))
run(bin/keystone-manage role grant Member %s %s
% (name, name))
On Tue, Jan 17, 2012 at 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Thx,
Yes we haven’t been 100% doing the style stuff yet (which is ok I think for
now).
My idea for not using an underlying fabric was just to keep it as simple as
possible (but not to simple). Not always an easy choice :-)
On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote:
Looks cool :)
I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.
We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.
The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.
The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.
I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote servers
allows for some more versatility.
--andy
On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Hi all,
I would just like to propose a new devstack (v2?) that we have been starting
to work on that uses python throughout as well as has componentized installs
(for glance, nova...) and a nice object oriented design and the like
(including having a json format for defining package and pip dependencies
that allows simple comments so people can know what the pkgs are). We are
currently trying to get equivalence going for ubuntu (and at the same time
rhel6.x) and I would like it if we could get peoples initial thoughts on
this.
I know the current devstack shell script is starting to explode (LOC wise)
and it seems like it is a good time to stop that from exploding by creating
something a little more flexible (and maintainable imho).
Please check it out @ https://github.com/yahoo/Openstack-Devstack2
Comments welcome!
We are working on getting as much equivalence as we can (while still
maintaining a “clean” design).
Thx,
Josh
___
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
___
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] Proposal for new devstack (v2?)
My goals were/are/(may continue to be, haha) the following: 1. Add in enough abstraction so that you can look at how each component is installed/uninstalled/started/stopped by looking at a single file (maybe 2 files) 2. Have the ability to start/stop in different manners (not always screen) 3. Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro. * This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu) 4. Increase the level of documentation (probably not going to be in the end, inline like what is in devstack, since that just doesn't seem maintainable in the long-term) * This may mean having documentation created similar to nova, glance, as a separate documentation document/page Still be simple enough to run and use so that the non-python dev can install from trunk without having to understand what is going on. -Josh On 1/17/12 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Thx, Yes we haven't been 100% doing the style stuff yet (which is ok I think for now). My idea for not using an underlying fabric was just to keep it as simple as possible (but not to simple). Not always an easy choice :-) On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote: Looks cool :) I've been trying to plant the seed of switching devstack to python (heavily utilizing fabric and cuisine) in my team's head for a while now. We are heavily dependent on devstack for our development and testing workflows so it would be a pretty big decision for us to switch tools, and we'd be doing very active development on whatever new tool we switched to. The general flow and goals of the tool seem appropriate, and it looks like it could be a good starting place for work in this direction. The style of the code is pretty far from most of the common openstack style guides, but that's pretty easily solvable, as are the other small things to get the project looking more openstack-y. I'd still be interested in using fabric and cuisine as the underlying layer because of having a well-tested, built-in way of dealing with remote servers allows for some more versatility. --andy On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com wrote: Hi all, I would just like to propose a new devstack (v2?) that we have been starting to work on that uses python throughout as well as has componentized installs (for glance, nova...) and a nice object oriented design and the like (including having a json format for defining package and pip dependencies that allows simple comments so people can know what the pkgs are). We are currently trying to get equivalence going for ubuntu (and at the same time rhel6.x) and I would like it if we could get peoples initial thoughts on this. I know the current devstack shell script is starting to explode (LOC wise) and it seems like it is a good time to stop that from exploding by creating something a little more flexible (and maintainable imho). Please check it out @ https://github.com/yahoo/Openstack-Devstack2 Comments welcome! We are working on getting as much equivalence as we can (while still maintaining a clean design). Thx, Josh ___ 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] Proposal for new devstack (v2?)
On a different note: ideally we should have folks run a devstack build with
their changes before committing else we will have broken devstack builds e.g.
now.
debo
-Original Message-
From: openstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of
Jesse Andrews
Sent: Tuesday, January 17, 2012 11:19 AM
To: Joshua Harlow
Cc: Andy Smith; Ken Thomas; openstack
Subject: Re: [Openstack] Proposal for new devstack (v2?)
I think a goal would be to have easy fabric integration.
Right now our fabric scripts for devstack look like:
@task
@parallel
def stop():
Kill devstack and all VMs running
run(killall -9 screen || true)
run(screen -wipe || true)
# note we can probably remove this once devstack supports removing instances
# which anthony is working on
sudo(rm -rf /etc/libvirt/qemu/inst*)
sudo(virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh
destroy; true)
@task
def reserve_ips():
Remove IPs from nova's fixed ip pool for use by hosts
This is needed for both the compute hosts and the VPN instances
if env.host == config.master:
with cd('%s/nova' % config.dest):
for n in xrange(2, 10):
ip = 10.4.128.%s % n
run(bin/nova-manage fixed reserve %s % ip)
# reserve VPN client IPs too
for n in xrange(240, 254):
ip = 10.4.143.%s % n
run(bin/nova-manage fixed reserve %s % ip)
@task
@parallel
def users():
ensure our users exist
if env.host == config.master:
for name, password in config.users.iteritems():
# add_user(username, password)
with cd(config.dest + '/keystone'):
if not name in run(bin/keystone-manage tenant list):
run(bin/keystone-manage tenant add %s % name)
run(bin/keystone-manage user add %s %s % (name, password))
run(bin/keystone-manage credentials add %s EC2 %s
%s %s % (name, name, password, name))
run(bin/keystone-manage role grant sysadmin %s
%s % (name, name))
run(bin/keystone-manage role grant netadmin %s
%s % (name, name))
run(bin/keystone-manage role grant Member %s %s
% (name, name))
On Tue, Jan 17, 2012 at 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Thx,
Yes we haven't been 100% doing the style stuff yet (which is ok I think for
now).
My idea for not using an underlying fabric was just to keep it as simple as
possible (but not to simple). Not always an easy choice :-)
On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote:
Looks cool :)
I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.
We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.
The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.
The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.
I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote servers
allows for some more versatility.
--andy
On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Hi all,
I would just like to propose a new devstack (v2?) that we have been starting
to work on that uses python throughout as well as has componentized installs
(for glance, nova...) and a nice object oriented design and the like
(including having a json format for defining package and pip dependencies
that allows simple comments so people can know what the pkgs are). We are
currently trying to get equivalence going for ubuntu (and at the same time
rhel6.x) and I would like it if we could get peoples initial thoughts on
this.
I know the current devstack shell script is starting to explode (LOC wise)
and it seems like it is a good time to stop that from exploding by creating
something a little more flexible (and maintainable imho).
Please check it out @ https://github.com/yahoo/Openstack-Devstack2
Comments welcome!
We are working on getting as much equivalence as we can (while still
maintaining a clean design).
Thx,
Josh
___
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
Re: [Openstack] Proposal for new devstack (v2?)
We currently run devstack on all changes before letting them land.
I think once devstack-v2 is ready to go, it should be pretty easy to add
a job that runs it as well for a little bit until we're happy with
stability, and then turn off the old one.
As long as v2 continues to be annotated and easy to follow, I think this
sounds great. One of the current big wins of devstack over things like
the chef and puppet recipes is that you can read devstack to learn how
to deploy OpenStack without having to learn chef or puppet. If the new
thing introduces TOO many abstractions, it could get us back to the
place where a dev has to learn the framework first ... but it sounds
like you guys are talking about keeping (or even adding) sanity. So awesome.
On 01/18/2012 06:36 AM, Debo Dutta (dedutta) wrote:
On a different note: ideally we should have folks run a devstack build with
their changes before committing else we will have broken devstack builds
e..g. now.
debo
-Original Message-
From: openstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of
Jesse Andrews
Sent: Tuesday, January 17, 2012 11:19 AM
To: Joshua Harlow
Cc: Andy Smith; Ken Thomas; openstack
Subject: Re: [Openstack] Proposal for new devstack (v2?)
I think a goal would be to have easy fabric integration.
Right now our fabric scripts for devstack look like:
@task
@parallel
def stop():
Kill devstack and all VMs running
run(killall -9 screen || true)
run(screen -wipe || true)
# note we can probably remove this once devstack supports removing
instances
# which anthony is working on
sudo(rm -rf /etc/libvirt/qemu/inst*)
sudo(virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh
destroy; true)
@task
def reserve_ips():
Remove IPs from nova's fixed ip pool for use by hosts
This is needed for both the compute hosts and the VPN instances
if env.host == config.master:
with cd('%s/nova' % config.dest):
for n in xrange(2, 10):
ip = 10.4.128.%s % n
run(bin/nova-manage fixed reserve %s % ip)
# reserve VPN client IPs too
for n in xrange(240, 254):
ip = 10.4.143.%s % n
run(bin/nova-manage fixed reserve %s % ip)
@task
@parallel
def users():
ensure our users exist
if env.host == config.master:
for name, password in config.users.iteritems():
# add_user(username, password)
with cd(config.dest + '/keystone'):
if not name in run(bin/keystone-manage tenant list):
run(bin/keystone-manage tenant add %s % name)
run(bin/keystone-manage user add %s %s % (name,
password))
run(bin/keystone-manage credentials add %s EC2 %s
%s %s % (name, name, password, name))
run(bin/keystone-manage role grant sysadmin %s
%s % (name, name))
run(bin/keystone-manage role grant netadmin %s
%s % (name, name))
run(bin/keystone-manage role grant Member %s %s
% (name, name))
On Tue, Jan 17, 2012 at 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Thx,
Yes we haven't been 100% doing the style stuff yet (which is ok I think for
now).
My idea for not using an underlying fabric was just to keep it as simple as
possible (but not to simple). Not always an easy choice :-)
On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote:
Looks cool :)
I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.
We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.
The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.
The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.
I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote servers
allows for some more versatility.
--andy
On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Hi all,
I would just like to propose a new devstack (v2?) that we have been starting
to work on that uses python throughout as well as has componentized installs
(for glance, nova...) and a nice object oriented design and the like
(including having a json format for defining package and pip dependencies
that allows simple comments so people can know what the pkgs are). We are
currently
Re: [Openstack] Proposal for new devstack (v2?)
That's the goal. More sanity the better! :-) But not to much that it becomes
abstracted away to far.
Once this comes out of WIP mode (hopefully soon) we'll hopefully be able to do
all that, and help unit tests run with ubuntu and rhel6 (ie on smokestack).
And going forward hopefully this can be used for other distro as the current
devstack is being used to figure out what to install and how (and pkg
versions)...
On 1/17/12 1:36 PM, Monty Taylor mord...@inaugust.com wrote:
We currently run devstack on all changes before letting them land.
I think once devstack-v2 is ready to go, it should be pretty easy to add
a job that runs it as well for a little bit until we're happy with
stability, and then turn off the old one.
As long as v2 continues to be annotated and easy to follow, I think this
sounds great. One of the current big wins of devstack over things like
the chef and puppet recipes is that you can read devstack to learn how
to deploy OpenStack without having to learn chef or puppet. If the new
thing introduces TOO many abstractions, it could get us back to the
place where a dev has to learn the framework first ... but it sounds
like you guys are talking about keeping (or even adding) sanity. So awesome.
On 01/18/2012 06:36 AM, Debo Dutta (dedutta) wrote:
On a different note: ideally we should have folks run a devstack build with
their changes before committing else we will have broken devstack builds
e..g. now.
debo
-Original Message-
From: openstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of
Jesse Andrews
Sent: Tuesday, January 17, 2012 11:19 AM
To: Joshua Harlow
Cc: Andy Smith; Ken Thomas; openstack
Subject: Re: [Openstack] Proposal for new devstack (v2?)
I think a goal would be to have easy fabric integration.
Right now our fabric scripts for devstack look like:
@task
@parallel
def stop():
Kill devstack and all VMs running
run(killall -9 screen || true)
run(screen -wipe || true)
# note we can probably remove this once devstack supports removing
instances
# which anthony is working on
sudo(rm -rf /etc/libvirt/qemu/inst*)
sudo(virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh
destroy; true)
@task
def reserve_ips():
Remove IPs from nova's fixed ip pool for use by hosts
This is needed for both the compute hosts and the VPN instances
if env.host == config.master:
with cd('%s/nova' % config.dest):
for n in xrange(2, 10):
ip = 10.4.128.%s % n
run(bin/nova-manage fixed reserve %s % ip)
# reserve VPN client IPs too
for n in xrange(240, 254):
ip = 10.4.143.%s % n
run(bin/nova-manage fixed reserve %s % ip)
@task
@parallel
def users():
ensure our users exist
if env.host == config.master:
for name, password in config.users.iteritems():
# add_user(username, password)
with cd(config.dest + '/keystone'):
if not name in run(bin/keystone-manage tenant list):
run(bin/keystone-manage tenant add %s % name)
run(bin/keystone-manage user add %s %s % (name,
password))
run(bin/keystone-manage credentials add %s EC2 %s
%s %s % (name, name, password, name))
run(bin/keystone-manage role grant sysadmin %s
%s % (name, name))
run(bin/keystone-manage role grant netadmin %s
%s % (name, name))
run(bin/keystone-manage role grant Member %s %s
% (name, name))
On Tue, Jan 17, 2012 at 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Thx,
Yes we haven't been 100% doing the style stuff yet (which is ok I think for
now).
My idea for not using an underlying fabric was just to keep it as simple as
possible (but not to simple). Not always an easy choice :-)
On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote:
Looks cool :)
I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.
We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.
The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.
The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.
I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote servers
allows for some more versatility.
--andy
On Tue
Re: [Openstack] Proposal for new devstack (v2?)
I think this can be done, sure.
Its basically abstracting away how actually execute commands (ie going throw
fabric instead of the shell...).
Which I think can be accomplished.
On 1/17/12 11:18 AM, Jesse Andrews anotherje...@gmail.com wrote:
I think a goal would be to have easy fabric integration.
Right now our fabric scripts for devstack look like:
@task
@parallel
def stop():
Kill devstack and all VMs running
run(killall -9 screen || true)
run(screen -wipe || true)
# note we can probably remove this once devstack supports removing instances
# which anthony is working on
sudo(rm -rf /etc/libvirt/qemu/inst*)
sudo(virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh
destroy; true)
@task
def reserve_ips():
Remove IPs from nova's fixed ip pool for use by hosts
This is needed for both the compute hosts and the VPN instances
if env.host == config.master:
with cd('%s/nova' % config.dest):
for n in xrange(2, 10):
ip = 10.4.128.%s % n
run(bin/nova-manage fixed reserve %s % ip)
# reserve VPN client IPs too
for n in xrange(240, 254):
ip = 10.4.143.%s % n
run(bin/nova-manage fixed reserve %s % ip)
@task
@parallel
def users():
ensure our users exist
if env.host == config.master:
for name, password in config.users.iteritems():
# add_user(username, password)
with cd(config.dest + '/keystone'):
if not name in run(bin/keystone-manage tenant list):
run(bin/keystone-manage tenant add %s % name)
run(bin/keystone-manage user add %s %s % (name, password))
run(bin/keystone-manage credentials add %s EC2 %s
%s %s % (name, name, password, name))
run(bin/keystone-manage role grant sysadmin %s
%s % (name, name))
run(bin/keystone-manage role grant netadmin %s
%s % (name, name))
run(bin/keystone-manage role grant Member %s %s
% (name, name))
On Tue, Jan 17, 2012 at 11:01 AM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Thx,
Yes we haven't been 100% doing the style stuff yet (which is ok I think for
now).
My idea for not using an underlying fabric was just to keep it as simple as
possible (but not to simple). Not always an easy choice :-)
On 1/17/12 10:56 AM, Andy Smith andys...@gmail.com wrote:
Looks cool :)
I've been trying to plant the seed of switching devstack to python (heavily
utilizing fabric and cuisine) in my team's head for a while now.
We are heavily dependent on devstack for our development and testing
workflows so it would be a pretty big decision for us to switch tools, and
we'd be doing very active development on whatever new tool we switched to.
The general flow and goals of the tool seem appropriate, and it looks like
it could be a good starting place for work in this direction.
The style of the code is pretty far from most of the common openstack style
guides, but that's pretty easily solvable, as are the other small things to
get the project looking more openstack-y.
I'd still be interested in using fabric and cuisine as the underlying layer
because of having a well-tested, built-in way of dealing with remote servers
allows for some more versatility.
--andy
On Tue, Jan 17, 2012 at 10:20 AM, Joshua Harlow harlo...@yahoo-inc.com
wrote:
Hi all,
I would just like to propose a new devstack (v2?) that we have been starting
to work on that uses python throughout as well as has componentized installs
(for glance, nova...) and a nice object oriented design and the like
(including having a json format for defining package and pip dependencies
that allows simple comments so people can know what the pkgs are). We are
currently trying to get equivalence going for ubuntu (and at the same time
rhel6.x) and I would like it if we could get peoples initial thoughts on
this.
I know the current devstack shell script is starting to explode (LOC wise)
and it seems like it is a good time to stop that from exploding by creating
something a little more flexible (and maintainable imho).
Please check it out @ https://github.com/yahoo/Openstack-Devstack2
Comments welcome!
We are working on getting as much equivalence as we can (while still
maintaining a clean design).
Thx,
Josh
___
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
___
Mailing list:
