[17:37] <cjwatson> kentb: this bug is turning into a bit of a nightmare, isn't it - in all fairness I think I have to say that it's currently at risk for 12.04.2
[17:37] <cjwatson> kentb: (I'm on leave tomorrow, which doesn't help)
[17:38] <kentb> cjwatson,  ok. indeed it is.  I'll talk to Dell about when they expect to see these drives start selling and whether or not we need to come up with a plan B
[17:41] <cjwatson> kentb: Do you think it might be possible for me to get remote console access to a box matching the one you're using, somehow?
[17:41] <cjwatson> (And yeah, I realise I dropped the ball between October and now ...)
[17:42] <kentb> cjwatson, let me find out wrt to console access...would it help if we could (possibly) express ship a drive to you?
[17:47] <cjwatson> Difficult - I have very little study space and currently don't have a spare machine to put a drive in
[17:48] <cjwatson> We need to move house really, but I've been working too hard to prepare for it, so slightly chicken and egg :)
[17:48] <cjwatson> Maybe in the next place I should look at rack + KVM
[17:50] <infinity> Every time I move, my inner nerd says "I should totally make room for a 19" rack".  I never do.
[17:54] <ogra_> mak room, i have a spare one to give away !
[17:54] <ogra_> *make
[17:57] <kentb> cjwatson, we're looking into console access but it may not be in enough time for you (we need to do that, anyway for the future).
[18:03]  * kentb heads to lunch
[20:53] <danjared> cjwatson: are you still looking to see if you can get remote access?
[21:03] <danjared> kentb: Custom Solutions would be able to provide remote access. I just need to patch some cables.
[21:10] <kentb> danjared, ok. cool.
[23:15] <cjwatson> danjared: That'd be fantastic, thanks.  Due to holiday I won't be able to make use of it until Monday, but if it's available by then I can get right on it.


