| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-12 | |||
| 17:12:04 | Sundar | sean-k-mooney: Ok, got it. Thanks. | |
| 17:12:55 | sean-k-mooney | im not 100% if you want to be in our out side of the if but you likely should be doing the clean up in that exeption handeling code https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L674-L699 | |
| 17:14:36 | melwitt | gmann: yeah, I agree it should be allowing everyone to see AZ list by default. I added a comment | |
| 17:15:34 | gmann | melwitt: ok. detail make sense to be admin-only as it has host info | |
| 17:15:44 | melwitt | gmann: right, agreed | |
| 17:16:03 | gmann | thanks. I will modify accordingly | |
| 17:29:49 | stephenfin | sean-k-mooney: You can only specify the number of instance CPUs via the flavor, right? | |
| 17:29:53 | stephenfin | i.e. not via the image | |
| 17:30:12 | sean-k-mooney | yes | |
| 17:32:46 | sean-k-mooney | technically you could do evial things with a cyborg device profile but if you put VCPU or PCPU int eh device profile your on your own | |
| 17:35:05 | sean-k-mooney | *evil | |
| 17:38:59 | sean-k-mooney | lyarwood: by the way did you want me to do anything with the backprots for the numa inplace rebuild patches | |
| 17:39:31 | sean-k-mooney | lyarwood: you pinged my earlier but i was not sure if you already fixt them up or if there was still stuff pending | |
| 17:39:53 | stephenfin | huaqiang: Reviewed https://review.opendev.org/#/c/668656/. You need to drop the image metadata option and avoid the need to mix placement'y syntax extra specs with legacy extra specs. Do that and I'm +2 | |
| 17:39:56 | stephenfin | sean-k-mooney, efried, alex_xu: ^ | |
| 17:40:24 | sean-k-mooney | what do you think about the need for the service bump | |
| 17:40:45 | sean-k-mooney | e.g. do you think we could use a compute capablity trait isntead | |
| 17:40:45 | stephenfin | vs. a capability? | |
| 17:40:49 | sean-k-mooney | ya | |
| 17:40:59 | sean-k-mooney | i would be fine with leaving that to impleenation to decied | |
| 17:41:04 | sean-k-mooney | but i think the trait would work | |
| 17:41:43 | sean-k-mooney | there may be another reason for the service version bump that i missed | |
| 17:41:55 | stephenfin | I used a capability for the PCPU work | |
| 17:42:01 | stephenfin | so yeah, I'd probably do the same again | |
| 17:42:35 | stephenfin | commit f329ee5a3b6 | |
| 17:42:43 | sean-k-mooney | using the capablity trait means we can support rolling upgrades too rather then requiring all nodes to be upgraded | |
| 17:43:10 | sean-k-mooney | just the contoler and the host it lands on will need to be ussuri | |
| 17:44:59 | stephenfin | Exactly | |
| 17:45:22 | sean-k-mooney | there is a usecase for keeping the image property by the way | |
| 17:45:32 | sean-k-mooney | we support setting the realtime mask in the image | |
| 17:45:44 | stephenfin | We do, but I think that's wrong | |
| 17:45:45 | sean-k-mooney | so for parity we could support the pinned cpus there too | |
| 17:45:49 | sean-k-mooney | why | |
| 17:45:54 | stephenfin | For the same reasons | |
| 17:46:07 | stephenfin | You boot an N core instance | |
| 17:46:11 | sean-k-mooney | the idea is the vnf vendor will package teh image and expres the requirements in the image properties | |
| 17:46:21 | stephenfin | Right, but they can't express the number of CPUs | |
| 17:46:29 | stephenfin | which is probably also required | |
| 17:46:43 | sean-k-mooney | well the can express a min numa of cpus in the image | |
| 17:47:06 | stephenfin | Via the topology stuff? | |
| 17:47:08 | sean-k-mooney | the same way they can express a min amount of ram or disk | |
| 17:47:10 | stephenfin | That's a bit of hack | |
| 17:47:17 | sean-k-mooney | no | |
| 17:47:23 | sean-k-mooney | one sec | |
| 17:47:27 | sean-k-mooney | medtadef time | |
| 17:47:55 | sean-k-mooney | actully im not sure this is even a metadef it migh be directly on the image | |
| 17:48:30 | stephenfin | Hmm, we do also have 'hw_numa_cpus' there | |
| 17:48:41 | stephenfin | That's wrong too, IMO :( | |
| 17:49:00 | stephenfin | I wonder if we should do this just to be compatible even if it's not a great design though | |
| 17:49:54 | stephenfin | We have a 'img_bittorrent' field on the 'ImageMetaProps' object. Good Lord | |
| 17:50:43 | sean-k-mooney | oh looks like it only has min disk and min ram | |
| 17:50:45 | sean-k-mooney | https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/image.html#image-create | |
| 17:50:59 | sean-k-mooney | stephenfin: its by design | |
| 17:51:12 | sean-k-mooney | again the intent was to allow the image to descibr the toplogy | |
| 17:51:20 | sean-k-mooney | and the flavor to describe the quantity | |
| 17:51:45 | stephenfin | sean-k-mooney: But remember, that's a not a simple list | |
| 17:51:58 | stephenfin | or actually, maybe it is for the image metadata | |
| 17:52:45 | stephenfin | what happens if you create an N node instance that lists M CPUs in the 'hw_numa_cpus' image metadata option? | |
| 17:52:50 | sean-k-mooney | stephenfin: i agree that we should not mix it with the resouces:* syntax | |
| 17:53:28 | stephenfin | yeah, I really don't think we need the image metadata option. If anything, I'd be looking to deprecate the likes of 'hw_numa_cpus' | |
| 17:53:52 | sean-k-mooney | but if we are seting hw_cpu_policy=mixed in the image seting hw_pinned_cpus=1-5 i think is ok | |
| 17:54:07 | sean-k-mooney | stephenfin: i dont think that we shoudl do that | |
| 17:54:22 | sean-k-mooney | we could but its there for a reason | |
| 17:54:27 | stephenfin | so if we boot using a flavor with 4 cores, what happens? | |
| 17:54:30 | stephenfin | or with 8 cores? | |
| 17:54:30 | sean-k-mooney | partly to prevent falvor explosion | |
| 17:55:06 | sean-k-mooney | with 4 course it woudl be rejected by the numa constraint in the api | |
| 17:55:07 | stephenfin | by having image explosion instead? | |
| 17:55:24 | sean-k-mooney | before we even create the instance record | |
| 17:55:55 | sean-k-mooney | stephenfin: for 8 cors 0,6,7 would be un pinned | |
| 17:56:25 | stephenfin | Yeah, that seems wrong to me | |
| 17:56:27 | stephenfin | I'd be okay with a ratio | |
| 17:56:36 | stephenfin | i.e. 3:1 pinned:unpinned | |
| 17:56:44 | stephenfin | because it's a hint | |
| 17:56:45 | sean-k-mooney | right but we said its a list | |
| 17:56:52 | stephenfin | but I don't think anyone's asked for that | |
| 17:57:12 | stephenfin | has anyone actually said they need the image metadata option? | |
| 17:57:12 | sean-k-mooney | a ratio is not ok in general | |
| 17:57:30 | sean-k-mooney | thats a question for huaqiang and alex_xu | |
| 17:57:33 | stephenfin | well we have that in a manner already | |
| 17:57:54 | stephenfin | that's what e.g. the 'hw_cpu_cores' thing is doing | |
| 17:58:02 | stephenfin | the ratio of cores to threads and sockets | |
| 17:58:18 | sean-k-mooney | yes although its not really a raitio | |
| 17:58:24 | sean-k-mooney | it indireclty is | |
| 17:58:27 | sean-k-mooney | but ya | |
| 17:58:53 | stephenfin | a flat number of unpinned cores would also be okay for me | |
| 17:59:06 | redrobot | Hi friends! I have a question about your pep8 gate configuration. | |
| 17:59:08 | stephenfin | but again, I don't know how much that achieves | |
| 17:59:08 | sean-k-mooney | its really socket per vm, cores per socket and then threads per core | |
| 17:59:12 | stephenfin | redrobot: shoot | |
| 17:59:15 | redrobot | Seeing this error right now: | |
| 17:59:17 | redrobot | > F841 local variable '_' is assigned to but never used | |
| 17:59:31 | redrobot | I'm used to _ being used for throwaways in tests | |
| 17:59:47 | redrobot | but I was wondering if y'all handled it differently? | |
| 17:59:52 | stephenfin | Yeah, I thought that was usually ignored | |
| 18:00:04 | sean-k-mooney | it depens on the context i think | |
| 18:00:09 | stephenfin | Got a link to a build? We're just using flake8 + hacking | |
| 18:00:13 | sean-k-mooney | if you do _ = 4 | |
| 18:00:21 | sean-k-mooney | i think we will raise an error | |
| 18:00:27 | stephenfin | yeah, maybe | |