[15:12] smoser: whne you have a chance, could you please review/approve: [15:12] https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 [15:12] https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions/+merge/147460 [15:12] thank! [15:17] roaksoax, 2 comments, that i'll add to review. [15:17] smoser: cool thanks [15:19] review updated. [15:19] sorry that took so long [15:19] smoser: thanks!! no worries :) [15:22] smoser: updated! [15:55] roaksoax, my only comment is on the drop of 'maas-commission' user [15:55] why did that go? or am i just reading it wrong [15:56] smoser: because it adds more complication on replacing users with iLO3 [15:56] smoser: and I'm not sure whether it would work [15:57] well, it added more complication in *all* cases. [15:57] but it was deemed necessary/important [15:57] smoser: right, so I don't know whether you can replace a user in iLO3, and don't have HW to test it [15:58] smoser: either way, a different password is created [15:58] smoser: so I think it no longer makes sense to have 2 different users [15:59] smoser: that's one of the things that created issues at the drill [16:00] well you dont have to *replace* a user, do you? [16:00] you delete then add, or add then delete. [16:00] right? [16:00] i understand that we dont hav a way to easily test this, but that should'nt be justificaiton for removing code that was deemed necessary previously. [16:02] smoser: it was deemed necessary to differentiate in what stage the user was added right? [16:03] there was no other reason why we did that [16:04] just only to differentiate what stage added the usre [16:04] is that still necessary? [16:15] rvba: around? [16:17] roaksoax: hi [16:17] What's up? [16:17] roaksoax, i believe it was deemed necessary to avoid deleting a 'maas' user (and corrupting maas usage) if a node booted into enlistment. [16:17] i think. [16:19] rvba: so, since bigjools is in leave... I was wondering whether you could help us get the GenericIpAddressField thing in MAAS rather than in django [16:19] rvba: the technical board adviced to implement that on the maas side rather than on the django side [16:19] rvba: and we need that for sru [16:22] smoser: we don't delete IPMI users actually. And we don't correct cause if the node boots into enlistment/commissioning, if it has been previsouly added to MAAS, then it will use the credentials it has there regardless of whether they are maas-commission or maas username's [16:23] roaksoax: too bad we can't SRU Django. Technically, this should adding GenericIpAddressField in MAAS should not really be complicated (but I'll look into it). What about the other feature from 1.4 that we use? [16:23] rvba: the other 2 patches are good to go [16:23] rvba: but will require external testing. The only thing is to move the genericIPAddressField to maas instead of django [16:24] "the other 2 patches are good to go" thank goodness for that! [16:25] :) [16:25] roaksoax: I'll have a look at this tomorrow. Can you file a bug for this please? (maybe there is already one…?) [16:26] rvba: sure I'll do that if there's not one :) [16:26] ta [16:31] roaksoax: please add a reference to the tech board decision in the bug's description. So that everyone will know why we're doing this. [16:31] rvba: ack! [16:49] roaksoax, i thought that the general flow/idea was: [16:50] * if a system boots into enlistment, create a new ipmi user 'maas-commission' [16:50] that was only to be used for the commsisioning turn on (and would only be ever used for that) [16:51] * in commissioning (after admin acceptance of node), the 'maas' user is adde,d and from there out, the 'maas' user is used for power control [16:51] by removing the 'maas-commission' user, you potentially report to MAAS-SERVER-X credentials from MAAS-SERVER-Y. thats at leas tone fallout from removing the maas-commission user. [16:52] but thats probably not that big of a deal. [16:52] the point is, though, that we very explicitly decided to use this temporary "first-commission only" user. [16:52] and you're dropping that. [16:52] Daviey, was involved in that discussion, perhaps he has other thoughts. [16:57] smoser: we never remove the maas-commission user, we replace it [16:57] or at least that's how it works on iLo1 [16:58] smoser: the only difference was that there was a different user name, and obviously a different password [16:58] roaksoax, my concern (possibly un-founded) resulted from readingg lines 31-35 at https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 [16:58] so if the node had user 'maas' and then for some reason commissioning run, it would have created a new user/[pass and updated maas, or if it failed to update, it would have a different user/pass in the bmc than what it is stored in maas [16:59] not commissioning, enlistment. [16:59] smoser: right, so it is exactly the same case [16:59] the 'maas-commissioning' was explicitly there for enlistment [16:59] smoser: I'm not emotional either way.. that just seemed a sane way [17:00] as enlistment potentially (i think very unlikely) results in accidentally breaking something for someone [17:00] (ie, if they accendentally pxe booted off a new network... something i thought then was un-likely) [17:00] look, if the node is set to 'Ready', and it enlists again, it will change the creds in the BMC either way [17:00] well, that was slightly different [17:00] not if it enlists to a new maas. [17:01] or a maas it did not intend to enlist to [17:01] smoser: in iLO3 yes [17:01] i mean [17:01] iLO1/2 yes [17:01] it would have *replaced* the user regardless of what user it would have been [17:01] smoser: so if the BMC had user 'maas', and it enlisted against any other MAAS, the 'maas' user would have been replaced with 'maas-commission [17:02] previously, that would not have happened. [17:02] smoser: it would [17:02] at least that was not what we intended. [17:02] the goal before was that enlistment would create a maas-commission user [17:02] and only ever break or change a user named 'maas-commission' [17:02] smoser: yes, and we agreed that that user should be *replaced* [17:03] i dont think "replaced" matters. [17:03] smoser: exactly, which means that maas-comission or only maas doesn't matter either way [17:03] surely you're not suggesting that previously "maas-commision" would "replace" "maas" user [17:03] as that would be stupid, and the same as deleting. [17:03] smoser: that would have happened if you would enlist that machine to a different MAAS [17:04] smoser: if you enlist the machine to a different maas, it will replace the existing 'maas' user with 'maas-commission' [17:04] that's how it [17:04] that's how it always worked [17:04] because we decided to have a temporary user/password combination that would later be replaced by the 'maas' user [17:05] but then it was *replace* [17:06] roaksoax, you're missing something. or i'm missing something [17:06] i dont care what happens on commission [17:07] smoser: so 1. enlistment would create maas-commission in User3. 2. commissioning would replace User3 (maas-commission) with user 'maas'. If that machine is enlisted in another MAAS, the User3 (whjich was previously 'maas') would be replaced by 'maas-commission' again [17:09] well, that was a bug then. [17:09] smoser: so using only 'maas' makes more sense [17:10] well, other than it is destructive [17:10] in enlistment [17:10] which is why we had this 'maas-commission' user [17:10] but you're dropping that. [17:10] even if the implementation was broken, it was still there in concept, and now you're removing it. [17:11] if its known broken, i'd just make sure we remove all 'maas-commision' strings anywhere. [17:15] smoser: well then the whole IPMI stuff needs re-factoring to support those 2 things differently [17:16] smoser: but won't be able to say it works 100% until i can test that with iLO3 === matsubara is now known as matsubara-lunch [17:20] roaksoax, well, for now then i think its probably best to pull it completely [17:20] smoser: ack!