[04:10] <Will> I have maas installed on an orange box. using juju I can load OpenStack. I want to use maas by itself to install/boot several nodes. However, on the nodes page I select a few nodes and run the bulk action but always get an error message: The action "Start selected nodes" could not be performed on 1 node because its state does not allow that action.
[04:11] <Will> Any idea about what state it is taking about?
[10:44] <mup> Bug #1415493 changed: MAAS raises 'Cluster Master' (some UUID); no connections available' when changing a cluster interface <MAAS:Invalid> <https://launchpad.net/bugs/1415493>
[10:50] <mup> Bug #1415493 was opened: MAAS raises 'Cluster Master' (some UUID); no connections available' when changing a cluster interface <MAAS:Invalid> <https://launchpad.net/bugs/1415493>
[10:56] <mup> Bug #1415493 changed: MAAS raises 'Cluster Master' (some UUID); no connections available' when changing a cluster interface <MAAS:Invalid> <https://launchpad.net/bugs/1415493>
[16:12] <mup> Bug #1455560 was opened: when I move servers between tags, list in nodes view is out of sync <oil> <MAAS:New> <https://launchpad.net/bugs/1455560>
[20:34] <elurkki> What could be the problem when Commisioning new KVM virtual machine with MaaS the virtual machine gets IP nicely from DHCP, uses it, prints it on the screen, but the IP is not added to the Node. The IP can not seen in the node and from this DNS is not updated.
[20:35] <elurkki> The IP can be found from "Discovery Data" list aka. lsww:setting: ip: ip, value: <IP_ADDRESS>
[20:35] <elurkki> Thanks a lot for any tips
[20:36] <mup> Bug #1455643 was opened: 1.8 regression: Node listing extends past the edge of the screen <MAAS:Triaged by ubuntudotcom1> <https://launchpad.net/bugs/1455643>
[21:16] <mup> Bug #1455656 was opened: 1.8beta6: not filter for tags doesn't work <oil> <MAAS:New> <https://launchpad.net/bugs/1455656>
[21:18] <ahasenack> elurkki: commissioning is something temporary, after that the machine changes into Ready and gets powered off, so no IP
[21:18] <ahasenack> elurkki: do you get that far? To the Ready state and power off?
[21:21] <elurkki> There I get yes
[21:21] <bleepbloop> Is there a way to tell how many disks maas thinks a machine has?
[21:21] <elurkki> ahasenack: Should the MaaS handle the IP to the DNS ?
[21:22] <ahasenack> elurkki: during commissioning it will use an IP from the so called "dynamic range" that you configured in the cluster
[21:22] <ahasenack> elurkki: but after all that, with the machine Ready and off, the IP is free
[21:22] <elurkki> ahasenack: Yep, I can see it gets the IP from DHCP pool
[21:22] <ahasenack> elurkki: you need to start it
[21:22] <elurkki> Testing again
[21:22] <ahasenack> elurkki: once you start it (or deploy, in maas 1.8 terminology), it will get an OS installed and an IP from the "static range". That will be in DNS
[21:23] <elurkki> Commisioning with fast boot now
[21:23] <ahasenack> no
[21:23] <ahasenack> commissioning is only done once
[21:23] <ahasenack> if it's in the Ready state, you don't need to commission anymore
[21:23] <elurkki> Can not boot it
[21:23] <elurkki> Hangs in the PXE
[21:23] <elurkki> And timeouts
[21:24] <elurkki> So thought to commision it again
[21:24] <ahasenack> I thought you said the machine was in the "Ready" state
[21:24] <elurkki> It is
[21:24] <elurkki> Power OFf
[21:24] <elurkki> If I power it on
[21:24] <ahasenack> these are two things: Ready, and powered off
[21:24] <ahasenack> if it's Ready, it means it commissioned correctly before
[21:25] <elurkki> and the machine is powered off in ready state I assume ?
[21:25] <elurkki> pysically powered off
[21:25] <ahasenack> bleepbloop: in maas 1.7, go to the node page in maas and click on "discovered details", you will have to search a bit
[21:25] <ahasenack> elurkki: it's written in the node list page, it's a collumn. What does it say for this machine?
[21:25] <elurkki> Status: Ready
[21:26] <ahasenack> elurkki: ok, then select it and from the drop down action menu select "start"
[21:26] <elurkki> done
[21:26] <elurkki> "Deploying"
[21:26] <bleepbloop> ahasenack: okay, do you happen to know what canonical landscape looks for exactly there? I'm having an issue where landscape is attached to maas and is not seeing as many drives as there actually are
[21:27] <ahasenack> bleepbloop: are you sure it's drives, and not networks? That's what usually trips people (networks)
[21:28] <ahasenack> bleepbloop: there is one checklist item that wants both on a machine: two disks, and two nics. The later attached to actual networks (can be the same, but must be attached)
[21:28] <bleepbloop> ahasenack: the failing condition is "At least three machines with more than one disk have been commissioned"
[21:28] <ahasenack> bleepbloop: ok, then landscape will look for that hardware information from maas, in the "discovered details"
[21:28] <ahasenack> the disks need to be larger than 1Gb, and cannot be virtio disks
[21:28] <ahasenack> (if using a VM)
[21:29] <bleepbloop> Okay, they are all physical machines, I guess what is most likely messing it up is it is detecting one of the disks as 1gb even though it is larger
[21:29] <ahasenack> bleepbloop: there is a virtual disk that maas uses for commissioning, it appears in that output, but is ignored
[21:29] <ahasenack> it's a QEMU something something disk
[21:30] <ahasenack> bleepbloop: one other case I saw once was about raid disks
[21:30] <ahasenack> some confusion between the actual disks, and the raid device
[21:30] <bleepbloop> It is probably the raid disks, I have raid enabled, I'm guessing I should just completely disable raid for this case?
[21:30] <ahasenack> bleepbloop: is it a dell?
[21:30] <bleepbloop> It is 2 ibm's and an hp
[21:31] <mup> Bug #1455656 changed: 1.8beta6: not filter for tags doesn't work <oil> <MAAS:New> <https://launchpad.net/bugs/1455656>
[21:31] <ahasenack> bleepbloop: ok, try disabling raid
[21:31] <ahasenack> then commission again
[21:31] <ahasenack> if that still doesn't work, enlist again. I'm not sure commissioning picks up this kind of hardware change
[21:34] <bleepbloop> ahasenack: Will do, I don't have access to the hardware where I am right now, however I will definitely try that monday, thank you! Do you think it will be enough to tell the raid controller to treat each drive as a simple volume? I am only asking because it seems everyone has really struggled with completely disabling raid on this machine, its an IBM x3650
[21:35] <ahasenack> bleepbloop: all that matters in the end is what linux sees once it boots
[21:35] <ahasenack> bleepbloop: the code runs the "lshw" tool, you can try it somewhere else if you want
[21:35] <ahasenack> it two disks are shown as something like /dev/md0, then that will count as one disk only, and the checklist will fail
[21:35] <ahasenack> unless you have 4 disks ;)
[21:36] <ahasenack> bleepbloop: the two disks are required because one is used for the OS, and the other is used entirely for storage (ceph or swift)
[21:36] <ahasenack> so access to the actual disk is needed (the block device)
[21:37] <mup> Bug #1455656 was opened: 1.8beta6: not filter for tags doesn't work <oil> <MAAS:New> <https://launchpad.net/bugs/1455656>
[21:37] <mup> Bug #1455658 was opened: 1.8beta6: There is no documentation for the filter syntax <oil> <MAAS:New> <https://launchpad.net/bugs/1455658>
[21:37] <mup> Bug #1455659 was opened: 1.8beta6: No way to filter to find nodes that don't have any of a list of tags <oil> <MAAS:New> <https://launchpad.net/bugs/1455659>
[21:39] <bleepbloop> ahasenack: Gotcha, okay I will have to play around with a livecd boot on all of the machines and see what it is really seeing, so out of curiousity, if the machine has 3 drives which are all detected, will it use them all or just use 1 for os and 1 for storage?
[21:40] <ahasenack> bleepbloop: I think it will use the other 2 for storage
[21:40] <ahasenack> bleepbloop: we pass it a list of devices from /dev/sda to /dev/sdz, and the storage charm tries them all
[21:41] <ahasenack> of course, it won't wipe /dev/sda if that's where the OS is :)
[21:41] <ahasenack> s/wipe/use/
[21:41] <bleepbloop> ahasenack: very cool, okay thats really useful, does the os always get installed on the first one seen or is it smart about using the smaller one for the os and larger ones for storage?
[21:42] <ahasenack> bleepbloop: maas installs the OS for the autopilot,
[21:42] <ahasenack> bleepbloop: I believe it's very simple in that regard: something like alphabetical order of the block devices
[21:42] <bleepbloop> ahasenack: ah so thats pretty much up to maas at that point
[21:42] <ahasenack> right
[21:43] <ahasenack> juju asks maas for an ubuntu trusty machine, maas delivers
[21:43] <mup> Bug #1455658 changed: 1.8beta6: There is no documentation for the filter syntax <oil> <MAAS:New> <https://launchpad.net/bugs/1455658>
[21:43] <mup> Bug #1455659 changed: 1.8beta6: No way to filter to find nodes that don't have any of a list of tags <oil> <MAAS:New> <https://launchpad.net/bugs/1455659>
[21:43] <ahasenack> then the autopilot says what will be installed there in terms of services
[21:43] <ahasenack> I have seen a case where the machine had /dev/sda, /dev/sdb and /dev/nvmsomething
[21:43] <ahasenack> and /dev/nvm* was chosen for the OS
[21:44] <ahasenack> it was a high end ssd
[21:44] <ahasenack> had to customise a bit the installation step to have it use /dev/sda, which is what we wanted
[21:46] <mup> Bug #1455658 was opened: 1.8beta6: There is no documentation for the filter syntax <oil> <MAAS:New> <https://launchpad.net/bugs/1455658>
[21:46] <mup> Bug #1455659 was opened: 1.8beta6: No way to filter to find nodes that don't have any of a list of tags <oil> <MAAS:New> <https://launchpad.net/bugs/1455659>
[21:46] <bleepbloop> ahasenack: Interesting, really wish there was a bit more documentation on just how maas works, it does some stuff where it seems to try to abstract away as much stuff as possible from the user and leaves you wondering just what its going to do in a specific situtation
[21:49] <elurkki> ahasenack: This node which is trying to "Deploying" just hangs to the "Booting under MAAS direction". Probably my MaaS server just is not capable enough and does have something configured wrong.
[21:49] <ahasenack> bleepbloop: I think in general it's thought that if you have dozens of machines, grouped somehow, they are bound to be similar
[21:50] <ahasenack> elurkki: yeah, something else is wrong then, sorry
[21:50] <ahasenack> elurkki: did the vm do anything else since you clicked on start?
[21:50] <elurkki> ahasenack: Oh, after 7th boot try it started to go forward from the PXE
[21:50] <ahasenack> like, install the OS? You would have seen a big wget output here it downloaded images
[21:51] <ahasenack> elurkki: it's a pretty straight forward setup, we use it all the time (maas with VMs), it's probably a networking issue of some kind
[21:51] <elurkki> ahasenack: It just powered on, acquired IP from DHCP and then started to try PXE
[21:51] <ahasenack> don't forget to disable dhcp on the network where you attach maas to, for example
[21:51] <ahasenack> the only dhcp server should be maas
[21:52] <elurkki> Yes, there is only MaaS DHCP
[21:52] <bleepbloop> ahasenack: Well thanks for your help, I'll give disabling the raids as much as possible a go and hope it works!
[21:52] <elurkki> reading MaaS syslog to see
[21:52] <ahasenack> bleepbloop: good luck
[21:52] <elurkki> But I agree about other problems
[21:52] <ahasenack> bleepbloop: if you hit more issues, you can try askubuntu.com with the autopilot and/or landscape tags
[21:52] <ahasenack> bleepbloop: I rarely idle here
[21:53] <elurkki> I assume this old Fujitsu RX100 S4 with deadly old virtualization support is just pulling my leg
[21:53] <ahasenack> I mean, I *idle* here :)
[21:53] <ahasenack> elurkki: I created it all in virt-manager
[21:53] <bleepbloop> ahasenack: Will do, I was eyeing that up as well however figured I'd try here first :P
[21:53] <ahasenack> elurkki: network, vms
[21:54] <ahasenack> bleepbloop: sure
[21:54] <elurkki> ahasenack: I am using bridged network. It might be problem as well
[21:54] <ahasenack> hm
[21:54] <ahasenack> elurkki: I used NAT, what virt-manager calls NAT
[21:54] <ahasenack> elurkki: just disabled DHCP
[21:55] <ahasenack> elurkki: then created the vm for maas, and for the nodes, attached to this network
[21:55] <ahasenack> elurkki: that's the simplest case and should work. Later on you can try more advanced scenarios
[21:55] <elurkki> ahasenack: yep, probably have to test that scenario first
[21:55] <ahasenack> that's isolated enough, and allows the nodes to reach the internet without problems
[21:56] <elurkki> I agree
[21:56] <ahasenack> but you can only reach the nodes from your machine, of course
[21:57] <ahasenack> I'm gonna go
[21:57] <ahasenack> good luck guys
[21:57] <ahasenack> see you around
[21:57] <elurkki> thanks a lot for all the help
[21:57] <elurkki> cu later


