| === valeech_ is now known as valeech | ||
| tinchux | hi! everyone | 04:40 |
|---|---|---|
| tinchux | I need some /HELP | 04:40 |
| tinchux | provisioningserver.drivers.hardware.virsh.VirshError: Unknown state: apagado | 04:44 |
| tinchux | I'm receiving this error on my maas controller node | 04:44 |
| tinchux | all my machines have this status "Failed commissioning" | 04:44 |
| tinchux | I'm using MAAS Version 2.0.0 (beta7+bzr5112) | 04:45 |
| tinchux | with Ubuntu 16.04 | 04:45 |
| === jefferai_ is now known as jefferai | ||
| === frankban|afk is now known as frankban | ||
| === BlackDex_ is now known as BlackDex | ||
| === Gues_____ is now known as Bofu2U | ||
| === kwmonroe_ is now known as kwmonroe | ||
| bdx | hey whats up everyone? I am testing out the maas-{region,rack} charms in ha, I seem to be at an impasse where I'm blocked due to "Miossing admin config" as shown here -> http://paste.ubuntu.com/17705033/ | 16:50 |
| kiko | bdx, oh, nice! | 16:52 |
| kiko | sounds like the charm is broken | 16:52 |
| kiko | the region charm | 16:52 |
| kiko | who owns it? | 16:52 |
| bdx | blake_r-_ | 16:53 |
| kiko | wow | 16:53 |
| bdx | https://jujucharms.com/u/blake-rouse/ | 16:53 |
| bdx | the charms ^ in his namespace error on install though .... I had to pull them down and rebuild to get the wheelhouse deps with the latest pip | 16:54 |
| kiko | ah they are new | 16:56 |
| bdx | yeah ... I have a feeling theres a step that just might not be documented that I'm missing to pull the rest of it together | 16:57 |
| bdx | blake_r_:^ | 16:58 |
| === frankban is now known as frankban|afk | ||
| bdx | figured it out | 17:33 |
| bdx | the admin-password set in maas-region configs on deploy isn't picked up, you must also set it again when you are blocked post-deploy | 17:34 |
| bdx | ;-) | 17:34 |
| LiftedKilt | maas 1.9 worked perfectly detecting and setting ipmi settings and deploying nodes, but I can't seem to get 2.0 (using beta 7 now) to recognize the power type on my nodes | 17:36 |
| LiftedKilt | and idea where to poke to try and get it working? | 17:36 |
| === zz_CyberJacob is now known as CyberJacob | ||
| bugrum | Is there any documentation on how to troubleshoot MAAS when dealing with iDRAC IPMI? | 17:49 |
| bugrum | I configured MAAS to act as a DHCP server and it seems to be properly assigning IP addresses if other machines are connected to a switch, however I tried to make the MAAS DHCP server into a multi-homed server so that it can provide IP addresses to an iDRAC network and it doesn't seem to be working | 17:51 |
| bugrum | any machine connected to the server via iDRAC IPMI doesn't seem to get an IP address as I thought they would | 17:52 |
| arosales | any folks available to help with a MAAS 2.0 beta 7 / juju 2.0 beta 9 setup? | 18:01 |
| * arosales working with valeech | 18:01 | |
| arosales | current issue: 2.0 beta 7 running in a vm. I have juju 2.0 beta 9 | 18:02 |
| jhegge | still running juju beta 7, i saw some maas breakage in beta8 so i have stuck with beta7 for the time being | 18:04 |
| kiko | arosales, what's the actual problem? | 18:05 |
| arosales | current problem definition http://paste.ubuntu.com/17708627/ | 18:06 |
| arosales | jhegge: hmm so I wonder if juju beta9 and maas beta7 are not compatibile | 18:07 |
| mup | Bug #1595279 opened: ipaddresses API doesn't show hostname when reading <oil> <MAAS:Triaged> <https://launchpad.net/bugs/1595279> | 18:07 |
| arosales | kiko: ^ problem def above | 18:10 |
| kiko | arosales, looks like a bug, but perhaps his network setup is wonky? the paste is really painful to read | 18:11 |
| jhegge | arosales: no idea on beta9, wasn't released last i'd looked but beta8 didn't last so i'd hope beta9 was repaired. for what i'm doing beta7 of juju is working. i agree with kiko, the network setup on the maas server affects the deploy | 18:12 |
| kiko | jhegge, did you see the no-default-gw issue that valeech is seeing? | 18:12 |
| kiko | jhegge, or perhaps put differently, what breakage did you see in beta8? | 18:12 |
| arosales | jhegge so your set up is maas 2.0 beta7 and juju 2.0 beta 7, and this workng? | 18:13 |
| jhegge | kiko: haven't seen the default gw issue, i've deployed and had all apt traffic back through the maas-proxy, nicely | 18:17 |
| kiko | jhegge, even with beta8 you mean? :) | 18:18 |
| jhegge | kiko: can't recall the beta8 issue, something scrolled past in #juju and well, i was busy working on ephemeral image deploys under maas anyway, so i have a full plate, didn't need more juju fun | 18:18 |
| jhegge | still on juju beta7 | 18:18 |
| kiko | heh | 18:18 |
| jhegge | 2 betas, working their way to release, it's a bit bumpy | 18:18 |
| jhegge | arosales: i have maas beta7 (and a maas beta5) working with juju beta 7 | 18:19 |
| jhegge | but i'm trying not to the use the UI, just the API. (and the CLI to work out ideas) | 18:20 |
| jhegge | kiko: the network trouble we've seen is having to change the resolv.conf on the maas server to get the nodes to resolve <my maas node>.maas but that's as much an artifice of dev environments as anything | 18:21 |
| jhegge | and you do have that doc'd on the end of the page on ... can't recall... | 18:22 |
| kiko | I'm surprised changing resolv.conf on the maas server does anything actually | 18:22 |
| kiko | jhegge, why would the local resolver there affect anything? | 18:22 |
| jhegge | go to a node, ask the node to resolve its own FQDN, fail | 18:23 |
| kiko | jhegge, sure, but that would be resolve.conf missing on /the node/, not the maas server? | 18:23 |
| jhegge | also, depending on how maas is installed, hosts file doesn't get a good entry for the host itself | 18:23 |
| arosales | jhegge: ok perhaps that is the recommendation for valeech | 18:23 |
| * arosales not sure if anyone has validated juju2 beta9 and maas2 beta 7 :-/ | 18:24 | |
| jhegge | yeah, the maas server with 2 NICs was part of the issue: one NAT and one static/private net. hosts file and resolv.conf may get written wrong on install by ubuntu | 18:24 |
| jhegge | but uh, MAAS is made for metal so VMs are a bit trickier | 18:25 |
| LiftedKilt | I can't get maas beta 7 to detect/set IPMI settings, so commissioning is failing for all my nodes - any ideas? | 18:28 |
| LiftedKilt | it worked perfectly in 1.9 | 18:28 |
| kiko | LiftedKilt, do you mean the auto-enlist functionality is failing? | 18:29 |
| LiftedKilt | kiko: when I pxe boot the nodes, they enlist in maas and show in the New state w/o any configuration for the power options | 18:31 |
| LiftedKilt | in 1.9 the power settings were automatically configured for IPMI, and maas created the user and password for it | 18:31 |
| jhegge | lifterKilt: are you commissioning with xenial or trusty? we had better luck commissioning trusty with maas 2.x (just in a few cases, no idea why) | 18:32 |
| LiftedKilt | it isn't doing that in 2.0, and thus the commissioning fails because it can't control the nodes | 18:32 |
| LiftedKilt | trying everything in xenial | 18:32 |
| LiftedKilt | jhegge: importing 14.04 now | 18:33 |
| LiftedKilt | err 14.10 | 18:33 |
| LiftedKilt | err should have been 14.04 and I just selected the wrong release haha | 18:34 |
| kiko | yes, it should have indeed | 18:40 |
| jhegge | yeah, I stuck with the 2 LTS releases | 18:40 |
| jhegge | i learned my lesson on Azure with 15.10 disappearing | 18:41 |
| kiko | jhegge, MSFT knows how to keep one honest always! | 18:41 |
| mpontillo | arosales: valeech: when you look at the subnet configuration in MAAS for the PXE network, is there a default gateway defined? if so, can it be removed? | 19:05 |
| valeech | mpontillo: arosales: there was a gw on the pxe subnet and I removed it and it did not help. | 19:09 |
| mpontillo | valeech: could you use the MAAS CLI to do something like, "maas <profile> machine get-curtin-config <system-id>" so we can see how the deployed node is being instructed to set up its network? | 19:11 |
| valeech | mpontillo: yes, I will need to tear down my ha setup to put one of the machines back into ready state… one sec. | 19:15 |
| mpontillo | valeech: that command should be run on a deployed or deploying node | 19:15 |
| LiftedKilt | jhegge: still not working | 19:16 |
| valeech | mpontillo: ok, so I ran this: maas 20-juju machine get-curtin-config 4y3h7s and it returned “Machine overrighteous-concetta is not in a deployment state." | 19:16 |
| mpontillo | valeech: also, I assume you've redeployed after changing the subnet configuration | 19:16 |
| LiftedKilt | it won't even let me try to commission them without a power type selected | 19:17 |
| mpontillo | valeech: yeah, that command only works if you're deploying or deployed. it will tell us what the configuration we sent to the installer was, including the network config | 19:17 |
| valeech | mpontillo: yes I tried redeploying again. same situation, I had to ssh in to the node getting deployed and change the gw in order for juju to finish bootstrapping. | 19:17 |
| LiftedKilt | I just can't figure out why it isn't configuring the power type | 19:17 |
| mpontillo | valeech: can you run the get-curtin-config command while you're having trouble bootstrapping? | 19:18 |
| valeech | mpontillo: am I using the wrong system-id? | 19:18 |
| mpontillo | valeech: I'm not sure. what state is the node in? I assume when juju starts bootstrapping it will move to "Deploying". at which point you should be able to run the command on the bootstrapping node. | 19:19 |
| mpontillo | valeech: juju probably won't try to do anything with it until it moves to "deployed", come to think of it | 19:19 |
| valeech | mpontillo: right now, because I was able to change the gw, I have juju bootstrapped to 3 VMs all in the delpoyed state and juju status showing the 3 nodes running | 19:20 |
| valeech | 3 nodes because I ran juju enable-ha | 19:20 |
| mpontillo | valeech: then, yeah, please double check the system_id; you can run something like this: maas 20-juju nodes read | jq '.[] | {hostname:.hostname, system_id: .system_id, status:.status}' --compact-output | 19:22 |
| mpontillo | valeech: the deployed nodes should have status = 6 | 19:23 |
| valeech | mpontillo: looks good: http://pastebin.com/xZdsM1Sk | 19:25 |
| valeech | overrighteous-concetta is the first of many bare metal boxes. | 19:26 |
| valeech | mponitllo: I was using the wrong system id. Here is the output of the get-curtin-config on one of the juju bootstrap nodes: http://pastebin.com/r6u0cya4 | 19:28 |
| mpontillo | valeech: ah, that node is in failed commissioning state | 19:29 |
| mpontillo | valeech: thanks, taking a look | 19:29 |
| mup | Bug #1595304 opened: add Subnet fails with "Extra data: line 1 column 8 (char 7) <MAAS:New> <https://launchpad.net/bugs/1595304> | 19:37 |
| mpontillo | valeech: is 10.131.107.2 the correct gateway? that's the only one I see in the curtin config. I do have a theory though: in this configuration, you can either have successful deployments or successful commissioning. the reason being that, based on MAAS configuration, you can *either* have internet access during commissioning/enlistment (on the PXE network) | 19:40 |
| mpontillo | or after deployment (on the deployment network) | 19:40 |
| valeech | mpontillo: yes, 10.131.107.2 is the correct gateway. the pxe network is 10.0.0.0/23 | 19:43 |
| valeech | mpontillo: when you say either successful deployments or commissioning, is that something specifc in my setup or a general concept with juju/maas? | 19:44 |
| mpontillo | valeech: with MAAS, when a machine first boots and registers, it is called enlistment. enlistment is a minimal statement of "this machine is on the network; we saw it with a MAC address and an IP address". when the machine enlists, it must contact MAAS to report this information back | 19:49 |
| mpontillo | valeech: commissioning is similar but more involved; the machine will inventory its disks and network cards, hardware, etc, and send it back to MAAS. | 19:49 |
| mpontillo | valeech: both commissioning and enlistment happen in what we call an "ephemeral" environment, in which we "live boot" over the network; no data is written to the machine's disks | 19:50 |
| mpontillo | valeech: however, in order for successful commissioning (and in some cases, enlistment) to occur, generally the node must DHCP boot from MAAS and get a correct default gateway, in order to access the Ubuntu archive and download whatever software is necessary to complete the commissioning (or in the case of enlistment, enough to just contact MAAS) | 19:51 |
| mpontillo | valeech: that all would work fine with MAAS knowing about the gateway on your PXE network. but if you start deploying machines and expecting them to not use the PXE network, we may have a problem | 19:51 |
| mpontillo | valeech: when the machine deploys, we take the network configuration in MAAS and write it to disk - generally statically. (we assign a static IP address, etc) | 19:52 |
| valeech | mpontillo: that’s exactly what’s happening. Would a local repository allow elisting/commissioning to work without a gw? | 19:52 |
| valeech | mpontillo: I didn’t realize elisting/commissioning required a gw. | 19:53 |
| valeech | mpontillo: I thought the nodes would simply use the maas-proxy to get whatever they needed. | 19:53 |
| mpontillo | valeech: well, I think there may be a better workaround. why not set the PXE interface to be unconfigured (no IP address), so that it won't be possible for the deployed node to accidentally use the gateway on the wrong network? | 19:54 |
| valeech | mpontillo: That should work. I have no need for the PXE network outside of deployment… | 19:55 |
| mpontillo | valeech: I would tend to agree that the proxy should allow enlisting in this situation. I'm not sure why that wouldn't be working. | 19:55 |
| mpontillo | (and commissioning) | 19:56 |
| valeech | mpontillo: Enlisting works great! Its commissioning that is having issues. | 19:56 |
| valeech | and deployment | 19:56 |
| * mpontillo needs to do more testing with the proxy; I usually don't use it in my test environment | 19:56 | |
| mpontillo | yeah, commissioning is what accesses the archive. | 19:56 |
| valeech | ok | 19:56 |
| valeech | what’s the quickest way to tear down a juju ha? :) | 19:56 |
| mpontillo | valeech: I would just release the nodes and delete the juju environment, but I haven't done much with juju 2.0. you might ask in #juju | 20:08 |
| valeech | mpontill: fair enough | 20:10 |
| valeech | mpontillo: That worked! Setting a gw on the pxe subnet so that machines can boot and enlist/commission but then leaving that interface unconfigured for deployment was the trick. Thanks for all of the help. Thank you to arosales also! | 21:23 |
| mpontillo | valeech: great! glad you got it to work. thanks for the feedback and for trying MAAS. | 21:30 |
| === valeech_ is now known as valeech | ||
| === valeech_ is now known as valeech | ||
| valeech | mpomtillo: you are welcome. my team is installing maas/juju/openstack. this is the first go I am having at it with. so far it is awesome! my understanding of everything is something less than awesome :) | 21:48 |
| arosales | mpontillo: rocks, thanks for the help :-) | 21:53 |
| arosales | valeech: many thanks for baring with us while we get these beta released | 21:54 |
| arosales | maas 2.0 and juju 2.0 GA are going to be a solid pair | 21:54 |
| valeech | arosales: no worries at all. thanks for the quick responses to questions and excellent support! | 21:54 |
| === CyberJacob is now known as zz_CyberJacob | ||
| bdx | or | 23:03 |
| mup | Bug #1595339 opened: Boot failed on enlist <MAAS:New> <https://launchpad.net/bugs/1595339> | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!