Re: [Openstack] Proposal for Dashboard as an official OpenStack project
Devin Carlen wrote: I believe the time is right to make the dashboard an official OpenStack project. To my knowledge, no other projects have gone through the incubation process to become an official project, so in some ways we are in uncharted territory. Is there an officially documented process to make this happen? It needs to be proposed to the PPB for acceptance. Please put it on the meeting agenda at [1]. [1] http://wiki.openstack.org/Governance/PPB Note that the PPB still needs to finalize the evolution of its current Project addition process [2] to accommodate the new Core/Incubation/Related project types [3] with clear process to move from one to another. [2] http://wiki.openstack.org/Governance/Approved/NewProjectProcess [3] http://wiki.openstack.org/ProjectTypes Maybe we can do everything in one meeting :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] DRBD storage for Openstack installations
Hi Our approach was defined by need to combine storage and compute on the same hosts. Our configuration is dual-primary, so we can run nova-compute and virtual servers on both nodes and have them with write access to volumes. DRBD allows this mode out-of-box now, but it requires clustered file system or great caution when runnning LVM on it. But nova-volume must run on one node of drbd-connected pair, while the second gets copy of lvm data via drbd. The tricky part is that it seems we must activate volumes and volume groups on the peer node, but automation of this is relatively easy. For now, we are not going to share volumes outside of drbd-peers pair for live migration or as attachable volumes, except some special cases like migrating VMs between drbd pairs. Looking forward to read couple of words on your approach. 2011/5/26 Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com Hi Oleg, thank you very much for your post, it's really didactic. We are taking a different approach for HA at storage level, but I have worked formerly with DRBD and I think it's a very good choice. I'm curious about how you have deployed nova-volume nodes in your architecture. You don't specify if the two nodes of the DRBD cluster run one or two instances of nova-volume. If you run one instance probably you have implemented some kind of fault-tolerant active-passive service if the nova-volume process fails in the active node, but I would like to know if you can run an active-active two nova-volume instances on two different physical nodes on top of the DRBD shared resource. Regards Diego -- Diego Parrilla http://www.stackops.com*CEO* *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 | skype:diegoparrilla* * http://www.stackops.com On Thu, May 26, 2011 at 1:29 PM, Oleg Gelbukh ogelb...@mirantis.comwrote: Hi, We were researching Openstack for our private cloud, and want to share experience and get tips from community as we go on. We have settled on DRBD as shared storage platform for our installation. LVM is used over the drbd device to mange logical volumes. OCFS2 file system is created on one of volumes, mounted and set up as *image_path* and * instance_path* in the *nova.conf*, other space is reserved for storage volumes (managed by nova-volume). As a result, we have shared storage suitable for features such as live migration and snapshots. We also have some level of fault-tolerance, with DRBD I/O error handling, which automatically redirects I/O requests to peer node over network in case of primary node failure. We created scripthttps://github.com/Mirantis/openstack-utils/blob/master/recovery_instance_by_id.pyfor bootstrapping lost VMs in two crash scenarios: * dom0 host restart/domU failure: restore VMs on the same host * dom0 host failure: restore VMs on peer node We are considering such pair of servers with shared storage as a basic block for the cloud structure. For whom it may interest, the details of DRBD installation are herehttp://mirantis.blogspot.com/2011/05/shared-storage-for-openstack-based-on.html. I'll be glad to answer any questions and highly appreciate feedback on this. Oleg S. Gelbukh, Mirantis Inc. www.mirantis.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
[Openstack] Access to OpenStack cluster for Scalr and rest of the community
Fellow Cloudsters, good morning! Is there anyone in the community that could lend us access to an OpenStack cluster we could use to start supporting it in Scalr? We've asked many times, but every request has fizzled out, so we're reaching out with the mailing list this time. Our requirements are minimal, we just need to spin up 2-3 small instances a couple times a day for maybe 2 weeks. A community cluster would be welcome too, but I think we're a long way to having one. Cheers, Sebastian ___ 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] Getting pagination right
On Thu, May 26, 2011 at 9:56 AM, Michael Barton mike-launch...@weirdlooking.com wrote: On Wed, May 25, 2011 at 2:40 PM, Jay Pipes jaypi...@gmail.com wrote: The pagination in Swift is not consistent. Inserts into the Swift databases in between the time of the initial query and the requesting the next page can result in rows from the original first page getting on the new second page. No, you only get records not on the first page, because you're sending a marker of the last item from the first page. Though even if that were the case, I wouldn't do very much work to try and provide some sort of point-in-time consistent view of the database for pagination. Pagination after the page you are on is not consistent. Meaning, if I do a query, go to page 2, I can refresh and the contents of the page may change. That is not a consistent view of data, and that's what I was referring to. Sorry if that was confusing... On Wed, May 25, 2011 at 3:32 PM, Greg Holt gh...@rackspace.com wrote: select w from x where y marker order by y limit z LIMIT X OFFSET Y clause. Your query above would return ALL the rows that match WHERE y marker. That's not what we want. We want a segment of those rows. He had a limit clause in there. The reason we usually shy from offsets is they don't scale. I don't know what cardinality you're expecting on these tables, but if you're querying for an offset of a million, offset's gotta go count a million records before it can return any results. For a marker query, it can just do an index lookup. Sure, I'll grant you that. Not disagreeing with you on the scalability issues around OFFSET (at least as implemented in most RDBMS). My point was about consistent view of data sets and ensuring that page X of a result set doesn't change over time. But, it sounds like folks aren't really concerned about the consistency of the view as much as the scalability concerns, and I'm perfectly cool with ditching OFFSET in favour of a last-record marker. -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
Re: [Openstack] Keystone Release #1 - seeking community input
Agreed. We could create a list of potential standards, protocols, and integration work and maintain it in the README file. I'll get that in… From: James Weir james.w...@usharesoft.commailto:james.w...@usharesoft.com Date: Fri, 27 May 2011 10:24:36 +0200 To: Ziad Sawalha ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone Release #1 - seeking community input Hi, Completely agree with your last statement,but always good to know what other people are doing around identity (albiet web identity in this case). I am not the best person to run with that integration, however, I know the guy that would be. I will reach out to him to see if that would be an interesting side project. Cheers James On 5/26/11 4:22 PM, Ziad Sawalha wrote: Hi James – this is interesting work. Desire to incorporate it into Keystone will increase when and if it gains traction. Either way, if this is something someone (you?) wants to implement as a keystone plug-in, that's why we made it pluggable. Reconfirming also that we're specifically not trying to solve identity (or web identity) with Keystone. We're focused on providing a framework for integrating any existing standard (or custom) identity solution into OpenStack. Thanks for the link. Z From: James Weir james.w...@usharesoft.commailto:james.w...@usharesoft.com Date: Thu, 26 May 2011 09:52:54 +0200 To: Ziad Sawalha ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone Release #1 - seeking community input Hi, Unsure if this is interesting also to consider under the keystone project: http://www.w3.org/wiki/Foaf+ssl This is more for social web, but might be interesting for user authentication. Regards James On 5/26/11 9:04 AM, Ziad Sawalha wrote: Hi Everyone! It's been a while since the summit in Santa Clara. It was great meeting with everyone who was there – looking forward to the next one! Since the summit, we've been working on Keystone and figuring out how to integrate it into OpenStack (Nova, Swift, Glance, and the dashboard). There has been much activity on the project. The code, design, and API has been changing daily. Anyone interested, please join us. RELEASE 1 Milestone 1 for Diablo is right around the corner already! The goal remains to create a common auth system supporting existing use cases. There are a couple of proposals we'd like community input on before we get too far into the implementation: 1. API spec 2. Scope of first release API Spec We've published an API spec doc which we've been altering as requests come in for changes. The spec includes proposals for a core API that covers: * tokens: for authentication * tenants: for isolating and grouping resources to support multi-tenancy * users: because we have to! * roles: to support the Nova roles (see http://nova.openstack.org/runnova/managing.users.html for roles and users) * credentials: to address the EC2, Rackspace auth, multiple-credentials question The draft spec is on github and includes both the core APIs and additional extensions needed to make Keystone function as a stand-alone system. We'd like to lock it down as soon as is feasible. R1 is too close (June 2nd) so we probably won't be done by then, but aiming for Friday June 10th gives us a good couple of weeks to get there and then a couple of weeks to firm up implementation and tests, so we should be able to hit R2 with a locked down API. Scope of R1 For the first Diablo milestone, we're aiming to support the user stories listed in http://wiki.openstack.org/KeystoneR1 ANNOUNCEMENTS Repo We're moving the source to the Rackspace repo (mainly because we can add multiple admins). Please start using the new repo. I will keep both in sync for a while. https://github.com/rackspace/keystone/ I was able to change my config with those commands: git remote rm origin git remote add origin -m master -t master https://your-lo...@github.com/rackspace/keystone.git As you open new issues, please use the Rackspace repo. Participate If you're interested in joining the team and working on Keystone, we'd love the input and help. Just let me know. And, of course, anyone is welcome to submit code, blueprints, issues, etc… Looking forward to hearing from ya'll. Ziad 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
[Openstack] Fwd: help wanted: porting sqlalchemy-migrate for SQLAlchemy 0.7 and sqlalchemy-migrate maintenance
FYI, this has implications for both Nova and Glance. Our relevant bug on Launchpad for this is here: https://bugs.launchpad.net/glance/+bug/787296 Ta, -jay -- Forwarded message -- From: Jan Dittberner jan.dittber...@googlemail.com Date: Thu, May 26, 2011 at 11:41 AM Subject: help wanted: porting sqlalchemy-migrate for SQLAlchemy 0.7 and sqlalchemy-migrate maintenance To: sqlalch...@googlegroups.com Cc: migrate-us...@googlegroups.com, migrate-annou...@googlegroups.com Hello, I work on making sqlalchemy-migrate [1] work with SQLAlchemy 0.7. I fixed all broken unit tests except for one related to adding a new column with a foreign key to an existing table. We have a continues integration system (Jenkins CI) at [2] that provides the output of the failing test. The problem is with some changed behaviour of the SchemaVisitor API (or the Column objects). Until SQLAlchemy 0.6 it was possible to get the constraints object for the ForeignKey arguments of a column. The test at [3] creates a new Column instance and adds it to the table. Afterwards our ANSIColumnGenerator [4] is triggered to generate the necessary SQL statements. Until SQLAlchemy 0.6 the code for generating the foreign key constraints could be generated properly but now the constraint is None instead of a ForeignKeyConstraint. I tried to just ignore fk.constraint if it is None, which expectedly did not generate a statement. I also tried to construct a ForeignKeyConstraint instance and pass that to the AddConstraint constructor. This approach added a second ForeignKey instance to the Column which is not desired too. Can you please give me hints in the right direction or provide help to fix this issue? We would also like to invite interested developers to join the sqlalchemy-migrate project because it has no maintainers with enough time to keep it in a good shape. I think it would be great if the test coverage and code quality would be improved but neither me nor the other current maintainers have enough time to do these necessary prerequisites. We have a quite long list of outstanding issues [5] that need some triaging and fixes and should give a good start for interested developers. [1] http://code.google.com/p/sqlalchemy-migrate/ [2] http://jenkins.gnuviech-server.de/job/sqlalchemy-migrate-all/ [3] http://code.google.com/p/sqlalchemy-migrate/source/browse/migrate/tests/changeset/test_changeset.py#160 [4] http://code.google.com/p/sqlalchemy-migrate/source/browse/migrate/changeset/ansisql.py#87 [5] http://code.google.com/p/sqlalchemy-migrate/issues/list Regards Jan Dittberner -- You received this message because you are subscribed to the Google Groups migrate-users group. To post to this group, send email to migrate-us...@googlegroups.com. To unsubscribe from this group, send email to migrate-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/migrate-users?hl=en. ___ 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] Openstack swift SAIO script with IPv6 support
Morning, If anyone is interested in checking this out and have any thoughts. I have created this swift SAIO setup script a few weeks back and I'm trying to improve it as much as I can when time allows. I have recently added ipv6 support to it, which means I can setup an openstack-swift SAIO vm/slice on full ipv6 (global or ula addresses). So far I have only tested/developed the script with Ubuntu 10.04 but it should be ok on 10.10 I believe https://github.com/btorch/swift-saio.sh Marcelo Martins Openstack-swift btorch...@zeroaccess.org mailto:btorch...@zeroaccess.org ___ 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] Welcome Belinda Lopez, OpenStack Training Manager
On May 27, 2011, at 11:55 AM, Jay Pipes wrote: I believe Belinda's even going to start an OpenStack glossary so I know we've hired the right person. I suggest the first word in the glossary be metadata. Good luck! ;) Ooohh.. that's mean! -- 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
[Openstack] Starting an OpenStack web/docs meeting
Hi all - Great refresh on both the openstack.org site by Todd Morey (wow, that was a ton of work) and the front page of the wiki by Thierry. Way to go! I'm looking at all our web properties all the time and I am inspired to start holding monthly meetings to gather contributors together, share information, and to help people get to know the process around each web site. From the main site to the wiki to each RST site to the docs site, they all serve a common purpose and we want to make them helpful and useful and awesome. We'll use IRC and the meeting bot and the openstack-meeting channel to hold these meetings. Now, to find a good time. Since we have contributors around the world and I'd like to report to the dev meetings on Tuesdays, I'd like to propose that we start with the first Monday of the month, June 6, 2011 at 9:00 pm CST Monday evening (02:00 UTChttp://www.timeanddate.com/worldclock/converted.html?month=6day=6year=2011hour=21min=0sec=0p1=24p2=0). We'll just meet monthly at first and adjust as needed. As a side note, I'm getting ready for the Open Help Conference in Cincinnati June 3-5. If ever a conference was finely tuned to my needs, this one is it, with talks about open source docs, open source support, and open source certification programs all on the list. :) Hope to see you in #openstack-meeting for our first meeting. Thanks, Anne *Anne Gentle* a...@openstack.org my blog http://justwriteclick.com/ | my bookhttp://xmlpress.net/publications/conversation-community/| LinkedIn http://www.linkedin.com/in/annegentle | Delicioushttp://del.icio.us/annegentle| Twitter http://twitter.com/annegentle ___ 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] Starting an OpenStack web/docs meeting
Is there somewhere you could add an iCal feed of these meetings? (meetup.com or your own google account would work). I love me some iCal. Joshua McKenty Piston Cloud Computing, Inc. (650) 283-6846 jos...@piston.cc On 2011-05-27, at 9:29 AM, Anne Gentle wrote: Hi all - Great refresh on both the openstack.org site by Todd Morey (wow, that was a ton of work) and the front page of the wiki by Thierry. Way to go! I'm looking at all our web properties all the time and I am inspired to start holding monthly meetings to gather contributors together, share information, and to help people get to know the process around each web site. From the main site to the wiki to each RST site to the docs site, they all serve a common purpose and we want to make them helpful and useful and awesome. We'll use IRC and the meeting bot and the openstack-meeting channel to hold these meetings. Now, to find a good time. Since we have contributors around the world and I'd like to report to the dev meetings on Tuesdays, I'd like to propose that we start with the first Monday of the month, June 6, 2011 at 9:00 pm CST Monday evening (02:00 UTC). We'll just meet monthly at first and adjust as needed. As a side note, I'm getting ready for the Open Help Conference in Cincinnati June 3-5. If ever a conference was finely tuned to my needs, this one is it, with talks about open source docs, open source support, and open source certification programs all on the list. :) Hope to see you in #openstack-meeting for our first meeting. Thanks, Anne Anne Gentle a...@openstack.org my blog | my book | LinkedIn | Delicious | Twitter ___ 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] Conclusion on Pagination (hopefully!) :)
Jay, +1 on this, however, I would also add linking to the API layer -- as we do in compute 1.1. Links make it supper easy for language bindings to traverse pages -- especially in the case that Thorsten points to, where you want to traverse all items in the collection. In this case, a client can keep following the next link until there aren't any. Links are less error prone, and easier to use in that they keep clients from having to mess with markers at all. The href is based on a marker of course, but the client doesn't have to construct the URL. -jOrGe W. On May 27, 2011, at 11:00 AM, Jay Pipes wrote: Thanks all for some awesome input on the pagination thread. I wanted to summarize what I think were the conclusions to come out of it. Please do let me know if I got it right. Proposal: 1) Push the LIMIT variable into the database API layer 2) Ensure that all queries that return a set of results have an ORDER BY expression to them 3) Push the marker into the database API layer. Continue to have the marker variable be a value of a unique key (primary key for now at least). Use a WHERE field $marker LIMIT $pagesize construct. I *think* this is what's agreed upon? It's basically the Swift model with a variation that the order of results is not static (it can be specified by the user). Please ++ if that looks good and I'll draw up a blueprint Thanks! 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 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
Re: [Openstack] Standardizing resource IDs on UUID?
On May 27, 2011, at 1:15 PM, Erik Carlin wrote: With the proliferation of new openstack services being built, is there any reason not to use UUID as the standard resource ID format? The consensus at the last summit was to move to UUIDs for instance IDs. The biggest concerns were that a) it breaks the current API (which can be updated), and it breaks the EC2 API (which can't be updated). I know that there were some ideas for working around the ec2 issues, but I don't remember them. I think moving ahead, UUIDs scale way better than locally-generated sequential integers. -- Ed Leafe ___ 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] Standardizing resource IDs on UUID?
+1 for UUIDs. If we agree on this approach, there is some difficulty incorporating it into nova as Ed has identified. However, any other projects, especially those hoping to be adopted as Openstack projects by the PPB, can probably switch to this approach more immediately. Just a thought. Ed Leafe e...@leafe.com said: On May 27, 2011, at 1:15 PM, Erik Carlin wrote: With the proliferation of new openstack services being built, is there any reason not to use UUID as the standard resource ID format? The consensus at the last summit was to move to UUIDs for instance IDs. The biggest concerns were that a) it breaks the current API (which can be updated), and it breaks the EC2 API (which can't be updated). I know that there were some ideas for working around the ec2 issues, but I don't remember them. I think moving ahead, UUIDs scale way better than locally-generated sequential integers. -- Ed Leafe ___ 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] Standardizing resource IDs on UUID?
+1 We have blueprints for migrating nova but it will take some time. On May 27, 2011, at 1:02 PM, Mark Washenberger wrote: +1 for UUIDs. If we agree on this approach, there is some difficulty incorporating it into nova as Ed has identified. However, any other projects, especially those hoping to be adopted as Openstack projects by the PPB, can probably switch to this approach more immediately. Just a thought. Ed Leafe e...@leafe.com said: On May 27, 2011, at 1:15 PM, Erik Carlin wrote: With the proliferation of new openstack services being built, is there any reason not to use UUID as the standard resource ID format? The consensus at the last summit was to move to UUIDs for instance IDs. The biggest concerns were that a) it breaks the current API (which can be updated), and it breaks the EC2 API (which can't be updated). I know that there were some ideas for working around the ec2 issues, but I don't remember them. I think moving ahead, UUIDs scale way better than locally-generated sequential integers. -- Ed Leafe ___ 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] Conclusion on Pagination (hopefully!) :)
++ That's the right approach! On May 27, 2011, at 9:00 AM, Jay Pipes wrote: Thanks all for some awesome input on the pagination thread. I wanted to summarize what I think were the conclusions to come out of it. Please do let me know if I got it right. Proposal: 1) Push the LIMIT variable into the database API layer 2) Ensure that all queries that return a set of results have an ORDER BY expression to them 3) Push the marker into the database API layer. Continue to have the marker variable be a value of a unique key (primary key for now at least). Use a WHERE field $marker LIMIT $pagesize construct. I *think* this is what's agreed upon? It's basically the Swift model with a variation that the order of results is not static (it can be specified by the user). Please ++ if that looks good and I'll draw up a blueprint Thanks! 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
Re: [Openstack] Standardizing resource IDs on UUID?
I think Erik's looking for a timeframe for this, too. We could implement this tomorrow in Glance, but there's been a conscience decision to use URIs as an image's globally-unique identifier, and to allow Glance registries to implement whatever image ID they wanted. This can, of course, change, but would break on existing Glance installations. The same would be true of Nova, of course. Old instances would need to be migrated to the new key as well. In Nova, I would say the following must all occur: 1) Change the ID in the model from autoinc keys to string/text UUIDs 2) Remove the current logic in various places that looks for integer keys 3) Add a field to the necessary tables for storing the EC2 ID (internal_id?) 4) Update all the test cases to use non-integer keys (PITA) 5) Test, test, test -jay On Fri, May 27, 2011 at 4:05 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: +1 We have blueprints for migrating nova but it will take some time. On May 27, 2011, at 1:02 PM, Mark Washenberger wrote: +1 for UUIDs. If we agree on this approach, there is some difficulty incorporating it into nova as Ed has identified. However, any other projects, especially those hoping to be adopted as Openstack projects by the PPB, can probably switch to this approach more immediately. Just a thought. Ed Leafe e...@leafe.com said: On May 27, 2011, at 1:15 PM, Erik Carlin wrote: With the proliferation of new openstack services being built, is there any reason not to use UUID as the standard resource ID format? The consensus at the last summit was to move to UUIDs for instance IDs. The biggest concerns were that a) it breaks the current API (which can be updated), and it breaks the EC2 API (which can't be updated). I know that there were some ideas for working around the ec2 issues, but I don't remember them. I think moving ahead, UUIDs scale way better than locally-generated sequential integers. -- Ed Leafe ___ 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] Proposal for Dashboard as an official OpenStack project
+1 The end user experience in OpenStack would greatly benefit from having an official web application that developers can focus their effort on. Devin, if this process winds up involving a vote or if there's is any other way we can support this, please let us know. Thanks, Everett On Thu, May 26, 2011 at 2:05 PM, Devin Carlen devin.car...@gmail.comwrote: Hello all, For quite a while now, the OpenStack Dashboard has existed as an incubation project. There is quite a bit of development effort going into it now from a number of different companies. Current projects underway include, but are not limited to: * swift support * internationalization * a new theme * OpenStack API support * integration with Keystone project This project is quickly gaining contributors, and is in use by a large number of members of the community. I believe the time is right to make the dashboard an official OpenStack project. To my knowledge, no other projects have gone through the incubation process to become an official project, so in some ways we are in uncharted territory. Is there an officially documented process to make this happen? Devin ___ 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] bexar swift socket issue?
hi,
On Fri, May 27, 2011 at 1:18 PM, Jon Slenk jsl...@internap.com wrote:
has anybody else (i've been searching but haven't yet precisely hit
pay-dirt) seen socket hangups with wsgi-related socket/worker code?
this is bexar swift.
In particular, has anybody seen issues / experimented with
swift/common/wsgi.py line 130 eventlet.hubs.use_hub('poll')? We
think we're seeing something akin to Java's notifyAll() bad behaviour,
increasing as more connections come in. Wondering if a different hub
like 'select' is known to help.
thanks.
___
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] Updating SystemUsageData blueprint w.r.t. accounts/tenants
A few of us were looking at starting to implement http://wiki.openstack.org/SystemUsageData, starting with updating the spec to reflect plans related to unified auth (the keystone project). In the blueprint, it was called out that data was to be aggregated by Account ID - which it claimed is NOT the same as a project. My understanding of how unified auth will work is: Nova will be sent a Tenant, User, Roles/Groups from the auth_token middleware If this is so, accounts (things that bind many tenants together) would exist outside of nova, so this level of aggregation (multiple tenants into an account) would occur in an external billing system, not in Nova. I'd like to clarify this so I can update the blueprint. (or alternatively clarify how tenants/users and ... work) Thanks, Jesse ___ 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] Updating SystemUsageData blueprint w.r.t. accounts/tenants
Project is indeed the equivalent of tenant. The multi-tenant-accounting blueprint says usage must be TAGGED with the tenant so that an operator can map and aggregate usage as is appropriate for their own business logic. If we aggregate by tenant, we just need ton recognize that there may eventually be a use case where an operator needs the data pre-aggregation. On 5/27/11 6:46 PM, Jesse Andrews anotherje...@gmail.com wrote: A few of us were looking at starting to implement http://wiki.openstack.org/SystemUsageData, starting with updating the spec to reflect plans related to unified auth (the keystone project). In the blueprint, it was called out that data was to be aggregated by Account ID - which it claimed is NOT the same as a project. My understanding of how unified auth will work is: Nova will be sent a Tenant, User, Roles/Groups from the auth_token middleware If this is so, accounts (things that bind many tenants together) would exist outside of nova, so this level of aggregation (multiple tenants into an account) would occur in an external billing system, not in Nova. I'd like to clarify this so I can update the blueprint. (or alternatively clarify how tenants/users and ... work) Thanks, Jesse ___ 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
Re: [Openstack] Feedback on HTTP APIs
On Fri, May 27, 2011 at 8:52 PM, Mark Nottingham m...@mnot.net wrote: Hi, I've started looking at the 1.1 API draft [1] and want to give some feedback. The draft says that feedback is welcome on the bug queue [2], but I suspect it'd be better to have a dialogue, at least initially. Should I file bugs, or discuss here? Hi Mark! Welcome :) Please feel free to get a conversation going here on the mailing list! If action items come out of the conversation, we'll make bugs and blueprints accordingly. Cheers! 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
Re: [Openstack-poc] Project designations draft
Still trying to get my email working with launchpad again, sorry for the spam... Joshua McKenty Piston Cloud Computing, Inc. (650) 283-6846 jos...@piston.cc On 2011-05-19, at 11:56 AM, John Purrier wrote: I would add this, it fleshes details on the core project definition. John -Original Message- From: openstack-poc-bounces+john=openstack@lists.launchpad.net [mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Thursday, May 19, 2011 1:52 PM To: openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] Project designations draft Jonathan Bryce wrote: Here's a draft of some description around the three project designations: http://wiki.openstack.org/ProjectTypes Let me know what you think, Here is the draft for the project model that Eric and I had to prepare: http://etherpad.openstack.org/PQ7dy5in2B If ok, it could be added to the same page. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] PPB Meeting tomorrow and Incubation program
Still trying to fix sending to launchpad, but I was happy to skip this. Joshua McKenty Piston Cloud Computing, Inc. (650) 283-6846 jos...@piston.cc On 2011-05-26, at 10:16 AM, Vishvananda Ishaya wrote: +1 (or an afternoon...) On May 26, 2011, at 5:33 AM, Soren Hansen wrote: 2011/5/25 Jonathan Bryce jbr...@jbryce.com: Hi all, I won't be able to make the policy board meeting tomorrow. Ewan will not either. There have been no new agenda items added to the wiki page so I propose we skip this week and reconvene next week. If anyone objects, that's fine as well if the rest of you still want to get together, we just need someone to run it and start the meetbot. Sure, I could use an evening off :) -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