[09:31] <czajkowski> sweet jebus kevin myers is some tit
[13:01] <infoturtle> How would I become a chan op, in another room, not this one. There's no ops in there ATM
[13:07] <czajkowski> infoturtle: is it on freenode
[13:07] <czajkowski> is it ubuntu ?
[13:07] <czajkowski> and there could be a person who has ops just not opped up
[13:12] <infoturtle> no it's on #infoturtle, duno how but there's no op's
[13:13] <infoturtle> but it is on freenode
[13:14] <czajkowski> infoturtle: did you create the channel
[13:14] <czajkowski> or did you just find it
[13:15] <infoturtle> created it, ages ago. It was just ment for the team to hand round and talk in but wana make it public now. There are others who are somtimes in there. If they come back in do they keep ops?
[13:16] <czajkowski> well it's on freenode and not an offical channel so it should be ## I think
[13:16] <czajkowski> and if created it you have ops
[13:16] <czajkowski> you can ask for help in... hmm lemmie check
[13:17] <czajkowski> infoturtle: also while you're here please dont send images as signatures to the .ie list
[13:17] <czajkowski> it's not really propper etiquette
[13:17] <infoturtle> ya, I don't get it, I even tried leaving it (so it was empty) and creating it again but still no ops
[13:17] <infoturtle> ok, I forget about that, it's an auto sig thing
[13:17] <czajkowski> infoturtle: you have to register it then :)
[13:18] <infoturtle> ah!
[13:19] <czajkowski> infoturtle: ask in #defoucus or #freenode for a staffer to help
[13:19] <infoturtle> cheers, will do
[13:41] <czajkowski> infoturtle: msg chanserv info #infoturtle
[13:41] <czajkowski>  /msg
[13:41] <czajkowski> infoturtle: someone else registered that channel
[20:34] <airurando> evening
[20:57] <mokmeister> hello airurando
[21:16] <airurando> hi mokmeister
[21:55] <tdr112> evening


