Hi, sorry for the response delay, it's a holiday around here now. On Thu, Jul 4, 2013 at 6:58 AM, christophe courtaut <christophe.courtaut@xxxxxxxxx> wrote: > Hi Yehuda, > > Thanks for pointing out tasks to me. > > I have lately worked on theses tasks. > We are done with #1779, #5228 and #5324. > > #Issue #1779: > > This issue has been marked has resolved, but as Greg pointed out here > http://tracker.ceph.com/issues/1779, > it might be backported. > > Do you agree? If so, where should it be backported? It doesn't look to me like a bug fix that needs backporting. > > Issue #3074: > > I started looking at #3074, which one seems to be trivial, > but as commented on the issue http://tracker.ceph.com/issues/3074, > the options that should be in the help does not only belong to radosgw, > but seems to be a generic option parsed in many binaries. > i would need more info to step forward. > > Do we duplicate the option help in each binaries supporting it? > Do we use generic help? Or something else maybe? There is some generic help system for the common commands. Look at src/common/ceph_argparse.cc:generic_usage() and friends. > > Issue #5416: > > I digged into ceph code to find about the --rgw-zone option, but i had > no chance in finding where this option is parsed, so i'll be able to write help > for it. > As you told me too, i looked into cuttlefish branch, and many others, > but still can't find it. > It would be great if you could point me out where exactly does this > option lives. That's a generic config option, it's defined in src/common/config_opts.h. It's only relevant to the radosgw, and radosgw-admin binaries though. > > Issue #5374: > > A pull request has been made for the #5374, and you commented on it. > Btw i think the #5374 should be sandboxed to this issue and we should open > a new one for the feature you request about S3 keystone. I agree > > S3 Keystone: > > As i am new to keystone and s3, i need more explanation on the work to > be done here. > I'm not familiar with the authentication process in S3, and on how it could rely > on keystone. Do you have any ideas on what should be done? The idea is that there should be an alternative way to authenticate S3 requests. Currently we handle the S3 authentication by verifying signature against the one we calculate by having the user credentials internally. However, certain deployments might just want to have the S3 users controlled by Keystone, and not create their credentials on the rados backend. We do a similar thing with swift, in which we send a request to Keystone to verify the tokens that we get. With S3 it's a bit different, as there's no real way to cache the 'tokens'. But in any case, it'll require sending a request to Keystone to validate the signature. I opened issue #5506 for that. > > temp URLs: > > You mentionned earlier a mecanism of temp URLs, already present in S3. > How does it works? What are there purpose? E.g., when providing a URL that accesses a private data. Unlike regular S3 authenticated requests, all the auth data resides in the request as request params (and not as HTTP fields). The request params have a timestamp that specifies until when this url is valid, and also a signature. > > Issue #4365: > > For the #4365 issue, i think i miss some info about > what to do exactly. Do you have any hints on how wildcard role works? > How does rgw need to integrate this wildcard roles? new Rest API command? Currently we only allow Keystone users that have specific (preconfigured) roles set to access the system. A wildcard role will allow any Keystone users to access the system. > > Vstart documentation: > > I also submitted another pull request on vstart documentation. > As i previously written a manpage a while ago, i have been told > that a manpage is not the good way to document vstart. > I now propose a new documentation page. > > All feedbacks are very welcome. Great. I'll take a look at that, but probably Greg and Sage may want to take a look at it too (CC'ed). Thanks! > Best regards. > > On Mon, Jul 1, 2013 at 10:23 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: >> Hi, >> >> On Mon, Jul 1, 2013 at 12:52 PM, christophe courtaut >> <christophe.courtaut@xxxxxxxxx> wrote: >>> Hi, >>> >>> I updated my pull request and looking forward #5416, and asked for >>> more information on the tracker. >>> >>> Nowadays, i'm iterating on the tracker to find issues i can fix. >>> I currently proposed fixes for #1779, #5228 and #5324. >> >> I pulled your fix for 1779. I commented on 5228 (a similar fix for >> that issue already went in, but your fix does some other things). I >> will pull 5324 (already commented on that at github). >> >>> >>> I'm not very familiar with tests, and it might be a little too big for >>> me to start with. >>> Btw, I was also in contact with Joe Buck to properly setup a fake cluster >>> suitable to make tests, as i was having trouble in doing that. >>> >>> To get started, i'm looking for things a bit smaller, that could fit in a day. >>> >>> I would be glad if you could point me to some specific tasks, >>> even if they are not specially related to the geo-replication blueprint, >>> the best for me remaining rgw related tasks as it's what i am trying to learn. >> >> >> Here are a few (ordered by complexity): >> >> - 3074 (trivial) >> - swift temp URLs (there's already a similar mechanism for S3) >> - 5374 >> - 4365 >> >> Thanks! >> Yehuda >> >>> >>> Best regards. >>> >>> On Thu, Jun 27, 2013 at 5:25 PM, christophe courtaut >>> <christophe.courtaut@xxxxxxxxx> wrote: >>>> ---------- Forwarded message ---------- >>>> From: Yehuda Sadeh <yehuda@xxxxxxxxxxx> >>>> Date: Thu, Jun 27, 2013 at 5:21 PM >>>> Subject: Re: Contribution >>>> To: christophe courtaut <christophe.courtaut@xxxxxxxxx> >>>> >>>> >>>> On Thu, Jun 27, 2013 at 7:30 AM, christophe courtaut >>>> <christophe.courtaut@xxxxxxxxx> wrote: >>>>> Hi Yehuda, >>>>> >>>>> I went thru http://tracker.ceph.com/projects/rgw/issues today ( all 22 >>>>> of them ;-) and contributed a patch to >>>>> http://tracker.ceph.com/issues/5324 ( that was an easy one ). I'd be >>>>> happy to either fix more bugs on the current development branch or >>>>> contribute to the geo-replication >>>>> https://github.com/ceph/ceph/commits/wip-rgw-geo-2 >>>>> >>>>> The amount of work going on with wip-rgw-geo is impressive and I'm not >>>>> sure what I could do to help. It would be most convenient for me to >>>>> pick from a list of self contained tasks in the tracker. I would be >>>>> happy to spend a few days on each of them, one at a time. Since I'm >>>>> still new to the code base, working on a tasks that would require >>>>> weeks of work is probably too ambitious at this point. However, I very >>>>> much understand that the definition of such tasks requires a fair >>>>> amount of work on your part. And if noone works on these tasks, this >>>>> would be a waste of your time. If that helps, I promise to diligently >>>>> work on them, full time :-) >>>>> >>>> >>>> Hi, >>>> >>>> I saw your pull request, and also commented on the commit. There's >>>> a similar easy issue (#5416) that you can take a look at now if you'd >>>> like. >>>> I think that at the moment with regard to the geo-replication, the >>>> most helpful thing would be to test the different APIs, make sure they >>>> work as expected as we're on a tight schedule, and planning a feature >>>> freeze by the end of next week. >>>> The API specifications are in the wiki >>>> (http://wiki.ceph.com/RESTful_API_for_DR_%2F%2F_Geo-Replication). >>>> Specifically I'm interested in data sync, as it's the path less >>>> tested. If you could simulate (even manually) a scenario, where you >>>> put an object in a bucket, check to see whether bucket is listed in >>>> the data log, then go to the bucket index log, see the change entry in >>>> the bucket index log, then generate a copy of that object from the >>>> master zone to the secondary zone. Look at the operation state log to >>>> see whether this operation is marked as completed. >>>> Check to see whether the object appears in the secondary zone, check >>>> its attributes. >>>> That tests a wide range of the new APIs, and it'll be really helpful. >>>> If you could somewhat automate it and create a script that does it, >>>> it'll be extra helpful. >>>> >>>> Most of the other DR/geo-replication tasks are either done (waiting >>>> for review and merge) or being implemented now. There are other >>>> non-geo-replication issues that I can assign to you if you want to get >>>> your feet dipped in the rgw code. Even if these are not a direct >>>> geo-replication issues it may help us getting geo-replication out the >>>> door faster as it'll free me to work on geo-replication. Let me know >>>> if you're interested. >>>> >>>> Thanks! >>>> Yehuda >>>> >>>> >>>> -- >>>> Christophe Courtaut >>> >>> >>> >>> -- >>> Christophe Courtaut > > > > -- > Christophe Courtaut -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
