21:00:35 <acoles> #startmeeting swift
21:00:36 <openstack> Meeting started Wed Aug  2 21:00:35 2017 UTC and is due to finish in 60 minutes.  The chair is acoles. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:39 <openstack> The meeting name has been set to 'swift'
21:00:48 <acoles> Hi, who is here for the swift meeting?
21:00:51 <joeljwright> o/
21:01:03 <kota_> hi
21:01:06 <tdasilva> hello
21:01:13 <jungleboyj> @!
21:01:13 <_pewp_> jungleboyj (*´･д･)ﾉ
21:01:22 <rledisez> hello o/
21:02:19 <acoles> this week notmyname is on vacation so I will faclitate the meeting
21:02:33 <acoles> thanks everyone for being here
21:02:42 <acoles> the agenda is in the usual place ...
21:02:43 <kota_> thanks acoles
21:02:46 <acoles> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:22 <torgomatic> oh, hello everyone
21:03:31 <timburke> hi all
21:03:36 <joeljwright> hey
21:03:41 <acoles> not too much to cover so hopefully a short meeting
21:03:55 <acoles> so first up is the PTG
21:04:08 <acoles> #topic Denver PTG
21:04:25 <acoles> we are gathering ideas for the PTG sessions on an etherpad
21:04:34 <acoles> #link https://etherpad.openstack.org/p/swift-ptg-queens
21:04:54 <acoles> it's good to see there ^^ that a few more people are signed up
21:05:10 <acoles> let's keep adding ideas for topics
21:05:29 <acoles> and also indicate where your particular interests are
21:06:22 <acoles> I see notmyname has started a list for those that will be around for bug triage so go and add your name there if you will (on the same etherpad)
21:06:55 <acoles> did we decide how that bug triage would work?
21:07:06 <zaitcev> I think I'll be there at PTG, hopefully with functests for PUT+POST, although these days I'm mostly looking at Gnocchi.
21:07:20 <acoles> zaitcev: good to hear!
21:07:33 <tdasilva> acoles: divide and conquer sounded good to me
21:07:44 <acoles> tdasilva: yes
21:08:22 <tdasilva> acoles: I was also going to suggest actually removing the lines that are getting crossed out, maybe the visualization of smaller list encourages more people to triage ;)
21:08:56 <acoles> tdasilva: yes, they will eventually make it hard to find the un-triaged bugs!
21:09:06 <tdasilva> right
21:09:25 <acoles> or shuffle them down but that is more work
21:09:57 <acoles> any questions about the PTG?
21:10:48 <acoles> ok since we strayed on to it let's jump to
21:10:49 <acoles> # topic bug triage
21:11:06 <acoles> #link etherpad: https://etherpad.openstack.org/p/swift-bug-triage-list
21:11:26 <acoles> looks like there has been some progress but plenty more to do :)
21:11:48 <acoles> any questions on the process for triage?
21:12:35 <acoles> quiet today
21:12:54 <tdasilva> heh, might be short meeting indeed
21:13:28 <acoles> ok, well let's keep plugging away at the bugs - I found some easy ones to triage so get there early to do the same
21:13:30 <kota_> tdasilva: hehe, me too :P
21:13:44 <timburke> i found one to do with adding ipv6 support :-)
21:13:56 <acoles> hehe
21:14:15 <timburke> ✓
21:15:12 <tdasilva> btw: this this the list: https://etherpad.openstack.org/p/swift-bug-triage-list
21:15:18 <tdasilva> for folks that are not aware...
21:15:35 <tdasilva> nevermind, acoles had already posted it
21:15:39 <acoles> it is also allowed to *fix* bugs but a reminder that the goal of this exercise is to reduce the number of un-triaged (Importance=Undecided, Status=New)
21:15:54 <acoles> tdasilva: you can't post it enough! ;)
21:16:15 <acoles> ok, enough on triage?
21:16:23 <acoles> going, going...
21:16:33 <timburke> oh, quick question: do we have much guidance on assigning importance?
21:16:54 <timburke> in particular, low vs medium seems... fuzzy
21:18:21 <tdasilva> use your best judgment ??? honestly...idk..but i expect we would hash it out overtime
21:18:47 <acoles> timburke: to my mind Low is the bottom rung (wishlist is sort of orthogonal, not really a bug) and probably implies inaction until it bumps up to Medium??
21:19:22 <timburke> k. i'll continue winging it :-)
21:19:25 <acoles> that said, I can imagine Low importance sometimes being low hanging fruit so they might bet worked on
21:19:34 <acoles> s/bet/get/
21:19:38 <mattoliverau> Sorry I'm late o/
21:19:56 <acoles> the one rule I do know is that Critical blocks a release
21:20:05 <acoles> mattoliverau: welcome
21:20:47 <acoles> and maybe High implies pain for ops?
21:21:13 <acoles> but we'll all make our own judgements I guess
21:22:01 <acoles> ok next topic...
21:22:03 <acoles> #topic recent releases
21:22:21 <acoles> since last week's meeting we have had both swiftclient and swift releases
21:22:51 <mattoliverau> \o/
21:22:55 <acoles> #link https://releases.openstack.org/teams/swift.html
21:22:56 <joeljwright> yay!
21:22:58 <kota_> great
21:23:19 <acoles> There is lots of good stuff in these releases so well done and thanks to everyone for contributing!
21:23:52 <acoles> If I understand correctly the swiftclient release will be the final one for Pike. I'm not so sure for swift - there may be one more before Pike (end August/start September)
21:24:56 <timburke> oh yeah, i should look into getting a release-notes link on that page for swiftclient, too
21:25:33 <acoles> timburke: that would be great (but I have no idea how it happens)
21:26:03 <tdasilva> timburke: is this the work of reno: https://docs.openstack.org/releasenotes/swift/current.html ?
21:26:26 <acoles> yes reno is the tool
21:26:58 <timburke> i did it once... https://review.openstack.org/#/c/462708/ i think? maybe needed us to have some other stuff already in place...
21:27:35 <timburke> like https://review.openstack.org/#/c/451118/
21:28:28 <acoles> so timburke is going to fix that (along with everything else) ;-)
21:29:04 <timburke> ...and it looks like swiftclient still needs a releasenotes tox job
21:29:43 <acoles> Perhaps worth a reminder that swift 2.15.0 is the first release to force deprecation of unsupported isa_l_rs_vand policies as announced here...
21:29:44 <acoles> #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118242.html
21:30:05 <mattoliverau> Oh yeah cool
21:30:15 <mattoliverau> Good to remember
21:30:22 <acoles> mattoliverau: or not, depending on your circumstances ;)
21:30:55 <mattoliverau> Maybe soon we'll hear how many people where running EC in a bad configuration out in the wild
21:31:09 <zaitcev> Imagine waking up one day and saying "I wish Erasude Coding were never invented!"
21:32:34 <timburke> zaitcev: ...been working on that PUT+POST patch a bit, eh?
21:33:30 <kota_> is there any idea on calling alert for k>=22, m=4 for isa_l_rs_vand too?
21:33:57 <kota_> as well as m>=5 case on that e-mail from notmyname
21:34:10 <timburke> that would probably be wise, but i don't know that anyone's started on it
21:34:17 <acoles> kota_: yes we should do that, needs a patch
21:34:36 <acoles> kota_: do you have link to the isa_l issue for those who may not be familiar?
21:35:05 <acoles> found it
21:35:09 <acoles> #link https://github.com/01org/isa-l/issues/10#issuecomment-310944022
21:35:43 <kota_> acoles: that one, i just am looking for with my browser ;)
21:36:24 <acoles> note that the use of 'm' on that page is different from how kota_ and many of use 'k' and 'm'
21:37:32 <mattoliverau> Right, then that isn't confusing ;p
21:37:55 <acoles> but the conclusion is that when num data parity frag is >=22 then num parity frags should be <= 4
21:38:16 <acoles> gah and I just confused it myself :/
21:38:29 <acoles> when num data frag is >=22 then num parity frags should be <= 4
21:39:07 <mattoliverau> lol
21:39:14 <acoles> kota_: timburke I think first step might be a patch to add a warning? similar to the original issue
21:39:30 <kota_> acoles:  +1
21:39:33 <timburke> strictly < 4, yeah? m=4 is bad
21:39:43 <kota_> timburke: true
21:41:28 <acoles> timburke: yes. sorry. too late here for maths!
21:41:57 <acoles> Anyway, great work everyone on the recent releases.
21:42:01 <acoles> #topic next meeting
21:42:41 <acoles> Next week there is an 0700UTC meeting  on August 9th which I believe mattoliverau will be chairing
21:42:54 <mattoliverau> Yup
21:42:56 <acoles> I'm not sure what the plan is for next week's 2100UTC meeting - notmyname will still be on vacation.
21:43:49 <acoles> I'm also away next week. I suggest watch the agenda wiki for an update on the 2100 meeting.
21:44:03 <acoles> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:44:13 <mattoliverau> Kk
21:44:14 <acoles> #topic open discussion
21:44:32 <acoles> anyone want to raise anything for discussion?
21:44:51 <joeljwright> I'd love more opinion on slo pre/post amble
21:44:57 <joeljwright> christian made some comments
21:45:01 <joeljwright> but it feels stuck
21:45:16 <joeljwright> https://review.openstack.org/#/c/365371/
21:45:40 <zaitcev> well, I saw the review but I have no idea what it's for and how it works. I'll have a look, I guess.
21:46:05 <joeljwright> zaitcev: thanks
21:46:30 <joeljwright> it's for building containers (like tar) around data without storing tiny objects in the SLO manifest
21:46:52 <joeljwright> thanks to anyone who looks :)
21:47:07 <mattoliverau> I'm getting up to speed on the new job etc. But hope to be more available soon :)
21:47:54 <acoles> Christian's review is positive
21:48:21 <acoles> let's try to get some more review on this for joeljwright
21:48:30 <joeljwright> acoles: thanks!
21:48:59 <rledisez> joeljwright: i should be missing something, but i'm wondering what is the advantage over a middleware that would generate the tar on-the-fly based on a requested list of objects. is that because the list is stored in the swift cluster?
21:50:16 <torgomatic> rledisez: if nothing else, it's more general. A middleware that generates a tarball can only generate tarballs; this one can be made to produce tar archives, zip archives, or other sorts of things
21:50:46 <timburke> torgomatic: according to joeljwright, zip is...problematic
21:51:08 <joeljwright> well, it would be a lot less problematic if we had crc's in the metadata ;)
21:51:11 <torgomatic> ok, zip is a bad example then... but you could concatenate audio/video files in cooperating formats
21:51:33 <zaitcev> any archive that splits up objects into blocks will not be expressed with just preambles
21:51:37 <joeljwright> torgomatic: that's one of the other examples I've been trying to find time to look into
21:51:46 <rledisez> so the use case is to be able to access part individually and also "grouped" together. right?
21:51:58 <joeljwright> preambles + postambles + range requests would work though zaitcev
21:53:16 <joeljwright> rledisez: yes that's one use case
21:53:27 <joeljwright> it's also useful to have the pre-validation of SLO
21:53:34 <joeljwright> so we know the tarball is the one we created
21:53:48 <joeljwright> not some arbitrarilty changed data later dynamically made into a tar
21:54:53 <zaitcev> Well, as long as it's limited to middleware... I'm really suspicious of these ad-hoc things.
21:55:03 <rledisez> ok. i'm asking cause we are looking into dynamic archive construction on swift (zip for now). but it's different use case, so no overlap i think
21:56:38 <acoles> joeljwright: thanks for drawing attention to that patch
21:56:54 <joeljwright> :)
21:56:59 <acoles> anything else to raise before we end?
21:58:16 <acoles> ok. thanks everyone for being here. I'm calling 58 mins a 'short' meeting ;)
21:58:31 <acoles> #endmeeting