Thursday, 2017-02-09

*** Syed__ has quit IRC00:05
*** wirehead_ has quit IRC02:12
*** wirehead_ has joined #craton02:13
*** anonymike has quit IRC02:17
*** anonymike has joined #craton02:17
*** anonymike has quit IRC02:33
*** openstackstatus has quit IRC02:58
*** openstackstatus has joined #craton03:00
*** ChanServ sets mode: +v openstackstatus03:00
*** tojuvone has joined #craton04:48
*** VW has joined #craton04:51
*** VW has quit IRC05:51
*** ediardo_ has joined #craton06:30
*** ediardo has quit IRC06:33
*** ediardo_ is now known as ediardo06:33
*** klindgren_ has joined #craton10:06
*** klindgren has quit IRC10:08
sulook, so search by label is actually broken because of pagination stuff14:12
suloit seems _pagination causes some weirdness with that query14:12
suloi am not 100% why14:12
thomasemIt did not occur to me that we had a generic variables API piped up in the codebase. I'm thinking I ought to switch Project over to using that?14:15
thomasemAh, it's being added, nvm.14:18
thomasemI'll switch that over once that lands.14:18
*** VW has joined #craton14:29
*** acabot has quit IRC14:42
sulosigmavirus: fyi: https://bugs.launchpad.net/craton/+bug/166284214:55
openstackLaunchpad bug 1662842 in craton "Allow search by labels" [Critical,New]14:55
suloi am not sure why it does this with labels join but not vars join14:56
sulobut its definitely the pagination function14:56
sigmavirusThat's very weird14:57
* sigmavirus looks at oslo_db's docs again14:57
sigmavirusI dont' think there was anything about using it only on certain tables14:57
suloi do see the "Unique keys not in sort_keys" get logged14:57
sigmavirusThat said, I'm also chairing  a meeting so give me time14:57
sulosigmavirus: no worries14:57
*** VW_ has joined #craton14:57
sigmavirussulo: Oh, so the default sort_keys are created_at and id14:57
sigmavirusbecause we need some keys to sort on14:58
*** VW_ has quit IRC14:58
*** VW_ has joined #craton14:58
*** VW__ has joined #craton15:01
*** VW has quit IRC15:01
sigmavirussulo: yeah, this is why I wanted to add tests but when you started depending on it I thought I'd push those off for another patch15:01
*** VW__ has quit IRC15:02
thomasemMay I get another core review of https://review.openstack.org/#/c/427777?15:02
*** VW has joined #craton15:02
thomasemand https://review.openstack.org/#/c/428996/15:03
thomasemBoth already have a +215:03
*** VW has quit IRC15:03
*** VW_ has quit IRC15:03
*** VW has joined #craton15:04
*** VW has quit IRC15:05
*** VW has joined #craton15:05
sulosigmavirus: so it seems to have mixed up the query somehow https://gist.githubusercontent.com/sulochan/8faff00f20a13351d0e3f35f95f419b6/raw/50c6a5cec56cd1c22d3e76975a055e2b2638b744/gistfile1.txt15:05
sigmaviruswow that's huge15:06
suloSELECT anon_1.devices_created_at AS anon_1_devices_created_at, anon_1.devices_updated_at AS15:07
sulothat cant be right15:07
sigmavirusyeah that was confusing to me15:08
sigmavirusI have no clue what SQLA is generating there15:08
sigmavirusI suspect that oslo_db's pagination helper wasn't designed to work on queries with variatic association15:09
sigmavirusperhaps we can't actually paginate that15:12
sigmavirussulo: that line number in the _paginate function doesn't match up for what the latest patch has15:17
sigmavirusI'm sure this will still happen, but you could you rebase so I could figure out what exactly is generating that exception?15:17
thomasemhaha git-harry, looks like cell-list doesn't work now, too. :P15:27
git-harrythomasem: damn it, I guess we need some more tests there.15:31
thomasemYeah, including integration tests15:32
* sigmavirus wishes our unit tests weren't so fragile15:39
*** anonymike has joined #craton15:39
thomasemCould always mock out the function you're testing. They'll never break.15:39
thomasem:P15:39
* thomasem shields face15:40
thomasemSo, why were those options available previously for those calls?15:46
thomasemin the CLI15:46
*** acabot has joined #craton15:48
*** VW has quit IRC16:01
*** VW has joined #craton16:02
jimbakerthomasem, agreed, we need to support tox -e integration for python-cratonclient16:02
*** VW has quit IRC16:03
*** VW has joined #craton16:03
jimbakerinteresting about that query16:04
*** VW_ has joined #craton16:05
*** VW_ has quit IRC16:05
jimbakerit can be useful to control the specifics of this query by doing such things as suppressing eagerness in the query16:05
*** VW has quit IRC16:05
*** VW has joined #craton16:05
jimbakerhttp://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html16:07
jimbakerit's worth pointing out that if we don't want the variable details, we shouldn't be doing any joins against variables and the variables association table16:09
jimbakersigmavirus, sulo, ^^^16:09
sigmavirusI'm reading those docs16:09
sigmavirusjimbaker: am I remembering wrong, or are labels not variable associations?16:10
jimbakersigmavirus, labels are treated differently16:10
*** jovon has joined #craton16:11
jimbakerthey are just an associated table for devices; we don't actually implement labels for other resources16:11
jimbakerthat could make sense... labeling a region could be reasonable... but it's possible we might even stop using labels and just use variables. that's a more interesting question i think16:13
thomasemThere was a subquery rendering bug, iirc, in SQLAlchemy related to eagerness16:19
thomasemI thought it was fixed, though16:19
thomasem:In Quark we attempted to use lazy='joined' to eagerly load, specifically, the 'associations' relationship on the IPAddress model and this was causing some functional tests to break due to a rendering bug where it would render 'ORDER BY address' in the outer query where it should have been 'ORDER BY <outer_query_alias>_address'.:16:21
thomasemBlurb from my bug about it way back when ^^16:21
jimbakerthomasem, we have this pinning: SQLAlchemy<1.1.0,>=1.0.10 # MIT16:26
thomasemYeah, I just saw that in my venv16:26
thomasemSo, it _should_ be fixed. Anyway, I don't want to throw red herrings out here. Sorry.16:26
jimbakerlatest sqlalchemy is at 1.1.5. maybe this requirement can be updated?16:27
jimbakerthomasem, so in this case, i think we don't need this fix because we should not be joining in these tables16:28
sigmavirusjimbaker: it should get auto-updated16:28
jimbakereven if we implement ?...details=all, that can be through a separate query16:28
jimbakersigmavirus, but it is pinned to be before <1.1.016:29
thomasemAgreed.16:29
thomasemAnd we can definitely cross that bridge when we get there.16:29
tojuvoneEvening16:29
sigmavirusjimbaker: we synchronize from upstream requirements. When that requirement is updated there, we'll receive it auto-magically16:30
thomasemgit-harry: I'm going to remove those options from the project-* calls in my CLI patch. Are you working on any of the other clean up around the issue we were discussing earlier?16:31
thomasemproject-list will only support --name, --detail, and --limit16:32
thomasemuntil further functionality is introduced into the API for it16:32
thomasemOh, and --fields :)16:33
git-harrythomasem: sounds like a plan. I'm not currently, I'm still going through reviews16:33
thomasemOkay, cool16:33
thomasemI'll push this up and then do the same.16:34
tojuvonegoing to update nova spec for single and same url for admin and owner of VMs in host. Just need to take care of having policy working on Craton side16:34
tojuvonehttps://review.openstack.org/428070/16:35
tojuvoneNow spec is not mentioning Craton, I do not know if it should.16:35
tojuvoneAnyhow planning to have there a link for the main idea of "planned host maintenance" and that will mention plan to use Craton16:37
tojuvoneNeed to get that spec work going if to have still in Pike16:38
tojuvoneThoughts?16:41
*** Syed__ has joined #craton16:42
sulotojuvone: where do you see craton coming into play for that spec ?16:56
tojuvonesulo, url that will be set there will point to craton16:57
tojuvonebut it can be just generic URL16:57
sulotojuvone: ah, but that could be any url right ?16:57
tojuvonesure16:57
tojuvonethe point being just if pointing to Craton16:58
tojuvoneI would keep single url instead like it is currently proposed there16:59
tojuvoneif set there url like: https://gerrit.opnfv.org/gerrit/2837916:59
tojuvonethat is same that will be shown to owner of server/vm16:59
tojuvoneups16:59
tojuvonelol, wrong link'17:00
tojuvonehttp://${CRATON_IP}:8080/v1/hosts/{id}/host_details17:00
sulotojuvone: so you want nova to know how to set the url ?17:00
tojuvonejust need policy to work when implementing to craton17:00
tojuvonethat server owner and admin can query that17:01
tojuvoneNow admin will set the url that points to Craton17:01
jimbakerhi, we should probably get started on our craton meeting17:01
tojuvonesorry17:01
sulotojuvone: ok, not sure i am following this right now17:01
sulolets chat more after the meeting17:02
jimbakersulo, or during the meeting17:02
jimbakerthis is a good topic17:02
jimbaker#startmeeting craton17:02
openstackMeeting started Thu Feb  9 17:02:25 2017 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.17:02
sulosure, i dont mind17:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:02
openstackThe meeting name has been set to 'craton'17:02
jimbaker#chair sigmavirus sulo jimbaker17:02
openstackCurrent chairs: jimbaker sigmavirus sulo17:02
jimbaker#link https://etherpad.openstack.org/p/craton-meetings17:02
jimbaker#topic Roll Call17:03
thomasemo/17:03
jovono/17:03
Syed__o/17:03
* sigmavirus can't chair this today17:03
jimbakersigmavirus, np, i will chair17:03
jimbakerand hopefully keep short17:03
git-harryhi17:03
tojuvonehi17:03
sulohello17:04
jimbakerso at some point we agreed that we are not supposed to have this meeting if we didn't have an agenda in advance...17:05
jimbakerbut given lots of stuff happening... i believe we should disregard and have a short meeting regardless :)17:05
jimbakereveryone ok with that?17:06
Syed__yep17:06
jovonindeed17:06
jimbakerawesome. let's just move to our standing agenda, and fit in what we need to communicate17:06
thomasemyep17:06
jimbaker#topic Action Items from Last Meeting17:07
jimbakerhttp://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-06-15.00.log.html17:08
jimbakerbunch of action items. so i haven't taken care of doing the dusty's req doc as launchpad17:09
jimbakerbug17:09
thomasemI have not gotten around to the BP yet this week. I took the bulk resources endpoint bug, but that's lowered in priority right now.17:09
thomasemHad some good discussion around the latter, though, and will continue once we get some more critical things done.17:09
jimbakerthomasem, agreed. we will want to figure out deployment specifics, and if you want to continue to drive point on that, that would be great17:10
thomasemYou bet17:10
jimbakerre dusty's doc, we got some very useful triaging in our discussion with toan and antonym17:11
jimbakerwhich to recap for others here (such as tojuvone)17:11
jimbakerwe are trying to figure out for rackspace if we can immediately use craton for some rackspace support needs17:12
jimbakerseparately i discussed with farid getting these into launchpad so we can track17:12
jimbakeri believe as your project lead :) that the most important thing we can do is see craton get adopted for real usage. it will get us in front of real problems, which this project is all about solving17:13
jimbaker*so earlier is better here*17:13
jimbakerso that's my action item and thomasem's17:14
jimbakersigmavirus is out this point, but we can discuss that later17:14
jimbakersulo, it was mentioned as info, but it could be considered an implicit action item as well given priority17:15
* sigmavirus is here17:15
sigmavirusjust also in another meeting17:15
thomasemYeah. We have some discussions that need be had with another contender for these use-cases.17:15
sigmavirusand can't focus on chairing this one :)17:15
jimbakersigmavirus, no worries. do you want to report on your action item at this time?17:15
jimbakersulo, also please give us feedback on Parent/Child Relationship work is the highest priority work for this week (was marked as #info)17:16
sigmavirusJust constantly spinning between projects. Everytime I come back to craton I'm working on testing things17:16
sigmavirus(Things I have in flight)17:16
jimbakersigmavirus, and that's your action item right, testing the CLI - hopefully will reduce some of that spin as well17:17
Syed__cool17:18
jimbakerok, let me report on the last high priority item, that might have been marked as #action; more work on the getters/setters in the client/CLI, mostly by clean up; and addition of delete support17:19
jimbakeri will push that up momentarily. did find that our DELETE on variables doesn't actually do anything, so i have a patch for that as well17:20
Syed__Sounds good17:20
Syed__for me, i have been looking into https://bugs.launchpad.net/craton/+bug/166284217:20
openstackLaunchpad bug 1662842 in craton "Allow search by labels" [Critical,New]17:20
jimbakeri like the curious symmetry of "addition of delete" :)17:20
Syed__and have some patches in the review, need to write functional test for update calls of projects and users and that patch will be good to go17:21
jimbakerSyed__, that's cool, but we are currently focused on action items17:21
Syed__Sounds good, i guess once bugs are raised and referenced properly, helps a lot in picking those up17:21
jimbakerSyed__, right, that was part of my conversation with farid is everyone doing a better job there. which seems to have improved. and more importantly, making it easier to use the bug info to get at useful reporting17:22
jimbakerso we will work on that, and that's very much related to the "requirements as a bug/feature" (or better, bugs) action item i started off with17:23
Syed__yeap and that would be great once we have that in place17:24
Syed__+117:24
jimbakerawesome. i think that's it for action items, which all seem to be in flight at this point17:24
jimbaker#topic Stand-up17:25
jimbaker#topic Stand-up - Syed17:25
jimbaker(let it be noted that the meetbot seems currently unresponsive. but it's in the log)17:26
Syed__Sounds good17:26
jimbakerSyed__, anything you want to add to your earlier comments?17:26
Syed__No i guess thats all i am doing. Will be looking into picking some CLI bug apart from other things i am doing17:27
jimbakerSyed__, that would be great17:27
jimbaker#topic Stand-up - git-harry17:27
jimbakerfwiw, git-harry, i'm still thinking about my response to your spec on variables in https://review.openstack.org/#/c/428190/17:28
jimbakerand i see you have some changes now for review17:28
git-harryI've got some patches in review for tidying up the variables a bit. Currently I'm going through the review queue. If there's high priority stuff that needs picking up, point me in the direction of it and I'll take a look.17:29
git-harryjimbaker: that stuff is just clean up to make any future changes easier17:29
git-harrydone17:29
jimbakergit-harry, got it. dupe removal is good. i do have concerns about some of the API changes you proposed, namely around PUT17:30
jimbakerfor variables17:30
jimbakerwe can discuss further17:30
git-harryokay17:30
jimbaker#topic Stand-up - jovon17:30
jimbakerwe will circle back to jovon17:31
jimbaker#topic Stand-up - thomasem17:31
jovon currently working on documenting users, projects, and devices.17:31
jimbakerjovon, +117:32
thomasemNeed reviews:17:32
thomasemhttps://review.openstack.org/42777717:32
thomasemhttps://review.openstack.org/42899617:32
thomasemBeen keeping those tidy17:32
thomasemCurrently working on wiring up Cloud resource in between Project and Region17:32
thomasemGoing through the review queue as well17:32
jimbakerthomasem, awesome, sounds like you're keeping busy!17:32
thomasemI try!17:33
jimbakeri expect any number of conflicts here, but we will get the changes in17:33
thomasemOther than that, had a lot of meetings distracting me this week, but that won't continue much.17:33
thomasemNeed to write up a bug for the issue git-harry found this morning with an API change that went in, so putting that on my list right now.17:34
thomasemdone17:34
jovonquestion. are we planning to create a separate definition for devices? as it is currently nested within net devices?17:34
jimbakerthomasem, thanks for reminding us of that part of standup protocol17:35
thomasemYou bet!17:35
jimbakerjovon, consider it like an abstract class17:35
jovonunderstood17:35
jimbakerit should not be directly instantiated17:35
jovonjust curious17:36
jimbakernot certain if sqlalchemy would prevent, but our apis certainly do not support17:36
jimbakerjovon, no worries. but let's move to open discussion if more. everyone, please remember your open discussion topics!17:36
jimbaker#topic Stand-up tojuvone17:37
tojuvoneok..17:37
tojuvoneI want to make "planned host maintenance" using Craton17:37
tojuvoneAdding namespace, something like:  http://${CRATON_IP}:8080/v1/hosts/{id}/host_details17:37
tojuvoneI want to add this url link to Nova17:37
tojuvoneNow in Craton namespace host_details is added by "admin"17:38
tojuvonebut in Nova side also owner of server/VM will see the same link17:38
tojuvoneI guess we can handle the policy somehow in Craton to make this possible?17:38
tojuvoneI want to update my Nova spec with different url to link to Craton than it currently state there: https://review.openstack.org/428070/17:38
jimbakertojuvone, so we should have the level of support necessary for this in rbac17:38
jimbakerbut rbac + namespaces is not something we have considered just yet17:38
jimbakerhaving said that: i think namespaces are exactly the way one would want to organize some set of variables for rbac17:39
jimbakerwe have considered separately that the prefix of a variable is something we would directly control with rbac, and is mentioned briefly in the rbac bp that is posted17:40
jimbaker(this follows similar practice in tooling like zookeeper or consul)17:40
sulotojuvone: your nova service permissions are different from craton .. unless you are using all within the same keystone domain/context17:41
jimbakerso that is the extended answer to yes17:41
jimbakersulo, and that's a great question, what that cross service permission model means17:41
sulotojuvone: i am not sure why you are worried about policy right now .. i think what should matter here is how does nova know to create the link17:41
sulotojuvone: the answer is possibly, it doesnt17:41
tojuvoneWe need to set it there17:42
tojuvonewhen making http://${CRATON_IP}:8080/v1/hosts/{id}/host_details17:42
suloso unless this url is something you are manually looking to set in nova .. i dont see how this will work17:42
sulotojuvone: what is id ?17:42
suloid here is craton id .. nova doesnot know that17:42
jimbakersulo, so we see some similar sort of bidirectionality required in webhooks17:42
tojuvone"id" I guess we have in Craton host the "id"17:43
sulojimbaker: how do you mean ?17:43
jimbakerbut can i ask we move this to the open discussion?17:43
sulotojuvone: yes, but how does nova know that id ?17:43
sulotojuvone: are you going to manually push the url for each host ?17:43
jimbakerplease remember this topic, we can get back to it17:43
jimbakersulo, since you are here17:44
tojuvoneyes, need to push it to Nova17:44
jimbaker#topic Stand-up sulo17:44
sulojimbaker: iirc nova does not have any webhooks, neither do we17:44
jimbakersulo, no, but it's in the same idea. what can we learn?17:44
jimbaker:17:44
jimbaker:)17:44
suloI am just chasing a sqlalchemy bug thats causign search by labels to fail17:44
suloits on pagination function17:45
sulobut looks like something weird on sqla17:45
jimbakersulo, ok, is this something we can ignore for now17:45
sulonot unelss we want search by labels to work17:45
jimbakerby avoiding that join?17:45
sulojoin ?17:45
jimbakerto the labels table17:46
jimbakerbut  back up17:46
jimbakerthe relevant question is search by labels17:46
sulonot sure i follow, why woud that matter ?17:46
jimbakerso sure, that needs to work :)17:46
suloalthough, it is freaking out on labels join .. we do join on variables too .. which seems to work17:47
sulowell, its not exactly join its freakign out on17:47
jimbakersulo, earlier we were discussing unnecessary joins and how that was impacting pagination. specifically variable details when such details were not requested (not even implemented!)17:47
suloits the part where pagination is adding limit17:47
sulojimbaker: thats different ? .. we are eager loading17:48
sulowe can chagne that to select load17:48
sulobut that wont fix this problem17:48
jimbakersulo, and eager loading can be great. but not here17:48
jimbakerlet's back up. i wanted to find out earlier about parent/child and supporting cabinet to container views17:49
jimbakersince this is the highest priority task we have right now, other than variable support down to the CLI17:49
suloparent_id is a easy fix, ill push a review soon17:49
suloi need this pagination work to get done for that17:50
jimbakersulo, ok, just want to make sure we are addressing17:50
sulosince it piggybacks on the links support added by ian17:50
jimbakerah, ok17:50
jimbakerand not so separable17:50
jimbakeras coded now17:50
suloyeah its tied to this code17:50
sulomy change is based on this work17:50
suloeverything works .. except the seach by labels test is failing17:51
jimbakergot it. i was hearing pagination, and thinking, that's not in any of our immediate reqs17:51
jimbakereven though we know it's super important for the future17:51
suloanyway need to figure out why this is happening17:51
suloas it seems there might be other conditions this can cause pain with17:51
jimbakeryes. let's spend some more time on this17:52
jimbakerbut we may need to separate out the link code and defer pagination if too much17:52
jimbakerjust want to give us that out17:52
suloyeah so the search function i had added while back17:52
suloand without the pagination bit it works17:52
jimbakergot it17:52
suloits a much have feature righ tnow17:53
suloexample: seach for all compute nodes17:53
suloor api nodes etc17:53
suloby labels17:53
jimbakerin terms of vars17:53
sulomore than one service on a host17:53
suloidentified by host labels17:54
jimbakerright, which is more efficient with labels than going into json17:54
jimbaker#info clearly we have gone to open discussion...17:54
jimbakersulo, let me state something provocative/time saving: i do wonder if we will end up not caring about labels after all17:55
sulohow so ?17:56
jimbakerwhat would happen if we just removed labels?17:56
sulowe wont have a nice way to tag hosts ? vars are not well suited for this ?17:56
thomasemYes... what WOULD happen if we just removed labels?17:56
jimbakercould we do the same sort of queries, by using variables?17:56
sulomaybe17:56
suloit might be ugly17:57
jimbakersulo, especially given namespaces, which we will be implementing17:57
suloexample: host1 needs 3 labels "compute", "api", "scheduler"17:57
suloeven with namespace17:57
jimbakerso let's say we have the labels namespace17:57
sulolabels (namespace) will have which k:v pair17:57
jimbakerlabels/compute=true17:58
jimbakerbasically we get everything we need17:58
suloyeah, i dunno how that seach will look like17:59
jimbakeryes, right now our variables search is expensive, because it's not indexed. but it should be cheap with the right json indexing17:59
jimbakerin this case, it might be still be fine, since we only care about the presence of keys, not even the values17:59
thomasemIt would be weird to have labels/compute=false18:00
thomasemand treat it as a compute.18:00
suloyeah18:00
suloi mean we can make it work if desired18:00
jimbakerthomasem, but that's why we have the labels namespace18:01
jimbakeri should point out that the usual representation of a set is a dict...18:01
suloyeah i dunno18:01
sulowhat happens when someone does compute=false18:01
suloit wil mean we have to query on k and filter on value18:01
jimbakercpython may have an alternative implementation; but that's how it's done in java for example: key=true18:02
jimbakerimplicitly18:02
jimbakersulo, so we constrain with the namespace18:02
jimbakerwe can use convention for now18:02
sulolike ?18:02
jimbakerbut one thing tojuvone and i discussed is that if we had a "maintenance/" namespace, we could constrain the allowed transitions18:03
suloso what do we gain from doing k:v labels, vs doing labels the way it is now ?18:03
suloi think if we gain more .. then its a no brainer18:03
jimbakerso one can just set keys to arbitrary values18:03
jimbakersulo, so we get k:v labels for free18:03
jimbakerand we implement less db code, and complex queries18:04
suloi get that .. but whats the use case for that18:04
jimbakerwhich are currently breaking18:04
jimbakeralso, labels don't work on anything but devices18:04
suloright18:04
sulothen its the equivalent of getting rid of labels18:04
tojuvoneActually might extend /maintenance to more generic /host_details18:04
sulok:v is just vars18:05
jimbakeryes!18:05
sulowe can still keep the endpoint etc ..18:05
sulonot saying i am convinced this is good yet18:05
jimbakersulo, because it knows about the labels/ namespace18:05
suloyeah18:05
suloi am mostly worried about perf hit when there is large data seach on vars18:05
sulobut if we dont think that will be a probl18:06
sulothen its fine18:06
jimbakersulo, i think it's less of a problem than a multitable join18:06
tojuvoneI need to go, but be back in as hour or so18:06
sulojimbaker: you will have that join regardless .. because varxmixin18:06
jimbakertojuvone, thanks for your participation18:06
sulojimbaker: currently we can get rid of vars in labels seach18:06
sulothats a differnt issue18:06
jimbakersulo, there are joins regardless :)18:07
jimbakerjust fewer joins18:07
jimbakerin a complex query18:07
suloheh sure18:07
jimbakerso consider labels + variables in the search query. with pagination. uh-oh18:07
* thomasem needs to go investigate the labels implementation18:08
sulojimbaker: yeah, i think we should experiement for sure18:08
jimbakerthomasem, it is simple, and a delight to read18:08
jimbakerbut it's too simple imho18:08
sulothis is somethign we've talked about for a while anyway18:08
sulomaybe its time to just try it out18:08
jimbakersulo, yeah, we kept on simplifying variables18:08
jimbakersorry, simplifying *labels*18:09
jimbakerultimate simplification: remove them18:09
sulowell anyway, in terms of priority work to get done18:09
sulowe needs labels right now18:09
jimbakerbut again if we can just use convention now18:09
jimbakerlabels/compute=true18:10
jimbakerthen figure out how to make that cleaner later...18:10
jimbakerthen we can get this done now18:10
sulothats a much bigger change right now ?18:11
sulothat needs change on all layers including api maybe18:11
jimbakerbut vars work now18:11
sulowill have to look18:11
sulolabels works too18:11
jimbakerjust not enough18:11
jimbakeranyway... good discussion18:11
sulowell its pretty bad if we are getting rid of label because somethig else is breaking it18:11
sulolets figure out why paginaiton is breaking it18:12
sulorather than getting rid of it18:12
jimbakersulo, so i would first relax the requirement on sqlalchemy18:12
jimbakerand use 1.1.518:12
jimbakeras we earlier discussed18:12
jimbakeron this channel18:12
jimbakerthomasem mentioned that he saw a similar bug18:12
jimbakeri suggest we wrap up our meeting. we are well over18:13
jimbakerdiscussion can continue of course18:13
jimbakerseeing no objections....18:13
thomasemThat bug might have been fixed, btw. I wanted to throw out an idea of where to look, but I haven't gone and dug in very deep on it.18:13
jimbaker#endmeeting18:13
openstackMeeting ended Thu Feb  9 18:13:58 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:14
openstackMinutes:        http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-09-17.02.html18:14
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-09-17.02.txt18:14
openstackLog:            http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-09-17.02.log.html18:14
thomasemThat bug was in SQLAlchemy < 1.0, iirc. I don't know if it's still there.18:14
jimbakerthomasem, so very early SA18:14
thomasemI seem to remember installing 1.0 caused it to disappear, but that was years ago.18:14
jimbakerbut still worthwhile trying in the 1.1 series18:14
jimbakerjust to see if it goes away18:14
thomasemGotcha18:15
suloso check this https://gist.github.com/sulochan/28d2827c80d580091c9c5bb4e706b4a718:16
jimbakerthat it happens to come because of a certain variable modeling is not so relevant. it's the joins18:16
sulothat function is ..https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/utils.py#L13818:16
suloso it looks like i get some werid behavior when doing limit18:16
suloif you commit out line 261 where its adding the limit, then everything is happy18:17
suloso this must be some sqlalchemy weirdness18:17
jimbakerstuff like that makes me want to have a simple path for the usual query18:18
jimbakerand just do the limit in python18:18
suloyeah18:18
jimbaker(ordering still has to be done of course)18:18
jimbakerthe usual: top N results are the most common query18:18
jimbakeroptimize for that first before anything special for the next set of pages18:18
suloanyway afk for now18:19
*** VW has quit IRC18:20
jimbakersulo, np, and thanks!18:20
jimbakergreat meeting everyone, much appreciated!18:20
*** VW has joined #craton18:20
*** VW has quit IRC18:20
*** VW has joined #craton18:21
jovongreat job team! (just a little moral support) :)18:21
jimbaker:)18:24
*** VW has quit IRC18:42
*** VW has joined #craton18:42
*** VW has quit IRC18:47
*** VW has joined #craton18:50
tojuvoneback for a while19:06
thomasemwb!19:07
tojuvonethx19:07
*** VW_ has joined #craton19:08
*** VW_ has quit IRC19:10
*** VW_ has joined #craton19:10
*** VW_ has quit IRC19:11
tojuvoneI think I know now how I will change my spec19:11
*** VW_ has joined #craton19:11
tojuvoneCan deal with the details how things will be done in Craton side later19:12
*** VW has quit IRC19:12
tojuvoneBtw, going to be in London from Saturday till Tuesday and also off holiday on week 8.19:15
jimbakertojuvone, next week? you can potentially meet up with sulo and git-harry - sulo i know is near heathrow, and i believe git-harry is too19:18
tojuvonejimbaker, Otherwise nice, but I go with the family :)19:24
tojuvoneHarry Potter studios and stuff :D19:25
tojuvoneyes, would be so great to meet otherwise19:27
jimbakertojuvone, awesome, i enjoyed visiting the harry potter attraction in orlando a few years back. should be fun!19:49
Syed__git-harry: you around ?19:53
*** VW_ has quit IRC20:00
*** VW has joined #craton20:01
thomasemruh roh, network troubles20:13
-openstackstatus- NOTICE: Restarting gerrit due to performance problems20:18
thomasemaha20:19
thomasemThat's what it is20:19
*** VW has quit IRC20:29
*** VW has joined #craton20:29
*** harlowja_ has joined #craton20:35
*** harlowja has quit IRC20:37
thomasemI must run to an appointment. bbiab20:41
jimbakernp20:43
*** VW has quit IRC20:48
*** VW has joined #craton21:24
*** VW_ has joined #craton21:26
*** VW_ has quit IRC21:26
*** VW has quit IRC21:26
*** VW has joined #craton21:27
*** harlowja_ has quit IRC21:58
*** harlowja has joined #craton22:05
jimbakerthomasem, please refactor your change for https://review.openstack.org/#/c/427777/ based on the work i just +2'ed for the var refactoring22:20
jimbakerjust love it when we can remove code, and make it easier to implement changes like what is needed here for project vars support22:20
jimbaker(i have my own minor refactoring to now do based on this change, with respect to properly support deletion)22:21
*** jovon has quit IRC22:22
thomasemjimbaker: Sounds good. I was going to come in behind and do that anyway, so might as well do it now since that got in. :)22:43
jimbakerthomasem, i was only helping you :)22:52
jimbakerand this minimizes a fix i need to make as well. plus better testing i can use22:52
thomasemjimbaker: oh, yeah! No worries.22:56
jimbakeri'm just glad that the vars work uses a mixin approach in the model; now the api; and soon the client. this is going to make var support easier to manage, especially as we start adding support like namespaces22:58
thomasem+1--22:58
thomasem+100*22:58
thomasemlol22:58
jimbakeranother thing we will soon want to decide is if we want to remove labels. i'm increasingly in favor of this, given that vars work just as well23:01
jimbakerone fewer abstraction to implement, and vars are more pervasive. right now labels only support devices, and i think that's a legacy of an older design idea23:01
jimbakeranother consideration would be searchlight support - if we just need this with vars, that just makes it easier23:02

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