Expected to see both child devices in "Non-Racked Devices" on rack at step 6. The first with parent set and the second without parent set.
At step 4 and 5 the first child device is shown in the "Non-Racked Devices" as expected. At step 4 with no parent and at step 5 with the parent device set. Upon creating the second child device in step 6 - if the first child device is already placed inside a device bay it disappears from the list of "Non-Racked Devices" and only the second child device is show.
Confirmed on netboxdemo.com running version 2.8.1 as well.
Expected to see both child devices in "Non-Racked Devices" on rack at step 6. The first with parent set and the second without parent set.
This is not correct. After step 5, the device is "racked" in the bay of the first device, hence why it does not show in the "Non-Racked" devices.
Just to confirm.
If so, this looks like a cache invalidation problem as removing the second child does not replace the blade back in the unrack section. Additionally, editing the blade will also remove it.
Cache invalidation problem sounds very reasonable.
Indeed the process is correct. I have captured some screenshots to demonstrate. If I in step 4 create two child devices (Blade1 and Blade2) and rack them as unracked devices they show up as expected:

If I then place Blade1 in device bay 1 of Chassis1 I get this:

If I then place Blade2 in device bay 2 of Chassis 1 I get this:

But as soon as I add a new unracked child device, Blade3, to the rack - both Blade 1 and 2 disappear:

Which behaviour is the correct one I am not certain of. From your comment the fact that Blade 1 and 2 remain in unracked devices seems to be the incorrect behaviour.
Let me know if you need more information.
@jeremystretch I am a little confused about the intended behavior here. As I recall once a child device is installed in a racked parent, that child is also considered racked. However, the non-racked devices table includes a parent column. I assume this was intended to cover a case in which a parent is not racked and thus the children should show up in the table too? If that is the case, I think we have a separate bug, because the existing query would not allow the inclusion of the child devices in such a case because of parent_bay__isnull=True:
nonracked_devices = Device.objects.filter(
rack=rack,
position__isnull=True,
parent_bay__isnull=True
).prefetch_related('device_type__manufacturer')
As for the actual caching issue here, it appears to be related to the use of a related name (parent_bay) with an isnull option. I have raised #353 upstream.
Blocked: Suor/django-cacheops#353
As far as what @lampwins mentions about the Parent column, I think once a child is put in a bay, I think we should consider it "racked", at least to the parent, so we might want to ditch the Parent column. If no one has objections, I am going to open a issue for that one
Looks like this got fixed upstream, we will just need to wait for the next release of cacheops
I ended up just cleaning up the table to include both 0U and child devices. Did away with the parent_bay__isnull filter on the queryset so that both types of device are included.
On v2.8.9, even after wiping Redis to clear the cache, I see all of my child devices (whose parents are racked) showing up in Unracked Devices. Looking at the commit for this issue, 9d243103f494923ed97538ad866526688d4809e9, it seems this is now intended behavior, but it's very not ideal for my use case. A 0U PDU is an unracked device, but a blade server is not. It's racked, inside the parent device. Now I can't distinguish devices which are not yet installed or are missing necessary rack elevation data, from devices which are correctly installed inside a racked parent device.
If you think the other way is better, it may be best to open a FR for it instead of posting in here.
Make sure you provide ample justification however.