[00:27] <Unit193> andygraybeal: Howdy.
[00:27] <andygraybeal> hi
[00:28] <andygraybeal> howsit going?
[00:28] <Unit193> Not my favorite day.  You?
[00:29] <andygraybeal> yea, things aren't well with me.. but that is okay.  today though, it wasn't so bad.  i spent all morning in the woods with my boy in my arms looking for mushrooms.  he even napped that way.. from around  9am till 1pm.. no mushroom though
[00:29] <Unit193> Wow.
[00:30] <andygraybeal> i'm super jealous seeing everyones mushrooms on fb
[00:40] <dzho> we talking morels, yeah?
[10:48] <andygraybeal> yea, dzho


[16:31] <cmaloney> Morning
[21:26] <rick_h_> phew, home at last
[22:45] <brousch> This is crazy stuff. They are working on a makerspace+k-12 school+universities+more in the old Steelcase Pyramid building. We're talking 665,000sqft
[22:47] <cmaloney> rick_h_: Welcome back
[22:58] <rick_h_> ty much
[22:59] <rick_h_> just have to make it  2 more hours before bed


[05:07] <jsgotangco> oh god i totally forgot about it
[05:32] <Riddell> so did everyone else by the looks of it
[05:33] <jsgotangco> Riddell: shame really, the team (or whatever is left) really needs rebuilding...
[05:37] <Yagisan> well I usually just watch
[05:38] <Yagisan> but yeah - it's really quiet here
[06:28] <Seveas> When's the new docteam meeting?
[06:31] <mdke> no idea
[06:31] <mdke> why?
[06:35] <Seveas> I want to show off Ubugtu's new plugin ;)
[06:37] <mdke> bah


