Ian Denhardt

My thinking is for 0.4 we just write up a quick blurb saying that downgrade isn't really tested or supported and leave it at that. We can consider outright removing...

@henn, not sure exactly what the right solution is, will require some thought. we ought to find some systematic way of handling these, rather than checking everything individually. One thing...

Ok. In that case I'll probably just drop the check as part of removing the legacy stuff, and we can do the rest of the fix for this separately.

Ideally, though I'm not sure how involved that would be.

Yeah, I also don't really see this as a problem.

+1 for making using HIL less error prone. If it's just about preventing doing things by mistake (rather than a fundamental security/integrity issue), we can implement this as a client...

I took two traces of hil --help; this one is from the moc server: [kzn-trace.txt](https://github.com/CCI-MOC/hil/files/2497428/kzn-trace.txt) This one is from my laptop: [local-trace.txt](https://github.com/CCI-MOC/hil/files/2497431/local-trace.txt) The latter is taking ~0.4 seconds vs. ~1.3...

I agree, I think we should split the client lib off into a separate python package. For the immediate term though, it's worth noting that it shouldn't break anything to...

Note that way back when I started the work on this in the `distro-packages` repo, I'd envisioned doing distro-quality packages, which would mean also individually packaging all of our dependencies...

So would this just be a variant on list all nodes where we also get a field telling us what project they're in? Have you tried parallelizing the individual list_project_nodes...