Wednesday, 2013-08-21

*** sacharya has joined #openstack-meeting-alt00:27
*** NehaV has joined #openstack-meeting-alt00:31
*** yidclare has quit IRC00:34
*** NehaV has quit IRC00:40
*** anteaya has quit IRC01:11
*** NehaV has joined #openstack-meeting-alt01:18
*** NehaV has quit IRC01:25
*** NehaV has joined #openstack-meeting-alt01:25
*** jmaron has quit IRC01:29
*** vkmc has quit IRC01:41
*** jmaron has joined #openstack-meeting-alt02:00
*** markwash has joined #openstack-meeting-alt02:04
*** markmcclain has quit IRC02:06
*** jmaron has quit IRC02:07
*** amytron has joined #openstack-meeting-alt02:09
*** tanisdl has quit IRC02:19
*** NehaV has quit IRC02:45
*** markwash has quit IRC02:46
*** markwash has joined #openstack-meeting-alt02:53
*** jmaron has joined #openstack-meeting-alt03:04
*** msisk has joined #openstack-meeting-alt03:10
*** jmaron has quit IRC03:12
*** bdpayne has quit IRC03:17
*** mberwanger has joined #openstack-meeting-alt03:34
*** NehaV has joined #openstack-meeting-alt03:41
*** NehaV1 has joined #openstack-meeting-alt03:41
*** NehaV has quit IRC03:45
*** NehaV1 has quit IRC03:49
*** markwash has quit IRC03:50
*** markwash has joined #openstack-meeting-alt03:57
*** sacharya has quit IRC04:00
*** msisk has quit IRC04:09
*** jmaron has joined #openstack-meeting-alt04:09
*** markwash has quit IRC04:12
*** jmaron has quit IRC04:14
*** akuznetsov has joined #openstack-meeting-alt04:16
*** mberwanger has quit IRC04:34
*** NehaV has joined #openstack-meeting-alt04:35
*** mberwanger has joined #openstack-meeting-alt04:38
*** NehaV has quit IRC04:43
*** markwash has joined #openstack-meeting-alt04:51
*** mberwanger has quit IRC05:06
*** markwash has quit IRC05:07
*** enikanorov-w has quit IRC05:08
*** enikanorov-w has joined #openstack-meeting-alt05:10
*** akuznetsov has quit IRC05:28
*** NehaV has joined #openstack-meeting-alt05:30
*** NehaV has quit IRC05:39
*** markwash has joined #openstack-meeting-alt05:43
*** amytron has quit IRC05:55
*** markwash has quit IRC06:03
*** jmaron has joined #openstack-meeting-alt06:10
*** jmaron has joined #openstack-meeting-alt06:10
*** jmaron has quit IRC06:15
*** dmakogon_ has joined #openstack-meeting-alt06:24
*** NehaV has joined #openstack-meeting-alt06:25
*** markwash has joined #openstack-meeting-alt06:29
*** NehaV has quit IRC06:32
*** markwash has quit IRC06:44
*** ruhe has joined #openstack-meeting-alt06:52
*** jmaron has joined #openstack-meeting-alt07:11
*** jmaron has quit IRC07:15
*** markwash has joined #openstack-meeting-alt07:27
*** dmakogon_ has quit IRC07:28
*** dmakogon_ has joined #openstack-meeting-alt07:37
*** markwash has quit IRC07:39
*** boris-42 has joined #openstack-meeting-alt07:42
*** benl has joined #openstack-meeting-alt07:51
*** aignatov has quit IRC08:00
*** aignatov has joined #openstack-meeting-alt08:01
*** dmakogon_ has quit IRC08:11
*** ameade has quit IRC08:11
*** clarkb has quit IRC08:11
*** jeblair has quit IRC08:11
*** ameade has joined #openstack-meeting-alt08:12
*** jeblair has joined #openstack-meeting-alt08:12
*** clarkb has joined #openstack-meeting-alt08:12
*** jmaron has joined #openstack-meeting-alt08:12
*** jmaron has quit IRC08:17
*** markwash has joined #openstack-meeting-alt08:22
*** markwash has quit IRC08:34
*** markwash has joined #openstack-meeting-alt08:48
*** dmitryme has joined #openstack-meeting-alt08:59
*** markwash has quit IRC09:09
*** akuznetsov has joined #openstack-meeting-alt09:11
*** jmaron has joined #openstack-meeting-alt09:12
*** ruhe has quit IRC09:16
*** jmaron has quit IRC09:17
*** dkoryavov has joined #openstack-meeting-alt09:18
*** ruhe has joined #openstack-meeting-alt09:18
*** ruhe has quit IRC09:37
*** akuznetsov has quit IRC09:37
*** akuznetsov has joined #openstack-meeting-alt09:40
*** akuznetsov has quit IRC09:43
*** dmitryme has quit IRC09:45
*** isviridov has quit IRC09:52
*** pcm_ has joined #openstack-meeting-alt10:04
*** pcm_ has quit IRC10:06
*** pcm_ has joined #openstack-meeting-alt10:06
*** boris-42 has quit IRC10:09
*** dmitryme has joined #openstack-meeting-alt10:09
*** jmaron has joined #openstack-meeting-alt10:12
*** akuznetsov has joined #openstack-meeting-alt10:14
*** ruhe has joined #openstack-meeting-alt10:16
*** jmaron has quit IRC10:17
*** benl has quit IRC10:22
*** isviridov has joined #openstack-meeting-alt10:24
*** dmitryme has left #openstack-meeting-alt10:38
*** markmcclain has joined #openstack-meeting-alt10:39
*** sergmelikyan has joined #openstack-meeting-alt10:48
*** SergeyLukjanov has joined #openstack-meeting-alt10:50
*** dkoryavov has quit IRC10:54
*** SergeyLukjanov has quit IRC10:54
*** ruhe has quit IRC10:59
*** ruhe has joined #openstack-meeting-alt11:01
*** SergeyLukjanov has joined #openstack-meeting-alt11:03
*** dina_belova has joined #openstack-meeting-alt11:05
*** jmaron has joined #openstack-meeting-alt11:13
*** jmaron has quit IRC11:18
*** boris-42 has joined #openstack-meeting-alt11:19
*** benl has joined #openstack-meeting-alt11:33
*** benl has quit IRC11:37
*** dosaboy_ is now known as dosaboy_afk11:43
*** dina_belova has quit IRC11:45
*** ruhe has quit IRC12:00
*** SergeyLukjanov has quit IRC12:11
*** pdmars has joined #openstack-meeting-alt12:12
*** jmaron has joined #openstack-meeting-alt12:14
*** jmaron has quit IRC12:18
*** jmaron has joined #openstack-meeting-alt12:24
*** akuznetsov has quit IRC12:31
*** _crobertsrh is now known as crobertsrh12:32
*** akuznetsov has joined #openstack-meeting-alt12:36
*** dosaboy_afk has quit IRC12:55
*** akuznetsov has quit IRC13:01
*** ruhe has joined #openstack-meeting-alt13:04
*** dina_belova has joined #openstack-meeting-alt13:11
*** dina_belova has quit IRC13:12
*** dina_belova has joined #openstack-meeting-alt13:12
*** dina_belova has quit IRC13:17
*** akuznetsov has joined #openstack-meeting-alt13:20
*** eankutse has joined #openstack-meeting-alt13:22
*** eankutse has joined #openstack-meeting-alt13:24
*** eankutse1 has joined #openstack-meeting-alt13:25
*** anteaya has joined #openstack-meeting-alt13:26
*** eankutse has quit IRC13:28
*** NehaV has joined #openstack-meeting-alt13:37
*** amytron has joined #openstack-meeting-alt13:40
*** eankutse1 has quit IRC13:42
*** NehaV1 has joined #openstack-meeting-alt13:45
*** isviridov is now known as isviridov_13:45
*** NehaV has quit IRC13:46
*** ogelbukh has joined #openstack-meeting-alt13:54
*** sirmax has quit IRC13:54
*** sirmax has joined #openstack-meeting-alt13:55
*** eankutse has joined #openstack-meeting-alt14:06
*** isviridov_ has left #openstack-meeting-alt14:10
*** dina_belova has joined #openstack-meeting-alt14:13
*** sacharya has joined #openstack-meeting-alt14:15
*** dina_belova has quit IRC14:17
*** eankutse has quit IRC14:17
*** ruhe has quit IRC14:17
*** eankutse has joined #openstack-meeting-alt14:18
*** eankutse has quit IRC14:21
*** Riddhi has joined #openstack-meeting-alt14:25
*** tanisdl has joined #openstack-meeting-alt14:28
*** sacharya has quit IRC14:32
*** Riddhi has quit IRC14:33
*** akuznetsov has quit IRC14:35
*** sergmelikyan has quit IRC14:45
*** akuznetsov has joined #openstack-meeting-alt14:50
*** eankutse has joined #openstack-meeting-alt14:52
*** rnirmal has joined #openstack-meeting-alt14:53
*** eankutse has quit IRC14:56
*** eankutse has joined #openstack-meeting-alt14:56
*** ruhe has joined #openstack-meeting-alt14:57
*** akuznetsov has quit IRC14:58
*** akuznetsov has joined #openstack-meeting-alt14:59
*** eankutse has quit IRC14:59
*** esker has joined #openstack-meeting-alt15:00
*** eankutse has joined #openstack-meeting-alt15:01
*** NehaV1 has quit IRC15:03
*** jmontemayor has joined #openstack-meeting-alt15:04
*** sacharya has joined #openstack-meeting-alt15:04
*** rnirmal has quit IRC15:10
*** dina_belova has joined #openstack-meeting-alt15:13
*** NehaV has joined #openstack-meeting-alt15:17
*** eankutse1 has joined #openstack-meeting-alt15:18
*** dina_belova has quit IRC15:18
*** eankutse1 has quit IRC15:19
*** eankutse1 has joined #openstack-meeting-alt15:20
*** eankutse has quit IRC15:20
*** NehaV has quit IRC15:20
*** NehaV has joined #openstack-meeting-alt15:21
*** esker has quit IRC15:35
*** yidclare has joined #openstack-meeting-alt15:47
*** NehaV1 has joined #openstack-meeting-alt15:48
*** akuznetsov has quit IRC15:49
*** SergeyLukjanov has joined #openstack-meeting-alt15:49
*** NehaV has quit IRC15:51
*** msisk has joined #openstack-meeting-alt15:53
*** dina_belova has joined #openstack-meeting-alt15:54
*** pcm_ has quit IRC15:56
*** boris-42 has quit IRC15:57
*** ruhe has quit IRC16:05
*** vinodmr has joined #openstack-meeting-alt16:09
*** SergeyLukjanov has quit IRC16:16
*** rnirmal has joined #openstack-meeting-alt16:18
*** ruhe has joined #openstack-meeting-alt16:21
*** vinodmr has quit IRC16:25
*** SergeyLukjanov has joined #openstack-meeting-alt16:28
*** jmontemayor has quit IRC16:30
*** dina_belova has quit IRC16:32
*** betsy has joined #openstack-meeting-alt16:34
*** dina_belova has joined #openstack-meeting-alt16:37
*** akuznetsov has joined #openstack-meeting-alt16:38
*** mugsie has joined #openstack-meeting-alt16:53
*** kiall has joined #openstack-meeting-alt16:56
*** vinodmr has joined #openstack-meeting-alt16:59
*** tsimmons has joined #openstack-meeting-alt16:59
kiall#startmeeting designate17:00
openstackMeeting started Wed Aug 21 17:00:10 2013 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.17:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
*** openstack changes topic to " (Meeting topic: designate)"17:00
openstackThe meeting name has been set to 'designate'17:00
kiallHeya - Who's about?17:00
mugsieo/17:00
tsimmonsHowdy from Texas.17:00
betsyo/17:00
*** NehaV1 has quit IRC17:01
vinodmrvinod here17:01
*** NehaV has joined #openstack-meeting-alt17:01
kiallsimonmcc / Capttofu ?17:01
eankutse1Emmanuel here17:01
simonmcco/17:01
kiallOkay .. That'll do :)17:02
*** pdmars has quit IRC17:02
kiall#topic API v2.0 Discussion/Feedback17:02
*** openstack changes topic to "API v2.0 Discussion/Feedback (Meeting topic: designate)"17:02
*** CaptTofu has joined #openstack-meeting-alt17:02
* CaptTofu is present17:02
kiallSo - I've got review up thats far from production ready, but it getting to large to continue adding more to :)17:02
kiallhttps://review.openstack.org/#/c/42859/17:02
kiallThis is a start on the /zones endpoint, and lots of the "bits" that make it work17:03
kiall"Happy Path" CRUD+List operations are working nicely, and have tests etc17:03
kiallSo - Anyone wanting to start to play with it, please do :)17:03
kiallAnyone happen to look it over and have any comments?17:04
betsyokay17:04
tsimmonsCool, we'll check it out.17:04
*** ruhe has quit IRC17:04
eankutse1Not yet. Will do17:04
betsyI've looked at it very briefly. I'll look at it more in depth and start playing with it17:04
kiallCool :) I'm wanting to get it merged sooner rather than later - It's just too "big" already and will be difficult to review as more iterations go on top17:05
simonmccI've looked & added some comments, mostly around documenting some bits17:05
kiallOkay .. So..17:06
kiallWe updated the API v2 spec to replace the "old" pagination with the "new"17:06
kiallAny more comments on that before someone starts implementing it? :)17:06
eankutse1not from me17:07
tsimmonsNope, I think it's good.17:07
betsy+117:07
CaptTofuI agree17:07
kiallCool - Okay :)17:07
kiallAnything from anyone else on APIv2 before moving over to Blueprints and Bugs? :)17:08
simonmccnothing from me17:09
*** SergeyLukjanov has quit IRC17:09
tsimmonsor me17:09
kiall#topic Blueprints and Bugs17:09
*** openstack changes topic to "Blueprints and Bugs (Meeting topic: designate)"17:09
mugsienope17:09
*** dina_belova has quit IRC17:10
kiallWe filed/cleaned yup a couple of blueprints/bugs this morning.. With an eye towards making sure there are pieces for people to grab and work on .. There's obviously lots more to add .. but it's a start17:10
kiallThe blueprints list https://blueprints.launchpad.net/designate17:10
eankutse1Thanks Kiall for filing bugs and blueprints17:10
kiallhas a bunch of generally useful features - most of which should be easy enough to pick up and work on :)17:10
CaptTofubite-sized tasks++17:11
kiallSome examples would be domain-import-export (from traditional bind/rfc zone files)17:11
betsykiall: so is that one for v1 or v2?17:12
kiallcaching-backend - which needs to be renamed to caching-storage ;) a small caching layer been the DB and DB Users ..17:12
betsyI'm assuming these are all on v1. Is that right?17:12
kiallWe do lots of "GET where ID = 1234" that could easily not need to hit the DB17:12
*** dina_belova has joined #openstack-meeting-alt17:12
kiallbetsy: generally speaking, we should stop adding to v1 .. But .. v2 isn't ready, so there's no harm ;)17:13
betsyYeah. That's where I was a little confused17:13
kiallAnyway -17:13
kiallugh17:13
kialltried to delete that ;)17:13
kiallThere's also the bind9 and agent stuff we talked about during the week - they aren't filed17:13
simonmcccaching-storage - sounds a little premature?  or something we should leverage in SQLA?17:13
kiallBut are generally in need of some love :)17:14
tsimmonsI was planning on filing a blueprint for that.17:14
kiallsimonmcc: possibly :) but it's still generally useful :)17:14
*** dina_belova has quit IRC17:15
kialltsimmons: please do :) Anything anyone see's that they think is missing etc.. file one :)17:15
kiallAnyway - The point of all this is :) myself / simonmcc / CaptTofu are figuring out what bugs/blueprints are missing, and are filing as we find them..17:16
eankutse1Thanks for doing that17:16
*** lifeless has quit IRC17:16
kiallNo problem.. It's a change for us .. we're used to filing tickets in JIRA!17:17
*** lifeless has joined #openstack-meeting-alt17:17
betsyI know. We have an internal tool, too17:17
kiallBeing split between two is awful :)17:17
betsyTrying to figure out the best way to tie them together17:17
betsyExactly!17:17
CaptTofuperhaps just internal tickets for proprietary issues17:18
kiallAnyway - Hopefully there's enough in the lists to last a few weeks ;)17:18
CaptTofuif something designate-specific, public17:18
kiallCaptTofu: yea, ideally *everything* designate related goes in LaunchPad .. :)17:19
kiallThere's also a second bug list for the client.. https://bugs.launchpad.net/python-designateclient/+bugs17:19
kiallAlthough .. I know there are 50 or so bugs in the client that aren't filed. We'll port them from JIRA :)17:19
kiallSo, that's all we has listed on the agenda for today.. Nice and short!17:20
kiall#topic Open discussion17:20
*** openstack changes topic to "Open discussion (Meeting topic: designate)"17:20
kiallAnything else from anyone?17:20
CaptTofuyes17:21
CaptTofuI'm curious how other organizations using Designate are doing with their implementations17:21
CaptTofuif what's worth discussing17:21
CaptTofuif not, glad to take it offline17:21
eankutse1We are Bind9 based17:21
*** mordred has quit IRC17:22
eankutse1so we are still working through some issues17:22
eankutse1to get a Bind9 installation17:22
eankutse1and then think of a migration plan17:22
CaptTofueankutse1: do you use any backing databases?17:22
kialleankutse1: I'd bet :) the bind9 support has lagged, and defiantly needs work17:22
eankutse1yes we do17:22
*** dmakogon_ has joined #openstack-meeting-alt17:22
CaptTofuI updated mysqlbind recently and it works pretty well. You only have to re-write your zone conf file. I can discuss offline if you are interested.17:23
CaptTofuvery easy to use.17:23
tsimmonsRight now we're using a PowerDNS backend to get a small implementation up and running with a few environments so we can get an idea of what our eventual implementation will look like.17:23
eankutse1CapTofu: that would be helpful17:23
eankutse1We will get in touch with you - maybe tsimmons17:24
tsimmonsFor sure.17:25
kiallCaptTofu: maybe the best thing would be to add to the documentation? That way it's totally public etc :)17:25
eankutse1Even better17:25
*** akuznetsov has quit IRC17:25
kiallWe should probably add a docs sections for each backend covering the backend specific stuff17:26
tsimmonsIt would be helpful to have more specific instructions on setting up each one, yeah.17:26
*** ruhe has joined #openstack-meeting-alt17:26
simonmcc+1 on that17:26
*** markwash has joined #openstack-meeting-alt17:27
kiall#action New doc section to be added for backend specific, starting with CaptTofu's mysqlbind docs..17:27
kiallSo - Are there any others areas you, as "new guys", have found lacking?17:28
kialldoc areas*17:28
*** akuznetsov has joined #openstack-meeting-alt17:28
CaptTofu:)17:29
CaptTofu@kiall agreed17:29
CaptTofuoops, not hipchat17:29
kiallhah :D17:29
betsykiall: I haven't noticed any17:29
kiallbetsy: that sounds promising :)17:29
tsimmonsThere could be more instruction on backend setup, like we've said here.17:30
kiall#action Add doc section on plain bind9 backend, including agent limitations..17:30
*** mordred has joined #openstack-meeting-alt17:30
kiall#action Get a blueprint together discussing the future of the agent, and how it will interact with API v2's "server pools"17:31
kiall^ that one is likely to need input from everyone, HPs implementation is very different than I expect may others would be.. So getting that right for everyone is a meeting to itself17:31
kiallmany others would be*17:32
eankutse1I agree17:32
kiallOkay :) Anything else?17:32
tsimmons#agree the documentation for agent could be fleshed out some more after that ^17:32
betsykiall: True17:32
tsimmonsCould we get some clarification on the designate client? Just a quick background on it?17:33
eankutse1+117:33
betsyLooks like it hasn't been worked on since folsom?17:34
simonmccit's a python binding & cli client for the rest api17:34
kiallbetsy: "Happy Path" works perfectly :)17:34
kiallIf it runs into an issue, it's not very user friendly17:34
betsykiall: :)17:34
kiallI use it daily.. More than I use the API by itself17:34
simonmccFM there are parts of the API not covered by it, but all the core stuff is there17:35
eankutse1Cool17:35
betsycli clients are always handy17:35
kiallAnyway - As simonmcc said, the tradition in openstack is to include both Python API bindings and a CLI that makes use of those bindings in a single package17:35
eankutse1Sounds like there is some work to be done there as well17:35
betsyWe could probably use some documentation around that, too17:35
simonmccit'll need the v2 api added to it for a start :-)17:36
betsyUnless I've just missed that17:36
kialleankutse1: I think the error handling is the main area .. and, when v2 comes out, we can make it MUCH more user friendly17:36
eankutse1ok17:36
simonmcc#action add usage example for python-designate cli17:36
kiallToday, it's quite "awkward" to use17:37
kialle.g17:37
kiall$ designate record-delete b1bbcb29-d2f7-4ec4-82e3-0bbb32230977 6d3bf479-8a93-47ae-8c65-3dff8dba1b0d17:37
kiallfirst UUID is the domain, second is the Record17:37
kiallThe v2 api will make looking up domains etc by name doable17:37
kiall(and actually works in the /zones review I mentioned earlier)17:38
*** venkatesh has joined #openstack-meeting-alt17:38
kiallAnyway, we have some docs on our internal wiki that explain how to use the CLI. We'll port those, and add docs on the python bindings aswell17:39
eankutse1Great!17:39
betsyAwesome17:39
kiall#action Document designateclient python bindings..17:39
kiallStarting the cycle again :D Anything else?17:40
CaptTofunot from me.17:40
*** esker has joined #openstack-meeting-alt17:40
simonmccshould we pypi the client?17:41
kiallI have 1 last one :)17:41
kiallsimonmcc: yea, all we had to do to make that happen is tag to repo17:41
kiallJenkins will build the package based on the and upload it to pypi17:41
*** akuznetsov has quit IRC17:41
simonmccok, doh, we've talked about that before :-)17:41
kiall:)17:41
simonmccso, what's your "one last thing" ?17:42
CaptTofunifty!17:42
kiallWhat would you change about these meetings?17:42
CaptTofumore people.17:42
CaptTofujust so we have more project involvement17:42
CaptTofubut that's an external issue17:42
betsyCaptTofu: we're trying :)17:42
tsimmonsMake them in person :D17:43
*** rnirmal has quit IRC17:43
*** SergeyLukjanov has joined #openstack-meeting-alt17:43
betsyRoad trip to Ireland!!17:43
kiallI want to make sure time is well spent by everyone .. If we're not covering stuff people are interested in talking about .. or any other issues. Lets fix it :)17:43
eankutse1I think we are doing well so far17:44
betsy+117:44
eankutse1useful17:44
eankutse1in the future17:44
eankutse1we might be able to17:44
kiallCool - For anyone who hasn't sat in on some of the other OpenStack meetings that go on .. Do.. :)17:44
eankutse1publish17:44
eankutse1agenda ahead of time17:44
kiallI knew that was going to come up ;)17:45
eankutse1:-)17:45
kiallThe agena is on https://wiki.openstack.org/wiki/Meetings/Designate17:45
kiallBut .. It was only updated this morning ;)17:45
kialli.e. no good.17:45
eankutse1Cool. Thanks for letting me know17:45
kiallAlso - everyone can edit that page, and add items..17:46
betsyOkay17:46
kiallDoesn't matter what it is! Maybe you want to dicuss how to implement some feature, or general project direction, or .. those are all things you can just add17:47
tsimmonsIs there/should there be a designate mailing list where we could send out the agenda/other info to people, perhaps get more people involved?17:47
kiall#action Update agenda as soon as items are thought of!17:47
kialltsimmons: generally, the other openstack projects share the openstack-dev list, and publish meeting stuff in advance to there.. We probably should too :)17:48
kiall#action Start publishing meeting schedules/agenda to the openstack-dev list.17:48
tsimmonsI see, that should help drive some traffic to the project/meetings.17:48
mugsiedo we need to register as a topic on that list?17:49
kiallI'm not sure there should be a designate specific dev list, there used to 1 for each project.. and they go removed :)17:49
kiallmugsie: no, just prefix designate stuff with "[Designate] My Subject Here"17:49
simonmccthe problem with the -dev list is that it's getting to be hight traffic ;/17:49
kiallsimonmcc: yea, that's the idea behind the prefixes :)17:50
kiallyou can move [Nova] to somewhere else, but let [Glance] and [Designate though..17:50
simonmcckiall :-017:50
kiall(using your email client's tiles)17:50
kiallrules*17:50
mugsiekiall: there is a filter option in the mailing list software now17:51
kiallOh, really? News to me17:51
mugsiethat has a load of projects as "topics"17:51
kiall#action mugsie to look into if we need to register as a "topic" :)17:51
kiallStarting the cycle again :D Anything else?17:52
eankutse1Not from me17:52
simonmccnot from me17:53
mugsienor me17:53
kiallOkay I guess not, thanks everyone :) I think there's plenty of useful feedback buried in the logs!17:53
CaptTofuthanks!17:53
simonmcccheers!17:53
eankutse1Bye17:53
kiallNo wonder my IRC is so laggy: 5 packets transmitted, 0 received, 100% packet loss, time 5999ms17:53
kiall100% -_-17:53
kiall#endmeeting17:54
*** openstack changes topic to "OpenStack meetings (alternate)"17:54
openstackMeeting ended Wed Aug 21 17:54:01 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:54
openstackMinutes:        http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-08-21-17.00.html17:54
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-08-21-17.00.txt17:54
openstackLog:            http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-08-21-17.00.log.html17:54
*** arborism has joined #openstack-meeting-alt17:54
tsimmonsSee ya, thanks guys.17:54
*** vinodmr has left #openstack-meeting-alt17:54
*** dina_belova has joined #openstack-meeting-alt17:54
*** nicole has joined #openstack-meeting-alt17:57
*** mugsie has left #openstack-meeting-alt17:57
*** nicole is now known as Guest4748517:57
*** Guest47485 has left #openstack-meeting-alt17:57
*** Guest47485 has joined #openstack-meeting-alt17:58
*** ruhe has quit IRC17:58
*** vkmc has joined #openstack-meeting-alt18:02
*** Guest47485 has left #openstack-meeting-alt18:04
*** rnirmal has joined #openstack-meeting-alt18:08
*** yogesh has joined #openstack-meeting-alt18:17
*** boris-42 has joined #openstack-meeting-alt18:19
*** yogesh has quit IRC18:19
*** pdmars has joined #openstack-meeting-alt18:23
*** grapex has joined #openstack-meeting-alt18:24
*** venkatesh has quit IRC18:26
*** eankutse1 has quit IRC18:27
*** yogesh has joined #openstack-meeting-alt18:35
*** tsimmons has quit IRC18:36
*** tsimmons has joined #openstack-meeting-alt18:42
*** yogesh has quit IRC18:50
*** Riddhi has joined #openstack-meeting-alt18:50
*** yogesh has joined #openstack-meeting-alt18:51
*** eankutse has joined #openstack-meeting-alt18:52
*** tsimmons has quit IRC18:54
*** eankutse has quit IRC18:56
*** eankutse has joined #openstack-meeting-alt18:57
*** akuznetsov has joined #openstack-meeting-alt18:57
*** tsimmons has joined #openstack-meeting-alt18:57
*** yogesh has quit IRC18:58
*** sarob has joined #openstack-meeting-alt18:59
*** msisk has quit IRC19:16
*** esker has quit IRC19:20
*** sarob has quit IRC19:21
*** sarob has joined #openstack-meeting-alt19:21
*** ashestakov has joined #openstack-meeting-alt19:25
*** sarob has quit IRC19:25
*** vipul is now known as vipul-away19:36
*** vipul-away is now known as vipul19:36
*** boris-42 has quit IRC19:37
*** jmontemayor has joined #openstack-meeting-alt19:42
*** yogesh has joined #openstack-meeting-alt19:47
*** djohnstone has quit IRC19:48
*** akuznetsov has quit IRC19:49
*** vipul is now known as vipul-away19:51
*** esp has joined #openstack-meeting-alt19:53
*** vipul-away is now known as vipul19:53
*** yogesh has quit IRC19:54
*** yogesh has joined #openstack-meeting-alt19:55
*** esker has joined #openstack-meeting-alt19:56
*** KennethWilke has joined #openstack-meeting-alt19:56
*** cweid has joined #openstack-meeting-alt19:57
*** KennethWilke has quit IRC19:57
*** imsplitbit has joined #openstack-meeting-alt19:58
*** vinodmr has joined #openstack-meeting-alt19:59
*** vinodmr has quit IRC19:59
*** KennethWilke has joined #openstack-meeting-alt19:59
vipul#startmeeting trove20:00
openstackMeeting started Wed Aug 21 20:00:07 2013 UTC and is due to finish in 60 minutes.  The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: trove)"20:00
openstackThe meeting name has been set to 'trove'20:00
KennethWilkehowdy20:00
*** jcru has joined #openstack-meeting-alt20:00
imsplitbito/20:00
vipulo/20:00
dmakogon_hi 2 all20:00
amytrono/20:00
*** saurabhs has joined #openstack-meeting-alt20:00
dmakogon_o/20:00
*** robertmyers has joined #openstack-meeting-alt20:00
robertmyerso/20:00
espo/20:00
*** SlickNik has joined #openstack-meeting-alt20:00
vipul#link https://wiki.openstack.org/wiki/Meetings/TroveMeeting20:00
pdmarso/20:01
kevinconway\-\0/-/20:01
SlickNiko/20:01
vipul#topic action items20:01
*** openstack changes topic to "action items (Meeting topic: trove)"20:01
cp16neto^/20:01
cweido/20:01
vipulimsplitbit: first one is you20:01
*** datsun180b has joined #openstack-meeting-alt20:01
vipulimsplitbit to move his clustering reviews to a feature branch20:01
grapexo/20:02
imsplitbityeah I've got the clustertype stuff out there for review20:02
vipuli assume this was for the cluster api itself maybe20:02
vipul?20:02
imsplitbitI've created a feature branch and I'm moving my current work for cluster api into it20:02
*** tsimmons has joined #openstack-meeting-alt20:02
datsun180bo720:02
imsplitbityes20:02
vipulcool20:02
imsplitbitI haven't pushed it up yet20:02
dmakogon_can it be extended ?20:02
imsplitbitI would love some feedback on the clustertype20:02
imsplitbitboth for trove and trove client20:02
vipul#action imsplitbit to push up cluster api to feature branch20:02
*** vinodmr has joined #openstack-meeting-alt20:02
vipulimsplitbit: Yea i've been meaning to find some time20:03
vipuli'll look this week.20:03
SlickNikSame here20:03
vipuli did browse over it though...20:03
imsplitbitkk thx!20:03
vipulnext item was hub_cap..20:03
vipuli guess we skip him20:03
vipul#action hub_cap to find out what happens w/ feature based reviews that land after FF20:03
vipulnext.. SlickNick20:03
SlickNikYeah, I made a couple of changes to the devstack review.20:04
SlickNikBut I have to yet make the default role change20:04
SlickNikSo I'm going to action this one again for myself.20:04
SlickNik#action SlickNik update devstack review to add role to default devstack users.20:04
*** key2 has joined #openstack-meeting-alt20:04
vipulcool..20:04
vipulthanks!20:04
vipuland that is all for actions20:04
*** yogesh has quit IRC20:04
arborismdoh! meant to comment on cluster stuff, was afk for a minute or so :X20:04
vipul#topic Automated Backups Design20:04
*** openstack changes topic to "Automated Backups Design (Meeting topic: trove)"20:04
vipularborism: that'll be after this topic20:04
vipulcp16net: wanna take it away?20:05
cp16netyes... thx20:05
cp16netso this name i think is a little off now that i have more defined20:05
cp16netits more about scheduled tasks20:05
vipul#link https://wiki.openstack.org/wiki/Trove/scheduled-tasks20:05
cp16netthis will require a scheduler  that will send messages to the guests to rn the tasks20:06
cp16netthese tasks could be anything20:06
*** yogesh has joined #openstack-meeting-alt20:06
cp16netbut initially we will have backups20:06
cp16netthis could be extended to allowing updates to pacakges for the customer20:06
arborismtheoretically, the guest upgrade blueprint could find some usefulness as a scheduled task as well, no?20:07
cp16netlike mysql/guest or other packages20:07
vipulyep i would think we'd be able to do that20:07
cp16netit surely can20:07
arborismniiiiice20:07
SlickNik@cp16net: will the guest be agnostic about these tasks?20:07
*** vinodmr has left #openstack-meeting-alt20:08
cp16netSlickNik: the guest will be able to handle them20:08
cp16netthe idea is that the scheudler will send a task to the guest to act on20:09
cp16netthat guest will complete that task and report back on it20:09
SlickNikcp16net: Sorry if I was a bit unclear. Meant to ask whether the guest would know the difference between whether a task was part of a schedule or not?20:09
cp16netthat its complete and such20:09
SlickNikOr does it look like just another task to the gues20:09
vipulcp16net: so what does it mean for a maintenance window20:09
SlickNikguest*20:09
vipullike does the guest know not to accept any more 'tasks' ?20:09
cp16netSlickNik: i think it would be able to tell if it was a scheudled20:10
grapexcp16net: What would the distinction be?20:10
cp16netbecause the guest needs to report back saying that the task it was given is complete20:10
grapexOr rather, what value does having that distinction give us?20:10
grapexSeems like a typical "call". Or a longer running task issued via "cast" which the guest then updates Trove on20:10
cp16netvipul: the maintenance window is decalared by the customer of when they would want these schedules to run20:11
SlickNikSo then do we need a separate scheduler component? Or can the guest just run the task based on the schedule of the task?20:11
grapexwhich currently happens through the database, but will possibly be over RPC in the future via conductor or something.20:11
vipulkinda agree with grapex.. seems unnecessary for the guest to be aware or differentiate how an request to it originated20:11
cp16netgrapex:  this is a good point that we need bidirectional comm between the guest and system20:11
cp16neti was thining that the conductor could handle some of this20:11
grapexSlickNik: The guest has to schedule stuff it makes it harder to manage if things begin to fail or die20:11
grapexcp16net: Possibly20:12
cp16netbut that is just a dream atm20:12
grapexbut for this conversation20:12
grapexlet's assume that the guest has a decent way to pass back info to Trove20:12
grapexcp16net: I have a feeling the first phase of conductor won't take too long20:12
cp16netSlickNik: the idea i have is that theere is a new service running as the scheduler20:12
dmakogon_i thinks the best way it to pass data through DB20:12
vipuldmakogon_: that's how it's done now20:13
cp16netgrapex: yes i agree that because its just a dream i have20:13
grapexdmakogon_: Maybe- we could create a strategy for using the DB still if people want to-20:13
vipulyea it should be configuratable i suppose20:13
grapexlet's save the talk of sending messages back on the guest for when we discuss Conductor later20:13
cp16nethave the guest agent have different stragetys?20:13
cp16netew.. spellign20:13
*** tsimmons has quit IRC20:14
*** jasonb365 has joined #openstack-meeting-alt20:14
vipullet's table that for now.. talk about automated tasks now20:14
dmakogon_and choosing strategy would be configurable ??20:14
vipula maintentenance window to me seems like a time the guest should not be able to do things that may be long running20:14
cp16netso lets bring this back to the scheduled task20:14
vipullike i want to upgrade my guest agent during a time window..20:14
cp16netits going to handle scheudling a task on behalf of the customer20:14
vipulso i can be sure a backup isn't runnign when i take it down20:15
SlickNikcp16net: I'm still working through the pro's and cons of having a separate scheduler.20:15
grapexvipul: Ah20:15
*** yogesh has quit IRC20:15
grapexWell, we already have code to see if an action in trove can be performed20:15
dmakogon_scheduler should be done like it done in nova20:15
dmakogon_or am i wrong ?20:15
SlickNiknova scheduler is something different.20:16
vipulgrapex: Yea i'd wnat to extend that to take the maintenance window into account i susppose20:16
cp16netdmakogon_: thats the idea20:16
grapexvipul: What may be possible is to query to see if the guest or instance is ready at routine intervals and then upgrade if possible20:16
grapexdmakogon_: I think we should take whatever is applicable from Nova20:16
SlickNikgrapex / dmakogon_: I don't think that nova does time based scheduling.20:16
vipulgrapex: that could work as well20:16
key2dmakogon_: Can you create the blueprint?20:17
vipulSlickNik: agreed, everything time based just is a periodic task within exisitng services20:17
grapexSo20:17
dmakogon_key2: i could do that20:17
grapexcp16net: do you see a distinction between what you propose and these time based calls to the guest?20:17
*** rnirmal has quit IRC20:18
grapexkey2 dmakogon_: I'm not sure if there's a dictinction between what you're suggesting and the scheduled tasks blueprint20:18
vipulgrapex: cp16net i do see one diff... nova doens't take inot account a user's specified time20:18
cp16neti'm a little confused between what the question i am reading20:18
SlickNikwhy can't the scheduled task info just be stored on the guest.20:18
datsun180bBecause containers aren't reliable for keeping time20:18
cp16netoh i see what you mean20:18
SlickNikAnd the guest can decide when to run based on a periodic task, this time based info, and maintenance window info.20:18
redthruxand we don't want the guest to grow larger and larger having to track things20:18
grapexSlickNik: Let's say the guest dies-20:18
cp16netwe dont want to make the guest any more complicated20:18
*** benl has joined #openstack-meeting-alt20:19
cp16netwe rather keep it in the infra20:19
SlickNikWell, if the guest dies it can't run anything anyway.20:19
grapexSlickNik: Maybe the guest could send back in it's heart beat if it has resources on hand to perform tasks20:19
cp16netthis needs to be able to handle different senarios20:19
vipulyou'd have to give the guest access to the database20:19
vipulwhere will it configure itself from20:19
imsplitbitNOOOOOOOOOOOOOOO20:19
imsplitbit:)20:19
vipulbut we should look at simplifying this.. it may very well be create a crontab entry on the guest20:20
vipulbut what drives that might be some trove service20:20
cp16netone of the ideas here is that its plugable with diffrernt strategies20:20
key2well. let's consider how we different from Nova in terms of requirements to the module20:20
espyeah I think having a dedicated scheduler makes sense.20:20
SlickNikA separate scheduler is a single point of failure for jobs across multiple guests.20:20
grapexSo the issue is do we want to make the guest store this information on scheduling and also have to be in charge of cron20:20
cp16netvipul: i think thats a bad idea to have cron running on the geust20:20
kevinconwayvipul: wouldn't a cron schedule on the guest make it harder to implement the scheduler pause you want to introduce for maintenance windows?20:20
cp16netit should be centalized20:21
redthrux(and clusterable)20:21
cp16netredthrux: +120:21
imsplitbitif it is centralized then clusterable is a requirement20:21
vipulkevinconway: point..20:21
key2redthrux: +120:21
key2I desperately want Cassandra ))20:21
espSlickNik: not necessarily20:22
dmakogon_Cassandra is easy clusterable20:22
SlickNikcp16net: you can't really control running _only_ in maintenance windows if it's centralized.20:22
dmakogon_key2: but the point is scheduler for now20:22
grapexSlickNik: Is it because the central point wouldn't know if the maintenance window is happening?20:22
cp16netSlickNik: its the only way you can if the customer is to define when the window is20:22
SlickNikYou don't know if the guest / network is down when you schedule the cast.20:22
imsplitbitwell lets not get bogged down too heavy in impl details20:22
grapexSlickNik: We have heart beats though, so we should know20:22
cp16netSlickNik: there is an api that the customer can define what the window will be20:22
SlickNikSo when the guest picks the message up, it _might_ well be out of the window.20:22
key2dmakogon_: I mean we should keep clustering in mind20:23
dmakogon_key2: yes, it's really true!20:23
grapexSlickNik: I am expecting the latency to be short enough that won't be a problem20:23
vipulYou should only send messages to services that are up20:23
grapexMaybe I'm assuming too much20:23
cp16netSlickNik: you bring up a good point tho20:23
cp16netSlickNik: there has to be a fuzzy window20:23
SlickNikSo what if you send one message after another.20:23
SlickNikGuest is up20:23
grapexSlickNik: I know at Rack, the latency of messages isn't more than a second or so20:23
cp16netit can not be exact20:23
kevinconwaygrapex: could always treat it like medication. take as soon as possible or just the next dose. whichever is soonest.20:23
SlickNikBut the first action takes a long time to complete, so that when the guest picks the second message, it's out of the window.20:24
grapexSlickNik: Maybe what's needed are TTLs and gauranteed delivery20:24
SlickNikYou can't guarantee maintenance windows unless you build that logic _into_ the guest.20:24
*** esker has quit IRC20:24
vipulThat's logic that can be built into the scheduling hting to only send it the second message after you know the first maintennace task is done20:24
grapexSo if the scheduler makes the guest do something, and it doesn't, the request is cancelled20:24
*** crobertsrh is now known as _crobertsrh20:25
vipulgrapex: that's assuming syncronous20:25
grapexSlickNik: There could also be time windows sent- so the guest would know if it's past the given Window don't bother20:25
redthrux+1 grapex - easily done with messages in if you are using  rabbitmq20:25
vipulit seems like the scheduler component will need to keep task status in mind.. and if it does you can solve for these things20:25
SlickNikVipul, what if the guest is already taking a backup based on a user call.20:25
kevinconwaycould scheduled tasks come with an expiry time where the guest will refuse it with knowledge that another task is coming?20:25
vipulthat's somethign the scheduler shoudl be aware20:25
vipulyou shoudln't blindly schedule things20:25
cp16netvipul: grapex: SlickNik: should we have a meeting outisde of this meeting on this?20:25
vipulwhether you're in a maintenance window or not20:25
*** tsimmons has joined #openstack-meeting-alt20:25
vipulcp16net: yes20:25
SlickNikYes, please20:26
SlickNikcp16net: ^^^20:26
vipulmoving on.. evryone.. look over the Design please20:26
key2cp16net: yes20:26
vipullet's try to meet again20:26
vipulthis week or next?20:26
cp16neti'd gladly talk more but we do have more to talk about orry20:26
cp16netthis week perferably20:26
vipullet's throw out some times20:26
vipultomorrow at 2PST?20:26
cp16netwe could chat tmorrow at this same time20:27
SlickNikWorks for me20:27
imsplitbitI can't make that but don't hold it up on me20:27
cp16net3cst?20:27
vipulok 1pst tomorrow 3cst20:27
vipuldone20:27
vipul#topic Trove API section for DB type selection20:27
*** openstack changes topic to "Trove API section for DB type selection (Meeting topic: trove)"20:27
vipulimsplitbit:  is this you?20:27
imsplitbitno20:28
dmakogon_me20:28
vipulgo dmakogon_20:28
dmakogon_ what the idea, we should provide specific chose to user for service type20:28
dmakogon_it could be setted by config, or be stored at DB and be manually added to it20:29
vipulservice_type is something that we allow user to specify20:29
vipulin the create instance call20:30
dmakogon_in this way every one could extend initail configs for trove and build custom images with differernt DBs20:30
vipulwith that, today you can support >1 type of db in trove20:30
dmakogon_for now it specifies only one type20:30
dmakogon_it's not normal20:30
vipulin the config? yes20:30
SlickNikdmakogon_: the trove config only specifies the _default_ service type.20:30
dmakogon_trove should do it's dinamically20:30
vipulthat becomes the default service_type ... BUT if you had another entry in service_images it would honor that20:30
SlickNikYou can still have other service types that you can explicitly pick during the instance create call.20:31
arborismOne thing to consider, is that given you'll likely want specific flavors for different service_types, how do you guarantee such affinity? You could let the flavor drive the service_type (e.g. mysql.xl)...20:31
dmakogon_my point is to extend API for adding new dinamic parameter20:31
dmakogon_service_type20:31
vipularborism: https://blueprints.launchpad.net/trove/+spec/service-type-filter-on-flavors20:31
dmakogon_and it's should be done20:32
SlickNikarborism: good point. there's a later topic scheduled to discuss that very thing ^^^20:32
grapexarborism: I'd rather have some new API resource analogous to Nova images that let a user enumerate service types.20:32
vipuldmakogon_: so a management API20:32
cp16netdmakogon_: could there be an extension for this?20:32
vipulyes! grapex we disucssed this a while ago20:32
kevinconwaygrapex: +120:32
vipulGET /servicetypes20:32
grapexvipul: Sorry... good we agree though. :)20:32
dmakogon_cp16net: i think we could do that20:33
SlickNikI like that idea, grapex / vipul20:33
vipulgrapex: no worries.. i just mean we should revive that discussion20:33
vipulit was proposed by demorris a while ago.. then sort of died20:33
vipulbut since ther is a lot of itnerest in support >1 service type.. we kinda need the API20:33
dmakogon_it wont die20:33
vipuldmakogon_: So i think what you want is a management api to add new service types.. please file a BP20:34
dmakogon_i will try to make a propose at wiki20:34
dmakogon_ok20:34
cp16netgrapex: so that the maintainer could disable types or set one as default?20:34
vipuldone? moving on20:34
SlickNikgood with it20:34
vipul#topic clustering API update20:34
*** openstack changes topic to "clustering API update (Meeting topic: trove)"20:34
grapexcp16net: Sure20:34
arborismdmakogon_: While spec'ing, can you also take into consideration versioning? i.e. mysql-5.5 vs. 5.620:34
dmakogon_arborism: ok20:35
vipuldmakogon_: you wanted to chime in here?20:35
kevinconwayarborism: nova images handle the same thing20:35
key2arborism: anything else beside version?20:35
dmakogon_but it although makes API more complicated20:35
kevinconwayubuntu 12 vs ubuntu 13 are just different images20:36
vipulanyone have anythign to say about clusterin API?20:36
arborismI wasn't advocating for anything, I was just mentioning that while writing out the specs, to consider the implications of wanting multiple versions of a service_type available. How it's impl'd/handled is up in the air.20:36
arborismvipul: Yes20:36
dmakogon_kevinconway: should you propose still image for it20:36
vipularborism: dmakogon_: i'll try to find an old wiki for it20:37
dmakogon_vipul: i have20:37
arborismSo given the API Ref, I'm not sure I see how it will work in the future w/ the inevitable parameter groups and region awareness requirements20:37
arborism(regarding Clustering API)20:37
vipulgo for it..20:37
dmakogon_if, in future, trove will have multiple service support20:38
*** rnirmal has joined #openstack-meeting-alt20:38
vipulyes..20:38
dmakogon_we sould build flexible clustering API that will be applicapable  for all20:38
dmakogon_sorry for slow typing20:38
vipulno worries :)20:39
imsplitbitI believe that's what we're attempting to do20:39
imsplitbitwe're trying to make it as open as possible20:39
dmakogon_that is why, although Trove API(single-node) should be changed20:39
vipul#link https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API-Using-Instances20:39
dmakogon_because of alot of NoSQL doesn't support ACL at db-layer20:39
vipuldmakogon_: after lookign at that proposal.. do you think there are things that don't fit with other dbs?20:40
arborismvipul: redis20:40
dmakogon_cassandra20:40
vipularborism: :P20:40
dmakogon_alot of dbs20:40
vipulare we going to bring up users again20:40
imsplitbitwhere?20:40
imsplitbithow?20:40
imsplitbitlol20:40
imsplitbitplease god no20:40
arborismcan i elaborate on redis?20:40
imsplitbitsure20:40
kevinconwayeven i don't want to talk about users anymore20:40
arborismwithout users ;)20:40
imsplitbitplease proceed20:40
arborismSay I have 3 DCs, and I want a Redis Master in each20:40
dmakogon_we don't need users in NoSQL20:41
arborismI'll use consistent hashing client side20:41
arborismto pick20:41
arborismHow, with the clustering api, will I be able to add a read slave20:41
arborismpicking whether I want to daisy chain, or connect directly to master20:41
arborismplus, choose the ability to accept explicit writes on a slave (aka readonly)20:41
imsplitbitI am not sure where in the clustering api it doesn't allow you to do that20:42
arborismBecause as a whole, I'd logically consider the entire deployment a cluster, but with the api spec20:42
arborismThere's no "nodeType"20:42
arborismonly cluster type20:42
vipuli think that's what the clusterConfig is for20:42
*** yogesh has joined #openstack-meeting-alt20:42
vipulyou specify the primary.. at least in that example20:42
vipulwe may need to extend what goes in there based on service type20:43
arborismwell, read replica uses primary, add a node doesn't20:43
imsplitbitthere is a concept of roles within thee clustering api20:43
arborismvipul: but doesn't clusterConfig end up becoming a parameter group?20:43
SlickNikarborism: can you explain what you mean by parameter group?20:44
SlickNik(or link to something that does, please)20:44
arborisme.g. key-value-pairs related to the service_type20:44
arborisma la, conf pairs20:44
vipularborism: i guess it would become that if we allowed it to change20:45
vipulmaybe what we need is a concrete API example that will do what you want..20:45
arborismLet me paste out a couple of things I wrote, then add a quick comment:20:45
arborism> In "Create Replication Set: (No previous db instance, fresh)", should be able to specify flavorRef per Node.20:45
vipuland we should compare that with what we've come up with so far20:45
arborism> "Create Replication Set" is a POST to /clusters, but "Add Node" is a PUT to /clusters/{cluster_id}/nodes, this seems inconsistent.20:46
arborism  Is primaryNode the means of association, or is it the URI (i.e. /clusters/{cluster_id})20:46
arborism> Confused on "Promote a slave node to master"; where is it indicating the promotion action explicitly? Why not /clusters/{cluster_id}/promote?20:46
arborism> What's the expected behavior of a resize, delete, restart-db, or restart on /instance/{instance_id}? Block? Forward to /clusters?20:46
dmakogon_arborism: flavorRef of each node should be the same20:47
dmakogon_it is like BP20:47
dmakogon_best-practicies20:47
arborismdmakogon_: Not true. We had that discussion awhile ago. You might want a read slave with a beefier profile to handle ad-hoc queries20:47
imsplitbitcorrect20:47
arborismI modeled out multiple service types, and arrived at: https://gist.github.com/amcr/96c59a333b72ec973c3a20:48
arborismTo me, it seems a little easier to grok20:48
imsplitbitcreate should allow you to easily create a cluster of instances of all the same flavor really easily but shouldn't be so inflexible so as to disallow individual flavors20:48
arborismimsplitbit: +120:49
key2imsplitbit: +120:49
dmakogon_arborism: i will do it in my way20:50
imsplitbitwith regard to the notes, I'll need to look through them more and we can discuss further.  but for example, adding a an instance to a cluster is a cluster operation20:50
imsplitbitso it would be in /cluster, not /instance20:50
vipulso do we need to set up another meeting to discuss clusters?20:50
dmakogon_imsplitbit: +120:50
imsplitbitseems like it20:50
vipulsome of these questions we should send in ML as well20:50
vipulmailing list20:50
vipulSounds like we have a big enough audience that IRC isn't going to work for every time zone20:51
dmakogon_even if you create a cluster with tha same flavors for each node, you could do a instance_resize, on each of it20:51
imsplitbitand it may be that the doc is unclear and questions like this will help us get that fixed20:51
vipularborism: what would you prefer20:51
arborismi'm amicable to whatever works for you guys20:51
vipulrunning out of time.. 10 minutes to go20:51
SlickNikYes, we might need to take some of these discussion to the mailing list.20:51
key2ML +120:52
vipularborism: send the email [trove] in subject line :)20:52
vipul#topic Flavors per Service Type20:52
*** openstack changes topic to "Flavors per Service Type (Meeting topic: trove)"20:52
vipulhttps://blueprints.launchpad.net/trove/+spec/service-type-filter-on-flavors20:52
SlickNikarborism does raise some valid points that I would like to see addressed.20:52
vipulso arborism this is somehting you might be interested in as well..20:52
vipulif everyone is good with it.. we'll start working on it20:52
arborismIt is, because I want to shield Trove specific flavors from regular compute provisioning20:53
arborismand vice versa20:53
vipulk cool20:53
SlickNikI'm totally good with it.20:53
vipul#topic Trove Conductor20:53
*** openstack changes topic to "Trove Conductor (Meeting topic: trove)"20:53
vipulwho's doing this20:53
datsun180bme20:54
datsun180bThat is, I'm working on implementing a proof of concept first20:54
datsun180bI don't have a #link handy but KennethWilke wrote up a rough of what we want20:54
vipuldatsun180b: i assume you captured some of the comment from today.. about making it optional20:54
datsun180b#link https://wiki.openstack.org/wiki/Trove/guest_agent_communication20:54
datsun180bif i didn't, i hope eavesdrop did20:55
grapexIt seems like all step one of this needs to be is to set up a OpenStack daemon that receives RPC calls20:55
arborismnice, didn't see this one. we have heartbeats turned off for this very concern.20:56
grapexand receives one for the heartbeat, and another for backup status20:56
datsun180bgrapex: done in poc20:56
vipulOk everyone please look at ^^ as well, we'll have to tlak more about it next meeting20:56
SlickNikdatsun180b / KennethWilke: reading the wiki on it. Nice explanation!20:56
grapexmake the guest use that instead of updating the DB20:56
datsun180bthat's as much as i've got presently though20:56
vipulsorry guys.. moving on... time constraint20:56
vipul#topic Naming convention / style guide20:56
*** openstack changes topic to "Naming convention / style guide (Meeting topic: trove)"20:56
imsplitbitok real quick20:56
grapexvipul: I'm adding an action for datsun180b20:56
imsplitbitI've been looking through trove code20:56
vipulthanks grapex20:56
grapex#action datsun180b to do pull request on phase one of Trove Conductor20:57
imsplitbitand I've noticed that the json structures aren't consistent for keys20:57
imsplitbitsome are camel case and some are underscore20:57
*** tsimmons has quit IRC20:57
vipulthe actual request bodies?20:57
imsplitbitI just wanted to bring that up and see if we can come to an agreement some point soon on getting some consistency there20:57
datsun180bfor example, root_enabled ?20:57
SlickNikcan you link a couple of examples, imsplitbit?20:58
imsplitbitsure20:58
datsun180bmy fault20:58
arborismflavorRef vs. service_type20:58
vipulugh..20:58
vipuldon't know what the openstack stance is on this20:58
imsplitbitwell20:58
grapexDoes anyone know if an *official* OpenStack style has popped up int he past few years?20:58
imsplitbityeah20:58
datsun180bbesides HACKING?20:58
imsplitbitwe have flavorRef20:58
imsplitbitresorePoint20:58
imsplitbitand service_type20:58
grapexOriginally we looked and found swift and nova had different styles in their API20:58
imsplitbitroot_enabled20:58
imsplitbitit was confusing to me having not worked in the api until recently20:59
datsun180bI'm to blame for root_enabled! I was young and naive!20:59
grapeximsplitbit: It's "flavorRef" as Nova did it that way.20:59
kevinconwaygrapex: all lower case, underscored, and using wingdings characters20:59
grapexBut it seems like after that20:59
grapexwe've gone with PEP8 styles20:59
imsplitbitright20:59
grapexAnd IIRC Nova is also inconsistent in it's own API20:59
imsplitbitand pep8 would smack you upside the head for camelcase20:59
grapexSo maybe what we do is decided to go forward with PEP8 styled field names in the future21:00
imsplitbitI'm not opposed to either21:00
grapexand keep the old names around for backwards compatability21:00
imsplitbitbut I'm opposed to both21:00
imsplitbitit looks messy21:00
datsun180bi don't know that pep8 governs variable naming, past it must be tokenizable by the parser21:00
dmakogon_https://blueprints.launchpad.net/trove/+spec/multi-service-type-support - is gonna be approved ?21:00
cp16netyea i didnt think it mattered21:00
grapexdatsun180b: Keep in mind when I say PEP8, this isn't a code convention, but one for the Rest API- PEP8 won't catch it21:00
*** KennethWilke has quit IRC21:00
vipul#action Find json style guide vipul hub_cap grapex21:00
kevinconwayhttp://www.python.org/dev/peps/pep-0008/#naming-conventions21:01
vipulok moving on..21:01
SlickNikpep8 has no take on the matter.21:01
vipul#topic open Discussion21:01
*** openstack changes topic to "open Discussion (Meeting topic: trove)"21:01
cp16nethaha gl on finding one :-P21:01
vipulcontinue.. :)21:01
grapexSo quick question21:01
dmakogon_all blueprints are approved for today ?21:01
grapexarborism: https://gist.github.com/amcr/96c59a333b72ec973c3a Is the style here of putting different keys for each service type what we're going with?21:01
vipuloh.. .21:02
arborismNo, just a thought experiment of avoiding a /custer api21:02
datsun180bguess i'd better reread pep8, i'm getting rusty21:02
kevinconwayvipul: grapex: http://javascript.crockford.com/code.html closest you might get to a style guide for JS related things21:02
grapexarborism: Ok21:02
vipularborism: dmakogon_ this might interest you https://wiki.openstack.org/wiki/Reddwarf-versions-types21:02
vipulit is the serviceType api that never got implemented21:02
grapexvipul: Thanks21:02
kevinconwaydatsun180b: http://www.pylint.org/21:03
grapexOne more question - and this may be a can of worms21:03
vipuloh noe grapex :)21:03
grapexand not the fun kind either that jump out like a gag21:03
arborismIs it about users?21:03
arborism;)21:03
grapexbut the bad kind of worms21:03
cp16netdoh21:03
grapexarborism: Lol21:03
grapexSo- the reference guest, as it is today- does it block all incoming RPC calls when doing a backup?21:03
datsun180bkevinconway: a foolish consistency...21:03
dmakogon_vipul: i think we should do that21:03
kevinconwaydatsun180b: meaning if you break consistency ever21:04
kevinconwayfor any reason21:04
vipulSo i don't think we do... since it's asynchronous21:04
SlickNikgrapex: I think it works on one message at a time.21:04
vipulSlickNik: that is correct.. but create backup isn't sync21:04
grapexI ask this because we need the guest to report on the size of the volume even while doing a backup.21:04
cp16netvipul: so its in its own thread when runnning a backup?21:04
vipulwe do spawn a subprocess to take the backup21:05
vipulwhich probably doesn't block21:05
vipuli could be wrong21:05
SlickNikwe spawn a subprocess, yes.21:05
grapexvipul: Ok, so then it can get other RPC calls as it's taking the backup?21:05
grapexJust checking21:05
vipulI _think_ so.. i'd have to get back to you21:05
grapexBy the way this is what Sneaky Pete does in case it's not obvious what I'm driving at. Some of the questions in the meeting today made me think otherwise.21:05
grapexIf it doesn't we can work to change the reference guest21:06
grapexvipul: Ok21:06
vipuli woudl be great to block though :P21:06
vipulso we could do things like upgrade.. and mke sure upgrade only happens after backup is finished21:06
grapexvipul: There are ways around that, like using the trove code that currently checks to see if an action is being performed.21:07
grapexBut that's back to the discussion we already finished up.21:07
grapexSince we're past time21:07
vipulalrighty.. calling it done21:07
vipul#endmeeting21:07
*** openstack changes topic to "OpenStack meetings (alternate)"21:07
openstackMeeting ended Wed Aug 21 21:07:45 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:07
dmakogon_vipul: soon i'll propose my own version of API, that wont ruined current Trove and add new stuff for it21:07
grapexThanks vipul!21:07
cp16netawesome21:07
openstackMinutes:        http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-21-20.00.html21:07
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-21-20.00.txt21:07
openstackLog:            http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-21-20.00.log.html21:07
cp16netthanks!21:07
*** imsplitbit has left #openstack-meeting-alt21:08
SlickNikso grapex, just looked at the code.21:08
vipuldmakogon_: Ok, please write it up21:08
*** dmakogon_ has left #openstack-meeting-alt21:09
*** esp has left #openstack-meeting-alt21:09
*** Riddhi has quit IRC21:13
*** dina_belova has quit IRC21:16
*** betsy has quit IRC21:19
*** tsimmons has joined #openstack-meeting-alt21:21
*** tsimmons has left #openstack-meeting-alt21:21
*** jmontemayor has quit IRC21:21
*** pdmars has quit IRC21:23
*** yogesh has quit IRC21:23
*** yogesh has joined #openstack-meeting-alt21:24
*** SlickNik has left #openstack-meeting-alt21:25
*** yogesh has quit IRC21:26
*** ashestakov has left #openstack-meeting-alt21:28
*** jasonb365 has quit IRC21:30
*** vipul is now known as vipul-away21:32
*** vipul-away is now known as vipul21:35
*** eankutse has quit IRC21:37
*** eankutse has joined #openstack-meeting-alt21:37
*** eankutse has quit IRC21:37
*** SergeyLukjanov has quit IRC21:45
*** robertmyers has quit IRC22:09
*** dina_belova has joined #openstack-meeting-alt22:17
*** dina_belova has quit IRC22:21
*** dina_belova has joined #openstack-meeting-alt22:27
*** dina_belova has quit IRC22:32
*** sarob has joined #openstack-meeting-alt22:38
*** sacharya has quit IRC22:48
*** benl has quit IRC22:53
*** rnirmal has quit IRC23:05
*** NehaV has quit IRC23:11
*** mberwanger has joined #openstack-meeting-alt23:13
*** mberwanger has quit IRC23:21
*** yogesh has joined #openstack-meeting-alt23:24
*** datsun180b has quit IRC23:27
*** dina_belova has joined #openstack-meeting-alt23:28
*** dina_belova has quit IRC23:32
*** yidclare has quit IRC23:40
*** yogesh has quit IRC23:41
*** yidclare has joined #openstack-meeting-alt23:41
*** jcooley has quit IRC23:41
*** yidclare has quit IRC23:42
*** jcooley has joined #openstack-meeting-alt23:44
*** saurabhs has left #openstack-meeting-alt23:51
*** sacharya has joined #openstack-meeting-alt23:51

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