[Openstack] TC Candidacy
I'd like to propose myself as a candidate for the Technical Committee. == About Me == I am currently a Principal Architect at Rackspace, where i work on Private Cloud deployments powered by OpenStack. == OpenStack Experience == I have been contributing to the development of OpenStack side May of 2011. I have contributed to the nova, glance, and keystone projects. Most of my contributions have been focused on usability and functionality of the software (with an operators viewpoint). My reviews and commits can be seen here: https://review.openstack.org/#/q/reviewer:jshepher%2540rackspace.com+OR+owner:jshepher%2540rackspace.com,n,zhttps://review.openstack.org/#/q/reviewer:jshepher%40rackspace.com+OR+owner:jshepher%40rackspace.com,n,z In order to help with ease of installation and configuration, I have worked on a couple of projects in the OpenStack ecosystem. I have spent the most time working on the chef-cookbooks that we use for our deployments. These cookbooks are currently the source from which Opscode is creating the official community cookbooks. https://github.com/rcbops/chef-cookbooks As testing and usability are both important to me, I have contributed to the following test suites. These test suites help validate new deployments, and help us identify issues in milestone releases. https://github.com/rcbops/exerstack https://github.com/rcbops/kong As part of my current position, I have run several multi-day OpenStack workshops with a wide variety of companies. During these workshops, I have had the opportunity to see how business ranging from small to enterprise companies are utilizing/wanting to utilize OpenStack. I believe that this kind of input is extremely valuable to the community and to the project. == Involvement with Open Source == I have been using open source software for the better part of 15 years, and have contributed to multiple projects over the years. OpenStack is the largest project I have ever worked on, and I really enjoy the collaboration pushing it along. == Reasons for interest in TC == As OpenStack adoption increases, upgradability and operator usability also gain in importance. I believe that operator interaction, and ease of management both have a tremendous impact on adoption of OpenStack. I think having an operations viewpoint on the TC will help us as a community continue to improve both of these aspects. Thank you for your consideration, Justin Shepherd ___ 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] Endpoints problems
So why would the preferred method be the one that you have to do all sort of magic stuff to protect from bash extrapolation.. and also given that the code converts those to %(tenant_id).. why wouldn't the %( way be the preferred way? Sounds like an artifact of the CLI being a second class use case.. --shep On Apr 13, 2012, at 8:48 AM, Dean Troyer wrote: On Fri, Apr 13, 2012 at 8:28 AM, Guilherme Birk guib...@hotmail.com wrote: keystone --token ADMIN --endpoint http://192.168.100.142:35357/v2.0 endpoint-create --region RegionOne --service_id=1fd7b5f1add74aa4b6efc514fd153e72 --publicurl=http://192.168.100.142:8774/v2/$(tenant_id)s --adminurl=http://192.168.100.142:8774/v2/$(tenant_id)s --internalurl=http://192.168.100.142:8774/v2/$(tenant_id)s But I'm getting a tenant_id: command not found. When I list the endpoints all my url's are like http://192.168.100.142:8774/v2/s; for the created endpoint. Am I doing something wrong ? You need to escape the '$'s in your URLs or change the double quotes around them to single quotes. The shell sees the $(tenant_id) and attempts to execute a command called tenant_id. dt -- Dean Troyer dtro...@gmail.com ___ 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] Endpoints problems
So looking at the code.. both templated and sql backends seem to support the variable substitution. And if i am reading the code correctly they support both of the following variable declarations: %(tennant_id)s $(tennant_id)s since it appears the code replaces $( with %( --shep On Apr 12, 2012, at 9:33 PM, Lorin Hochstein wrote: On Apr 12, 2012, at 6:44 PM, Pete Zaitcev wrote: On Thu, 12 Apr 2012 15:28:21 -0500 Anne Gentle a...@openstack.orgmailto:a...@openstack.org wrote: keystone --token 012345SECRET99TOKEN012345 --endpoint http://192.168.206.130:35357/v2.0 endpoint-create \ [] --internalurl http://192.168.206.130:8774/v2/$(tenant_id)s I haven't fixed this yet because I'm not sure if the $(tenant_id)s is literal or which tenant_id specifically to use (the Service tenant for the adminurl possibly)? The expression $(tenant_id)s is really contained inside the pattern in the database. It is substituded with a specific tennant ID when an application makes its request. The weird syntax is inherited from Python, where one can use constructs like %s or %(key)s. My understanding (based on somebody's previous answer in the mailing list, or possibly one of the IRC channels) was that you could only do this with the template backend, and when you were using the database backend you had to explicitly add endpoints for each tenant that needed to talk to the API. Can you confirm that you can use the $(tenant_id)s syntax when the backend is set using the following keystone.conf entry: [catalog] driver = keystone.catalog.backends.sql.Catalog Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.comhttps://www.nimbisservices.com/ ___ 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] [NOVA] Snapshotting may require significant disk space (in /tmp). How to properly solve disk space issues?
Sent from my iPad On Mar 16, 2012, at 12:26, Pádraig Brady p...@draigbrady.com wrote: On 03/16/2012 04:11 PM, Jay Pipes wrote: Hi Stackers, So, in diagnosing a few things on TryStack yesterday, I ran into an interesting problem with snapshotting that I'm hoping to get some advice on. == The Problem == QEMU was unhelpfully returning a vague error message of error while writing. That could be improved. As an aside, since qemu-img is mainly dealing with large files, it would be a prime candidate to call fallocate() from to get good layout for the files and immediate feedback if there isn't enough space. On a related note, I've a patch pending for after RC1 that should auto clean any of these partially written files: https://review.openstack.org/#change,5442 As it turns out, the base operating system we install on our compute nodes in TryStack has a (very) small root partition == Possible Solutions == So, there are a number of solutions that we can work on here, and I'm wondering what the preference would be. Here are the solutions I have come up with, along with a no-brainer improvement to Nova that would help in diagnosing this problem: The no-brainer: Detect before attempting a snapshot that there is enough space on a device to perform the operation, and if not, throw a useful error message up the stack The space can change while writing, so you could still get the same error above. Solutions to the disk space problem: (1) Silly Jay, change the damn size of the root partition in your PXE base OS install! Now, I'm no expert in creating customized base disk images, but from looking at the build_pxe_env.sh script in devstack [1], it seems pretty trivial to change the ramdisk_size parameter in the startup options to something larger than 2109600. We could do this and reimage the compute nodes one by one. (2) Make the location in which the snapshot is made configurable. Right now, as mentioned above, tempfile.mkdtemp() is used, which creates a directory in the user's TMPDIR (typically /tmp, which is usually on the root partition). We could add an option (--libvirt-snapshot-dir?) that would allow nova-compute to override where that snapshot is built. (3) Change the user (running nova-compute) TMPDIR setting to something different than /tmp on the root partition). I'd lean towards (3). That's something that depends on the environment (as you've nicely demonstrated), and also for security reasons the admin should be able to set TMPDIR. That's the standard way to do it, and it works already (hopefully). Actually I would argue that the best way to accomplish this would be option #2. That way an admin/operator has control over the location. Not manipulating this by messing around with a users environment variable. 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 ___ 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] [NOVA] Snapshotting may require significant disk space (in /tmp). How to properly solve disk space issues?
On Mar 16, 2012, at 7:51 PM, Pádraig Brady wrote: On 03/16/2012 11:57 PM, Justin Shepherd wrote: On Mar 16, 2012, at 12:26, Pádraig Brady p...@draigbrady.com wrote: On 03/16/2012 04:11 PM, Jay Pipes wrote: Hi Stackers, So, in diagnosing a few things on TryStack yesterday, I ran into an interesting problem with snapshotting that I'm hoping to get some advice on. == The Problem == QEMU was unhelpfully returning a vague error message of error while writing. That could be improved. As an aside, since qemu-img is mainly dealing with large files, it would be a prime candidate to call fallocate() from to get good layout for the files and immediate feedback if there isn't enough space. On a related note, I've a patch pending for after RC1 that should auto clean any of these partially written files: https://review.openstack.org/#change,5442 As it turns out, the base operating system we install on our compute nodes in TryStack has a (very) small root partition == Possible Solutions == So, there are a number of solutions that we can work on here, and I'm wondering what the preference would be. Here are the solutions I have come up with, along with a no-brainer improvement to Nova that would help in diagnosing this problem: The no-brainer: Detect before attempting a snapshot that there is enough space on a device to perform the operation, and if not, throw a useful error message up the stack The space can change while writing, so you could still get the same error above. Solutions to the disk space problem: (1) Silly Jay, change the damn size of the root partition in your PXE base OS install! Now, I'm no expert in creating customized base disk images, but from looking at the build_pxe_env.sh script in devstack [1], it seems pretty trivial to change the ramdisk_size parameter in the startup options to something larger than 2109600. We could do this and reimage the compute nodes one by one. (2) Make the location in which the snapshot is made configurable. Right now, as mentioned above, tempfile.mkdtemp() is used, which creates a directory in the user's TMPDIR (typically /tmp, which is usually on the root partition). We could add an option (--libvirt-snapshot-dir?) that would allow nova-compute to override where that snapshot is built. (3) Change the user (running nova-compute) TMPDIR setting to something different than /tmp on the root partition). I'd lean towards (3). That's something that depends on the environment (as you've nicely demonstrated), and also for security reasons the admin should be able to set TMPDIR. That's the standard way to do it, and it works already (hopefully). Actually I would argue that the best way to accomplish this would be option #2. That way an admin/operator has control over the location. Not manipulating this by messing around with a users environment variable. Well one can set the TMPDIR in the init script for the service. That's a fairly standard mechanism. While it is fairly standard practice.. it makes me cry a little inside every time i have to start adding ENV vars to an init script because of a hard coded value that was not exposed as a configuration option. My $0.02 as an ops guy. (2) is good though if you would ever want to separate --libvirt-snapshot-dir from, $TMPDIR Now I can definitely see the need for changing TMPDIR from /tmp for Jay's reasons and /tmp being tmpfs by default on debian for example: http://lists.debian.org/debian-devel/2011/11/msg00281.html I'm not sure if you'd need to separate them? Though I'm always biased towards avoiding new config variables. I suppose one could argue you might want /tmp for small fast accesses, and something large and separate for manipulating large files. Now that I look at the existing nova uses of tmp dirs to store/stage large images, I see existing config vars: FLAGS.xenapi_sr_base_path # xens default Storage Repo FLAGS.image_decryption_dir # nova/image/s3.py So if you were following that you would implement (2) with: FLAGS.libvirt_snapshot_dir There might be opportunity to merge all three to: FLAGS.nova_image_staging_dir 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] OpenStack Installation Woes - Need re-assurance and help.
On Mar 14, 2012, at 11:57 AM, Anne Gentle wrote: Hi Shep and others - A couple of questions to enhance my understanding while I walk through this for the install doc. Service Tenant - do you create just one service tenant to enclose all the service users? Glance Service User - do you create a Nova Service User and a Swift Service User also? files/default_catalog.templates - are your commands updating the template or a database? It this is a point of confusion. I guess I have to also add: [catalog] driver = keystone.catalog.backends.sql.Catalog to keystone.conf in order to use a database backend for my service catalog? Thanks for improving my mind map. Anne Anne, I based the service tenant off what is done in devstack.. and it creates one service tenant that encloses all the service users. Yes, i also create a nova and swift user that is part of the service tenant (also based on what is being done in devstack). In the example i set the name and password the same, but i generate separate passwords for each in actual deployments. As for the default_catalog.templates, I am not making use of that file in any way. I am creating endpoints from the command line/api which populates the service catalog.. To be honest I also find this file confusing, and do not understand why or how you use it. --shep On Tue, Mar 13, 2012 at 8:59 PM, Justin Shepherd jshep...@rackspace.commailto:jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.orghttp://openstack.org/. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.comhttp://archive.ubuntu.com/ are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack 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] OpenStack Installation Woes - Need re-assurance and help.
Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.orghttp://openstack.org/. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.comhttp://archive.ubuntu.com are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ 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] Problem nova-network failed on ubuntu 12.04
Add --root_helper=sudo nova-rootwrap to your nova.conf file.. this will allow it to work without needing to specify each command by hand or ALL. Also the 12.04 packages are shipping a /etc/sudoers.d/nova file that has the required sudo access for nova-rootwrap --shep On Mar 6, 2012, at 7:59 AM, Leandro Reox wrote: Its not , its a requirement actually, and we ask to add this to the docs, the same happens with nova-volumes Regards On Tue, Mar 6, 2012 at 10:58 AM, Roman Sokolkov rsokol...@gmail.commailto:rsokol...@gmail.com wrote: Hi! I ve trying nova packages on ubuntu 12.04. And have an issue with nova-network: when I try to start nova-network, it failed. Trace in nova-network.log http://paste.openstack.org/show/6812/ (nova): TRACE: Command: sudo iptables-save -t filter (nova): TRACE: Exit code: 1 (nova): TRACE: Stdout: '' (nova): TRACE: Stderr: 'sudo: no tty present and no askpass program specified\nSorry, try again.\nsudo: no tty present and no askpass program specified\nSorry, try again.\nsudo: no tty present and no askpass program specified\nSorry, try again.\nsudo: 3 incorrect password attempts\n' (nova): TRACE: If I try to add in sudoers something like this nova ALL=(ALL) NOPASSWD:ALL. All works good, but I think it is bad practise -- Regards, Roman Sokolkov ___ 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.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] Remove Zones code - FFE
+1 for cell Sent from my iPhone On Feb 18, 2012, at 14:32, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com wrote: +1 to cell. On Feb 18, 2012 9:41 AM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.commailto:cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com ___ 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.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] announcing api.openstack.org
Awesome work Anne and team.. On Feb 16, 2012, at 10:42 AM, Razique Mahroua wrote: Awesome job. - as always with Anne. I'm on it right now. Very efficient and powerful tool on a daily basis. Nuage Co - Razique Mahroua razique.mahr...@gmail.commailto:razique.mahr...@gmail.com NUAGECO-LOGO-Fblan_petit.jpg Le 16 févr. 2012 à 17:36, Jim Curry a écrit : Great stuff Anne and team! On 2/16/12 10:23 AM, Duncan McGreggor dun...@dreamhost.commailto:dun...@dreamhost.com wrote: *high fives* to Anne and everyone else involved! d On Thu, Feb 16, 2012 at 9:02 AM, Anne Gentle a...@openstack.orgmailto:a...@openstack.org wrote: I'm pleased to point you to http://api.openstack.orghttp://api.openstack.org/. Collecting OpenStack APIs on one page, built with an API developer in mind. This design implementation fulfills a blueprint for the openstack-manuals project. Inspired by sites like https://dev.twitter.com/docs/api but with a scope that we could actually complete prior to Essex, the site shows Identity 2.0, Compute 1.1, and Image 1.0 APIs with Object Storage to follow. The API site aims to document the installation at http://trystack.orghttp://trystack.org/ for starters. Different OpenStack deployments may choose different API extensions, for example, and extensions are not reflected on this site quite yet. The source for the page is three WADL files plus an index page that builds the HTML with a Maven plugin. There are JSON and XML samples for some of the methods, defaulting to JSON. A search box allows you to search the entire page whether the content is revealed or not. Click the details buttons to expand the content below each PUT/POST/GET/DELETE method. Click the close button to contract the content back to one line. Refresh the page to compress all expanded content. We welcome bug reports (and know of some bugs already) against the openstack-manuals project, tagged with api-site. Much appreciation and love for Joe Heck for cheerleading for the site and scope. A huge shout-out to the doc tools team at Rackspace especially David Cramer, Joe Savak, and Thu Doan for their efforts. Brian Waldon and Jorge Williams reviewed the site as we iterated on it and I appreciate it. Thanks y'all! I humbly hand it over to you all to keep improving it - the content needs additions for certain and we need to get the Object Storage WADL written. Patches welcome! Warmly, Anne ___ 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.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.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.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] [CHEF] Aligning Cookbook Efforts
Jay and All, I have a couple of questions about the goals of the proposal. 1. What is the origin for the package declarations? - PPA's - Tarball - OS Packages (e.g. whatever happens to be in ubuntu's 11.04 or 11.10 repo?) - Git checkout 2. Are these cookbooks meant to be run from a chef-server or as a chef-solo run? 3. In the case of stable branches, are the cookbooks going to be targeted at a specific release point inside of a branch? Or will they always be updated to follow the head of a branch. 4. Are the cookbooks going to be aimed at all first class hypervisors? As a maintainer of yet another repo of chef recipes (RCB Deploy) and committer to Crowbar, I am happy to collaborate on the consolidation. --shep On Feb 7, 2012, at 12:21 AM, Monty Taylor wrote: On 02/06/2012 06:07 PM, Jay Pipes wrote: Hi Stackers, tl;dr - There are myriad Chef cookbooks out there in the ecosystem and locked up behind various company firewalls. It would be awesome if we could agree to: * Align to a single origin repository for OpenStack cookbooks * Consolidate OpenStack Chef-based deployment experience into a single knowledge base * Have branches on the origin OpenStack cookbooks repository that align with core OpenStack projects * Automate the validation and testing of these cookbooks on multiple supported versions of the OpenStack code base Details --- Current State of Forks == Matt Ray and I tried to outline the current state of the various OpenStack Chef cookbooks this past Thursday, and we came up with the following state of affairs: ** The official OpenStack Chef cookbooks ** https://github.com/openstack/openstack-chef These chef cookbooks are the ones maintained mostly by Dan Prince and Brian Lamar and these are the cookbooks used by the SmokeStack project. The cookbooks contained in the above repo can install all the core OpenStack projects with the exception of Swift and Horizon. This repo is controlled by the Gerrit instance at review.openstack.org just like other core OpenStack projects. However, these cookbooks DO NOT currently have a stable/diablo branch -- they are updated when the development trunks of any OpenStack project merges a commit that requires deployment or configuration-related changes to their associated cookbook. Important note: it's easy for Dan and Brian to know when updates to these cookbooks are necessary -- SmokeStack will bomb out if a deployment-affecting configuration change hits a core project trunk :) I would like to get these to have a stable/diablo branch. These cookbooks are the ONLY cookbooks that contain stuff for deploying with XenServer, AFAICT. I think Dan and Brian are also deploying kvm as part of smokestack. ** NTT PF Lab Diablo Chef cookbooks ** https://github.com/ntt-pf-lab/openstack-chef/ So, NTT PF Lab forked the upstream Chef cookbooks back in Nov 11, 2011, because they needed a set of Chef cookbooks for OpenStack that functioned for the Diablo code base. While Nov 11, 2011, is not the *exact* date of the Diablo release, these cookbooks do in fact work for a Diablo install -- Nati Ueno is using them for the FreeCloud deployment so we know they work... If these are a fork of openstack/openstack-chef, could we perhaps make these the basis of a stable/diablo branch in openstack-chef? ** OpsCode OpenStack Chef Cookbooks ** Matt Ray from OpsCode created a set of cookbooks for OpenStack for the Cactus release of OpenStack: https://github.com/mattray/openstack-cookbooks http://wiki.opscode.com/display/chef/Deploying+OpenStack+with+Chef These cookbooks were forked from the Anso Labs' original OpenStack cookbooks from the Bexar release and were the basis for the Chef work that Dell did for Crowbar. Crowbar was originally based on Cactus, and according to Matt, the repositories of OpenStack cookbooks that OpsCode houses internally and uses most often are Cactus-based cookbooks. (Matt, please correct me if I am wrong here...) ** Rackspace CloudBuilders OpenStack Chef Cookbooks ** The RCB team also has a repository of OpenStack Chef cookbooks: https://github.com/cloudbuilders/openstack-cookbooks Now, GitHub *says* that these cookbooks were forked from the official upstream cookbooks, but I do not think that is correct. Looking at this repo, I believe that this repo was *actually* forked from the Anso Labs OpenStack Chef Cookbooks, as the list of cookbooks is virtually identical. ** Anso Labs OpenStack Chef Cookbooks ** These older cookbooks are in this repo: https://github.com/ansolabs/openstack-cookbooks/tree/master/cookbooks Interestingly, this repo DOES contain a cookbook for Swift. Current State of Documentation == Documentation for best practices on using Chef for your OpenStack deployments is, well, a bit scattered. Matt Ray has
