Re: [Openstack] OpenStack immaturity
There are many projects rolled up into the thing called "OpenStack". Nova is only one of them and is the one that most people are talking about when they say "OpenStack". This does a huge disservice to the other projects especially Swift. It's very frustrating to see the other projects all painted with the Nova brush. On Wed, Apr 4, 2012 at 1:25 PM, Ryan Lane wrote: >> According to the statement of this article from Gartner >> group http://blogs.gartner.com/lydia_leong/2012/04/03/citrix-cloudstack-openstack-and-the-war-for-open-source-clouds/ Openstack is a >> highly immature platform. >> But why? What's make Openstack so immature? >> >> Any comments on that? >> >> Thank you in advance :) >> > > I agree that it's an immature platform. That said, it's also a very > young platform and isn't that to be expected? There's a number of > things that need to be fixed before I'd ever recommend Nova's use in > production: > > 1. There's no upgrade path currently. Upgrading requires fairly > substantial downtime. > 2. Live migration is broken. Utterly. > 3. Every release fixes so many things that it's really important to > upgrade every time; however, only one release will likely be supported > every Ubuntu LTS release, meaning you're either stuck with a really > old (likely broken) version of nova, or you're stuck will a very > likely unstable version of Ubuntu. This will be easier over time, when > nova is more stable and has less bugs, but it's incredibly painful > right now. > > That said, I feel OpenStack's strengths greatly outweigh its > immatureness. I ran a private cloud at my last organization using a > VMWare ESXi cluster. It was more mature, upgrades worked > appropriately, live migration was solid, etc. I had (and still have) > the choice to run VMWare for my current project and am extremely happy > with my choice of OpenStack. The flexibility provided by the platform > and my ability to contribute to its future make its immaturity a > non-concern. Every release gets closer and closer to a stability point > I'm comfortable with. > > This article isn't bad news. In fact, I'd say it shows that > competitors see OpenStack as a fairly major threat. We should be > celebrating this ;). > > - Ryan > > ___ > 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] OpenStack immaturity
On Wed, Apr 4, 2012 at 8:14 AM, Razique Mahroua wrote: > The "immaturity" being exposed here has nothing to do with neither > stability nor bugs - in fact the angle is more about an ease of deployment. > Such statements are not new, and well known from "enterprises" point of > view. > I remember same articles about Linux, few years back about Zimbra, few > months back about proxmox, etc... > > This is an endless statement : "Is it possible for a community-driven > project to find it's place in business needs ?" The answer for Openstack is > NO, when it comes to ease of deployment compared to VMmware, and any > CLI-less required installers... > But even if fantastic progress has been made, on the different projects, > let's face it, even more progress are required today to give a satisfaction > to the OP. > > Let's keep working as we are doing : fixing, testing, thinking, updating. > When all the projects will be stable enough to work on a same level - I'm > quite confident we could see more positives feedbacks from Gartner > > > *Nuage & Co - Razique Mahroua** * > razique.mahr...@gmail.com > > > Le 4 avr. 2012 à 14:48, Jacek Artymiak a écrit : > > It depends on what you expect OpenStack to do for you. If you want > pre-packaged, click-to-install software, it is not there, yet. But if > you want to be able to influence the future of the project you want to > bet your business on, you have a much higher chance of doing that with > OpenStack than with other projects in this space. > > Just my $.02 worth. > > Jacek Artymiak > author: > http://docs.openstack.org/api/openstack-compute/programmer/content/ > (please submit patches so we can improve this document) > > On Wed, Apr 4, 2012 at 12:24 PM, Sébastien Han > wrote: > > Hi everyone, > > > According to the statement of this article from Gartner > > group > http://blogs.gartner.com/lydia_leong/2012/04/03/citrix-cloudstack-openstack-and-the-war-for-open-source-clouds/ > Openstack is a > > highly immature platform. > > But why? What's make Openstack so immature? > > > Any comments on that? > > > Thank you in advance :) > > > ___ > 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] OpenStack immaturity
I believe this "Openstack is a highly immature platform." is referring more to nova than swift. The simple reason for that is nova is more focused on dev than ops but that is changing.In mature projects the questions like "How do I run this reliably every day?" and "How can I safely upgrade from one version to the next?" are just as important as "What new features are coming?". Time will tell. On Wed, Apr 4, 2012 at 6:27 AM, Frans Thamura wrote: > I think this news is good > > Make us must work hard. > > Time will tell > > Like linux, now lead. > > On Apr 4, 2012 5:57 PM, "Diego Parrilla Santamaría" > wrote: >> >> Immaturity of a platform is something you can easily fix paying the right >> fee to your favorite analyst firm. >> >> Seriously, Openstack is an open platform and an open community. This means >> problems and issues are open to discuss to everyone. Propietary platforms >> issues are rarely disclosed, and they look more mature. And believe me, I >> have used most of them and Openstack is not more unstable (or stable) than >> others. >> >> Anyway, it's time to move the stack from 'devs' to 'ops'. When somebody >> says 'you have to install the development version to fix this' instead of >> 'you have to follow this procedure on the stable version', you cannot >> imagine the damage made to Openstack Nova. It's painful, but it's the only >> way to have a robust platform. Let's forget about 'you will have it in the >> next release': we are not Microsoft. This is real, not vapourware. >> >> My two cents >> Diego >> >> -- >> Diego Parrilla >> CEO >> www.stackops.com | diego.parri...@stackops.com | +34 649 94 43 29 >> | skype:diegoparrilla >> >> >> >> On Wed, Apr 4, 2012 at 12:24 PM, Sébastien Han >> wrote: >>> >>> Hi everyone, >>> >>> According to the statement of this article from Gartner >>> group http://blogs.gartner.com/lydia_leong/2012/04/03/citrix-cloudstack-openstack-and-the-war-for-open-source-clouds/ Openstack is a >>> highly immature platform. >>> But why? What's make Openstack so immature? >>> >>> Any comments on that? >>> >>> Thank you in advance :) >>> >>> >>> ___ >>> 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 > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Non-unique display names in Nova
Is there a reason there isn't a unique contraint on display_names per account for volumes, instances, etc? I see this potentially causing some operational problems and customer confusion.Also, currently the python-nova-client will only list the first one when you use the "show" command. What are some of the reasons this would be bad idea? Thanks for your time. --J ___ 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
This is wonderful. Great work. On Thu, Feb 16, 2012 at 11:54 AM, Jay Pipes wrote: > Excellent work Doc team! :) > > > On 02/16/2012 11:02 AM, Anne Gentle wrote: >> >> I'm pleased to point you to http://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.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.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] A possible alternative to Gerrit ...
Sandy, I'm sorry that your suggestion unfortunately got caught up in the general frustration about how the git/gerrit decision came about. Hopefully future decisions can be debated/discussed more before they are made rather than after they are implemented. This should be a lesson learned by both the PPB and community members. --letterj ___ 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] A possible alternative to Gerrit ...
Monty, Is there a published list of work flow requirements for an/the OpenStack project? Not really based on any specific implementation or tool. These is the closest thing I could find. For bzr there are http://wiki.openstack.org/BzrPerfectWorkflow & http://wiki.openstack.org/LifeWithBzrAndLaunchpad For git/gerrit there is this: http://wiki.openstack.org/GerritWorkflow All three of these focus mostly on the tool set. Thanks --letterj ___ 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] A possible alternative to Gerrit ...
Sandy, Thanks for bring this up. I think it's an interesting idea and plan on looking into it when I have some free time. Thierry, Seriously? "while this anti-Gerrit revolt is being sent on the ML" Can we dial down the drama a bit?It's things like this that will discourage people from submitting new ideas. Calling just the introduction of a new idea a "revolt" is a diservice to the community. --letterj ___ 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] [Keystone] [Swift] Keystone Tenant vs Swift Account
The DELETE call that John mentioned must be sent to a proxy server configured with "allow_account_management = true". Same with an account PUT. --J On Tue, Jul 19, 2011 at 9:07 AM, John Dickinson wrote: > Account deletes need to be handled by a DELETE call on the account to the > swift cluster. This would need to be set up as some separate process in your > account management system. > > --John > > > On Jul 19, 2011, at 8:55 AM, Khandeshi, Divyesh wrote: > >> Hi John, >> >> Thanks for the quick API info. >> >> Going back to the lazy model for provisioning accounts, how do you handle >> account deletions? Essentially, the issue here is that since the >> account_autocreate flag only handles creation, what happens when, say, a >> tenant is deleted from Keystone? How does that deletion get >> propagated/synced to Swift? Who or how would the account tombstones be set? >> >> Thanks >> >> Divyesh >> >> >> -Original Message- >> From: John Dickinson [mailto:john.dickin...@rackspace.com] >> Sent: Monday, July 18, 2011 5:03 PM >> To: Khandeshi, Divyesh >> Cc: 'openstack@lists.launchpad.net' >> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >> >> The security implications are tied to what credentials as user gets from the >> auth server you are using. The possibility is that a user could delete their >> own account (or even another user's account) or create new accounts. >> Disabling allow_account_management eliminates these issues by disabling the >> functionality. >> >> There are no formal docs of this part of the API. It's quite simple though: >> PUT/POST/GET/HEAD/DELETE to /v1/"your account string" >> >> --John >> >> >> On Jul 18, 2011, at 3:00 PM, Khandeshi, Divyesh wrote: >> >>> John, >>> >>> Sorry, hit the send button too fast.. >>> >>> What are the security implications? >>> >>> Thanks >>> >>> Divyesh >>> >>> -Original Message- >>> From: openstack-bounces+divyesh.khandeshi=hp@lists.launchpad.net >>> [mailto:openstack-bounces+divyesh.khandeshi=hp@lists.launchpad.net] On >>> Behalf Of Khandeshi, Divyesh >>> Sent: Monday, July 18, 2011 3:56 PM >>> To: John Dickinson >>> Cc: 'openstack@lists.launchpad.net' >>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> John, >>> >>> Thanks for the information. >>> >>> When you mention PUT/DELETE accounts - where is this API documented? Or >>> could you provide more details for the supported methods? >>> >>> Thanks >>> >>> Divyesh >>> >>> -Original Message- >>> From: John Dickinson [mailto:john.dickin...@rackspace.com] >>> Sent: Monday, July 18, 2011 3:41 PM >>> To: Khandeshi, Divyesh >>> Cc: Ziad Sawalha; 'openstack@lists.launchpad.net' >>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> To provision an account in a swift cluster without using the autocreate >>> option, you must run a proxy server with the allow_account_management >>> option set to True. Your auth system then needs to PUT/DELETE accounts to >>> that proxy server as necessary. There are security implications here (which >>> is why the value defaults to false), so you should take care to ensure that >>> only your auth server can talk to the proxy server with this option turned >>> on. >>> >>> --John >>> >>> >>> On Jul 18, 2011, at 2:05 PM, Khandeshi, Divyesh wrote: >>> Hi Ziad, Thanks for your responses. So Swift will authenticate against Keystone directly with the method you describe below? But is there an actual sync mechanism to sync keystone(tenant) -> swift(account)? account_autocreate provides the lazy option. Sorry for repeating this (and may be Swift folks can possibly help): What API/method does Rackspace dashboard use to manage accounts in Swift? Essentially, is there any exposed API access for managing accounts in Swift (non-lazy option). The swift_auth.py appears to only handle auth cases including Swift auth but does not actually provide account management (Swift account CRUD). Thanks Divyesh From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: Monday, July 18, 2011 11:41 AM To: Khandeshi, Divyesh; 'openstack@lists.launchpad.net' Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account Hi Divyesh - additional info I just got: "run with account_autocreate = True. As long as account ids == tenant names, you should be fine. For example, if you request /v1.0/AUTH_foobar and you have the foobar tenant then it will try to authorize against the foobar tenant." Z From: "Khandeshi, Divyesh" Date: Mon, 18 Jul 2011 15:47:31 +0100 To: Ziad Sawalha , "'openstack@lists.launchpad.net'" Subject: RE: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account Ziad, 1. You mention tha
Re: [Openstack] Conflicting st binary name
How about something like "swiftcli"? --J On Fri, Jun 10, 2011 at 7:52 AM, Greg Holt wrote: > On Jun 10, 2011, at 1:50 AM, Thomas Goirand wrote: > >> There's a bug report in the Debian BTS [1] against Nova in SID >> concerning the "st" binary shipped by Swift. Shall we consider renaming >> the binary "st" to something else? I know that a window manager has >> nothing to do with us, but there might be corner cases where it might be >> really annoying. >> >> Thomas >> >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629998 > > Ah, no fun. Someone had mentioned before they thought it should be named > 'swiftly'. > ___ > 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] testing and deploying swift?
Jon, There are just some fantastic tools kind of "hidden" in swift: st swift-get-nodes swift-bench swift-stats-populate & swift-stats-report (will be changing into the swift-dispersion-report in the next version) Take a look at them they are very useful On Wed, May 18, 2011 at 2:13 PM, Jon Slenk wrote: > On Wed, May 18, 2011 at 8:14 AM, Clay Gerrard > wrote: >> Specially regarding "expanding the ring" - one of the Cloud Files ops wrote >> some tips in a lp answer awhile back: >> https://answers.launchpad.net/swift/+question/152024 > > Cool, thank you for the pointer. > > -Jon. > > ___ > 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] testing and deploying swift?
Jon, When dealing with software migrations setting up a staging environment is a must. Set up your staging environment with as many production configs as possible and install the current code then add data. Be sure you can add data that represents your actual use cases. Once that's done upgrade the machines on one zone and run your tests. At that point, you should be able to determine the functional impact. Some important things to test: Are there problems with objects or containers replicating from old code vs new code Are old accounts, containers, and objects working well on using the new code. The dispersion-report is a great tool for production monitoring but it can be very useful for testing too. Production upgrades.Depending on your use case you can shutdown all backend processes for a short time, upgrade the machines, then restart them.Another things to keep in mind is that with a cluster of more four zones a single zone can be updated and watched to determine the impact and them either pull it out of the ring and reset it or continue upgrading the next zone. --J On Wed, May 18, 2011 at 10:14 AM, Clay Gerrard wrote: > Hey Jon, > > Specially regarding "expanding the ring" - one of the Cloud Files ops wrote > some tips in a lp answer awhile back: > https://answers.launchpad.net/swift/+question/152024 > > Clay Gerrard > Software Developer > Rackspace > > >> -Original Message- >> From: openstack-bounces+clay.gerrard=rackspace@lists.launchpad.net >> [mailto:openstack- >> bounces+clay.gerrard=rackspace@lists.launchpad.net] On Behalf Of >> Jon Slenk >> Sent: Tuesday, May 17, 2011 5:34 PM >> To: openstack@lists.launchpad.net >> Subject: [Openstack] testing and deploying swift? >> >> hi, >> >> So what are people's processes for tracking Swift releases, on >> production systems? >> >> I'm guessing Rackspace is probably the most serious deployment to >> date. If anybody there could comment on what release of Swift is being >> run and how you expect to deploy newer versions, that would be fun and >> educational to hear about and mull over. >> >> If anybody working on core Swift could comment on which parts of the >> system are more vs. less dangerous to muck with, that would be great, >> too. For one example, we're still trying to grok the implications of >> significantly changing the Rings (expanding them, usually). Like, what >> even qualifies as "significant" vs. not. >> >> thanks for sharing any experiences, >> -Jon. >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > ___ > 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] Chef Deployment System for Swift - a proposed design - feedback?
Judd, Proxy servers with the allow_account_management flag will accept PUT and DELETE requests on accounts. On most deployments I would think that this functionality would have limited access and locked down. That is why I was suggesting it be broken out into a different roll. --J On Fri, May 6, 2011 at 10:35 AM, Judd Maltin wrote: > Hi Joe - > > Answers inline: > > On Wed, Apr 27, 2011 at 9:55 PM, Jay Payne wrote: >> >> Judd, >> >> I'm not that familiar with Chef (I'll do some research) but I have a >> couple of questions and some thoughts: >> >> 1. Is this for a multi-server environment? > > Yes. >> >> 2. Are all your proxy nodes going to have "allow_account_management = >> true" in the configs? It might be a good idea to have a second proxy >> config for account management only > > I'm not sure - I don't know about the performance impact of such a config. >> >> 3. Have you looked at using swauth instead of auth? > > Not yet. >> >> 4. Have you thought about an admin or client node that has utilities >> on it like st and stats-report? > > Good suggestion. An admin node which is part of the cluster and not subject > to the performance sensitivity of line of business nodes. >> >> 5. How where will you do on-going ring management or changes? > > Rings are defined in a Chef "DataBag". When the databag is updated, Chef > detects the file change. When the chef-client runs on the nodes, they pick > up the config changes. Scheduling and orchestrating the chef-client runs > will also be expressed in the data-bag (or from an orchestration server) >> >> 6. I would think about including some type of functional test at the >> end of the deployment process to verify everything was created >> properly and that all nodes can communicate. > > Good point - adding in validation steps and final functional test. >> >> >> >> --J >> >> On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin wrote: >> > Hi Folks, >> > >> > I've been hacking away at creating an automated deployment system for >> > Swift >> > using Chef. I'd like to drop a design idea on you folks (most of which >> > I've >> > already implemented) and get feedback from this esteemed group. >> > >> > My end goal is to have a "manifest" (apologies to Puppet) which will >> > define >> > an entire swift cluster, deploy it automatically, and allow edits to the >> > ingredients to manage the cluster. In this case, a "manifest" is a >> > combination of a chef databag describing the swift settings, and a >> > spiceweasel infrastructure.yaml file describing the OS configuration. >> > >> > Ingredients: >> > - swift cookbook with base, proxy and server recipes. proxy nodes also >> > (provisionally) contain auth services. storage nodes handle object, >> > container and account services. >> > -- Base recipe handles common package install, OS user creation. Sets >> > up >> > keys. >> > -- Proxy recipe handles proxy nodes: network config, package install, >> > memcache config, proxy and auth package config, user creation, ring >> > management (including builder file backup), user management >> > -- Storage recipe handles storage nodes: network config, storage device >> > config, package install, ring management. >> > >> > - chef databag that describes a swift cluster (eg: >> > mycluster_databag.json) >> > -- proxy config settings >> > -- memcached settings >> > -- settings for all rings and devices >> > -- basic user settings >> > -- account management >> > >> > - chef "spiceweasel" file that auto-vivifies the infrastructure: (eg: >> > mycluster_infra.yaml) >> > -- uploads cookbooks >> > -- uploads roles >> > -- uploads the cluster's databag >> > -- kicks off node provisioning by requesting from infrastructure API >> > (ec2 or >> > what have you) the following: >> > --- chef roles applied (role[swift:proxy] or role[swift:storage]) >> > --- server flavor >> > --- storage device configs >> > --- hostname >> > --- proxy and storage network details >> > >> > By calling this spiceweasel file, the infrastructure can leap into >> > existence. >> > >> > I'm more or less done with all this stuff - and I'd really appreciate >> > conceptual feedback before I take o
Re: [Openstack] Creating a forum
On Thu, May 5, 2011 at 1:51 PM, Ed Leafe wrote: > On May 5, 2011, at 2:06 PM, Jordan Rinke wrote: > >> I don't see why developers are weighing in so heavily on something >> specifically for the user community? Many of you have specifically said you >> wouldn't visit a forum so why do you care so much about what software it >> uses, or if it even exists? > > > I can't speak for others, but I'm not 1-dimensional. The feedback I got at the Summit from individuals and groups trying to deploy multiple server environment (dozens of servers) is lacking with more information and help is requested. I don't think there are a lot of individual developers, without access to large company resources, that are going to stand up/maintain environments of this size and do operational testing. There is a growing number of people/organizations that want this type of information whether it is delivered in a forum, stackexchange, irc or email list. I don't think the medium is as important as just getting it to them in a clear,concise and searchable manner. > > While I may be a nova developer, and a dev on a few other projects, > I'm a user on a much greater number of projects, and have a good idea of what > has worked and not worked for me as a user. I've also gotten feedback from my > users on projects I run, and together this experience has formed my opinions. > There is a big difference between helping a developer get an single server environment up for developing and a company that is deploying dozens of servers for an on going production environment. > As for why I might care, just because some have said they wouldn't > visit doesn't mean that no developer will visit. My guess is that a great > many will want to, and that number will depend on the form such a forum might > take. I also care what the user experience is for a newcomer to the OpenStack > community; like other developers, I have a lot of my own work invested in the > project, and want it to succeed. > I think everyone in this list and especially on this thread cares a great deal about the OpenStack project, the community and the users. It's not necessary to say it. > > > -- Ed Leafe > > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > ___ > 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] Creating a forum
Add me as well --J On Wed, May 4, 2011 at 10:42 AM, Ed Leafe wrote: > On May 4, 2011, at 11:26 AM, Everett Toews wrote: > >> Below is a list of people from this thread who are in favor (or at least >> interested in trying) the StackExchange style. > > > Add me to that list. > > > > -- Ed Leafe > > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > ___ > 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] Separation of IRC Channels
If we do create any new IRC channels I would rather see a #openstack-ops or #openstack-deploy than an #openstack-dev but I do agree that the forum plans should be finalized first. --J Sent from my iPad On May 3, 2011, at 22:47, Todd Willey wrote: > I think we should finalize a plan for the forum before we start > changing IRC. I'd hate to become unresponsive on many fronts at once, > and I think growing just one of those communities will be hard enough. > > On Tue, May 3, 2011 at 8:23 PM, Devin Carlen wrote: >> +1 to not splitting everything up. >> >> On May 3, 2011, at 5:03 PM, Eric Day wrote: >> >>> I would vote for no separation yet, but I understand everyone has >>> a different threshold. If we do separate, +1 on #openstack-dev, >>> #openstack- seems a bit excessive. >>> >>> -Eric >>> >>> On Tue, May 03, 2011 at 07:34:30PM -0400, Jay Pipes wrote: On Tue, May 3, 2011 at 7:16 PM, Ken Pepple wrote: > Do we have to break out all the projects into their own development > channels > ? > Can't we just have a #openstack-dev to cover them all ? > There are a lot of cross-project discussions (especially between > nova/glance, but I think NaaS will also cross quite a few projects). +1 -jay ___ 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 >> > > ___ > 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] Creating a forum
I don't know if a forum is the right answer but I would like to have a better way to organize information about deployments, operational best practices and any issues running OpenStack code in production environments. Maybe the answer is creating a few more mailing lists and irc channels. Having one email list and one irc channel for governing, design, dev, deployments and ops for 3 projects plus the 10 or so new project proposals seems like information overload to me. Just some thoughts --J On Mon, May 2, 2011 at 7:59 PM, Thomas Goirand wrote: > On 05/03/2011 04:12 AM, Jordan Rinke wrote: >> I had a number of discussions with various people at the summit about >> creating a forum for openstack (forum.openstack.org) and everyone >> seemed to think it was a good idea especially for user support and >> discussions for people who are not likely to use a mailing list. So >> I have 2 questions... >> >> 1. Is anyone against creating a forum? >> 2. Does anyone have a specific forum software they suggest we use? > > There are tools which allow forums and lists to be seen as one, and > users would just use the medium they like the most. > > I don't know if this would be possible on a list @launchpad though. > > Just my 2 cents, > > Thomas > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > ___ 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 Deployment System for Swift - a proposed design - feedback?
#x27;s finally nice > around here... hence other weekend plans. > > > On Thu, Apr 28, 2011 at 11:25 PM, Judd Maltin wrote: >> >> Hey andi, >> I'm psyched to collaborate on this. I'm a busy guy, but I'm dedicating >> Sunday to this. So if you have time Sunday, that would be best to catch up >> via IRC, IM or voice. >> Having a node classifier of some sort is critical. >> -Judd >> >> Judd Maltin >> +1 917 882 1270 >> Happiness is a straight line and a goal. -fn >> On Apr 28, 2011, at 11:59, andi abes wrote: >> >> Judd, >> Ok. Here are some of the thoughts I've had (and have mostly working, but >> hitting some swift snags..) Maybe we can collaborate on this? >> Since Chef promotes idempotent operations and cookbooks, I put some effort >> in making sure that changes are only made if they're required, particularly >> around destructive or expensive operations. >> The 2 main cases are: >> - partitioning disks, which is obviously destructive >> - building / rebuilding the ring files - rebalancing the ring is >> relatively expensive. >> for both cases I've built a LWRP which reads the current state of affairs, >> and decides if and what are the required changes. For disks, I'm using ' >> 'parted', which produces machine friendly output. For ring files I'm using >> the output from ring-builder. >> the LWRP are driven by recipes which inspect databag - very similar to >> your approach. However, they also utilize inventory information about >> available resources created by crowbar in chef during the initial bring up >> of the deployment. >> (As a side note - Dell has announced plans to opensource most of crowbar, >> but there's legalese involved) >> >> I'd be more than happy to elaborate and collaborate on this ! >> >> a >> >> >> >> >> >> >> >> On Thu, Apr 28, 2011 at 11:35 AM, Judd Maltin wrote: >>> >>> Hi Andi, >>> >>> Indeed, the swift recipes hadn't been updated since mid 2010, so I pushed >>> forward with my own. >>> >>> Thanks! >>> -judd >>> >>> On Thu, Apr 28, 2011 at 10:03 AM, andi abes wrote: >>>> >>>> Judd, >>>> this is a great idea... actually so great, that some folks @Dell and >>>> OpsCode, me included, have been working on it. >>>> Have a peek on >>>> : https://github.com/opscode/openstack-cookbooks/tree/master/cookbooks >>>> This effort is also being included into Crowbar (take a peek >>>> here: http://robhirschfeld.com/tag/crowbar/) which adds the steps needed to >>>> start with bare metal (rather than installed OS), then using chef to get to >>>> a working Open stack deployment. >>>> (if you're at the design meeting, there are demos scheduled). >>>> That said - I'm updating the swift cookbook, and hope to update github >>>> soon. >>>> a. >>>> >>>> >>>> >>>> >>>> On Wed, Apr 27, 2011 at 9:55 PM, Jay Payne wrote: >>>>> >>>>> Judd, >>>>> >>>>> I'm not that familiar with Chef (I'll do some research) but I have a >>>>> couple of questions and some thoughts: >>>>> >>>>> 1. Is this for a multi-server environment? >>>>> 2. Are all your proxy nodes going to have "allow_account_management = >>>>> true" in the configs? It might be a good idea to have a second proxy >>>>> config for account management only >>>>> 3. Have you looked at using swauth instead of auth? >>>>> 4. Have you thought about an admin or client node that has utilities >>>>> on it like st and stats-report? >>>>> 5. How where will you do on-going ring management or changes? >>>>> 6. I would think about including some type of functional test at the >>>>> end of the deployment process to verify everything was created >>>>> properly and that all nodes can communicate. >>>>> >>>>> >>>>> >>>>> --J >>>>> >>>>> On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin >>>>> wrote: >>>>> > Hi Folks, >>>>> > >>>>> > I've been hacking away at creating an automated deployment system for >>>>> > Swift >>>>> &
Re: [Openstack] Chef Deployment System for Swift - a proposed design - feedback?
Judd, I'm not that familiar with Chef (I'll do some research) but I have a couple of questions and some thoughts: 1. Is this for a multi-server environment? 2. Are all your proxy nodes going to have "allow_account_management = true" in the configs? It might be a good idea to have a second proxy config for account management only 3. Have you looked at using swauth instead of auth? 4. Have you thought about an admin or client node that has utilities on it like st and stats-report? 5. How where will you do on-going ring management or changes? 6. I would think about including some type of functional test at the end of the deployment process to verify everything was created properly and that all nodes can communicate. --J On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin wrote: > Hi Folks, > > I've been hacking away at creating an automated deployment system for Swift > using Chef. I'd like to drop a design idea on you folks (most of which I've > already implemented) and get feedback from this esteemed group. > > My end goal is to have a "manifest" (apologies to Puppet) which will define > an entire swift cluster, deploy it automatically, and allow edits to the > ingredients to manage the cluster. In this case, a "manifest" is a > combination of a chef databag describing the swift settings, and a > spiceweasel infrastructure.yaml file describing the OS configuration. > > Ingredients: > - swift cookbook with base, proxy and server recipes. proxy nodes also > (provisionally) contain auth services. storage nodes handle object, > container and account services. > -- Base recipe handles common package install, OS user creation. Sets up > keys. > -- Proxy recipe handles proxy nodes: network config, package install, > memcache config, proxy and auth package config, user creation, ring > management (including builder file backup), user management > -- Storage recipe handles storage nodes: network config, storage device > config, package install, ring management. > > - chef databag that describes a swift cluster (eg: mycluster_databag.json) > -- proxy config settings > -- memcached settings > -- settings for all rings and devices > -- basic user settings > -- account management > > - chef "spiceweasel" file that auto-vivifies the infrastructure: (eg: > mycluster_infra.yaml) > -- uploads cookbooks > -- uploads roles > -- uploads the cluster's databag > -- kicks off node provisioning by requesting from infrastructure API (ec2 or > what have you) the following: > --- chef roles applied (role[swift:proxy] or role[swift:storage]) > --- server flavor > --- storage device configs > --- hostname > --- proxy and storage network details > > By calling this spiceweasel file, the infrastructure can leap into > existence. > > I'm more or less done with all this stuff - and I'd really appreciate > conceptual feedback before I take out all the non-sense code I have in the > files and publish. > > Many thanks! Happy spring, northern hemispherians! > -judd > > Judd Maltin > T: 917-882-1270 > F: 501-694-7809 > A loving heart is never wrong. > > > > > ___ > 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
[Openstack] Multi Server Test Environment How big?
I submitted a blueprint about creating an environment to get some discussion going about an automated test environment for the OpenStack projects (Nova, Glance, Swift, etc). I believe the goal of this environment is to be able to run: unit and functional tests performance tests true project integration tests benchmarks For each project, what is the DC, Network and Hardware requirement to get meaningful numbers and benefits? Thoughts, questions, comments or concerns? Thanks --J ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
