07:00:16 <acoles> #startmeeting swift
07:00:17 <openstack> Meeting started Wed Jun 14 07:00:16 2017 UTC and is due to finish in 60 minutes.  The chair is acoles. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:00:20 <openstack> The meeting name has been set to 'swift'
07:00:33 <acoles> Hi who is here for the swift meeting?
07:00:38 <hieulq> o/
07:00:39 <m_kazuhiro> o/
07:00:43 <mahatic> hello!
07:00:47 <tovin07_> o/
07:00:48 <mattoliverau> o/
07:00:50 <kota_> hello
07:01:01 <psachin> o/
07:01:05 <jeffli> o/
07:02:17 <acoles> good morning/afternoon/evening
07:02:44 <rledisez> hi
07:02:52 <mahatic> good morning
07:02:58 <jeffli> Good afternoon!
07:02:59 <acoles> Thanks for attending this meeting, the agenda is here ...
07:03:00 <acoles> #link https://wiki.openstack.org/wiki/Meetings/Swift
07:03:20 <acoles> note that the agenda for this meeting (0700) is in the right hand column
07:03:29 <mattoliverau> welcome to the second other meeting :)
07:03:58 <mahatic> notmyname doesn't want it to be called anything other than "Swift meeting" ;)
07:04:18 <acoles> mattoliverau: yes, this is the second in our new 0700UTC meeting slot
07:04:20 <mahatic> and I second that
07:04:27 <mahatic> oic, like that
07:04:36 <acoles> mahatic: yes, this is the "0700 swift meeting"
07:04:55 <mattoliverau> shame we can't call it the 007 meeting ;)
07:05:03 <mattoliverau> or can we? ;)
07:05:17 <kota_> lol
07:05:18 <acoles> Rather than duplicating the agenda for the 2100 meeting I tried to select some topics that would involve people likely to be here at this time
07:05:20 <mahatic> lol, looks like it
07:05:30 <kota_> mattoliverau: that sounds secret
07:05:32 <mattoliverau> acoles: nice
07:05:42 <mattoliverau> kota_:  lol, top secret
07:05:45 <acoles> mattoliverau: call it what you like, just showing up is great :)
07:05:52 <mahatic> acoles: yup, looks good
07:06:12 <acoles> so to start with there are some pieces of information to share...
07:06:25 <acoles> #topic Denver PTG
07:06:37 * acoles is learning the meeting bot commands :)
07:07:09 <acoles> in case you missed the announcement, the PTG in Denver now has dates and a hotel block confirmed
07:07:18 <acoles> #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118002.html
07:07:40 <acoles> week of 11th - 15th September
07:07:51 <mattoliverau> cool
07:08:10 <acoles> this is the 'dedicated developer gathering', so swift will have 3 full days of meeting room allocated
07:08:23 <acoles> on Weds-Thurs
07:08:33 <mattoliverau> tho I don't think I'll be there, not going to self fund cause I'm unemployed.. and if I do happen to have a new job by then, it might be too late (or early) to ask for travekl :(
07:08:36 <mahatic> thanks for the reminder
07:08:59 <acoles> Mon & Tues will be for 'cross project' or 'inter project' work
07:09:00 <mahatic> though it's unlikely that I'd attend
07:09:08 <acoles> mattoliverau: :(
07:09:14 <acoles> mahatic: :( too!
07:09:32 <mattoliverau> yeah, mahatic  and I will just do our own one... virtually :)
07:09:41 <mahatic> I know, too bad!
07:09:50 <mahatic> mattoliverau: it's a deal! ;)
07:09:52 <acoles> the PTG should IMHO be more productive than the forum in Boston due to us having more dedicated meeting times
07:10:03 <mattoliverau> +1
07:10:10 <kota_> I expects that
07:10:18 <mahatic> +1 I'd expect that as well
07:10:19 <mattoliverau> the last PTG was great
07:10:23 <acoles> there is a tentative room schedule here tentative room allocation plan
07:10:23 <acoles> #link https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/edit#gid=397241312
07:10:24 <mattoliverau> so if you can be there, try to be :)
07:11:00 <acoles> so, for those who may be able to attend, start making plans
07:11:31 <acoles> any questions on the ptg?
07:11:59 <mattoliverau> not at this point
07:12:01 <acoles> ok
07:12:05 <acoles> #topic Sydney summit call for presentations
07:12:30 <mattoliverau> now thiis one I hope I can at least self fund.. so come to my home country :)
07:12:33 <acoles> briefly, the Sydney summit (November) call for presentations is open
07:12:47 <mahatic> :)  mattoliverau nice!
07:12:49 <acoles> #link https://www.openstack.org/summit/sydney-2017/call-for-presentations/
07:13:06 <acoles> mattoliverau: come to your home??
07:13:16 <mattoliverau> sure!
07:13:17 <mahatic> :D
07:13:26 <acoles> oh , country! (line wrapped for me after home!)
07:13:32 <mattoliverau> come visit the beac house :(
07:13:34 <mattoliverau> :)
07:13:48 <acoles> moving on...
07:13:52 <acoles> #topic deprecating known-bad EC policy
07:14:21 <acoles> you should be aware of patch 468105
07:14:34 <acoles> patchbot? bah, you let me down!
07:14:39 <mattoliverau> lol
07:14:44 <acoles> #link https://review.openstack.org/#/c/468105/
07:14:48 <mahatic> lol
07:14:53 <mattoliverau> and notmyname also send a mailing list about it
07:14:58 <mahatic> yeah
07:14:59 <mattoliverau> #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118242.html
07:15:04 <acoles> notmyname promised me patchbot would be here to hold my hand :)
07:15:11 <acoles> mattoliverau: thanks
07:15:28 <acoles> and that email has also gone to the ops ML
07:15:31 <acoles> #link http://lists.openstack.org/pipermail/openstack-operators/2017-June/013735.html
07:15:43 <mattoliverau> oh yeah
07:16:02 <acoles> we have discussed this in previous meetings, but it's worth bringing up again, in case any one has questions/concerns
07:16:38 <acoles> in summary, once that patch lands, swift services will not start if there are known bad polices *that have not been deprecated*
07:17:33 <acoles> so that is likely to be in the next release of Swift
07:18:24 <acoles> if you or your customers are using the known-bad isa-l-rs-vand configuration then they MUST deprecate it and really should be moving data away from it
07:18:43 <acoles> any questions?
07:18:57 <mahatic> okay. Looks like the change could use some eyes, unless we're deliberately waiting to merge it
07:19:54 <acoles> mahatic: that is a good point, it might be one of those patches that we like to collect several +2 to be sure that the community as a whole has adopted the change
07:19:56 <psachin> acoles: Is it documented?
07:20:28 <acoles> psachin: that's also a great question!
07:20:40 <mahatic> acoles: yeah, sounds good
07:20:44 <acoles> I don't see any doc changes in that patch https://review.openstack.org/#/c/468105/
07:21:03 <acoles> we have been alerting the bad policies for a while, so maybe there is an existing doc warning
07:21:34 <mahatic> shouldn't the "UpgradeImpact" tag in commit msg trigger some doc changes?
07:21:53 <acoles> nope I do not yet find any doc
07:22:24 <acoles> ok, well there's a potential review comment that could be left on gerrit
07:22:47 <mattoliverau> i think it had deprication warning in the changelog
07:22:59 <mattoliverau> i thought
07:23:03 <acoles> mahatic: no I don't think anything automatic happens as a result of UpgradeImpact - the tag is there for users to grep and find likely ugrade issues
07:23:13 <mattoliverau> and we log the warning, I also thohught
07:23:24 <kota_> perhaps, it's good to add the info to doc/source/overview_erasure_code.rst?
07:23:44 <mattoliverau> yeah, thats where I was just looking but couldn't see antthing
07:23:45 <acoles> mattoliverau: right, it is in the changelog but it does feel like the EC docs should say 'don't use this config'
07:23:52 <mahatic> acoles: ah okay
07:23:54 * kota_ is searching the word about that
07:23:55 <mattoliverau> +100
07:23:56 <acoles> maybe they do and I don't see it
07:24:06 <acoles> kota_: +1
07:24:24 <acoles> would someone volunteer to leave a comment on the pacth re docs?
07:24:53 <mahatic> I'll do it
07:24:59 <mattoliverau> mahatic: thanks
07:25:08 <acoles> mahatic: thank you
07:25:17 <psachin> mahatic: +1 acoles +1
07:25:20 <acoles> psachin: thanks for raising that issue
07:25:34 <acoles> ok, let's move on
07:25:46 <acoles> #topic doc changes
07:26:01 <acoles> continuing the docs theme...
07:26:16 <acoles> This is a heads-up for forthcoming changes in the way openstack docs are maintained. Previously the bulk of
07:26:16 <acoles> docs was maintained by the docs team, but with changing resources they have decided to move more of the docs
07:26:16 <acoles> over to individual projects. So project teams will be taking more responsibility for maintaining docs.
07:26:35 * acoles prepared that statement earlier :)
07:27:02 <acoles> here's the openstack spec for the changes
07:27:03 <acoles> #link https://review.openstack.org/#/c/472275/
07:27:28 <mahatic> lol, thumbs up for the prep
07:27:32 <acoles> summary - we, swift team, will be maintaining more docs in the future
07:27:53 <acoles> swift already has install guide and api ref in swift repo, as well as the longer standing docs tree
07:28:14 <mattoliverau> yeah most the doc team where laid off with me :(
07:28:21 <kota_> which kind of docs will be in?
07:28:25 <acoles> but we will also get the admin guide and swiftclient will get the CLI reference, if I understand things correctly
07:28:29 <kota_> as a new ones
07:28:37 <kota_> oic
07:29:04 <acoles> there is also a quite lengthy etherpad detailing the implications for each project...
07:29:04 <acoles> #link https://etherpad.openstack.org/p/doc-migration-tracking
07:29:10 <acoles> kota_: listed there ^^
07:29:24 <kota_> thx
07:29:27 <acoles> AFAICT part of the plan will be to unify the various docs under a single doc/ dir
07:29:44 <acoles> I expect that when this move happens we may discover that some of the docs we inherit will need some updating
07:30:09 <mattoliverau> now that would be awesome. 1 doc tree not a million
07:30:12 <acoles> so that's a heads-up - it has not happened yet but it is coming
07:30:15 <acoles> mattoliverau: agree
07:31:21 <acoles> ok, tovin07_ added a topic to agenda so I want to skip to that before we get short on time
07:31:23 <acoles> #topic osprofiler in swift
07:31:38 <tovin07_> yes
07:31:49 <tovin07_> thanks acoles
07:31:51 <acoles> tovin07_: what's up? can you tell us a little about the patch?
07:31:52 <tovin07_> #link https://review.openstack.org/#/c/468316/
07:32:26 <tovin07_> I'll try to integrate osprofiler into swift
07:32:48 <tovin07_> osprofiler is an distributed tracing lib in openstack
07:33:12 <tovin07_> it's in nova, cinder, glance, keystone, neutron, heat,.. already
07:33:49 <tovin07_> the key thing here is that osprofiler can trace request across openstack services
07:34:14 <tovin07_> such as a request come from nova -> keystone -> glance -> cinder ....
07:34:22 <acoles> tovin07_: is it using request id for that?
07:34:42 <tovin07_> nope
07:35:55 <tovin07_> an example in magnum
07:35:57 <tovin07_> #link https://tovin07.github.io/magnum/cluster-create-with-50-iteration-limit.html
07:36:28 <tovin07_> it traces across magnum, keystone, nova, heat
07:36:52 <tovin07_> and traces http, rpc and db calls
07:37:00 <kota_> my brief understang is for osprofiler is that it is for making performance analytics inside of component, right?
07:37:33 <tovin07_> kota_, yes, it's can be used to trouble-shooting as well
07:38:21 <kota_> and at the fist time, i'm feeling swift already has x_profile middelware for such a purpose.
07:38:35 <tovin07_> recently, I discussed with notmyname here http://eavesdrop.openstack.org/irclogs/%23openstack-swift/%23openstack-swift.2017-05-03.log.html#t2017-05-03T16:05:17
07:38:46 <kota_> i'm at natural yet
07:39:19 <tovin07_> yes, I see, however, x-profile works with swift only
07:39:32 <kota_> tovin07_: yes
07:39:53 <kota_> so that sounds like swift logger vs oslo logging tome
07:39:55 <kota_> to me
07:40:15 <kota_> osprofiler is one of openstack "official"(?) analytics tool
07:40:21 <acoles> I see the patch has a link to the openstack spec for osprofiler
07:40:22 <kota_> but swift has already that one
07:40:27 <acoles> #link https://review.openstack.org/#/c/103825/
07:40:47 <psachin> tovin07_: osprofiler only traces requests or it can be used to trace background task like object replication?
07:41:01 <acoles> tovin07_: has the patch changed since the irc conversation with notmyname , in terms of dependencies?
07:41:17 <tovin07_> kota_, yes, https://github.com/openstack/osprofiler
07:42:42 <hieulq> acoles, yes, we only added osprofiler as new dependency, no oslo.config...
07:43:07 <hieulq> and we only added osprofiler into test-requirements
07:43:07 <tovin07_> psachin, currently, it traces requests (db, http, rpc), we also have plan to make osprofiler traces background tasks and periodic tasks as well
07:44:23 <mattoliverau> its interesting, how can we test it? do I need to use devstack or something?
07:44:34 <mahatic> +1
07:44:47 <mattoliverau> can it grow other swift metrics? ie, maybe intergrate x-profier into it
07:44:49 <acoles> tovin07_: what is different about the swift middleware vs middleware for other projects? just curious that there isn't a single generic middleware for all services?
07:45:03 <psachin> tovin07_: Thats great. Thanks.
07:45:14 <hieulq> mattoliverau, just enable it via swift configuration file and use OSC cli along with --profile option
07:45:31 <mattoliverau> cool
07:46:16 <acoles> hieulq: but presumably there is some infrastructure needed for osprofiler to gather/publish metrics?
07:46:17 <mattoliverau> acoles: I assume it needs to intergrate into project specific things, like our db calls etc
07:46:43 <tovin07_> acoles, i don't quite understand your question, can you make it clearer
07:46:51 <hieulq> acoles, default is rabbitmq, but you can use ceilometer, redis, mongodb, ELK..
07:47:02 <mattoliverau> hieulq, tovin07_ : swift can also output statsd, I wonder if we can get performance metrix out via there too.
07:47:38 <acoles> tovin07_: it may be a stupid question ;) but for example with keystone we just include keystonemiddleware same as every other project, but here we have a swift specific middleware implementation
07:47:52 <hieulq> acoles, here is the list of backend drivers now: https://github.com/openstack/osprofiler/tree/master/osprofiler/drivers
07:48:01 <kota_> hieulq: neither of those are used in swift in default
07:48:31 <acoles> hieulq: thanks
07:48:35 <hieulq> mattoliverau, yeah, we may do it in next cycles
07:49:08 <tovin07_> acoles, oh yes, because of dependencies --> I have to "custom" osprofiler middleware a little bits for swift
07:49:26 <acoles> tovin07_: got it, makes sense
07:50:03 <hieulq> kota_, yes, but if users used swift as back-end or along with other projects, we have rabbitmq as default
07:50:21 <acoles> tovin07_: so what do you need at this point in time? is the patch ready for reviewing?
07:50:51 <hieulq> and in case we use swift stand-alone, at least users need redis/mongo/etc to store the traces
07:50:54 <tovin07_> acoles, yes, it is ready for reviewing now
07:51:45 <acoles> ok community, take note and pls review if you can ^^
07:52:01 <hieulq> thanks :)
07:52:40 <mattoliverau> ok.. so I don't have redis or mongo.. so thatll be an extra stumbling block for me. but i'll try and loop round to it when I get some time.
07:52:43 <tovin07_> acoles, thanks :D
07:52:59 <mattoliverau> if only there was a swift driver :P
07:53:13 <acoles> tovin07_: it will help reviewers if there is a doc somewhere showing how to set up the other infrastructure (rabbitmq or whatever is simplest) - not all swift devs are familar with installing other openstack services since swift often runs standalone (or with only keystone)
07:53:37 <kota_> mattoliverau: +1
07:53:49 <mahatic> acoles: yup, +100
07:53:52 <kota_> mattoliverau: it seeems to make us easy to test in functional or probe
07:54:02 <mattoliverau> kota_: yeah
07:54:03 <tovin07_> acoles, yes, for simplest case, you can test it with redis or mongodb
07:54:17 <acoles> ok, time is passing - thank you tovin07_ and hieulq for coming along to discuss osprofiler
07:54:32 <mattoliverau> yeah thanks hieulq  and tovin07_
07:54:37 <acoles> #topic priority reviews
07:54:43 <hieulq> thanks guys
07:55:01 <acoles> very quickly, do we have any updates on progress on these patches...
07:55:18 <acoles> Make eventlet.tpool's thread count configurable in...
07:55:18 <acoles> #link https://review.openstack.org/#/c/289664/
07:55:39 <mattoliverau> I've pushed up a new version. but still doing a bit of testing as I was getting the wrong behaviour on my SAIOs..
07:55:42 <acoles> mattoliverau: cschwede did you get chance to look at that?
07:55:50 <acoles> mattoliverau: oh, great, thanks!
07:56:05 <mahatic> mattoliverau: nice
07:56:22 <acoles> This one we discussed at last 0700 meeting has merged ... ssync failing to sync expired object
07:56:22 <acoles> #link https://review.openstack.org/#/c/456921/
07:56:33 <acoles> but rledisez is fixing another ssync bug
07:56:49 <acoles> #link https://review.openstack.org/472659
07:56:50 <acoles> which is for bug
07:56:50 <acoles> #link https://launchpad.net/bugs/1652323
07:56:51 <openstack> Launchpad bug 1652323 in OpenStack Object Storage (swift) "ssync syncs an expired object as a tombstone" [Medium,Confirmed]
07:56:54 <rledisez> yep. i have the bugfix, i need to write tests
07:57:00 <acoles> rledisez: do you need reviews/help?
07:57:08 <acoles> rledisez: ok :) tests!
07:57:19 <acoles> rledisez: I'll try to help with that
07:57:35 <rledisez> better to wait i wrote tests i think, but the patch is really small so if you want to have a look, it's good to see if i'm in the right direction
07:57:45 <mattoliverau> If I have some time later this week, I'll loop round and try and take a look.. but can't promise atm.
07:57:51 <acoles> rledisez: name_lookup/domain_remap bugs - any more bugs to fix there?
07:58:09 <rledisez> one to come, but not pushed yet. and also i"'ll work on func test soon
07:58:10 <acoles> rledisez: ack I will wait for you to push another version of patch - first glance it looked ok
07:58:25 <rledisez> acoles: ok, good to know, thx
07:58:44 <acoles> ring part power increase
07:58:44 <acoles> #link https://review.openstack.org/#/c/337297/
07:58:44 <acoles> any progress?
07:58:48 <acoles> cschwede: ^^ ?
07:59:13 <mattoliverau> we should just merge the damn tihing ;)
07:59:16 <mahatic> looks like cschwede is not around
07:59:41 <mattoliverau> last i heard tim was going back and forward on it, but that was quite a whle ago
07:59:46 <acoles> ok, NM, well time is up anyway
07:59:55 <acoles> #topic next meeting
07:59:55 <acoles> Next 0700UTC meeting will be on June 28th
07:59:55 <acoles> Next 2100UTC meeting is today
07:59:58 <rledisez> thx acoles for chairing :)
08:00:05 <mattoliverau> +1
08:00:11 <acoles> rledisez: thanks! phew
08:00:14 <kota_> thanks acoles
08:00:17 <jeffli> Good night rledisez
08:00:23 <acoles> thank you for coming and working on swift
08:00:29 <acoles> #endmeeting