[17:05] <Martyn> Morning all
[17:06] <Martyn> does anyone here have experience bringing up linux on a Cortex-A9 (RealView)?
[17:47] <Meizirkki> where could i get Crtex-A9
[17:47] <Meizirkki> ?
[17:47] <Meizirkki> +o
[18:02] <armin76> Meizirkki: on a realview board? :D
[19:07] <Martyn> realview "board" that is
[19:08] <Martyn> It's a simulation, running under the ARM FastModel
[19:08] <Martyn> I have access to a Cortex-A9 that was implemented on an FPGA .. but the bloody thing is slow as mud (70Mhz)
[20:56] <lool> Martyn: not too surprizing :)
[23:43]  * Martyn can't remember, for the life of me, what the correct patch to printk.c is for the beagleboard
[23:43] <Martyn> I know the community kernel sources won't boot out-of-box without a patch .. but I can't find it


[21:03] <cj> seen seb128?
[21:04] <cj> can you folks access this?  http://depts.washington.edu/uwcl/docs/tutorial.pdf
[21:04] <dtchen> yes
[21:07] <cj> any of you help package evince?  maybe I should just submit a bug
[21:09] <cj> wait... now that I've looked at evince's 'apt-cache show' I don't see his name anywhere... I wonder how I got the idea he was involved...
[21:09] <cj> nm
[21:31] <vuntz|away> chrisccoulson: ping?
[21:31] <chrisccoulson> hi vuntz|away
[21:32] <vuntz|away> chrisccoulson: can you try a quick patch for https://bugzilla.gnome.org/show_bug.cgi?id=597623 ?
[21:32] <vuntz|away> seems to work fine for me, but since sometimes I don't see the issue, I'd like someone else to confirm ;-)
[21:32] <chrisccoulson> yeah, i can try
[21:34] <vuntz|away> just attached the patch
[21:34] <chrisccoulson> vuntz|away: thanks, i'll try that shortly
[21:56] <chrisccoulson> vuntz|away: your patch seems to fix the issue for me
[21:58] <TheMuso> dtchen: Fixes are uploaded
[22:07] <vuntz|away> chrisccoulson: cool
[22:09] <dtchen> TheMuso: thanks. what about alsa-lib?
[22:13] <TheMuso> dtchen: oh ok, forgot about that.
[22:13] <dtchen> TheMuso: no prob, thanks very much!
[22:14] <TheMuso> np
[22:14] <TheMuso> dtchen: thanks for your help, its much appreciated.
[22:14] <dtchen> anytime


