[Openstack] trystack.org down?
Sorry if this has been asked before, but has the trystack.orghttp://trystack.org service been suspended? I haven't been able to reach it for a week or more. -- Glen Campbell • Developer Advocate, Rackspace Developer Relations Group glen.campb...@rackspace.commailto:glen.campb...@rackspace.com • http://glenc.co • @glenc ___ 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] Downstream handling of extensions
Oops, realized that I didn't include the list… Glen Campbell • Developer Relations Group glen.campb...@rackspace.commailto:glen.campb...@rackspace.com • (210) 446-9990 • @glenc On Jun 14, 2012, at 12:26 PM, Brian Waldon wrote: My team is working on a set of language bindings for OpenStack and Rackspace services. The first language we're working on is Python, and I'm trying to come up with a simple, generic way to handle API extensions. The first question that comes to mind is why duplicate effort with the rest of the community? We already have a comprehensive set of python bindings and would love to have some real development effort invested in them. Two reasons: 1. Because there's existing bindings :) None of us are very strong Python developers, and it gives us a chance to get through the existing code and learn from the pros 2. Because there's only existing bindings for OpenStack stuff; not for (Rackspace-specific services) CloudDns, CloudDatabases, etc. We also have as our goal solving some of the larger problems (such as generic extension handling). We hope to address those and feed them back to the community. For example, the novaclient only supports native Keystone and RAX-KSKEY auth. It doesn't support any of the other auth extensions out there, and it's hard-coded to look at only those two. If I develope a generic auth module, we could update novaclient and voila! it would support HP's slightly different API key mechanism plus others that come along. So, for the OpenStack projects, you can think of this as the real development effort invested in them, since they're our sole focus at the moment. ___ 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] Image API v2 Draft 4
I'll bring the fish On Apr 9, 2012, at 11:05 PM, Monty Taylor wrote: On 04/09/2012 04:11 PM, Jay Pipes wrote: On 04/09/2012 07:07 PM, Jorge Williams wrote: On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of the EC2 API have never even seen the data representation! I take it you didn't attend the glorious JSON debate of a couple of summits ago :-) Glorious it was indeed. I'm up for round two, Only with beer. :) I still owe you a couple I think! I refuse to not be there for that. Please make sure I'm in the room. With a video camera. And a bottle of whiskey. Monty ___ 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] Donabe?
Is anything still happening with the Donabe project? Are there plans to push things forward at the Folsom summit? Thanks, Glen ___ 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] [Ops] Admin API: Actions to perform on accounts
The Ozone team at Rackspace has it in our current backlog, but we have not started working on it yet. Probably will be around February, however. On Dec 20, 2011, at 2:24 PM, Thierry Carrez wrote: Duncan McGreggor wrote: There is a blueprint on LP for admin account actions that is set as a high priority, but is missing the following information: * status * series goal * milestone target Series goal and milestone targets are set once someone committed to delivering the feature in a given timeframe. Status should be updated, though :) The blueprint is here: https://blueprints.launchpad.net/nova/+spec/admin-account-actions Devin Carlen, I see that a branch you own has been attached to this blueprint; are you working on this? Does your branch intend to cover all the work? Or are you going to split it over multiple branches? If you're working on this blueprint, do you expect to complete it for this milestone? That bzr branch is probably a bit old now. -- 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 ___ 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] Donabe meetings on Wed 2pm (and cancelling this week's)
For others outside of California, that's 2PM Pacific time. :-) Glen Campbell • Cloud 2.0 Architect glen.campb...@rackspace.commailto:glen.campb...@rackspace.com • (210) 446-9990 On Oct 26, 2011, at 2:07 PM, Debo Dutta (dedutta) wrote: Hi Lots of people had expressed interest but they were not aware of the meeting times (we did send out emails but maybe we should have re-sent a few times). We meet at 2pm on Wed, @#openstack-meetings ….. Please join us and help us make Donabe better. Also we are canceling this week’s and hope to have a lot of folks for next week. Regards Debo/Rick ___ 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] OSAPI equivalent of euca-get-console-output ?
At Rackspace, we have developed an extension that returns the URL of a console
via /servers/{id}/console.
The issue for putting this in OSAPI core is that the implementation is highly
specific to the console server software that you're running.
Glen Campbell • Cloud 2.0 Architect
glen.campb...@rackspace.commailto:glen.campb...@rackspace.com • (210) 446-9990
On Oct 21, 2011, at 11:30 AM, Day, Phil wrote:
Hi Folks,
The title says it all really – is there an OSAPI / nova-client equivalent to
the EC2 command to get the console output of a VM ?(I can’t see anything in
the code or extensions which calls the relevant compute.api method)
If there’s nothing at the moment are there any plans for adding in (seems like
is should be a core server action rather that an extension) ?
Thanks,
Phil
___
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
This email may include confidential information. If you received it in error,
please delete it.
___
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: Admin API blueprints
We're in the midst of implementing these now: https://blueprints.launchpad.net/nova/+spec/admin-account-actions Essentially suspend/resume for all servers associated with a tenant ID. We're still having discussions around the mass deletion and whether or not we want to expose something that risky (since it's easy enough just to list the servers and delete each one). If we do, it will almost certainly occur after this: https://blueprints.launchpad.net/nova/+spec/deferred-delete-instance [cid:9A0D0DA3-6B19-4D1E-9276-36B9E4A9DC3B] From: Rouault, Jason (Cloud Services) jason.roua...@hp.commailto:jason.roua...@hp.com Date: Tue, 30 Aug 2011 20:56:36 + To: Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com, Nguyen, Liem Manh liem_m_ngu...@hp.commailto:liem_m_ngu...@hp.com Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Nova: Admin API blueprints And does that interface exist? Thanks, Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.netmailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Tuesday, August 30, 2011 12:31 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Nova: Admin API blueprints With keystone in use, there is no user and project object in nova anymore. So the only thing that would make sense inside of nova is: delete all resources associated with a given project_id string. Vish On Aug 30, 2011, at 11:11 AM, Nguyen, Liem Manh wrote: How is Nova project/user deletion handled then? There is no synchronization for that currently. Liem ___ 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 This email may include confidential information. If you received it in error, please delete it. inline: signature[9].png___ 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] Nova: Admin API blueprints
As we discussed at last week's meeting, I have re-factored the generic Admin API blueprint into three separate blueprints. https://blueprints.launchpad.net/nova/+spec/admin-account-actions covers actions that an administrator can perform on a tenant/or account, such as suspending the account or suspending all of the servers for an account. https://blueprints.launchpad.net/nova/+spec/admin-server-actions covers actions that can be performed by an administrator on a server (suspend and resume at the moment). Finally, and this is the largest change, https://blueprints.launchpad.net/nova/+spec/admin-service-actions covers administrative actions on services. This used to be on /hosts but, because of my lack of understanding, we were not actually administering physical hosts, but the services that run on those hosts. For example, we're proposing that a compute node be able to be placed in MAINTENANCE_MODE — in this mode, the compute node will no longer accept any instance create requests, but will handle any other requests. The use case is for when a server is failing (for example, multiple disk failures have been detected). The administrator can put the host in maintenance mode, ensuring that no new instances are put there, and can then force migrations to move instances off of the node. Any and all feedback is appreciated. [cid:8AB30009-39F1-4E53-959A-2ED84BC80963] This email may include confidential information. If you received it in error, please delete it. inline: signature[7].png___ 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: Admin API blueprints
I believe that blueprints are strongly encouraged, but I'm not sure they're absolutely required, especially for an API extension since those are explicitly NOT in the core code. [cid:2B0DFC26-509D-4B57-8993-14695D4F6F4E] From: Nick Sokolov chemika...@gmail.commailto:chemika...@gmail.com Date: Tue, 23 Aug 2011 20:44:57 +0400 To: Glen Campbell glen.campb...@rackspace.commailto:glen.campb...@rackspace.com Subject: Re: [Openstack] Nova: Admin API blueprints I am going to merge extention for network manipulating https://code.launchpad.net/~chemikadze/nova/contrib-extention-networks/+merge/72204 . Must I write blueprint? 23.08.2011 19:31 пользователь Glen Campbell glen.campb...@rackspace.commailto:glen.campb...@rackspace.com написал: As we discussed at last week's meeting, I have re-factored the generic Admin API blueprint into three separate blueprints. https://blueprints.launchpad.net/nova/+spec/admin-account-actions covers actions that an administrator can perform on a tenant/or account, such as suspending the account or suspending all of the servers for an account. https://blueprints.launchpad.net/nova/+spec/admin-server-actions covers actions that can be performed by an administrator on a server (suspend and resume at the moment). Finally, and this is the largest change, https://blueprints.launchpad.net/nova/+spec/admin-service-actions covers administrative actions on services. This used to be on /hosts but, because of my lack of understanding, we were not actually administering physical hosts, but the services that run on those hosts. For example, we're proposing that a compute node be able to be placed in MAINTENANCE_MODE — in this mode, the compute node will no longer accept any instance create requests, but will handle any other requests. The use case is for when a server is failing (for example, multiple disk failures have been detected). The administrator can put the host in maintenance mode, ensuring that no new instances are put there, and can then force migrations to move instances off of the node. Any and all feedback is appreciated. [cid:8AB30009-39F1-4E53-959A-2ED84BC80963] This email may include confidential information. If you received it in error, please delete it. This email may include confidential information. If you received it in error, please delete it. inline: signature[8].png___ 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] Physical host identification
I understand that we're all familiar with virtualization and its benefits.
However, in the Real World, those of us who run clouds often need to work with
physical devices. I've proposed a blueprint and spec for a /hosts admin API
resource that would return information on physical hosts. However, I don't
believe that there's any way for us to actually identify a specific server (I'm
actually hoping I'm mistaken about this, because that would make my life
easier).
So, to get information about a specific host, you'd use /host/{id} — but what
should go in the {id} slot?
We'd also like to include this data elsewhere; for example, in error messages,
it might help to know the physical device on which a server is created.
[cid:EE757CE3-4A6A-4BB0-842C-849556274E00]
This email may include confidential information. If you received it in error,
please delete it.
inline: signature[4].png___
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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I kind of like the IPv6 idea myself. How would it work with a service provider that, for example, assigns a /96 address for an instance? If the user can change the IP address, would that mean that the instance ID would change as well? Or should we just keep with the original /96 (::0) address? On 7/11/11 2:57 PM, Chris Behrens chris.behr...@rackspace.com wrote: If you're referring to encoding zone information, yes it would. I was trying to ask more generally as well. IPv6 would be a very good solution, IMO. - Chris On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote: Won't an IPv6 address do that by it's very nature? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Monday, July 11, 2011 4:24 PM To: Ed Leafe Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ 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] Nova diablo-2
https://launchpad.net/nova/+milestone/diablo-2 There are a number of High priority blueprints that are showing as not started. Do we think those will be completed by diablo-2, or should we look into moving them out? It's an important question for us, since we will be deploying an alpha release of OpenStack based on the diablo-2 milestone, and I'd like to know what we will be including. [cid:F3B46A4E-99D9-43EB-ACC7-6422613B782D] 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. inline: signature.png___ 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] Glance API Extensions
Hey, all – I've proposed a blueprint for adding extensions to the Glance API in a similar manner to the Compute API Jorge proposed: https://blueprints.launchpad.net/glance/+spec/glance-api-extensions This would IMHO be a really useful mechanism for companies like Rackspace to add business-specific features that really don't need to be in the core code. We don't really want to fork the code to add our stuff, and those seem to be the only two options at the moment. I'd appreciate your feedback. Glen Campbell 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
There was another specific use case, where someone with a private OpenStack cloud was bursting into a public cloud. UUIDs would help ensure the uniqueness of identifiers in that case. On 5/29/11 8:43 PM, Mark Nottingham m...@mnot.net wrote: Ah -- makes sense. Thanks. On 30/05/2011, at 11:40 AM, Ed Leafe wrote: On May 29, 2011, at 9:01 PM, Mark Nottingham wrote: WIth regards to UUIDs -- I'm not sure what the use cases being discussed are (sorry for coming in late), but in my experience UUIDs are good fits for cases where you truly need distributed extensibility without coordination. In other uses, they can be a real burden for developers, if for no other reason than their extremely unwieldy syntax. What are the use cases here? The primary use case I can think of is a deployment with several zones that are geographically dispersed. Since each zone is shared-nothing with other zones, UUIDs are the most logical choice for instance IDs that need to be unique across zones. This is precisely the use case that UUIDs were created for. In my experience, UUIDs are no more of a programmatic burden than any other sort of PK; the only place where they are unwieldy is when humans have to type them into a command line or a browser URL. But since most humans doing that would have access to copy/paste, it isn't nearly as bad as it might seem. -- 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. -- Mark Nottingham http://www.mnot.net/ ___ 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
[Openstack] Global deployment of Glance
If we are going to deploy Glance to support a global deployment of Nova, would it make sense to have replicas in different regions for better performance? Or, to put it another way, is there a recommended way to keep multiple Glance installations in sync? Users doing snapshots/backups, etc., would presumably get better performance if Glance was local, but how would we keep the base/shared images in sync? [cid:67C8D8D2-A2AD-473E-8376-07B9818708A7] 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. inline: signature[4].png___ 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 security / automated python testing
Is anyone in the OpenStack community using automated tools to perform code analysis? If not, are you familiar with such tools that will work with python? We're specifically interested in tools that can be used to provide rapid feedback to developers about potentially dangerous code (for example, SQL statements that are not scrubbed, query strings that are not properly validated). I've used such tools in the past for PHP and other languages, but I'm kind of at a loss when it comes to python. What we'd really like to see is for someone to pick up the security task and run with it, with regular penetration testing and detailed analytics so that we can ensure that OpenStack products are reliably secure. Automated code testing is an early step in that process. [cid:F414D321-0144-4256-A1AB-F8051E60ED24] 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. inline: signature[1].png___ 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
This concerns me, as its not scalable. Yes, a few users might pick up some valuable information by osmosis, but as the use of OpenStack grows, it will require massive amounts of repetition to ensure that the same knowledge goes to all users. IRC is *not* the proper medium for capturing user information; that needs to be static and updatable. On 5/4/11 7:48 AM, Michael Shuler mshu...@gmail.com wrote: Wayne's observation is spot on - users hanging out with the devs and gaining valuable information by osmosis is a huge reason to leave main conversation in one location. Too many times I've seen a split, then the -dev mantra becomes that's a -user question, go ask there.. 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] Creating a forum
I wish the list archives had a better search function. On 5/2/11 3:12 PM, Jordan Rinke jor...@openstack.org 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? Once I have it all configured, we will need to determine the categories and get moderators etc for each category. Stephen Spector will be the keeper of the kingdom in that regard so if you would like to help out just let him know. ___ 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] Enhancements to Glance in Diablo? Input welcomed
Here's another Glance enhancement that we need for Rackspace: https://blueprints.launchpad.net/glance/+spec/glance-notifications On 4/12/11 1:11 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, We're in the planning stages for Diablo now, working on putting together blueprints, which turn into sessions at the design summit. I know the Glance team is small and our project narrow in scope, but it would be great to get some feedback from the list about stuff you'd like to see included in Glance in the Diablo release. Some possible thoughts: * Authn/authz - This is a big one, but dependent on the overall discussion of federated auth going on in the Nova/Swift communities. Glance will merely follow suit with what Nova does most likely. * Image conversion. This actually already has a blueprint, but maybe good for a detailed discussion at the summit? See https://blueprints.launchpad.net/glance/+spec/image-file-conversion * Metrics - for instance, tracking operations performed (read/write, bytes out/in, ?) Would this even be useful? * Integration with more backend storage systems? * XML support in the API? * Having Glance understand what is contained in the disk images by inspecting them on upload? * A Glance dashboard app? Please feel free to expand on any of the above and add any suggestions you have on the future direction of Glance. Your input is truly appreciated. 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 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] Enhancements to Glance in Diablo? Input welcomed
I posted a Blueprint yesterday with a requirement for some general-purpose filters for listing images: https://blueprints.launchpad.net/glance/+spec/query-filters These are needed at Rackspace to meet feature parity with our current systems. We need to be able to create various subsets of image collections, and IMHO it makes more sense to do this on the server side than at the client. For example, we want a customer to get a list of their images for restoring from a backup. For our managed customers, we need to select only base images that have a managed cloud flag set in the metadata. We need to be able to set a minimum RAM requirement on certain images and validate that the requested VM is large enough to hold them. Some of this may already be in Glance, but I'm not that familiar with it (and trying to get up to speed). On 4/12/11 1:11 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, We're in the planning stages for Diablo now, working on putting together blueprints, which turn into sessions at the design summit. I know the Glance team is small and our project narrow in scope, but it would be great to get some feedback from the list about stuff you'd like to see included in Glance in the Diablo release. Some possible thoughts: * Authn/authz - This is a big one, but dependent on the overall discussion of federated auth going on in the Nova/Swift communities. Glance will merely follow suit with what Nova does most likely. * Image conversion. This actually already has a blueprint, but maybe good for a detailed discussion at the summit? See https://blueprints.launchpad.net/glance/+spec/image-file-conversion * Metrics - for instance, tracking operations performed (read/write, bytes out/in, ?) Would this even be useful? * Integration with more backend storage systems? * XML support in the API? * Having Glance understand what is contained in the disk images by inspecting them on upload? * A Glance dashboard app? Please feel free to expand on any of the above and add any suggestions you have on the future direction of Glance. Your input is truly appreciated. 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 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] Commas and semicolons
On 4/14/11 6:19 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: Capabilities are just multi-value key-value pairs, such as: can_host=linux;windows, cpu_type=gpu, magic_sauce=purple,blue,red; cpu_min_max=0.01,0.98; I don't like the use of commas and semicolons, and you just made the error here that I was worried about. A semicolon has a higher precedence than a comma, if you will, and is used to separate clauses. You used a semicolon between linux;windows in the above example, then commas between the other clauses, but forgot on the magic_sauce and cpu_min_max clauses. IMHO we should use commas to separate the various values, and semicolons in between the keys. Thoughts? ___ 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] Enhancements to Glance in Diablo? Input welcomed
Yes, he and I have been emailing. I'd like to see it more generalized, rather than having only a limited set of attributes. On 4/14/11 8:45 AM, Jay Pipes jaypi...@gmail.com wrote: Hi Glen! Actually, the excellent Brian Waldon has already started working on this specifically: https://blueprints.launchpad.net/glance/+spec/api-results-filtering The blueprint was originally scheduled for Cactus, but we just didn't get around to it. Think we can combine the two blueprints? Feel free to add any input on the whiteboard for the above blueprint! Cheers! -jay On Thu, Apr 14, 2011 at 9:32 AM, Glen Campbell glen.campb...@rackspace.com wrote: I posted a Blueprint yesterday with a requirement for some general-purpose filters for listing images: https://blueprints.launchpad.net/glance/+spec/query-filters These are needed at Rackspace to meet feature parity with our current systems. We need to be able to create various subsets of image collections, and IMHO it makes more sense to do this on the server side than at the client. For example, we want a customer to get a list of their images for restoring from a backup. For our managed customers, we need to select only base images that have a managed cloud flag set in the metadata. We need to be able to set a minimum RAM requirement on certain images and validate that the requested VM is large enough to hold them. Some of this may already be in Glance, but I'm not that familiar with it (and trying to get up to speed). On 4/12/11 1:11 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, We're in the planning stages for Diablo now, working on putting together blueprints, which turn into sessions at the design summit. I know the Glance team is small and our project narrow in scope, but it would be great to get some feedback from the list about stuff you'd like to see included in Glance in the Diablo release. Some possible thoughts: * Authn/authz - This is a big one, but dependent on the overall discussion of federated auth going on in the Nova/Swift communities. Glance will merely follow suit with what Nova does most likely. * Image conversion. This actually already has a blueprint, but maybe good for a detailed discussion at the summit? See https://blueprints.launchpad.net/glance/+spec/image-file-conversion * Metrics - for instance, tracking operations performed (read/write, bytes out/in, ?) Would this even be useful? * Integration with more backend storage systems? * XML support in the API? * Having Glance understand what is contained in the disk images by inspecting them on upload? * A Glance dashboard app? Please feel free to expand on any of the above and add any suggestions you have on the future direction of Glance. Your input is truly appreciated. 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 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. 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] Search API
To diagnose issues in a production system, administrators may at times need to find a server or host based on limited information. I've proposed a blueprint for a generic search API with wildcard support to handle this need; I'm curious to learn if others also see that need, or if there are existing Nova features that would meet the need. https://blueprints.launchpad.net/nova/+spec/search-api [cid:5C3A53C1-541B-4A0B-9FF1-DCA54F2A4BDA] 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. inline: signature[2].png___ 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 single cross-zone database?
Instead of building data-specific caching (which always worries me), you could simply build the service to return the data directly, then add a Cach-Control: max-age=NNN header to the result. That way, users who wanted to improve their performance could add a squid layer (or other caching HTTP proxy) to their endpoints and ensure consistency within the cache max-age range (for example, max-age=300 would ensure consistency as of 5 minutes ago). If the user prefers consistency over performance, simply bypass the cache. In that manner, the consistency vs. performance decision is left up to the cloud administrator. On 3/16/11 12:58 PM, Paul Voccio paul.voc...@rackspace.com wrote: Ed, I would agree. The caching would go with the design tenet #7: Accept eventual consistency and use it where it is appropriate. If we're ok with accepting that the list may or may not always be up to date and feel its appropriate, we should be good with the caching. pvo On 3/16/11 11:45 AM, Ed Leafe ed.le...@rackspace.com wrote: On Mar 16, 2011, at 12:23 PM, Paul Voccio wrote: Not only is this expensive, but there is no way I can see at the moment to do pagination, which is what makes this really expensive. If someone asked for an entire list of all their instances and it was 10,000 then I would think they're ok with waiting while that response is gathered and returned. However, since the API spec says we should be able to do pagination, this is where asking each zone for all its children every time gets untenable. This gets us into the caching issues that were discussed at the last summit. We could run the query and then cache the results at the endpoint, but this would require accepting some level of staleness of the results. The cache would handle the paging, and some sort of TTL would have to be established as a balance between performance and staleness. -- 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 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] Management API
Thanks, Jay ‹ I'll take your suggestion and break these up; in fact, we were planning on doing that as the next step, and we have a team here at Rackspace that's planning on working on them. We plan on implementing these using the 1.1 extensions mechanism initially, and thus are not planning on synchronizing the delivery with cactus. Once available, they could be rolled into nova-core with little effort. On 3/4/11 8:39 AM, Jay Pipes jaypi...@gmail.com wrote: Hi Glen, I've read through the wiki page and although I think the individual commands are worthy commands to add to the API, I don't see why this is all being bunched into (yet another) API. I think if you broke out these commands into individual blueprints: * Contributors could have already completed work on some of them and others would have already gotten a good head start * We wouldn't be setting up (yet another) giant debate on whether all this functionality should be grouped into a Management API In addition, some of the added commands have dependencies that other commands don't. An example: the /accounts stuff clearly depends on the Authentication stuff currently being prototyped and debated. But the /hosts commands clearly don't. Grouping all this stuff together implies that the commands cannot be logically coded separately and distinctly proposed for inclusion into the singular OpenStack API. While I certainly recognize and respect that you need to provide a gap analysis to management inside Rackspace, doing things this way will actually prolong the coding of at least a good portion of these things IMHO. And, since we're now less than 2 weeks from feature freeze, I can't see how prolonging the coding on these features is going to help. I would propose that blueprints be created and assigned almost immediately to contributors for the commands in the proposed management API that do not have dependencies on things like Authentication. The fact that authentication is happening so late in the release cycle is already going to throw a wrench in many blueprints that are dependent on it... -jay On Wed, Mar 2, 2011 at 3:49 PM, Glen Campbell glen.campb...@rackspace.com wrote: There's been some discussion of an admin/management API and what functions would be provided there. I've been tasked with handling the technical coordination of implementing Nova at Rackspace, and have thus been identifying gaps between functionality that our current system provides and those provided by Nova. I've created a preliminary proposal at http://wiki.openstack.org/NovaAdminAPI this is still somewhat early, but I want to make sure that the OpenStack community has the opportunity to provide feedback. My expectations are that management API features will fall into two categories: (1) those that would be generally useful to anyone who deploys OpenStack Compute, and (2) those that are specific to Rackspace's needs (or perhaps another service provider). One of the goals of this discussion is to identify those different features. While all these features will initially be implemented using the API 1.1 extensions mechanism, those that fall into category (1) may be migrated to Nova-core in the near future, while (2) will remain Rackspace-specific extensions. Glen Campbell 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 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] Management API
I believe they are complementary; Sandy's is an architectural change that lets OpenStack users choose which API functions are restricted to admins only; my proposal is for a set of administrative functions (really just API extensions, since they could be deployed as a public API if the administrator so chooses) that are ancillary to the Nova-core functionality. I.e., Sandy's BP says HOW you deploy an admin API; mine says WHAT is in it. On 3/3/11 1:59 AM, Thierry Carrez thie...@openstack.org wrote: Glen Campbell wrote: There's been some discussion of an admin/management API and what functions would be provided there. I've been tasked with handling the technical coordination of implementing Nova at Rackspace, and have thus been identifying gaps between functionality that our current system provides and those provided by Nova. I've created a preliminary proposal at http://wiki.openstack.org/NovaAdminAPI this is still somewhat early, but I want to make sure that the OpenStack community has the opportunity to provide feedback. Hello Glen, I was wondering how that related to the Admin-only API that Sandy implemented for Bexar: https://blueprints.launchpad.net/nova/+spec/admin-only-api (summary: a allow_admin_api flag adds access to pause/suspend/diagnostics/... through the regular API) Is it a complement, a replacement, something completely different ? From what I can read, it looks like your Admin API would introduce higher-level actions, like suspend all in an account, so it would be complementary ? Cheers, -- 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 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] Entities in OpenStack Auth
According to the proposed API 1.1 spec, it *does* use an extra element in the path to indicate the account; this is (presumably) returned by the auth system: http://servers.api.openstack.org/v1.1/1234/servers/12 Where 1234 is the account ID (actually a token, I believe) and 12 is the server ID. See p. 5 of the latest API 1.1 doc. On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote: For that query you would, but not all. If you want to create a new instance for project1 you would: nova.openstack.org/v1.1/project1/servers Or if you wanted to reboot instance X in project1: nova.openstack.org/v1.1/project1/servers/X Note that the following resource is not the same as the last, since justin wouldn't be the owner for instance X, project1 would be: nova.openstack.org/v1.1/justin/servers/X I think searches will always have special cases with filter options, but for identifying a canonical URL for a resource, having the entity name of the owner in there seems correct. The main thing I'm trying to figure out is whether to use an extra entity in the path for new service URLs. Swift does and Nova does not, and it would be nice to have some consistency. I see the benefits of both, and in Swift's case it needs to for simple public URLs (where there is no user context). -Eric On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote: If we're always going to pass the same user-id token (for a particular user), what's the value in passing it at all? Why not get it from the authentication token? e.g. my X-Auth-Token could look like: justinsb project1,project2,project3 5OPr9UR2xk32K9ArAjO562e (i.e. my username, projects and a crypto signature) Justin On Tue, Mar 1, 2011 at 5:51 PM, Eric Day e...@oddments.org wrote: Hi Justin, On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote: However, what I don't understand is how I can query my servers in project1 and project2 (but not those in project3). *The only way I could see is doing something like this: *nova.openstack.org/v1.1/project1+project2/servers. I agree that REST paths aren't themselves hacky in the single-project case, but I don't yet grok the multi-project query. *Of the 3 options I do grok, I see (c) as the least hacky. I would probably say use nova.openstack.org/v1.1/justin/servers with one or more filter parameters in the URL or body as you mention. This something to consider across all services, not just nova. AFAIK Swift doesn't support queries across multiple accounts right now, so I'd like to hear their thoughts on it as well. -Eric ___ 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
[Openstack] OpenStack Compute API 1.1 ‹ server actions
The proposed compute API 1.1 has a specification for server actions (Sec. 4.4)
with the endpoint:
/servers/{id}/action
The actual action is specified as the body of the POST request, and the
implication is that the action is performed immediately, or as soon as possible.
I'd like us to consider changing this action resource into a calendar or
perhaps schedule resource:
/servers/{id}/schedule{/year{/month{/day{/hour{/minute}
This would provide a generalized way of performing actions on a scheduled basis.
For example, instead of having to wake up at 2AM to reboot a server (for
whatever reason), the administrator could schedule that event:
/servers/{id}/schedule/2011/2/17/02/00
By using the default resource (without the day or time specified), the meaning
would be synonymous with the proposed /action resource; i.e., perform it NOW,
or as soon as possible.
The schedule resource could have additional uses; for example, a GET request
could return the currently-scheduled actions for a particular server.
Glen
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
