Monday, 2014-12-01

*** ivar-lazzaro has quit IRC00:06
*** ivar-lazzaro has joined #openstack-meeting-300:21
*** alexpilotti has quit IRC00:33
*** lhcheng has quit IRC01:00
*** ivar-lazzaro has quit IRC01:07
*** ivar-lazzaro has joined #openstack-meeting-301:07
*** shwetaap has joined #openstack-meeting-301:16
*** shwetaap1 has joined #openstack-meeting-301:17
*** shwetaap has quit IRC01:20
*** sarob has quit IRC01:22
*** wuhg has joined #openstack-meeting-301:22
*** yamahata has joined #openstack-meeting-301:33
*** stanzgy has joined #openstack-meeting-301:35
*** yamahata has quit IRC01:39
*** persia has quit IRC01:41
*** persia has joined #openstack-meeting-301:43
*** etoews has joined #openstack-meeting-301:57
*** jacalcat has joined #openstack-meeting-302:21
*** jacalcat has left #openstack-meeting-302:21
*** etoews has quit IRC02:33
*** Ark has joined #openstack-meeting-302:35
*** Ark is now known as Guest4465302:36
*** smoriya_ has joined #openstack-meeting-302:40
*** smoriya_ has quit IRC02:41
*** ivar-laz_ has joined #openstack-meeting-302:52
*** ivar-lazzaro has quit IRC02:54
*** ivar-laz_ has quit IRC03:33
*** vkmc has quit IRC03:55
*** ivar-lazzaro has joined #openstack-meeting-304:04
*** shwetaap has joined #openstack-meeting-304:08
*** shwetaap1 has quit IRC04:09
*** armax has quit IRC04:10
*** ivar-lazzaro has quit IRC04:10
*** shwetaap has quit IRC04:17
*** shwetaap has joined #openstack-meeting-304:17
*** dconde has joined #openstack-meeting-305:27
*** dconde has quit IRC05:30
*** ivar-lazzaro has joined #openstack-meeting-305:38
*** mwagner_lap has quit IRC05:41
*** ivar-lazzaro has quit IRC05:42
*** Guest44653 has quit IRC05:53
*** mwagner_lap has joined #openstack-meeting-305:53
*** amotoki has joined #openstack-meeting-306:05
*** amotoki has quit IRC06:05
*** baoli has quit IRC06:06
*** dconde has joined #openstack-meeting-306:10
*** dconde has quit IRC06:11
*** iovadia has joined #openstack-meeting-306:14
*** iovadia has quit IRC06:19
*** dconde has joined #openstack-meeting-306:19
*** Longgeek has joined #openstack-meeting-306:21
*** Longgeek has quit IRC06:25
*** iovadia has joined #openstack-meeting-306:33
*** obondarev has quit IRC06:38
*** ivar-lazzaro has joined #openstack-meeting-306:38
*** obondarev has joined #openstack-meeting-306:39
*** sarob has joined #openstack-meeting-306:45
*** ivar-lazzaro has quit IRC06:48
*** baoli has joined #openstack-meeting-306:50
*** Longgeek has joined #openstack-meeting-306:53
*** Longgeek has quit IRC06:54
*** Longgeek has joined #openstack-meeting-306:54
*** Longgeek has quit IRC06:55
*** mrunge has joined #openstack-meeting-306:55
*** Longgeek has joined #openstack-meeting-306:55
*** mrunge has quit IRC06:56
*** Adri2000 has quit IRC06:56
*** Longgeek has quit IRC06:57
*** Longgeek_ has joined #openstack-meeting-306:57
*** Longgeek_ has quit IRC06:59
*** Longgeek has joined #openstack-meeting-307:01
*** Longgeek has quit IRC07:02
*** baoli has quit IRC07:06
*** mrunge has joined #openstack-meeting-307:08
*** sarob has quit IRC07:10
*** jcoufal has joined #openstack-meeting-307:24
*** k4n0 has joined #openstack-meeting-307:24
*** amotoki has joined #openstack-meeting-307:31
*** mrmartin has joined #openstack-meeting-307:39
*** evgenyf has joined #openstack-meeting-307:50
*** sergef has joined #openstack-meeting-307:53
*** obondarev_ has joined #openstack-meeting-308:03
*** Longgeek has joined #openstack-meeting-308:03
*** obondarev has quit IRC08:04
*** obondarev_ has quit IRC08:05
*** obondarev has joined #openstack-meeting-308:05
*** salv-orlando has joined #openstack-meeting-308:06
*** devvesa has joined #openstack-meeting-308:06
*** Longgeek has quit IRC08:08
*** rcleere is now known as rcleere_away08:11
*** mrmartin has quit IRC08:18
*** mrmartin has joined #openstack-meeting-308:20
*** jtomasek has joined #openstack-meeting-308:24
*** [1]evgenyf has joined #openstack-meeting-308:29
*** evgenyf has quit IRC08:32
*** [1]evgenyf is now known as evgenyf08:32
*** aleksandr_null has quit IRC08:33
*** ivar-lazzaro has joined #openstack-meeting-308:44
*** MaxV has joined #openstack-meeting-308:47
*** ivar-lazzaro has quit IRC08:49
*** ekarlso- has quit IRC08:52
*** Longgeek has joined #openstack-meeting-308:57
*** Longgeek_ has joined #openstack-meeting-309:08
*** Longgeek_ has quit IRC09:09
*** Longgeek_ has joined #openstack-meeting-309:09
*** ekarlso- has joined #openstack-meeting-309:09
*** Longgeek has quit IRC09:10
*** matrohon has joined #openstack-meeting-309:19
*** ozamiatin has quit IRC09:22
*** pkarikh has joined #openstack-meeting-309:37
*** igordcard has joined #openstack-meeting-309:49
*** Longgeek_ has quit IRC09:57
*** Longgeek has joined #openstack-meeting-309:58
*** Longgeek_ has joined #openstack-meeting-310:15
*** Longgeek has quit IRC10:18
*** alexpilotti has joined #openstack-meeting-310:43
*** ivar-lazzaro has joined #openstack-meeting-310:46
*** ivar-lazzaro has quit IRC10:51
*** stanzgy has quit IRC10:54
*** Longgeek_ has quit IRC11:00
*** Longgeek has joined #openstack-meeting-311:09
*** jcoufal has quit IRC11:22
*** vkmc has joined #openstack-meeting-311:23
*** Adri2000 has joined #openstack-meeting-311:43
*** Longgeek has quit IRC11:50
*** Longgeek has joined #openstack-meeting-311:53
*** yamahata has joined #openstack-meeting-311:57
*** belmoreira has joined #openstack-meeting-312:05
*** Ark has joined #openstack-meeting-312:18
*** Ark is now known as Guest5143312:18
*** Guest51433 has quit IRC12:22
*** bradjones has quit IRC12:26
*** bradjones has joined #openstack-meeting-312:27
*** yamahata has quit IRC12:27
*** sergef has quit IRC12:34
*** ivar-lazzaro has joined #openstack-meeting-312:47
*** igordcard has quit IRC12:50
*** ivar-lazzaro has quit IRC12:52
*** ozamiatin has joined #openstack-meeting-312:56
*** evgenyf has quit IRC13:04
*** etoews has joined #openstack-meeting-313:32
*** etoews has quit IRC13:37
*** ttrifonov is now known as zz_ttrifonov13:41
*** thomasem has joined #openstack-meeting-313:46
*** thomasem has quit IRC13:47
*** thomasem has joined #openstack-meeting-313:48
*** ivar-lazzaro has joined #openstack-meeting-313:48
*** baoli has joined #openstack-meeting-313:53
*** ivar-lazzaro has quit IRC13:53
*** baoli has quit IRC13:55
*** baoli has joined #openstack-meeting-313:56
*** mattfarina has joined #openstack-meeting-314:00
*** mwagner_lap has quit IRC14:00
*** lhcheng has joined #openstack-meeting-314:13
*** markmcclain has joined #openstack-meeting-314:19
*** sergef has joined #openstack-meeting-314:21
*** igordcard has joined #openstack-meeting-314:22
*** dboik has joined #openstack-meeting-314:26
*** belmoreira has quit IRC14:27
*** thangp has joined #openstack-meeting-314:31
*** Longgeek_ has joined #openstack-meeting-314:32
*** shwetaap has quit IRC14:33
*** Longgeek has quit IRC14:33
*** shwetaap has joined #openstack-meeting-314:33
*** jroll has joined #openstack-meeting-314:47
*** peristeri has joined #openstack-meeting-314:47
*** ivar-lazzaro has joined #openstack-meeting-314:49
*** julim has joined #openstack-meeting-314:50
*** armax has joined #openstack-meeting-314:52
*** alexpilotti has quit IRC14:53
*** ivar-lazzaro has quit IRC14:54
*** rcleere_away is now known as rcleere14:56
*** sigmavirus24_awa is now known as sigmavirus2414:58
*** dynarro has joined #openstack-meeting-314:58
flaper87#startmeeting Zaqar15:00
openstackMeeting started Mon Dec  1 15:00:02 2014 UTC and is due to finish in 60 minutes.  The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
*** openstack changes topic to " (Meeting topic: Zaqar)"15:00
openstackThe meeting name has been set to 'zaqar'15:00
*** jpomero has joined #openstack-meeting-315:00
flaper87good morning world15:00
flaper87#topic Roll Call15:00
*** openstack changes topic to "Roll Call (Meeting topic: Zaqar)"15:00
flaper87(o/15:00
kragniz\o/15:00
flaper87(o)15:00
flaper87\o)15:00
flaper87kragniz: you ruined my dance15:00
kragnizflaper87: sorry, man15:00
kragniz\o\15:00
kragniz/o/15:00
flaper87kragniz: are you skiing ?15:01
flaper87that's not dancing15:01
flaper87:P15:01
flaper87vkmc: ?15:01
vkmco/15:01
flaper87I guess kgriffs will join in a bit15:01
flaper87aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanyway15:01
flaper87#topic Agenda15:01
*** openstack changes topic to "Agenda (Meeting topic: Zaqar)"15:01
flaper87#link https://wiki.openstack.org/wiki/Meetings/Zaqar#Agenda15:01
flaper87that's what we have for today15:02
flaper87We still have 2 more specs to review and we're dong with that for a bit15:02
*** sriram has joined #openstack-meeting-315:02
flaper87#topic Deprecate sqlalchemy for the data plane15:02
*** openstack changes topic to "Deprecate sqlalchemy for the data plane (Meeting topic: Zaqar)"15:02
flaper87#link https://review.openstack.org/#/c/134248/15:02
flaper87Any initial comments on that?15:02
flaper87The TL;DR is that we were planning to get rid of sqlalchemy15:03
flaper87at least on the data plane15:03
flaper87That means you would still be able to use it to store pools, flavors etc15:03
flaper87but not to store messages15:03
vkmchow hard would be to update it and maintain it in the codebase?15:03
flaper87However, after some extra consideration, we (or was it just me?) also mentioned that we should just get rid of it entirely15:04
vkmccommunity has shown interest in sql backends15:04
flaper87We could keep it outside as an external driver15:04
vkmcthat sounds good15:04
flaper87In stackforge15:05
vkmcwe know that for Zaqar's use case sql is no good15:05
flaper87it'd have gates and whatnot15:05
vkmcwell, maybe we have to look into that again and look for other sql alternatives15:05
vkmcI'm speaking without certainty15:05
flaper87vkmc: that may be an overstatement. Depending on how it's implemented and configured, rdbms could also work very well15:05
flaper87however, as of now, the implementation is not good, not optimized and it's being quite a pain to maintain15:06
vkmcyeah, that's why I'm saying that we might need to look into that again15:06
vkmcall right15:06
vkmcanother concern15:06
flaper87Shipping something that works with things like mysql but doesn't work well is not good for the project reputation15:06
vkmcwe use sqlite for testing... a lot15:06
flaper87right15:06
vkmcremoving it would make testing heavier15:06
flaper87right15:06
vkmcso... we need something in between maybe15:07
flaper87Do we?15:07
flaper87I mean, is it really that bad to ask devs to have mongodb installed ?15:07
flaper87or redis15:07
vkmcI don't think it is15:07
vkmcbut15:07
flaper87We used to have an sqlite only driver but again, we have to maintain it15:07
vkmcI'm not an operator15:08
vkmcwe should ask this on the list and try to get feedback15:08
vkmcif you didn't do that already :)15:08
flaper87wait, this is devs we're talking about15:08
flaper87I really hope there's noone deploying Zaqar + sqla15:08
vkmcyeah me too15:09
vkmcwell... in the case of devs...15:09
flaper87we gave it a full cycle for deprecation15:09
flaper87now it's time to remove it15:09
vkmcI dunno... if you are deploying a cloud I could assume you won't have trouble deploying mongo15:09
vkmcright...?15:10
flaper87As far as tests go, I'm just concerned about devs installing mongodb somewhere15:10
flaper87to test this whole thing15:10
flaper87to be fair15:11
flaper87we could also just keep the sqlalchemy code, rename it to sqlite, use it as is and allow just "sqlite" url's15:11
flaper87That would keep testing easy15:12
flaper87we can try to maintain that code just for sqlite15:12
*** cpallares has joined #openstack-meeting-315:12
vkmcmh..15:12
*** nelsnelson has joined #openstack-meeting-315:12
flaper87if someone is interested in making it work well with mysql and psql then fine15:12
vkmchow that is different from keeping sqlalchemy?15:12
flaper87we'd just keep it as-is, rename the package to sqlite (or not), forbid url's for things that are not sqlite15:13
vkmcI like that approach15:14
*** ChuckC has quit IRC15:14
flaper87what about the renaming?15:14
*** ChuckC has joined #openstack-meeting-315:14
vkmcnobody will use sqlite for production and its default in most distros15:15
vkmclet's adjust sqlalchemy to be sqlite15:15
flaper87renaming it would clear any doubt15:15
flaper87ok15:15
vkmcfor tests we need sqlite15:15
flaper87If someone wants to copy that code, make it better, etc. Then, be my guest15:15
vkmcneat15:15
vkmcwe should submit a blueprint for that15:16
vkmcif its not already there15:16
flaper87There's a spec but I now have to update it15:16
flaper87#link https://review.openstack.org/#/c/134248/15:16
vkmc<315:16
flaper87ok, moving on15:16
sriramjust a thought here, have you looked at mocking frameworks?15:16
*** k4n0 has quit IRC15:16
srirammongomock, fakeredis.15:16
flaper87sriram: erm, nope15:17
sriramthat could remove dependency on sqlite for tests.15:17
flaper87sriram: sounds interesting15:17
flaper87sriram: do you have a link ?15:17
sriramsure gimme one sec.15:17
vkmcsriram, that sounds cool15:17
sriramhttps://github.com/jamesls/fakeredis15:17
sriramhttps://github.com/vmalloc/mongomock15:17
sriramobviously there could be better versions out there.15:17
sriramthese are ones I know of.15:18
vkmcneat!15:18
flaper87awesome, I'll take a look and update the spec based on that15:18
flaper87thanks, sriram15:18
vkmc:D thanks sriram15:18
sriramglad I can help :)15:18
flaper87#topic Deprecate queues in favor of topics15:18
*** openstack changes topic to "Deprecate queues in favor of topics (Meeting topic: Zaqar)"15:18
flaper87#link https://review.openstack.org/#/c/134015/15:18
flaper87So, no need to decide that right now, that will likely slip to k-2 anyway15:19
flaper87but please, lets take a better look at that spec and review it thoroughly15:19
flaper87it's quite a change and we need to be sure about it15:19
*** alexpilotti has joined #openstack-meeting-315:19
flaper87there were interesting comments w.r.t getting messages from the topic15:20
flaper87and how the URL should be formatted15:20
*** rcleere is now known as rcleere_away15:20
*** ChuckC has quit IRC15:20
flaper87comments?15:21
flaper87thoughts?15:21
flaper87worries?15:21
flaper87gummy bears?15:21
flaper87hugs ?15:21
* flaper87 is talking to himself15:21
* vkmc checks the spec15:21
vkmcgummy bears and hugs pls15:21
flaper87vkmc: awesome15:22
flaper87no need to go throught right now, Lets have a more detailed discussion about it next week15:22
vkmcso... well, I agree that we might no need to change the url15:22
*** rcleere_away is now known as rcleere15:23
flaper87ok, moving on15:23
vkmcas Gordon mentioned, it doesn't mean that we are dealing with containers (queues/topics) as first-class citizens15:23
* flaper87 stops15:23
vkmcand it allows us to have a more intuitive API15:24
flaper87right, but it does have a meaning for REST Apis15:24
flaper87it means there's a "resource"15:24
vkmcoh... true that15:24
flaper87the difference is that it'll be a virtual resource15:24
*** etoews has joined #openstack-meeting-315:24
vkmcdoes REST specify how virtual resources should be accessed?15:25
*** alexpilotti has quit IRC15:25
*** lhcheng has quit IRC15:25
flaper87AFAIK, it says nothing about virtual resources15:25
flaper87I just made that up15:25
flaper87:P15:25
vkmclol15:25
vkmcyou should totally propose the term15:26
*** alexpilotti has joined #openstack-meeting-315:26
vkmcand add some specs for it15:26
* flaper87 for president15:26
vkmchaha15:26
vkmcok, let's discuss about this later if you please15:26
vkmcI'm really sorry that we didn't get feedback in the mailing list15:26
flaper87sure thing15:26
flaper87yeah15:27
vkmcthat would make things easier15:27
flaper87ok15:28
flaper87moving on15:28
flaper87#topic Do we need message_data in config files?15:28
*** openstack changes topic to "Do we need message_data in config files? (Meeting topic: Zaqar)"15:28
flaper87So, exploreshafali is working on splitting the control and the data planes15:28
flaper87That means we'll have 2 new sections in our config files15:28
flaper87message_plane and data_plane15:28
flaper87Those sections will be used to configure the database for each plane15:29
flaper87There are 2 questions:15:29
*** dboik_ has joined #openstack-meeting-315:29
flaper871) Do we want to keep supporting non-pooled Zaqar deployments ?15:29
flaper872) Assuming pools are enabled, can we just forbid using Zaqar in non-pooled mode?15:30
flaper87I mean, if someone enables pools, we currently allow them to use it with and without pools15:31
flaper87(AFAIR :P)15:31
vkmcyeah15:31
flaper87Which creates the whole problem with both planes being together15:31
*** tsufiev has left #openstack-meeting-315:32
flaper87What if instead of splitting them, we just forbid people to use Zaqar in a non-pooled way when pools are enabled15:32
vkmcI think that would be a better solution15:32
flaper87I think she's going to kill me15:32
flaper87you tell her15:32
flaper87:P15:32
*** jtomasek has quit IRC15:32
*** dboik has quit IRC15:33
vkmchaha15:33
*** jtomasek has joined #openstack-meeting-315:33
vkmcwe can get another thing for her15:33
flaper87ok, I'll run this through Kurt as well before we make a final call15:33
flaper87I'd also like to get her feedback on this15:33
vkmcsounds good15:33
vkmcIMO we shouldn't work to fix users negligence15:34
vkmcbut constrain it15:34
flaper87yeah15:34
vkmcsplitting planes would take more work than forbbiding 0 pools in a pooled deployment15:34
vkmcfor that, you have the non-pooled deployment15:34
flaper87also, there's the whole deprecation thing15:34
flaper87and more sections15:34
vkmcyeah15:34
flaper87and config duplication15:34
flaper87ok15:34
vkmcmore trouble15:35
vkmcmore manteinance15:35
vkmcmore code15:35
* vkmc -> moar!15:35
flaper87Yeah, we don't want more trouble... we already have you15:35
vkmcthat is my mission here in Zaqar15:35
flaper87trouble-maker15:35
flaper87ok, that's all I had15:36
vkmchaha15:36
flaper87I guess we can jump into open discussions or just close the discussion for today15:36
flaper87:P15:36
vkmcsure :)15:36
flaper87it's not like we won't keep talking in #os-zaqar anyway15:36
vkmcwe also have the osprofiler spec15:36
*** kgriffs has joined #openstack-meeting-315:36
vkmcoh wait15:36
vkmcwait...15:36
flaper87vkmc: do we? I didn't see it15:36
flaper87kgriffs: just joined15:36
vkmckgriffs has joined15:36
flaper87miracles happen15:36
vkmchahahaha15:36
kgriffslol, sorry had a meeting conflict15:37
flaper87yeah yeah, that's what everyone says15:37
vkmchttps://review.openstack.org/#/c/135612/15:37
flaper87kgriffs: we went through some specs but we deferred the discussion 'til next week15:37
flaper87we need to provide more reviews there15:37
flaper87that said, we were now talking about whether we really need to split control and data plane15:38
kgriffsoic15:38
flaper87kgriffs: TL;DR: If pooling is enabled, can't we just forbid users to use zaqar in a non-pooled way?15:38
flaper87ah wait15:38
flaper87no yeah, that15:39
flaper87:P15:39
flaper87sorry, had one of those moments15:39
kgriffsmmm15:39
flaper87that way we can still keep it under the same config section, avoid duplicating options15:39
flaper87and deprecating the ones we have15:39
flaper87fewer docs to write, etc15:40
flaper87The "etc" is the most important bit there15:40
kgriffsso15:40
flaper87:D15:40
kgriffsis this different from having "always on pools"15:40
flaper87That was the other question15:40
flaper87but yes, it's different15:40
kgriffsok15:40
vkmcthat other question.. I would say no15:40
flaper87It'd, however, make the transition to "always pools" easier15:41
flaper87(if we ever decide to do so)15:41
kgriffslet me see if I understand15:41
kgriffsI thought that when you enable pooling, you already can't do anything "non-pooled"15:42
kgriffslike, it is all-or-nothing15:42
vkmckgriffs, you can enable pooling and don't have pools15:42
*** devlaps has joined #openstack-meeting-315:43
kgriffswhen you enable pooling, doesn't that cause the pooled driver to get loaded in between every interaction, so you have to have pools then?15:43
kgriffs(technically, the proxy controllers that the pool driver exposes)15:43
flaper87kgriffs: yes, but I think you can still create a queue and post messages15:43
* vkmc tries it15:44
flaper87if the queue doesn't exist, I believe it just uses the default config15:44
flaper87OMG, we should know this15:44
kgriffsbefore flavors, it would just shard the queues across all available pools15:44
flaper87but if there were no pools it'd just use the same configs15:45
flaper87AFAIR15:45
kgriffsyou create a queue and it would hit the proxy queue controller. that would add the queue to the catalog so it is mapped to a pool15:45
kgriffsflaper87: I thought it would just raise an error if there were no pools to choose from15:45
flaper87mmh, damn, now I'm confused15:45
kgriffsor perhaps that is what I would have expected, if it isn't the reality15:45
flaper87kgriffs: same here15:45
kgriffsin my mind, pools were always all-or-nothing15:45
flaper87if that's the case, then why are we doing this in the first place?15:46
*** salv-orlando has quit IRC15:46
flaper87I mean, splitting both planes15:46
flaper87I think I just lost track of the motivation behind this work15:46
kgriffslet me see15:46
flaper87actually, the benefits15:46
kgriffsI think we discussed that an operator may not want to use the same data store type for control vs. data15:47
kgriffsor they may want to use different settings15:47
*** marun has joined #openstack-meeting-315:47
kgriffslike have more strict/safe replication settings in the connection settings15:47
kgriffs(for control)15:47
flaper87right but pools are configured through the API15:47
flaper87When you create a pool, you have to specify the connection URI15:47
kgriffsgood point15:48
flaper87it wouldn't use the same store unless you tell it to do so15:48
kgriffsso then you should still be able to mix-and-match15:48
flaper87right15:48
*** salv-orlando has joined #openstack-meeting-315:48
kgriffsbut really, I recall something about the original motivation15:48
kgriffsbeing more architectural - it was messy to glom the two drivers together in the same bucket15:49
flaper87ok15:49
kgriffsalso15:49
kgriffsit is confusing to have the same config section be used for the catalog/control when pooling is enabled, but the data store when pooling is not enabled.15:50
kgriffsthat being said15:50
vkmcbtw, it raises an error15:50
flaper87vkmc: good15:50
kgriffsperhaps we are taking a hatchet to this when we really need a scalpel15:50
*** ivar-lazzaro has joined #openstack-meeting-315:50
vkmchttp://paste.openstack.org/show/142676/15:50
flaper87kgriffs: indeed, I started thinking about that earlier today15:50
kgriffsi think the root of the problem is the dual-mode15:51
kgriffsif you do not use pooling, yeah then having a couple config sections is necessary15:51
kgriffs(in order to mix-and-match)15:51
flaper87so, having some nodes non-pooled and others pooled15:52
kgriffsif you do have pooling, a single config section (as we have today) is groovy. We may still want to move control stuff into its own module inside each driver directory, but that is just refactoring15:52
kgriffsflaper87: no, I mean when non-pooled15:52
kgriffsI may want to use different driver settings for my catalog vs. my message data15:52
flaper87kgriffs: why if you're in a non-pooled mode?15:53
flaper87AH WAIT15:53
flaper87I remember the real motivation15:53
kgriffsred bull?15:53
flaper87we wanted to move queue's out of the data plane15:53
kgriffsoh, and put their info somewhere else?15:54
flaper87therefore we needed a way to split both planes even in a non-pooled mode15:54
flaper87yeah15:54
kgriffsyeah, I you are right. that was another reason15:54
kgriffshmm15:54
* flaper87 is right15:54
* flaper87 won't give kgriffs gummy bears15:54
kgriffs(happens sometimes on accident)15:54
kgriffs;)15:54
flaper87:P15:54
flaper87ok, we solved the mistery15:54
vkmcok15:55
vkmcplease15:55
vkmcwrite it down15:55
kgriffsok, so here is the thing15:55
vkmcsomewhere15:55
flaper87It was the majordomo15:55
flaper87in the living room15:55
*** ivar-lazzaro has quit IRC15:55
flaper87with a knife15:55
flaper87:P15:55
kgriffsin an ideal world we would say pools are always on15:55
flaper87That dude cut both planes into 215:55
flaper87kgriffs: I kinda agree15:55
kgriffsthen you always have that config section mean the same thing15:55
kgriffsand it already gives you a way to use different data stores15:55
flaper87with just 1 config section15:56
kgriffsso if you want that, please use pools15:56
flaper87:)15:56
flaper87oh no wait15:56
*** dboik_ has quit IRC15:56
flaper87we would still want to have 215:56
flaper87probably15:56
flaper87to have a default one15:56
flaper87no idea15:56
flaper87that'd be confusing15:56
vkmc2'15:56
*** dboik has joined #openstack-meeting-315:57
kgriffswe are almost out of time, but I don't think there is another meeting after us is there?15:57
flaper87vkmc: SSSSSSSSSSSHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH15:57
flaper87kgriffs: I've oslo's15:57
flaper87we should discuss this further15:57
flaper87in the channel, perhaps15:57
kgriffsyes15:57
flaper87rock on15:57
flaper87thanks for all those thoughts15:57
*** julim has quit IRC15:57
krotscheckYep. Stoyrboard is here in 315:57
flaper87krotscheck: 215:58
flaper87:P15:58
flaper87ok, we're out!15:58
vkmcthanks guys o/15:58
flaper87Thank y'all15:58
flaper87#endmeeting15:58
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:58
openstackMeeting ended Mon Dec  1 15:58:20 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:58
openstackMinutes:        http://eavesdrop.openstack.org/meetings/zaqar/2014/zaqar.2014-12-01-15.00.html15:58
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/zaqar/2014/zaqar.2014-12-01-15.00.txt15:58
openstackLog:            http://eavesdrop.openstack.org/meetings/zaqar/2014/zaqar.2014-12-01-15.00.log.html15:58
krotscheck#startmeeting StoryBoard16:00
openstackMeeting started Mon Dec  1 16:00:25 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: StoryBoard)"16:00
openstackThe meeting name has been set to 'storyboard'16:00
*** nibalizer has joined #openstack-meeting-316:00
krotscheckAgenda! https://wiki.openstack.org/wiki/StoryBoard#Agenda16:00
*** CTtpollard has joined #openstack-meeting-316:00
krotscheck#topic Actions from last week.16:01
*** openstack changes topic to "Actions from last week. (Meeting topic: StoryBoard)"16:01
*** wdutch has joined #openstack-meeting-316:01
* krotscheck reorganized things. Roadmap and meeting agendas are updated.16:01
*** julim has joined #openstack-meeting-316:01
krotscheckI also pinged persia and rainya about their own pieces. persia stated that he’d finally start having time again this week, rainya is in singapore on a school trip and will likely be able to come back on board after.16:02
fungiawesome16:02
krotscheckfungi: I totally forgot to ping you about storyboard-dev.openstack.org last week.16:02
*** mattfari_ has joined #openstack-meeting-316:02
*** mattfarina has quit IRC16:02
fungikrotscheck: 's okay. i totally didn't have time. maybe later this week16:02
* krotscheck may have been suffering a turkey coma.16:02
krotscheckAlright!16:02
*** jfjoly has joined #openstack-meeting-316:03
krotscheck#action krotscheck Pester fungi about storyboard-dev.openstack.org16:03
fungisounds great16:03
krotscheck#topic User Feedback16:03
*** openstack changes topic to "User Feedback (Meeting topic: StoryBoard)"16:03
ttxo/16:03
krotscheckI’ve captured a few issues raised in channel.16:03
*** carl_baldwin has joined #openstack-meeting-316:03
*** yolanda has joined #openstack-meeting-316:03
krotscheckThe first is related to mbitard’s inability to log in. At all.16:03
krotscheckI’ve been poking at it, but haven’t been able to figure out exactly why he hasn’t been able to do so. Apparently he’s encountering a reproducible 500 error.16:04
fungidid you get any clearer details on that? or retries?16:04
krotscheckNo retries, unfortunately16:04
*** mattfari_ has quit IRC16:04
krotscheckDoes anyone want to take this on and see if we can at least coordinate logs + retry?16:05
*** cpallares has left #openstack-meeting-316:05
fungiif it happens at a known time i can try to pare down the logs well enough to spot it, but whatever the issue it didn't mention that username16:05
krotscheckAnd capture a good output?16:05
fungiknowing the source ip address would also be great16:05
* SergeyLukjanov lurking16:05
krotscheckNo volunteers? Hoookay.16:05
yolandai can do it16:05
krotscheckyolanda: Thanks!16:06
*** david-lyle_afk is now known as david-lyle16:06
yolandakrotscheck, is there any story filed?16:06
krotscheckyolanda: Not yet, since he couldn’t log in to file a story.16:06
yolandaof course :)16:06
*** mattfarina has joined #openstack-meeting-316:06
jeblairkrotscheck: was he in irc?16:06
krotscheck#action krotscheck File a story for mbitard’s login issue.16:06
krotscheckjeblair: He was. This was 2 weeks ago.16:06
krotscheckjeblair: We tried to go off of his comment timestamp, that didn’t work :/16:07
yolandakrotscheck, will be useful to have logs about it, do we have that available?16:07
* SergeyLukjanov looking on server logs16:07
krotscheckyolanda: We already had fungi go look back when it happened. He wasn’t able to whittle things down, so we’re hoping to capture mbitard and an infra-core online at the same time so we can capture an actual event.16:08
krotscheckyolanda: That’d be the first step.16:08
fungiyolanda: SergeyLukjanov: i already went through the logs. the trick is that we're logging all manner of errors but none which mention that account name and we have no feedback from the user as to when they got the error16:08
SergeyLukjanovokay16:09
krotscheck#action krotscheck File a story for storyboard spamming log errors.16:09
fungiso step 1 is to find this user and get them to try again under more controlled circumstances (get approximate timestamps, find out the source ip address, et cetera)16:09
fungiotherwise i don't think it will be able to move forward16:09
*** vdrok has joined #openstack-meeting-316:10
*** rcarrillocruz has joined #openstack-meeting-316:10
yolandado we have contact details for that user?16:10
krotscheckNext issue: reed reported that the project group summary page does not actually filter stories by project group.16:10
SergeyLukjanovfungi, where the log files located? I see the /var/log/storyboard empty16:10
fungiSergeyLukjanov: apache logs16:10
krotscheckyolanda: he’s mbitard on irc.16:10
*** sriram has left #openstack-meeting-316:10
SergeyLukjanovfungi, thx16:10
fungiSergeyLukjanov: they're the access and error logs for the storyboard vhost16:10
*** gothicmindfood has joined #openstack-meeting-316:11
fungiSergeyLukjanov: since it runs as a subprocess of the apache daemon16:11
krotscheckCase and point: https://storyboard.openstack.org/api/v1/stories?project_group_id=5716:12
krotscheck(57 is storyboard)16:12
krotscheckSo that’s something that should be fairly straightforward to build some test cases and fix.16:12
krotscheckAnyone want to pick into the API and figure this out? Else I’ll do it.16:13
krotscheck#action krotscheck File a story for project group ID not working on stories API, fix.16:13
krotscheckThird issue is how Storyboard tends to log you out in a nonrecoverable manner. jedimike is on that.16:14
krotscheck#action krotscheck make sure that there’s a story for the login issue and assign it to jedimike.16:14
yolandakrotscheck, i created a story for it16:14
krotscheckyolanda: Awesome.16:14
krotscheckyolanda++16:14
krotscheck#undo :)16:14
openstackRemoving item from minutes: <ircmeeting.items.Action object at 0x3dd1f10>16:14
krotscheckWhoa, that works?16:15
krotscheckNeat!16:15
krotscheck#topic Urgent Items16:15
*** openstack changes topic to "Urgent Items (Meeting topic: StoryBoard)"16:15
krotscheckNone on the agenda, does anyone have one to raise?16:15
rcarrillocruzi have something, but not urgent16:15
rcarrillocruznot sure if applicable now16:15
rcarrillocruzhttps://storyboard.openstack.org/#!/story/15316:15
rcarrillocruzi've looked a bit about it this weekend16:15
rcarrillocruzhow about a websocket streaming api16:16
rcarrillocruzi think we could do this API around gevent-socketio, so consumers can subscribe to streams of events based on filters16:16
krotscheckFor reference: https://review.openstack.org/#/c/105252/16:16
NikitaKonovalovrcarrillocruz: I thought krotscheck had a spec for that16:16
rcarrillocruzetc16:16
rcarrillocruzk thx16:17
krotscheckAnd yes, it says WebSocket.16:17
krotscheck:D16:17
rcarrillocruzheh16:17
krotscheck(great minds, think alike, rcarrillocruz )16:17
rcarrillocruzi'm glad it wasn't a totally mad idea16:17
rcarrillocruzkrotscheck: have you started with it yet?16:17
krotscheckI know that there are other opinions about using the jabber protocol, however I’ve only received those in person.16:17
krotscheckrcarrillocruz: I have not. Go nuts!16:17
rcarrillocruzi haven't fiddled with storyboard yet, but i'm looking to start with something16:18
*** jedimike has joined #openstack-meeting-316:18
krotschecki.e. go for it.16:18
rcarrillocruzawesome16:18
krotscheckrcarrillocruz: Fair warning, taht’s a large piece of code.16:18
rcarrillocruzyou can put me as an action16:18
jedimikeo/ sorry i'm late16:18
rcarrillocruzyeah, i'll take an exploratory approach16:18
jeblairkrotscheck: should i add that spec to the priority spec list?16:18
NikitaKonovalovAs for an implementation of that I've not seen WebSocket frameworks used in OpenStack16:18
krotscheckjeblair: I don’t think so, it’s not on our critical path.16:18
*** dynarro has quit IRC16:18
krotscheck#action rcarrillocruz Start working on the storyboard streaming API.16:19
NikitaKonovalovso we need to find a framework for that16:19
krotscheckNikitaKonovalov: Yeah, i don’t think openstack does a lot of web things :D16:19
krotscheckAny more urgent items?16:19
jeblairkrotscheck: okay, i want infra-core to review that one before we get too far16:19
jeblairkrotscheck: if someone is ready to start on impl, then i think we should16:19
krotscheckjeblair: You got it.16:19
krotscheck#topic Discussion16:20
*** openstack changes topic to "Discussion (Meeting topic: StoryBoard)"16:20
krotscheck#topic Discussion: Story Types16:20
*** openstack changes topic to "Discussion: Story Types (Meeting topic: StoryBoard)"16:20
krotscheckttx: Floor is yours.16:20
krotscheck#link https://review.openstack.org/#/c/129267/16:20
ttxSo the numerous reviewers reported that the only thing that make story types tricky is trgheir interaction with branches16:21
ttxnamely, the fact that some story types would restrict the target branches for tasks16:21
ttxthat said, it's a bit difficult to discuss that until we actually have support for branches at all16:21
ttxsince it leads to red herrings like "we need to support projects that don't really have branches"16:22
ttxwhich is a bit oethogonal to that discussion16:22
ttx+r16:22
ttxSo... I'll draft the spec on branch support first :)16:22
ttxand revisit story types once that is done16:22
krotscheckAlrightey, shall I replace the discussion topic with branch support, or are you not yet ready to talk about that?16:23
NikitaKonovalovttx: do you want the branches to look like they do in LP now?16:23
ttxNikitaKonovalov: well, minus the weird part16:23
*** wuhg has quit IRC16:23
ttx(the weird part being... they have magic branch that is both current series and master16:24
ttxwhich is VERY confusing16:24
ttx)16:24
krotscheck#topic Discussion: Branch Support16:24
*** openstack changes topic to "Discussion: Branch Support (Meeting topic: StoryBoard)"16:24
ttxso yeah, overall the idea is to allow to have tasks that are targeted toward the development branch (master)16:25
ttxand tasks that are about backporting to older branches16:25
krotscheckOk, so where is a branch associated to a repository? Do projects need repo support?16:25
ttxthe notion of development branch / master could degrade gracefully to mean "the current thing"16:26
NikitaKonovalovafaik, LP allows projects define their own branches and series, should we do the same?16:26
ttxkrotscheck: oh, you mean, where would SB learn about the branches there are ?16:26
krotscheckttx: Yep16:26
ttxkrotscheck: importing branches from git would be neat16:26
ttxbut LP forces you to define them16:26
*** hinnant_ has joined #openstack-meeting-316:26
ttxso both approaches are possible I guess16:27
ttxI'll make sure to cover that in spec16:27
krotscheckttx: Got it,16:27
jeblairi think since we're expeciting storyboard's git support to be external...16:27
*** iovadia has quit IRC16:27
jeblair..sort of like how we work with lp now -- we have scripts that interact with lp based on gerrit actions..16:28
ttxkrotscheck: fwiw I still think having a project name and a git URL in a separtate field would make sense16:28
jeblair..we could have branches in storyboard automatically be created by those external tools16:28
ttxso that we stop wasting space listing "openstack/" or "openstack-infra/" on every task16:28
jeblairwhich still allows for the 'create arbitrary branch' use-case which may be useful for non-git projects16:28
ttxjeblair: yes16:29
krotscheckYeah, this one’s going to get tricky :)16:29
ttxwe just need to make sure projects without branches don't look too funny16:29
ttxI guess if there is a single branch, we could omit talking about "master"16:29
ttxthat would look just like it looks today16:29
krotscheckSo, first things first: A git repository can be associated with a project, yes?16:30
ttx(just no branch column in case the project only has one branch (or has no git repo)16:30
jeblairi think some non-git projects would actually want to use the term 'master' (after all -- many of them are still in service of things that have git branches)16:30
*** ChuckC has joined #openstack-meeting-316:30
ttxkrotscheck: I'd say yes16:31
krotscheckCan a project have more than one git repository assocaited with it?16:31
ttxkrotscheck: I'd say no16:31
NikitaKonovalovkrotscheck: I'd say we need a git project url field for a project first, and then think of a flow how how to load branches if there is one16:31
krotscheckNikitaKonovalov: I agree.16:31
NikitaKonovalovso probably listening on gerrit events16:31
krotscheckNikitaKonovalov: We can either gerrit-event that or cron that.16:31
ttxNikitaKonovalov: could be cron16:31
*** kgriffs has left #openstack-meeting-316:32
* krotscheck is working on a new iteration of the cron plugin.16:32
NikitaKonovalovthat depend on how often do the branches appea16:32
NikitaKonovalovr16:32
jeblairjust to be clear -- i do not think that listing to gerrit events and acting on them should not be a core part of storyboard16:32
krotscheckjeblair: That’s a double negative ;)16:32
jeblairstoryboard should be useful without gerrit, or with other source control systems16:32
krotscheckjeblair: I agree.16:32
NikitaKonovalovIt think that mostly happens when OS projects hit release time16:32
jeblairsorry, heh16:32
jeblairjust to be clear -- i do not think that listing to gerrit events and acting on them should be a core part of storyboard16:32
krotscheckjeblair: The question becomes whether it’ll be a storyboard plugin in a separate repo, or a gerrit thing that talks to storyboard via the SDK16:33
NikitaKonovalovjeblair: it could be a plugin16:33
jeblairso yeah, we should develop a full suite of tools to do this, but not depend on them architecturally16:33
jeblairsounds like we're on the same page :)16:33
krotscheckYep.16:33
krotscheckApproach may vary.16:33
jeblairi just really didn't want to get that one wrong :)16:33
ttxOK, should draft that branch thing this week16:35
krotscheckAlright, so it sounds like the first step is to get some way of adding a git repo field to a project, and let ttx write a spec from there.16:35
krotscheckThat seems simple enough.16:35
krotscheckAnything else before we move on?16:35
ttxkrotscheck: would that allow to make projects names be smaller16:35
krotscheckttx: ....peeerhaps?16:36
krotscheckttx: Those project names come from projects.config.yaml though16:36
ttxsince we don't allow duplicates across orgs, "openstack-infra/storyboard" could be "storyboard"16:36
krotscheckSo you’ll have to argue with jim about that :)16:36
*** jfjoly has quit IRC16:36
ttxI hate losing horizontal space. Pet peeve of mine16:37
krotscheckFrom a technical perspective there’s nothing preventing the project names from being shorter.16:37
krotscheckOk, next topic16:37
ttxand we'll need more horizontal space with branches :)16:37
*** zhipeng has joined #openstack-meeting-316:37
krotscheck#topic Discussion: API Paging16:37
*** openstack changes topic to "Discussion: API Paging (Meeting topic: StoryBoard)"16:37
krotscheckjedimike: THis one’s yours!16:37
* jedimike cowers16:37
jedimike:)16:37
*** lblanchard has joined #openstack-meeting-316:37
jedimikeok, I guess we need to decide if we're going to go with some more expensive marker + results snapshot system, or just simple offset/limit?16:38
*** naohirot has joined #openstack-meeting-316:38
krotscheckWhat’s your recommendation?16:38
jedimikeif it's essential that our users don't miss or duplicate any data when paging, the marker+snapshot16:39
jedimikeif it's not really an issue, offset+limit16:39
jedimikeI would say that, probably, storyboard isnt going to lose people money or bring systems down if they miss out on a few records as they page16:40
krotscheckI agree - in most cases the things that will make people lsoe money should be at the top of the sort list anyway.16:40
jedimikeyeah. If this were Horizon, I'd be firmly saying we need the more expensive, absolutely reliable option. But I don't think we do.16:41
krotscheckI’m somewhat curious about the performance implications on someone using an API client to go through All The Things (TM), but I feel that that particular use case can be fixed by removing the max results limit on the API.16:42
krotscheckAssuming that the query prep on deep pages becomes an issue.16:42
jedimikedepends on the number of results we'd typically deal with16:42
krotscheckjedimike: I’d say, conservatively, 100K or so?16:43
NikitaKonovalovjedimike: search by one tag may return a really large set16:43
jeblairi think the api case is key -- if you can't reliably interface with the system using the api (and "dropping results" is not reliably interfacing) then it's going to be of much lower value than we want16:43
jedimikeand how often would someone page to the thousandth page if we had a result set of 100k?16:43
krotscheckjedimike: Well, we haz reports :)16:43
jedimikehmmm ok...16:44
krotscheckI get what you’re saying though.16:44
krotscheckPersonally, I can see cases in which a marker-based page will also result in skipped records.16:44
jedimikethe thing is, a non-snapshotted marker based paging system fails all of its goals when you can order by arbritary columns16:45
krotscheckEspecially in sorted situations.16:45
jedimikeif you snapshot, you can be golden, but it's much more expensive to do16:45
krotscheckYeah, that requires all kinds of caching.16:45
jedimikeyeah. can shard nicely though ;)16:46
krotscheckThough the request becomes more of a POST -> Create this result set for me, and then a 302 redirect to where that result set lives.16:46
jedimikeyes, basically it does16:46
krotscheckAnd the POST can include a “Keep it around for X days"16:46
krotscheckAgain, though, marker based paging gives us no idea of where within the result set a user is.16:47
jedimikeand the position can change at any time, with no notification16:47
*** lblanchard has quit IRC16:47
krotscheckSo I kindof feel that the need to snapshot and the method by which we traverse a result set are two different discussions.16:47
jedimikeyou could find yourself back on the first page after paging through 100 pages, with no idea it's happened16:47
jedimikeif we snapshot, we can use markers to navigate and I'd recommend we do because of the nice use of indexes it brings16:48
jedimikeand because we're snapshotting, underlying data changes won't affect where we are16:48
*** armax has quit IRC16:48
krotscheckjedimike: How about the usability bit of “You’re on record X of YYYY”?16:48
jedimikebut snapshotting 100k results for a search, or every time a search *changes* is not in any sense cheap16:49
jedimikekrotscheck, that's easily done by caching counts, seeing how many records are after the marker and how many ther are in total16:49
krotscheckjedimike: That requires though that you start at the beginning in the client.16:49
krotscheckjedimike: If you don’t, you’ve got no idea.16:50
jedimikekrotscheck, not if you calculate the page markers and cache them16:50
jedimikethen you can jump to pages16:50
krotscheckjedimike: Right, or if the cached record set gives you an order index as well.16:50
krotscheck(Because users can be annoying and change their page sizes.16:50
jedimikeand if you know the marker you can get back where marker > than this.marker to see how many follow, and you know the total16:50
jedimikeyes16:50
krotscheckYeah, sounds like there’s a solution there.16:51
*** ivar-lazzaro has joined #openstack-meeting-316:51
jedimikein the case of an ordered result set, the marker becomes a combination of pk and the value in the ordered column16:51
krotscheckThat would also greatly improve API performance, because we can include expiration headers on search results and use the browser cache to reduce API calls.16:51
jedimikeit just means a lot more inserts/deletes, and we need to figure out, based on our  (predicted) usage patterns, which is going to serve us better16:52
krotscheckjedimike: You mean prewarmed result caches?16:52
*** exploreshaifali has joined #openstack-meeting-316:53
jedimikethat's interesting, but cache invalidation becomes a problem that needs solving there16:53
jedimikei mean, which would be lesser - the overhead of snapshotting, or the overhead of using offsets, with the usage pattern we think we'll see when this gets big?16:53
krotscheckjedimike: Maybe. Just take a snapshot of the prewarmed results at that moment?16:54
*** lucasagomes has joined #openstack-meeting-316:54
krotscheckjedimike: Don’t forget the overhead of breaking things downstream if we change our paging parameters.16:54
krotscheckTwice.16:54
*** aleksandr_null has joined #openstack-meeting-316:55
jedimikekrotscheck, in the past, i've only snapshotted the pk and the value ordered by so that i can join on the main data table and highlight any changes to the ordered value in the ui without having the change affect the order16:55
*** Shrews has joined #openstack-meeting-316:55
*** yuriyz has joined #openstack-meeting-316:55
krotscheckjedimike: That’s sane.16:55
*** ivar-lazzaro has quit IRC16:55
*** Nisha has joined #openstack-meeting-316:55
*** NobodyCam has joined #openstack-meeting-316:55
krotscheckIt feels like we’re coming to a consensus on using marker paging with snapshots.16:56
*** dtantsur has joined #openstack-meeting-316:56
jedimikeyeah, so your table is narrow and if you left join, you even cope with deletes quite easily, without affecting any navigation16:56
krotscheckAnd that things like what-is-shapshotted and so forth should just be detailed out in a spec.16:56
krotscheck(Also we’re running out of time)16:56
jedimikeyeah, and how the snapshots are sharded, the housekeeping around them, etc.16:56
krotscheckjedimike: Yeah, that’s implementation details :)16:57
jedimikeindeed :)16:57
krotscheckjedimike: For the sake of sanity, can you put that into a spec for us?16:57
jedimikeyes, I can write up the approach i outlined on the mailing list into a generic paging spec16:57
*** devananda has joined #openstack-meeting-316:57
krotscheckjedimike: Works for me.16:58
krotscheck#action jedimike Write paging spec.16:58
jedimikecool :)16:58
NikitaKonovalovjedimike: works for me as well16:58
krotscheckSince we only have a little time yet, I’m going to bounce out directly to open discussion and we’ll visit the other discussion topics next week or in channel.16:58
krotscheck#topic Open Discussion16:58
*** openstack changes topic to "Open Discussion (Meeting topic: StoryBoard)"16:58
*** stendulker has joined #openstack-meeting-316:58
krotscheckAnything?16:59
* krotscheck has nothing.16:59
NikitaKonovalovI've finally got a client created16:59
NikitaKonovalovSo there are a few changes up16:59
krotscheckWOO16:59
rcarrillocruzNikitaKonovalov: nice16:59
*** sarob has joined #openstack-meeting-316:59
rcarrillocruzwhere ? :-)16:59
CTtpollardcool NikitaKonovalov16:59
*** rloo has joined #openstack-meeting-316:59
NikitaKonovalovif the general approach is OK, I'll start covering it with tests docs and enpoint support16:59
NikitaKonovalovthe repo is openstack-infra/python-storyboardclient17:00
krotscheckCool17:00
rcarrillocruzawesome17:00
CTtpollard:)17:00
*** zz_jgrimm is now known as jgrimm17:00
krotscheckAlright, thanks everyone! We’re out of time.17:01
krotscheck#endmeeting17:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:01
openstackMeeting ended Mon Dec  1 17:01:07 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-12-01-16.00.html17:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-12-01-16.00.txt17:01
openstackLog:            http://eavesdrop.openstack.org/meetings/storyboard/2014/storyboard.2014-12-01-16.00.log.html17:01
devanandahi all! anyone here for the Ironic meeting, at our new place and time?17:01
jroll\o17:01
lucasagomesme17:01
ChuckCo/17:01
NobodyCamw00 h00 nice new digs17:01
Nishame17:01
naohiroto/17:01
vdroko/17:01
Shrewso/17:01
*** yolanda has left #openstack-meeting-317:01
yuriyzo/17:01
JoshNango/17:01
stendulkero/17:01
rlooo/17:02
devanandagreat! let's get started17:02
devananda#startmeeting ironic17:02
openstackMeeting started Mon Dec  1 17:02:09 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.17:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:02
*** openstack changes topic to " (Meeting topic: ironic)"17:02
openstackThe meeting name has been set to 'ironic'17:02
devananda#chair NobodyCam17:02
openstackCurrent chairs: NobodyCam devananda17:02
devananda#topic announcements17:02
*** openstack changes topic to "announcements (Meeting topic: ironic)"17:02
devanandaas usual, our agenda is here: https://wiki.openstack.org/wiki/Meetings/Ironic17:02
devanandahowever, not as usual, we're at a new place and time17:02
*** ivar-lazzaro has joined #openstack-meeting-317:03
devanandaand we're alternating -- so next week will *not* be at this time17:03
*** zyluo_ has joined #openstack-meeting-317:03
Nishadevananda, thanks for the new times. It works for us17:03
*** mrmartin has quit IRC17:03
devanandanext week will be at 0500 UTC tuesday, which translates to 11pm PST, for those who think in US time zones17:03
devanandaNisha: you're welcome17:03
NobodyCam:)17:03
Nisha:)17:04
*** jedimike has left #openstack-meeting-317:04
devanandathat's the only announcement from me. NobodyCam  ?17:04
ChuckC0500 UTC == 2100 PST17:04
lucasagomesI will be in brazil next week and on, that will me 3am for me. So I won't be able to join the next meeting17:04
NobodyCamno announcements here17:04
naohirotdevananda: I noticed that Neutron team announced surprisingly early deadlines at here17:04
devanandaChuckC: urgh. you are correct17:05
naohirothttps://wiki.openstack.org/wiki/NeutronKiloProjectPlan17:05
naohirotdevananda: Are we going to announce such that deadlines too?17:05
* ChuckC didn't want to stay up that late ;-)17:05
* dtantsur hopes no17:05
NobodyCamwow that is a early deadline17:05
*** matrohon has quit IRC17:05
dtantsurwe won't land anything, if we do :D17:06
naohirotNobodyCam: yes17:06
NobodyCamlike one week17:06
rloomy understanding is that we're going with this sched: https://wiki.openstack.org/wiki/Kilo_Release_Schedule17:06
jrollwow, let's not do that17:06
devananda#info As we are now  alternating weekly times,  next week's meeting is at 0500 UTC Tuesday (or 2100 PST Monday)17:06
devanandanaohirot: Neutron is doing a very massive refactoring this cycle17:06
naohirotrloo: I see17:06
devanandanaohirot: they are, afaik, the only project doing that. so a separate schedule makes sense for them17:06
devanandawe are not17:06
lucasagomesrloo, +117:07
*** sarob_ has joined #openstack-meeting-317:07
zyluo_Should there be a specs deadline?17:07
devanandarloo pointed to the Kilo release schedule already, and my plan is to follow that for this cycle17:07
NobodyCamzyluo_: yes.. we had a deadline last cycle17:07
devanandazyluo_: there is. see the link17:07
naohirotdevananda: so we are following the official schedule at https://wiki.openstack.org/wiki/Kilo_Release_Schedule, right?17:07
devananda#link https://wiki.openstack.org/wiki/Kilo_Release_Schedule17:07
lucasagomeszyluo_, yes, because of the feature freeze and all17:07
devanandayes17:07
rloodevananda: maybe an #info and an email out about the spec deadlines?17:07
naohirotdevananda: Okay17:08
yuriyz+117:08
*** rcarrillocruz has left #openstack-meeting-317:08
devanandarloo: sure, will do17:08
devananda#topic subteam status17:08
*** openstack changes topic to "subteam status (Meeting topic: ironic)"17:08
rloodevananda: thx17:08
*** mrmartin has joined #openstack-meeting-317:08
NobodyCamI like the new status format .... thank you all17:08
devananda#link https://etherpad.openstack.org/p/IronicWhiteBoard17:08
devanandagiving folks a minute or two to review the status on the whiteboard17:09
*** jimhoagland has joined #openstack-meeting-317:09
devanandaif you have questions or comments, please raise them17:09
jrolloops17:09
naohirotNobodyCam: I added iRMC status :-)17:09
* jroll forgot to update IPA status17:09
jrollupdated17:09
* zyluo_ just saw featureproposalfreeze17:10
*** mrmartin has quit IRC17:10
*** stevelle has left #openstack-meeting-317:10
NobodyCamnaohirot: awesome thank you :)17:11
*** ivar-lazzaro has quit IRC17:11
naohirotNobodyCam: wc17:11
*** Longgeek_ has quit IRC17:11
*** mrmartin has joined #openstack-meeting-317:11
*** CTtpollard has left #openstack-meeting-317:11
devanandaNisha: feedback for wanyen - it's great that she is reviewing other specs, but that's not really a driver status report17:12
Nishadevananda, ok17:12
devanandaif there are no questions, let's move on17:13
NobodyCam+117:13
*** mrmartin has quit IRC17:13
devananda#topic changes to the 'maintenance mode' API17:13
*** openstack changes topic to "changes to the 'maintenance mode' API (Meeting topic: ironic)"17:13
*** jacalcat has joined #openstack-meeting-317:13
devanandaI filed this bug last week17:14
devananda#link https://review.openstack.org/#/c/136934/17:14
devanandatldr; there was a LOG line about deprecation17:14
devanandain the API service17:14
devanandawe added a feature recently that allows tracking a maintenance reason, and in so doing, added a second RESTful means to change the status of the maintenance field17:15
devanandawith no clear way to remove the first method17:15
*** etoews has quit IRC17:15
devanandaI'd like to suggest that we don't remove it17:15
*** markmcclain has quit IRC17:16
NobodyCamdevananda: for backward compat ?17:16
lucasagomesI was thinking about having it documented as deprecated for one cycle17:16
devanandalucasagomes: documentation != deprecation. users won't know.17:16
rlooI don't like having two different ways of doing almost the same thing. But I suppose we already have that/will have that in other situations.17:16
jrollI think I'm fine without removing it, I don't see a need to; the only downside of leaving it is that folks can clear maintenance mode without clearing the reason17:16
lucasagomesI understand it's hard to programatically say it's deprecated in that case because it's not an endpoint in the API only for that (so you can't use 301 (Permanently Moved) as return code for e.g)17:17
lucasagomesright yeah, my concern is once we start adding more stuff to the new endpoint17:17
rloojroll: that isn't good, not clearing the reason17:17
devanandathere is no means, AFAIK, to indicate to users of our API that PATCH /v1/nodes/<uuid> {op: replace, key: maintenance, value: othervalue} is no longer acceptable17:17
lucasagomeslike sending notification once the node is put on the maitenance etc, we would need to change in both places17:17
devanandaso, not clearing the reason is bad -- but also easy to fix17:17
jrollrloo: but we could special case *that* part17:18
*** dboik has quit IRC17:18
rloojroll, devananda: yes (we should fix it)17:18
Nisha+117:18
jrolllucasagomes: but we should send notifications for PATCH /nodes/uuid as well, nova will see it either way17:18
jrolllucasagomes: so I disagree that's a problem17:18
rloois the only reason for not getting rid of it is because we don't know how to deprecate it and we may break someone's usage?17:18
devanandalucasagomes: if a user('s existing automation tooling) is using the icehouse,juno PATCH approach, then they have no means to set the maintenance_reason.17:19
Shrewsdevananda: so are you suggesting that the old method could be adjusted to automatically clear the reason17:19
Shrews?17:19
devanandalucasagomes: if they're using the new approach, it is clearer for them.17:19
devanandaShrews: yes17:19
lucasagomesjroll, it's not very user friendly to have 2 endpoints to the same thing17:19
lucasagomesnot a technical reason17:19
Shrewsdevananda: yeah, that seems like a good compromise17:19
devanandaShrews: that solves the "two clients manipulating the same node in different ways leaves dangling data" problem17:19
rlooShrews: and if they set to maintanance on, they can't specify the reason17:19
lucasagomesanother approach maybe would be to add a custom HTTP header17:20
lucasagomesX-deprecated idk17:20
Shrewsrloo: i don't see that as a problem17:20
lucasagomesand in the lib/client we can look at it and give the user a message17:20
devanandalucasagomes: I agree that it's not the most user friendly thing to have two APIs to change the same thing. However, breaking the current API without any user-visible warning isn't good either17:20
rloowhen we have a v2, would we get rid of it then?17:20
devanandalucasagomes: there are other clients out there. making a change in ours doesn't inform everyone else of the change17:20
devanandarloo: yes :)17:20
rloohmm. ok, i'm fine with this then. On to v2 one day... :-)17:21
*** victor_lowther has joined #openstack-meeting-317:21
NobodyCamI can see the value to leaving it.. until we move on to a V2 api17:21
lucasagomesaight... yeah it's fine to keep it then. /me runs out of ideas to know how to deprecate that17:21
devanandaif folks want to discuss futher, let's do that on the bug report / mailing list17:22
lucasagomes+117:22
*** thangp has quit IRC17:22
Shrewsboo technical debt, but yay helping users17:22
devananda#topic discovery is blocked on the state machine17:22
*** openstack changes topic to "discovery is blocked on the state machine (Meeting topic: ironic)"17:22
devanandadtantsur: hi! I think this is you17:23
rloocan we decide now, what to do, or should we always send email to the list for those that can't attend the meeting?17:23
dtantsuroh sorry17:23
devanandadtantsur: hm, hang on one moment, sorry17:23
devananda#undo17:23
openstackRemoving item from minutes: <ircmeeting.items.Topic object at 0x3ac00d0>17:23
jrollI mean, many things are blocked on the state machine...17:23
*** jgrimm is now known as zz_jgrimm17:23
devananda#agreed keep both endpoints for now, plan to drop the old one (if/)when we have a v2 API17:23
devananda#topic discovery is blocked on the state machine17:24
*** openstack changes topic to "discovery is blocked on the state machine (Meeting topic: ironic)"17:24
devanandathere :)17:24
rloothx devananda17:24
rloojroll: i'll offer to update the spec17:24
jrollrloo: what spec?17:24
NobodyCamvictor_lowther: just put up a new state machine spec that I have not had a chance to look at BTW17:25
rloojroll: the maintenance spec with the deprecate thingy that I added17:25
dtantsuraha. just wanted to get your opinion, if we can short-cut discovery specs, while we're talking about state machine17:25
devanandarloo: ++17:25
jrollrloo: ok, cool, gopher it17:25
dtantsurbecause discovery only needs 2 new states and does not need e.g. talk about zapping to finish17:25
*** exploreshaifali has quit IRC17:25
rlooi think we should all try to get the state machine spec approved instead of shortcutting anything else17:25
victor_lowtherNobodyCam: This rev is tox compliance, speling fixes, and fix the bothced state machine ascii art.17:25
dtantsurrloo, discovery spec is ~ready, while state machine is not even close to17:26
NobodyCamahh :)17:26
devanandadtantsur: it seemed that the state machine spec discussion had stalled around the init/enroll/discovery process17:26
victor_lowtherAll the substantive issues are still present. :)17:26
devanandadtantsur: which makes me hesitant to short cut something in that space17:26
devanandadtantsur: also, that discussion is on the agenda today too17:26
dtantsurdevananda, then maybe postpone this question and proceed to the 2nd?17:26
devananda++17:27
jrollI mean, we know there will be discovery states, it's just the transitions that are stalling yes?17:27
devananda#info question deferred until later in the agenda17:27
rloodtantsur: you're only blocked on getting code approved for discovery, right?17:27
lucasagomesjroll, seems so17:27
dtantsurwhich is: any objections for discovery to be in it's own interface? like IntrospectionInterface?17:27
jrollso the discovery spec can just go ahead IMO17:27
victor_lowtherIMO, discovery should be totally driven by introspection.17:28
jrolleveryone seems to like IntrospectionInterface, and we'll probably need it... but our driver matrix is getting insane17:28
victor_lowthermy latest comments to the discovery spec points out that system hw properties are not stable in INIT.17:28
victor_lowtherjroll: hence composable drivers.17:28
lucasagomesyeah... I like the interface as well it gives flexibility to the drivers17:28
jrollvictor_lowther: I want to try that. people don't think it will work.17:29
devanandavictor_lowther: or cute names for drivers17:29
lucasagomesI believe that people may start compositing their own driver downstream with the interfaces they like17:29
victor_lowtherjroll: crowbar does it.17:29
* NobodyCam likes cute names17:29
rlooso +1 to IntrospectionInterface17:29
jrollvictor_lowther: right, of course it works in general, I just mean in ironic17:29
rloo-1 to cute names ;)17:29
NobodyCam;)17:29
dtantsurI think Nisha agreed to IntrospectionInterface too, right?17:30
victor_lowtherNo reason it could not in Ironic17:30
Nisha++17:30
victor_lowtherv2, that is17:30
*** dboik has joined #openstack-meeting-317:30
*** baoli has quit IRC17:30
victor_lowtherbecause there would probably be incompatible API changes.17:30
devanandaif Ironic "ships with" a set of composed drivers, and instructions on how to compose them differently, should an operator so desire17:30
devanandais that enough?17:30
jrollvictor_lowther: there may be reasons, e.g. drivers sometimes depend on each other17:30
jrollI want to figure it out, to be clear17:31
devanandaI think we'll want to improve the testing around arbitrarily-composable drivers if we go the route of enouraging downstream compositing17:31
devanandajroll: exactly my concern17:31
jrolldevananda: I really want to look into composing them arbitrarily17:31
*** MaxV has quit IRC17:31
jrollyeah17:31
victor_lowtherAs long as they declare the depencency and the core does the Right Thing with dep info, that is not a problem.17:31
jrollyeah17:31
rloowe need a spec for composable drivers :-)17:31
lucasagomesdevananda, it sounds good. Tho we still need to work on some interface dependencies, for e.g pxe deploy also depends on the pxe vendor17:32
devanandaI don't think we have that today. and so, at least in this cycle, yes, I think we'll see a continued increase in number of entries in the driver namespace17:32
*** etoews has joined #openstack-meeting-317:32
lucasagomeswithout it it doesn't work (because of the pass_deploy_info)17:32
lucasagomesbut I believe it's a good goal17:32
devanandalucasagomes: right17:32
jrollindeed17:32
jrollenabled_drivers will get interesting, too17:32
devananda#info arbitrary driver compositing is a good goal, but not there today (and unlikely for this cycle, given other work)17:33
dtantsurare we still arguing about IntrospectionInterface?17:33
* dtantsur is confused17:33
NobodyCamjroll: oh thats a good point17:33
victor_lowtherNot really, but we should be.17:33
jrolldtantsur: no, I don't think anyone is saying no to that17:33
lucasagomesdtantsur, I think we mostly agreed with the Introspectioninterface17:33
dtantsurack, I'll call it agreed :)17:33
jrollNobodyCam: x.x17:33
rlooso we're agreed then? +2 for IntrospectionInterfaace?17:33
lucasagomesnow it's mostly about incrising the matrix to composite a driver17:33
lucasagomesbut I see it as a diff problem17:33
devananda#info adding an IntrospectionInterface increases the number of entries in the driver namespace, but it's a good thing regardless17:33
dtantsurNisha, ^^^17:34
jrolllucasagomes: yeah, let's jfdi for now17:34
devananda#agreed add new IntrospectionInterface17:34
NobodyCam+1 :)17:34
Nisha:) +117:34
devananda#topic adding PUT support for API resources17:34
*** openstack changes topic to "adding PUT support for API resources (Meeting topic: ironic)"17:34
devanandavdrok: hi!17:34
vdrokdevananda, hi17:35
vdrokthere are couple of questions about adding put to create/update resources17:35
vdrok#link https://review.openstack.org/#/c/130228/17:35
vdrokchange for nodes is here^17:35
vdrokshould we PUT the whole document or only fields that need to be changed?17:35
devanandavdrok: AIUI, PUT by its definition requires one to PUT the whole document17:36
lucasagomesindeed, usually it's like GET -> [modify] -> PUT17:36
lucasagomesthat's why we have PATCH for partial resources updates17:36
victor_lowtherya, but I have seen that pretty widely ignored.17:36
vdrokok, then will udpate the change to do that17:37
vdrokto reflect the changes i need to add DocImpact and ApiImpact flags to commit messages, is it correct?17:37
devanandavictor_lowther: how can one express the deletion of an element via PUT without honoring that?17:37
jrolljust curious, have we already agreed that this is valuable?17:37
lucasagomesvictor_lowther, well, I mean we should try to suck less then17:37
devanandai'm curious -- does anyone feel that we need PUT support for top-level resources (eg nodes, ports) in Ironic?17:38
victor_lowtherIn JSON terms, either by putting the thing with a nil value, or just not handling it well.17:38
vdrokjroll, i think i saw that on one of the summit etherpads17:38
jrollI don't think we need it, personally17:38
lucasagomesthe only benefit I see with PUT is that it may be more user friendly17:38
jrollvdrok: I think that was just an idea someone through out17:38
lucasagomesright now we require people to build a json-patch17:38
jrollthrough/threw17:38
victor_lowtherand there is a difference between JSON PATCH and the PATCH HTTP method17:38
jrollright, ok17:39
jrollso I think JSON PATCH is better17:39
victor_lowtherhttps://tools.ietf.org/html/rfc6902 <-- JSON PATCH rfc17:39
jrollif you do a GET/PUT, there could be a race17:39
jrolland things get messy17:39
devanandavictor_lowther: AIUI, a JSON PATCH is the BODY document sent to an HTTP PATCH request17:39
lucasagomesvictor_lowther, yup we use a lib that implements that rfc17:39
*** devvesa has quit IRC17:39
lucasagomes#link https://github.com/stefankoegl/python-json-patch17:39
*** armax has joined #openstack-meeting-317:39
rlooi thought we wanted PUT cuz it was idempotent?17:40
devanandabuilding a JSON PATCH is not necessarily simple. I ran into this when taking a stab at an ansible client17:40
jrollyeah, it makes declarative things harder17:40
devanandaas a client, I want $this information on the Node, but it has $that information right now17:40
devanandawith the current PATCH support, I have to figure out the transformation myself, in the client17:40
lucasagomesI believe that we could make the library smarter to help with that syntax problem17:41
yuriyzPUT with create-or-update logic is idempotent, this is a big advantage IMO17:41
lucasagomeslike creating a json-patch by diffing documents17:41
devanandaand anyone using a different client lib (or one in a different language) has to repeat that effort17:41
devanandalucasagomes: so that would help python developers. but there are other languages in the world ;)17:41
NobodyCamdevananda: ++17:41
devanandaso at least, in this regard, adding PUT support would make things simpler for some users17:42
jrollthis might be useful btw http://json-delta.readthedocs.org/en/latest/17:42
victor_lowtherPUT is only idempotent of nothing has changed since you got the original on the server.17:42
jrollactually17:42
jrollhttps://github.com/stefankoegl/python-json-patch/blob/master/doc/commandline.rst17:42
victor_lowtherWe have a mechanism in place for detecting that?17:42
jrollsame person as json patch ^17:43
*** lhcheng has joined #openstack-meeting-317:43
devanandavictor_lowther: ooh. nope17:43
jrollvictor_lowther: no, that's one of my problems with this17:43
victor_lowtherya17:43
*** Longgeek has joined #openstack-meeting-317:43
victor_lowtherso17:43
*** lhcheng has quit IRC17:43
victor_lowtherwhen updating something, send back the old one and the new one17:43
lucasagomesjroll, nice17:43
jrollI think devs that nee declarative things could use python-json-patch17:43
jrollneed*17:43
*** lhcheng has joined #openstack-meeting-317:43
victor_lowtherthen the server can say, sorry, try again if its copy of the resource does not match the old one you sent17:44
jroll... or just send a PATCH :|17:45
jrollI don't see much value in this work17:45
vdrokso, whats the agreement then?17:46
devanandajson-delta looks like it addresses my needs17:46
NobodyCam*<15 minutes to go17:46
* NobodyCam needs to look at json-delta more17:47
jrollnonono, look at python-json-patch https://python-json-patch.readthedocs.org/en/latest/17:47
devanandaanyone have a strong argument in favor of PUT, such that we should do the work to support it properly?17:47
victor_lowtherPUT or PATCH a json patch, and handle it according to HTTP PATCH settings no matter how you get it.17:47
*** lhcheng has quit IRC17:47
rloodevananda: you filed the bug that may have led to that patch: https://bugs.launchpad.net/ironic/+bug/127259917:48
devanandavictor_lowther: I mean, w.r.t. handling PUT of a whole document, not a patch17:48
victor_lowtherpoint and laugh at the client. :)17:49
devanandarloo: indeed I did. and we now have support for client-side UUID creation17:49
devanandaactually, I think that bug can be closed17:49
victor_lowtheror live in an eventaully consistent world17:49
NobodyCam*ten minutes17:50
*** lhcheng has joined #openstack-meeting-317:50
rloodevananda: great, let's close the bug then.17:50
rloovdrok: thx for all the work you put in this...17:50
vdrokokay, then i'll update the change to put json patches?17:50
jrollwe already have patch for json patches?17:50
devanandajroll: huh?17:50
lucasagomesPUT a json patch!?17:50
lucasagomesoh noes please17:50
vdrokor abandon? :)17:50
lucasagomesit's not needed17:50
*** alexsyip has joined #openstack-meeting-317:50
rloodo we want PUT for anything? doesn't sound like it?17:51
*** reed has joined #openstack-meeting-317:51
jrolldevananda: I guess that wasn't a question17:51
jrollI vote we don't need PUT17:51
NobodyCamsounds like we're talking our selfs out of put support17:51
*** ivar-lazzaro has joined #openstack-meeting-317:51
jrollyes17:51
devanandaas a user, I still feel that it would be easier to write clients for PUT, especially of subresources (like node.properties)17:52
jrollwe really need to land the state machine spec this week...17:52
*** baoli has joined #openstack-meeting-317:52
lucasagomesI see the UX benefit in having PUT (as a whole document) I just don't know if that's really needed17:52
*** jimhoagland has left #openstack-meeting-317:52
devanandabut let's move on, since it sounds like there's agreement to not bother with PUT now, and alternatives alraedy exist17:52
yuriyz+1 for put whole document17:52
*** Longgeek has quit IRC17:52
victor_lowtherjroll: state machine scope will have to be narrowed if it is to land this week.17:53
devananda#info no agreement on whether we should or shouldn't have PUT, but also, no clear need for it. deferring any further discussion17:53
jrollwhat, why?17:53
devananda#topic new state machine17:53
*** openstack changes topic to "new state machine (Meeting topic: ironic)"17:53
NobodyCamI added some comments to help reviewers do just that17:53
victor_lowtherno real discussion or consensus on wait_flag17:53
victor_lowtherso that should probably be deferred until later17:54
devanandaa lot of other things depend on the state machine at this point17:54
victor_lowtherand dropped from the current spec17:54
jrollwe can't defer it, ironic doesn't work with a wait flag17:54
lucasagomesone thing that I see on the proposed state machine is that it's too complex/hard to debug17:54
lucasagomesfor e.g17:54
devanandaso I agree, we need to focus on getting agreement on _enough_ of that so we can proceed17:54
lucasagomesfrom INIT to AVAILABLE17:54
lucasagomesyou have 3 paths17:54
devanandaeven if there are other aspects which take longer to flesh out17:54
lucasagomesINIT -> DISCOVERING -> ZAPPING -> AVAILABLE17:54
lucasagomesINIT -> AVAIALABLE17:54
lucasagomesINIT -> ZAPPING -> AVAILABLE17:55
lucasagomesonce in available you never know from where you came from17:55
lucasagomesit can be very hard to debug17:55
devanandalucasagomes: maybe I'm being dense. why does that matter?17:55
dtantsurlucasagomes, ++ and we also found that DISCOVERING may need to be _after_ ZAPPING...17:55
victor_lowtherI am cool with killing the shorter paths and allowing some of the longer states to be NOOP'able17:55
jrollwe're doing the last 2 paths in prod today, it hasn't been a problem17:55
jroll(as a note)17:56
victor_lowtherthey are in because people had use cases for them at the summit17:56
rloocan we address that (if we need to) with a 'previous state' ?17:56
*** JayF has joined #openstack-meeting-317:56
lucasagomesdevananda, well because image you have N nodes, they are same but configured different17:56
lucasagomessome will pass, some will fail17:56
lucasagomesand you never know the previous action17:56
jrolllogs can give you an idea, no?17:56
lucasagomeswell the idea of having a state mahcine17:56
devanandastate transition log table?17:56
lucasagomesis that you can see what are the transitions17:56
jrolloh god17:56
lucasagomesand in our state machine we don;t diff states and actions17:57
NobodyCamrloo: that seems like a lot up keep17:57
victor_lowtherI would expect we would be logging the state transitions for any given node as a matter of course.17:57
lucasagomeswe only talk about states there, we may need to think like17:57
devanandavictor_lowther: I do not think everyone shared taht assumption17:57
rlooNobodyCam: if just the prev state, it isn't cuz to change the state to the new state, you knew what the current state was17:57
lucasagomesto go from state A to B we need an action17:57
victor_lowtherlucasagomes: such as?17:57
lucasagomesvictor_lowther, such AVAILABLE -> [DEPLOYING] -> DEPLOYED17:58
lucasagomes[deploying] is an action17:58
lucasagomesnot a state17:58
victor_lowtherno17:58
victor_lowtherit is a state in which actions are being performed to the node by Ironic17:58
devanandalucasagomes: it's a state. the system is [CURRENTLY DEPLOYING]17:58
lucasagomeshttp://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Finite_state_machine_example_with_comments.svg/244px-Finite_state_machine_example_with_comments.svg.png17:58
*** s3wong has joined #openstack-meeting-317:58
NobodyCami see that as a state17:58
NobodyCam+1 it is a state in which actions are being performed17:59
NobodyCam*one minute17:59
yuriyzyes when deploy is running17:59
devanandalucasagomes: the action is the user POSTing the new state to Ironic's REST API17:59
lucasagomeshttp://en.wikipedia.org/wiki/Finite-state_machine#Concepts_and_terminology17:59
victor_lowtherfrom my POV, the actions that transition between states are API calls17:59
victor_lowthereither the REST API or direct method calls17:59
*** dboik_ has joined #openstack-meeting-317:59
*** Nisha has quit IRC18:00
NobodyCam*beep18:00
jrollback to our channel :|18:00
victor_lowtherya18:00
dtantsurthanks!18:00
devanandathanks all -- clearly this is a longer conversation18:00
NobodyCamya18:00
devananda#endmeeeting18:00
lucasagomesthanks all18:00
*** baoli has quit IRC18:00
lucasagomesyeah channel18:00
devananda#endmeeting18:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:00
*** victor_lowther has left #openstack-meeting-318:00
openstackMeeting ended Mon Dec  1 18:00:49 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-12-01-17.02.html18:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-12-01-17.02.txt18:00
*** etoews_ has joined #openstack-meeting-318:00
*** JayF has left #openstack-meeting-318:00
openstackLog:            http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-12-01-17.02.log.html18:00
*** Shrews has left #openstack-meeting-318:00
*** yuriyz has left #openstack-meeting-318:01
*** zyluo_ has quit IRC18:01
*** vdrok has left #openstack-meeting-318:01
*** dtantsur has left #openstack-meeting-318:01
*** lucasagomes has left #openstack-meeting-318:01
*** thangp has joined #openstack-meeting-318:02
*** baoli has joined #openstack-meeting-318:02
*** Nisha has joined #openstack-meeting-318:02
*** stendulker has quit IRC18:02
*** etoews has quit IRC18:03
*** dboik has quit IRC18:03
*** armax has quit IRC18:06
*** lifeless has quit IRC18:10
*** sarob_ has quit IRC18:12
*** igordcard has quit IRC18:13
*** pballand has joined #openstack-meeting-318:14
*** igordcard has joined #openstack-meeting-318:15
*** dconde has joined #openstack-meeting-318:16
*** SridharRamaswamy has joined #openstack-meeting-318:18
*** armax has joined #openstack-meeting-318:19
*** sarob has quit IRC18:19
*** mwagner_lap has joined #openstack-meeting-318:19
*** lifeless has joined #openstack-meeting-318:23
*** dboik_ has quit IRC18:35
*** dboik has joined #openstack-meeting-318:36
*** dboik has quit IRC18:37
*** dboik has joined #openstack-meeting-318:37
*** dboik has quit IRC18:37
*** dboik has joined #openstack-meeting-318:39
*** naohirot has quit IRC18:44
*** MaxV has joined #openstack-meeting-318:44
*** jacalcat has left #openstack-meeting-318:45
*** rloo has left #openstack-meeting-318:46
*** MarkAtwood has joined #openstack-meeting-318:50
*** markmcclain has joined #openstack-meeting-318:52
*** markmcclain has quit IRC18:53
*** markmcclain has joined #openstack-meeting-318:54
*** emagana has joined #openstack-meeting-319:01
*** wanyen has joined #openstack-meeting-319:07
*** nfedotov has joined #openstack-meeting-319:07
*** markmcclain has quit IRC19:08
*** markmcclain has joined #openstack-meeting-319:08
wanyenDo we have ironic meeting at this room now?19:09
*** rudrarugge has joined #openstack-meeting-319:10
*** markmcclain has quit IRC19:10
*** markmcclain has joined #openstack-meeting-319:10
*** sarob has joined #openstack-meeting-319:10
*** emagana has quit IRC19:15
*** emagana has joined #openstack-meeting-319:16
*** aweeks has joined #openstack-meeting-319:17
*** salv-orlando has quit IRC19:17
*** MaxV has quit IRC19:17
*** jacalcat has joined #openstack-meeting-319:18
*** jacalcat has left #openstack-meeting-319:19
*** markmcclain1 has joined #openstack-meeting-319:19
*** emagana has quit IRC19:20
*** Longgeek has joined #openstack-meeting-319:21
*** Longgeek has quit IRC19:22
*** markmcclain has quit IRC19:22
*** devlaps has quit IRC19:22
*** wanyen has quit IRC19:23
*** MaxV has joined #openstack-meeting-319:24
*** rcleere is now known as rcleere_away19:29
*** devlaps has joined #openstack-meeting-319:30
*** sarob has quit IRC19:30
*** mrmartin has joined #openstack-meeting-319:32
*** igordcard has quit IRC19:35
*** devananda has left #openstack-meeting-319:45
*** emagana has joined #openstack-meeting-319:47
*** rcleere_away is now known as rcleere19:48
*** MaxV has quit IRC19:49
*** ChuckC has quit IRC19:49
*** shwetaap has quit IRC19:51
*** ChuckC has joined #openstack-meeting-319:55
*** matrohon has joined #openstack-meeting-319:55
*** MaxV has joined #openstack-meeting-319:56
*** etoews has joined #openstack-meeting-319:57
*** jtomasek has quit IRC19:57
*** etoews_ has quit IRC20:00
*** matrohon has quit IRC20:01
*** dboik has quit IRC20:04
*** s3wong has quit IRC20:05
*** SridharRamaswamy has left #openstack-meeting-320:05
*** MaxV has quit IRC20:07
*** baoli has quit IRC20:11
*** emagana has quit IRC20:15
*** emagana has joined #openstack-meeting-320:16
*** emagana_ has joined #openstack-meeting-320:18
*** emagana has quit IRC20:18
*** armax has quit IRC20:21
*** emagana_ has quit IRC20:22
*** Nisha has quit IRC20:24
*** dconde has quit IRC20:26
*** dconde has joined #openstack-meeting-320:27
*** dconde has quit IRC20:27
*** dconde has joined #openstack-meeting-320:28
*** gduan has quit IRC20:28
*** dboik has joined #openstack-meeting-320:30
*** dboik has quit IRC20:30
*** baoli has joined #openstack-meeting-320:30
*** garyduan has joined #openstack-meeting-320:30
*** dconde has quit IRC20:30
*** dboik has joined #openstack-meeting-320:31
*** emagana has joined #openstack-meeting-320:32
*** markmcclain1 has quit IRC20:34
*** emagana has quit IRC20:44
*** emagana has joined #openstack-meeting-320:44
*** emagana has quit IRC20:48
*** SumitNaiksatam has joined #openstack-meeting-320:53
*** marun_ has joined #openstack-meeting-320:55
*** carl_baldwin has quit IRC20:57
*** marun_ has quit IRC21:03
*** dynarro has joined #openstack-meeting-321:06
*** armax has joined #openstack-meeting-321:06
*** nfedotov has quit IRC21:08
*** dynarro has quit IRC21:10
*** sergef has quit IRC21:12
*** markmcclain has joined #openstack-meeting-321:13
*** carl_baldwin has joined #openstack-meeting-321:16
*** emagana has joined #openstack-meeting-321:17
*** dkehn has quit IRC21:17
*** igordcard has joined #openstack-meeting-321:17
*** dkehn has joined #openstack-meeting-321:19
*** SumitNaiksatam_ has joined #openstack-meeting-321:20
*** salv-orlando has joined #openstack-meeting-321:20
*** alexiz has joined #openstack-meeting-321:20
*** rloo_ has joined #openstack-meeting-321:21
*** ChuckC_ has joined #openstack-meeting-321:22
*** MaxV has joined #openstack-meeting-321:23
*** s3wong has joined #openstack-meeting-321:25
*** pkarikh_ has joined #openstack-meeting-321:27
*** fesp has joined #openstack-meeting-321:28
*** julim has quit IRC21:29
*** igordcard has quit IRC21:35
*** SumitNaiksatam has quit IRC21:35
*** ChuckC has quit IRC21:35
*** hinnant_ has quit IRC21:35
*** pkarikh has quit IRC21:35
*** flaper87 has quit IRC21:35
*** shakayumi has quit IRC21:35
*** russellb has quit IRC21:35
*** rossella_s has quit IRC21:35
*** SumitNaiksatam_ is now known as SumitNaiksatam21:35
*** fesp is now known as flaper8721:35
*** MaxV has quit IRC21:35
*** mrmartin has quit IRC21:35
*** lhcheng has quit IRC21:38
*** lhcheng has joined #openstack-meeting-321:38
*** emagana has quit IRC21:40
*** emagana has joined #openstack-meeting-321:40
*** MarkAtwood has quit IRC21:41
*** emagana has quit IRC21:44
*** emagana has joined #openstack-meeting-321:50
*** rtomasko has joined #openstack-meeting-321:53
*** sarob has joined #openstack-meeting-322:01
*** rtomasko has quit IRC22:04
*** armax has quit IRC22:05
*** armax has joined #openstack-meeting-322:05
*** sarob has quit IRC22:05
*** mattfarina has quit IRC22:06
*** dconde has joined #openstack-meeting-322:12
*** jacalcat has joined #openstack-meeting-322:15
*** peristeri has quit IRC22:17
*** emagana has quit IRC22:18
*** armax has quit IRC22:18
*** emagana has joined #openstack-meeting-322:18
*** emagana has quit IRC22:19
*** thangp has quit IRC22:20
*** emagana has joined #openstack-meeting-322:20
*** rossella_s has joined #openstack-meeting-322:29
*** igordcard has joined #openstack-meeting-322:29
*** sarob has joined #openstack-meeting-322:31
*** emagana has quit IRC22:33
*** emagana has joined #openstack-meeting-322:34
*** marun has quit IRC22:38
*** emagana has quit IRC22:39
*** emagana has joined #openstack-meeting-322:40
*** Ark has joined #openstack-meeting-322:43
*** Ark is now known as Guest569922:44
*** jacalcat has left #openstack-meeting-322:45
*** armax has joined #openstack-meeting-322:49
*** zhipeng has quit IRC22:50
*** armax has quit IRC22:54
*** sarob has quit IRC22:58
*** sarob has joined #openstack-meeting-323:04
*** emagana has quit IRC23:06
*** emagana has joined #openstack-meeting-323:06
*** emagana_ has joined #openstack-meeting-323:08
*** emagana has quit IRC23:09
*** dboik_ has joined #openstack-meeting-323:12
*** thomasem has quit IRC23:12
*** rhagarty_ has joined #openstack-meeting-323:12
*** rhagarty__ has joined #openstack-meeting-323:13
*** rhagarty has quit IRC23:13
*** rhagarty__ has quit IRC23:13
*** rhagarty_ has quit IRC23:13
*** rhagarty has joined #openstack-meeting-323:14
*** marun has joined #openstack-meeting-323:16
*** dboik has quit IRC23:16
*** dboik_ has quit IRC23:17
*** MaxV has joined #openstack-meeting-323:18
*** MaxV has quit IRC23:29
*** clu_ has joined #openstack-meeting-323:34
*** marun has quit IRC23:38
*** baoli has quit IRC23:42
*** emagana_ has quit IRC23:50
*** ChuckC_ has quit IRC23:53
*** devlaps has quit IRC23:58

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