| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-16 | |||
| 18:12:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899 | |
| 18:12:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: add test for scenario with sum of child resources https://review.openstack.org/534339 | |
| 18:13:31 | jaypipes | melwitt: an aggregate in placement doesn't have any metadata associated with it at all. it's a pure grouping mechanism. | |
| 18:14:30 | efried | stephenfin Not sure which two comments were the ones holding you back. Let us know if we can clarify anything further. Thanks for the review! | |
| 18:14:31 | melwitt | jaypipes: yeah, I understand. just pointing out the high level effect on the usability in this case | |
| 18:14:40 | jaypipes | melwitt: the problem with the aggregate overcommit thing in Nova is what happens when the compute node's allocation ratio is != the aggregate's allocation ratio? also, what happens when a compute node is in multiple aggregates? which allocation ratio should be used? all these things are not issues in placement because we don't store metadata for aggregates. | |
| 18:15:11 | melwitt | jaypipes: good points | |
| 18:15:24 | melwitt | especially the multiple aggregates | |
| 18:16:38 | jaypipes | melwitt: and I'm not trying to be argumentative. just pointing out that there are definitely some things we won't be porting over to placement land... | |
| 18:17:15 | melwitt | jaypipes: understood. I'm not trying to be argumentative either. just looking to understand and be able to explain it to ppl :) | |
| 18:17:21 | melwitt | so thanks | |
| 18:18:55 | jaypipes | melwitt: when discussing a similar thing with operators (having to set traits on compute node resource provider records individually instead of relying on agg metadata) I had suggested a simple CLI tool that would essentially apply a particular trait to all providers associated with an aggregate. they seemed responsive to that idea. | |
| 18:26:14 | efried | jaypipes edleafe cdent gibi For all the hubbub, we may still want to implement an accessor for provider generation. Given the way I'm using it e.g. in https://review.openstack.org/#/c/532564/9/nova/scheduler/client/report.py@1046 | |
| 18:26:19 | melwitt | jaypipes: k, I'll mention that to them. we'll be looking at how to change over from the Aggregate<resource> filters and configure the deployment to set it per compute node | |
| 18:27:09 | melwitt | s/it/overcommit/ | |
| 18:27:56 | edleafe | efried: what's the reason you can't just use generation = self._provider_tree.generation? | |
| 18:28:21 | efried | edleafe ProviderTree doesn't have a generation. A single provider does. | |
| 18:28:43 | efried | edleafe Back to the thing where individual providers are hidden in the ProviderTree. | |
| 18:29:03 | edleafe | efried: ok, I thought there was something I was missing | |
| 18:29:26 | efried | ProviderTree.snapshot(rp_uuid).generation *works* - it's just wildly inefficient. | |
| 18:30:25 | edleafe | efried: are there other atts besides generation that you have a need to access? | |
| 18:31:14 | openstackgerrit | Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886 | |
| 18:31:43 | efried | edleafe Yes, the complex ones (aggs, traits, inventory) which we *must* copy out. Primitives, though... maybe parent_uuid? Eventually name? | |
| 18:32:16 | efried | edleafe More will shake out once drivers start implementing update_provider_tree. | |
| 18:33:11 | edleafe | efried: so are you thinking something like: ptree.getattr(rp_uuid, attname) ? | |
| 18:34:42 | efried | edleafe Initially I was just thinking about ptree.generation_for(rp_uuid), qua https://review.openstack.org/532922 | |
| 18:35:16 | edleafe | efried: well, that's why I asked if you will need this for more than just generation | |
| 18:35:39 | efried | edleafe Surely. Even so, the idea of N accessors was discussed on Monday and jaypipes expressed a preference for doing it this way. | |
| 18:35:49 | edleafe | efried: it would suck to have ptree.name_for(rp_uuid), ptree.parent_uuid_for(rp_uuid), etc. | |
| 18:35:55 | efried | agreeeeed. | |
| 18:36:10 | efried | edleafe I think what I'm actually coming around to is that we shouldn't do the deep copy of the nested children in .snapshot() - at least not by default. | |
| 18:36:46 | efried | edleafe Then at least we're only throwing away one provider's worth of stuff we copied for no reason. | |
| 18:38:11 | sean-k-mooney | stephenfin: jaypipes i ran all the tempest smoke test + senario test + tox -e py35,py27,functional,pep8,docs locally on https://review.openstack.org/#/c/534307/2 here http://paste.openstack.org/show/645744/ all passed so just waiting on the gate to do the same. | |
| 18:38:15 | edleafe | or have snapshot() take an optional rp_uuid | |
| 18:38:32 | edleafe | and only return that provider w/o children | |
| 18:38:54 | efried | edleafe It already does take rp_uuid; that's how you tell it which provider you want to snapshot. | |
| 18:41:23 | esberglu | stephenfin: Asked around and it turns out that nova-networking isn't supported. You okay with leaving bit in for now and removing it in a follow up? | |
| 18:41:34 | esberglu | Trying to avoid respinning the series if possible | |
| 18:42:02 | sean-k-mooney | esberglu: nova-networking has not been removed yet. it will be in early rocky | |
| 18:42:28 | esberglu | sean-k-mooney: This is in regards to powervm virt driver support | |
| 18:42:52 | esberglu | It only supports neutron | |
| 18:43:27 | sean-k-mooney | esberglu: oh well if povervm never supported nova-net before or you have already dropped(or never supported) cells v1 then you dont need nova-networks support | |
| 18:44:02 | efried | esberglu fyi stephenfin is on UK time, so may be gone for the evening. | |
| 18:44:22 | esberglu | efried: ahh thanks for the info | |
| 18:45:28 | efried | esberglu And gibi is also euro. So you might as well respin the series and they should be able to nail 'em quick in the morning (like 4am for us). | |
| 18:46:53 | sean-k-mooney | efried: are you east coast or west? | |
| 18:47:12 | efried | sean-k-mooney Central (Texas) | |
| 18:47:27 | sean-k-mooney | ah ok | |
| 18:47:31 | efried | I think esberglu is either Central or East | |
| 18:47:47 | esberglu | central | |
| 18:48:26 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 18:49:10 | sean-k-mooney | ya unlike me stephen starts early and finishes early. i generally stay later but start later to give more us overlap in my day. also i hate have 2 7 oclocks in my day unless the frist on is 7 pm | |
| 18:50:10 | efried | sean-k-mooney Sounds like you coordinate way more than we do :) | |
| 18:51:14 | efried | As far as meetings go, I consider a successful week to be one with three IRC meetings and zero in-person or phone meetings. | |
| 18:52:28 | efried | (at least, zero in-person meetings that don't involve choking the persons involved) | |
| 18:52:52 | openstackgerrit | Claudiu Belu proposed openstack/nova master: tests: fixes mock autospec usage https://review.openstack.org/447505 | |
| 18:53:18 | sean-k-mooney | efried: haha i would love that. lately i have not had much internal meeting but in the past i had. i like beeing on irc when most of the nova,neutron and kolla core team are about too so haveing a slightly later day helps | |
| 18:53:41 | efried | Mm. I believe cdent is of similar philosophy. | |
| 18:54:03 | edleafe | efried: I have 3 phone meetings *today* | |
| 18:54:28 | cdent | ... that's more side-effect than goal | |
| 18:58:37 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 18:58:37 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216 | |
| 18:58:38 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 19:01:10 | sean-k-mooney | efried_nomnom: esberglu is there a reason you are not using and os-vif plugin intead of https://review.openstack.org/#/c/422512/40/nova/virt/powervm/vif.py | |
| 19:02:17 | efried_nomnom | sean-k-mooney The main reason is probably because os-vif didn't exist when we wrote this stuff, or even when we first started porting it in tree. | |
| 19:02:51 | sean-k-mooney | efried_nomnom: os-vif has been around for 3 maybe 4 cycles now | |
| 19:03:11 | sean-k-mooney | efried_nomnom: it would be nice to convert in rocky | |
| 19:03:23 | efried_nomnom | Duly noted. esberglu ^ for the to-do list? | |
| 19:03:59 | efried_nomnom | Also sean-k-mooney we wouldn't know how to do that offhand. But since you've volunteered to guide us.... :) | |
| 19:04:06 | cfriesen | I'm trying to figure out if a bug is in nova or libvirt/qemu. Do we have any functional/tempest tests of live migration with a config drive and an attached cinder volume? | |
| 19:04:45 | Roamer` | hmm, if mriedem is really on vacation, could I interest any of you in taking a quick look at https://review.openstack.org/140733/ - the StorPool libvirt volume attachment driver? :) The Cinder and os-brick support is in, and Nova's requirements.txt has a dependency on the new version of os-brick now. | |
| 19:05:31 | Roamer` | of course, "leave it till he gets back" might also be kind of reasonable... although it may be cutting it a bit too close to the January 25th deadline | |
| 19:06:34 | sean-k-mooney | efried_nomnom: sure im happy to help. its not a huge amount of work to do but it means you dont have to submit patches to nova to take advantage of things like ovs now support jumbo frames with datapath x or other network backend specific features | |
| 19:07:15 | efried_nomnom | sean-k-mooney Thanks in advance | |
| 19:08:25 | sean-k-mooney | efried_nomnom: other then requireing a powerpc system is there any other requirement to be able to deploy powervm. e.g. is it opensouce? | |
| 19:10:10 | efried_nomnom | sean-k-mooney As long as "having a POWER system" includes relevant licensing (e.g. for VIOS), no other requirements I believe. Everything else is free (though not all of it is open source). | |
| 19:11:21 | sean-k-mooney | efried_nomnom: hum ok i was wondering if i could emulate PPC under kvm and in stall powervm hyperviors under something like ubunut but i guess not | |
| 19:11:30 | cfriesen | melwitt: do you know what the fix was for https://bugzilla.redhat.com/show_bug.cgi?id=1394964 (I'm guessing "mwitt@redhat.com" is you...) | |
| 19:11:31 | openstack | bugzilla.redhat.com bug 1394964 in openstack-nova "Live migration with config-drive fails with InvalidSharedStorage error" [High,Closed: errata] - Assigned to mwitt | |
| 19:11:52 | efried_nomnom | sean-k-mooney No, fraid not. | |
| 19:12:23 | efried_nomnom | sean-k-mooney I mean, if you *could* actually emulate POWER (which isn't PowerPC, btw) then I imagine you could do that. | |
| 19:13:00 | efried_nomnom | sean-k-mooney But emulating POWER is very, very hard. There is/was a project around here to do it, but I don't think it's up to date; and it's dogggggg slow. | |
| 19:13:15 | sean-k-mooney | oh i did not know they were different. PPC is ibm right is POWER openPOWER | |
| 19:13:37 | efried_nomnom | I'm not sure what the status of ppc is actually. | |
| 19:13:54 | efried_nomnom | And POWER is *almost* openPOWER. | |
| 19:14:09 | melwitt | cfriesen: yes, that is me. looking ... | |
| 19:14:20 | efried_nomnom | I think openpower is a way for not-IBM to build POWER-compatible systems. | |
| 19:15:12 | efried_nomnom | But I'm totally not a terminology/marketing guy. I just try to write as much code as possible. | |
| 19:16:25 | cfriesen | melwitt: maybe bc4b9980f ? | |
| 19:16:26 | sean-k-mooney | til well i shoudl be able to help in anycase. there is a lot you can do with unitest to fake things out + there is the IBM PowerVM CI so if you remind me/ i get time i might take a go at it but not before the PTG/end of Q1 | |
| 19:19:07 | melwitt | cfriesen: so it was fixed by having https://review.openstack.org/#/c/227278 and removing VIR_MIGRATE_TUNNELLED from the block_migration_flag in nova.conf | |
| 19:19:29 | melwitt | and I think config drive has to be vfat also | |
| 19:20:49 | cfriesen | melwitt: okay, was wondering about that last part. we're still (in Pike) hitting issues with iso9660 config drives and boot-from-volume on a compute node with local storage. | |
| 19:21:45 | cfriesen | melwitt: specifically with block-live-migrating such instances | |
| 19:22:03 | cfriesen | I'm trying to see if it's something we broke or an upstream issue. | |
| 19:22:07 | melwitt | cfriesen: yeah, I can't remember the context now but if you dig into the libvirt driver code there are a lot of conditions that have to be met before live block migration will work, and if you have a config drive, that's local storage so has to be a live BLOCK migration | |
| 19:22:43 | melwitt | you can't have the tunneling but I don't remember why | |
| 19:23:48 | cfriesen | melwitt: that part I know...tunnelling prevents the "block migrate some disks but not others" behaviour in libvirt | |
| 19:23:56 | melwitt | oh, okay. cool | |
| 19:24:12 | melwitt | now I know then :) | |