Open Stack

There's a button in Gerrit to mark a change Work In Progress once you've 
submitted it.  Sounds like that would be appropriate here.

-Ben

On 2013-06-13 13:59, Pecoraro, Alex wrote:
> I can submit code to gerrit that is not ready to be checked in (hasn't
> been fully tested, unit tests aren't fully written yet, etc)?  Mainly
> I'm just looking for feedback so that I can be sure that I'm headed in
> a direction that will be acceptable when I am done.
> 
> Thanks.
> 
> Alex
> 
> -----Original Message-----
> From: John Dickinson [mailto:me at not.mn]
> Sent: Wednesday, June 12, 2013 5:29 PM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Swift] code changes feedback
> 
> I'm happy to see your interest in contributing. Now that the patch is
> squashed (as gerrit requires), and since you actually already have the
> code, submitting it to gerrit would be the best way to get feedback.
> Gerrit will allow us to comment line-by-line and recommend any
> changes, if needed. I'd suggest adding a second paragraph to your
> commit message with some of the info from your original email about
> the reasons for this and problems it solves for you.
> 
> Looking forward to seeing the patch in gerrit.
> 
> --John
> 
> 
> 
> 
> On Jun 12, 2013, at 1:38 PM, "Pecoraro, Alex" <Alex.Pecoraro at emc.com> 
> wrote:
> 
>> I think I did the patch format correctly this time. So sending again.
>> 
>> Alex
>> 
>> From: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]
>> Sent: Wednesday, June 12, 2013 11:04 AM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [Swift] code changes feedback
>> 
>> Forgot to put the [Swift] on the subject of this email - resubmitting 
>> so it doesn't get missed.
>> 
>> From: Pecoraro, Alex
>> Sent: Wednesday, June 12, 2013 11:02 AM
>> To: OpenStack Development Mailing List
>> Subject: code changes feedback
>> 
>> Hi, I've been working on some changes to Swift that I'm not quite done 
>> with, but I wanted to request some feedback on the path I'm taking to 
>> make sure it is correct/acceptable. My changes don't add any new 
>> features per se, their purpose is to make the code a little more 
>> flexible so that it is easier to add custom behavior by subclassing 
>> base Swift classes and overriding key functions. The reason that I 
>> want to do this is so that I can create extensions to Swift either 
>> through monkey-patching or some other method that make it possible for 
>> Swift to work with Isilon storage devices. The main change that I 
>> needed to make was to how nodes are iterated in the proxy server, 
>> replicators, updaters, and the container synchronizer. So I created a 
>> class called NodeIterator and another class called 
>> NodeIteratorFactory, which are used for iterating the primary and 
>> handoff nodes rather than simply iterating the list of nodes returned 
>> by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the 
>> proxy server the code for iterating through nodes to satisfy a GET 
>> request  changes from this:
>> 
>> def GETorHEAD_base(self, req, server_type, ring, partition, path):
>> ...
>> for node in self.iter_nodes(ring, partition):
>> 
>> to (more or less) this:
>> 
>> def GETorHEAD_base(self, req, server_type, ring, partition, path):
>> ...
>> node_iter = self.node_iterator_factory.create(ring, part) for node in
>> node_iter:
>> 
>> My plan is to create a subclass of NodeIteratorFactory and override 
>> the create function to have it return a subclass of NodeIterator that 
>> iterates the nodes in a way that is compatible with Isilon devices.
>> 
>> I've attached a patch file showing what I've done so far. Please take 
>> a look and let me know what you think.
>> 
>> Also, I'm not sure if I created the patch file correctly, it seems to 
>> show every change that I've committed rather than just my most recent 
>> changes (this is my first time using git). I've been committing 
>> locally and then pulling in changes from the origin/source as I go in 
>> order to lessen the chance of conflicts. Hopefully that's not too 
>> confusing.
>> 
>> Thanks.
>> 
>> Alex
>> <node_iterator_changes.patch>_________________________________________
>> ______
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev