| === CyberJacob is now known as CyberJacob|Away | ||
| rvba | gmb: ping | 01:16 |
|---|---|---|
| gmb | rvba: Did you just ping me and then ask me out loud? | 01:17 |
| jtv | Yes. Yes, he did. | 01:17 |
| rvba | gmb: ping! | 01:20 |
| gmb | rvba: bzr shelve --all; bzr pull; bzr unshelve | 01:59 |
| rvba | rvb@leaf:~/canonical/api-power-type$ bzr pull ../maas | 02:00 |
| rvba | bzr: ERROR: These branches have diverged. Use the missing command to see how. | 02:00 |
| rvba | Use the merge command to reconcile them. | 02:00 |
| rvba | ^ lie | 02:00 |
| roaksoax | rvba: o/ | 02:32 |
| roaksoax | bigjools: o/ | 02:32 |
| roaksoax | bigjools: how are things going? How's the progress? | 02:32 |
| roaksoax | anything I can look at? | 02:32 |
| bigjools | roaksoax: slow | 02:33 |
| rvba | \o roaksoax | 02:33 |
| roaksoax | bigjools: can you or one of the team please review the UEFI stuff? | 02:33 |
| bigjools | roaksoax: gavin did | 02:34 |
| rvba | roaksoax: question for you: why isn't this returning anything? http://paste.ubuntu.com/7030441/. Looks like the beta1 ephemeral for trusty hasn't been released yet…? | 02:34 |
| roaksoax | bigjools: ok great | 02:35 |
| roaksoax | rvba: looking | 02:35 |
| rvba | Ta | 02:35 |
| roaksoax | rvba: can you try daily;'s? that's weird trusty ephemeral were available | 02:36 |
| roaksoax | smoser: ? | 02:36 |
| roaksoax | /query/win 10 | 02:44 |
| rvba | roaksoax: I tried with the daily url but I still get no results. | 02:44 |
| roaksoax | rvba: maybe there's an error somewhere | 02:45 |
| roaksoax | or maybe something happened | 02:45 |
| rvba | I don't know. http://maas.ubuntu.com/images/ephemeral/releases/trusty/ says alpha-2 is there but not beta-1 | 02:46 |
| roaksoax | rvba: so images have not yet been generated then | 02:48 |
| rvba | roaksoax: any idea when this is supposed to happen then? | 02:48 |
| roaksoax | rvba: nope, but will lookinto that tomorrow | 02:48 |
| rvba | Okay, ta. | 02:48 |
| Settite | jtv? roaksoax? either of you around? | 03:26 |
| === edamato is now known as edu-afk | ||
| jtv | Settite: hi, just out getting lunch. We're a bit pressed for time on this end. | 03:53 |
| Settite | I know. Just need quick help manually uninstalling MAAS | 03:54 |
| bigjools | Settite: you might want to ask in #ubuntu-server as this is a dpkg problem not a maas problem | 03:55 |
| Settite | Alright | 03:55 |
| bigjools | although | 03:55 |
| Settite | Didn't realize that | 03:55 |
| bigjools | the maas package has a problem, but the result of the problem is a dpkg problem :) | 03:55 |
| bigjools | basically the failed install is preventing removal | 03:56 |
| Settite | I will hit up #ubuntu-server first and see where i can get | 04:02 |
| === CyberJacob|Away is now known as CyberJacob | ||
| mwhudson | bigjools: has anyone talked about running maas on arm64 yet? | 04:45 |
| bigjools | mwhudson: not that I heard | 04:47 |
| bigjools | are you talking deploying or running on? | 04:47 |
| mwhudson | bigjools: deploying on | 04:47 |
| mwhudson | bigjools: is that even a sensible question, or does it depend on how a particular device boots/does ipmi/whatever | 04:48 |
| mwhudson | ? | 04:48 |
| bigjools | mwhudson: well AFAIC there's no difference to arm | 04:52 |
| bigjools | uboot has to tftp a specific location to get the right loader | 04:52 |
| mwhudson | right | 04:52 |
| Settite | So in #ubuntu-server they told me to remove the entries in /var/lib/dpkg/status for MAAS and just install it again... to me that doesn't seem right. | 05:11 |
| Settite | Or am i missing something/ | 05:11 |
| Settite | ? | 05:11 |
| bigjools | uhm | 05:11 |
| bigjools | I am no expert so try it | 05:12 |
| Settite | I will and report the results | 05:12 |
| === Settite is now known as Lord_Set2 | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| Lord_Set2 | bigjools: That method worked FYI to reinstall. | 08:29 |
| Lord_Set2 | The MAAS installer found some of the old stuff but regenerated passwords fine and migrated everything else | 08:30 |
| Lord_Set2 | No issues yet | 08:30 |
| Lord_Set2 | So I got some new dell blade servers to play around with and test with MAAS | 09:01 |
| Lord_Set2 | Will be interesting to see how they enlist and commission | 09:01 |
| Lord_Set2 | They are Dell C6100s | 09:02 |
| Lord_Set2 | 2 of them with all intel quad core 5600 series processors, 3 of them with AMD 6-core processors. 192GB of ram in each. | 09:02 |
| jtv | all otp here :) | 09:03 |
| Lord_Set2 | otp? | 09:03 |
| jtv | On The Phone. | 09:03 |
| Lord_Set2 | Oh | 09:03 |
| jtv | Reference for TLAs: http://xs4all.nl/~jtv/gtf/ | 09:04 |
| Lord_Set2 | fml, with a fresh install of the daily maintainers build of MAAS it is still having ilo/ipmi detection problems | 09:05 |
| Lord_Set2 | I watched the boot of one of the servers and it isn't able to open the device at /dev/ipmi0 or /dev/ipmi/o or /dev/ipmidev/0 | 09:06 |
| Lord_Set2 | But I am able to access to control the servers via ipmipower manually | 09:07 |
| Lord_Set2 | *access and controll | 09:07 |
| Lord_Set2 | control | 09:07 |
| bigjools | Lord_Set2: good to hear | 09:10 |
| bigjools | the first thing, not the recent thing :) | 09:11 |
| Lord_Set2 | lol | 09:11 |
| bigjools | so the ipmi things are actively getting looked at, they will get a fix soon, maybe in a day or two | 09:12 |
| Lord_Set2 | Alright. I guess for now I will manually boot the servers between installation phases. Should this cause any issues in the OS install? | 09:13 |
| bigjools | no | 09:17 |
| Lord_Set2 | Awesome and thanks. | 09:17 |
| bigjools | https://bugs.launchpad.net/bugs/1287512 is prob the bug | 09:17 |
| ubot5 | Ubuntu bug 1287512 in MAAS "OCPv3 roadrunner detects IPMI as 1.5, which isn't supported." [Critical,In progress] | 09:17 |
| Lord_Set2 | I don't think so. This isn't detecting any IPMI at all at the end of the enlistment. | 09:19 |
| Lord_Set2 | Current errors in maas.log | 09:24 |
| Lord_Set2 | http://pastebin.ubuntu.com/7032086/ | 09:24 |
| bigjools | Lord_Set2: what client is connecting when it does that? | 09:26 |
| bigjools | it's basically not authed | 09:27 |
| Lord_Set2 | I am logged in with 2 different current API keys | 09:27 |
| bigjools | is this the api cmd line client? | 09:27 |
| bigjools | you need to re-login | 09:27 |
| Lord_Set2 | Yes | 09:27 |
| bigjools | you deleted your install and lost the auth keys | 09:28 |
| Lord_Set2 | I did logout of the old logins and re-logged in with the newly generated keys | 09:28 |
| Lord_Set2 | Those are the ones currently logged in | 09:28 |
| bigjools | right we're all EODing | 09:30 |
| Lord_Set2 | I am just trying to figure out if it is a configuration issue or a bug I should report | 09:30 |
| bigjools | you need to log in again | 09:31 |
| Lord_Set2 | Ok I will | 09:31 |
| Lord_Set2 | More good news... MAAS loves the Dell C6100 blades. | 09:57 |
| Lord_Set2 | No issues with ipmi detection or enlistment at all | 09:58 |
| Lord_Set2 | If anyone is still available... how difficult is to to modify the installation of Ubuntu via MAAS to install LAMP as part of the base install? | 11:38 |
| smoser | rvba, why do you care about something called "beta1" ? | 13:24 |
| smoser | please don't get stuck on names. i'm sure we can/should get a newer thing there, but why are you explicitly looking for something named 'beta-1' ? | 13:24 |
| smoser | :q | 13:34 |
| === CyberJacob|Away is now known as CyberJacob | ||
| manjiri | hello. I replaced /var/lib/maas/tftp/amd64/generic/precise/install/* by passing a different MAIN_ARCHIVE to import-pxe-files. The intent was to install Ubuntu 12.04.3 (3.8.0-29-generic). MAAS still install 12.04.4 (3.2.0-59-generic). Any idea what I need to do differently? | 19:37 |
| Lord_Set2 | So... any specific reason why nodes are prompting for a password when I have had a ssh key generated and trying to ssh from the maas controller? | 20:33 |
| bigjools | Lord_Set2: you need to alter preseeds or pass cloud-init userdata for post-install actions | 22:07 |
| roaksoax | manjiri: 12.04.4 is now default so there's really nothing you can do there | 22:07 |
| bigjools | hey roaksoax | 22:07 |
| bigjools | Lord_Set2: is your key registered in maas for the same account that you used to start the node and are now sshing with? | 22:08 |
| roaksoax | bigjools: howdy! | 22:08 |
| roaksoax | bigjools: early start today? | 22:10 |
| bigjools | meeting | 22:10 |
| bigjools | that is if the other party shows up :) | 22:10 |
| roaksoax | haha | 22:10 |
| Lord_Set2 | bigjools: yes, I ended up modifying the preseed master for now to use a static user/pass across all nodes | 22:16 |
| bigjools | urgh | 22:17 |
| bigjools | that's horrible | 22:17 |
| Lord_Set2 | I agree but no choice right now | 22:26 |
| bigjools | roaksoax/jhobbs: is this related to any of your recent work? https://bugs.launchpad.net/bugs/1287828 | 22:26 |
| ubot5 | Ubuntu bug 1287828 in MAAS "IPMI power driver setting is reset/overriden by commissioning" [Undecided,New] | 22:26 |
| bigjools | Lord_Set2: can you check that once you are in, you can see the public key in they ubuntu user dir? | 22:31 |
| bigjools | the* | 22:31 |
| bigjools | you *are* sshing with ubuntu@ right? | 22:31 |
| bigjools | as that is the default user name | 22:31 |
| jhobbs | bigjools: i don't think so, i think that's always been the behavior | 22:33 |
| jhobbs | bigjools: ipmi autodetect, when it runs during commissioning, will supply all of the settings it applies/discovers back to metadataserver | 22:35 |
| jhobbs | bigjools: bigjools i think the bug they reference as the underlying reason for needing to do so (autodetect doesn't work) should be fixed by recent work though | 22:36 |
| bigjools | jhobbs: well we autodetct in enlistment, but didn't think we did it during commissioning | 22:43 |
| bigjools | so I am surprised at the behaviour | 22:43 |
| jhobbs | bigjools: yup, runs both times. i'm still not 100% sure why it has to run during commissioning. roaksoax explained it at one point but it's not coming to the top of my head | 22:44 |
| bigjools | jhobbs: yeah it doesn't seem right to me at all | 22:45 |
| * bigjools waits for roaksoax too :) | 22:45 | |
| jtv | Maybe because the "commissioning snippets" infrastructure got re-used for enlistment? | 22:45 |
| jhobbs | it's good that it runs during enlistment, so we have the power parmeters to use to turn it on for commissioning | 22:49 |
| manjiri | roaksoax: is the preseed config used with the "fast installer"? | 22:52 |
| jhobbs | i guess one case autodetect in commissioning is useful is if the user manually added the nodes, but didn't add power info, and then manually powered on? | 22:55 |
| jhobbs | maybe commissioning ipmi autodetect should only run if power isn't configured for the node | 22:55 |
| bigjools | maybe | 22:59 |
| roaksoax | manjiri: there are different preseeds used | 23:04 |
| roaksoax | bigjools: me what how when? | 23:04 |
| bigjools | roaksoax: que? | 23:04 |
| bigjools | :) | 23:04 |
| roaksoax | bigjools: thge bug above should be fixed with the recent changes that just landed | 23:05 |
| bigjools | roaksoax: elmo's bug about overwriting power settings? | 23:05 |
| bigjools | https://bugs.launchpad.net/bugs/1287828 | 23:05 |
| ubot5 | Ubuntu bug 1287828 in MAAS "IPMI power driver setting is reset/overriden by commissioning" [High,Triaged] | 23:05 |
| roaksoax | bigjools: yeah, since commissioning does the discovery again regardless | 23:05 |
| bigjools | roaksoax: so what changed? | 23:06 |
| manjiri | roaksoax: Which preseed config should I modify to see if I can specify a particular kernel-image during fast-installation? | 23:06 |
| roaksoax | bigjools: we removed the aut0o-detect option | 23:06 |
| roaksoax | bigjools: and improved the lan_2_0 detection | 23:06 |
| roaksoax | bigjools: so it will either be lan_2_0 or lan | 23:06 |
| roaksoax | and in this case, enlistment will detect lan_2_0 and he wont need to change it manually | 23:07 |
| bigjools | roaksoax: in either case I think we should not overwrite user settings | 23:07 |
| roaksoax | bigjools: there's no way for us to determine that | 23:07 |
| bigjools | there's always a way :) | 23:07 |
| roaksoax | manjiri: /etc/maas/preseeds/user_data | 23:07 |
| roaksoax | bigjools: not really, so enlistment and commissioning both modify and update IPMI settings regardless of the user manually changing the setting | 23:08 |
| manjiri | roaksoax: curtin_userdata? | 23:08 |
| roaksoax | bigjools: i.e. enlistment happens, then the user manually enters user/password, and in commissioning, whatever was entered by user, gets overwritten if maas can create user/pass | 23:09 |
| roaksoax | makes sense? | 23:09 |
| roaksoax | manjiri: yes! sorry | 23:09 |
| jhobbs | roaksoax: what if commissioning only made IPMI changes if the node didn't already have IPMI configuration? | 23:09 |
| bigjools | roaksoax: right, so I am saying we need to change that, we should never overwrite what the user put in unless they ask for it | 23:09 |
| bigjools | that is the crux of elmo's bug | 23:09 |
| bigjools | see my last comment on it | 23:09 |
| manjiri | roaksoax: What format is that? How can I effectively add base-installer/kernel/image config? | 23:10 |
| roaksoax | bigjools: so how can we determine wether e user changed this settings or not? | 23:10 |
| roaksoax | manjiri: it copies the kernel image being loaded | 23:10 |
| roaksoax | so that would be 12.04 | 23:10 |
| roaksoax | no .01/02 | 23:10 |
| roaksoax | you woul,d need to upgrade kernel | 23:10 |
| roaksoax | in postinst | 23:10 |
| roaksoax | i guess | 23:10 |
| bigjools | roaksoax: we can detect it on the server if we are able to see that the api request came from commissioning | 23:11 |
| roaksoax | jhobbs: we cant.. it is based -on the sabe assumption. say IPMI user was created during enlistment, and user manually changes the password of the maas user, then on commissioning, it has no way of knowing that, and will generate new user/pass combination. | 23:12 |
| roaksoax | jhobbs: and covers cases where things fail during enlistment | 23:12 |
| manjiri | roaksoax: what is a source of information that will help me understand the sentence "you would need to upgrade kernel in postinst". What context is postinst - so that I may google for more info | 23:12 |
| jhobbs | bigjools: it's too late then, the ipmi settings have actually changed then, and if the API doesn't update, the saved settings will be wrong | 23:12 |
| bigjools | roaksoax: perhaps you can comment on the bug then please, because it seems simple enough to me :) | 23:12 |
| bigjools | jhobbs: point | 23:12 |
| bigjools | so the preseed needs to prevent this in the first place | 23:12 |
| bigjools | I need to make coffee for the sprinters, back in 10m | 23:13 |
| roaksoax | bigjools: hold on. If enlistment creates user/password, it works, but user changes these settings manually, how can commissioning successfully say "don't try to detect IPMI again because the user has changed user/password"? | 23:13 |
| bigjools | they are looking at me like they are about to kill | 23:13 |
| jhobbs | roaksoax: we have to change the commissioning script to not call ipmi-autodetect if there is already ipmi credentials for the node | 23:14 |
| bigjools | that ^ | 23:14 |
| jhobbs | roaksoax: that way, no matter where they came from - enlistment or manual user entry - they aren't changed except via another enlistment, or via another manual user edit | 23:14 |
| bigjools | +1 | 23:14 |
| roaksoax | jhobbs: right, but we *want* to change the password if it came from enlistment | 23:14 |
| bigjools | +1 again | 23:14 |
| jhobbs | roaksoax: why? | 23:14 |
| bigjools | this just affects commissioning | 23:15 |
| roaksoax | jhobbs: because enlistment is unsecure | 23:15 |
| bigjools | with enlistment, there is no node in maas | 23:15 |
| roaksoax | it is anynomous add | 23:15 |
| roaksoax | jhobbs: the noed was added to maas withpower parameters anonymously | 23:15 |
| * bigjools goes barista-ing | 23:16 | |
| manjiri | roaksoax: I was able to specify the specific kernel by modifying the preseed_master config. How can I get the same functionality for fast installer? | 23:16 |
| roaksoax | in commissioning it actually authenticates with the server and we can trusty that the accepted the node, and new credentials are being generated | 23:16 |
| roaksoax | manjiri: i don't know unfortunately. this might help astokes.org/using-fastpath-installer-maas | 23:16 |
| jhobbs | roaksoax: ok - i think that makes sense | 23:17 |
| roaksoax | manjiri: see related posts / configuring vlans in MAAS node deployment or customizing fast path (curtin) installations in MAAS | 23:17 |
| roaksoax | jhobbs: so the problem is, what if the user manually changes the password on the BMC and updates MAAS< and then it breaks things? | 23:18 |
| jhobbs | hmm, maybe not, i don't really get where we can start trusting vs. where we can't | 23:18 |
| jhobbs | we can trust from commissioning because it has the API key that we gave via the PXE boot process, whereas anyone with IP access to MAAS can spam and enlist nodes | 23:19 |
| roaksoax | jhobbs: correct | 23:19 |
| roaksoax | jhobbs: this is why we generate a second set of credentials (another password) during commissioning, because those are the credentials that we know will be used for deployment | 23:20 |
| manjiri | roaksoax: http://maas.ubuntu.com/docs/development/preseeds.html says that there is a preseed_xinstall. But my MAAS controller does not have that file. (Only preseed_master is present). Any idea? | 23:24 |
| bigjools | docs are probably for a newer version than what you have installed | 23:25 |
| manjiri | bigjools: ah! thanks | 23:27 |
| roaksoax | manjiri: that has changed in latests | 23:32 |
| roaksoax | curtin is more recent than xinstall | 23:32 |
| roaksoax | bigjools: so back on the above... I don't think we can effectively determine what to trust or not on enlistment/commissioning | 23:33 |
| roaksoax | bigjools: i don't mind having commissioning not trying to re-do ipmi discovery | 23:33 |
| bigjools | roaksoax: I think that is best | 23:33 |
| roaksoax | bigjools: but that would defeat the purpose of not trusting what came from enlistment to trusting what came from commissioning | 23:33 |
| bigjools | although we may have a certain dictator arguing the opposite at some point | 23:34 |
| roaksoax | bigjools: well, we went thorugh this long ago with smoser | 23:34 |
| roaksoax | and we both agreed it was better to do this | 23:34 |
| roaksoax | in both cases | 23:34 |
| bigjools | well elmo has a valid point don't you think? | 23:34 |
| jhobbs | there's nothing secure about ipmi and pxe booting | 23:34 |
| roaksoax | bigjools: i do believe he does | 23:35 |
| roaksoax | bigjools: wouldn't it be better to have someone to determine whether the changes were made by a user or by enlistment? | 23:35 |
| roaksoax | to have something* | 23:35 |
| bigjools | my thoughts are that the preseed template can turn on the commissioning detection if it knows there's no power set yet | 23:35 |
| bigjools | anyway - I'll let you guys talk it over, we have to sprint here! | 23:37 |
| roaksoax | i'll wait for smoser to chip in | 23:42 |
| roaksoax | i' | 23:42 |
| roaksoax | i'm out for lunch ... or should I say dinner | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!