Tuesday, 2015-05-26

*** chlong has joined #openstack-dns00:15
*** marzif has quit IRC01:00
*** logan2 has joined #openstack-dns01:25
*** stanzgy has joined #openstack-dns01:35
*** dguerri`away has quit IRC01:41
*** dguerri`away has joined #openstack-dns01:45
*** dguerri`away is now known as dguerri01:45
*** kei_yama has quit IRC03:11
*** kei_yama has joined #openstack-dns03:15
*** penick has joined #openstack-dns05:03
*** logan2 has quit IRC05:08
*** nihilifer has joined #openstack-dns05:45
*** chlong has quit IRC06:30
*** kei_yama has quit IRC06:39
*** kei_yama has joined #openstack-dns06:45
*** hetii has joined #openstack-dns07:04
*** logan2 has joined #openstack-dns07:06
*** jordanP has joined #openstack-dns07:09
*** logan2 has quit IRC07:17
rcarrillocruzmugsie: hiya, i'm working on adding designate on shade library, if you remember a conversation we had on our employer messaging app last week or so there is an issue on designate python client when using keystone auth07:24
rcarrillocruzhttps://review.openstack.org/#/c/184988/07:24
rcarrillocruzdguerri as awesome as he is pushed a change for it07:24
rcarrillocruzany change we could get another core review? and how often do you release python designate to pypi? is it automated or you do after a git tag and the post job does its magic?07:25
*** rcarrillocruz has quit IRC07:58
KiallThat was probably meant as a PM for me ;) Oh well!08:52
*** logan2 has joined #openstack-dns09:02
*** rcarrillocruz has joined #openstack-dns09:06
openstackgerritMerged openstack/designate: Disable recursive queries with bind in Devstack  https://review.openstack.org/18520109:19
*** marzif has joined #openstack-dns10:39
stanzgyKiall: You have disappeared for a long time, finally show up again ;)10:41
Kiallstanzgy: lol - OpenStack Summit was all last week in Vancouver10:41
stanzgyKiall: Yea, I know. I checked the Summit agenda and a bit interested on DB rework topic. Any conclusion or notes on this?10:43
*** boris-42 has joined #openstack-dns10:49
* ekarlso is curious on that too10:55
Kiallstanzgy: mostly that everyone agrees it's in poor shape today, the initial set of things to cleanup are...10:55
Kiall1) Connection management .. 2 SELECT's outside of a TX in a single call should use the same connection, not checkout a new connection from the pool each time.10:55
Kiall2) Many of the storage methods need updating for "batch" actions.. e.g. `UPDATE/DELETE ... WHERE <criterion>` or `INSERT ... VALUES (...), (...) etc`10:55
Kiall3) Cleanup central to avoid fetching stuff from the DB needlessly over+over inside tight loops10:55
Kiallalso some talk of adding some caching of resultsets, but it remains to be seen how you you go about invalidating the right cache items once #2 is implemented..10:58
Kialle.g. UPDATE records SET status = 'ACTIVE' WHERE status = 'PENDING' and domain_id = <foo>10:58
KiallDetermining which cache entries to expire there will be difficult.. And likely (effectivly) impossible if we allow for queries without the domain_id criteria10:58
*** stanzgy has quit IRC10:58
*** untriaged-bot has joined #openstack-dns10:59
untriaged-botUntriaged bugs so far:10:59
untriaged-bothttps://bugs.launchpad.net/designate/+bug/145611510:59
openstackLaunchpad bug 1456115 in Designate "DesignateContext.is_admin is false on admin tenant" [Undecided,In progress] - Assigned to stanzgy (stanzgy)10:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145813010:59
openstackLaunchpad bug 1458130 in python-designateclient "Missing Logger Handler" [Undecided,New]10:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145508310:59
openstackLaunchpad bug 1455083 in python-designateclient "record create call ignores 'description' param" [Undecided,Incomplete] - Assigned to DIV (div-unknown)10:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145782110:59
openstackLaunchpad bug 1457821 in python-designateclient "all_tenants and edit_managed not defined using external keystone session" [Undecided,In progress] - Assigned to Davide Guerri (davide-guerri)10:59
*** untriaged-bot has quit IRC10:59
Kialland stanzgy left.. oh well ;) will point him at the room logs :D11:04
*** stanzgy has joined #openstack-dns11:37
Kiallstanzgy: I replied, but way too long to paste again ;) check the room logs11:39
stanzgyKiall, got it, thanks for the explanation. Just got home from office :)11:42
Kiall1 thing I forgot.. Those items are just the easy / obvious starting points..11:42
KiallAnd that cleanup would be a multi-cycle ongoing thing11:42
stanzgyKiall, Now my team is suffering from db performance/deadlock issues. Not only in Designate, but also Nova/Neutron/etc.. Sometimes only mysql's slowlog is not enough since it lacks python contexts. We want some profiling tools which could get deep inside Openstack. e.g.: https://github.com/inconshreveable/sqltap  It could not only print sql query metrics, but also the python call-stack backtrace. Do you think it's valuable to introduce this kind of11:55
stanzgydb profiling tool into Designate, or just let developer themselves hack it?11:55
Kiallstanzgy: probably not exactly what you're looking for, but you can ask oslo.db to include traces with the connection_trace option11:55
Kiallthe trace will end up as a SQL comment11:56
Kiall(It'll likely KILL performance tho, given genererating a trace is a slow thing to do)11:56
Kiallbut, it should hurt perf equally everywhere, so the slowest stuff should still be the slowest stuff if you get what I mean11:56
stanzgyKiall, AFAIK oslo.db could not collect query time/counts statistics?11:57
Kiallsqltap looks interesting though .. as yea, it gathers some stats11:58
KiallI'd generally end up using percona-toolkit to analyize slow query logs etc, most of the time I can tell where each query is coming from by looking at it.. So, the traces etc are less useful to me :)11:59
stanzgyKiall, in fact we just use sqltap to find a neutron db issue which neutron-sever calls thousands db.query in a single API call and make it very slow. It's some kind useful :D12:00
KiallYea, I have no doubt being able to gather things like the list of queries execited for a single request-ID accross the various services etc would be useful :)12:01
stanzgyevery single query is not slow and will not print to mysql-slow.log. but thousands of them make it very very slow.12:01
Kiallhttps://github.com/stackforge/osprofiler is starting down this general direction from what I understand12:02
stanzgyKiall, okay, thanks for the information, I'll check it later.12:03
KiallThe reports aren't quite what percona-toolkit or sqltap would produce, example: http://pavlovic.me/rally/profiler/12:03
KiallIf you dig "deep enough" you see SQL queries, but that whole example is 1 request spanning multiple openstack services etc12:04
stanzgyKiall, see it, very coool chart12:04
KiallYea, I'd love to see someone wire designate up for it ;) boris-42 started a while back, but it never passed gate! I think we do something weird which it didn't support from memory12:05
Kiallanyway - I'd look at grabbing the authors of osprofiler, and seeing if they have plans to get more SQL-centric reports  and/or need the help, as you'll get "automatic" support in almost every project12:06
boris-42Kiall: ?12:06
boris-42Kiall: where wat ?12:06
Kialllol :)12:07
boris-42Kiall: btw I am going to continue work12:07
boris-42Kiall: on it12:07
KiallI was just remembering this review https://review.openstack.org/#/c/134841/12:07
boris-42Kiall: finally I got support from community12:07
KiallYep :)12:07
boris-42Kiall: yep I didn't get the fully what the hell I am doing wrong12:07
boris-42=)12:07
boris-42Kiall: but I will try to revisit it12:07
KiallIt's likely something Designate is doing stoopidly... But, no idea what :P12:08
boris-42Kiall: lol12:08
boris-42stanzgy: hey nice to meed you12:09
*** ducttape_ has joined #openstack-dns12:09
stanzgylol, I stared this patchset and will check it later to see if I can find something :D12:09
boris-42stanzgy: http://boris-42.github.io/ngk.html12:09
boris-42stanzgy: ^ btw this is new output12:09
*** km has quit IRC12:10
*** dguerri is now known as dguerri`away12:10
stanzgyboris-42, hi, very cool. wish I could use it on my servers. :)12:10
boris-42stanzgy: so it's already merged in heat, cinder, glance and as far as I remember trove12:12
stanzgyboris-42, does it has a bp name?12:12
*** logan2 has quit IRC12:12
boris-42stanzgy: so it's not about BP12:13
boris-42stanzgy: =)12:13
boris-42stanzgy: https://review.openstack.org/#/c/134839/12:14
boris-42stanzgy: I will create improve this spec, add spec to add it to oslo12:14
boris-42stanzgy: and I will create google doc with road map12:14
stanzgyboris-42, great! wait for your news12:15
*** ekarlso has quit IRC12:16
*** ekarlso has joined #openstack-dns12:16
stanzgyKiall, and another question. Do you think it's necessary that admin could directly create sub-domain for other tenants via create_zone API?12:27
stanzgyI have a usecase that Designate serves sub-domains %(tenant_id)s.%(base_domain)s for each keystone tenant. And the base_domain is belongs to the admin tenant. It's very hard the initialize all the sub-domains now.12:27
KiallWe do actually allow that today.. As you're admin user, you can create domains in other tenants with..12:28
Kiallhttp://docs.openstack.org/developer/designate/rest.html#http-headers12:28
Kiallthe X-Auth-Sudo-Tenant-ID header, and it will let you create in the "sudo" tenant12:29
KiallOr, you can create in the admin, and use the transfer stuff to move it to the target tenant12:29
Kiallhttp://docs.openstack.org/developer/designate/rest/v2/zones.html#transfer-zone12:29
stanzgyKiall, in my memory it's ok with primary domains, but failed with sub-domains. I'll confirm it tomorrow.12:29
stanzgyKiall, in fact I'm using the domain-transfer way now :(12:30
KiallOh, that could be a bug so12:30
stanzgyKiall, I'm not sure about it. let me check it tomorrow.12:30
* Kiall files another internal JIRA to get tempest tests for zone-transfers12:30
stanzgyKiall, lol, it's maybe my fault.12:32
ekarlso*on it* :p12:34
*** ducttape_ has quit IRC12:35
*** ZZelle has joined #openstack-dns12:40
*** robert4man has joined #openstack-dns12:40
*** dguerri`away is now known as dguerri12:50
*** stanzgy has quit IRC12:52
*** cflmarques has joined #openstack-dns12:54
*** cflmarques has quit IRC13:00
*** kei_yama has quit IRC13:08
*** logan2 has joined #openstack-dns13:21
openstackgerritJohn Belamaric proposed openstack/designate: Infoblox Backend  https://review.openstack.org/18310513:29
*** logan2 has quit IRC13:54
*** johnbelamaric has joined #openstack-dns13:55
openstackgerritKiall Mac Innes proposed openstack/designate: Update Dashboard requirements  https://review.openstack.org/18355713:56
*** hetii has quit IRC14:00
*** ducttape_ has joined #openstack-dns14:02
*** pglass has joined #openstack-dns14:04
Kiallstanzgy_: BTW, re https://review.openstack.org/#/c/184432/ / bug 145611514:25
openstackbug 1456115 in Designate "DesignateContext.is_admin is false on admin tenant" [Undecided,In progress] https://launchpad.net/bugs/1456115 - Assigned to stanzgy (stanzgy)14:25
KiallI'm not 100% convinced that really is a bug, is_admin is just badly named these days now that oslo.policy is a thing14:25
Kiallis_admin is meant as a hint to olso.policy to "say yes to everything", rather than the other way around14:26
KiallNothing bar oslo.policy should ever look at the value of context.is_admin, if it does, it's bypassing policy and is a bug14:26
KiallI'll post those comments in the bug report, seems stanzgy's real IRC handle already dropped off14:29
*** jhova has joined #openstack-dns14:37
*** ducttape_ has quit IRC14:38
*** ducttape_ has joined #openstack-dns14:43
*** dguerri is now known as dguerri`away14:44
*** cliles has joined #openstack-dns14:47
*** nihilifer has quit IRC14:47
openstackgerritKiall Mac Innes proposed openstack/designate: Install dnspython3 on python 3  https://review.openstack.org/18564115:13
*** nihilifer has joined #openstack-dns15:19
*** nihilifer has quit IRC15:19
*** nihilifer has joined #openstack-dns15:20
*** stanzgy has joined #openstack-dns15:36
stanzgyKiall: just see your comments on https://review.openstack.org/#/c/184432/15:36
Kiallstanzgy: heya, yep, as I said in the bug report, I'm thinking that's not a bug15:37
KiallMaybe I'm wrong though, I'm curious how you noticed it?15:37
*** stanzgy__ has joined #openstack-dns15:37
Kiallstanzgy__: lol you get those 2 messages, or? ;)15:38
stanzgyKiall: Kiall: IMO it's a convention in Openstack projects that when we want to identify if a context is an *admin context*, we check context.is_admin15:38
*** stanzgy__ has quit IRC15:38
KiallIMO, that's no longer the case - not since projects adopted oslo.policy, and is being removed etc15:39
KiallCode that hardcodes a notion of "admin" is effectivly breaking deployers ability to split the concept of "admin" between multiple groups of users15:41
stanzgyKiall: but when your got a context object with 'admin' role but 'is_admin' is false, it's obvious wrong somehow. If we abandon 'is_admin' attribute we should just remove it from DesignateContext, not offer a wrong value15:42
Kialle.g. if for our "Is allowed see other tenants domains" check do `if context.is_admin", we no longer have any way to allow support staff to do that without also giving all of support full admin15:42
Kiallright - that's the point - the "admin" role is just a name we as a group of projects ship as the default.. Larger deploymens will have many many different roles each with varying levels of the stock "admin" roles access15:43
stanzgyKiall: now In popular openstack projects like nova, context.is_admin is still widely used.15:44
KiallAbsolutly, and that code pre-dates oslo.policy :)15:44
stanzgyKiall: I got you ideas, maybe we should just remove this attribute 'is_admin'15:44
stanzgy?15:44
KiallNeutron's use of context.is_admin has actually bitten us at HP already, and we've had to fork that bit of the code..15:45
stanzgyKiall: if we don't use it anymore15:45
stanzgyKiall: lol, I just made a mistake too by trying to use this in Designate15:45
KiallWell - We do use it - It's a signal to oslo.policy that we want to policy checks to always pass.. Other projects use it this way too, but they also happen to have code that still directly checks it's value too15:46
*** nkinder has joined #openstack-dns15:46
KiallOther openstack projects should be removing code that uses it, and at the very list, should not be accepting new code which uses that style inside of simply asking oslo.policy15:48
Kiallvery least*15:48
Kiallinsteal* lol.. full of typos :)15:48
*** busterswt has joined #openstack-dns15:49
stanzgyKiall: I just check oslo_policy codes, seems there is no codes treats 'is_admin' special. It's special because we define a admin rule as 'is_admin: True' in policy.json, and many API requires this admin rule.15:51
KiallYes, the "is_admin" name is somewhat legacy, something like "is_elevated" would be much nicer.. but we inheit the name from oslo.context, and use it the same way as all the other projects do - at least - the elevated part..15:53
Kiallhttps://github.com/openstack/neutron/blob/master/neutron/context.py#L13415:53
KiallIdeally, it get's renamed.. but convincing 10+ projects to do anything is slow moving ;)15:53
Kiall(L136/L137 in there is legacy legacy code.. lol)15:54
stanzgyKiall: Yea, in Neutron there is many codes use 'is_admin' as if conditions, so we should treat it carefully in neutron. But in Designate we have no case of this.15:57
KiallAs an example of how it's slowely being removed from the code: http://paste.openstack.org/show/238065/15:58
*** EricGonczer_ has joined #openstack-dns15:58
Kiallwe have no case of that because we've sucessfully completed the "Use is_admin only as hint for oslo.policy" migration, while others like neutron are in-progress15:58
stanzgyKiall: lol15:58
KiallIn the paste above, Juno neutron had 48 instances of checking is_admin, Kilo neutron has 2415:59
Kiallonce everyone get's to 0 .. we can likely rename is_admin in oslo.context to something more descriptive :)15:59
stanzgyKiall: IMO for oslo_policy, 'is_admin' is not specially from other rules, just because we have a rule 'admin': 'is_admin is True', and many API require rule 'admin'.16:00
stanzgyKiall: maybe we should just leave 'admin' rule as 'role:admin' instead of  '"role:admin or is_admin:True"'16:01
stanzgyKiall: and abandon the use of is_admin?16:01
KiallThat would prevent some key code from working. For example, while creating a domain, we need to ensure it's uniqueness accross all tenants. So, we need to elevate the users context for a small subset of the request in order to be allowed query for other tenants domains..16:02
stanzgyKiall: huh, it is16:03
*** EricGonc_ has joined #openstack-dns16:04
stanzgyKiall: so in order to get rid of is_admin, how we plan to handle these codes in future?16:05
Kiallis_admin could be named something better (but we have no choice but to keep the name as is, due to oslo.context including it and using it for the things we want)16:06
Kiallhttps://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L4616:06
Kialland the method @ L11016:06
stanzgyKiall: IMO, for current situation, new designate developer(like me) will deeply get confused with this when handling admin context in Designate (withouth explanation)16:07
*** EricGonczer_ has quit IRC16:08
KiallI understand, and hopefully we can improve on that, but I believe making that flag sometimes be used as a hint for oslo.policy, and sometimes get used as the output of a policy check is more confusing. Especially when any usage of a single concept of "admin"  in Designate would be -2'd by almost all the core devs! We all have requirements for partial admin etc16:09
stanzgyKiall: I mean people get a context with admin role but is_admin is False. <--- deeply confused about this16:09
KiallYea, the naming sucks, but we're stuck with it :(16:09
*** EricGonc_ has quit IRC16:10
stanzgyKiall: okay, I'm clear about this now. dunno who is next one. lol16:10
KiallYea, I know.. It sucks! But I don't know how we have improve on it, without encouraging a single concept of "admin" in designate16:11
Kiall(other than renaming it, and we're blocked on that)16:11
stanzgyKiall: Thanks for your time! It's late here and I'm going to sleep now :)16:12
stanzgyKiall: good night~16:13
*** EricGonczer_ has joined #openstack-dns16:13
*** EricGonc_ has joined #openstack-dns16:15
Kiallgoodnight :)16:17
*** EricGonczer_ has quit IRC16:18
*** robert4man has quit IRC16:19
*** mlavalle has joined #openstack-dns16:21
*** stanzgy has quit IRC16:22
openstackgerritMerged openstack/python-designateclient: Move all_tenants and edit_managed attributes to designate Client  https://review.openstack.org/18498816:50
openstackgerritMerged openstack/designate: Drop use of 'oslo' namespace package  https://review.openstack.org/18544816:50
openstackgerritMerged openstack/designate: Add Akamai Management comamnds  https://review.openstack.org/18230916:50
*** jschwarz has joined #openstack-dns16:56
*** untriaged-bot has joined #openstack-dns16:59
untriaged-botUntriaged bugs so far:16:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145813016:59
openstackLaunchpad bug 1458130 in python-designateclient "Missing Logger Handler" [Undecided,New]16:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145508316:59
openstackLaunchpad bug 1455083 in python-designateclient "record create call ignores 'description' param" [Undecided,Incomplete] - Assigned to DIV (div-unknown)16:59
untriaged-bothttps://bugs.launchpad.net/python-designateclient/+bug/145782116:59
openstackLaunchpad bug 1457821 in python-designateclient "all_tenants and edit_managed not defined using external keystone session" [Undecided,Fix committed] - Assigned to Davide Guerri (davide-guerri)16:59
*** untriaged-bot has quit IRC16:59
*** robert4man has joined #openstack-dns17:00
*** jschwarz_ has joined #openstack-dns17:01
*** jschwarz has quit IRC17:04
openstackgerritJohn Belamaric proposed openstack/designate: Infoblox Backend  https://review.openstack.org/18310517:05
*** jordanP has quit IRC17:07
*** penick has joined #openstack-dns17:09
openstackgerritMerged openstack/python-designateclient: Log a more informative error upon EndpointNotFound  https://review.openstack.org/18475417:09
*** jschwarz_ has quit IRC17:33
*** HenryG has quit IRC17:42
*** HenryG has joined #openstack-dns17:46
rcarrillocruzKiall timsim: thx for the all_tenants merge :-)17:47
Kiallrcarrillocruz: will cut a release as soon as I can, need to talk to ttx first though as things have changed slightly this cycle with client releases17:48
KiallHe's EU somewhere, so likely gone for the day.. But, will grab him tomorrow.17:49
*** robert4man has quit IRC17:51
ryanpetrelloKiall: when you have some time, mind looking at https://review.openstack.org/#/c/185684/ ?17:57
ryanpetrelloI'm releasing a new pecan soon, and this will prevent it from breaking tests in stable/kilo17:58
ryanpetrello(it's a backport)17:58
Kiallryanpetrello: +2, straight backport that I remember well ;)17:58
ryanpetrellogreat, thanks!17:59
*** HenryG has quit IRC18:01
*** HenryG has joined #openstack-dns18:01
*** iraw_ has joined #openstack-dns18:05
*** iraw_ has quit IRC18:05
*** dguerri`away is now known as dguerri18:08
*** csoukup has joined #openstack-dns18:40
*** richm has quit IRC18:43
*** logan2 has joined #openstack-dns18:47
*** robert4man has joined #openstack-dns18:56
*** pglass has quit IRC19:04
*** pglass has joined #openstack-dns19:06
*** barra204 has joined #openstack-dns19:16
*** robert4man has quit IRC20:23
openstackgerritMerged openstack/designate: Infoblox Backend  https://review.openstack.org/18310520:33
*** pglass has quit IRC20:35
*** pglass has joined #openstack-dns20:35
*** EricGonc_ has quit IRC20:45
*** EricGonczer_ has joined #openstack-dns20:47
*** EricGonczer_ has quit IRC20:58
*** johnbelamaric has quit IRC21:00
*** EricGonczer_ has joined #openstack-dns21:03
*** HenryG has quit IRC21:04
*** HenryG has joined #openstack-dns21:07
*** EricGonczer_ has quit IRC21:11
*** busterswt has quit IRC22:10
*** EricGonczer_ has joined #openstack-dns22:25
*** pglass has quit IRC22:25
*** johnbelamaric has joined #openstack-dns22:47
*** ducttape_ has quit IRC22:52
*** csoukup has quit IRC22:56
*** dguerri is now known as dguerri`away22:57
*** johnbelamaric has quit IRC23:00
*** km has joined #openstack-dns23:04
*** pglass has joined #openstack-dns23:06
*** chlong has joined #openstack-dns23:09
*** chlong has quit IRC23:15
*** kei_yama has joined #openstack-dns23:18
*** mlavalle has quit IRC23:26
*** chlong has joined #openstack-dns23:44
*** johnbelamaric has joined #openstack-dns23:52
*** csoukup has joined #openstack-dns23:54
*** johnbelamaric has quit IRC23:58
*** ducttape_ has joined #openstack-dns23:58

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