| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-21 | |||
| 15:06:13 | edmondsw | tittywai lots of different ones | |
| 15:06:19 | frickler | it may be easy, but for an operator it would still be nice to have a command at the end of https://docs.openstack.org/developer/nova/placement.html that confirms that all computes have successfully placed their data into the api | |
| 15:07:00 | tittywai | no what I mean is that.. where you are right now.. to be more specific... :P | |
| 15:07:26 | mriedem | tittywai: many people are currently at the PTG in Atlanta, GA in the US | |
| 15:08:12 | bauzas | frickler: I think it's a bit premature to have that, given we also need to cut the current methods we use into a different module at least | |
| 15:08:36 | bauzas | frickler: a separate try was https://review.openstack.org/#/c/417111/ | |
| 15:08:56 | tittywai | mriedem: thanks for the info | |
| 15:09:01 | tittywai | im from sg | |
| 15:09:06 | mriedem | bauzas: frickler just wants to know they are fully upgraded i believe | |
| 15:09:16 | mriedem | so that all computes are reporting into placement so the filter scheduler starts using placement | |
| 15:09:27 | bauzas | um ok | |
| 15:09:56 | mriedem | so i guess nova hypervisor-list wc matches placement resource-provider-list | |
| 15:10:02 | mriedem | or something like that | |
| 15:10:05 | mriedem | frickler: please confirm | |
| 15:10:23 | mriedem | frickler: also, check out the "nova-status upgrade check" command | |
| 15:10:44 | mriedem | frickler: https://docs.openstack.org/developer/nova/man/nova-status.html#upgrade | |
| 15:10:51 | mriedem | that might help you in the meantime | |
| 15:11:05 | satyar | hi mriedem | |
| 15:11:10 | frickler | nova-status: command not found -- for Newton | |
| 15:11:17 | mriedem | frickler: new in ocata | |
| 15:12:32 | markus_z | mriedem: Now is a bad time to ask you about the newton backport for serial console https://review.openstack.org/#/c/406898/ right? | |
| 15:12:34 | frickler | we are currently doing Newton deployments but want to make sure we have the placement-api in place there properly, so that the upgrade to Ocata will be easier | |
| 15:12:45 | mriedem | markus_z: yup | |
| 15:12:47 | mriedem | satyar: hi | |
| 15:13:00 | markus_z | np, I'll ask again next week | |
| 15:13:19 | bauzas | mriedem: I see | |
| 15:13:24 | mriedem | frickler: yeah. you could install nova ocata in a venv and run it against newton with your full nova.conf | |
| 15:13:36 | mriedem | nova.conf from the control node | |
| 15:13:56 | bauzas | frickler: you wanna get that from an API call ? | |
| 15:14:14 | bauzas | frickler: because it's fairly simple to just DB query that if you don't cells | |
| 15:14:23 | bauzas | for Newton I mean of course | |
| 15:14:42 | mriedem | you can curl request to the placement endpoint | |
| 15:14:51 | mriedem | there are a few ways to skin this cat | |
| 15:14:55 | bauzas | as well | |
| 15:15:03 | bauzas | given you have a valid token of course | |
| 15:20:48 | frickler | yeah, so I guess I'll script something together with that | |
| 15:57:47 | openstackgerrit | Sean Dague proposed openstack/nova master: Verify project id for flavor access calls https://review.openstack.org/435432 | |
| 16:20:48 | bauzas | reminder for non-English native bug reporters, please think of people who don't speak your language | |
| 16:20:50 | openstack | Launchpad bug 1666148 in OpenStack Compute (nova) "nova set-password instancesname return 409 error" [Undecided,New] | |
| 16:20:50 | bauzas | https://bugs.launchpad.net/nova/+bug/1666148 | |
| 16:21:25 | bauzas | désolé, je ne parle pas le chinois et j'ai aussi essayé de googler | |
| 16:22:40 | bauzas | hah, that's just a google footer telling the bug reporter did translated automatically their report... | |
| 16:33:15 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_class https://review.openstack.org/430463 | |
| 16:34:25 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_class https://review.openstack.org/430463 | |
| 16:43:00 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: WIP: Remove deprecated image commands/API bindings https://review.openstack.org/436494 | |
| 16:59:14 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Remove deprecated image commands/API bindings https://review.openstack.org/436494 | |
| 17:04:05 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Remove deprecated image commands/API bindings https://review.openstack.org/436494 | |
| 18:31:32 | openstackgerrit | Sean Dague proposed openstack/nova master: Verify project id for flavor access calls https://review.openstack.org/435432 | |
| 18:54:16 | diana_clarke | mriedem: Have you seen any patches go by to fix these warnings? They're getting really annoying ;) http://paste.openstack.org/show/598407/ | |
| 18:54:24 | diana_clarke | (If not, I can look into it) | |
| 18:55:52 | mriedem | diana_clarke: no, i think it's actually an issue in the openrc created in devstack | |
| 18:55:57 | mriedem | i assume it's setting OS_TENANT_ID | |
| 18:56:44 | diana_clarke | mriedem: Okie dokie. I'll look into it then. I just assumed someone else probably got to it already, but perhaps not. | |
| 19:10:53 | dansmith | alaski: just thought you might want to know.. I just started the first ever instance in a second cell(v2) | |
| 19:11:30 | gmann | gibi: bauzas I am ok to add that tests in tempest but few inline comment and yes we can reduced the testing bits if that really saving time and resource - https://review.openstack.org/#/c/374887/12 | |
| 19:11:31 | melwitt | dansmith: did you have to do anything more than the cell-aware compute node get? | |
| 19:12:01 | dansmith | melwitt: yes, lots | |
| 19:12:06 | melwitt | oh | |
| 19:12:25 | melwitt | (I meant as the last hurdle) | |
| 19:12:53 | dansmith | compute node and service get per cell, and then (super-)conductor was creating the instance action in the wrong cell | |
| 19:12:54 | dansmith | i.e. not targeted | |
| 19:12:55 | dansmith | and failing | |
| 19:13:06 | dansmith | which means that's a bug we would not have caught if we didn't go with the full three-way deal right way | |
| 19:13:09 | dansmith | so, glad we did that | |
| 19:13:41 | melwitt | ah | |
| 19:16:04 | bauzas | gmann: FWIW, I don't like that because it just consumes a lot of infra resources for some very small coverage | |
| 19:16:53 | bauzas | gmann: instead, I'm just writing a functional test in the nova tree that would setup a fake env using fixtures and would verify the output without requiring further space | |
| 19:18:56 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Remove mox from nova/tests/unit/virt/vmwareapi/test_vif.py https://review.openstack.org/436596 | |
| 19:19:12 | gmann | bauzas: yea functional tests on nova is nice idea. But on tempest side also i think this is something nice things to tests. yea infra resource is issue but we can sort out that where to run those tests. Making Tempest more useful for production env testing also :) | |
| 19:19:43 | gmann | bauzas: i mean yea infra resource and gate is 1 think but it will be for production cloud testing also | |
| 19:21:06 | alaski | dansmith: \o/ awesome | |
| 19:25:26 | gmann | bauzas: like we have same host and different host filter tests on tempest | |
| 19:26:25 | bauzas | aaaaand I don't like that :) | |
| 19:26:45 | bauzas | we also have ServerGroup testing in the nova functional tree y'know | |
| 19:27:05 | bauzas | so, in between both ways, I prefer the less consuming one | |
| 19:27:08 | gmann | bauzas: I can check if we can make hotse filter and aggregate filter tests in single class and can be run on single multinode setup | |
| 19:27:33 | gmann | so that infra resource things can be shared | |
| 19:27:41 | bauzas | again, I don't see the added value of running it in a multinode env if we can just spin a couple of services using fixtures for doing that | |
| 19:28:01 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Add functional test for "nova boot --image-with" https://review.openstack.org/436608 | |
| 19:28:05 | mriedem | sdague: ^ check out how fun that is | |
| 19:28:36 | bauzas | gmann: and that would require to deploy all the filters for testing each of those, meaning no isolation, good luck with that | |
| 19:28:37 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Remove deprecated image commands/API bindings https://review.openstack.org/436494 | |
| 19:31:17 | gmann | bauzas: you mean no isolation? even test will add different tenants on aggregate and test will not boot server with any other scheduler hint | |
| 19:32:28 | gmann | i mean let's devstack enabled those filters on nova side(it does currently and we can add aggregate tenant isolation also) and specific tests for aggregate filter will just add tenant metadata on aggregate and boot server | |
| 19:36:01 | bauzas | gmann: say you want to test two filters | |
| 19:36:16 | bauzas | gmann: and you don't want to spin a devstack for every case | |
| 19:37:01 | bauzas | gmann: what you need then is, spin my devstack, pimp my scheduler config, restart my scheduler config, do my POST, verify my result, and loop back for the second filter | |
| 19:37:21 | openstackgerrit | Roman Podoliaka proposed openstack/nova-specs master: Ironic: add support for instance RAID configuration https://review.openstack.org/408151 | |
| 19:37:25 | bauzas | if you wanna make sure that a 2nd filter result wouldn't pollute | |
| 19:38:25 | bauzas | gmann: because spin devstack, pimp my sched config by adding two filters, restart, do POST, verify against a specific filter means that you could get NoValidHost because of the 2nd filter you don't explicitely wanna test | |
| 19:39:19 | gibi | bauzas: only if the two filters interfere. | |
| 19:39:42 | bauzas | gmann: either way, I leave you convince the tempest folks, on my side, I'm writing the in-tree functional test for that | |
| 19:39:47 | gibi | bauzas: and here the tenant isolation filter only filter out hosts if the aggregate has special metadata | |
| 19:40:15 | gmann | bauzas: I understand. currently we have those are filter enabled from devstack side - https://github.com/openstack-dev/devstack/blob/master/lib/nova#L94 | |
| 19:41:02 | gmann | so as gibi mentioned if those filters are not conflicting it should be fine right? | |
| 19:44:11 | gibi | bauzas: and I'm not against having the functional test but it has a benefit having a tempest test against a deployed system to ensure that depolyment does the isolation | |
| 19:44:54 | openstackgerrit | Dinesh Bhor proposed openstack/nova-specs master: Policy support for specific metadata keys https://review.openstack.org/436493 | |
| 19:45:07 | bauzas | gibi: if that's not running in the gate, then maybe | |
| 19:45:29 | mriedem | ildikov: upstream training email sent | |
| 19:45:31 | bauzas | but I'm seriously concerned by that being a thing for the gate | |