Thursday, 2016-03-24

*** haomaiwa_ has quit IRC00:01
*** haomaiwang has joined #openstack-swift00:01
*** chlong has quit IRC00:11
*** garthb has quit IRC00:18
*** gyee has quit IRC00:20
*** rickyrem has joined #openstack-swift00:29
*** briancline has quit IRC00:38
*** briancline has joined #openstack-swift00:45
*** StraubTW has quit IRC00:47
*** sheel has quit IRC00:47
*** klamath has quit IRC00:52
*** haomaiwang has quit IRC01:01
*** haomaiwang has joined #openstack-swift01:01
*** lyrrad has quit IRC01:10
*** sgundur has joined #openstack-swift01:11
*** sgundur has left #openstack-swift01:11
*** Jeffrey4l has joined #openstack-swift01:15
*** klrmn1 has quit IRC01:15
*** dmorita has quit IRC01:21
*** rickyrem has quit IRC01:33
*** rickyrem has joined #openstack-swift01:34
*** chlong has joined #openstack-swift01:36
*** dmorita has joined #openstack-swift01:37
*** dmorita has quit IRC01:41
*** haomaiwang has quit IRC01:44
*** baojg has joined #openstack-swift01:46
*** Jeffrey4l has quit IRC01:58
*** mtreinish has quit IRC01:59
*** mtreinish has joined #openstack-swift02:01
*** panda has quit IRC02:05
*** panda has joined #openstack-swift02:06
*** dmorita has joined #openstack-swift02:23
*** klrmn has joined #openstack-swift02:27
*** dmorita has quit IRC02:28
*** mingdang1 has joined #openstack-swift02:37
*** StraubTW has joined #openstack-swift02:48
mahaticgood morning02:52
*** StraubTW has quit IRC02:52
notmynamegood evening02:53
*** dmorita has joined #openstack-swift03:10
tdasilvagood night03:13
notmynameI'm reminded of the truman show. http://alexpeak.com/art/films/tts/excerpts/greetings.jpg03:14
*** dmorita has quit IRC03:14
*** links has joined #openstack-swift03:27
*** haomaiwang has joined #openstack-swift03:29
*** haomaiwang has quit IRC04:01
*** haomaiwang has joined #openstack-swift04:01
*** klrmn has quit IRC04:05
*** Zyric has quit IRC04:08
*** dmorita has joined #openstack-swift04:11
*** dmorita has quit IRC04:16
*** sheel has joined #openstack-swift04:18
*** Zyric has joined #openstack-swift04:22
*** treaki__ has joined #openstack-swift04:23
*** treaki_ has quit IRC04:25
*** takashi has joined #openstack-swift04:26
*** chlong has quit IRC04:56
*** rickyrem has quit IRC04:57
*** tanee has quit IRC04:58
*** haomaiwang has quit IRC05:01
*** haomaiwang has joined #openstack-swift05:01
*** tanee has joined #openstack-swift05:03
*** dmorita has joined #openstack-swift05:08
*** chlong has joined #openstack-swift05:12
*** dmorita has quit IRC05:12
*** hosanai has joined #openstack-swift05:15
*** ChanServ sets mode: +v hosanai05:15
*** baojg has quit IRC05:19
*** hosanai has quit IRC05:33
*** trifon has joined #openstack-swift05:42
*** asettle has quit IRC05:44
*** asettle has joined #openstack-swift05:44
*** asettle has quit IRC05:45
*** pcaruana has quit IRC05:48
*** takashi has quit IRC05:51
*** haomaiwang has quit IRC06:01
*** haomaiwang has joined #openstack-swift06:01
*** panda has quit IRC06:05
*** panda has joined #openstack-swift06:06
*** chlong has quit IRC06:08
*** chlong has joined #openstack-swift06:22
*** trifon has quit IRC06:22
*** rcernin has joined #openstack-swift06:23
*** sheel has quit IRC06:27
*** baojg has joined #openstack-swift06:27
*** StraubTW has joined #openstack-swift06:27
*** sheel has joined #openstack-swift06:29
*** StraubTW has quit IRC06:32
*** trifon has joined #openstack-swift06:35
openstackgerritKazuhiro MIYAHARA proposed openstack/swift: WIP: Swift Automated Tiering  https://review.openstack.org/28705706:36
*** ChubYann has quit IRC06:39
*** baojg has quit IRC06:42
*** esker has quit IRC06:46
*** baojg has joined #openstack-swift06:47
*** haomaiwang has quit IRC07:01
*** haomaiwa_ has joined #openstack-swift07:01
*** silor has joined #openstack-swift07:02
*** lifeless has quit IRC07:06
*** baojg has quit IRC07:06
*** baojg has joined #openstack-swift07:08
*** silor1 has joined #openstack-swift07:08
*** silor has quit IRC07:11
*** silor1 is now known as silor07:11
*** pcaruana has joined #openstack-swift07:32
*** daemontool has joined #openstack-swift07:33
*** wanghua has joined #openstack-swift07:38
*** tesseract has joined #openstack-swift07:41
*** tesseract is now known as Guest2798207:42
*** geaaru has joined #openstack-swift07:52
*** Trixboxer has quit IRC07:54
*** Trixboxer has joined #openstack-swift07:55
*** haomaiwa_ has quit IRC08:01
*** haomaiwang has joined #openstack-swift08:01
openstackgerritMerged openstack/swift: 2.7.0 authors and changelog updates  https://review.openstack.org/29617508:01
*** Zyric has quit IRC08:08
*** rledisez has joined #openstack-swift08:09
*** mmcardle has joined #openstack-swift08:09
*** dmorita has joined #openstack-swift08:10
*** mmcardle1 has joined #openstack-swift08:11
*** mmcardle has quit IRC08:11
*** Zyric has joined #openstack-swift08:12
*** dmorita has quit IRC08:14
openstackgerritDavid Liu proposed openstack/swift: Handle tempurl Content-Disposition header missing from HEAD  https://review.openstack.org/29693608:17
openstackgerritMarek Kaleta proposed openstack/python-swiftclient: Add copy object method  https://review.openstack.org/28020008:31
*** jmccarthy has quit IRC08:32
*** cbartz has joined #openstack-swift08:33
*** jmccarthy has joined #openstack-swift08:35
cschwedeacoles: Good Morning! so, i’m looking into this rolling upgrade thing08:36
cschwedeand i’m wondering about https://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html#tag-assert-supports-rolling-upgrade08:36
*** acoles_ is now known as acoles08:37
*** sheel has quit IRC08:37
cschwededoes that mean a rolling upgrade within a cloud, ie for example upgrade nova at time t0, but no other service, then at t1 keystone, and so on?08:37
cschwedeor upgrade within a service, ie swift-proxy, then swift-object server, and so on08:38
acolescschwede: good morning, i just got here08:38
*** chlong has quit IRC08:38
acolescschwede: tbh, i am not sure, but what i took away from last night's discussion was at least a proxy server running version x and a/c/o servers running version y08:38
cschwedeacoles: yes, so that would match with patch 64074, that added rolling upgrade tests for nova a while ago08:40
patchbotcschwede: https://review.openstack.org/#/c/64074/ - openstack-dev/grenade - Add rolling upgrade test for nova-compute (MERGED)08:40
cschwedeso only the api is updated, but not nova-compute then08:41
cschwedeand i think that’s how to do this in swift as well08:42
acolescschwede: what i was planning to try, as an experiment, was running swift services inside virtual envs, and then rolling back the version in one venv08:43
cschwedeso the two code env are setup by devstack (old branch and new branch), so we don’t need to take care of that (using a virtualenv or similar) - iiuc08:43
*** Trixboxer has quit IRC08:43
*** Trixboxer has joined #openstack-swift08:44
acolescschwede: so you think grenade already has some infrastructure to manage multiple versions? how is it deploying the services, in separate vms?08:48
cschwedeacoles: yes, it has this; and it’s using virtualenvs. see patch 15837608:49
patchbotcschwede: https://review.openstack.org/#/c/158376/ - openstack-dev/grenade - Prepare for Services in virtual env (MERGED)08:49
cschwedeespecially https://review.openstack.org/#/c/158376/5/upgrade-swift08:50
patchbotcschwede: patch 158376 - openstack-dev/grenade - Prepare for Services in virtual env (MERGED)08:50
*** Jeffrey4l has joined #openstack-swift08:50
*** early has quit IRC08:50
cschwedeso i’m wondering, with this already in place, it shouldn’t be too hard to only update the proxy for example08:50
*** jordanP has joined #openstack-swift08:52
*** zaitcev has quit IRC08:54
*** joeljwright has joined #openstack-swift08:56
*** ChanServ sets mode: +v joeljwright08:56
*** zaitcev has joined #openstack-swift08:57
*** ChanServ sets mode: +v zaitcev08:57
acolescschwede: OIC. so the sequence of events is install and start all services at version x, then upgrade to version y, then re-start only a subset of services. i can see how that can work in a single venv.09:00
cschwedeacoles: yes, i think that’s the plan09:00
*** haomaiwang has quit IRC09:01
*** haomaiwang has joined #openstack-swift09:01
acolescschwede: i was trying to figure out how to simultaneously start different services on different versions, which is why i was thinking multiple venvs.09:01
*** stantonnet has quit IRC09:02
acolescschwede: have you setup a grenade test environment locally?09:03
cschwedeso, instead of stopping all swift services in https://github.com/openstack-dev/grenade/blob/master/projects/30_swift/shutdown.sh, we could only stop the proxy maybe? and that get’s restarted after the upgrade09:03
cschwedeacoles: no, at least not yet...09:03
acoleshehe. i gave up on devstack a while ago :/09:03
*** stantonnet has joined #openstack-swift09:04
acolescschwede: yes, i think you have a good idea there. looks like we'd need to break out, or parameterise, stop_swift to stop only specific services09:05
cschwedeok, i’ll try to setup a local grenade vm to test this - i’ll get back to you later09:06
cschwedeacoles: ^^09:06
acolescschwede: thanks for doing the research! i am about to commute to office, and may try the same i.e. setup grenade, in case i can be of nay help later09:07
acoless/nay/any/09:07
*** acoles is now known as acoles_09:15
*** kei_yama has quit IRC09:38
*** joeljwright1 has joined #openstack-swift09:48
*** cbartz has left #openstack-swift09:51
*** joeljwright has quit IRC09:52
*** early has joined #openstack-swift09:53
*** baojg has quit IRC09:55
*** _JZ_ has quit IRC09:56
*** haomaiwang has quit IRC10:01
*** haomaiwang has joined #openstack-swift10:01
*** Jeffrey4l has quit IRC10:06
cschwedeso, i think we need three patches to test rolling upgrades:10:08
cschwede1. devstack: a method to stop only the swift proxy server10:08
cschwede2. grenade: adding a flag, that will only stop the proxy using the method from devstack10:09
cschwede3. project-config: adding another job(?) to run grenade with a flag for the rolling upgrade10:10
cschwedei’m not sure if this is the right way to do this, but it somehow makes sense to me10:10
cschwedei will upload patch 1+2 later, currently running grenade on my vm to test this10:10
patchbotcschwede: https://review.openstack.org/#/c/1/ - openstack-infra/system-config - Add puppet module for ssh that installs an sshd_co... (MERGED)10:10
cschwede?10:11
cschwedeacoles_: notmyname: ^^10:11
cschwedeat least that’s something we can discuss with TC, and iterate from that10:11
cschwedefirst patch: 29699110:15
cschwedepatch 29699110:15
patchbotcschwede: https://review.openstack.org/#/c/296991/ - openstack-dev/devstack - WIP: Add stop_swift_proxy method10:15
*** asettle has joined #openstack-swift10:16
*** Jeffrey4l has joined #openstack-swift10:18
*** acoles_ is now known as acoles10:18
acolescschwede: ack, sounds good10:19
*** early has quit IRC10:21
*** asettle has quit IRC10:24
cschwedenext patch 29699710:24
patchbotcschwede: https://review.openstack.org/#/c/296997/ - openstack-dev/grenade - WIP: Add option to test Swift rolling upgrade test10:24
*** joeljwright has joined #openstack-swift10:28
*** ChanServ sets mode: +v joeljwright10:28
*** StraubTW has joined #openstack-swift10:29
*** early has joined #openstack-swift10:30
*** joeljwright1 has quit IRC10:31
*** StraubTW has quit IRC10:34
*** Jeffrey4l has quit IRC10:35
cschwedeand, finally patch 29700510:38
patchbotcschwede: https://review.openstack.org/#/c/297005/ - openstack-infra/project-config - WIP: Add grenade job for Swift rolling upgrade tests10:38
cschwede^^ these patches are all WIP, and open for discussion. as i said, not sure it’s the current right way to do it, so let’s discuss this with infra & TC10:39
*** daemontool has quit IRC10:46
*** km has quit IRC10:52
*** eranrom has joined #openstack-swift10:54
eranromacoles,: Hi, A question on container sync with fast post: To my surprise the following seems to work:10:57
eranrom1. put object in source and have it synced to dest.10:57
eranrom2. update the data on source at t110:57
eranrom3. update metadata and content type on dest at t2>t110:58
eranrom4. sync.10:58
eranromApparently the data got replicated to the other side.10:58
eranromwhich IMO is the right behavior, although, I did not think it would work given the data ts1 being smaller then ts2....10:59
eranromIf this is in fact the case, and considering the other probe tests in place, we can say container sync works with fast-post. yay!11:00
*** haomaiwang has quit IRC11:00
*** haomaiwang has joined #openstack-swift11:04
*** lifeless has joined #openstack-swift11:07
acoleseranrom: actually i would not have expected that outcome. unfortunately my dev environment has broken this morning so i cannot reproduce right now. but at step3 the dest becomes newer than the source, so I would not expect a sync at step 4.11:17
acoleseranrom: are you up to date with master, i.e. do you have https://review.openstack.org/#/c/270961/11:18
patchbotacoles: patch 270961 - swift - Container-Sync to perform HEAD before PUT object o... (MERGED)11:18
acoleseranrom: i can see how your scenario worked *prior* to that patch^^ because then the PUT would be accepted11:19
openstackgerritEran Rom proposed openstack/swift: Add process level concurrency to container sync  https://review.openstack.org/21009911:19
acoleseranrom: but the behavior on master now should be the same as with post-as-copy11:19
eranromacoles,: right. False alarm :-( indeed with patch 270961) the scenarion fails.11:23
patchboteranrom: https://review.openstack.org/#/c/270961/ - swift - Container-Sync to perform HEAD before PUT object o... (MERGED)11:23
acoleseranrom: phew, you made me sweat there for a moment ;)11:24
acoleseranrom: however, your scenario is one that imho it would be good to have work i.e. when source has data at t1 and dest has data at t0 and metadata at t2, we'd like to end up with dest having data at t1 and metadata at t211:25
acoleseranrom: that is 'further work' that i am aware needs doing, but i do think that at this point the behavior is equitable with post-as-copy11:25
acoleseranrom: "equitable" is wrong word, i mean equivalent11:26
eranromacole: I was just looking up "equitable" :)11:26
acoleseranrom: sorry! we need to improve container sync further to achieve what ssync does which is to treat sync of data and metadata separately w.r.t. their timestamps11:27
*** mvk_ has quit IRC11:28
eranromacoles: two points that comes into mind:11:28
acolesthat way we can also save sending content bytes to dest when only metadata has changed on source11:28
eranrom1. I am not positive that we really want to end up with data at t1 and metadata at t2 - the way I see it in object stores data and metadata should be viewed as a whole, and if the data got updated in one cluster it is does not necessarily make sense to retain the 'new' metadata11:30
eranromclearly the content type might not make sense anymore....11:31
eranrom2. Personally, I think that the current behavior is an acceptable limitation for working with fast-post with container sync.11:31
eranromThat is to say: stating the limitation we may want to encourage working with fast-post together with container sync11:32
acoleseranrom: that's an interesting point. within a cluster the goal is always to make all replicas of an object have consistent state. you are arguing that the semantic of container sync might be different, that we sync newest "composite" state.11:38
acoleseranrom: it depends on use case for sync i think, and whether it is a bi-directional sync of two active clusters or one-directional backup-type use case11:40
eranromacoles,: I think that I am arguing that the data ts, ct ts and md ts are not symmetric. That is: a newer data timestamp should cause older ct,md to 'vanish'.11:41
*** jmb__ has joined #openstack-swift11:42
eranromacoles: well, not sure that it has to do with symmetry... Its just that new data implies also new ct and metadata11:42
acolesyes, that should always be true11:43
eranromacoles: ok, so is this is the way that a consistent state is achieved in a single cluster - right?11:44
acoleseranrom: within a cluster your statement is true: i.e. " a newer data timestamp should cause older ct,md to 'vanish'"11:45
acolesand its also true for sync11:45
eranromacoles,: ok, so I probably missed something along the way.11:45
eranromacoles: The scenario I tried above, was trying to test that this is also the case for container sync:11:46
eranromsource has newer data, target has newer metadata but older data11:46
acolesthe case i was considering was, for sync, source has t1.data, dest has t0.data and t2.meta - what would you like the outcome of a sync to be?11:46
acoles:) right, that^^11:47
acolesat the moment the outcome is no change, which is the same outcome as if the same events had occurred with post-as-copy11:48
eranromacoles,: dest shoudl be, IMO, t1.data along with source metadata - as t2.meta refers to an 'obsolete' data11:48
acoleseranrom: ok, so that ^^ is what i think you observed before updating to have patch 270961, but I don't think you'd observe that with HEAD of master11:50
patchbotacoles: https://review.openstack.org/#/c/270961/ - swift - Container-Sync to perform HEAD before PUT object o... (MERGED)11:50
eranromacoles: Let me test this again.11:50
acoleseranrom: let me try to fix my system.. :/11:51
*** sheel has joined #openstack-swift11:58
*** haomaiwang has quit IRC12:01
*** haomaiwang has joined #openstack-swift12:01
eranromacoles: Alright, tested again with  270961 and the behavior is what I (we? - not sure anymore:-) thought - the new data is not propegated.12:05
eranromacoles,: or in other words: the metadata timestamp 'wins'12:05
*** daemontool has joined #openstack-swift12:07
eranromacoles: back to the discussion: I guess you were right with the 'depends on use case' remark. If one is doing a unidirectional sync then a metadata update to the destination is most likely a metadata update that reflects the local data, and hence it needs to 'vanish' as noew data comes in from the source12:07
eranromthe local data == the local data at the destination12:08
eranromacoles,: I am not sure I have an opinion on what is the right behavior for bi-directional sync though :-)12:09
acoleseranrom: ok, so I am satisfied that what you now see is what I would expect, and that it is the same behavior as if you were using post-as-copy12:10
acoleswith post-as-copy, when you make a post to the destination object at time t2, it's data timestamp is effectively advance to t2. then source data at t1 would never be sync'd to the dest.12:11
acoleseranrom: and i also understand the alternative behaviour you are describing, and I am not sure what I think of that proposal. Need time to consider it some more.12:12
*** kairat has joined #openstack-swift12:13
kairatHi guys12:13
kairatWhen i got 499 error when creating object on object server12:13
kairatwhat does it mean12:13
kairatwho break the connection12:13
acoleseranrom: away for a while12:14
kairatclient who requested object create (me)12:14
kairator swift proxy server12:14
kairatCould you please help me with some info, I am trying to debug a bug between glance and swift12:15
*** daemontool has quit IRC12:15
*** mvk_ has joined #openstack-swift12:35
*** StraubTW has joined #openstack-swift12:46
eranromacoles,: Sure, Agree this requires more thought. Thanks12:48
*** haomaiwang has quit IRC13:01
*** haomaiwang has joined #openstack-swift13:01
*** haomaiwang has quit IRC13:07
*** NM has joined #openstack-swift13:08
*** NM has quit IRC13:09
*** mingdang1 has quit IRC13:23
*** jmb__ has quit IRC13:27
*** links has quit IRC13:28
jrichlikairat: this means the client disconnected before the server expected it to.  there are a few reasons for that.  one thing to look at is the request content length to be sure its correct.13:36
openstackgerritoshritf proposed openstack/swift: Per container stat. report  https://review.openstack.org/28181413:38
kairatjrichli, who can be the client13:42
kairatproxy-server?13:42
kairator glance itself13:43
jrichliwhatever sent the http request that is getting the 49913:43
jrichliwe you able to get some swift logs?13:43
kairatyep13:44
kairatjust a sec13:44
jrichlithe 499 should be logged - and then you can see which request generated that response13:44
cschwedeacoles: notmyname: ok, so i think the proposed patches for the rolling upgrade tests should work fine, at least they are for me. i added an process list output as a comment on patch 29699713:45
patchbotcschwede: https://review.openstack.org/#/c/296997/ - openstack-dev/grenade - WIP: Add option to test Swift rolling upgrade test13:45
kairatjrichli, http://paste.openstack.org/show/491711/13:45
kairatthat's object-server.log13:46
acolescschwede: ack, thanks.13:46
tdasilvaacoles, cschwede: not trying to make too much fuss about it, but wouldn't you typically do the oposite of first upgrading storage services and then proxy?13:47
tdasilvajust wondering if it should be the other way around13:48
acolescschwede: i haven't got far setting up grenade ...vm problems13:48
cschwedetdasilva: well, we could change that, but before i spent even more time on this i want to get some feedback from infra and the TC if this is the way to go. we can still improve this13:49
jrichlikairat: is the content-length being specified on the put?  does it match the length of the data being sent?13:51
*** daemontool has joined #openstack-swift13:52
*** sgundur has joined #openstack-swift13:58
*** panda has quit IRC14:05
*** panda has joined #openstack-swift14:05
kairatit is hard to check14:06
kairatah14:06
kairatwe are using chunked requests14:07
kairatso content-length is absent at all14:07
kairatjrichli, ^14:07
*** asettle has joined #openstack-swift14:12
*** jmb__ has joined #openstack-swift14:13
*** asettle has quit IRC14:16
jrichlikairat: ok.  the server was expecting more data for some reason, and it either detected a disconnect or may have timed out waiting for more data.  to find out why, i'd have to debug to see where the problem is happening.14:16
jrichlimaybe there is somebody else here who has some suggestions14:17
kairatjrichli, thanks a lot14:17
kairatI also asked to enable debug on CI env where we got this failure14:17
kairat*debug on object-server and container-server14:18
jrichlikairat: there are some places in the proxy/controller/obj that swift will raise that error, so you may as well request debug there too.  although, i dont really see debug logging that would help in that file.14:21
jrichli(debugging on proxy, that is)14:21
jrichlioh, nm.  we saw that it was in the obj srv14:22
kairatyeah14:23
*** vint_bra has joined #openstack-swift14:24
*** ametts has joined #openstack-swift14:33
*** esker has joined #openstack-swift14:36
*** esker has quit IRC14:36
*** esker has joined #openstack-swift14:37
*** haomaiwang has joined #openstack-swift14:56
hurricanerixjrichli: is there a blueprint/spec/overview of all the encryption stuff?14:57
*** kairat has left #openstack-swift14:58
jrichlihurricanerix: spec: http://specs.openstack.org/openstack/swift-specs/specs/in_progress/at_rest_encryption.html15:00
jrichlihurricanerix: status: https://etherpad.openstack.org/p/swift-hackathon-feb-2016-encryption15:00
*** haomaiwang has quit IRC15:01
*** haomaiwang has joined #openstack-swift15:01
jrichlihurricanerix: I have been wanting to start the docs - just have a lot to do right now.  i think that might be more of what you are looking for.  if you have questions, let me know.15:01
*** links has joined #openstack-swift15:02
*** trifon has quit IRC15:03
hurricanerixjrichli: Thanks!15:03
*** eranrom has quit IRC15:05
*** StraubTW_ has joined #openstack-swift15:08
*** StraubTW has quit IRC15:10
*** acorwin_ has joined #openstack-swift15:12
*** lifeless has quit IRC15:13
*** david-lyle has quit IRC15:13
*** fbo has quit IRC15:13
*** acorwin has quit IRC15:13
*** dmsimard has quit IRC15:13
*** kota_ has quit IRC15:13
notmynamegood morning15:14
notmynamecschwede: great work on those patches. I just read over the scrollback, and I've got them open15:14
notmynamecschwede: have you raised anything with -infra yet?15:16
*** Guest27982 has quit IRC15:17
*** rcernin has quit IRC15:17
*** david-lyle has joined #openstack-swift15:17
*** links has quit IRC15:18
cschwedenotmyname: thx! not yet, i first wanted to ensure we’re on the same line with this. if you agree with the overall approach, we should get in touch with -infra (and probably leave a comment on the TC patch, that there is something in progress)15:23
notmynamecschwede: I think I am, but TBH I'm still fuzzy on how those yaml files set it up. eg I don't actually see/know when swift is actually started. or when the upgrade happens and what versions are used15:25
*** dmsimard has joined #openstack-swift15:25
*** wasmum has quit IRC15:29
*** lifeless has joined #openstack-swift15:29
*** fbo has joined #openstack-swift15:29
*** kota_ has joined #openstack-swift15:29
*** wolfe.freenode.net sets mode: +v kota_15:29
*** Guest27982 has joined #openstack-swift15:29
*** rcernin has joined #openstack-swift15:29
*** lifeless has quit IRC15:30
*** lifeless has joined #openstack-swift15:30
notmynamecschwede: I can start coordinating with -infra and the TC today to get these looked at (and maybe landed)15:33
cschwedenotmyname: that would be very welcome, i’m currently in a meeting15:33
*** asettle has joined #openstack-swift15:34
cschwedenotmyname: i can get back to you later if you like to discuss this approach15:34
notmynamecschwede: sure15:34
*** asettle has quit IRC15:38
*** garthb has joined #openstack-swift15:44
*** wasmum has joined #openstack-swift15:48
*** clarkb has joined #openstack-swift15:49
clarkbnotmyname: o/15:49
notmynameclarkb: thanks :-)15:49
notmynameclarkb: background is that we're setting up a rolling upgrade test15:49
notmynamecschwede (in germany) worked on it today. he's in a meeting now, but I'm taking the handoff this morning15:50
notmynamewe've got patch 296991 patch 296997 and patch 29700515:50
patchbotnotmyname: https://review.openstack.org/#/c/296991/ - openstack-dev/devstack - WIP: Add stop_swift_proxy method15:50
patchbotnotmyname: https://review.openstack.org/#/c/296997/ - openstack-dev/grenade - WIP: Add option to test Swift rolling upgrade test15:50
patchbotnotmyname: https://review.openstack.org/#/c/297005/ - openstack-infra/project-config - WIP: Add grenade job for Swift rolling upgrade tests15:50
notmynamecschwede has tested these locally (see the comments), but we'd like an -infra eye on the setup/etc to see if this actually is the right way to do stuff15:51
notmynameand, ideally, if things look good, to land them ASAP15:51
clarkblet me see15:51
claygare grenade tests always "rolling"15:54
claygdo the storage servers eventually get upgraded in the test?15:55
notmynameclayg: no, I'm told that it's more of a cold upgrade currently. ie stop everything, upgrade everything, start it, run tests15:55
clarkbclayg: no grenades default behavior is bring up services, run some basic functionality testing, stop all services, upgrade everything, start services and run more tests15:55
claygk, yeah that's how i understood it - so i was questioning the naming here -> https://review.openstack.org/#/c/297005/2/jenkins/jobs/devstack-gate.yaml15:56
patchbotclayg: patch 297005 - openstack-infra/project-config - WIP: Add grenade job for Swift rolling upgrade tests15:56
clarkbthe way these rolling tests are set up for swift appears to be only upgrade the proxy server15:56
notmynameclarkb: right. that's the point. to test a scenario where only some of the services are upgraded15:56
notmynameie what would be partway through a rolling upgrade15:56
notmynameclayg: if we have this test + the tests we already have that test everything upgraded, then we cover the bases15:57
clarkbclayg: I think the terminology used elsewhere for this type of upgrade is 'partial'15:57
clarkbn-cpu-partial but I would have to double check15:57
notmynamewell, specifically the reason for working on this (and rushing on it) is because the TC is wanting to strip swift of it's "supports rolling upgrades" tag15:58
notmynameand the requirement listed there is to test a partially upgraded cluster15:58
clarkbthe devstack and grenade things look fine to me but I am not core there so you'll probably want someone else to actually confirm that. There is one small issue with the job config I will comment in a few once I figure out how the other grenade jobs handle it15:59
notmynameclarkb: thanks for looking. who's core on devstack and grenade that I can ping about it?16:00
clarkbsdague, mtreinish, dtroyer off hte top of my head16:00
*** haomaiwang has quit IRC16:01
notmynamethanks16:01
*** haomaiwang has joined #openstack-swift16:01
clarkbexport DO_NOT_UPGRADE_SERVICES=[n-cpu] is apparently how the nova cpu tests work16:01
clarkbthey may ask that you use that in the grenade change16:02
notmynameclarkb: FWIW, ideally, I'd like to have this all squared away by next tuesday. that's the timeframe I'm working under16:06
notmynameclarkb: meaning, landed and running on patches in the gate16:06
acolescschwede: i am getting closer to having a grenade vm setup. once i have, is it straightforward to point the grenade script at your patches rather than it pulling master branches of devstack?16:07
clarkbya I think its a fairly simple set of updates because this is a mostly solved problem16:07
clarkbits just slapping this into that framework and gerrit just dumped my comments because I need to log in again aparenlty16:07
notmynameclayg: on patch 257502, you had reviewed but not approved, waiting on follow-up stuff. acoles pushed another patch set and added +2. if you're good with the current one and it gets in the gate this morning, it can be in the mitaka release16:08
patchbotnotmyname: https://review.openstack.org/#/c/257502/ - swift - Fix full_listing in internal_client16:08
clarkbnotmyname: ok commented on https://review.openstack.org/#/c/297005/ hopefully that is enough detail?16:09
patchbotclarkb: patch 297005 - openstack-infra/project-config - WIP: Add grenade job for Swift rolling upgrade tests16:09
notmynameclarkb: yeah, gerrit does that a lot :-)16:09
clarkbapparenlty if you go anonymous your comment isn't deleted, you can copy it, then login, and paste it back16:10
clarkbwoo gerrit16:10
notmynameclarkb: thanks. I'm still trying to understand how it actually is working. where is it actually upgrading code and running the tests? how is it picking the versions of code to run (yes, new code will be HEAD of the branch, but what's the starting point?)16:11
*** gyee has joined #openstack-swift16:12
clarkbnotmyname: devstack-gate picks the versions of code to test just below where I linked in my comment https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n287 which is why that case statement falls through16:12
clarkbnotmyname: as for what is actually upgrading code and running the tests that is all in grenade16:12
clarkbbasicall it is a list of if I am testing a change for $branch then the old branch is foo16:13
notmynameah ok16:13
clarkbwe just aproved the change for liberty -> mitaka and mitaka -> master so that will show up today16:13
notmynameclarkb: the envvar is name BRANCh, but is it really just a git refspec? eg could one specify GRENADE_OLD_BRANCH as a tag?16:14
clarkbnotmyname: not the way that is current configured16:15
notmynameok16:15
clarkbbecause it upgrades an entire cloud together you need a common ref16:15
clarkbtags unfortunately are not common across the cloud projcets16:15
*** mvk_ has quit IRC16:15
notmynameah, right. these tests are running tests on other projects too16:16
notmynamethere was some talk around just pulling the oldest tag we could find (or even just an old commit SHA) to test rolling upgrades from there. just to show that rolling upgrades work from eg austin release to current master ;-)16:17
cschwedeacoles: i don’t think so, because you need the swift_proxy_stop on the liberty branch as well. i simply added that function to both devstack branches manually16:19
cschwedeand that reminds me that we probably need a backport to liberty… ah well16:19
notmynameclarkb: so updating the gate wrap script will take a fourth patch, right? or is that the same repo as patch 296991?16:20
patchbotnotmyname: https://review.openstack.org/#/c/296991/ - openstack-dev/devstack - WIP: Add stop_swift_proxy method16:20
clarkbnotmyname: correct it is a fourth patch16:20
notmynamecschwede: did clarkb's comments make sense?16:20
cschwedeclarkb: thanks for your comment, will update the patch16:20
cschwedenotmyname: yes, sounds good to me16:20
notmynamecschwede: great. and let's ping the devstacka nd grenade people as soon as those are updated16:21
cschwedei’m not sure when i will be able to update this, will try to work on it tonight16:21
cschwedenotmyname: yes, absolutely. i also remove the wip flags then16:21
*** eranrom has joined #openstack-swift16:21
*** trifon has joined #openstack-swift16:21
notmynamecschwede: ok. if you arent' getting to it until later tonight, I can take a stab at updating it (I'll probably need to figure out how to set up a test env for it)16:22
*** haomaiwang has quit IRC16:22
*** haomaiwang has joined #openstack-swift16:22
*** haomaiwang has quit IRC16:23
clarkbfor a test env you may be able to take the reproduce.sh script in the logs of other grenade runs and tweak the parameters16:23
clarkbthen run that on an ubuntu trusty VM16:23
*** haomaiwa_ has joined #openstack-swift16:23
clarkbin theory that will just work16:23
*** haomaiwa_ has quit IRC16:24
clarkbbut I doubt anyone has tried it against grenade recently16:24
*** haomaiwang has joined #openstack-swift16:25
*** haomaiwang has quit IRC16:26
*** haomaiwa_ has joined #openstack-swift16:26
*** haomaiwa_ has quit IRC16:27
*** haomaiwang has joined #openstack-swift16:27
*** haomaiwang has quit IRC16:28
*** jordanP has quit IRC16:28
*** haomaiwa_ has joined #openstack-swift16:28
*** haomaiwa_ has quit IRC16:29
*** haomaiwa_ has joined #openstack-swift16:29
*** haomaiwa_ has quit IRC16:30
*** 7F1AAK9L3 has joined #openstack-swift16:30
*** 7F1AAK9L3 has quit IRC16:31
*** haomaiwa_ has joined #openstack-swift16:31
*** haomaiwa_ has quit IRC16:32
*** haomaiwang has joined #openstack-swift16:32
*** haomaiwang has quit IRC16:33
*** chsc has joined #openstack-swift16:33
*** haomaiwa_ has joined #openstack-swift16:33
*** haomaiwa_ has quit IRC16:34
*** haomaiwang has joined #openstack-swift16:34
*** haomaiwang has quit IRC16:35
*** nadeem has joined #openstack-swift16:35
*** haomaiwang has joined #openstack-swift16:35
*** haomaiwang has quit IRC16:36
*** haomaiwang has joined #openstack-swift16:36
*** dmorita has joined #openstack-swift16:36
*** haomaiwang has quit IRC16:37
*** lyrrad has joined #openstack-swift16:37
*** 14WAAKC1C has joined #openstack-swift16:37
*** 14WAAKC1C has quit IRC16:38
*** haomaiwa_ has joined #openstack-swift16:38
*** haomaiwa_ has quit IRC16:39
*** haomaiwang has joined #openstack-swift16:39
*** haomaiwang has quit IRC16:40
*** haomaiwang has joined #openstack-swift16:40
*** haomaiwang has quit IRC16:41
*** haomaiwa_ has joined #openstack-swift16:41
*** haomaiwa_ has quit IRC16:42
timburkegood morning16:42
*** haomaiwa_ has joined #openstack-swift16:42
*** haomaiwa_ has quit IRC16:43
*** haomaiwa_ has joined #openstack-swift16:43
*** haomaiwa_ has quit IRC16:43
notmynametimburke: hello. read the scrollback for interesting developments on the rolling upgrade test. cschwede has done a bunch of good work16:44
claygoh man, gerrit is getting under my skin today.... "Working"16:44
timburkeyep, i saw. thanks cschwede!16:44
clayg...16:44
*** StraubTW_ has quit IRC16:44
*** geaaru has quit IRC16:46
*** trifon has quit IRC16:48
openstackgerritSamuel Merritt proposed openstack/swift: Fix up get_account_info and get_container_info  https://review.openstack.org/28097816:52
openstackgerritSamuel Merritt proposed openstack/swift: Make info caching work across subrequests  https://review.openstack.org/28097716:52
*** [1]eranrom has joined #openstack-swift16:53
*** eranrom has quit IRC16:56
*** [1]eranrom is now known as eranrom16:56
*** esker has quit IRC16:56
*** wasmum has quit IRC16:56
*** openstackgerrit has quit IRC17:01
*** openstackgerrit has joined #openstack-swift17:02
notmynameclayg: yeah, I'm seeing some big slowdowns in gerrit too17:05
*** trifon has joined #openstack-swift17:05
timburkestill? they just restarted it. i thought it was supposed to be better :(17:05
notmynameoh, did they just restart it? might be better now17:06
timburkeno, it's still pretty slow...17:06
notmynameyeah17:06
notmynameseems that gerrit needs to be restarted every other day recently17:06
notmynamecschwede: acoles: timburke: I talked to ttx about the rolling upgrade tag. based on the current work being close to landing, we'll at least have some support in the TC for not dropping the tag17:07
notmynamebut likely not universal17:07
notmynameand I'll need to give an update on the TC resolution before the end of this week17:07
clarkbit should be happy now17:10
clarkbat least I hae been able to review several changes iwthout it going nuts17:10
*** StraubTW has joined #openstack-swift17:11
*** wasmum has joined #openstack-swift17:12
*** StraubTW has quit IRC17:12
claygtorgomatic: i've been trying to approve that patch for 10mins!  how'd you get gerrit to load!17:12
timburkeanybody else see this when running unit tests lately? "proxy ERROR: Exception fetching fragments for '/a/ec-discon/test': ChunkWriteTimeout (60s)"17:16
claygwell it *was* a discon test?17:17
claygtimburke: anyway it reminds me of a really *old* error we *used* to get - but I think we (like literally you and I) managed to get it fixed?17:18
timburkeyeah...i just don't like having such messages leak out. makes me think something's up17:18
claygtimburke: I have this vague memory of like having to add a sleep before nosetests exits in order to make sure it was fixed?17:18
timburkeclayg: yeah, that's part of why it weirds me out. like, i've seen this before, and it seemed to be masking a problem last time i saw it, so...17:18
claygdo you have like old branch checked out that's maybe not fully up to speed rebased?17:19
claygtimburke: iirc the problem last time ... oh yeah maybe it was a bug - something kota ended up fixing seperatly for the change we had to make in tests ... still - SEEMS LIKE WE'VE DONE THIS ALREADY!  :)17:19
claygtimburke: anyway, no i'm not seeing it on master - is it all the time or just some of the time for you?17:20
timburkeclayg: nope; very recent branch. only missing the 2.7.0 authors/changelog commit. seems to be every time i run the full suite17:21
timburkemaybe my VM's just slower than yours :P17:21
timburkedefinitely the get test, rather than the put17:21
*** asettle has joined #openstack-swift17:22
*** trifon has quit IRC17:23
*** gyee has quit IRC17:23
claygtimburke: ok, i added my "sleep before you exit" hack to nose.core - we'll see if i can spot it17:24
claygtimburke: you think you know the specific test that's generating the request?  like the path is unique or something?  you say "the get test" - which one is that?17:24
timburkeclayg: test_ec_client_disconnect, not test_ec_client_put_disconnect17:25
*** klrmn has joined #openstack-swift17:26
timburke(i added -get and -put to my container path so i could differentiate)17:26
notmynameclayg: thanks on patch 257502. when patch 296800 lands, I think we're good for a release17:26
patchbotnotmyname: https://review.openstack.org/#/c/257502/ - swift - Fix full_listing in internal_client17:26
patchbotnotmyname: https://review.openstack.org/#/c/296800/ - swift - Check marker params in SimpleClient full listing r...17:26
*** rledisez has quit IRC17:26
*** asettle has quit IRC17:27
claygtimburke: oic17:27
claygtimburke: maybe the change you're on breaks it :P17:28
claygwhy is the *GET* test seening a chunkwritetimeout?  Does the test fail?17:29
acolestimburke: i see it17:29
claygacoles: wat!?  how am I missing it then?17:29
timburkeclayg: timeout writing to client17:30
acolesdid i not file a bug?? i remember raising it here but no one bit17:30
clayglol17:30
claygtimburke: ok, well that sorta makes sense - i mean the client *did* disconnect17:31
acolesiirc it was a deliberate client disconnect that leaves thread writing to chunk to the queue in proxy waiting to write...until the tiemout pops17:31
timburkeyeah. not *entirely* sure it's a problem. it just felt suspicious17:31
claygbut i just see -> proxy INFO: 127.0.0.1 127.0.0.1 24/Mar/2016/17/26/39 GET /v1/a/ec-discon/test HTTP/1.0 499 - - t - 8192 - tx3410690f3583472b8682c-0056f4234f - 0.0335 - - 1458840399.807980061 1458840399.841509104 317:31
claygproxy WARNING: Client disconnected on read (txn: tx3410690f3583472b8682c-0056f4234f) (client_ip: 127.0.0.1)17:31
acolestimburke: that was my conclusion, it was noise rather than a bug17:32
claygeventlet==0.18.117:32
clayg???17:32
acolesstill annoying17:32
claygtimburke: acoles: you see the message on *stderr* on a normal `.unittests` run?  like mixed in with the .....17:33
claygi'm on "5d00ce9 2.7.0 authors and changelog updates17:33
timburkeclayg: yeah, immediately after the "OK" line at the end. at least, i assume it's stderr17:33
claygtimburke: ok well i'm definately *not* seeing that - so what's your swift sha and eventlet version?17:34
claygi can't think of anything else relevant that might be different between my config and your17:35
*** rcernin has quit IRC17:36
acolesi'm just running tests to confirm17:37
acoleshehe, my mention was right at top of my scrollback...17:37
acoles"hmmm, the yield in https://github.com/openstack/swift/blob/902cb8f8d74feabc4f402a687b311875935d5221/swift/proxy/controllers/base.py#L825-L825 will timeout after 60s, way after the test has completed. not sure how to prevent/silence that"17:37
*** wasmum has quit IRC17:38
acolesclayg: yeah i see it with tox -e py27, eventlet=0.18.417:38
acolescommit 4be37017:39
timburkei'm exactly where acoles is; same sha, same eventlet17:40
claygyay!  "proxy ERROR: Exception fetching fragments for '/a/ec-discon/test': ChunkWriteTimeout (60s)"17:40
claygyeah i didn't see it with eventlet 0.18.117:40
*** wasmum has joined #openstack-swift17:40
*** pcaruana has quit IRC17:40
acolesyay! i hated the thought of clayg missing out17:41
clayglet me take out my sleep hack - i'm guessing eventlet added some new hawtness to pop timeouts on running coro's during shutdown or something cute - and by that time who's ya boy nose has already stopped his capture stderr jazz17:41
clayghrm... nope nothing that fancy - i acctually have to sleep before letting proxy exit to see it17:42
*** joeljwright has quit IRC17:43
claygwell at least I think it's innocuous17:44
*** trifon has joined #openstack-swift17:46
*** wasmum has quit IRC17:51
timburkeis there any reason not to pass on ChunkWriteTimeouts around https://github.com/openstack/swift/blob/4be370/swift/proxy/controllers/obj.py#L1440, like we do for GreenletExits?17:52
claygtimburke: acoles: I'm looking at https://github.com/openstack/swift/blob/5d00ce9e3a1f5e32ae91c78b6bdfd953658ab984/swift/proxy/controllers/obj.py#L144517:52
*** wasmum has joined #openstack-swift17:53
timburkeyeah, that guy!17:53
*** mmcardle1 has quit IRC17:54
*** ChubYann has joined #openstack-swift17:54
claygwhere is the WriteTimeout being raised from exactly?17:54
notmynamecschwede: oh, I just saw you propose a patch update. you're working on it?17:55
claygit's kind of annoying that the blanket exception handler is trying to log a traceback for us and our logger is being helpful and coverting it to a oneliner :\17:55
cschwedenotmyname: yes17:55
notmynameok17:55
cschwedenearly done, updating my patch chain17:56
cschwedenotmyname: or did i miss something, are you working on it too?17:56
notmynamecschwede: no, it's better if you do it. I had started looking, but I've been hunting for the right repos to download to patch17:56
cschwedenotmyname: sorry, should have pinged you. my day is a ittle bit crazy, my mind feels like there is an error in the floating point unit now :P17:58
notmynameno worries :-)17:58
timburkeclayg: roundabouts https://github.com/openstack/swift/blob/902cb8f8d74feabc4f402a687b311875935d5221/swift/proxy/controllers/base.py#L897-L89917:58
timburke(or a more up-to-date equivalent)17:58
claygtimburke: this is what I got -> https://gist.github.com/clayg/23e6a477f7370efe3fd118:01
claygtimburke: but yeah that doesn't really tell me where it came from - thanks stack switching18:01
cschwedenotmyname: do you want the new job experimantal or voting on the gate?18:01
cschwedewe could start experimental, and change to voting later on18:02
cschwedethat would be my proposal18:02
notmynamecschwede: yes, start with experimental. but very very quickly move to gating18:03
*** esker has joined #openstack-swift18:04
*** panda has quit IRC18:04
*** panda has joined #openstack-swift18:05
cschwedenotmyname: ok, done; the last patch is 297005, and the other three patches are linked using the depends-on tags. hopefully that’s good for now18:06
notmynamecschwede: got it. and I added myself to them all so I can follow them18:07
cschwedenotmyname: answering your earlier comment, i totally think this can and should be improved to do a full rolling upgrade, so if you talk to the TC, that’s in my mind and i will continue working on this once this has landed18:07
claygtimburke: idk more than just silencing the error it'd be nice if we could close those sockets and shutdown those coro's as soon as the front-end notices the pipe is torndown18:07
cschwedebut i won’t be able to work on any follow up patches this week18:07
notmynamecschwede: what do you mean by full rolling upgrade? what did you have in mind?18:07
*** resker has joined #openstack-swift18:08
cschwedenotmyname: well, right now it’s just the proxy that is upgraded, ie all other services are running on liberty, and proxy on mitaka (or head). but i can think to add more steps inbetween, so another step for account-servers, container-servers, object-servers18:09
notmynamecschwede: yeah, that sounds good18:09
cschwedenotmyname: that are just ideas for now, i will have a closer look how other projects handle this. and of course i’m open to all suggestions from the TC, comments welcome!18:09
notmynamecschwede: thank you for working on this :-)18:09
cschwedeyou’re welcome :)18:10
*** esker has quit IRC18:11
claygnotmyname: so the works on http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html seem pretty clear that this tag means it's tested in the gate - i'm not sure on the timeline tho - did they grandfather the tag with the assumption we'd setup a job during this release cycle - or did the merge "yeah this is a gated assert tag now, you're out" in the past couple of weeks and now we're fire drilled?18:13
timburkeclayg: notmyname claimed support in patch 24655818:14
patchbottimburke: https://review.openstack.org/#/c/246558/ - governance - added assert tags to swift (MERGED)18:14
*** silor has quit IRC18:14
*** wasmum has quit IRC18:15
timburkeand i seem to recall asking about whether we *actually* tested it in the gate when he did that...18:15
*** silor has joined #openstack-swift18:16
claygwell I7ba9cdbe1b6ba026da374dd66e30611133538e91 sure makes it seem like dems' the rules and we sorta cheated - oops!18:19
claygtimburke: acoles: I'm going down this line of reasoning -> https://gist.github.com/clayg/29eb57bb93142dbfe64b18:23
*** wasmum has joined #openstack-swift18:23
claygonce we have the backend sockets shutdown things only go off the rails because the backends are blocked in wrong place - so if we drain the queues after we shutdown the sockets thing resolve fairly quickly?18:23
notmyname /headdesk18:24
openstackgerritEran Rom proposed openstack/swift: Add process level concurrency to container sync  https://review.openstack.org/21009918:25
openstackgerritEran Rom proposed openstack/swift: Add thread level concurrency to container sync  https://review.openstack.org/22533818:25
claygtimburke: i also added a diff on the test that might make it easier for see the error when running the test by itself18:25
acolescschwede: thanks for all your work on the upgrade test!18:26
claygtimburke: or it might not be helping at all - i'm not sure I understand wft is going on18:26
acolescschwede: i have been very frustrated by setting up grenade today - partly my usual problem of proxy settings causing stuff to fail:/ i feel like i am close.18:27
acolesclayg: makes sense when you put it in words like that. but also i'm not sure i grok it yet18:29
timburkeclayg: that's how i felt through most of my debugging last time :/18:29
*** daemontool has quit IRC18:32
*** asettle has joined #openstack-swift18:43
*** Guest27982 has quit IRC18:46
*** asettle has quit IRC18:48
timburkeclayg: i think i may have been hasty to rip out the part_iter.close() in https://review.openstack.org/#/c/241778/2/swift/proxy/controllers/base.py -- what do you think about https://gist.github.com/tipabu/9e1b3b79db36dd964e34?19:02
patchbottimburke: patch 241778 - swift - Close EC fragment iterators in the GreenThread tha... (MERGED)19:02
timburkestill need to try functests with EC-by-default, though19:03
*** daemontool has joined #openstack-swift19:07
notmynameacoles: timburke: cschwede: current summary (since you may have seen the reviews): turns out the -partial mechanism isn't supposed to be used any more. but there's a different thing. multinode19:11
notmynamehttps://review.openstack.org/#/c/297311/ sets up the multinode job in a way that would allow for different versions to be installed19:11
patchbotnotmyname: patch 297311 - openstack-infra/devstack-gate - Run swift services on subnode19:11
notmynamebut it would require that we (1) add the multinode job to our gate (which should be easy) and (2) figure out how to get the deployed rings to use both services, which nobody has any idea on right now19:12
notmynameI'm talking it over with sdague in -infra19:14
acolesnotmyname: have you managed to figure out yet - are the multi "nodes" actually mulitple vms?19:14
notmynameI'm led to believe that, but I'll check19:14
clarkbthey are19:15
acolesi noticed suggestion 2 on that review "Do the more complicated bits as a swift devstack plugin." which got me wondering again about running different swift service/versions in differetn venvs19:15
acolesclarkb: thanks19:15
*** _JZ_ has joined #openstack-swift19:15
notmynameclarkb: thanks for arguing for the -partial method19:16
clarkbya well...19:16
notmynamehttps://etherpad.openstack.org/p/swift-rolling-upgrade-multinode-testing  <-- is sdague's suggestions19:19
*** daemontool has quit IRC19:25
notmynameclarkb: is there only one (data) drive on the nodes? sdb1?19:32
notmynameah, nm. I see now19:33
clarkbI believe that devstack makes a single xfs device for you19:33
clarkbso ya19:33
notmynamethat's one loopback device that is created in that script19:33
clarkbyup19:33
clarkband formated xfs because thats what swift wants iirc19:33
notmynameyeah. really just needs xattrs support, but xfs is best19:34
notmynameclarkb: how much space is available on the VM?19:35
clarkbnot a ton, its 80GB / with about 15 used by system, 8GB swap file/device, 7GB of git repos etc19:35
notmynamenot as big of a deal as I thought because it's only setting up 1 replica. otherwise we'd need more disks19:37
*** wasmum has quit IRC19:39
openstackgerritPeter Lisák proposed openstack/swift: Change schedule priority of daemon/server in config  https://review.openstack.org/23879919:40
*** asettle has joined #openstack-swift19:40
*** asettle has quit IRC19:45
openstackgerritThiago da Silva proposed openstack/swift: Refactor server side copy as middleware  https://review.openstack.org/15692319:57
openstackgerritThiago da Silva proposed openstack/swift: decouple versioned writes from COPY  https://review.openstack.org/26017919:57
cschwedenotmyname: ok, so i expected something like this… anyways, i can continue working on this, following up with Seans proposals, but not before Monday. Let me know if you or someone else continues with, otherwise I continue next week19:59
notmynamecschwede: thanks20:00
notmynametimburke's also looking at stuff20:00
*** cdelatte has quit IRC20:02
*** trifon has quit IRC20:03
*** gyee has joined #openstack-swift20:06
openstackgerritTim Burke proposed openstack/python-swiftclient: Clean up some unnecessary variables  https://review.openstack.org/29662020:07
claygtimburke: Mar 24 20:10:15 saio proxy-server: STDERR: ValueError: generator already executing (txn: tx62b6255e778b49459dcbc-0056f449a7) (client_ip: 127.0.0.1)20:10
claygsigh20:10
claygtimburke: I do think we have something wrong on ec_get_disconnect - your intuition was right about that message showing up20:11
clayg... i think20:11
claygtimburke: at least I'm seeing way more ESTABLISHED connections than I would like after running this -> https://gist.github.com/clayg/e2501e6615d0a1eae4e820:12
*** zhiyan has quit IRC20:19
openstackgerritMerged openstack/swift: Fix full_listing in internal_client  https://review.openstack.org/25750220:19
*** mmcardle has joined #openstack-swift20:19
openstackgerritMerged openstack/swift: Check marker params in SimpleClient full listing requests  https://review.openstack.org/29680020:20
notmynamecool. I think those are the last things for this release20:20
*** zhiyan has joined #openstack-swift20:20
notmynamethat means the SHA for swift 2.7.0 is e0bac5e9e874f0dbdda3ea94f34b1922fca9ba3520:21
timburkeclayg: right..generator-already-executing guy...hmmm... wrong finally, maybe? try latest revision at https://gist.github.com/tipabu/9e1b3b79db36dd964e3420:21
acolesnotmyname: i'm not sure what is required for the upgrade test, but i believe i have a proxy running HEAD and a/c/o running liberty on my saio20:22
notmynameacoles: that's really cool20:22
claygtimburke: i thought that's what I was running?20:22
notmynameacoles: did you see the etherpad I linked earlier? https://etherpad.openstack.org/p/swift-rolling-upgrade-multinode-testing20:23
acolesis there anywhere we log the version? i need reassurance :)20:23
timburkeclayg: i updated it. like a jerk.20:23
acolesnotmyname: just looked20:23
claygtimburke: oh nice20:23
notmynameacoles: it's in /info. also in code via 'import swift; swift.__version__'20:23
notmynameacoles: timburke: clayg: good with e0bac5e9e874f0dbdda3ea94f34b1922fca9ba35 as the release SHA? (current HEAD of master)20:24
acolesnotmyname: well let me just run it by my upgrade test... ;)20:25
notmyname:-)20:25
acolesnotmyname: that's Merge "Check marker params in SimpleClient full listing requests", looks good to me20:25
claygtimburke: still generator-already-executing, still established sockets from proxy->storage, now put_fragments_in_queue logs [Errno 9] Bad file descriptor (well some of them do, another still logged ChunkWriteTimeout20:26
claygnotmyname: if it's good by acoles it's good by me20:26
claygnotmyname: do we get to keep making swift better or is this like our last chance?20:27
notmynamewe will have next week to land backports, if necessary20:27
*** sheel has quit IRC20:27
claygok, so we can keep going, phew20:27
claygi need more coffee20:27
*** jmccarthy1 has joined #openstack-swift20:30
claygtimburke: i think it's weird for a generator to throw already running when you call close - it's like no joke - that's why i'm closing your %^&hole20:30
notmynameswift mitaka release request https://review.openstack.org/#/c/297352/20:32
patchbotnotmyname: patch 297352 - releases - Swift 2.7.0 release20:32
acolesnotmyname:  so /info tells me *proxy* is at 2.6.1dev260 while in a/c/o venv swift.__version__ is '2.5.1.dev2', plus when i started a/c/o they barfed because i have liberasurecode_rs_vand config'd, so i had to rollback the config to jerasure, so i am gaining confidence that i am running two versions20:34
acolesjust running func tests20:34
acolesi think the sure way will be for me to create a branch that spits out errors and run that in a/c/o venv20:35
notmynameacoles: I think it seems like the way to go is with the multinode setup in devstack. do you think the multiple venvs offer anything that the multinode setup doesn't?20:36
acolesnotmyname: i can't argue against it. i have spent today battling to setup grenade/devstack without success, it took me 5 mins to spin up two venvs, so i am wary of the learning curve wrt devstack20:38
acolesbut if someone knows how to get it all to work then great!20:38
acolesof course my way would still require some devstack hackery20:39
acolesnotmyname: i was also curious to see how the tests do fare in a partial upgrade scenario - we'll have to choose a reasonable set of tests to run. i see some functest failure (which may well be expected)20:43
notmynameyeah, I think it's a good thing to have the tests, and something we'll definitely be able to use to improve20:44
* notmyname steps away for a bit20:44
acolesnotmyname: i'm out mon/tues, i may only check in briefly tomorrow, but looks like the release is good to go :)20:46
*** openstackgerrit has quit IRC20:48
*** openstackgerrit has joined #openstack-swift20:49
*** acoles is now known as acoles_20:51
*** acoles_ is now known as acoles20:51
*** acoles is now known as acoles_20:55
*** silor has quit IRC21:07
*** sileht has quit IRC21:07
*** sileht has joined #openstack-swift21:08
notmynameacoles_: thanks21:13
*** panda has quit IRC21:20
*** trifon has joined #openstack-swift21:29
*** asettle has joined #openstack-swift21:33
*** ntata has quit IRC21:33
*** zacksh has quit IRC21:33
*** zacksh has joined #openstack-swift21:35
*** nadeem has quit IRC21:38
*** nadeem has joined #openstack-swift21:38
*** openstack has joined #openstack-swift21:50
*** elmiko has left #openstack-swift21:51
*** ntata has joined #openstack-swift21:54
*** ametts has quit IRC21:57
*** fbo has joined #openstack-swift22:00
*** kota_ has joined #openstack-swift22:00
*** wolfe.freenode.net sets mode: +v kota_22:00
*** Zyric has quit IRC22:01
*** Zyric has joined #openstack-swift22:03
*** dmorita has quit IRC22:04
*** dmorita has joined #openstack-swift22:05
*** asettle has quit IRC22:12
openstackgerritMerged openstack/swift: Handle tempurl Content-Disposition header missing from HEAD  https://review.openstack.org/29693622:19
*** Zyric has quit IRC22:23
*** NM has joined #openstack-swift22:37
openstackgerritTim Burke proposed openstack/swift: Add Expires header for successful GETs using tempurls  https://review.openstack.org/27973722:38
*** trifon has quit IRC22:39
*** NM has quit IRC22:43
*** nadeem has quit IRC22:43
*** CaioBrentano has quit IRC22:44
*** jmccarthy1 has quit IRC22:44
*** jmb__ has quit IRC22:47
*** chlong has joined #openstack-swift22:55
*** km has joined #openstack-swift22:58
*** Zyric has joined #openstack-swift22:59
*** _JZ_ has quit IRC23:06
*** mmcardle has quit IRC23:12
*** dmorita has quit IRC23:20
*** dmorita has joined #openstack-swift23:20
*** dmorita has quit IRC23:21
*** dmorita has joined #openstack-swift23:21
*** jmb__ has joined #openstack-swift23:22
*** lyrrad_ has joined #openstack-swift23:23
*** lyrrad has quit IRC23:23
*** lyrrad_ is now known as lyrrad23:23
*** rickyrem has joined #openstack-swift23:25
*** jmb__ has quit IRC23:27
*** kei_yama has joined #openstack-swift23:28
claygtimburke: so i was wrong - you can close the part_iter up there if you want - but I still need to add the sleep() call - it just switches from needing it for a slow client to needing it for a fast client23:32
openstackgerritTim Burke proposed openstack/swift: Fix versioned_writes functional test skipping  https://review.openstack.org/26501723:33
*** vint_bra has quit IRC23:37
*** mingdang1 has joined #openstack-swift23:38
*** mingdang1 has quit IRC23:55

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!