| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-11 | |||
| 09:25:44 | gmann | i was thinking with help of quota things but that would generate the scenario you want | |
| 09:31:05 | gibi | gmann: but quota is not per compute so it wont remove a single compute from scheduling | |
| 09:31:38 | gmann | yeah | |
| 09:31:46 | gibi | gmann: another way would be to create a flavor that is bigger than the remaining space on the compute the affinity group members are | |
| 09:32:15 | gmann | but how we would know how big flavor needs to be | |
| 09:32:21 | gibi | gmann: are the multi node computes has fixed size or it depends on the node they are running? | |
| 09:32:52 | gmann | gibi: it depends on node they are running. | |
| 09:33:01 | gmann | gibi: and it can be any size on non-gate env | |
| 09:33:29 | gibi | gmann: than I would have to ask nova/placement about the available resources to create a big enough flavor | |
| 09:35:43 | gibi | gmann: ahh it is not good | |
| 09:36:30 | gibi | gmann: I would need a flavor that requests more than available on the group's compute but still fits on the other compute (in multinode) | |
| 09:37:03 | gmann | gibi: another idea is to keep booting the server with same_host hint on anti-affinity compute till No-host | |
| 09:37:39 | gmann | but it can be very long scenario tests and need exact enabled_filter on setup | |
| 09:38:08 | gibi | gmann: and that could potentially interfere with test running in paralell | |
| 09:39:02 | gmann | yeah. not good | |
| 09:42:38 | gibi | gmann: OK, I conclude that this cannot be covered in tempest. So we need to cover that in nova functional | |
| 09:43:24 | gmann | gibi: yeah, functional tests is the way | |
| 09:43:39 | gmann | gibi: but for this bug, your patch is ok right? -https://bugs.launchpad.net/nova/+bug/1770434 | |
| 09:43:40 | openstack | Launchpad bug 1746863 in OpenStack Compute (nova) "duplicate for #1770434 scheduler affinity doesn't work with multiple cells" [High,In progress] - Assigned to melanie witt (melwitt) | |
| 09:44:16 | gmann | gibi: i mean doing multiple request not single | |
| 09:44:44 | gibi | gmann: yeah, that seems doable. I will push a new PS soon fixing the TODO and mriedem's comments | |
| 09:45:11 | gibi | gmann: it won't cover affinity + NoValid host case but that I will describe in the commit message | |
| 09:45:16 | gmann | gibi: yeah, because at least covering that scenario is good | |
| 09:45:23 | gmann | yeah | |
| 09:45:38 | gibi | gmann: thanks | |
| 09:45:50 | gmann | gibi: i will check that tomorrow. added in my list | |
| 09:46:00 | gibi | gmann: thank you | |
| 09:46:04 | gmann | time to go home, have good lunch | |
| 09:46:12 | gibi | have a good afternoon | |
| 09:53:15 | yikun | gibi: hi | |
| 09:53:47 | yikun | could you take a look on | |
| 09:53:52 | yikun | https://review.openstack.org/#/c/563401/31/nova/tests/unit/compute/test_compute_utils.py@1179 | |
| 09:55:23 | yikun | should we change {"max_server_per_host": "3"} to {"max_server_per_host": 3} keep same use user passed? | |
| 09:56:38 | yikun | we do conversion thing in group obj, see https://review.openstack.org/#/c/563375/39/nova/objects/instance_group.py@140 | |
| 10:00:28 | yikun | I'm not sure should we keep same with it. | |
| 10:00:44 | yikun | and here is some message history: | |
| 10:00:45 | yikun | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-07-11.log.html#t2018-07-11T02:18:53 | |
| 10:00:59 | yikun | ^ gibi | |
| 10:19:27 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform metrics.update notification https://review.openstack.org/580567 | |
| 10:28:05 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/559034 | |
| 10:28:55 | openstackgerrit | huanhongda proposed openstack/nova master: Microversion 2.64 - Add "deleted" time in GET server response https://review.openstack.org/574159 | |
| 10:44:03 | openstackgerrit | Van Hung Pham proposed openstack/nova master: convert py35 jobs to py3 https://review.openstack.org/581663 | |
| 10:46:15 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update queued-for-delete from the ComputeAPI during deletion. https://review.openstack.org/566813 | |
| 10:48:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update queued-for-delete from the ComputeAPI during deletion/restoration https://review.openstack.org/566813 | |
| 10:55:53 | gibi | yikun: it is on my list | |
| 10:57:31 | cnf | hi, anyone know what would cause the creation of a new instance to give me "Block Device Mapping is Invalid" ? | |
| 10:57:42 | cnf | on -cinder, someone said it looks like a nova issue | |
| 11:11:52 | yikun | gibi: ok, thanks :) | |
| 11:28:41 | openstackgerrit | huanhongda proposed openstack/nova master: Microversion 2.64 - Add "deleted" time in GET server response https://review.openstack.org/574159 | |
| 12:26:12 | gibi | yikun: did I expressed my opininon in every open issue in https://review.openstack.org/#/c/563401/28/nova/notifications/objects/server_group.py@41 or did I missed something? | |
| 12:27:08 | gibi | yikun: ahh the conversion thing | |
| 12:27:12 | gibi | yikun: i missed that | |
| 12:27:22 | yikun | yep, : ) | |
| 12:27:33 | yikun | conversion | |
| 12:27:46 | gibi | yikun: would it be hard to make the int conversion in the notification body as well? | |
| 12:28:30 | yikun | No, just need put some duplicate code into notification obj. | |
| 12:29:10 | yikun | like https://review.openstack.org/#/c/563375/39/nova/objects/instance_group.py@140 | |
| 12:30:36 | gibi | yikun: I see. We can only store a DictOfString even if your values will be in different types in the future | |
| 12:31:19 | gibi | yikun: can we call the rules property from the notification payload generation? let me look a bit deeper in the code... | |
| 12:32:11 | gibi | yikun: I guess we call the rules property but then we store the result in a DictOfString in the payload as well | |
| 12:32:23 | gibi | yikun: which converts it back to string | |
| 12:32:57 | yikun | yes, so if we don't do convert, we will get back a "3" | |
| 12:32:58 | gibi | yikun: as we don't have a Dict type with variable value type | |
| 12:33:11 | gibi | yikun: we cannot define a proper field in the payload class | |
| 12:33:44 | gibi | yikun: and the payload class is something we think about as a contract for the consumers | |
| 12:33:49 | yikun | yes, at least I can't see a DictField type in ovo. :) | |
| 12:34:14 | gibi | yikun: let's keep it as "3" | |
| 12:34:35 | gibi | yikun: I would not like to have a DictOfString defined in the class but we would emit an int as a value | |
| 12:34:38 | gibi | in the notification | |
| 12:35:48 | gibi | yikun: commenting it in the review... | |
| 12:37:47 | gibi | yikun: done | |
| 12:38:00 | gibi | yikun: thanks for your patientes | |
| 12:38:42 | yikun | OK, I see, much thanks for your time and help. :) | |
| 12:38:45 | gibi | s/patientes/patience | |
| 12:39:07 | yikun | :), ha, I know | |
| 12:39:22 | gibi | :) | |
| 12:40:30 | yikun | and it time to leave and back home, have a good day. | |
| 12:40:46 | gibi | good day to you too | |
| 12:41:17 | mriedem | gibi: so we're leaving it as a string in the notification payload? | |
| 12:41:25 | gibi | mriedem: yes | |
| 12:42:32 | gibi | mriedem: because the field type is DictOfString and when we finally generate json schemas for notification classes then that will also created from the field typw | |
| 12:42:35 | gibi | type | |
| 12:44:23 | mriedem | i'm assuming yikun pointed out that for InstanceGroup.rules we coerce the known max_server_per_host field value to an int | |
| 12:47:31 | gibi | mriedem: yes, I saw that. gmann also pointed out that can be lead to some json validation inconvenience | |
| 12:47:41 | gibi | mriedem: if we flatten the API | |
| 12:49:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip ServerShowV257Test.test_rebuild_server for cells v1 job https://review.openstack.org/581717 | |
| 12:51:04 | mriedem | for the rest api, we accept strings or ints apparently | |
| 12:51:07 | mriedem | which was news to me | |
| 12:51:13 | mriedem | for the positive_integer type | |
| 12:51:50 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L238 | |
| 12:51:51 | gibi | mriedem: and we patternmatch, I see | |
| 12:52:16 | mriedem | so i'm not sure why {'max_server_per_host': 3} vs {'max_server_per_host': '3'} | |
| 12:52:20 | mriedem | will make a difference | |
| 12:52:39 | mriedem | tbc, the InstanceGroup.rules doing the cast to int for that value is for internal convenience more than anything, | |
| 12:52:54 | mriedem | so we don't have to remember to cast the value in all of the code that uses it, like the view builder in the api, the scheduler filter and the late affinity check in the compute | |
| 12:54:45 | gibi | mriedem: I think the api accepts strings for historical reasons | |
| 12:55:33 | gibi | mriedem: I sure I'm OK to cast it to int internally for counting and comparison | |
| 12:57:08 | mriedem | ok. i just don't understand the json schema validation concern | |
| 12:57:19 | mriedem | is that a concern for the consumer of the notification? | |
| 12:59:01 | gibi | mriedem: no it is not. I refer to gmann's comment in https://review.openstack.org/#/c/563401/28/nova/notifications/objects/server_group.py@41 about the need to move the validation from json to code | |