Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-24
14:40:08 mriedem so you could do that and then when we handle the ironic driver TODO we can also cleanup the powervm driver
14:40:40 esberglu mriedem: Sounds good thanks!
14:41:00 mriedem that also forces you to use DriverVolumeBlockDevice objects in your unit tests, but i think that's a good thing, given a BDM can be one of at least 3 or 4 things at any given point in the code
14:42:52 esberglu mriedem: We already are using DriverVolumeBlockDevice objects :)
14:43:28 mriedem then you get a root beer scented scratch-n-sniff
14:45:21 stephenfin mriedem, jaypipes, bauzas, gibi: I'm thinking most of the information from here down is too detailed for the spec (it was mostly to help me figure out the problem boundary myself). I think I could drop the whole piece. Thoughts? https://review.openstack.org/#/c/541290/7/specs/rocky/approved/numa-aware-vswitches.rst@38
14:47:02 mriedem stephenfin: given my lack of knowledge on numa stuff, i'll likely appreciate details in the problem description
14:48:00 stephenfin mriedem: This is more about OVS-DPDK internals. If you think that's be helpful, I can keep it
14:48:12 stephenfin I'd like to add it to a different section but that upsets pep8 :)
14:48:29 gibi stephenfin: I have the same mental debate about the bandwidth spec. It is too detailed for a reader who is familar with the problem and the proposed solution, but it has a lot of nice details and reasoning for a new reader.
14:48:44 gibi stephenfin: for me it is OK to remove that section from your spec
14:49:09 gibi stephenfin: you can add new subsections but you cannot add a new top level section
14:49:11 stephenfin maybe I can publish it as a separate blog and link to that from there
14:49:23 mriedem stephenfin: i was just thinking that
14:49:50 mriedem 'for more information on how this relates to dpdk, see $link'
14:50:02 stephenfin mriedem: Sounds good to me. I'll do that
14:53:55 jaypipes stephenfin: I don't mind that detail.
15:05:54 kashyap stephenfin: Yeah, it comes useful for that poor soul who will look at it 5 years down the line
15:14:03 melwitt lyaaaaaaaaarwood: could you please hit this again? pike change has merged https://review.openstack.org/#/c/561613/
15:15:27 melwitt dansmith: could you please look at this stack of two backports for ocata? these and the one ^ are the last needed for the ocata release https://review.openstack.org/#/c/560162
15:17:39 dansmith ack
15:19:37 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Support initial allocation ratios https://review.openstack.org/552105
15:19:57 lyarwood melwitt: done
15:20:17 melwitt mriedem: what do you think of this approach for fixing the ceph job? frickler is trying something different to check the target branch to determine "if pike uca" https://review.openstack.org/#/c/563870
15:20:55 melwitt thanks lyarwood
15:23:08 mriedem melwitt: since stable/pike devstack uses the ocata UCA, and rocky now uses the queens UCA, and devstack-plugin-ceph is branchless, this seems appropriate
15:24:36 melwitt mriedem: k, cool. just wanted to make sure stable/queens won't be changing which UCA it uses in the future (makes sense that it wouldn't change)
15:24:56 mriedem it could change, but likely wont
15:24:58 kashyap Does anyone with Parallels / Virtuozzo experience, do you know if QEMU Guest Agent is required to set password in Nova?
15:25:18 mriedem kashyap: you'd have to reach out to mnestratov
15:25:42 kashyap mriedem: Yep, checking with one of his colleagues
15:25:45 mriedem https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_CI
15:25:47 melwitt cool
15:25:55 kashyap As Maxim normally doesn't seem to hangout here, only occasionally
15:28:16 kashyap None of the contacts are on IRC (neither on FN, nor on OFTC), I'll email them probably
15:37:24 kashyap Sent
15:38:06 openstackgerrit Merged openstack/os-vif master: Trivial: Update pypi url to new url https://review.openstack.org/563246
15:39:56 openstackgerrit Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597
15:40:52 TheJulia preparing to spawn in order to facilitate the actual lock of the node resource. Thoughts would be appreciated since we somehow need to flag the node as in use for any other users of ironic's API prior to attaching the vifs.
15:40:52 TheJulia Greetings nova folk, we're currently looking at an issue with ironic virt driver where due to the need for networking information for block device mappings, we end up getting called for vif attachment actions prior to a node being reserved in the spawn action by our virt driver. We're pondering two options, explicitly check during a vif plugging action, or adding a new virt driver call that would be along the lines of
15:41:12 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI Fibre Channel volume adapter https://review.openstack.org/526094
15:41:13 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot https://review.openstack.org/543023
15:41:14 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053
15:41:16 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300
15:42:38 melwitt jbernard: hi, we're trying to fix the ceph job that's failing 100% on master, would appreciate your review https://review.openstack.org/#/c/563870
15:43:04 jbernard melwitt: certainly
15:43:12 melwitt thanks!
15:43:38 jaypipes TheJulia: I'm confused why vif setup actions are being called prior to the node being reserved.
15:44:12 melwitt same
15:44:27 jaypipes TheJulia: I would think that setup_networking_on_host() would only happen after Ironic has notified the Ironic virt driver that the node is ready for provisioining?
15:47:27 TheJulia jaypipes: melwitt: let me grab the link for the change so we can discuss this with more information
15:47:39 TheJulia between three other conversations :(
15:48:19 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_BLOCK_LM_WITH_VOLUMES_VERSION https://review.openstack.org/563984
15:48:20 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_NUMA_VERSION_PPC https://review.openstack.org/564010
15:48:21 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: Drop BAD_LIBVIRT_NUMA_VERSIONS https://review.openstack.org/564011
15:48:22 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop BAD_LIBVIRT_CPU_POLICY_VERSIONS https://review.openstack.org/564012
15:48:23 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_PARALLELS_SET_ADMIN_PASSWD https://review.openstack.org/564013
15:49:09 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290
15:49:26 kashyap (Damn, missed the 'libivrt' prefix for one of the commits; will fix it after I figure out to fix the 2 failing unit tests.)
15:50:56 TheJulia melwitt: jaypipes: This is the change that changed the behavior https://github.com/openstack/nova/commit/23d935b3a60741ddb52f076ffeacde9c37f17c8c which should hopefully shed light as to why
15:52:12 melwitt oh, I remember that now
15:53:58 jaypipes TheJulia: gimme a bit to read the original review.
15:54:19 TheJulia jaypipes: no worries, 2 other conversations and a meeting shortly :(
15:55:00 melwitt IP is needed for the volume backend (or some volume backends require it)
15:55:57 TheJulia Correct, as some do IP level filtering on inbound iscsi connections
15:57:23 melwitt so the vif plug is the problem right? I would think you could get the IP early but wait to plug the vif until the normal time
15:57:58 melwitt (until after it's reserved) or would that not help?
15:58:23 openstackgerrit Merged openstack/nova master: Test case: traits don't sync if first access fails https://review.openstack.org/558066
15:59:50 TheJulia Well, getting the IP earlier would help, I think but there is a caveat there I need to try and remember around vif behavior
16:01:31 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Proxy is_volume through DriverBlockDevice https://review.openstack.org/564017
16:01:42 efried mriedem, esberglu, TheJulia: ^^
16:02:03 melwitt what I mean is decouple the two (creating port vs plugging vif). because that patch moved both of them earlier, so I was thinking maybe decoupling them to leave the port create earlier but do the vif plug later (back to the original place). I need to look at it more to see if what I'm saying makes sense or not
16:03:57 melwitt oh, all prepare_networks_before_block_device_mapping does is plug vifs. it doesn't create the port
16:04:36 melwitt hm, I didn't think vif plugging had anything to do with getting an IP address. I thought that was connected to the port creation
16:16:30 TheJulia efried: I completely forgot about that *blink* *blink*
16:16:38 TheJulia feels like a lifetime ago
16:17:16 melwitt TheJulia: I see that the patch gets the IP address from the attached vif from ironic. is there some reason why we couldn't just use the IP address from the neutron port instead of attaching the vif early? https://developer.openstack.org/api-ref/network/v2/#show-port-details
16:17:46 jaypipes melwitt: it's not really port creation that is needed. it's IP allocation.
16:18:04 jaypipes melwitt: but if that's what you mean by port creation, then yes, decoupling those things would be ++
16:18:24 melwitt okay, so with ironic driver we don't get an IP when we create a port in neutron? or do we not even create a port in neutron when ironic driver?
16:18:39 jaypipes melwitt: as with most thing neutron, it depends :)
16:19:16 TheJulia heh
16:19:35 jaypipes melwitt: if the subnet upon which the port resides uses DHCP, then the IP is doled out to the port after the port is set up on the host.
16:19:47 TheJulia I think if we could get the IP address in advance then ++++++ but I'm having strong deja vu, I just can't place it at hte moment
16:19:53 melwitt okay. yeah, from what I understand, creating the port in neutron will allocate the IP(s). plugging the vif will just attach the instance to the network. so I was thinking can we decouple that and get the IP from neutron instead of getting it from ironic by way of the vif
16:19:56 TheJulia uhg, yeah
16:20:04 TheJulia which means the port has to be plugged to have correct dhcp information
16:20:07 jaypipes melwitt: in TheJulia's case, I think that basically the only way that it will work is if an IP is statically assigned ahead of time.
16:20:42 jaypipes melwitt: but I'm definitely no expert in Neutron-isms. Perhaps sean-k-mooney is a good person to ask about this if not mriedem.
16:20:44 melwitt jaypipes: oh, I see. I wasn't thinking of DHCP :(
16:21:57 jaypipes melwitt: in this specific case (the hitachi/fujitsu NFS/SAN thing) I would think that a statically-assigned IP address is really the only way it would work.
16:23:07 jaypipes melwitt: otherwise, the connector info would need to essentially say "this storage NIC is gonna get some IP address in this CIDR but I don't know what that specific IP address is right now". And I'm pretty sure no such affordance is possible in the volume connector info ;)
16:23:12 TheJulia jaypipes: as in operator pre-creation of the ports, definition of said vifs upon spawning a node?
16:23:17 melwitt yeah. huh. I guess that means that any deployment using DHCP must be creating neutron ports in deferred mode or no IP allocation mode?
16:23:51 jaypipes TheJulia: yes, which is a very common thing already.
16:24:16 jaypipes TheJulia: and passing nova boot --nic port=<UUID> (or whatever the magical incantation is...)
16:24:19 TheJulia jaypipes: that is correct, we can't say "later" for the volume connection info because it gets shipped all the way to the backend storage upfront
16:24:33 TheJulia hshiina|afk: ^^^ thoughts
16:24:44 jaypipes TheJulia: although saying "laterz dude" in the connector info would be, well, amaze-balls.
16:24:57 TheJulia jaypipes: totally

Earlier   Later