16:01:28 <mugsie> #startmeeting Kosmos
16:01:28 <openstack> Meeting started Tue Sep 22 16:01:28 2015 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:33 <openstack> The meeting name has been set to 'kosmos'
16:01:36 <johnsom> o/
16:01:48 <xgerman> o/
16:01:51 <mugsie> #topic Action Items
16:02:34 <mugsie> nothing outstanding
16:02:43 <mugsie> #topic Architecture - https://review.openstack.org/#/c/223663/
16:02:49 <mugsie> #link https://review.openstack.org/#/c/223663/
16:03:08 <mugsie> I have a few comments that I am addressing - has everyone had a chance to read ^ ?
16:03:30 <johnsom> I have (those are probably my comments you are still addressing...)
16:03:40 <mugsie> johnsom: yup :)
16:03:45 <dougwig> #link http://docs-draft.openstack.org/63/223663/1/check/gate-kosmos-specs-docs/8927647//doc/build/html/specs/liberty/sysarch.html
16:03:48 <mugsie> I did leave a few replies as well
16:04:46 <dougwig> is the api/conductor approach similar to what designate is doing?
16:05:11 <mugsie> kinda - we have a central service - but the name confused people
16:05:23 <mugsie> conductor seems to be the openstack terminology
16:05:43 <mugsie> the idea was that we had one input point to the DB
16:05:44 <dougwig> interesting. neutron has both of those in one process, which has its issues.
16:06:06 <mugsie> yeah - I like the ability to scale out APIs
16:06:29 <KunalGan_> @mugsie .. so the endpoints are VIP's in the regional LB's ?
16:06:41 <mugsie> KunalGan_: yeah
16:06:51 <mugsie> or they could be random IPs as well
16:07:06 <mugsie> what ever we are loadbalancing
16:07:24 <mugsie> that is the reason there is plugins for the status checks
16:07:33 <KunalGan_> So there would be two plugin interfaces for custom implementation.. one for making the entity changes on GSLB and other one for status checks
16:07:39 <mugsie> yup
16:08:12 <KunalGan_> ok.. where does the designate call fit in here ?
16:08:14 <mugsie> for example if I am going to get traction for this with product marketing we would need to support things like AWS
16:08:22 <mugsie> it would be the default GSLB
16:08:44 <mugsie> so the calls to the GSLB driver would be translated to DNS updates via designate
16:09:17 <xgerman> so Designate would be the GSLB appliance in the picture?
16:09:24 <dougwig> KunalGan_: it's the default and primary DNS server for the G in the GSLB.
16:09:29 <mugsie> yup
16:09:35 <dougwig> xgerman: the front half, yes.
16:10:00 <KunalGan_> ok got it..
16:10:27 <xgerman> well, Designate has an API :-)
16:10:56 <mugsie> johnsom: had a good question - "Are we keeping status history in the Database or should we have some sort of logging component or call out?"
16:11:03 <mugsie> what are peoples thoughts on this?
16:11:23 <xgerman> both?
16:11:24 <dougwig> i'm not a fan of huge databases, for scaling reasons. i'd prefer the callout/logging, personally.
16:11:37 <johnsom> I lean towards logging
16:11:48 <KunalGan_> what is the benefit of keeping status history ?
16:11:49 <xgerman> well, users like to have cli commands which show status
16:11:58 <xgerman> history can be in logging
16:12:14 <mugsie> KunalGan_: to show when a change was made, and what triggered it
16:12:25 <johnsom> If you have backend endpoints coming and going it's nice to be able to see that history
16:12:57 <mugsie> yeah. you want users to see *why* a region disappeared
16:13:04 <elarson> +1 logging
16:13:12 <KunalGan_> @mugsie .. if we have to show the history on CLI then wouldn't it be easier to get it from the db rather than logs ?
16:13:24 <mugsie> well, logging could be another DB
16:13:28 <mugsie> or timeseries
16:13:30 <KunalGan_> oh ok
16:13:36 <xgerman> well, what about monasca?
16:13:36 <KunalGan_> @mugsie .. that makes sense..
16:13:45 <elarson> that presents a whole slew of questions regarding linearabilty, but, conceptually +1 :)
16:13:45 <dougwig> if in db, we could also limit it to the last 1000 checks or something, to keep it sane.
16:13:54 <mugsie> xgerman: i would rather not tie us to them just yet
16:13:58 <mugsie> dougwig: ++
16:14:13 <KunalGan_> +1 on limiting it
16:14:15 <mugsie> there would definitly need to be a "prune"
16:15:40 <mugsie> OK, i think that is good feedback
16:15:52 <mugsie> and for MVP we may not need to actually show the history in the API
16:15:59 <KunalGan_> @mugsie .. the default GSLB will be integrated with designate and lbaas. do we know which applicance wr have to support by default
16:16:05 <elarson> +1 re: mvp
16:16:11 <KunalGan_> like an opensource one ?
16:16:28 <mugsie> there is no list yet
16:16:40 <mugsie> but with just LBaaS + Designate it will be functional
16:16:41 <dougwig> KunalGan_: i think we'll end up writing the backend monitors ourselves, for the ref impl.
16:17:05 <mugsie> KunalGan_: oh, by appliance you mean LB appliance?
16:17:05 <KunalGan_> ok..
16:17:28 <dougwig> i think that's what he meant.  so if we use designate+lbaas, the ref will be designate's defaults + haproxy.
16:17:28 <mugsie> dougwig: I think we can have in tree drivers, as long as there is a way of testing them
16:17:41 <KunalGan_> yes.. someone needs to do the health checks against the local VIP
16:18:05 <dougwig> KunalGan_: we could either write those in python, or as mugsie said, we could setup hm's in lbaas and poll lbaas's /stats call for health.
16:18:09 <mugsie> KunalGan_: that would be the status check service
16:18:25 <mugsie> ah, yeah. what dougwig said
16:19:35 <mugsie> OK, anymore feedback?
16:19:41 <KunalGan_> down the line when we have to support more complex GSLB algo's like geo-location, ratio based, etc, would that be supported just by lbaas and designate ?
16:20:05 <mugsie> KunalGan_: designate has those features on the roadmap
16:20:10 <KunalGan_> oh ok
16:20:11 <mugsie> so, hopefully
16:21:05 <dougwig> and hopefully some 3rd party drivers might also expose those things.
16:21:10 <mugsie> yeah
16:21:33 <KunalGan_> on a separate topic, i got a lot of feedback on https://review.openstack.org/#/c/218709/
16:21:55 <KunalGan_> but the code review is not line with the design
16:22:30 <mugsie> KunalGan_: yeah. we decided 2 weeks ago to go more conceptual with the design first
16:22:49 <KunalGan_> do you want me to redo it and align it with the design @mugsie or wait a little bit
16:22:57 <mugsie> KunalGan_: I think we wait a bit
16:22:58 <KunalGan_> before we finalize the design
16:23:03 <KunalGan_> @mugsie .. ok
16:23:09 <mugsie> we can then do the services on a service by service basis
16:23:17 <KunalGan_> ok
16:23:22 <mugsie> as we will have an interface to work against
16:24:28 <dougwig> if you want to rework now with a stock pecan and alembic goo, though, we'll need that.
16:24:29 <mugsie> OK.
16:25:20 <mugsie> #topic Open Discussion
16:25:26 <KunalGan_> ok so pecan is preferred over flask ?
16:25:26 <mugsie> any off agenda items?
16:25:30 <mugsie> KunalGan_: yes
16:25:41 <KunalGan_> i see
16:25:42 <mugsie> well, no, but it is the standard basically
16:25:48 <elarson> :)
16:25:58 <mugsie> both designate + neutron use it now afaik
16:26:02 <KunalGan_> @mugsie .. i was looking at designate code
16:26:10 <mugsie> KunalGan_: I am sorry
16:26:12 <KunalGan_> maybe an older one i guess
16:26:15 <mugsie> :D
16:26:20 <dougwig> i think pecan is what the tc recommends now.
16:26:23 <mugsie> yeah. our V1 API was flask
16:26:29 <mugsie> the v2 API is pecan
16:26:34 <KunalGan_> ok
16:26:46 <mugsie> with a few fixes in our tree
16:26:53 <dougwig> neutron's old server was/is totally homebrew.  *shudder*.
16:26:54 <xgerman> flask is so much better
16:26:59 <mugsie> it is
16:27:10 <xgerman> yeah, wonder what pecan paid the TC?
16:27:17 <mugsie> but if both related projects use pecan, we should probably use it
16:27:35 <dougwig> i'm open to either, if the team feels strongly. it's just a wsgi server to me.
16:27:48 <KunalGan_> @dougwig .. +1. either is fine
16:28:00 <mugsie> yeah. not really pushed, just like to have commonalities
16:28:14 <KunalGan_> ok. i can take a task to switch the API to pecan from flask
16:28:30 <xgerman> flask is fine ;-)
16:28:32 <KunalGan_> since that might not change a lot
16:28:34 <elarson> cherrypy ?
16:28:50 <elarson> http://ionrock.org/2013/01/30/CherryFlask.html
16:28:50 <mugsie> elarson: :|
16:29:01 <xgerman> Werkzeug all the way
16:29:16 <mugsie> webob ++
16:29:24 * mugsie needs to stop feedin the bikeshed
16:29:42 <mugsie> OK, anything else for the meeting?
16:29:53 <dougwig> it gets crazy enough and i'm gonna ask for rails or sinatra.
16:30:07 <dougwig> this is where i usually get dirty stares.
16:30:23 <mugsie> :)
16:30:24 * johnsom stares at dougwig
16:30:37 <mugsie> https://kore.io/
16:30:42 <mugsie> done
16:30:44 <mugsie> :D
16:31:04 <KunalGan_> :)
16:31:55 <mugsie> OK. if thats it - shall we call the meeting adjourned?
16:32:13 <xgerman> it was just starting to be fun...
16:33:51 <mugsie> OK - see you in #openstack-gslb
16:33:54 <mugsie> #endmeeting