[09:55] <teddy-dbear> Morning peoples, critters and everything else
[14:14] <naughtypeaches> morning
[14:15] <teddy-dbear> o/


[15:12] <roaksoax> smoser: whne you have a chance, could you please review/approve:
[15:12] <roaksoax> https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579
[15:12] <roaksoax> https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions/+merge/147460
[15:12] <roaksoax> thank!
[15:17] <smoser> roaksoax, 2 comments, that i'll add to review.
[15:17] <roaksoax> smoser: cool thanks
[15:19] <smoser> review updated.
[15:19] <smoser> sorry that took so long
[15:19] <roaksoax> smoser: thanks!! no worries :)
[15:22] <roaksoax> smoser: updated!
[15:55] <smoser> roaksoax, my only comment is on the drop of 'maas-commission' user
[15:55] <smoser> why did that go? or am i just reading it wrong
[15:56] <roaksoax> smoser:  because it adds more complication on replacing users with iLO3
[15:56] <roaksoax> smoser: and I'm not sure whether it would work
[15:57] <smoser> well, it added more complication in *all* cases.
[15:57] <smoser> but it was deemed necessary/important
[15:57] <roaksoax> 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] <roaksoax> smoser: either way, a different password is created
[15:58] <roaksoax> smoser: so I think it no longer makes sense to have 2 different users
[15:59] <roaksoax> smoser: that's one of the things that created issues at the drill
[16:00] <smoser> well you dont have to *replace* a user, do you?
[16:00] <smoser> you delete then add, or add then delete.
[16:00] <smoser> right?
[16:00] <smoser> 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] <roaksoax> smoser: it was deemed necessary to differentiate in what stage the user was added right?
[16:03] <roaksoax> there was no other reason why we did that
[16:04] <roaksoax> just only to differentiate what stage added the usre
[16:04] <roaksoax> is that still necessary?
[16:15] <roaksoax> rvba: around?
[16:17] <rvba> roaksoax: hi
[16:17] <rvba> What's up?
[16:17] <smoser> 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] <smoser> i think.
[16:19] <roaksoax> 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] <roaksoax> rvba: the technical board adviced to implement that on the maas side rather than on the django side
[16:19] <roaksoax> rvba: and we need that for sru
[16:22] <roaksoax> 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] <rvba> 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] <roaksoax> rvba: the other 2 patches are good to go
[16:23] <roaksoax> rvba: but will require external testing. The only thing is to move the genericIPAddressField to maas instead of django
[16:24] <rvba> "the other 2 patches are good to go" thank goodness for that!
[16:25] <roaksoax> :)
[16:25] <rvba> roaksoax: I'll have a look at this tomorrow.  Can you file a bug for this please? (maybe there is already one…?)
[16:26] <roaksoax> rvba: sure I'll do that if there's not one :)
[16:26] <rvba> ta
[16:31] <rvba> 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] <roaksoax> rvba: ack!
[16:49] <smoser> roaksoax, i thought that the general flow/idea was:
[16:50] <smoser>  * if a system boots into enlistment, create a new ipmi user 'maas-commission'
[16:50] <smoser>  that was only to be used for the commsisioning turn on (and would only be ever used for that)
[16:51] <smoser>  * 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] <smoser> 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] <smoser> but thats probably not that big of a deal.
[16:52] <smoser> the point is, though, that we very explicitly decided to use this temporary "first-commission only" user.
[16:52] <smoser> and you're dropping that.
[16:52] <smoser> Daviey, was involved in that discussion, perhaps he has other thoughts.
[16:57] <roaksoax> smoser: we never remove the maas-commission user, we replace it
[16:57] <roaksoax> or at least that's how it works on iLo1
[16:58] <roaksoax> smoser: the only difference was that there was a different user name, and obviously a different password
[16:58] <smoser> 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] <roaksoax> 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] <smoser> not commissioning, enlistment.
[16:59] <roaksoax> smoser: right, so it is exactly the same case
[16:59] <smoser> the 'maas-commissioning' was explicitly there for enlistment
[16:59] <Daviey> smoser: I'm not emotional either way.. that just seemed a sane way
[17:00] <smoser> as enlistment potentially (i think very unlikely) results in accidentally breaking something for someone
[17:00] <smoser> (ie, if they accendentally pxe booted off a new network... something i thought then was un-likely)
[17:00] <roaksoax> look, if the node is set to 'Ready', and it enlists again, it will change the creds in the BMC either way
[17:00] <Daviey> well, that was slightly different
[17:00] <smoser> not if it enlists to a new maas.
[17:01] <smoser> or a maas it did not intend to enlist to
[17:01] <roaksoax> smoser: in iLO3 yes
[17:01] <roaksoax> i mean
[17:01] <roaksoax> iLO1/2 yes
[17:01] <roaksoax> it would have *replaced* the user regardless of what user it would have been
[17:01] <roaksoax> 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] <smoser> previously, that would not have happened.
[17:02] <roaksoax> smoser: it would
[17:02] <smoser> at least that was not what we intended.
[17:02] <smoser> the goal before was that enlistment would create a maas-commission user
[17:02] <smoser> and only ever break or change a user named 'maas-commission'
[17:02] <roaksoax> smoser: yes, and we agreed that that user should be *replaced*
[17:03] <smoser> i dont think "replaced" matters.
[17:03] <roaksoax> smoser: exactly, which means that maas-comission or only maas doesn't matter either way
[17:03] <smoser> surely you're not suggesting that previously "maas-commision" would "replace" "maas" user
[17:03] <smoser> as that would be stupid, and the same as deleting.
[17:03] <roaksoax> smoser: that would have happened if you would enlist that machine to a different MAAS
[17:04] <roaksoax> smoser: if you enlist the machine to a different maas, it will replace the existing 'maas' user with 'maas-commission'
[17:04] <roaksoax> that's how it
[17:04] <roaksoax> that's how it always worked
[17:04] <roaksoax> because we decided to have a temporary user/password combination that would later be replaced by the 'maas' user
[17:05] <roaksoax> but then it was *replace*
[17:06] <smoser> roaksoax, you're missing something. or i'm missing something
[17:06] <smoser> i dont care what happens on commission
[17:07] <roaksoax> 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] <smoser> well, that was a bug then.
[17:09] <roaksoax> smoser: so using only 'maas' makes more sense
[17:10] <smoser> well, other than it is destructive
[17:10] <smoser> in enlistment
[17:10] <smoser> which is why we had this 'maas-commission' user
[17:10] <smoser> but you're dropping that.
[17:10] <smoser> even if the implementation was broken, it was still there in concept, and now you're removing it.
[17:11] <smoser> if its known broken, i'd just make sure we remove all 'maas-commision' strings anywhere.
[17:15] <roaksoax> smoser: well then the whole IPMI stuff needs re-factoring to support those 2 things differently
[17:16] <roaksoax> smoser: but won't be able to say it works 100% until i can test that with iLO3
[17:20] <smoser> roaksoax, well, for now then i think its probably best to pull it completely
[17:20] <roaksoax> smoser: ack!