Open Stack

I'm for zone-generated ids.  If we take user input it is one more
thing to sanitize and scope accordingly.  As the number is essentially
disposable, I don't know why they would care to provide one anyway, it
just seems like changing who is responsible for making a uuid.

On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh <sandy.walsh at rackspace.com> wrote:
> Actually, I'm cool with it either way.
>
> I'm not really sure of the value in letting users generate their own Reservation ID though. What would the typical motivation be?
>
> That said, anyone else have preferences (PUT + user defined reservation ID's) vs. (POST + zone generated ID's)?
>
> -S
>
> ________________________________________
> From: Brian Lamar [brian.lamar at rackspace.com]
> Sent: Tuesday, May 24, 2011 11:30 AM
> To: Sandy Walsh
> Cc: openstack at lists.launchpad.net
> Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
>
> Only a small scream on PUT /zones/server/
>
> PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server.
>
> -----Original Message-----
> From: "Sandy Walsh" <sandy.walsh at rackspace.com>
> Sent: Monday, May 23, 2011 5:54pm
> To: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
>
> Thanks to all for the input. I don't think we've really come to any conclusions for the near term.
>
> Unless someone screams, we will be proceeding along the following lines:
>
> 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-instances parameter.
> (I'll refactor with the existing code to keep the duplication to a minimum)
>
> 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID
>
> None of this should affect the existing OS API or EC2 API functionality.
>
> We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world.
>
> /me listens for the screams ...
>
> -S
>
>
> 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 abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>