| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-12 | |||
| 10:40:52 | nehaalhat_ | sean-k-mooney: In the logs you can see the logs are getting logged in keystoneauth library | |
| 10:41:13 | nehaalhat_ | but with logger name 'novaclient.v2.client' | |
| 10:42:33 | sean-k-mooney | do you know where in novaclient it is calling log.debug | |
| 10:43:22 | nehaalhat_ | sean-k-mooney: No | |
| 10:51:40 | sean-k-mooney | nehaalhat_: it looks like they are bing logged in the keystone auth lib but that means its not internally creating its own logger | |
| 10:52:31 | nehaalhat_ | sean-k-mooney: yes it is being logged in keystoneauth lib | |
| 10:53:53 | sean-k-mooney | nehaalhat_: i think you should be making you change here instead https://github.com/openstack/python-novaclient/blob/003ac57d9af74aa4658a7bf6cc6b6b3bafa58c11/novaclient/client.py#L167 | |
| 10:54:18 | nehaalhat_ | sean-k-mooney: But identity related logs are logged using logger name 'keystoneauth.session' and the are also logged in 'keystone auth' lob | |
| 10:54:48 | sean-k-mooney | actully that is the only place the logger is used in that function. | |
| 10:58:44 | nehaalhat_ | sean-k-mooney: you are suggesting to make changes here: https://github.com/openstack/python-novaclient/blob/003ac57d9af74aa4658a7bf6cc6b6b3bafa58c11/novaclient/client.py#L167 right? | |
| 11:02:32 | sean-k-mooney | i was but looking at how the code works and the keystonauth adapter.py the client is working differntely then i had taught | |
| 11:02:53 | sean-k-mooney | i think you can leave you chage as it is | |
| 11:03:11 | nehaalhat_ | sean-k-mooney: ok..thanks | |
| 11:03:47 | sean-k-mooney | that said i think the api for the keystone auth adapter is incorerct. im not sure it should allow passing a logger at all | |
| 11:04:34 | sean-k-mooney | nehaalhat_: the other option you have is to creat a new logger and pass it in | |
| 11:04:34 | nehaalhat_ | sean-k-mooney: ok | |
| 11:05:06 | sean-k-mooney | so you could create a novaclient.v2.client.auth logger and pass that in | |
| 11:05:25 | sean-k-mooney | then people could use the python loging filtering to choose to filter it out or not | |
| 11:07:32 | nehaalhat_ | sean-k-mooney: ok will check | |
| 11:08:33 | sean-k-mooney | coool you would then set novaclient.v2.client.auth to info in cinder to not log the debug logs form the keystone auth adapter | |
| 11:11:42 | nehaalhat_ | sean-k-mooney: what if i want logs related to debug | |
| 11:12:49 | sean-k-mooney | novaclient.v2.client.auth would only be the kestoneauth logs your are currently uncondtionally removing | |
| 11:13:24 | sean-k-mooney | so if you have novaclient.v2.client at debug setting novaclient.v2.client.auth to info will only filter out the auth debug logs | |
| 11:14:28 | sean-k-mooney | the keystone auth adapter does not fall back to its own logging if you don tpass a logger in http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/adapter.py#n129 | |
| 11:58:37 | sean-k-mooney | are the wsgi script for placement generated the same way we generate the the nova-compute etc command scripts using setuptool entrypoints? | |
| 12:00:13 | sean-k-mooney | specifcally https://github.com/openstack/nova/blob/master/setup.cfg#L78 gets processed by setuptools to generate /var/www/cgi-bin/nova/nova-placement-api ? | |
| 12:01:54 | sean-k-mooney | ah they are generated by pbr | |
| 12:04:31 | jaosorior | sean-k-mooney: hey, if you have some time, can you check the review from yesterday https://review.openstack.org/#/c/609591/ ? | |
| 12:45:52 | leakypipes | mordred: Monty, would you be a dear and review https://review.openstack.org/#/c/581218/ please? Both mriedem and myself are kinda lost as to what is going on there and need your feedback on the impact this would have in SDKs. | |
| 12:46:56 | leakypipes | aspiers: BTW, it may be a little while until I can review https://review.openstack.org/#/c/609779/1/specs/stein/approved/amd-sev-libvirt-support.rst... it's cause me to open a number of new browser tabs as I read about that technology. :) | |
| 12:47:40 | leakypipes | aspiers: something that negatively affected my goal for yesterday. shame on you. (https://twitter.com/jaypipes/status/1050394398163443713) :P | |
| 12:48:04 | aspiers | leakypipes: no problem :) although if it's any consolation, I know very little about it myself, but I don't think a deep understanding is really necessary anyway ... | |
| 12:48:17 | aspiers | haha :) | |
| 12:50:41 | aspiers | there are browser extensions for that, you know | |
| 12:51:50 | aspiers | although depressingly the one I use has just vanished from my Chrome :-/ | |
| 12:51:53 | leakypipes | aspiers: well, I actually *do* want to read (or take other action on) all those tabs... just takes a while! :) | |
| 12:52:16 | leakypipes | aspiers: just takes some good ol' fashioned time to do it | |
| 12:52:18 | aspiers | ah well, then you need a way to move them onto a todo list | |
| 12:52:45 | aspiers | https://getpocket.com/ is pretty handy, but then so is a text file full of URLs | |
| 12:53:13 | aspiers | or if you want nicer hyperlinks, try this https://github.com/aspiers/desktop-config/blob/master/lib/browser/userscripts/page-id-helpers/README.md | |
| 12:58:31 | leakypipes | aspiers: rock on brother. (though you just added yet another tab to my browser, damn you Adam!) | |
| 12:59:00 | aspiers | X-p | |
| 12:59:16 | leakypipes | aspiers: btw, just curious, is SUSE planning on deploying an AMD-based cloud? or do you have customers that want to use EPYCs instead of Xeons? | |
| 13:00:12 | aspiers | I'm guessing it's for customers eventually but I don't really have a clue - not involved in the business discussions thank goodness :) | |
| 13:00:34 | aspiers | our partnership with AMD goes way back | |
| 13:00:38 | leakypipes | ack | |
| 13:00:51 | aspiers | IIRC we were the first enterprise Linux to support AMD, or something like that | |
| 13:01:08 | aspiers | mind you, we're obviously very close with Intel too | |
| 13:01:25 | leakypipes | gotcha | |
| 13:04:21 | mriedem | well, i guess we have to decide if the volume_type support when creating a server should be the same as cinder's volume create api https://review.openstack.org/#/c/606398/ and allow passing volume_type='' or volume_type=None, or restrict that in the compute API | |
| 13:04:30 | mriedem | so that if you pass a volume_type, it has to be non-null and minLength: 1 | |
| 13:05:10 | mriedem | i'm personally fine keeping parity with cinder's API since people really just want the proxy here | |
| 13:07:41 | leakypipes | mriedem: how about --volume-type=force:True? That would mesh well with our long tradition of force APIs. | |
| 13:08:04 | leakypipes | mriedem: you could even add a --volume-type=force:None to make things super clear. | |
| 13:08:13 | mriedem | i would like it to pass it over flavor extra spec myself, | |
| 13:08:16 | mriedem | but we don't all get what we want | |
| 13:08:39 | leakypipes | mriedem: scheduler hint for volume type --hint force-volume-type=None | |
| 13:08:42 | mriedem | or encoded scheduler hitn | |
| 13:08:43 | mriedem | *hint | |
| 13:08:46 | mriedem | yes | |
| 13:08:48 | leakypipes | mriedem: beat you to it. | |
| 13:10:54 | giblet | :) | |
| 13:13:43 | mordred | leakypipes: looking | |
| 13:16:21 | leakypipes | mordred: thanks man. it was mriedem who also wanted your opinion on that, which I concurred with. | |
| 13:16:56 | mordred | leakypipes: I believe the patch looks fine - and I'm happy to see people are excited about the split-loggers option :) | |
| 13:18:25 | mriedem | ? https://review.openstack.org/#/c/581218/ ? | |
| 13:20:40 | leakypipes | mordred: what about sean-k-mooney's first comment here? https://review.openstack.org/#/c/581218/5/novaclient/v2/client.py | |
| 13:20:47 | leakypipes | mordred: is that a concern? | |
| 13:21:20 | mriedem | jackding: you know your reboot/rebuild check the network for unbound ports patch? | |
| 13:21:23 | leakypipes | mriedem: yes, that one. you had commented on there: "-1 for the missing lower-constraints bump, but I'd also like to see Monty +1 this before we merge it since I'm not really following all of this." | |
| 13:21:30 | mriedem | that's checking the ports right after we refreshed them from neutron, | |
| 13:21:35 | mriedem | can we avoid the list_ports in your check method? | |
| 13:21:39 | mriedem | and just use the instance.info_cache? | |
| 13:21:44 | mriedem | that would help some of my concern | |
| 13:21:55 | mriedem | leakypipes: yar | |
| 13:22:05 | mriedem | if you want split logs, pass a scheduler hint | |
| 13:22:07 | leakypipes | mriedem: aye, matey. | |
| 13:22:19 | leakypipes | mriedem: lol. thx moleman. | |
| 13:22:34 | leakypipes | there he is! | |
| 13:23:12 | hansmoleman | https://deadhomersociety.files.wordpress.com/2016/11/thisisaknife.gif?w=655 | |
| 13:24:27 | hansmoleman | gmann: do you have a patch to cap max microversions for tempest in devstack for rocky yet? | |
| 13:25:30 | hansmoleman | nope, i'll do that | |
| 13:30:17 | openstackgerrit | sean mooney proposed openstack/nova master: harden placement init under wsgi https://review.openstack.org/610034 | |
| 13:33:35 | sean-k-mooney | ^ that may be dumb but its my attempt to fix part of a downstream bug in triplo that i dont have an enviornment to reproduce and or time to reporduce. | |
| 13:34:01 | hansmoleman | comments inline | |
| 13:34:09 | hansmoleman | efried: what's the process now for placement bug fixes? | |
| 13:34:15 | hansmoleman | fix in nova and cherry pick to placement or vice versa? | |
| 13:35:39 | sean-k-mooney | oh right placement is moving... | |
| 13:39:29 | mordred | leakypipes, hansmoleman: +1 left - I agree with sean-k-mooney's followup comment | |
| 13:40:56 | PapaOurs | hansmoleman: AFAIUC, we need two changes | |
| 13:41:11 | PapaOurs | hansmoleman: and just waiting for the placement one to be merged before merging the nova one | |
| 13:41:16 | PapaOurs | but not Depends-On | |
| 13:42:00 | finucannot | hansmoleman: What would it cost me to get you to look at https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens+topic:bug/1746393 again? | |
| 13:42:30 | finucannot | hansmoleman: It's not something I'm going to be able to test with the Intel NFV CI but I did manually verify it | |
| 13:45:23 | PapaOurs | does someone remember the link for querying all the OpenStack project repos ? | |
| 13:46:17 | hansmoleman | codesearch.openstack.org | |
| 13:46:57 | PapaOurs | hansmoleman: <3 | |
| 13:47:24 | hansmoleman | finucannot: how far back to plan on trying to get those backports? has that code just always been broken? | |
| 13:47:33 | hansmoleman | that stack seems extremely risky to me | |
| 13:47:40 | hansmoleman | especially when we have 0 CI | |