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.wa...@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.la...@rackspace.com] > Sent: Tuesday, May 24, 2011 11:30 AM > To: Sandy Walsh > Cc: openstack@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.wa...@rackspace.com> > Sent: Monday, May 23, 2011 5:54pm > To: "openstack@lists.launchpad.net" <openstack@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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
