17:00:23 <Kiall> #startmeeting Designate
17:00:24 <openstack> Meeting started Wed Jul  9 17:00:23 2014 UTC and is due to finish in 60 minutes.  The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:27 <openstack> The meeting name has been set to 'designate'
17:00:34 <Kiall> Heya - Who's here?
17:00:35 <mugsie> o/
17:00:38 <vinod1> o/
17:00:39 <rjrjr_> here
17:00:44 <betsy> o/
17:00:45 <jaycaz> i'm here!
17:00:50 <timsim> hey
17:00:50 <eankutse> o/
17:01:05 <Kiall> #topic Action Items from last week
17:01:21 <Kiall> So - None recorded - was anything not recorded?
17:01:31 <mugsie> dont think so
17:01:36 <Kiall> Okay - Easy :)
17:01:46 <Kiall> #topic Release Management Changes
17:02:13 <Kiall> So - I have a weekly 1:1 with ttx now, and one of things we discussed was him taking over our release management
17:02:34 <eankutse> who is ttx?
17:02:38 <Kiall> So - Starting with juno-2 he'll be handling our releases
17:02:45 <Kiall> Thierry - OpenStack Release Manager
17:02:53 <timsim> Cool.
17:02:54 <eankutse> thx
17:03:09 <Kiall> So - What does that mean for us?
17:03:18 <Kiall> Well - No more missed/late releases :)
17:03:23 <Kiall> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:03:33 <eankutse> cool :-)
17:03:33 <Kiall> juno-2 is due July 24th
17:03:45 <Kiall> 2 weeks and 1 day away
17:04:19 <Kiall> We'll want to focus on items which are important for that release, and are achievable for that date
17:04:41 <Kiall> I'd personally like to see all of jaycaz's doc fixes/changes merged, and betsy's RecordSet API change merged.
17:05:15 <Kiall> Does anyone have any other items they think we we should push for in j2?
17:05:17 <mugsie> Kiall: does that mean he is taking over the targeting of bp / bugs as well?
17:05:32 <mugsie> or do we target, and he deals with them as they go forward?
17:05:35 <Kiall> mugsie: no, he'll mark them "Fix Released" etc
17:05:41 <mugsie> k
17:05:43 <Kiall> but it's up to us to triage and target
17:05:47 <Kiall> Speaking of that...
17:05:51 <Kiall> We're doing it wrong :)
17:06:05 <Kiall> e.g. https://bugs.launchpad.net/designate/+bug/1319112
17:06:07 <uvirtbot> Launchpad bug 1319112 in python-designateclient "Admins can't see all domains in domain-list" [High,Triaged]
17:06:20 <Kiall> In the table at the top, it should not be "Status tracked in Juno"
17:06:31 <Kiall> there's a button we press to make that happen.. We should stop
17:06:42 <mugsie> yeah - that is only if we are backporting a fix isnt it?
17:07:03 <Kiall> Yea, that's only for targeting to older releases
17:07:30 <Kiall> So - anyone have any other items they think we we should push for in j2?
17:07:50 <betsy> I’m almost finished porting over the reports, but not a big deal if it doesn’t get in
17:07:58 <Kiall> betsy: cool :)
17:08:12 <vinod1> what about https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-functional
17:08:25 <vinod1> I am close to getting done with it
17:08:39 <Kiall> vinod1: if you think you'll have in done in the next 1.5 weeks or so - Yea, I think it's worth including.
17:09:11 <vinod1> yes i will have it done - at least submitted for review - the rest is up to you :-)
17:09:23 <Kiall> Great - OK
17:09:58 <Kiall> Let's move on then, and we'll circle back to j2 tasks again next week. (I'd actually like to make that a standing agenda item from now on)
17:10:16 <Kiall> #topic Division of labor for server pools
17:10:28 <Kiall> vinod1 / mugsie - over to you guys
17:10:46 <mugsie> yup -  I asked for people to let me know if they were interested
17:10:57 <vinod1> I wanted to check if the server pools was ready to be divided up?  I know rjrjr mentioned earlier that they would be working on it
17:11:11 <betsy> Oh, I’m interested BTW
17:11:14 <mugsie> i have had one responce - rjrjr_ & I updated the work items in the review
17:11:36 <betsy> Sorry. Just realized I never responded to your email.
17:11:45 <mugsie> np
17:12:15 <mugsie> I have an idea for how we do it, and it is going ot be part of the sub team stuff I will be sending out tonight
17:12:26 <vinod1> thanks for the update mugsie - are any of the server pool items blocked by mdns?
17:12:31 <Kiall> #link https://review.openstack.org/#/c/101298/
17:12:43 <mugsie> some of it is
17:12:59 <mugsie> but there is more than enough stuff for us to do before
17:13:23 <Kiall> Yea, I think mdns is close enough that starting pools stuff wouldn't be wasted
17:13:35 <mugsie> nope
17:13:42 <mugsie> thing like the basic services etc
17:13:57 <mugsie> can be started, and we can plug in mdns stuff as it comes along
17:15:21 <timsim> Cool, so email coming this evening, and we'll get started on it in parallel.
17:15:34 <mugsie> yup
17:15:48 <betsy> cool
17:15:49 <rjrjr_> cool. 8^)
17:16:07 <Kiall> mugsie: the BP list the workitems, but they don't seem to be in any particular order. Maybe reordering into the order they can be started?
17:16:29 <Kiall> Or I suppose that's what the LP graph is for
17:18:12 <Kiall> Testing?
17:18:20 <Kiall> Whey - working again
17:18:25 <mugsie> sorry - back
17:18:38 <Kiall> Seems the internet fell over for a minute
17:18:55 <mugsie> yeah, my sshd session died as well
17:18:56 <Kiall> Okay - Unless there's anything else, we'll move on
17:18:58 <timsim> Alright, I think we can move on. You didn't miss anything :)
17:19:21 <Kiall> #topic SOA records - making them visible and editable in v2
17:19:27 <Kiall> #link https://etherpad.openstack.org/p/soa-records
17:19:32 <betsy> So, I apologize — I didn’t see the bp for this
17:19:37 <Kiall> #link https://review.openstack.org/#/c/100901/
17:19:44 <betsy> But I started thinking about it...
17:19:44 <Kiall> betsy: no problem :)
17:20:05 <betsy> And I don’t see how the SOA record can be represented as a recordset. There’s no overlappying data between the two
17:20:38 <betsy> I was thinking, the necessary fields could be edited through domains
17:20:44 <betsy> Since that’s where they’re stored
17:20:54 <betsy> And we make an object with all the values to pass to mdns
17:21:10 <Kiall> So, my BP and your etherpad suggest different approaches.
17:21:21 <betsy> Right. I should have made the comments in the bp
17:21:30 <betsy> But didn’t see it
17:21:42 <betsy> Only saw the bug to make SOA and NS records visible in v2
17:22:06 <betsy> So, you’re right. I’m suggesting a different approach
17:22:06 <Kiall> My approach was to have fields editable on the domain (in the future), and generate the SOA Record/RecordSet when changes are made to the Domain row. That way, mDNS and the API simply sees another record.
17:22:24 <Kiall> And - We introduce a "read-only" flag on recordsets, preventing customers from editing that RRSet directly
17:23:02 <betsy> So just put all the SOA fields — refresh, retry, expire, etc in the data field?
17:23:12 <vinod1> kiall: with your approach would the api for domains be altered to include the soa information?
17:23:46 <Kiall> vinod1: I didn't address that in my BP, leaving that part for another BP.
17:23:55 <Kiall> But - In theory, they could just be exposed and made editable.
17:24:09 <Kiall> Any change would cause Designate to internally regenerate the SOA record
17:24:28 <betsy> And stored in the Recordset/Records table?
17:24:42 <Kiall> Yes - Alongside the RRSets/Records
17:25:18 <Kiall> Which means no special casing is needed in the backends/mDNS for it - and the API can be updated to support a generic "read-only" flag on RRSets
17:25:57 <eankutse> That sounds good
17:25:59 <betsy> So everything goes in the data field?
17:26:37 <eankutse> Kiall: who would be allowed to set the "read-only" flag?
17:26:41 <Kiall> betsy: Yes, a copy of the data anyway, and eventually when we split the records table into per-type tables, each component would be in it's own column
17:26:49 <vinod1> so when and how would the SOA rrset be modified if it is marked as read only?
17:27:02 <Kiall> eankutse: Designate itself - i.e. the system.
17:27:10 <eankutse> ok
17:27:11 <betsy> So we’ll be storing the same data in multiple db tables
17:27:41 <betsy> vinod1: thru changes to the domain
17:27:49 <Kiall> betsy: yea, there's advantages and disadvantages to that :) 2 copies of the data vs having anything that needs the SOA to special case building it up
17:28:24 <betsy> Seems easy enough to write a call to create an internal only SOA record
17:28:28 <Kiall> We read-only would apply to end users (and admins..) Designate, internally, would be able to regenerate the SOA record as changes to the Domain row are made
17:28:39 <Kiall> betsy: yea, I hope so :)
17:29:06 <betsy> kiall: I mean without actually storing it in the recordset table
17:29:14 <betsy> recordset/records tables
17:29:50 <betsy> What’s the advance to storing it in the tables rather than creating it every time?
17:29:53 <Kiall> Oh - Well, then mDNS and the API and the backends would have to do a "Get me all records and the Domain, then, Build a pseudo SOA record and merge it into the records
17:30:06 <Kiall> vs simply "Get me the records"
17:30:07 <betsy> Central could have a call that did that
17:30:40 <Kiall> We could, but things start getting real complex with paging and sorting etc
17:30:50 <betsy> I guess my db background is just objecting to having the data stored in two places
17:31:05 <Kiall> Does the SOA record, when sort by record.type is applied, appear on page 1, 2 or 8? etc
17:31:06 <betsy> But I can live with it if that’s what we want to do
17:31:33 <Kiall> Well - Here's another option..
17:31:34 <mugsie> de-normalisation isn't always a bad thing ;)
17:31:45 <Kiall> Have the RRSet be the home for it, and remove them from the Domain altogether?
17:31:45 <betsy> I was thinking it would be a separate call to get the SOA apart from the other records
17:31:59 <rjrjr_> kiall: i agree with that.
17:32:10 <betsy> No. Don’t put them in the recordset/records
17:32:26 <Kiall> betsy: yea, but on which page of the API results should you make that call on? And, where in the current page? Should it be at the start/middle/end of the page etc?
17:32:46 <betsy> True. Ok.
17:33:03 <vinod1> kiall: another option - we could remove it from the domain, once we have the different records in their own tables - so that it is easier to get to the various soa fields
17:33:10 <Kiall> betsy: Well .. Storing them on the domain is a little weird, since they are only used as part of the SOA.. But, I think that's a bigger change
17:33:12 <Kiall> vinod1: ++
17:33:17 <rjrjr_> SOA is just a record type.  it should be in the recordset/record tables.
17:33:23 <betsy> kiall: _1
17:33:26 <betsy> +1
17:33:32 <Kiall> I thought that was a -1 ;)
17:33:43 <betsy> Nope :D
17:34:02 <Kiall> Either way - I think a good first step is to simply expose the record in the API - read only - with the source of truth being the domains table
17:34:35 <betsy> Agreed
17:34:36 <Kiall> the source of truth can then be moved, and eventually, the access from the "domain" resource can be removed if we decide we want to do that
17:35:59 <Kiall> Okay .. If there is nothing else, let's move on?
17:36:30 <Kiall> #topic Open Discussion
17:36:35 <Kiall> I have 2 today that didn't warrant a "whole agenda item"... :)
17:36:52 <Kiall> mugsie: hows that oslosphinx stuff looking? Has the second change merged?
17:36:57 <mugsie> yup
17:37:04 <Kiall> and - have you talked to dhellmann about maybe getting a final release :D
17:37:15 <mugsie> tried to get hold of dhellmann yesterday, but he wasnt around
17:37:23 <mugsie> i think he is on atm actually
17:37:28 <mugsie> will grab him after this
17:37:35 <Kiall> Maybe he'll see our mentions :)
17:38:04 <Kiall> Okay - Well, if you can keep on top of it :)
17:38:21 <mugsie> yup
17:38:22 <Kiall> The second I had was - betsy's recordset change and my update's should use objects change.
17:38:27 <Kiall> They conflict like hell.
17:38:30 <mugsie> haha
17:38:38 <betsy> how’s that going?
17:39:16 <Kiall> betsy: I spent almost all day fighting a fire today, but I intent on having it rebased before you wake up tomorrow
17:39:26 <Kiall> intend*
17:39:41 <betsy> Nice
17:39:46 <betsy> I’ll be very impressed
17:39:51 <Kiall> I think the biggest issue is that the obejcts aren't playing nice with having recordset.records = [{},{},{}]
17:39:58 <vinod1> kiall: there are a bunch of object changes for review - do you want them approved and merged if necessary or wait till you try to get the conflicts resolved?
17:40:46 <Kiall> So - I started down this route - https://review.openstack.org/#/c/105021/7 combined with https://review.openstack.org/#/c/105038/
17:40:50 <vinod1> if you can −1 the changes that you do not want merged - that would be helpful
17:41:12 <Kiall> That would do the recordset.records = [] in a "Objects friendly way", which would hopefully make it easier..
17:41:29 <Kiall> vinod1: I think I've -2'd everything I don't think is ready
17:41:36 <vinod1> thanks kiall
17:42:16 <Kiall> betsy: did you have a look at either of those reviews of out curisoity?
17:42:27 <betsy> No, but I can today
17:42:49 <Kiall> They attempted to get the notion of a "ListObject" in, and the second attempted to make the storage layer play nice with that and populate recordset.records = ..
17:43:28 <betsy> Okay. Let me take a look
17:43:56 <Kiall> I was hoping it would be easier, then with that being "objects" friendly your code would be easier to rebase.. I had to give up at the time though.. it was midnight ;)
17:44:06 <Kiall> Anyway - That's it from me..
17:44:17 <Kiall> Anyone else have an off-agenda item?
17:44:39 <jaycaz> i do
17:45:00 <jaycaz> there's a small feature that I was looking to implement but I wanted to see what you guys thought of it
17:45:01 <jaycaz> https://blueprints.launchpad.net/designate/+spec/zone-and-record-totalcount
17:45:54 <jaycaz> It's about adding a totalEntries value to the view for zones and recordsets that will list the total number of items, even when the collection is paginated
17:46:21 <Kiall> From memory, we talked about that before.. And wrote it off as too big a change, as it would have required changes at every level in order to pass the info back out to to the API
17:46:33 <Kiall> But - Funny enough - https://review.openstack.org/#/c/105021/7 gives us that place :)
17:47:06 <Kiall> Now, since we would be returning our own objects rather than python lists, we have somewhere to "hold" that info
17:47:09 <jaycaz> are you sure it's a really big change?  don't the count_domains and count_recordsets methods help with that?
17:47:52 <betsy> those are in the reports extenstion that I’m porting over to v2
17:47:54 <Kiall> Well, an example would have been.. find_recordsets() - that currently returns a simple list, and it would have had to be updated to support returning (metadata, list)
17:48:04 <Kiall> which would have to happen at every level of the stack
17:48:14 <Kiall> 100's of places
17:48:45 <Kiall> But... If we merged #105021 - that wouldn't be necessary anymore, and is one of the things I really like about the Objects
17:48:49 <Kiall> they save us from all that crap :)
17:49:07 <Kiall> e.g. https://review.openstack.org/#/c/105021/7/designate/objects/domain.py
17:49:49 <Kiall> There's the "DomainList" class, which is the return from the storage layer when you do a find_domains() - more info + methods can be added to the ListBaseObject to handle things like totalCount, currentOffset etc
17:50:52 <timsim> jaycaz has a WIP thing he has as a POC, and just looking at it on his computer real quick, it seems to work. He gets the information in the controller and passes it to the view to return. Might be inefficient or something.
17:50:57 <Kiall> Anyway - in case it's not obvious - I'd like to see that kinda info exposed, so long as we can do it clenly.
17:51:18 <Kiall> cleanly*
17:51:33 <jaycaz> ah, makes sense
17:51:39 <Kiall> So - API makes two calls to central? 1 for the results, 1 for the counts?
17:51:53 <jaycaz> yes, that's what I have as a prototype, anyway
17:52:17 <jaycaz> not sure if that counts as clean…
17:52:23 <timsim> probably not :p
17:52:28 <Kiall> :D
17:52:45 <jaycaz> well, if you think it's worth looking into, I'd be glad to take it on
17:52:54 <jaycaz> otherwise, I could look into other features to implement
17:52:56 <Kiall> jaycaz: I could talk to you after about how that might work with #105021 ? It's actually one of the things I had in my head while writing that
17:53:05 <Kiall> But only made allowances, didn't implement it
17:53:29 <Kiall> (since we have 5 mins left, want to open to anyone else's topics!)
17:53:32 <rjrjr_> are we still meeting at the end of July?
17:53:35 <jaycaz> Kiall: sure thing, I'd be glad to talk about it
17:53:43 <Kiall> rjrjr_: ah yes, you missed last week's meet
17:53:47 <Kiall> we are - can you make it?
17:53:58 <rjrjr_> i can.  just need to know when and where.
17:54:05 <Kiall> Let me dig out the email
17:54:09 <rjrjr_> did you send out email?
17:54:14 <Kiall> #topic http://lists.openstack.org/pipermail/openstack-dev/2014-July/039509.html
17:54:14 <mugsie> rjrjr_: I did
17:54:21 <Kiall> lol
17:54:22 <Kiall> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039509.html
17:54:27 <Kiall> #topic Open Discussion
17:55:09 <Kiall> rjrjr_: not mentioned in the email - but we're planning to do a dinner on Sunday 27th
17:55:10 <rjrjr_> mugsie: can you resend me the email?  i missed it.
17:55:20 <Kiall> rjrjr_: it was to the mailing list - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039509.html
17:55:37 <eankutse> BTW, eankutse will be remote
17:55:42 <rjrjr_> need to sign up for that. 8^)
17:55:46 <Kiall> :D
17:55:47 <mugsie> rjrjr_: I will forward ti on to you
17:55:59 <timsim> vinod1 and I will be there.
17:56:11 <Kiall> and myself / mugsie
17:56:36 <mugsie> cool - betsy you were remote weren't you?
17:56:46 <betsy> yes
17:56:49 <mugsie> cool
17:56:53 <betsy> I’ll send you an email asking for an invite
17:57:01 <betsy> for google hangouts
17:57:04 <Kiall> Okay - Anything else? Clock is ticking :)
17:57:39 * Kiall takes that as a no
17:57:41 * mugsie is good
17:57:49 <eankutse> nothing
17:57:55 <Kiall> jaycaz: give me 5 and I'll be back in #openstack-dns
17:57:59 <rjrjr_> i'm good.
17:58:02 <jaycaz> Kiall: sure thing!
17:58:14 <Kiall> Thanks all
17:58:16 <Kiall> #endmeeting