Earlier  
Posted Nick Remark
#openstack-nova - 2020-09-22
11:26:19 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Add regression tests for bug #1889108 https://review.opendev.org/749232
11:26:20 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: compute: Don't delete the original attachment during pre LM rollback https://review.opendev.org/749233
11:26:43 lyarwood elod: https://review.opendev.org/#/c/752641/ sorry
11:26:54 lyarwood elod: I can respin the commit to point to that if you'd like
11:27:17 lyarwood CeeMac: nova-compute would be the most useful yes
11:27:31 elod lyarwood: no need for that, I just haven't found that :)
11:56:49 CeeMac lyarwood: where would libvirtd log to by default?
11:57:28 sean-k-mooney /var/log/libivrt
11:57:39 sean-k-mooney unless you are using ooo
11:58:19 sean-k-mooney in which case they are in /var/log/containers/nova/nova_libvirt or something like that
11:59:04 CeeMac using osa, will check
12:00:07 CeeMac ok, folder is there, which logs in particular? qemu presumably?
12:00:19 CeeMac I have libxl, lxc, qemu and uml folders
12:00:22 lyarwood CeeMac: libvirtd if you have it
12:00:30 lyarwood CeeMac: but it might not be enabled by OSA by default
12:00:45 lyarwood CeeMac: libvirtd.log that is
12:00:57 CeeMac lyarwood: can't see that one
12:01:15 CeeMac i found some things in nova-compute though
12:01:22 CeeMac i'll pull a bug together
12:01:56 CeeMac is it ok to paste the errors directly in the bug, or you'd prefer a paste url?
12:02:16 CeeMac hmm, 100 or so lines, maybe paste url for readability
12:03:03 lyarwood yeah pastebins are easier to read
12:03:13 sean-k-mooney you can put it at the end of the bug but paste it better
12:03:13 lyarwood launchpad-- comments are pretty awful
12:03:29 sean-k-mooney lyarwood: you have used bugzilla right :P
12:03:39 CeeMac no worries, i'll do a paste url :)
12:03:39 sean-k-mooney at least launchpad comments dont have conflicts
12:03:56 sean-k-mooney for that alone i forgive much
12:15:28 lyarwood sean-k-mooney: yeah rhbz has many faults but the comments are readable and editable now :)
12:18:03 sean-k-mooney really even comment 0
12:19:45 lyarwood sean-k-mooney: yeah even c#0, landed in the recent upgrade
12:20:11 sean-k-mooney well that is progress at least
12:28:07 brinzhang0 hi all, compared to appclient what benefits the introduction of openstacksdk can bring us?
12:28:47 brinzhang0 I saw we introduced it, but not used it, if I am not missing some key message
12:29:28 sean-k-mooney the sdk would be replacing keystone auth client and then eventrully replcing the other service python clients
12:29:29 openstackgerrit Mamduh proposed openstack/os-vif master: Fix - os-vif fails to get the correct UpLink Representor https://review.opendev.org/745895
12:30:03 brinzhang0 benifit?
12:30:34 sean-k-mooney to not need to main tain project sepcicif clients and eventurlaly only have one python sdk with all features
12:30:50 sean-k-mooney eventually we will hopefully get rid of python-novaclint
12:31:00 sean-k-mooney but we need full parity in osc and sdk first
12:32:11 brinzhang0 yeah, now the sdk cannot support the cli, if we decrapted it, that how to use the command?
12:32:11 sean-k-mooney the sdk also papers over some of the interoperablity issue between clouds
12:32:46 sean-k-mooney osc can use the sdk if it wants too
12:33:03 sean-k-mooney but osc should replace all uses of nova cli eventually
12:33:42 sean-k-mooney i wanted to freeze all addtions to nova cli last cycle and require new feature to be added only to osc but others disagreed
12:34:07 brinzhang0 yeah, I remembered gibi said, there is still a big gap between osc and novaclient
12:34:29 sean-k-mooney yep i dont think we should be widening that by adding new feautres or comands to nova client
12:35:01 brinzhang0 sean-k-mooney: if we can required new feature and added the lack of feature to osc, I think it will be good start
12:35:41 brinzhang0 *interoperablity issue between clouds* can you give some example?
12:37:19 sean-k-mooney the sdk has 3 levels fo apis. 1 is a raw rest client that just handels auth, 1 is driect method for the indigivual apis and the final one is a high level api that abstrct the differnce between say the old glance image import and the new way using the correct one for the cloud its conneccting too
12:37:21 brinzhang0 Do we plan to replace the SDK? In W release or X release, or more further?
12:38:12 sean-k-mooney brinzhang0: another example is that the high level api provide a way to look up the ip you can ssh over taking into account floating ips and if the vm is directly connect to an external network
12:38:24 sean-k-mooney basically the functionality that shade provided
12:39:03 sean-k-mooney brinzhang0: replce the sdk? no adopt the SDK we should in thoery use it any time we need to call an new api in a different service
12:39:42 sean-k-mooney brinzhang0: for example we shoudl be interacting with cybrog via the sdk rahter then using a python-cyborgclient
12:40:06 sean-k-mooney im pretty sure we already do use the sdk to get a rest client and make direct rest call
12:40:22 sean-k-mooney if the sdk had cyborg supprot we would use that instead
12:41:04 brinzhang0 oh, that the sdk and novaclient will be all exist in Nova, it means we will maintain two tools
12:41:08 sean-k-mooney much of https://github.com/openstack/nova/blob/master/nova/accelerator/cyborg.py could live in the sdk
12:41:14 sean-k-mooney not all of it but much of it
12:41:36 sean-k-mooney brinzhang0: the sdk is a sperate repo
12:41:46 sean-k-mooney not part of nova
12:42:02 sean-k-mooney and novaclinet will eventually be deprecated and removed hopefully
12:42:22 sean-k-mooney just not in W or likely not in X either
12:42:25 brinzhang0 yeah, I know, but if we want to use sdk for the new api call, we need to deploy it, and add the api support in sdk
12:42:46 sean-k-mooney sure
12:43:46 brinzhang0 yes, now we interactiing with cyborg via cyborgclient
12:44:05 sean-k-mooney we do not use cyborgclient
12:44:27 sean-k-mooney and we should not
12:45:07 sean-k-mooney we use a raw rest client and make json queryies to the cyborg api
12:45:33 sean-k-mooney we have our own cyborg client https://github.com/openstack/nova/blob/master/nova/accelerator/cyborg.py#L81
12:45:48 sean-k-mooney but its not the python-cyborgclient
12:46:11 sean-k-mooney we never use https://opendev.org/openstack/python-cyborgclient
12:46:38 sean-k-mooney and likely never will in nova
12:47:08 brinzhang0 sean-k-mooney: oh sorry, when we complete the nova-cyborg interaction we havenot completed the python-cyborgclient, so we cannot use the python-cyborgclient in that time
12:47:28 sean-k-mooney right but we also would not use it
12:47:38 sean-k-mooney we had already started adopting the sdk
12:47:43 brinzhang0 yes
12:47:56 sean-k-mooney so we would not add a dep on a new project sepcific client
12:48:01 sean-k-mooney we would jsut use the sdk
12:48:03 brinzhang0 we can use sdk instead of python-cyborgclient in future
12:48:21 sean-k-mooney yep we aldready use the sdk in some places by the way
12:48:41 sean-k-mooney anything you see "from openstack" thats using the sdk
12:48:44 sean-k-mooney https://github.com/openstack/nova/search?q=%22from+openstack%22
12:49:15 sean-k-mooney or were we use get_sdk_adapter
12:49:36 sean-k-mooney that really shoudl be replacing all uses of the keystoneauth adapter eventually
12:50:36 brinzhang0 sean-k-mooney: thans, I will see it later :)
12:51:17 sean-k-mooney so far we are only using that for placement https://github.com/openstack/nova/blob/b1e34c594bc1b3a8c7c12e033e1e4576270e6be7/nova/scheduler/client/report.py#L231 and ironic https://github.com/openstack/nova/blob/99781d6fa96f7d776612bcd41c94f5b9a3724f3b/nova/virt/ironic/driver.py#L216
12:51:39 openstackgerrit Federico Ressi proposed openstack/nova master: Log stack trace when fails launching a defined domain https://review.opendev.org/750652
12:52:10 openstackgerrit Federico Ressi proposed openstack/nova master: Requires default python3-devel package on CentOS https://review.opendev.org/752073
12:53:21 brinzhang0 I think placement only using sdk interacting with nova, and ironic now used python-ironicclient and sdk in Nova
12:55:21 sean-k-mooney placment only used the sdk yes https://github.com/openstack/nova/commit/2a2379a63cab4414676882c068d25163874cf08e and i think ironic only uses it too https://github.com/openstack/nova/commit/0176390531aa7bba56a12960334be4de2dd409ef
12:56:10 sean-k-mooney ya the driver and client wrapper https://github.com/openstack/nova/blob/99781d6fa96f7d776612bcd41c94f5b9a3724f3b/nova/virt/ironic/client_wrapper.py do not import ironic client
12:57:55 brinzhang0 sean-k-mooney: yeah, from the code record *yes*, placement and ironic interacting with nova only use sdk
12:59:07 sean-k-mooney keep in mind that the openstack sdk and openstack client are not the same thing
12:59:36 sean-k-mooney then now are both develoep and maaged via the opesntack-sdks team but they were seperate projects
12:59:54 brinzhang0 yeah, got it
13:01:53 brinzhang0 sean-k-mooney: In ironic we also inint the client, maybe the ironicclient also available https://github.com/openstack/nova/blob/99781d6fa96f7d776612bcd41c94f5b9a3724f3b/nova/virt/ironic/driver.py#L202
13:02:32 sean-k-mooney that uses the sdk i think
13:02:49 sean-k-mooney that nova ironic wrapper

Earlier   Later