Currently Fedora's openstack-nova package generates the following 2 packages, with the dependencies indented:
openstack-nova openstack-utils bridge-utils dnsmasq-utils libguestfs-mount >= 1.7.17 fuse # The fuse dependency should be added to libguestfs-mount libvirt >= 0.8.7 MySQL-python euca2ools openssl sudo Requires(pre): shadow-utils qemu-kvm
python-nova vconfig # configures and adjusts 802.1q VLAN parameters curl coreutils radvd # Router Advertisement daemon iptables iptables-ipv6 lvm2 scsi-target-utils iscsi-initiator-utils
libvirt-python
python-crypto python-paramiko
python-qpid python-kombu python-amqplib
python-daemon python-eventlet python-greenlet python-gflags python-iso8601 python-lockfile python-netaddr python-lxml PyXML python-anyjson python-boto python-cheetah python-ldap
python-memcached
python-sqlalchemy python-migrate
python-paste-deploy python-routes python-webob
python-glance python-novaclient
Now even though we don't auto enable any services on install, splitting out some sub packages would reduce dependencies on particular packages, saving disk space and identifying and distributing dependencies going forward. The current plan is to split into the following 10 subpackages:
openstack-nova (a new meta package for compat with old scripts) openstack-nova-compute openstack-nova-cert openstack-nova-scheduler openstack-nova-volume openstack-nova-api openstack-nova-network openstack-nova-objectstore openstack-nova-console
python-nova openssl sudo
MySQL-python
python-crypto python-paramiko
python-qpid python-kombu python-amqplib
python-daemon python-eventlet python-greenlet python-gflags python-iso8601 python-lockfile python-netaddr python-lxml PyXML python-anyjson python-boto python-cheetah python-ldap
python-memcached
python-sqlalchemy python-migrate
python-paste-deploy python-routes python-webob
python-glance python-novaclient
openstack-nova-compute python-nova curl iscsi-initiator-utils iptables iptables-v6 vconfig libguestfs-mount fuse qemu-kvm libvirt libvirt-python
openstack-nova-cert python-nova
openstack-nova-scheduler python-nova
openstack-nova-volume python-nova lvm2 scsi-target-utils
openstack-nova-api python-nova
openstack-nova-network python-nova vconfig radvd bridge-utils dnsmasq-utils
openstack-nova-objectstore python-nova
openstack-nova-console python-nova
I plan to implement this for the existing Essex packages in Fedora 17 and EPEL6 over the next while.
Note to get an idea of the distribution of the disk space at least I used `yum install --disablerepo=*updates pkg1 pkg2` in an F17 VM booted from a live iso. That gave an installed size of existing packages as:
python-nova = 134M openstack-nova = 117M
Splitting to 10 sub packages would give:
python-nova = 56M openstack-nova-compute = 166M openstack-nova-volume = 38M rest are minimal in size (but dep on python-nova)
cheers, Pádraig.
On 07/24/2012 11:20 AM, Pádraig Brady wrote:
Currently Fedora's openstack-nova package generates the following 2 packages, with the dependencies indented:
Looks like a nice improvement!
Regards -steve
openstack-nova openstack-utils bridge-utils dnsmasq-utils libguestfs-mount >= 1.7.17 fuse # The fuse dependency should be added to libguestfs-mount libvirt >= 0.8.7 MySQL-python euca2ools openssl sudo Requires(pre): shadow-utils qemu-kvm
python-nova vconfig # configures and adjusts 802.1q VLAN parameters curl coreutils radvd # Router Advertisement daemon iptables iptables-ipv6 lvm2 scsi-target-utils iscsi-initiator-utils
libvirt-python
python-crypto python-paramiko
python-qpid python-kombu python-amqplib
python-daemon python-eventlet python-greenlet python-gflags python-iso8601 python-lockfile python-netaddr python-lxml PyXML python-anyjson python-boto python-cheetah python-ldap
python-memcached
python-sqlalchemy python-migrate
python-paste-deploy python-routes python-webob
python-glance python-novaclient
Now even though we don't auto enable any services on install, splitting out some sub packages would reduce dependencies on particular packages, saving disk space and identifying and distributing dependencies going forward. The current plan is to split into the following 10 subpackages:
openstack-nova (a new meta package for compat with old scripts) openstack-nova-compute openstack-nova-cert openstack-nova-scheduler openstack-nova-volume openstack-nova-api openstack-nova-network openstack-nova-objectstore openstack-nova-console
python-nova openssl sudo
MySQL-python
python-crypto python-paramiko
python-qpid python-kombu python-amqplib
python-daemon python-eventlet python-greenlet python-gflags python-iso8601 python-lockfile python-netaddr python-lxml PyXML python-anyjson python-boto python-cheetah python-ldap
python-memcached
python-sqlalchemy python-migrate
python-paste-deploy python-routes python-webob
python-glance python-novaclient
openstack-nova-compute python-nova curl iscsi-initiator-utils iptables iptables-v6 vconfig libguestfs-mount fuse qemu-kvm libvirt libvirt-python
openstack-nova-cert python-nova
openstack-nova-scheduler python-nova
openstack-nova-volume python-nova lvm2 scsi-target-utils
openstack-nova-api python-nova
openstack-nova-network python-nova vconfig radvd bridge-utils dnsmasq-utils
openstack-nova-objectstore python-nova
openstack-nova-console python-nova
I plan to implement this for the existing Essex packages in Fedora 17 and EPEL6 over the next while.
Note to get an idea of the distribution of the disk space at least I used `yum install --disablerepo=*updates pkg1 pkg2` in an F17 VM booted from a live iso. That gave an installed size of existing packages as:
python-nova = 134M openstack-nova = 117M
Splitting to 10 sub packages would give:
python-nova = 56M openstack-nova-compute = 166M openstack-nova-volume = 38M rest are minimal in size (but dep on python-nova)
cheers, Pádraig. _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
How are the other distributions splitting the OpenStack packages ?
Are there benefits in aligning with Ubuntu ?
Tim
On 07/25/2012 08:14 AM, Tim Bell wrote:
How are the other distributions splitting the OpenStack packages ?
Are there benefits in aligning with Ubuntu ?
So I had a look... http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/nova/precise/vie...
That splits nova into 26 sub packages, which seems a bit excessive to me and you don't get the space distribution advantage at that level of splitting for example.
But the important thing is that there are mid level packages in ubuntu that align fairly closely, with the Fedora proposed split. I.E.
Ubuntu Fedora -------------------------------------- python-nova python-nova nova-compute openstack-nova-compute nova-volume openstack-nova-volume nova-network openstack-nova-network nova-cert openstack-nova-cert nova-objectstore openstack-nova-objectstore nova-api openstack-nova-api nova-console openstack-nova-console
The last 2 might not map closely, anyway...
I suppose we could rename the new Fedora nova packages to remove the "openstack-" prefix to minimize mapping config like:
http://www.puppetcookbook.com/posts/packages-with-different-name-per-distro....
On the other hand there are always going to be packaging differences like this, and the config to handle this is well supported and can be isolated in one place as shown at the URL above.
For example Fedora's openstack-glance corresponds to "glance" in debian. Also having an openstack- prefix seems a bit more consistent to me. For example there is the openstack-dashboard package in ubuntu rather than just "dashboard".
So I'm leaning towards keeping the proposed package naming/structure, given that the mapping is easy would need to be done anyway?
cheers, Pádraig.
On Wed, Jul 25, 2012 at 10:53:10AM +0100, Pádraig Brady wrote:
On 07/25/2012 08:14 AM, Tim Bell wrote:
How are the other distributions splitting the OpenStack packages ?
Are there benefits in aligning with Ubuntu ?
So I had a look... http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/nova/precise/vie...
That splits nova into 26 sub packages, which seems a bit excessive to me and you don't get the space distribution advantage at that level of splitting for example.
But the important thing is that there are mid level packages in ubuntu that align fairly closely, with the Fedora proposed split. I.E.
Ubuntu Fedora
python-nova python-nova nova-compute openstack-nova-compute nova-volume openstack-nova-volume nova-network openstack-nova-network nova-cert openstack-nova-cert nova-objectstore openstack-nova-objectstore nova-api openstack-nova-api nova-console openstack-nova-console
The last 2 might not map closely, anyway...
I suppose we could rename the new Fedora nova packages to remove the "openstack-" prefix to minimize mapping config like:
http://www.puppetcookbook.com/posts/packages-with-different-name-per-distro....
On the other hand there are always going to be packaging differences like this, and the config to handle this is well supported and can be isolated in one place as shown at the URL above.
For example Fedora's openstack-glance corresponds to "glance" in debian. Also having an openstack- prefix seems a bit more consistent to me. For example there is the openstack-dashboard package in ubuntu rather than just "dashboard".
So I'm leaning towards keeping the proposed package naming/structure, given that the mapping is easy would need to be done anyway?
I think I'm in favour of keeping the 'openstack-' prefix on package names too. I like your proposed split, though several of these pacakges might disappear when we move to Grizzly if network/volume stuff gets split out into a separate project
Daniel
On Wed, Jul 25, 2012 at 11:59 AM, Daniel P. Berrange berrange@redhat.com wrote:
I think I'm in favour of keeping the 'openstack-' prefix on package names too.
I second that, there was actually request to rename _Debian_ packages to have a prefix: https://lists.launchpad.net/openstack/msg07835.html but I'm not sure if anything came out of that.
Cheers, Alan
On 07/25/2012 06:48 AM, Alan Pevec wrote:
On Wed, Jul 25, 2012 at 11:59 AM, Daniel P. Berrange berrange@redhat.com wrote:
I think I'm in favour of keeping the 'openstack-' prefix on package names too.
Is the plan to leave all the python code in the python-nova package, with the openstack-* packages just adding init scripts, config, and dependencies? Or is the python code being split up as well?
In quantum, the python-quantum package currently contains the quantum core python code, but the quantum plugin python code is in the openstack-quantum-<plugin> subpackages.
Is the current quantum approach consistent with the proposed approach for nova?
-Bob
I second that, there was actually request to rename _Debian_ packages to have a prefix: https://lists.launchpad.net/openstack/msg07835.html but I'm not sure if anything came out of that.
Cheers, Alan _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On 07/25/2012 04:07 PM, Robert Kukura wrote:
On 07/25/2012 06:48 AM, Alan Pevec wrote:
On Wed, Jul 25, 2012 at 11:59 AM, Daniel P. Berrange berrange@redhat.com wrote:
I think I'm in favour of keeping the 'openstack-' prefix on package names too.
Is the plan to leave all the python code in the python-nova package, with the openstack-* packages just adding init scripts, config, and dependencies? Or is the python code being split up as well?
Ideally we would like to split out more from python-nova into each of the sub packages, which I'll look into.
In quantum, the python-quantum package currently contains the quantum core python code, but the quantum plugin python code is in the openstack-quantum-<plugin> subpackages.
Is the current quantum approach consistent with the proposed approach for nova?
Yes. The more cohesive the packages the better, irrespective of whether the components are code, config or whatever.
cheers, Pádraig.
On 07/25/2012 04:07 PM, Robert Kukura wrote:
On 07/25/2012 06:48 AM, Alan Pevec wrote:
On Wed, Jul 25, 2012 at 11:59 AM, Daniel P. Berrange berrange@redhat.com wrote:
I think I'm in favour of keeping the 'openstack-' prefix on package names too.
Is the plan to leave all the python code in the python-nova package, with the openstack-* packages just adding init scripts, config, and dependencies? Or is the python code being split up as well?
In quantum, the python-quantum package currently contains the quantum core python code, but the quantum plugin python code is in the openstack-quantum-<plugin> subpackages.
Is the current quantum approach consistent with the proposed approach for nova?
Your mention of config reminds me that I'd not considered shared nova.conf file. Now each service can support multiple conf files, so we could have common settings in /etc/nova/nova.conf and specific settings in /etc/nova/nova-{compute,network,volume,...}.conf? I'm 60:40 for keeping a single /etc/nova/nova.conf
Anyway, where to package the shared /etc/nova/nova.conf? I suppose we could include it with python-nova and perhaps rename that package to openstack-nova-common to be clearer on the intent of that package. Alternatively we could create a new openstack-nova-common package to include this config file and other shared stuff like /usr/bin/nova-rootwrap? I'm 70:30 for creating a new openstack-nova-common package.
cheers, Pádraig.
On 26/07/2012, at 5:00 AM, Pádraig Brady wrote: <snip>
Your mention of config reminds me that I'd not considered shared nova.conf file. Now each service can support multiple conf files, so we could have common settings in /etc/nova/nova.conf and specific settings in /etc/nova/nova-{compute,network,volume,...}.conf?
"/etc/nova.d/" style split up maybe?
-- Aeolus Community Manager http://www.aeolusproject.org
On 07/27/2012 06:51 AM, Justin Clift wrote:
On 26/07/2012, at 5:00 AM, Pádraig Brady wrote:
<snip> > Your mention of config reminds me that I'd not considered shared nova.conf file. > Now each service can support multiple conf files, so we could have common > settings in /etc/nova/nova.conf and specific settings in > /etc/nova/nova-{compute,network,volume,...}.conf?
"/etc/nova.d/" style split up maybe?
That would be good for separate packages looking to adjust nova's config. Anyway for now I'm sticking with a single /etc/nova/nova.conf
cheers, Pádraig.
On 07/24/2012 07:20 PM, Pádraig Brady wrote:
even though we don't auto enable any services on install, splitting out some sub packages would reduce dependencies on particular packages, saving disk space and identifying and distributing dependencies going forward. The current plan is to split into the following 10 subpackages:
openstack-nova (a new meta package for compat with old scripts) openstack-nova-compute openstack-nova-cert openstack-nova-scheduler openstack-nova-volume openstack-nova-api openstack-nova-network openstack-nova-objectstore openstack-nova-console
I plan to implement this for the existing Essex packages in Fedora 17 and EPEL6 over the next while.
Note to get an idea of the distribution of the disk space at least I used `yum install --disablerepo=*updates pkg1 pkg2` in an F17 VM booted from a live iso. That gave an installed size of existing packages as:
python-nova = 134M openstack-nova = 117M
Splitting to 10 sub packages would give:
python-nova = 56M openstack-nova-compute = 166M openstack-nova-volume = 38M rest are minimal in size (but dep on python-nova)
This split is now pushed to Fedora 17 and EPEL 6 testing:
https://admin.fedoraproject.org/updates/openstack-nova-2012.1.1-11.el6 https://admin.fedoraproject.org/updates/openstack-nova-2012.1.1-11.fc17
cheers, Pádraig.
cloud@lists.stg.fedoraproject.org
-
Alan Pevec -
Daniel P. Berrange -
Justin Clift -
Pádraig Brady -
Robert Kukura -
Steven Dake -
Tim Bell