=== alexlist` is now known as alexlist [01:32] ok everything rebuild [01:32] trying openstack installer again [01:33] mpontillo, i noticed that if you want to change the boot drive you have to re-commisson. Otherwise the initial commission will use whatever drive has a / mount point [01:33] even though i selected sdb it still used sda [01:33] from what i can tell [02:01] Bug #1597964 opened: Node/Interfaces page should have a UI feedback mechanism [02:02] who [02:02] oops [02:07] mpontillo: who is responsible for calling metadata api after node got deployed? I was able to add boot-local api action and UI button which boots node from local disk. Now the node comes up right, but the status never changes from Deploying to Deployed. So I'm wondering if I can fix this too with some small hack. [02:28] ahasenack, failed [02:29] ahasenack, http://paste.ubuntu.com/18207341/ [02:29] this is all clean install [02:29] clean MaaS [02:29] setup as per my document [02:30] https://www.dropbox.com/s/fxs3voyjgtkrei4/Ubuntu_14.04_Install_Docuement.pdf?dl=0 [02:30] updated the DHCP ranges to be larger as discussed [02:31] Bug #1597967 opened: DHCP activation is not easily discoverable [02:31] Bug #1597968 opened: subnet configuration is confusing and undocumented [02:31] Bug #1597969 opened: Change boot device and not recommissioning causes curtain failure [02:31] commands log: http://paste.ubuntu.com/18207431/ [03:19] Bug #1596287 changed: Feature request Installation tracking via MaaS [03:51] pacavaca_: I think curtin calls it when it's done with the installation, assuming everything proceeded with no errors. [03:51] pacavaca_: if not, it's probably cloud-init when it first runs on the deployed node. try removing /var/lib/cloud/* and seeing if it gets called === frankban|afk is now known as frankban [07:50] Bug #1598028 opened: [2.0] Loading latest machine events can make web browser unresponsive === spammy is now known as Guest3061 [11:23] Bug #1598116 opened: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment === bradm_ is now known as bradm [11:32] Bug #1598116 changed: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment [11:41] Bug #1598116 opened: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment [12:41] ahasenack, you there? [12:41] f1gjam: yes, but busy, sorry [12:41] ah ok [12:41] f1gjam: you can paste here and I can take a look later [12:41] ping me when you are free [12:42] ahasenack, log from node being deployed http://paste.ubuntu.com/18207341/ [12:42] This is all clean install [12:42] clean MaaS [12:42] Setup as per my document [12:42] updated document: https://www.dropbox.com/s/fxs3voyjgtkrei4/Ubuntu_14.04_Install_Docuement.pdf?dl=0 [12:42] updated the DHCP ranges to be larger as discussed [12:43] commands log: http://paste.ubuntu.com/18207431/ [12:43] server is still up ill wait for you to become free [13:21] Bug #1598149 opened: [2.0b8] When a machine is stuck in 'Releasing' I cannot abort it [14:03] Bug #1598175 opened: [2.0] If the machine is deployed, I cannot update NIC's nor storage === narindergupta is now known as narinder [14:59] roaksoax_: i was going to try and MP some docs to talk about ip ranges in the main (non-changelog) part of the manual. one thing i don't understand though, is why would you choose dhcp vs. auto assign for an interface? [15:18] dannf: the auto-assing, dhcp, static are properties of the interface, and not ranges [15:19] dannf: auto-assign means, randomly select an IP address from the subnet (not from reserved, dynamic range), and configure e/n/i [15:19] dannf: static means, user must provide an IP address, to be configured on e/n/i [15:20] dannf: dhcp means, configure interface on e/n/i as 'dhcp' [15:20] dannf: so that if the subnet in question is not managed by MAAS (external DHCP server), the NIC DHCP's from there [15:20] roaksoax_: well, they're tightly coupled. if i don't understand how/why i want to configure my interfaces a certain way, i don't know how to allocate my ip ranges [15:20] dannf: that's the thing you can do it whicever way you want === narinder is now known as naridner [15:21] dannf: auto-assign -> maas picks an IP for you on the subnet, and configures e/n/i === naridner is now known as Narinder [15:21] dhcp -> you configure the interface as 'dhcp' on e/n/i [15:21] static -> user picks the IP that interface will have (always, regardless of the deployment) [15:21] dannf: auto-assign is backwards compaibility from previous versions [15:22] roaksoax_: i know i can - but how do i make that decision? is it beneficial somehow to use auto assign, or is it functionally equivalent? [15:23] i was guessing that auto assign would let maas "know" what ip will be assigned, or maybe prevent it from being changed by a random dhcp server [15:23] dannf: so there's two things, the way how we configure an interface, and the source of where the IP comes from [15:23] dannf: in the past, we had two sources, dynamic range, and static range [15:23] dannf: maas would only configure eth0 from the static range, everything else would be from the dynamic range (because maas didn't configure e/n/i) [15:24] dannf: so 1.9/2.0 changed that [15:24] dannf: specially 2.0 [15:25] dannf: for example, if 1.x you had-> dynamic 10.10 - 10.100 and static 10.101 - 10.200 [15:26] dannf: in 2.0 you will have: 2-9 (reserved), 201-254 (reserved), 10.10 - 10.100 (dynamic), 10.101 - 10.200 (free) [15:26] dannf: so if you see, the "free" range used to be the "static" range [15:26] yep - with you there [15:27] dannf: and we select an interface as "auto-assign" it will pick an IP address from the "free" range [15:28] dannf: the "reserved" range is a way of telling maas, don't automatically use IP's from that range(S) because in the version you upgraded from, MAAS wasn't able to use those IP's and you may have something there (switch, routers) [15:28] dannf: so it is a safety measure (this is on upgrade only) [15:28] dannf: however, if you manually reserved a range, you may be telling MAAS - i dont want to auto-assign IP's from this reserved range, because they are reserved for my cloud instances managed by neutron [15:28] dannf: and the dynamic rnage is the same as above [15:29] dannf: that said, say you don't have the "dynamic" range on the subnet, and you also don't have dhcp enabled [15:30] dannf: if you set the interface to "DHCP" on that subnet, we will only configure e/n/i to dhcp for the interface, but we wont provide any ip address because dhcp/dynamic range is not managed by MAAS [15:30] dannf: so you may have an exnternal DHCP server [15:30] dannf: but if you configure the interface with "auto-assign", then we will select any ip address from the "free" range and configure e/n/i [15:30] dannf: does that help ? [15:30] roaksoax_: if i deploy a node w/ auto assign, is it creating a static e/n/i ? [15:30] dannf: yes [15:31] roaksoax_: ok. i think i understand. i'll write some docs up in an MP and let you be the judge by reviewing :) [15:32] dannf: http://pastebin.ubuntu.com/18242414/ [16:51] ahasenack, any luck?? [17:05] smoser: yeah, thanks; I realized that after leaving work the other day (was offline yesterday); of course the curtin environment is not available to the cloud-init running on the deployed server [17:06] I also realized that the user-data URL has to be translated slightly as you note. [17:06] With those changes, I think my curtin-hooks does all the right stuff now. [17:07] The only remaining issue I'm aware of is that I need a newer cloud-init than CentOS has to pick up the reporting infrastructure you merged in from curtin. [17:07] And current cloud-init expects a newer python than CentOS 6 provides. [17:10] I was able to patch cloud-init to compile on python 2.6 again (changing some dict comprehensions to dict() with list comprehensions), but some of the other patches that have gone in recently to clean up how file IO is managed don't play well with older python libraries... [17:13] * nturner wonders if anyone is using MAAS with CentOS 6 images [17:19] pacavaca_, mpontillo: from what I can tell, with newer versions of maas and cloud init, the cloud-init reporting framework handles informing maas of the transition to deployed [17:19] MAAS configures the reporting part of cloud-init via /etc/cloud/cloud.cfg.d/90_dpkg_local_cloud_config.cfg on an ubuntu node [17:20] However, if you're using a newer MAAS with an older cloud-init, you may (as I did) see that this step never happens, because the maas reporting logic is not in older versions of cloud-init [17:21] Getting the newer cloud-init to run in an older environment may take some work (I've started attempting this). [17:23] If that turns out to be the right approach, we might want to coordinate our efforts... === frankban is now known as frankban|afk [17:28] possibly useful: https://paste.ubuntu.com/18251337/ and just plain icky: https://paste.ubuntu.com/18251374/ === nturner is now known as nturner|away [17:57] Hello, I'm looking into trying to manage a large number of diskless systems using MAAS. Currently all the systems run using a copy-on-write ramdisk clone of a central NFS share. Is it possible to do this with MAAS? [18:17] nturner: Thank you. My cloud-init is whatever comes with 12.04, so it's probably quite old. Though it works on first deployment. But when I'm trying to re-run it for the second time it complains, saying something about oauth and clock. Anyways, I think it's not so important anymore. For my case I'll just set the state to DEPLOYED right after powering node on. It's wrong, but for my hack it's fine. [18:40] is there a deployment process flow similar to this for commission? http://maas.ubuntu.com/docs2.0/development/notes/anatomy-of-recommissioning-in-maas-2.0.html?highlight=record trying to debug a centos deploy intermittent failure [18:48] Bug #1598275 opened: [Feature request] Ability to boot the machine without re-imaging. [18:56] pacavaca_, cool. === mup_ is now known as mup [20:21] anyone know the release date for MaaS 2.0 [21:18] f1gjam, i guess you mean the final release? maas 2.0 is in xenial but not the final release yet [21:32] brendand, yes final release