| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-19 | |||
| 13:16:29 | aspiers | efried: personally I *never* tire of workflow improvements | |
| 13:16:39 | aspiers | you can always count me in for reviewing those | |
| 13:18:04 | efried | aspiers: what's mybranch^! ? | |
| 13:18:21 | aspiers | the commit at the tip of mybranch | |
| 13:18:31 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Exclude build request marker from server listing https://review.opendev.org/677201 | |
| 13:19:02 | aspiers | efried: https://git-scm.com/docs/git-rev-parse#_other_rev_parent_shorthand_notations | |
| 13:19:21 | stephenfin | Well it's not a workflow improvement, but this would save us some time https://review.opendev.org/#/c/470775/ | |
| 13:19:52 | stephenfin | (make mock fail if you call a mocked function incorrectly or a function that doesn't exist) | |
| 13:20:35 | stephenfin | and it's been around in one form or another for...2 years, 2 months and 17 days :'D | |
| 13:21:05 | efried | yeah, I thought claudiub had been working on this for ages and was never able to get it quiiite right. | |
| 13:21:09 | efried | is it right now? | |
| 13:21:19 | efried | I guess you think so according to your +2 :) | |
| 13:21:48 | stephenfin | It all looks sane and I'm relying on CI to catch anything we might have missed | |
| 13:21:55 | stephenfin | so...yes. | |
| 13:22:47 | efried | aspiers: So foo^! is like foo~1..foo ? | |
| 13:24:59 | efried | I admit, I learned like two of the weird shorthands and then cordoned off the rest of my brain for other things. | |
| 13:25:13 | efried | 80/20 rule | |
| 13:27:01 | sean-k-mooney | woudl foo~1..foo not be git show | |
| 13:27:16 | sean-k-mooney | e.g. compare ing n-1 to n | |
| 13:27:41 | sean-k-mooney | which is the diff of n or what git show displays | |
| 13:27:48 | efried | if you're using it for a diff, yes | |
| 13:27:55 | sean-k-mooney | ok | |
| 13:28:01 | sean-k-mooney | just makeing sure | |
| 13:28:55 | sean-k-mooney | the ~1 thing always confused me | |
| 13:29:15 | sean-k-mooney | i only ever use it if im doing "git reset --hard HEAD~1" | |
| 13:29:37 | sean-k-mooney | to remove the top commit form my branch when i commit to master by mistake | |
| 13:33:34 | efried | when I commit to master by mistake, I do something like: | |
| 13:33:34 | efried | git branch -m oops | |
| 13:33:34 | efried | git checkout -b master origin/master | |
| 13:35:54 | stephenfin | Somewhat related https://github.blog/2019-08-16-highlights-from-git-2-23/ | |
| 13:36:40 | stephenfin | (git 2.23 adds experimental 'git restore' and 'git switch' commands that each do a bit of what 'git checkout' is doing currently) | |
| 13:47:03 | mriedem | gibi: answered your question about multi-cell migration reschedule https://review.opendev.org/#/c/635668/41 | |
| 13:47:23 | yonglihe | stephenfin: Thanks, its stressful. | |
| 13:47:23 | mriedem | gibi: tl;dr yes it's a todo, i just didn't do it yet since i wanted to get the main flow written, tested and reviewed first | |
| 13:52:45 | gregwork | what kind of access does a tenant need to create private flavors within their tenant | |
| 13:54:50 | gregwork | getting ERROR: You are not authorized to use resource_types: OS::Nova::Flavor when deploying a stack in this tenant as _member_... I also get this error as ResellerAdmin and Creator | |
| 13:55:30 | gregwork | the "admin" role appears to transform the tenant into a cloud operator able to see and modify all other tenants so this is not useful | |
| 14:03:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits from privsep series https://review.opendev.org/677210 | |
| 14:03:35 | stephenfin | efried: ^ | |
| 14:05:17 | efried | ack | |
| 14:17:02 | mriedem | gibi: now that there has been more review on the cross-cell-resize series, i'm thinking about moving https://review.opendev.org/#/c/642590/ and https://review.opendev.org/#/c/642183/ and https://review.opendev.org/#/c/637605/ to the front of the series to get those merged out of the way (next time i do a rebase) - any problems with that? | |
| 14:20:10 | mriedem | dansmith: this is a pretty simple +2d bottom of the cross-cell series which is the prep_resize equivalent and would help move a few things https://review.opendev.org/#/c/633293/ - it's basically just a call to the dest compute to do a resize_claim for pci/numa and send back the migration context | |
| 14:25:29 | dansmith | mriedem: okay | |
| 14:26:52 | dansmith | mriedem: is this not something we should be doing all the time to make numa lm easier? | |
| 14:27:02 | dansmith | because they're kinda stuffing the claim into other calls right now | |
| 14:28:27 | mriedem | meaning the numa lm series is doing the move claim as part of pre_live_migrate_at_dest or whatever, right? | |
| 14:28:36 | dansmith | yeah, | |
| 14:28:37 | mriedem | and same-cell resize/cold migrate does it in prep_resize | |
| 14:29:13 | dansmith | I had just read the commit message when I said ^ but it struck an immediate chord with me | |
| 14:29:20 | dansmith | that we're going to have three ways for the three types, AFAICT | |
| 14:30:17 | mriedem | i would need to refresh on the live migration claim to know if it's needing to use migrate data from the source or anything | |
| 14:30:30 | dansmith | it does | |
| 14:30:36 | efried | aspiers: Didn't you write a mock_open wrapper? | |
| 14:30:43 | aspiers | I did | |
| 14:30:53 | aspiers | patch_open and patch_exists | |
| 14:30:53 | mriedem | prep_resize for same-cell is quite a bit different from the cross-cell one since it's a cast, does reschedule logic, and then casts to the resize_instance method on the source | |
| 14:31:04 | mriedem | so i'm not sure that trying to munge those into a single method to work for all is going to be better | |
| 14:31:11 | mriedem | feels like the rebuild/evacuate trap to me | |
| 14:31:20 | aspiers | efried: and yes, foo^! is foo^..foo | |
| 14:31:24 | sean-k-mooney | aspiers: how do you determin all test that need to be run for a change | |
| 14:31:26 | efried | aspiers: found it | |
| 14:31:44 | sean-k-mooney | reliable that is | |
| 14:31:51 | efried | sean-k-mooney: he's not mapping source changes to tests. | |
| 14:31:57 | aspiers | sean-k-mooney: I don't yet, but you would need to hardcode those mappings | |
| 14:32:01 | efried | sean-k-mooney: he's just running test files you changed in the commits | |
| 14:32:11 | aspiers | which is exactly what you can do with a Guardfile | |
| 14:32:25 | mriedem | efried: so no tests no failures yay! | |
| 14:32:31 | sean-k-mooney | ok that | |
| 14:32:51 | efried | aspiers: I was thinking you could get partway by mapping nova/a/b/c.py to nova/tests/{unit|functional}/a/b/test_c.py | |
| 14:32:51 | aspiers | hell, that's the kind of thing people used to do with Makefiles, in the olden days before actually useful dependency trees went out of fashion and all the modern bullshit came in | |
| 14:32:52 | sean-k-mooney | will likely miss relevent tests then | |
| 14:32:58 | efried | and then hardcode anything that doesn't hit with that. | |
| 14:33:01 | aspiers | efried: yes for sure | |
| 14:33:31 | mriedem | efried: note that lots of the modules aren't 1:1 like that | |
| 14:33:35 | sean-k-mooney | i really dont like the idea of hardcoding any mappings | |
| 14:33:50 | efried | mriedem: Yes, I get that, I'm saying that would get you a big chunk for free, and then you hardcode the rest. | |
| 14:33:57 | mriedem | gross | |
| 14:34:00 | efried | but that's not the point of this patch at all. | |
| 14:34:13 | mriedem | it's just auto-run the test module changes in my commit, i know | |
| 14:34:13 | efried | this patch just runs "tests I changed in XXX commit(s)" | |
| 14:34:29 | aspiers | sean-k-mooney: the entire CI test suite is "relevant" in a sense. The point of locally rapidly running a small subset of tests every time you make a local code change is not to be complete, it's to catch the 80% of stupid mistakes and make sure the tests you *are* changing on are correct | |
| 14:34:49 | mriedem | this is proposed as totally optional yes? | |
| 14:34:53 | mriedem | meaning i never have to deal with this? | |
| 14:34:58 | aspiers | yes | |
| 14:35:10 | sean-k-mooney | ya i get that but generally i jsut use the regex support for that | |
| 14:35:20 | mriedem | same, | |
| 14:35:26 | mriedem | tox -e py36 -- test_compute | |
| 14:35:29 | aspiers | sean-k-mooney: but then you have to maintain lists of regexes. the point is to save you the hassle for quick obvious stuff | |
| 14:35:35 | sean-k-mooney | e.g. tox -e py36 -- "libvirt|compute" | |
| 14:35:58 | sean-k-mooney | aspiers: no you just add words that relate to the thing your doing when you type it | |
| 14:36:00 | aspiers | right, except that will take like 20-30s longer because a) it goes through tox and b) it does test discovery | |
| 14:36:24 | sean-k-mooney | if i change ovo i add objecst if i modify the libvirt dirver i add libvirt | |
| 14:36:24 | aspiers | sean-k-mooney: sure but that's a different use case | |
| 14:36:48 | aspiers | I'm not proposing to replace any existing workflows, just add the option of a quick and easy extra one | |
| 14:36:55 | sean-k-mooney | right but if i want to run just one test it add teh test name or use an ide. | |
| 14:37:05 | aspiers | it's already saved me a bunch of typing this morning since I wrote it | |
| 14:37:19 | sean-k-mooney | anyway it nice to have a script for the new stuff | |
| 14:37:33 | sean-k-mooney | just i dont want it to imply that it will run all the relevent tests | |
| 14:39:46 | sean-k-mooney | aspiers: its good for saving time locally as long as it does not encurage people to waste gate time but not running the test they should have locally | |
| 14:40:00 | openstackgerrit | Adam Spiers proposed openstack/nova master: Switch some GitHub URLs to point to opendev.org https://review.opendev.org/677185 | |