| *** kei_yama has joined #openstack-swift | 00:04 | |
| kota_ | yup | 00:16 |
|---|---|---|
| kota_ | hello, | 00:16 |
| *** openstackgerrit has quit IRC | 00:21 | |
| *** openstackgerrit has joined #openstack-swift | 00:21 | |
| notmyname | kota_: ok, etags on static manifests.... | 00:26 |
| *** dmorita has joined #openstack-swift | 00:26 | |
| notmyname | dmorita: I'm guessing you are interested in etags too? :-) | 00:26 |
| notmyname | kota_: so, what was it you were saying? | 00:27 |
| kota_ | ya | 00:27 |
| kota_ | When getting slo object, firstly swift reading the manifest and then transfer each segment contaniously. | 00:28 |
| kota_ | right? | 00:28 |
| *** david-lyle is now known as david-lyle_afk | 00:28 | |
| notmyname | right | 00:28 |
| notmyname | sequentially | 00:29 |
| kota_ | Yes | 00:29 |
| *** rmcall has quit IRC | 00:29 | |
| kota_ | And I would like to define etag mean. | 00:29 |
| kota_ | firstly, here. | 00:30 |
| kota_ | The etag on Swift is a md5 disget must be caluclated from object body. | 00:30 |
| notmyname | etags for normal objects is the md5 of the contents of the object. for large objects, it's the md5 of the concatenation of the etags of the segments in the manifest | 00:30 |
| kota_ | Thanks. | 00:31 |
| kota_ | And then, I guess we should make the etag for large objects to be the md5 of the contents of the object. | 00:32 |
| kota_ | Same as normal objects. | 00:32 |
| kota_ | even though doc shows the etag for large objects is the concatenation of the etags, currently. | 00:34 |
| notmyname | well, that would be nice. but it would be an API change that we can't do without versioning the API | 00:34 |
| kota_ | Oh, I didn't notice the effect for versiong API. | 00:35 |
| notmyname | and I think it would be hard to do without having to read in potentially _lots_ of data. I think you'd have to store the state of the md5 hasher so it's resumable. and I'm not sure what you can do with 2 stored states. maybe it's possible. I don't know | 00:35 |
| kota_ | yes, it's hard thing but Kazuhiro knows hash algorithms more deeply than me, and he is trying to be that the imporovement be less performance issue. | 00:36 |
| notmyname | cool | 00:37 |
| kota_ | Currently, that is still under development and making the idea to be better so that I would like to introduce his idea in hackathon | 00:37 |
| kota_ | Is it suitable for you? | 00:37 |
| notmyname | it totally doesn't surprise me that NTT says "oh, we know hashing. we can do that" :-) | 00:37 |
| kota_ | lol | 00:38 |
| kota_ | Though, it's still just a draft and research. | 00:38 |
| notmyname | kota_: I think it's interesting to consider, but I don't think we can change the meaning of the etag withut versioning the api | 00:38 |
| notmyname | ya, I agree that it's interesting research right now | 00:39 |
| kota_ | yes, it's not for users to change the API. | 00:39 |
| notmyname | there's several things that we've considered for new API versions. | 00:39 |
| kota_ | But I guess we can add a header. | 00:39 |
| kota_ | Probably it's related to new API :) | 00:40 |
| kota_ | I don't know the new API in detail... | 00:40 |
| notmyname | there isn't one :-) | 00:41 |
| torgomatic | how would you go about computing the whole-object MD5 without reading the whole object, or at a minimum, all but the first segment? | 00:41 |
| zaitcev | What's the advantage of having a hash that covers the whole body of segmented object? | 00:42 |
| torgomatic | I mean, yes, you can save the MD5 generator state prior to length-padding, but you still have to take the first segment's saved state and update the generator with the bytes from the segments 2..N | 00:42 |
| notmyname | torgomatic: md5 is in the class of hashers that the digest is the serialization of the state of the hasher, right? so maybe there's some way to store the state? I know that's possible to resume it. I don't know if that's posisble to take 2 states and do something meaningful | 00:42 |
| kota_ | Currently, computing on object-server and then share the inter-medeate info among the segment at HEAD segments to check the etag. | 00:43 |
| notmyname | zaitcev: if you download a large object, there's nothing you can do on the client side to validate the contents without doing subsequent HEAD requests to all of the segments | 00:43 |
| torgomatic | kota_: that would only work if the segments were uploaded in sequence, right? if the segments are uploaded in random order, no amount of initial-state setting would help | 00:44 |
| kota_ | no | 00:44 |
| kota_ | calculated when uploading a manifest | 00:44 |
| kota_ | 'PUT manifest for slo' | 00:45 |
| zaitcev | it could be optional... like if you use that middleware thing that unpacks tarballs, then voila you have full etag. otherwise, no change from today. | 00:45 |
| zaitcev | wait, that middleware does different thing | 00:46 |
| kota_ | what? | 00:46 |
| torgomatic | kota_: so, take the unpadded MD5 of segment 1, then make a request to segment 2's object server with that unpadded md5 that spins up a new generator with the unpadded MD5 as initial state, feeds in the bytes, and responds with the new unpadded state? | 00:46 |
| torgomatic | saves the network but not the disk IO, in that case | 00:46 |
| kota_ | tagomatic: yes | 00:46 |
| kota_ | sacrifice the I/O | 00:47 |
| kota_ | but save network. | 00:47 |
| * notmyname wants the magic drives kota_ has | 00:48 | |
| notmyname | ;-) | 00:48 |
| kota_ | s/"the I/O"/"the disk I/O"/ | 00:48 |
| torgomatic | interesting... in my (admittedly limited) experience, disk IO runs out before network does | 00:49 |
| torgomatic | also the latency on such a request would be phenomenal | 00:49 |
| kota_ | torgomatic: yes, curent issue is the latency. | 00:49 |
| kota_ | We have already write the code to make sure the efficiency but our current implementation is too slow | 00:50 |
| kota_ | The consideration for the performance issue is still remaining but he is tryining to make it faster by shaping the code. | 00:52 |
| kota_ | hum... | 00:55 |
| torgomatic | Well, I wish him luck with that. However, unless he can find some way to avoid reading all those bytes off disk, I'm afrait it will not be possible to speed up very much. | 00:55 |
| torgomatic | *afraid | 00:55 |
| zaitcev | maybe some kind of stateful upload | 00:56 |
| zaitcev | in sequence | 00:56 |
| kota_ | torgomatic: Thanks, I will talk with him more for the disk I/O. | 00:57 |
| kota_ | zaitcev: ok | 00:58 |
| kota_ | Anyways, we are going to figure out about this discussion by hackathon and then would like to talk more. | 00:59 |
| *** oomichi has joined #openstack-swift | 01:00 | |
| kota_ | Thanks, notmyname, torgomatic and zaitcev! | 01:00 |
| *** addnull has joined #openstack-swift | 01:03 | |
| *** openstackgerrit has quit IRC | 01:05 | |
| *** openstackgerrit has joined #openstack-swift | 01:05 | |
| *** gyee has quit IRC | 01:12 | |
| *** tellesnobrega_ has quit IRC | 01:15 | |
| *** nexusz99 has joined #openstack-swift | 01:18 | |
| *** nexusz99 has quit IRC | 01:37 | |
| *** nexusz99 has joined #openstack-swift | 01:55 | |
| *** nexusz99 has quit IRC | 02:04 | |
| *** tsg has quit IRC | 02:04 | |
| *** IRTermite has quit IRC | 02:07 | |
| notmyname | blog post on tempurls almost done... | 02:09 |
| mattoliverau | notmyname: nice, once 2.2.2 is realeased a blog post on overload would be nice, feel free to delagate that to torgomatic or clayg tho ;) | 02:12 |
| notmyname | oh, yeah. definitely going to happen | 02:12 |
| mattoliverau | Swfitstack blog is an awesome ressource to point at even for those of us who don't work there ;) | 02:13 |
| notmyname | :-) | 02:13 |
| notmyname | that's the idea | 02:13 |
| notmyname | you've discovered our business strategy. | 02:13 |
| notmyname | shhhh. don't tell anyone | 02:13 |
| *** haomaiwang has joined #openstack-swift | 02:14 | |
| mattoliverau | notmyname: oh crap, you mean this isn't a private chat.... sorry :P | 02:16 |
| *** openstackgerrit has quit IRC | 02:20 | |
| *** openstackgerrit has joined #openstack-swift | 02:21 | |
| *** IRTermite has joined #openstack-swift | 02:25 | |
| *** jkugel has joined #openstack-swift | 02:32 | |
| *** addnull has quit IRC | 02:38 | |
| *** tellesnobrega_ has joined #openstack-swift | 02:43 | |
| *** occupant has quit IRC | 02:46 | |
| *** ahonda has quit IRC | 02:49 | |
| *** NM has joined #openstack-swift | 02:50 | |
| *** bkopilov has quit IRC | 03:05 | |
| *** NM has quit IRC | 03:06 | |
| *** jkugel has quit IRC | 03:07 | |
| *** jkugel has joined #openstack-swift | 03:09 | |
| *** jkugel has quit IRC | 03:09 | |
| *** jkugel has joined #openstack-swift | 03:10 | |
| *** openstackgerrit has quit IRC | 03:20 | |
| *** openstackgerrit has joined #openstack-swift | 03:20 | |
| *** jkugel has quit IRC | 03:33 | |
| *** oomichi has quit IRC | 04:01 | |
| *** kota_ has quit IRC | 04:03 | |
| *** Dieterbe has joined #openstack-swift | 04:14 | |
| *** silor has joined #openstack-swift | 04:15 | |
| *** bkopilov has joined #openstack-swift | 04:19 | |
| *** jrichli has joined #openstack-swift | 04:21 | |
| *** kei_yama has quit IRC | 04:28 | |
| *** addnull has joined #openstack-swift | 04:29 | |
| *** jrichli has quit IRC | 04:39 | |
| *** sileht has quit IRC | 04:40 | |
| *** tellesnobrega_ has quit IRC | 04:46 | |
| *** gvernik has joined #openstack-swift | 04:47 | |
| openstackgerrit | Daisuke Morita proposed openstack/swift: Output account-reaper's logs for PolicyError https://review.openstack.org/141241 | 04:47 |
| *** ahonda has joined #openstack-swift | 04:57 | |
| *** gvernik has quit IRC | 04:58 | |
| *** jrichli has joined #openstack-swift | 05:01 | |
| *** SkyRocknRoll has joined #openstack-swift | 05:02 | |
| *** jrichli has quit IRC | 05:11 | |
| *** jrichli has joined #openstack-swift | 05:12 | |
| *** jrichli has quit IRC | 05:18 | |
| *** echevemaster has quit IRC | 05:31 | |
| *** addnull has quit IRC | 05:33 | |
| *** ppai has joined #openstack-swift | 05:48 | |
| *** oomichi_ has joined #openstack-swift | 05:57 | |
| *** oomichi_ has quit IRC | 05:57 | |
| *** gvernik has joined #openstack-swift | 06:01 | |
| *** zaitcev has quit IRC | 06:18 | |
| openstackgerrit | Merged openstack/swift: don't print cached dispersion if it's a lie https://review.openstack.org/150531 | 06:18 |
| openstackgerrit | Merged openstack/swift: 2.2.2 changelog and authors update https://review.openstack.org/150909 | 06:19 |
| *** gvernik has quit IRC | 06:19 | |
| openstackgerrit | Merged openstack/swift: Allow set_overload to take value as percent https://review.openstack.org/145970 | 06:19 |
| mattoliverau | notmyname: ^^ they finally made it through zuul :) | 06:24 |
| mattoliverau | on that note, I'm calling it a day. night all. | 06:24 |
| *** reed has quit IRC | 06:26 | |
| *** SkyRocknRoll has quit IRC | 06:27 | |
| *** mahatic has joined #openstack-swift | 06:28 | |
| *** sileht has joined #openstack-swift | 06:29 | |
| *** SkyRocknRoll has joined #openstack-swift | 06:39 | |
| *** JoshNang has quit IRC | 06:52 | |
| *** mahatic has quit IRC | 07:00 | |
| *** JoshNang has joined #openstack-swift | 07:01 | |
| openstackgerrit | Daisuke Morita proposed openstack/swift: Output account-reaper's logs for PolicyError https://review.openstack.org/141241 | 07:07 |
| *** mahatic has joined #openstack-swift | 07:13 | |
| openstackgerrit | Hisashi Osanai proposed openstack/swift: Allow hostnames for nodes in Rings https://review.openstack.org/133155 | 07:20 |
| *** oomichi has joined #openstack-swift | 07:33 | |
| *** addnull has joined #openstack-swift | 08:06 | |
| *** geaaru has joined #openstack-swift | 08:16 | |
| *** geaaru_ has joined #openstack-swift | 08:26 | |
| *** geaaru has quit IRC | 08:27 | |
| *** nellysmitt has joined #openstack-swift | 08:35 | |
| *** chlong has quit IRC | 08:36 | |
| *** rledisez has joined #openstack-swift | 08:37 | |
| *** BobBall_AWOL is now known as BobBall | 09:09 | |
| *** addnull has quit IRC | 09:10 | |
| *** jordanP has joined #openstack-swift | 09:10 | |
| openstackgerrit | Bob Ball proposed openstack/swift: Remove deprecated config variables https://review.openstack.org/150832 | 09:11 |
| openstackgerrit | Bob Ball proposed openstack/swift: Remove deprecated config variables https://review.openstack.org/150832 | 09:11 |
| *** jistr has joined #openstack-swift | 09:16 | |
| *** acoles_away is now known as acoles | 09:21 | |
| *** addnull has joined #openstack-swift | 09:23 | |
| acoles | torgomatic: thanks for the rechecks! | 10:05 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 10:06 |
| *** chlong has joined #openstack-swift | 10:13 | |
| *** nshaikh has joined #openstack-swift | 10:14 | |
| *** tellesnobrega_ has joined #openstack-swift | 10:17 | |
| *** addnull has quit IRC | 10:24 | |
| *** chlong has quit IRC | 10:27 | |
| ho | ping Donagh McCabe | 10:31 |
| *** haomaiwang has quit IRC | 10:34 | |
| *** silor has quit IRC | 10:40 | |
| *** jordanP has quit IRC | 10:41 | |
| *** tellesnobrega_ has quit IRC | 10:43 | |
| *** chlong has joined #openstack-swift | 10:44 | |
| *** tellesnobrega_ has joined #openstack-swift | 11:00 | |
| *** nshaikh has left #openstack-swift | 11:01 | |
| *** tellesnobrega_ has quit IRC | 11:06 | |
| *** donagh has joined #openstack-swift | 11:07 | |
| *** tellesnobrega_ has joined #openstack-swift | 11:07 | |
| *** oomichi has quit IRC | 11:08 | |
| *** tellesnobrega_ has quit IRC | 11:11 | |
| *** NM has joined #openstack-swift | 11:20 | |
| donagh | ho: you wanted to talk? | 11:23 |
| ho | donagh: yes! | 11:24 |
| ho | donagh: I just wrote a response for your comment. | 11:25 |
| ho | donagh: I understand your specification is already approved so I should remove -1 with the comment. | 11:25 |
| ho | donagh: I want to talk (tell you) about my concern | 11:26 |
| donagh | ho: I'm not sure "approved" is the right word... | 11:26 |
| donagh | It's in the "in-progress" section | 11:26 |
| ho | donagh: i see. | 11:26 |
| ho | donagh: My concerns to implement this without policy-based RBAC are following: | 11:26 |
| donagh | which means that a number of cores believe the code work should go ahead and that it will be reviewed | 11:26 |
| *** oomichi_ has joined #openstack-swift | 11:27 | |
| ho | donagh: i believe your spec is right direction what we go :) | 11:27 |
| ho | donagh: From end users point of view, end users need to know both usages, one is OpenStack standard and another is Swift only. Swift's implementation will be unique even if the OSLO incubator policy engine will be graduated in Kilo. | 11:28 |
| donagh | ho: I think it's a matter of timing. Adding composite tokens and multiple prefixes is an agreed plan. | 11:28 |
| ho | donagh: From Swift's community point of view, we need to maitain both if they will be landed. | 11:29 |
| ho | donagh: but i don't know my understanding is corrent or not... | 11:29 |
| donagh | I think they are ortogonal issues/features | 11:30 |
| donagh | The composite token/milti-resellers is a feature designed to support Glance/Cinder use-case | 11:30 |
| donagh | It's implemented on the current keystoneauth design because that's what's there now | 11:30 |
| donagh | Converting keystoneauth to using policy files is a future feature | 11:31 |
| donagh | I'm not arguing that policy should not be done....but we should not delay composite tokens/multipe-resellers to also incorporate poliy | 11:32 |
| donagh | Doing so would complicate acceptance | 11:32 |
| ho | donagh: i summarize my understanding and thought http://paste.openstack.org/show/163626/ | 11:32 |
| donagh | Ok...let me read that | 11:32 |
| ho | donagh: then my concerns above come to me. | 11:33 |
| *** NM1 has joined #openstack-swift | 11:35 | |
| donagh | ho: let me take those items one by one | 11:35 |
| ho | donagh: sorry... | 11:35 |
| *** NM has quit IRC | 11:37 | |
| donagh | Item 1: I read lines 77-79 as a more general description. Specifically, "policy engine" just means "however the service handles roles, projects and resources"! | 11:37 |
| donagh | The overall direction of the service token spec was to agree how the protocol (HTTP_X_SERVICE_ROLES, etc.) was done. | 11:38 |
| donagh | Swift *has* a policy engine...it uses options called operator_roles and an ACL syntax | 11:39 |
| *** chlong has quit IRC | 11:39 | |
| *** aix has joined #openstack-swift | 11:40 | |
| donagh | Re item 2, what are you asking to correct? Is that use of the word "incubation" | 11:42 |
| ho | donagh: i mean oslo incubator module does not need to support X-service-token | 11:43 |
| ho | donagh: it's just a library it depends on how to use it from openstack compo. | 11:44 |
| donagh | Ok, I don't know enough about the library to know how to use it. | 11:45 |
| donagh | I was thinking of something such as "role: swiftoperator" | 11:45 |
| donagh | ...I had assumed this intercepted the HTTP_X_ROLES environment variable? | 11:46 |
| donagh | Is that how it works, or doe sit work in another way? | 11:46 |
| ho | donagh: for example, just a moments. | 11:48 |
| ho | donagh: first, swift prepares policy file. in this file we describe the rule like "role: swiftoperator and role: reselleradmin" | 11:49 |
| donagh | ok.. I understand that part | 11:50 |
| ho | donagh: second: keystoneauth gets a request from a users, he passes an identity (from envrion, HTTP_X_XXX) to policy engine. | 11:51 |
| donagh | I see a call such as: enforcer.enforce(action, target, creds) | 11:51 |
| ho | donagh: then policy engine compares identity and policy file, this request can be authorized or not. | 11:51 |
| *** dmorita has quit IRC | 11:51 | |
| ho | donagh: yes that right! | 11:52 |
| donagh | So environment is not passed in -- however, "creds" is passed in | 11:52 |
| ho | donagh: yes. | 11:53 |
| donagh | I see creds is a dictionary, with items such as "roles" | 11:53 |
| donagh | So I assume enforcer, when it parses something such as "role:swiftoperator" knows to look at the "roles" item in the creds argument. Correct | 11:54 |
| donagh | ? | 11:54 |
| ho | donagh: info from identity see _get_creds in https://review.openstack.org/#/c/149930/4/swift/common/middleware/keystoneauth.py | 11:54 |
| donagh | I saw that...my question is how enforcer works | 11:55 |
| ho | donagh: i will write a case with this conf https://review.openstack.org/#/c/149930/4/etc/default_policy.json-sample | 11:56 |
| ho | donagh: in this file. rules are described. | 11:57 |
| *** tdasilva has quit IRC | 11:57 | |
| donagh | I understand that part (I think). | 11:58 |
| donagh | However, lets examine just one line | 11:58 |
| ho | donagh: when enforcer.enforce(action, target, creds) is called, | 11:58 |
| ho | donagh: ok | 11:58 |
| donagh | 'reseller_admin_roles': 'role:ResellerAdmin' | 11:59 |
| donagh | That says the condition reseller_admin_roles is met if the role ResellerAdmin is present in creds.roles | 11:59 |
| donagh | Correct? | 11:59 |
| *** oomichi_ has quit IRC | 11:59 | |
| ho | donagh: yes | 12:00 |
| ho | correct | 12:00 |
| donagh | Ok, so enforcer has code to parse the word "role:", pick up he next item, "ResellerAdmin" and then look at the "role" item in the creds argument | 12:01 |
| donagh | ? | 12:01 |
| ho | donagh: enforcer checks action first. | 12:01 |
| ho | donagh: like get_account in 'post_account': 'rule:allowed_user' | 12:02 |
| donagh | However, you agree there is code looking for the string "role:" ?? | 12:03 |
| ho | donagh: he meets allowed_user then parses 'allowed_user': ('(rule:authenticated and ' ... | 12:03 |
| donagh | ho: you still there? | 12:05 |
| ho | donagh: sorry for multi lines. he continusly parses til (usually) meet role like 'operator_roles': 'role:admin or role:swiftoperator', | 12:05 |
| *** chlong has joined #openstack-swift | 12:05 | |
| ho | donagh: sorry for late response. just need time to write it in english. | 12:06 |
| donagh | My point is that "role:" has a specific meaning. For service tokens, we need something such as "service_role: blah" | 12:06 |
| donagh | Because oslo.policy does not currently support "service_role:" or does it? | 12:07 |
| ho | donagh: oslo.policy is a just library. therefore they don't have "service_role" but can support it. | 12:08 |
| ho | donagh: s/can support it/can work with it/ | 12:08 |
| donagh | Sorry for beign so detailed, but that was the point of the paragraph you mention in your point 2 | 12:08 |
| ho | donagh: no my explantion is wrong. let me explain: it's just one correction which i think you have a mis-understanding about oslo incubator policy check. | 12:10 |
| donagh | Ok -- since I'm still doing updates for the spec, I'll say something such as: | 12:12 |
| donagh | ..hhhm. actually, now that I think about it...I will simply delete the paragraph since I'm *not* using oslo.policy in the solution | 12:13 |
| donagh | Anyway, that's just detail. Were there other points you wanted to make? | 12:14 |
| *** oomichi_ has joined #openstack-swift | 12:16 | |
| ho | donagh: i wrote above. My concerns to implement this without policy-based RBAC are following: From end users point of view, end users need to know both usages, one is OpenStack standard and another is Swift only. Swift's implementation will be unique even if the OSLO incubator policy engine will be graduated in Kilo. From Swift's community point of view, we need to maitain both if they will be landed. | 12:16 |
| ho | donagh: so I would like to contribute for Swift better so I would appricate if you could think for co-work to realize this functionality before landed. | 12:17 |
| donagh | I think we are talking at cross purposes | 12:17 |
| ho | donagh: ? | 12:17 |
| *** Guest52 has joined #openstack-swift | 12:18 | |
| donagh | I agree, and support, adding policy to keystoneauth | 12:18 |
| donagh | I dissagree that the work I'm doing must be based on policy | 12:18 |
| donagh | The reason is that to do so makes two changes at one thime: add policy and add service token | 12:19 |
| donagh | Generally, we like to make incremental changes | 12:19 |
| donagh | Not combine changes together | 12:19 |
| *** Guest52 has quit IRC | 12:19 | |
| *** silor has joined #openstack-swift | 12:20 | |
| ho | donagh: i think so too. so my proposal is we finish policy based patch first. | 12:20 |
| donagh | In my estimation you won't land the policy patch for some time. | 12:20 |
| *** Novtopro_ has joined #openstack-swift | 12:20 | |
| ho | donagh: s/my proposal is/my proposal was/ | 12:20 |
| donagh | Firstly, you don't have a a spec in swift-specs ... so Swift core's don't know this is coming and have not discussed | 12:21 |
| acoles | ho: sorry to barge in, but can i ask - is oslo.policy still in incubation ? | 12:21 |
| donagh | Second, there are more interactions with your proposal | 12:21 |
| donagh | First you would need to land policy that matches exactly the current situation | 12:22 |
| ho | acoles: https://github.com/openstack/oslo-specs/blob/master/specs/kilo/graduate-policy.rst | 12:22 |
| donagh | Then oslo.policy needs to be updated to support service_roles | 12:23 |
| ho | acoles: kilo-2 (feb 5) | 12:23 |
| donagh | Only then, would we be able to add composite tokens/resellers to keystoneauth | 12:23 |
| donagh | The effect is to delay a feature (composite token/resellers) that's ready to go...and needed by other projects | 12:24 |
| ho | donagh: no oslo,policy doesn't need to care it. | 12:24 |
| *** Novtopro_ has quit IRC | 12:25 | |
| acoles | ho: thanks | 12:25 |
| donagh | If I'm wrong about whether or not oslo.policy needs a change, my general point still stands | 12:25 |
| *** Novtopro_ has joined #openstack-swift | 12:25 | |
| donagh | As mentioned earlier, I think your first step is to put a proposal into swift-specs | 12:26 |
| ho | donagh: sorry. my proposal is too late for you | 12:26 |
| donagh | By all means, you can propose in that that document that my work should wait. | 12:27 |
| donagh | That allows the core reviewers to comment on that point | 12:27 |
| donagh | The swift-specs process is supposed to allow reviewers to comment on all aspects of a proposal. | 12:28 |
| acoles | ho: if oslo.policy can support service tokens then why not include it in your patch? i.e. base your patch on https://review.openstack.org/#/c/137086/ - the changes in 139086 to keystoneauth are not *huge*, most of the lines of change are tests and docs | 12:30 |
| acoles | s/139086/137086 | 12:30 |
| ho | acoles: i didn't recognize donagh's patch at that time. | 12:31 |
| ho | acoles: not https://review.openstack.org/#/c/149930/4? | 12:32 |
| acoles | ho: i mean, rebase 149930 on 137086 so 149930 will depend on the test donagh has for service tokens, then add to 149930 whatever is needed for service token in policy.json | 12:34 |
| ho | acoles: it possible but my idea is no. (5) in http://paste.openstack.org/show/163626/ | 12:36 |
| acoles | ho: point (5) refers to this https://review.openstack.org/#/c/133155/ ??? | 12:37 |
| donagh | ho: that's the hostname support in ring files...wrong URL? | 12:38 |
| ho | acoles: and I need to ask the spec. regarding single-project and multi-project | 12:39 |
| ho | donagh: https://review.openstack.org/#/c/149930/4 "Enable Role-based access control using oslo.policy in Swift" | 12:40 |
| *** Novtopro_ has quit IRC | 12:40 | |
| *** Novtopro_ has joined #openstack-swift | 12:41 | |
| ho | donagh: acoles: sorry. i need to fix the url. | 12:41 |
| *** Novtopro_ has quit IRC | 12:42 | |
| acoles | ho: with 149930 are you allowing a choice of (a) continue to use role options in proxy-server.conf or (b) use policy file? | 12:42 |
| donagh | acoles: 149930 works with old operator_roles option in [keystoneauth] | 12:43 |
| donagh | or uses a new polciy_file option if present | 12:43 |
| ho | acoles: it can work both(proxy-server.conf or policy-file) | 12:43 |
| acoles | ho: ok, and are you suggesting that the service token would *only* be supported if the policy-file is used? | 12:44 |
| ho | acoles: yes. | 12:44 |
| acoles | ho: ok. so i am suggesting that since donagh has already done the work to support service token using proxy-server.conf then we should keep that and in a follow-on patch add support for policy-file | 12:46 |
| ho | donagh: acoles: http://paste.openstack.org/show/163636/ . ok i understand. i just worried about impact for uses. sorry for this. | 12:47 |
| acoles | ho: its better for users, they get service token support with either .conf file or policy-file. | 12:48 |
| acoles | ho: also, if you can rebase 149930 on 137086 then it will demonstrate how policy-file will support service tokens, which will help us understand | 12:51 |
| acoles | ho: btw, it must be late for you? | 12:52 |
| rledisez | ho: sorry to step in in the middle of the discussion, but i'm very interrested in having a policy file that would allow to describe very precisely some actions | 12:53 |
| rledisez | ho: today it's almost all or nothing (reseller or standard user) | 12:53 |
| rledisez | ho: but it would be nice to be able to have role that can for example, only set quota | 12:54 |
| rledisez | ho: = POST with some specific headers | 12:54 |
| rledisez | do you think your proposal will allow that (not right now, but in a futur patch) ? | 12:54 |
| ho | donagh: acoles: thaks for your time! | 12:54 |
| acoles | ho: you're welcome, thanks for the explanations. i have to go now for a while. | 12:55 |
| donagh | ho: no problem. In the meantime, I may post some other comments on 149930 | 12:56 |
| donagh | ho: I need to leave now (lunch) | 12:58 |
| ho | rledisez: quota is in HTTP HEADER. if it correct, it is possible to realize it with my patch but needs some coding. | 13:02 |
| ho | acoles: donagh: thanks! | 13:03 |
| ho | rledisez: action, key for policy, is consists of http-method and target like post_account so it can work but to compare quota i need to put quta info in headers to credential or target. | 13:07 |
| ho | rledisez: i have to leave. good night! | 13:08 |
| *** ho has quit IRC | 13:09 | |
| *** oomichi_ has quit IRC | 13:14 | |
| *** bkopilov has quit IRC | 13:14 | |
| *** EmilienM|afk is now known as EmilienM | 13:14 | |
| *** dmsimard_away is now known as dmsimard | 13:40 | |
| *** jordanP has joined #openstack-swift | 13:41 | |
| *** dmsimard is now known as dmsimard_away | 13:49 | |
| *** dmsimard_away is now known as dmsimard | 13:49 | |
| openstackgerrit | Donagh McCabe proposed openstack/swift: Add multiple reseller prefixes and composite tokens https://review.openstack.org/137086 | 13:49 |
| *** dmsimard is now known as dmsimard_away | 13:49 | |
| *** tdasilva has joined #openstack-swift | 13:52 | |
| *** jistr has quit IRC | 13:58 | |
| *** jistr has joined #openstack-swift | 14:00 | |
| *** jkugel has joined #openstack-swift | 14:05 | |
| *** ppai has quit IRC | 14:16 | |
| *** rdaly2 has joined #openstack-swift | 14:27 | |
| *** jasondot_ has joined #openstack-swift | 14:34 | |
| *** jasondot_ has quit IRC | 14:45 | |
| *** mahatic has quit IRC | 15:00 | |
| *** omame has quit IRC | 15:02 | |
| *** omame has joined #openstack-swift | 15:03 | |
| *** jistr has quit IRC | 15:10 | |
| *** jistr has joined #openstack-swift | 15:12 | |
| *** dmsimard_away is now known as dmsimard | 15:21 | |
| *** mahatic has joined #openstack-swift | 15:21 | |
| *** NM1 has quit IRC | 15:29 | |
| *** NM has joined #openstack-swift | 15:29 | |
| *** bkopilov has joined #openstack-swift | 16:02 | |
| *** rdaly2 has quit IRC | 16:22 | |
| *** abhirc has quit IRC | 16:24 | |
| *** silor has quit IRC | 16:38 | |
| *** IRTermite1 has joined #openstack-swift | 16:48 | |
| *** IRTermite1 has quit IRC | 16:48 | |
| *** IRTermite has quit IRC | 16:48 | |
| *** IRTermite has joined #openstack-swift | 16:49 | |
| *** david-lyle_afk is now known as david-lyle | 16:49 | |
| notmyname | good morning | 16:53 |
| *** jkremer has joined #openstack-swift | 16:59 | |
| mahatic | notmyname, good morning | 17:05 |
| notmyname | hello | 17:05 |
| mahatic | I saw the comments on the server type patch. I would like it torgomatic's way of having separate headers. But the rfc you pointed differs from that. So i'm kind of split on it. | 17:06 |
| notmyname | ttx is tagging the 2.2.2 rc right now | 17:07 |
| notmyname | mahatic: ya, I haven't been able to convince torgomatic that he's wrong yet ;-) | 17:07 |
| mahatic | notmyname, :D will wait on that then. I made that NotImplementedError change though. Will push it when we decide on the headers | 17:09 |
| notmyname | cool | 17:09 |
| *** nellysmitt has quit IRC | 17:11 | |
| *** SkyRocknRoll has quit IRC | 17:13 | |
| *** rledisez has quit IRC | 17:13 | |
| notmyname | 2.2.2rc has just been tagged | 17:15 |
| notmyname | mattoliverau: tempurl feature highlight blog post https://swiftstack.com/blog/2015/01/29/swift-feature-highlight-tempurls/ | 17:16 |
| torgomatic | notmyname: mahatic: if you use a header other than "Server", you get to make up your own semantics :) | 17:19 |
| notmyname | torgomatic: X-Recon-Binary-Data-Payload ;-) | 17:20 |
| torgomatic | 👍 | 17:20 |
| notmyname | so in this case we're specifically trying to send info about what kind of server it is back to the client. http has a server header already for that exact purpose | 17:21 |
| notmyname | I'm more ok with dropping the version (although I'd prefer it to be there now) than just making up another header for this | 17:22 |
| notmyname | rephrase: currently, I'd prefer for the version to be there. ie I haven't yet been convinced otherwise | 17:22 |
| torgomatic | well, the driver for all this is to have swift-recon be able to ask "what are you?" to a Swift backend server, and we've chosen OPTIONS requests as the mechanism for the question and answer | 17:24 |
| torgomatic | so at some point, there will be code with an OPTIONS response in hand that has to figure out what kind of backend made the response | 17:24 |
| torgomatic | and, while it's not terribly difficult to do some string splitting and whatnot, it's even easier to type ".headers.get("X-Server-Type") == 'swift-account-server'" | 17:25 |
| torgomatic | but if you have a strong preference for the Server header, then that's probably fine too, just more code to write | 17:26 |
| *** NM has quit IRC | 17:27 | |
| notmyname | more or different? | 17:27 |
| *** EmilienM is now known as EmilienM|afk | 17:27 | |
| notmyname | heh, well the fun part is that we're discussing code that we aren't going to write but mahatic is :-) | 17:28 |
| torgomatic | the Server header is a whitespace-separated string of component/version pairs, so it'll need a little parsing help, and probably some tests | 17:29 |
| torgomatic | I could see the Server header sprouting more information in the future (library versions, for example), while the hypothetical X-Swift-Server-Type wouldn't. | 17:30 |
| mahatic | notmyname, I guess it's more than different | 17:30 |
| notmyname | recon (currently) won't need to handle a server header with more than one component/version pair | 17:30 |
| torgomatic | old recon + new swift, when the our-future recon becomes old | 17:30 |
| notmyname | torgomatic: do you think a server header with the version would help various management systems (*wink*) with determining what should be upgraded or otherwise handled? | 17:30 |
| *** jistr has quit IRC | 17:31 | |
| torgomatic | notmyname: just saying that a list of thingies with one thingy in it tends to evolve towards having more thingies over time :) | 17:31 |
| *** NM has joined #openstack-swift | 17:31 | |
| notmyname | sure. eventually "Server: object-server/4.28.92 recon-middeware/0.6.28 foobar-middleware/9.2 acme-proprietary/0.42" | 17:33 |
| mahatic | torgomatic, if I understand correctly, Server header could be used in future for other purposes and hence now go with a X-Server-Type etc? | 17:33 |
| torgomatic | mahatic: I have a slight preference for X-Server-Type, but notmyname has a preference for the Server header | 17:33 |
| torgomatic | my preference is weak enough that you probably shouldn't pay much attention to it | 17:34 |
| notmyname | torgomatic: to paraphrase you, "there's an http thing that is for what we are trying to communicate, but it can be overused in the future so we shouldn't use it and instead make up a new header" | 17:34 |
| notmyname | (admittedly, a biased paraphrase) | 17:34 |
| notmyname | ;-) | 17:34 |
| torgomatic | notmyname: just saying that it takes more code to parse a string than to do a straight comparison is all | 17:34 |
| mahatic | torgomatic, notmyname hmm, my preference is whatever makes the code easier to write ;) | 17:34 |
| notmyname | we should get acoles clayg peluse cschwede to weigh in :-) | 17:35 |
| torgomatic | notmyname: really, it's a weak preference, so if you have a good reason for the Server header (and it sounds like you do, because library versions are good to know), then go with thtat | 17:35 |
| torgomatic | *that | 17:35 |
| torgomatic | alright they | 17:35 |
| torgomatic | *then | 17:35 |
| torgomatic | I retract my preference for X-Server-Type; knowing eventlet version (someday in the future) is a good enough reason to use the Server header | 17:36 |
| notmyname | ah, that's an interesting idea | 17:36 |
| *** jodah has left #openstack-swift | 17:37 | |
| *** jordanP has quit IRC | 17:37 | |
| notmyname | mahatic: ok. "Server" it is. | 17:37 |
| notmyname | torgomatic: with or without the version? | 17:37 |
| torgomatic | notmyname: with; that's what the spec wants, no? | 17:37 |
| mahatic | notmyname, torgomatic "Server: object-server/4.28.92 recon-middeware/0.6.28 foobar-middleware/9.2 acme-proprietary/0.42", will we get to use that info? I mean I'm sure there is a scenario, can you point me to it? | 17:37 |
| notmyname | mahatic: nah, that's just some made up future worst case | 17:38 |
| notmyname | mahatic: for now, it would be "Server: %s/%s" % (server_type, version) | 17:38 |
| mahatic | notmyname, yeah | 17:38 |
| notmyname | and recon would look at server_header_value.split(' ', 1)[0].split('/'). and if that has an error, then it's unexpected anyway | 17:39 |
| *** nellysmitt has joined #openstack-swift | 17:40 | |
| mahatic | notmyname, yeah. also where would the version be used? | 17:41 |
| mahatic | notmyname, for future use? | 17:42 |
| notmyname | mahatic: for now, I'm not sure that it would be. or it wouldn't be required in the current feature | 17:42 |
| notmyname | ya, for future use | 17:42 |
| mahatic | alright | 17:42 |
| notmyname | torgomatic: you ok with that? | 17:42 |
| torgomatic | sure | 17:42 |
| *** torgomatic has quit IRC | 17:59 | |
| *** reed has joined #openstack-swift | 18:00 | |
| *** torgomatic has joined #openstack-swift | 18:13 | |
| *** ChanServ sets mode: +v torgomatic | 18:13 | |
| *** Trixboxer has joined #openstack-swift | 18:14 | |
| openstackgerrit | Shiva Chaitanya proposed openstack/swift-specs: Swift tiering specification https://review.openstack.org/151335 | 18:14 |
| *** abhirc has joined #openstack-swift | 18:19 | |
| *** EmilienM|afk is now known as EmilienM | 18:36 | |
| *** jrichli has joined #openstack-swift | 18:47 | |
| *** erlon has quit IRC | 18:48 | |
| *** fandi has joined #openstack-swift | 18:48 | |
| *** openstackgerrit has quit IRC | 18:50 | |
| *** openstackgerrit has joined #openstack-swift | 18:51 | |
| tdasilva | notmyname: good job on the tempurl lightning talk..pretty funny :-) | 18:51 |
| openstackgerrit | Merged openstack/swift: Don't set the already set Connection: close https://review.openstack.org/150575 | 18:52 |
| openstackgerrit | Mahati proposed openstack/swift: Add server type in OPTIONS response https://review.openstack.org/150847 | 18:56 |
| *** lpabon has joined #openstack-swift | 19:25 | |
| *** reed has quit IRC | 19:27 | |
| *** bill_az_ has joined #openstack-swift | 19:29 | |
| *** tdasilva has quit IRC | 19:33 | |
| *** rdaly2 has joined #openstack-swift | 19:34 | |
| *** aix has quit IRC | 19:35 | |
| *** rdaly2_ has joined #openstack-swift | 19:47 | |
| *** tdasilva has joined #openstack-swift | 19:48 | |
| *** torgomatic_ has joined #openstack-swift | 19:50 | |
| *** rdaly2 has quit IRC | 19:51 | |
| *** torgomatic has quit IRC | 19:56 | |
| *** torgomatic_ is now known as torgomatic | 19:56 | |
| *** ChanServ sets mode: +v torgomatic | 19:56 | |
| *** jkremer has quit IRC | 20:01 | |
| *** openstackgerrit has quit IRC | 20:04 | |
| *** openstackgerrit has joined #openstack-swift | 20:04 | |
| *** nellysmitt has quit IRC | 20:07 | |
| *** nellysmitt has joined #openstack-swift | 20:07 | |
| *** nellysmitt has quit IRC | 20:12 | |
| *** bkopilov has quit IRC | 20:13 | |
| *** fifieldt has quit IRC | 20:24 | |
| *** fifieldt has joined #openstack-swift | 20:25 | |
| *** annegent_ has joined #openstack-swift | 20:29 | |
| *** os1 has joined #openstack-swift | 20:44 | |
| os1 | Hi | 20:44 |
| os1 | Does swift-recon yield cluster-wide data for memory usage, and/or network statistics? | 20:44 |
| os1 | For instance, in the case of disk-usage, it seems to be able to yield a combined disk usage and combined capacity statistic when run. | 20:45 |
| os1 | combined, as in, the total disk usage of the cluster, and the total capacity of the cluster. | 20:46 |
| os1 | without having to manually add up the values that are returned. | 20:46 |
| os1 | I'm wondering if memory-related information, and/or network-related information, can be printed this way, too? | 20:47 |
| os1 | (for the cluster) | 20:48 |
| ctennis | I don't believe swift-recon gathers that info | 20:48 |
| *** rdaly2 has joined #openstack-swift | 20:52 | |
| *** rdaly2 has quit IRC | 20:54 | |
| *** rdaly2_ has quit IRC | 20:55 | |
| notmyname | some of it is in swift-recon | 20:56 |
| notmyname | load average and socket usage | 20:57 |
| os1 | Okay. When I'm querying it through curl, on the other hand, | 20:58 |
| *** annegent_ has quit IRC | 20:58 | |
| os1 | curl -i http://<bind-ip>:6000/recon/mem and curl -i http://<bind-ip>:6000/recon/sockstat | 20:59 |
| os1 | notmyname : Does that give combined (or averaged) data across the nodes in the cluster? | 21:00 |
| *** tdasilva has quit IRC | 21:01 | |
| os1 | If not, then is there a way to do so? | 21:01 |
| *** tdasilva has joined #openstack-swift | 21:02 | |
| notmyname | os1: no, that would be for one server. the swift-recon CLI will aggregate across many servers (you can specify the whole cluster or a zone or a server or etc) | 21:05 |
| os1 | notmyname : Okay, that's what it seemed like. However, what if you were to send the curl request to your HAProxy server? | 21:06 |
| *** annegent_ has joined #openstack-swift | 21:08 | |
| notmyname | you'd get the results from whatever backend the LB chooses right? | 21:09 |
| mattoliverau | Morning all | 21:09 |
| *** acoles is now known as acoles_away | 21:10 | |
| notmyname | mattoliverau: hi | 21:10 |
| mattoliverau | acoles_away: becomes away when I come online :( one day we'll overlap a little better again! P.S Been reviewing your fast post, I like the way you encoded the timestamps, nice thinking! | 21:12 |
| *** zaitcev has joined #openstack-swift | 21:13 | |
| *** ChanServ sets mode: +v zaitcev | 21:13 | |
| os1 | notmyname : That's what I assumed, as well. | 21:21 |
| os1 | notmyname : Lastly, then, do you know whether the swift-recon CLI can print out aggregate data for memory usage? | 21:22 |
| *** NM has quit IRC | 21:23 | |
| os1 | notmyname : I can't seem to find it in the list returned by "swift-recon -h", but it's interesting that you can retrieve /recon/mem via curl. | 21:23 |
| notmyname | os1: interesting. that doesn't seemed plumbed through the CLI. should be relatively easy to do so. would you be interested in working on a patch? | 21:26 |
| os1 | notmyname : Possibly. It sounds like it would be fun to do, and I may have time to look into it. | 21:32 |
| notmyname | great! | 21:32 |
| notmyname | os1: let me know if you need any help getting started | 21:32 |
| os1 | notmyname : Ok. | 21:32 |
| *** geaaru_ has quit IRC | 21:52 | |
| *** tdasilva has quit IRC | 21:59 | |
| *** Nadeem has joined #openstack-swift | 22:04 | |
| *** chlong has quit IRC | 22:08 | |
| *** nellysmitt has joined #openstack-swift | 22:08 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 22:09 |
| *** dmsimard is now known as dmsimard_away | 22:11 | |
| *** nellysmitt has quit IRC | 22:13 | |
| os1 | Hi. Do the proxy servers ever need to use rsync ? | 22:13 |
| *** dmsimard_away is now known as dmsimard | 22:13 | |
| *** tdasilva has joined #openstack-swift | 22:19 | |
| *** dmsimard is now known as dmsimard_away | 22:24 | |
| *** donagh has quit IRC | 22:32 | |
| notmyname | os1: no | 22:35 |
| notmyname | os1: that's only needed on storage nodes | 22:35 |
| openstackgerrit | Merged openstack/swift: Add server type in OPTIONS response https://review.openstack.org/150847 | 22:37 |
| *** abhirc has quit IRC | 22:40 | |
| *** annegent_ has quit IRC | 22:42 | |
| *** lpabon has quit IRC | 22:51 | |
| *** openstackgerrit has quit IRC | 22:51 | |
| *** openstackgerrit has joined #openstack-swift | 22:51 | |
| *** tellesnobrega_ has joined #openstack-swift | 22:51 | |
| *** occupant has joined #openstack-swift | 22:54 | |
| *** jrichli has quit IRC | 22:57 | |
| *** mahatic has quit IRC | 23:04 | |
| *** panbalag has quit IRC | 23:06 | |
| *** jkugel has quit IRC | 23:21 | |
| *** jkugel has joined #openstack-swift | 23:21 | |
| *** jkugel has quit IRC | 23:26 | |
| *** echevemaster has joined #openstack-swift | 23:30 | |
| *** tdasilva has quit IRC | 23:33 | |
| *** chlong has joined #openstack-swift | 23:53 | |
| *** abhirc has joined #openstack-swift | 23:56 | |
| *** rdaly2_ has joined #openstack-swift | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!