| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-12 | |||
| 01:35:45 | alex_xu | zhanglong: migrate vtpm vm to another host | |
| 01:36:16 | alex_xu | zhanglong: live migrate | |
| 01:45:10 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 01:45:33 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | |
| 01:45:52 | openstackgerrit | Naichuan Sun proposed openstack/nova master: os-xenapi(n-rp): add traits for vgpu n-rp https://review.openstack.org/604269 | |
| 02:11:24 | zhanglong | alex_xu: OK. So to ensure [source Asymmetric key] only migrate to [trusted destination vTPM], it is requested that [destination vTPM] use AIK signed key. | |
| 02:12:46 | zhanglong | alex_xu: And there are several solutions to solve this issue.see paper <vTPM: Virtualizing the Trusted Platform Module>. | |
| 02:19:36 | alex_xu | zhanglong: are you saying we don't have enough support in kvm to support live migrate with vTPM? | |
| 02:22:30 | alex_xu | zhanglong: btw, i'm revewing this spec https://review.openstack.org/571111, try to figure out the live migration whether is the scope of that proposal | |
| 02:24:35 | zhanglong | alex_xu: KVM? vm is related to QEMU, not KVM. | |
| 02:27:37 | zhanglong | alex_xu: As I know , the process of [live migrate with vTPM] is related to vm manager e.g. nova, and can be decoupling with host. :) | |
| 02:28:17 | alex_xu | zhanglong: yea, sorry, i'm just saying the generic word, i say kvm is mean to all those stuff qemu, kvm. i know qemu is about device emulation, kvm is kernel module... | |
| 02:29:21 | zhanglong | alex_xu: mm :) | |
| 05:25:45 | openstackgerrit | Dao Cong Tien proposed openstack/nova master: Add note for sending SIGHUP at rolling upgrade steps https://review.openstack.org/609910 | |
| 05:45:33 | cfriesen | alex_xu: not sure if it's libvirt or qemu, but nova doesn't need to worry about it. | |
| 05:46:01 | alex_xu | cfriesen: cool, i got it | |
| 05:54:21 | openstackgerrit | Merged openstack/nova master: Add volume_type field to BlockDeviceMapping object https://review.openstack.org/604687 | |
| 05:54:32 | openstackgerrit | Merged openstack/nova master: Replace openSUSE experimental check with newer version https://review.openstack.org/609467 | |
| 05:54:41 | openstackgerrit | Merged openstack/nova master: Add compute version 36 to support ``volume_type`` https://review.openstack.org/579360 | |
| 05:56:49 | openstackgerrit | Merged openstack/nova master: Add compute API validation for when a volume_type is requested https://review.openstack.org/605573 | |
| 06:02:56 | openstackgerrit | Juan Antonio Osorio Robles proposed openstack/nova master: Remove dead code from policy module https://review.openstack.org/609591 | |
| 06:10:52 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add microversion 2.67 to support volume_type https://review.openstack.org/606398 | |
| 06:58:57 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add microversion 2.67 to support volume_type https://review.openstack.org/606398 | |
| 08:07:36 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Use tempest-pg-full https://review.openstack.org/609954 | |
| 08:29:38 | openstackgerrit | Tushar Patil proposed openstack/nova-specs master: Support filtering of allocation_candidates by forbidden aggregates https://review.openstack.org/609960 | |
| 08:43:52 | gmann | alex_xu: melwitt i feel we should restrict the null and empty string in volume_type which are going to be ignored on cinder side - https://review.openstack.org/#/c/606398/13 | |
| 09:18:14 | openstackgerrit | Juan Antonio Osorio Robles proposed openstack/nova master: Remove dead code from policy module https://review.openstack.org/609591 | |
| 10:10:06 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Change the default values of XXX_allocation_ratio https://review.openstack.org/602803 | |
| 10:10:07 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Add compute_node ratio online data migration https://review.openstack.org/609995 | |
| 10:10:07 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804 | |
| 10:25:02 | nehaalhat_ | sean-k-mooney: Hi | |
| 10:25:51 | sean-k-mooney | nehaalhat_: hi | |
| 10:25:54 | nehaalhat_ | sean-k-mooney: want to discuss regarding patch: https://review.openstack.org/#/c/581218/ | |
| 10:26:22 | sean-k-mooney | sure | |
| 10:28:56 | nehaalhat_ | sean-k-mooney: the log messages that are mentioned in commit message of above patch, are logged from keystoneauth but with logger name: 'novaclient.v.client'. As these logs are from keyatoneauth the logger name should be like 'keystoneauth.session'' | |
| 10:29:20 | nehaalhat_ | 'novaclient.v2.client' | |
| 10:33:13 | sean-k-mooney | ok | |
| 10:33:37 | nehaalhat_ | sean-k-mooney: I have tried your suggestion that: set default_log_levels=novaclient=DEBUG in cinder.conf and then checked logs, but the logs related to nova are getting logged using 'novaclient.v2.client' logger name only. | |
| 10:34:43 | sean-k-mooney | right they should have novaclient.v2.client name | |
| 10:35:49 | sean-k-mooney | were are the keyston auth logs your are trying to suppress being generagted | |
| 10:36:07 | sean-k-mooney | they should only have the keystoneauth.session logger name if they are being logged in teh libary | |
| 10:36:37 | sean-k-mooney | if the log function is called in the nova client code they should be novaclient.v2.client | |
| 10:39:49 | nehaalhat_ | sean-k-mooney: yes the logger is initialized in novaclient only, so it is taking name as 'novaclient.v2.client'. You can refer this logs: http://paste.openstack.org/show/731959/ that i am getting for cinder to novaclient interaction | |
| 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 | nehaalhat_ | sean-k-mooney: ok | |
| 11:04:34 | sean-k-mooney | nehaalhat_: the other option you have is to creat a new logger and pass it in | |
| 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 | |