Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
15:11:16 mriedem that's why at my old dept in ibm we had an essex cloud, a folsom cloud, and a juno cloud at some point
15:11:17 mnaser bofh public cloud
15:11:18 mnaser :p
15:11:41 mriedem writing tooling on top was super fun!
15:12:08 mnaser i feel like it would be fun to deploy essex from essex-eol just for the fun of it and see how far we come
15:12:09 mnaser :p
15:12:10 mriedem "why doesn't this work? oh yeah, nova-net on essex has that one bug...let me code around that in my jenkins job..."
15:13:01 mriedem mnaser: clearly you have too much time on your hands :P
15:13:22 mnaser ahaha
15:13:22 sean-k-mooney our current private cloud is only using 10 of the 40 nodes its ment to be deployed on so i can keep the old run running while i bring up the new one.
15:13:43 mnaser well hey mriedem if it's cool to know work is actively wanted/needed
15:14:03 mnaser https://blueprints.launchpad.net/nova/+spec/deprecate-file-injection => literally customer right now "upon rebuild, is there a way to send userdata script?"
15:14:32 fallenour_ YAY PEOPLE!
15:15:04 fallenour_ has anyone ever seen an issue where config applies ceph osd devices, and registers OSD devices, but doesnt show them in openstack-dashboard under hypervisors for the compute nodes?
15:15:33 fallenour_ deployment method: conjure-up ; cloud version: xenial:pike
15:15:47 mnaser fallenour_ - please have a look at the topic, i'd suggest #openstack :)
15:16:05 mnaser and given that seems to be deployment tool related, i'd suggest #ubuntu-server
15:16:18 sean-k-mooney fallenour_: as what? they should not appear in localstorage. its ceph...
15:16:37 mnaser thanks superdan :D
15:17:04 fallenour_ mnaser: yes, I understand, I am trying to create a massive online development infrastructure as a service for free, so it koalafies? and its a nova issue o.o
15:17:42 mriedem mnaser: cool - keep in mind the input we got in the ML asking if we should do that got that into the spec :)
15:17:48 mriedem so keep it coming
15:17:49 superdan fallenour_: this channel is for nova development, not getting help with nova (see topic)
15:17:58 fallenour_ sean-k-mooney: I understand that, thats the issue, its configured to use ceph, but its only showing I have 140 gb of storage per node, and I hsould have 2.19 tb on the stack
15:18:23 fallenour_ superdan: roger, will take it to pms. My apologies. hard for me to do anything with it if baseline isnt working for me though :(
15:18:43 mnaser fallenour_ the problem isn't nova, the problem is the deployment tool not doing the job, hence suggesting #ubuntu-server :)
15:19:24 sean-k-mooney fallenour_: im guessing your missing the nova config option that make nova use rbd for all guest storage
15:19:45 sean-k-mooney fallenour_: with that set it will report 2.19TB pernode and be equally wrong
15:23:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform instance.resize_revert notification https://review.openstack.org/396811
15:27:44 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add a warning in 'nova-manage cell_v2 delete_cell' https://review.openstack.org/513771
15:57:44 openstackgerrit Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149
15:58:35 fried_rice cdent gibi Okay, I reworked ^ to "pass" with comments, and extracted it from alex_xu's chain so it can merge without it.
15:59:29 cdent does anybody remember a bug (and fix) where a disk related cache being wrong could cause the disk could go away, especially after a resize?
15:59:40 cdent fried_rice++
16:01:12 cdent I have a memory of that, but haven’t got enough info to search well
16:01:20 leakypipes gibi: hey. so on the "re-parenting a resource provider" thing.
16:01:38 leakypipes gibi, superdan: I think it would be easier to just prevent re-parenting on update for right now.
16:01:59 leakypipes and add in functionality to re-parent at some later time when we can deal with that potential use case.
16:02:40 fried_rice leakypipes Agree almost totally. We ought to be able to set the parent of a RP if it's currently null.
16:02:48 cdent mdbooth: you remember that bug (a few lines up)?
16:02:54 fried_rice Sorry if that's what you meant by "re-"
16:03:27 superdan leakypipes: I was kinda thinking that was going to be a really useful thing to have in the early days,
16:03:44 superdan leakypipes: for things like re-parenting a NIC provider underneath a numa node when we start having them, etc
16:03:45 fried_rice Dangit, I was literally just typing, "I can't think of a scenario where we would *need* to truly reparent..."
16:03:50 superdan without losing everything
16:04:11 fried_rice superdan That would be during an upgrade, kind of thing?
16:04:36 fried_rice superdan We wouldn't want to do that just on the fly while running, would we?
16:05:22 superdan fried_rice: it could come as a result of rolling past the commit/release where we add another layer of topology, yeah, or it could be part of a bugfix where we were improperly hanging things at places in the tree, or what4ver
16:05:49 superdan I just thought this was intended to be a fundamental operation we could do to avoid having to do expensive recalculation of allocations when we add functions, is all
16:06:55 fried_rice We ought to at least be able to disable it in this patch and work it in a later one, nah?
16:07:17 fried_rice if we decide we do want some reparenting affordance in q
16:08:41 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Fully destroy instances during _hard_reboot https://review.openstack.org/400384
16:09:49 superdan fried_rice: we'd need to implement it before we do anything that could change topology I guess
16:10:57 leakypipes superdan: right.
16:10:59 fried_rice superdan Agreed. If we just implement "set parent if null", then we can at least "change topology" from "flat".
16:11:21 fried_rice But we don't need to be able to change topology beyond that in the near term, IMO.
16:11:38 finucannot sean-k-mooney: You about?
16:12:21 superdan fried_rice: I dunno, what are the first few nested providers we expect? numa nodes, and SRIOV nics /VGPUs right?
16:12:41 fried_rice superdan reckon so, yeah.
16:12:54 superdan let's say we expose a VGPU for something like vmware or xen,
16:12:54 fried_rice superdan Early in R, network bw stuff mebbe.
16:13:06 superdan but we don't have numa information until a week later
16:13:14 superdan then we have to reparent the vgpu provider under the numa node
16:13:16 sean-k-mooney finucannot: yes
16:13:38 fried_rice superdan Oh, are we actually concerned about being able to rework existing deployments on the master branch?
16:13:53 superdan fried_rice: always
16:14:07 finucannot sean-k-mooney: Quick one - I've got two identical PCI devices and I want to disable one of them at least from a nova perspective. Any ideas on how that could be accomplished?
16:14:15 finucannot Only got access to the host OS - not the BIOS
16:14:37 fried_rice finucannot [pci]passthrough_whitelist by PCI address
16:15:02 finucannot fried_rice: Oh, can you do PCI address too?
16:15:03 cfriesen echo 0 > /sys/bus/pci/slot/$N/power
16:15:09 fried_rice finucannot yup
16:15:34 finucannot cfriesen: That's what I tried but alas, no power file
16:15:36 fried_rice finucannot e.g. https://docs.openstack.org/nova/pike/admin/pci-passthrough.html#configure-pci-devices-compute
16:15:59 sean-k-mooney finucannot: pci adress was the first thing the whiteliset support i think
16:16:30 fried_rice finucannot You can also put * in for any of those.
16:16:52 finucannot fried_rice: Serious case of RTFM there. Thanks for the link :)
16:17:01 fried_rice finucannot yahyoubetcha
16:17:47 sean-k-mooney finucannot: you needed to "disable" it so that openstack would not use it right and not for some other reason
16:18:57 finucannot sean-k-mooney: I want disable the PCI devices on node 0 to make sure non-PCI-needing devices use node 1 CPUs
16:19:20 sean-k-mooney finucannot: ah ok
16:19:27 sean-k-mooney you can do that another way
16:19:33 finucannot Validating that PCI weigher spec from last cycle again, but this time without a server beside me that I can unplug the NIC from :)
16:19:47 finucannot sean-k-mooney: Do tell
16:20:23 sean-k-mooney the numa node value in sysfs is writeable so you can lable the device as part of the other numa node or set it to -1 which means no numa affinity
16:21:32 finucannot Hahaha
16:21:47 leakypipes superdan: first nested resources are PFs which are children of the compute nodes.
16:21:49 finucannot That's even better though, because it can be scripted
16:21:56 finucannot from the perspective of automating this in the future
16:22:21 superdan leakypipes: right, and then we'll want them under numa nodes ASAP, so -> reparent
16:22:34 sean-k-mooney finucannot: true but you should check if the change get reflected into virsh nodedev list
16:23:35 sean-k-mooney fried_rice: intra master is the same as stable brance minor upgrades
16:24:17 fried_rice Which I *guess* is why we need microversions within a release.
16:24:21 finucannot fried_rice, cfriesen, sean-k-mooney: One more q: I noticed that adding 'physical_network' to the 'passthrough_whitelist' option and specifying '"device_type": "type-PCI"' for 'alias' resulted in 'type-PF'
16:24:22 superdan fried_rice: we have always done this.. like mriedem said earlier, each commit is a release
16:24:41 fried_rice superdan Good to know. I truly didn't realize that.
16:24:44 finucannot I haven't tried it again and know I shouldn't have set 'physical_network', but does that ring a bell?
16:25:19 mriedem i say lots of things
16:25:21 finucannot Want to make sure it's not a "feature" before I go tracking down a possible bug
16:25:24 sean-k-mooney finucannot: if you dont have vfs allocated that is expected

Earlier   Later