| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 14:26:21 | sdague | if version stops being a string, and is actually a version object when it gets to get_server_create_version then it would be harder to make it an equality | |
| 14:26:59 | sdague | version.between('2.32', None) | |
| 14:27:37 | sdague | if you really want an equal, then do between('2.32','2.32') | |
| 14:27:47 | sdague | that will be a lot more obvious to reviewers that it is wrong | |
| 14:28:14 | sdague | that might be more effective than complicated testing | |
| 14:34:20 | amrith | hi andreykurilin | |
| 14:34:37 | amrith | let's watch the change you proposed (with the dependency) | |
| 14:34:39 | amrith | and go from there | |
| 14:34:44 | amrith | I'm looking at the test you mentioned | |
| 14:34:46 | amrith | which also failed | |
| 14:34:51 | amrith | last time around | |
| 14:35:31 | andreykurilin | amrith: actually, it looks like I have a workaround (depends-on patch looks like not ready yet and require some additional work). I'll propose one more change | |
| 14:35:44 | amrith | ok, thx andreykurilin | |
| 14:36:55 | alex_xu | sdague: yea, we can pass the object instead of string. but the object support __eq__ :) | |
| 14:40:19 | alex_xu | johnthetubaguy: sdague, so that bug need to be fixed by microversion, is that something we can done before release, or it will be a Pike thing. And have a reno 'issue' note in Ocata? | |
| 14:41:06 | sdague | alex_xu: I think we should make the object stop supporting eq natively | |
| 14:42:03 | johnthetubaguy | I am with sdague on stopping the route cause here urgently | |
| 14:42:44 | sdague | alex_xu: so, what happens when 2.33 is used? | |
| 14:42:44 | alex_xu | sdague johnthetubaguy : ok, I will check that tomorrow | |
| 14:43:29 | andreykurilin | amrith: what is context.token here https://github.com/openstack/trove/blob/master/trove/common/remote.py#L102 ?) | |
| 14:45:29 | alex_xu | sdague: emm...looks like there is no 'addtionalProperties: False', that means the tag still work in the 2.33, just lose validation, I need to check that | |
| 14:45:48 | jroll | edleafe: one more question, did we figure out what an ironic flavor using resource classes looks like yet? | |
| 14:45:53 | jroll | jaypipes: ^^ | |
| 14:45:56 | sdague | alex_xu: it would be extremely useful to me to get a mailing list post out about what went wrong, what this allows, and what the fall out from various fixing options would be | |
| 14:46:29 | sdague | because otherwise everyone needs to build that up in their own head from scratch, and it's hard to agree on path forward unless we all agree where we stand | |
| 14:46:51 | edleafe | jroll: good question | |
| 14:47:05 | alex_xu | sdague: i see now. I will investigate more, then send out an email | |
| 14:47:09 | jroll | edleafe: I'd like to have that in my docs for the ironic install guide, I guess | |
| 14:47:20 | edleafe | jroll: I'm still not clear on whether we need to add the resource class to the flavor | |
| 14:47:20 | jroll | though, if it doesn't work until pike, idk | |
| 14:47:37 | jroll | edleafe: how else do we map a flavor to said resource class? | |
| 14:47:52 | edleafe | jroll: or if there is some other mapping | |
| 14:47:56 | sdague | alex_xu: thank you | |
| 14:47:57 | edleafe | jroll: jinx | |
| 14:48:02 | alex_xu | sdague: np | |
| 14:48:48 | edleafe | jroll: my understanding is that the flavor will be: CUSTOM_IRONIC_CLASS: 1 | |
| 14:49:13 | edleafe | jroll: and that placement will find a provider for that class | |
| 14:49:15 | jroll | edleafe: where, in the flavor? e.g. how do I create said flavor? | |
| 14:49:33 | edleafe | jroll: IOW, no disk/ram/cpu BS like now | |
| 14:50:13 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489 | |
| 14:50:14 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997 | |
| 14:50:15 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744 | |
| 14:50:21 | edleafe | jroll: well, like any other flavor, but not sure what changes the custom RC stuff will need | |
| 14:50:41 | jroll | edleafe: sure, so just nova flavor-key my-flavor set CUSTOM_FOO_THING=1? | |
| 14:50:43 | jroll | right | |
| 14:50:47 | edleafe | jroll: jaypipes had all this on his mental whiteboard | |
| 14:51:17 | jroll | edleafe: so here's the thing, if we require this to be set up for a smooth upgrade to pike, then we need to be able to make a working flavor in ocata | |
| 14:51:34 | edleafe | jroll: agreed | |
| 14:51:54 | jroll | edleafe: and we're three days from feature freeze and this is but a butterfly in jaypipes' brain, correct? | |
| 14:52:20 | edleafe | jroll: unless that butterfly laid some eggs in cdent's brain, yet | |
| 14:52:25 | edleafe | s/yet/yes | |
| 14:52:52 | edleafe | jroll: He may have written it up somewhere - I can dig for it | |
| 14:52:55 | jroll | edleafe: I mean, if it isn't written down at this point, I don't believe it will happen, which means this can't be mandatory fora pike upgrade | |
| 14:52:56 | jroll | okm, | |
| 14:52:58 | jroll | ok* | |
| 14:53:06 | jroll | thanks | |
| 14:53:15 | jroll | all I've seen is maybe an extra spec | |
| 14:53:18 | edleafe | jroll: I'll let you know what I find | |
| 14:53:25 | jroll | edleafe: thank you | |
| 14:56:40 | sfinucan | vladikr: Comments left on https://review.openstack.org/#/c/421186/2 | |
| 14:58:17 | vladikr | sfinucan, thanks | |
| 15:00:12 | amrith | andreykurilin, the token there is something that the client (trove client) would have created and passed to the server. so the auth and token creation is done on the trove client side and the API service (or TM) on the trove control plane uses those credentials. That would be a keystone token. | |
| 15:01:08 | andreykurilin | amrith: oh, sorry. I wrote the wrong question :( it should be : what is tenant there | |
| 15:01:33 | amrith | project_id | |
| 15:01:46 | dansmith | sdague: sfinucan: johnthetubaguy: bauzas: The two patches at the head of this series have been +1 from jenkins for a while and have seen little review. They're not super complicated and I'd really like to see them get in while we work on the third, which is the major goal for ocata for cells: https://review.openstack.org/#/c/396775 | |
| 15:02:18 | andreykurilin | amrith: nice | |
| 15:02:23 | bauzas | dansmith: okay, I can take a look now | |
| 15:02:30 | dansmith | thanks | |
| 15:02:32 | sfinucan | dansmith: Likewise | |
| 15:04:46 | dansmith | also thanks :) | |
| 15:06:52 | ildikov | johnthetubaguy Hi, Can you make it to the meeting today? | |
| 15:12:33 | openstackgerrit | Stephen Finucane proposed openstack/nova: scheduler: Don't modify RequestSpec.numa_topology https://review.openstack.org/419479 | |
| 15:13:14 | sfinucan | dansmith, sahid: If ye could take another look at ^, I'd be mighty appreciative | |
| 15:13:41 | bauzas | dansmith: comments in your bottom change | |
| 15:14:18 | dansmith | bauzas: thanks | |
| 15:14:20 | dansmith | sfinucan: yep | |
| 15:15:42 | bauzas | dansmith: just wanted to make sure we have a limit but not a marker, right? | |
| 15:16:59 | dansmith | bauzas: the marker is handled in that code | |
| 15:17:17 | bauzas | dansmith: mmm? lemme look, I maybe missed it | |
| 15:17:21 | dansmith | bauzas: we pass the marker down to all the sub-list commands and honor the limit at the top | |
| 15:20:22 | bauzas | dansmith: I'm seeing it now | |
| 15:20:46 | bauzas | dansmith: but I actually wonder how it works with 2 cells not having the same number of instances in there | |
| 15:20:58 | bauzas | dansmith: but lemme look at that | |
| 15:20:59 | dansmith | bauzas: how what works? | |
| 15:21:13 | bauzas | my brain is just fried by the scheduler upcall so I could be misunderstanding | |
| 15:21:36 | bauzas | dansmith: so, you construct a global limit and you pass it down to the cell-related instance.get_all() call | |
| 15:21:48 | bauzas | with leaving the marker, right? | |
| 15:22:27 | dansmith | the global limit is just to make sure that we don't keep querying cells for more instances | |
| 15:22:47 | dansmith | so if you limit=100 and we return 90 from the first cell, then the second cell should only fetch 10, and the third cell 0 | |
| 15:23:27 | dansmith | sfinucan: why no test on that filter change/ | |
| 15:24:08 | bauzas | dansmith: right, I understood that | |
| 15:24:17 | sfinucan | dansmith: Because I couldn't figure out where to slot it in 🙈 | |
| 15:24:34 | bauzas | I'm thinking of the limit=50 and cell1 having 60 | |
| 15:25:04 | dansmith | bauzas: then we'll limit=50 on the first cell, and then limit will be zero afterwards, an we will never call the next one | |
| 15:25:08 | bauzas | in that case, we get the first 50 elements and we set the marker to the 50th injstance | |
| 15:25:09 | dansmith | bauzas: and return 50 instances | |
| 15:25:17 | bauzas | right | |
| 15:25:51 | bauzas | so, next call would get the cell1 marker to the 50th instance, so a new limit of 50 would return the 10 left + 40 from cell2 if we have enough, right? | |
| 15:26:24 | bauzas | I think I see the logic | |
| 15:26:32 | bauzas | we consume all instances from cell to cell | |