18:00:10 <cp16net> #startmeeting trove
18:00:11 <openstack> Meeting started Wed Nov 11 18:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is cp16net. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:14 <openstack> The meeting name has been set to 'trove'
18:00:22 <cp16net> #topic whos here?
18:00:32 <cp16net> howdy yall
18:00:35 <imandhan> o/
18:01:35 <johnma> hello
18:02:59 <cp16net> short list
18:03:31 <cp16net> i guess others are busy or dont realize the time change :-P
18:03:51 <cp16net> even after 2 weeks hehe
18:04:06 <SlickNik> heh
18:04:29 <SlickNik> yes it does.
18:04:44 <vkmc> o/
18:04:54 <vkmc> heyo
18:05:04 <cp16net> alright well there are a few of us here now
18:05:14 <SlickNik> hi there!
18:05:25 <cp16net> #topic pulse update
18:05:27 <SlickNik> amrith's at usenix
18:05:31 <cp16net> #link https://etherpad.openstack.org/p/trove-pulse-update
18:05:41 <cp16net> #link http://bit.ly/1VQyg00
18:05:41 <SlickNik> evangelizing trove — so we can excuse him.
18:06:08 <cp16net> yeah amrith will catch up later
18:06:29 <cp16net> we had a good up tick on reviews this past week
18:07:02 <peterstac> o/
18:07:31 <cp16net> thanks for everyones effort there
18:08:12 <cp16net> any other questions concerns there?
18:08:42 <cp16net> i have a few topics that are related to the reviews
18:09:04 <peterstac> I do notice that the 'open reviews' graph is just getting bigger
18:09:28 <cp16net> yeah we are growing in size there
18:09:42 <peterstac> Now that we don't automatically 'abandon' old/contested changesets, they just sit around
18:10:53 <cp16net> and if they get stale and not rebased they may be there for a while
18:11:05 <dougshelley66> o/
18:11:34 <vgnbkr> o/
18:11:43 <atomic77> o\
18:11:58 <cp16net> we should look at the value of the changes and help them through if they just need a rebase or something
18:11:58 <peterstac> Yeah - I understand that we can filter them out of our views, but then how's that different from 'auto-abandoning' them? ;)
18:13:43 <cp16net> i think this slightly leads to the next topics reguarding reviews
18:14:02 <cp16net> #topic Mitaka 1 - Dec 1-3 (3 weeks away)
18:14:18 <cp16net> seems crazy but its coming up quickly
18:14:34 <cp16net> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
18:14:58 <vkmc> yeah :|
18:15:20 <peterstac> Is there a link to the bugs/bps earmarked for mitaka-1 ?
18:15:26 <cp16net> I'd like to see the specs we are planning on completing in Mitaka up and reviewed by this time frame
18:15:54 <cp16net> peterstac: good question. i think some of them are marked in launched pad
18:16:01 <peterstac> Sounds reasonable
18:16:35 <cp16net> i dont want what we had last time where we were approving specs at the last minute and pushing lots of code at the end of the cycle
18:17:31 <cp16net> i'll look into making sure the bp are updated in launchpad so that we have an idea of which ones we are looking at getting done
18:18:08 <cp16net> #action cp16net update the bps in launchpad for mitaka
18:18:35 <cp16net> any questions about mitaka-1?
18:19:28 <dougshelley66> cp16net so we should make sure that any specs targeted for mitaka are up for review before mitaka-1?
18:20:00 <dougshelley66> I see 11 BPs for mitaka ATM
18:20:09 <cp16net> dougshelley66: thats what i'd like to see
18:20:14 <johnma> so does that mean the spec needs to be approved by mitaka-1 ?
18:20:39 <cp16net> i'd like to see the specs approved
18:20:43 <dougshelley66> i believe this is the current list- https://blueprints.launchpad.net/trove/mitaka
18:21:00 <johnma> ok, good to know. Thanks cp16net
18:21:08 <peterstac> #link https://blueprints.launchpad.net/trove/mitaka
18:21:31 <cp16net> if they come alittle late i think we can manage if they are not refactoring everything
18:21:34 <cp16net> :-P
18:22:09 <cp16net> but i think this would help moving forward
18:22:44 <cp16net> because i know there is a ton of work todo
18:22:48 <imandhan> How do I tag a bp for mitaka? Just the milestone?
18:22:57 <cp16net> yeah milestone
18:23:22 <imandhan> thanks
18:24:00 <cp16net> so moving on...
18:24:05 <cp16net> #topic Lets get the stable/liberty and kilo patches reviewed
18:24:22 <cp16net> we have a couple patches that need to land for kilo and liberty
18:24:57 <cp16net> so not everyone can approve these but i just want everyopne to be aware
18:25:25 <cp16net> we should work on getting these merged
18:25:41 <peterstac> cp16net, I think most of those have been reviewed (for a while now)
18:25:56 <cp16net> if other patches are found that need to be backported lets get them up there
18:25:59 <peterstac> I'm not sure who we need to 'push' to get them approved ...
18:26:14 <cp16net> yeah there is a short list of people that can approve them
18:26:35 <cp16net> the stable maintainence team
18:27:14 <dougshelley66> cp16net is there something specific you would like us to do?
18:27:32 <cp16net> review them if you havnt
18:27:41 <cp16net> :)
18:27:45 <dougshelley66> ok
18:28:51 <cp16net> not much else on that topic
18:28:57 <peterstac> Looks like some of them are failing on py27
18:28:58 <cp16net> #topic adding reno support
18:29:39 <cp16net> peterstac: they may need a rebase
18:29:40 <peterstac> we may have to back-port this as well
18:29:46 <peterstac> #link https://review.openstack.org/#/c/236015/
18:30:08 <peterstac> cp16net, sure, that's possible too
18:30:16 <cp16net> hey i saw that error today :-P
18:30:21 <cp16net> lol
18:30:50 <peterstac> yeah, that was my fault (from back in my noob days :D )
18:31:06 <cp16net> its all good:)
18:31:13 <peterstac> (I'm trying to redeem myself with the fix)
18:31:17 <cp16net> so reno support...
18:31:37 <cp16net> just wanted to fill everyone in on what reno
18:32:16 <cp16net> so the openstack release team was being back logged with creating the release notes from launchpad
18:32:52 <cp16net> so they are having everyone move to the release notes in the file tree
18:33:09 <cp16net> so that they can be generated from code for each project
18:34:00 <cp16net> i have 1 patch up and still need to get the others up for stable/liberty
18:34:43 <cp16net> then there is a job that should run also reguarding reno
18:34:54 <cp16net> here is a email info link
18:34:58 <peterstac> So that would mean (once the changeset lands) that anything 'release note' worthy would have to be added to releasenotes/source/liberty.rst ?
18:35:03 <cp16net> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
18:35:11 <peterstac> (or mitaka, etc.)
18:35:50 <cp16net> peterstac: i think that would be the case
18:36:18 <cp16net> since this is still a bit new i think we are learning as we go
18:37:41 <imandhan> So basically moving forward as new features/bps get implemented, we should remember to add a line in release notes for that cycle?
18:37:59 <cp16net> i'd say lets keep doing the same thing we've done
18:38:46 <cp16net> and then once i/we get a better understanding of the expectation on this file then we can change how we approach this change int he release notes
18:38:55 <cp16net> sound good?
18:38:59 <peterstac> cp16net, by that you mean using DocImpact tags?
18:39:20 <cp16net> yeah that shouldnt be changing
18:39:29 <cp16net> thats for documentation notes
18:39:44 <dougshelley66> so what were we doing previously related to release notes
18:39:54 <cp16net> it was manaully being done
18:40:26 <cp16net> i'll follow up next week with this and get more info
18:40:28 <dougshelley66> but was there some sort of trigger on a bug or a commit to tell someone to manually add to relnotes
18:40:29 <peterstac> Ah, I didn't know we had a process around that ;)
18:40:46 <cp16net> i think there are a lot of questions that i dont know the answer to yet :-P
18:40:53 <dougshelley66> ah ok np
18:41:20 <cp16net> and i want to make sure we have time for this next topic.
18:42:02 <cp16net> so if anyone has further questions reguarding reno let me know in the trove channel
18:42:13 <cp16net> #topic datastore log operations blueprint
18:42:23 <cp16net> #link https://review.openstack.org/#/c/188168/
18:42:34 <cp16net> so there is this bp that has been reviewed a few times
18:43:29 <cp16net> but there was a conern in particular that was brought up regaurding the swift containers
18:44:12 <cp16net> i'd like more feedback from others on what they think about this...
18:44:42 <cp16net> 1. creating a container for each instance to hold the logs when a user requests them
18:44:44 <peterstac> right now, the proposal is to have a container for each log file requested
18:45:12 <cp16net> 2. creating a single container for the tenant that will hold the logs when the user requests them
18:45:24 <peterstac> having a single container would require filtering the files in the container, as a log could be made up of an unknown number of different files
18:45:51 <vgnbkr> Since each "log" can consist of a very large number of individual swift objects, it seemed prudent to put a single log, composed of many objects, in a single container.
18:46:17 <cp16net> peterstac: wait so this is going even further and saying that each file a user requests creates a new container?
18:46:46 <SlickNik> Does swift have limits on the number of files per container or max number of containers? How well do the variables in each case scale?
18:47:25 <peterstac> Each log file has its own container, not each request for a log file
18:48:10 <cp16net> so each log per instance creates a conatiner
18:48:22 <peterstac> SlickNik, I don't know about Swift limits (have to look that up)
18:48:37 <notmyname> SlickNik: no, not as a default. but there are recommendations for per-container number of objects based on deployment choices
18:49:07 <notmyname> SlickNik: there is a config option for max containers per account, but it's set to unlimited by default
18:49:07 <peterstac> cp16net, the first time you run log-publish on a log it will create a new container
18:50:03 <SlickNik> notmyname: awesome — thanks for the info.
18:50:04 <peterstac> notmyname, thanks for the info! (saves me some search time!)
18:50:28 <vgnbkr> Since each "log" consists of many swift objects, if all the logs were to share a single container, there would potentially be a phenomenally large number of objects in that contain.  It would be pretty much unmanagable for the user to look at the contents of that container.
18:50:45 <cp16net> so i could see a few different ways that this would work with a single container.
18:51:10 <cp16net> so within swift you can make sudo folders that would store the log files for each instance
18:51:35 <cp16net> or prefix the logs
18:52:54 <cp16net> peterstac: another question... do the containers eventually go away when the files expire?
18:53:15 <peterstac> The files are set to expire - I don't know that the containers do
18:53:47 <peterstac> (that would be another question for notmyname - can containers be set to 'disappear' once all the files expire)
18:53:57 <vgnbkr> The container will be removed when the log is deleted.
18:54:13 <cp16net> because as a user i'd wonder why i have so many containers i have to sift through to find the one i'm looking for
18:54:42 <dougshelley66> maybe we need "protected" or "locked" swift containers :)
18:55:08 <notmyname> peterstac: no. you'd end up with an empty container
18:55:17 <cp16net> dougshelley66: i dont think that would help
18:55:33 <dougshelley66> cp16net...it was kind of a joke/reference to our convo at summit...
18:55:49 <cp16net> ahh :-P
18:55:54 <SlickNik> dougshelley66: you have me in splits here :P
18:56:06 <dougshelley66> I try...
18:57:07 <cp16net> so do we have suggestions either way?
18:57:33 <peterstac> cp16net, I'll look into having a 'folder' within the Swift container
18:58:02 <cp16net> or am i alone on thinking that multiple containers seems like a bad idea
18:58:06 <peterstac> and see if that's fairly easy to implement ...
18:58:21 <cp16net> we use 1 container for all the backups
18:58:31 <cp16net> i think we should use 1 for logs
18:58:44 <atomic77> the only way i can see this being important is if swift, internally, thinks of its objects as basically a key:obj in some large keyspace, and the container is just a 'convenience prefix'
18:58:45 <cp16net> i dont think we should use the same one nessesarily
18:59:41 <cp16net> i think we are getting close on time here
19:00:14 <cp16net> i would like to continue this in the trove room
19:00:31 <atomic77> cp16net, ok i'll continue there :)
19:00:33 <cp16net> i'll end it.
19:00:36 <cp16net> #endmeeting