| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 17:40:09 | sean-k-mooney | no that i have moved my dns to cloudflare most of my issue with updating dns are fixed | |
| 17:40:22 | sean-k-mooney | godda's ui/api was horrible | |
| 17:44:28 | sean-k-mooney | by the way aparet form the backportable solution stephenfin are we also going to add an fqdn or domain field and a new microverion to the server create | |
| 23:11:00 | openstackgerrit | Mamduh proposed openstack/os-vif stable/ussuri: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765419 | |
| #openstack-nova - 2020-12-04 | |||
| 00:44:59 | openstackgerrit | melanie witt proposed openstack/nova master: Omit resource inventories from placement update if zero https://review.opendev.org/c/openstack/nova/+/759348 | |
| 01:33:16 | brinzhang | gmann: hi, I saw your comments in https://review.opendev.org/c/openstack/nova/+/765315/1 | |
| 01:33:33 | brinzhang | gmann: I think this change is ok, right? | |
| 01:34:25 | brinzhang | of course, I will update your comments, and adding the needed test cases | |
| 01:46:48 | gmann | brinzhang: +1. also we can do all the policy changes in one patch i added other policy also where changes are required | |
| 01:48:28 | gmann | brinzhang: also if you can squash these two 764292 and 765311. having one patch per API will be good and less error prone to review instead of separate patches for request and response change | |
| 01:49:51 | gmann | brinzhang: and on microversion number, stephenfin hypervisor API changes are mre close to merge for 2.88 - https://review.opendev.org/c/openstack/nova/+/764040 | |
| 01:50:18 | brinzhang | gmann: I have already serepate 764292 and 765311, I wonot waste time to merge, the policy changes I just see this api now, if I changes other api that need to be change the policies, I will be add in this patch | |
| 01:50:31 | gmann | brinzhang: if you can use 2.89 then it will be less work for you on rebase things because stephenfin changes are more likely yo be merge before tenant-id one | |
| 01:51:05 | gmann | brinzhang: i mean do these into single one - 764292 and 765311 | |
| 01:51:32 | gmann | otherwise it is hard to review what all things you are taking care or missed unless we check other patches too. | |
| 01:51:51 | brinzhang | gmann: I also would like merge noVNC feature before remove tenant_id, this patch seems too big | |
| 01:52:12 | gmann | this happened to me when I reviewed 764292 and gave comment on missing request body change and then found it is done separately | |
| 01:52:41 | gmann | brinzhang: +1 then you can do 2.90 for tenand-id. i can review noVNC also once you are ready | |
| 01:53:09 | brinzhang | gmann: noVNC patch is ready now, and I added in the runway, you can review | |
| 01:53:14 | gmann | tenand-id changes are huge and we need to carefully review those to avoid regressions as it involve lot of request/responsechanges | |
| 01:53:19 | gmann | brinzhang: cool | |
| 01:53:25 | gmann | brinzhang: will do tomorrow | |
| 01:54:21 | brinzhang | gmann:764292 and 765311 these are two things, 764292 do remove tenant_id and add project_id, 765311 just replace all_projects with all_tenants, it's easy to review | |
| 01:54:58 | brinzhang | gmann: I am appreciate you can review the noVNC patch, thanks | |
| 01:56:17 | gmann | brinzhang: its for one API GET /servers. my point is to divide the changes of 'remove/replace tenant->project' per API. if we do per parameter then it will be very long series and chance to miss the things unless we check all the changes and find all things covered for that API | |
| 01:58:19 | brinzhang | gmann: yeah, if I have time to combine these that I can | |
| 01:58:29 | gmann | brinzhang: thanks. | |
| 01:59:25 | brinzhang | gmann: indeed, I do my plan in my mindmaster, I dont want to break my plan | |
| 01:59:34 | brinzhang | s/do/did | |
| 02:23:32 | brinzhang | gmann: the lock server reason is not required? | |
| 02:23:34 | brinzhang | ['locked', 'locked_reason'] | |
| 02:23:34 | brinzhang | Extra key(s) in Response: | |
| 02:23:34 | brinzhang | [] | |
| 02:23:34 | brinzhang | Extra key(s) in template: | |
| 02:23:34 | brinzhang | nova.tests.functional.api_samples_test_base.NoMatch: Dictionary key mismatch: | |
| 02:24:40 | brinzhang | Why the functional test already needed the locked action? I inheritanced ServersSampleJsonTest | |
| 02:30:03 | gmann | brinzhang: that is for response of GET /servers so you need to add those in sample file of GET servers | |
| 02:32:12 | gmann | we should not need lock API sample unless we call lock action API from test | |
| 02:47:45 | brinzhang | gmann: as your said just add the class, dont need to re-write test cases, but why it has required lock response? | |
| 02:47:46 | brinzhang | https://review.opendev.org/c/openstack/nova/+/764292/5/nova/tests/functional/api_sample_tests/test_servers.py@662 | |
| 02:48:24 | brinzhang | I am sure I dont request the lock action | |
| 08:34:18 | bauzas | gibi: fwiw, I'm about to +1 https://review.opendev.org/c/openstack/releases/+/764703 | |
| 08:34:31 | bauzas | any concerns ? | |
| 08:36:05 | gibi | bauzas: hehe, I just finished reading the change on those and wanted to ping sean-k-mooney about it | |
| 08:36:40 | gibi | bauzas: I don't have any problem with that os-vif release btw | |
| 08:37:37 | gibi | and I don't see any critical thing in flight for os-vif | |
| 08:37:41 | gibi | https://review.opendev.org/q/project:openstack/os-vif+status:open+branch:master | |
| 08:37:48 | gibi | bauzas: so I'm also +1 | |
| 08:38:04 | gibi | sean-k-mooney: if you have anything against the os-vif release then let us know | |
| 09:10:51 | bauzas | gibi: whoops, sorry had a laptop crash | |
| 09:11:38 | bauzas | gibi: iirc, sean-k-mooney is on PTO today (and stephenfin too) | |
| 09:12:35 | bauzas | (and if s/o knows how to stop having a screen flickering, lemme know...) | |
| 09:13:03 | gibi | bauzas: ohh, then let's not wait for sean-k-mooney | |
| 09:20:42 | bauzas | gibi: mmm, my bad, can only see stephenfin's PTO today on our team calendar so sean-k-mooney should be around | |
| 09:21:02 | gibi | if you mean screen tearing then I had problem with kernel 5.9 on my thinkpad T480 so I went back to 5.8 | |
| 09:22:03 | bauzas | gibi: nope, screen flickering, ie. going on for 1 second and then turning black | |
| 09:22:16 | bauzas | and after 2 seconds, cycling over it | |
| 09:22:32 | bauzas | i had this after upgrading to F33 | |
| 09:22:41 | bauzas | so maybe this is a kernel issue indeed | |
| 09:22:54 | bauzas | (T470s here) | |
| 09:23:20 | bauzas | (and kernel 5.9.x indeed) | |
| 09:26:05 | bauzas | haha, dmesg is telling me something ! | |
| 09:36:20 | kashyap | bauzas: I'm also still on T470s, with F33 | |
| 09:36:41 | bauzas | looks like the new kernel introduced a few race conditions | |
| 09:37:02 | bauzas | [ 1137.076863] [drm:drm_dp_mst_dpcd_read [drm_kms_helper]] *ERROR* mstb 00000000a9d93826 port 3: DPCD read on addr 0x4b0 for 1 bytes NAKed | |
| 09:37:32 | kashyap | bauzas: What I notice is ... sometimes my 'mutt' window gets pixelated, I have to refresh (by doing Alt-F10 twice) to re-render it cleanly | |
| 09:38:21 | bauzas | I just feel this is related to power saving management | |
| 09:38:34 | bauzas | that's... annoying at most | |
| 09:39:12 | gibi | :/ | |
| 09:39:23 | bauzas | I found a BZ but with closed/worksforme :( | |
| 09:39:31 | bauzas | https://bugzilla.redhat.com/show_bug.cgi?id=1874782 | |
| 09:39:32 | openstack | bugzilla.redhat.com bug 1874782 in kernel "Fails to resume external monitor" [High,Closed: worksforme] - Assigned to kernel-maint | |
| 09:40:14 | bauzas | anyway, moving on | |
| 11:37:47 | sean-k-mooney | bauzas: actully not really i was helping emma drop her car to the garage and i need to driver her back later so im here today but i need to step away form the keyboard once or twice during the day | |
| 11:38:52 | sean-k-mooney | bauzas: gibi but ya there is nothing urgent in os-vif | |
| 11:40:52 | sean-k-mooney | so a realse is fine but its also not technically needed | |
| 11:41:44 | sean-k-mooney | os-vif is release-model: cycle-with-intermediary | |
| 11:42:11 | sean-k-mooney | that does not need a release at every milestone but it also does not hurt | |
| 11:42:38 | sean-k-mooney | i have been thinking of moving it to release-model: independent recently | |
| 11:43:17 | sean-k-mooney | cycle-with-intermediary allow us to do release when ever we want to anyway it just require at least one intermediary before the final release | |
| 11:52:12 | gibi | sean-k-mooney: ack. | |
| 11:53:47 | sean-k-mooney | oslo recently moved many of there libs to independent https://github.com/openstack/releases/blob/3409c68da0d1ea03296d62f4afd08f93d95097bc/doc/source/reference/release_models.rst#openstack-related-libraries | |
| 11:54:01 | gibi | sean-k-mooney: here Herve says that libs needs a release per milestone http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019080.html | |
| 11:54:26 | sean-k-mooney | that not documented and i have condened that is an incorrect interpertation | |
| 11:55:04 | sean-k-mooney | https://github.com/openstack/releases/blob/3409c68da0d1ea03296d62f4afd08f93d95097bc/doc/source/reference/release_models.rst#cycle-with-intermediary | |
| 11:55:11 | sean-k-mooney | is offially what the requirements are | |
| 11:58:09 | sean-k-mooney | its no like the relases are that much work anyway so it does not bother me to relase a little more often but we really have only have had one usefully fix since 2.2 https://github.com/openstack/os-vif/compare/2.2.0...2.3.0 | |
| 11:58:21 | sean-k-mooney | which is https://github.com/openstack/os-vif/commit/b37de19c58c877f5174d76d0a4ba5ab519f464e8 | |
| 11:59:24 | gibi | OK | |
| 13:34:46 | Dan6697 | Hi, Could someone tell me where to find the specifications for development? By specification I mean the high-level rules/requirements about how the system should behave | |
| 13:35:17 | bauzas | Dan6697: sorry, what do you mean about the Nova behaviour ? | |
| 13:35:39 | bauzas | for being a contributor ? | |
| 13:35:55 | Dan6697 | Like what's the correct behavior when it interact with other components such as keystone | |
| 13:36:34 | sean-k-mooney | there isnt a highlevel documetn for the interservice interaction | |
| 13:36:58 | sean-k-mooney | in most porjects we require spec to descibe api behavior when feature are being developed | |
| 13:37:24 | Dan6697 | I know there's spec but that seems to be like a proposal | |
| 13:37:27 | sean-k-mooney | those behviors in theory then get documented in the api ref for each service | |
| 13:38:03 | sean-k-mooney | Dan6697: yes spcs are propsosals for how a feature should function | |
| 13:39:14 | Dan6697 | Do you know 3GPP specification in telecommunication? That's more or less what I want | |
| 13:39:30 | sean-k-mooney | yes we are aware of them and we do not implement them | |