Shutting down the node before detaching network

[mosayyebzadeh]

We should shut the node down and wait before we can detach the network from it.

[naved001]

We need to do this because, in our specific use case, we need to power off the nodes before disconnecting the networks because otherwise their iscsi disk where they boot from might get corrupted (@apoorvemohan correct me if I'm wrong).

We can't use the maintenance service because it can only power off the node during the project detach call which only runs after networks have been removed.

[zenhack]

You've got a warning from pycodestyle. Other than that, this looks fine to me.

That said, I feel a little odd about maintaining this in the "examples" folder, as it's a script that you guys are clearly actively using and developing in production. There's a bit of cognitive dissonance there.

[mosayyebzadeh]

You are right about keeping it in the example folder. It is not just an example. Do you have any specific folder in your mind to keep this there?

[naved001]

This isn't really HIL core stuff, so if not the examples folder then I think we should maintain it in the some other repo on cci-moc (moc-tools or something like that).

[zenhack]

Quoting Naved Ansari (2018-01-12 09:55:39)

This isn't really HIL core stuff, so if not the examples folder then I think we should maintain it in the some other repo on cci-moc (moc-tools or something like that).

+1

The examples folder really should be used for stuff that is useful as a reference. If you guys are going to tune this thing for real use, that means it's probably going to hit a different set of trade-offs than what we want as a simple demo.

For example: I'd recommend using an actual database, instead of a custom file format. ACID guarantees and all that.

[SahilTikale]

Considering that I also have related HIL optimization scripts which cannot be directly considered as HIL core stuff, I think it is a good time to think about a separate folder called HIL_Contrib which will contain pointers to developer's repo that would contain use-case specific optimizations like this one.

Others can use it at their own risk without any validation or blessing from the HIL team. We should state that explicitly in the README of the folder that this folder is just a pointer of what other possible things can be done with HIL, without taking the responsibility of maintaining those code-bits as HIL changes. Contract to maintain this use-case specific code remains between the users and the developers. HIL only provides information in this folder.

Let me know your thoughts @naved001 @zenhack @mosayyebzadeh @knikolla

[naved001]

@SahilTikale How about we put a README in the examples folder, which can point to HIL developer's repos? I feel that the examples directory is pretty much like what you described HIL_Contrib to be, and I think it makes little sense to have yet another directory for uncore stuff.

And about this PR: @mosayyebzadeh I think we would have to close this, because the changes in the leasing script are going to be very specific to our environment in kumo, so it doesn't make sense to maintain it here. It's no longer just a leasing script for HIL.

[zenhack]

We could also just have a wiki page that folks can edit with random stuff, and point to that from the README. that way we don't have to do prs when folks create a new tool.

[zenhack]

And I think I agree that it probably makes sense to just close this.

[mosayyebzadeh]

I agree, we should close this PR.