/srv/irclogs.ubuntu.com/2016/07/01/#maas.txt

=== alexlist` is now known as alexlist
f1gjamok everything rebuild01:32
f1gjamtrying openstack installer again01:32
f1gjammpontillo, 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 point01:33
f1gjameven though i selected sdb it still used sda01:33
f1gjamfrom what i can tell01:33
mupBug #1597964 opened: Node/Interfaces page should have a UI feedback mechanism <MAAS:New> <https://launchpad.net/bugs/1597964>02:01
pacavaca_who02:02
pacavaca_oops02:02
pacavaca_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:07
f1gjamahasenack, failed02:28
f1gjamahasenack, http://paste.ubuntu.com/18207341/02:29
f1gjamthis is all clean install02:29
f1gjamclean MaaS02:29
f1gjamsetup as per my document02:29
f1gjamhttps://www.dropbox.com/s/fxs3voyjgtkrei4/Ubuntu_14.04_Install_Docuement.pdf?dl=002:30
f1gjamupdated the DHCP ranges to be larger as discussed02:30
mupBug #1597967 opened: DHCP activation is not easily discoverable <MAAS:New> <https://launchpad.net/bugs/1597967>02:31
mupBug #1597968 opened: subnet configuration is confusing and undocumented <MAAS:New> <https://launchpad.net/bugs/1597968>02:31
mupBug #1597969 opened: Change boot device and not recommissioning causes curtain failure <MAAS:New> <https://launchpad.net/bugs/1597969>02:31
f1gjamcommands log: http://paste.ubuntu.com/18207431/02:31
mupBug #1596287 changed: Feature request Installation tracking via MaaS <MAAS:Opinion> <https://launchpad.net/bugs/1596287>03:19
mpontillopacavaca_: I think curtin calls it when it's done with the installation, assuming everything proceeded with no errors.03:51
mpontillopacavaca_: 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 called03:51
=== frankban|afk is now known as frankban
mupBug #1598028 opened: [2.0] Loading latest machine events can make web browser unresponsive <MAAS:New> <https://launchpad.net/bugs/1598028>07:50
=== spammy is now known as Guest3061
mupBug #1598116 opened: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment <MAAS:New> <https://launchpad.net/bugs/1598116>11:23
=== bradm_ is now known as bradm
mupBug #1598116 changed: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment <MAAS:New> <https://launchpad.net/bugs/1598116>11:32
mupBug #1598116 opened: [2.0] Digital Loggers PDU are not cycled before commissioning/deployment <MAAS:New> <https://launchpad.net/bugs/1598116>11:41
f1gjamahasenack, you there?12:41
ahasenackf1gjam: yes, but busy, sorry12:41
f1gjamah ok12:41
ahasenackf1gjam: you can paste here and I can take a look later12:41
f1gjamping me when you are free12:41
f1gjamahasenack, log from node being deployed  http://paste.ubuntu.com/18207341/12:42
f1gjamThis is all clean install12:42
f1gjamclean MaaS12:42
f1gjamSetup as per my document12:42
f1gjamupdated document: https://www.dropbox.com/s/fxs3voyjgtkrei4/Ubuntu_14.04_Install_Docuement.pdf?dl=012:42
f1gjamupdated the DHCP ranges to be larger as discussed12:42
f1gjamcommands log: http://paste.ubuntu.com/18207431/12:43
f1gjamserver is still up ill wait for you to become free12:43
mupBug #1598149 opened: [2.0b8] When a machine is stuck in 'Releasing' I cannot abort it <MAAS:New> <https://launchpad.net/bugs/1598149>13:21
mupBug #1598175 opened: [2.0] If the machine is deployed, I cannot update NIC's nor storage <MAAS:Triaged> <https://launchpad.net/bugs/1598175>14:03
=== narindergupta is now known as narinder
dannfroaksoax_: 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?14:59
roaksoax_dannf: the auto-assing, dhcp, static are properties of the interface, and not ranges15:18
roaksoax_dannf: auto-assign means, randomly select an IP address from the subnet (not from reserved, dynamic range), and configure e/n/i15:19
roaksoax_dannf: static means, user must provide an IP address, to be configured on e/n/i15:19
roaksoax_dannf: dhcp means, configure interface on e/n/i as 'dhcp'15:20
roaksoax_dannf: so that if the subnet in question is not managed by MAAS (external DHCP server), the NIC DHCP's from there15:20
dannfroaksoax_: 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 ranges15:20
roaksoax_dannf: that's the thing you can do it whicever way you want15:20
=== narinder is now known as naridner
roaksoax_dannf: auto-assign -> maas picks an IP for you on the subnet, and configures e/n/i15:21
=== naridner is now known as Narinder
roaksoax_dhcp -> you configure the interface as 'dhcp' on e/n/i15:21
roaksoax_static -> user picks the IP that interface will have (always, regardless of the deployment)15:21
roaksoax_dannf: auto-assign is backwards compaibility from previous versions15:21
dannfroaksoax_: 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:22
dannfi 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 server15:23
roaksoax_dannf: so there's two things, the way how we configure an interface, and the source of where the IP comes from15:23
roaksoax_dannf: in the past, we had two sources, dynamic range, and static range15:23
roaksoax_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:23
roaksoax_dannf: so 1.9/2.0 changed that15:24
roaksoax_dannf: specially 2.015:24
roaksoax_dannf: for example, if 1.x you had-> dynamic 10.10 - 10.100 and static 10.101 - 10.20015:25
roaksoax_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
roaksoax_dannf: so if you see, the "free" range used to be the "static" range15:26
dannfyep - with you there15:26
roaksoax_dannf: and we select an interface as "auto-assign" it will pick an IP address from the "free" range15:27
roaksoax_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
roaksoax_dannf: so it is a safety measure  (this is on upgrade only)15:28
roaksoax_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 neutron15:28
roaksoax_dannf: and the dynamic rnage is the same as above15:28
roaksoax_dannf: that said, say you don't have the "dynamic" range on the subnet, and you also don't have dhcp enabled15:29
roaksoax_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 MAAS15:30
roaksoax_dannf: so you may have an exnternal DHCP server15:30
roaksoax_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/i15:30
roaksoax_dannf: does that help ?15:30
dannfroaksoax_: if i deploy a node w/ auto assign, is it creating a static e/n/i ?15:30
roaksoax_dannf: yes15:30
dannfroaksoax_: ok. i think i understand. i'll write some docs up in an MP and let you be the judge by reviewing :)15:31
roaksoax_dannf: http://pastebin.ubuntu.com/18242414/15:32
f1gjamahasenack, any luck??16:51
nturnersmoser: 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 server17:05
nturnerI also realized that the user-data URL has to be translated slightly as you note.17:06
nturnerWith those changes, I think my curtin-hooks does all the right stuff now.17:06
nturnerThe 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
nturnerAnd current cloud-init expects a newer python than CentOS 6 provides.17:07
nturnerI 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:10
* nturner wonders if anyone is using MAAS with CentOS 6 images17:13
nturnerpacavaca_, 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 deployed17:19
nturnerMAAS configures the reporting part of cloud-init via /etc/cloud/cloud.cfg.d/90_dpkg_local_cloud_config.cfg on an ubuntu node17:19
nturnerHowever, 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-init17:20
nturnerGetting the newer cloud-init to run in an older environment may take some work (I've started attempting this).17:21
nturnerIf that turns out to be the right approach, we might want to coordinate our efforts...17:23
=== frankban is now known as frankban|afk
nturnerpossibly useful: https://paste.ubuntu.com/18251337/ and just plain icky: https://paste.ubuntu.com/18251374/17:28
=== nturner is now known as nturner|away
Harold_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?17:57
pacavaca_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:17
sjlis 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 failure18:40
mupBug #1598275 opened: [Feature request] Ability to boot the machine without re-imaging. <MAAS:New> <https://launchpad.net/bugs/1598275>18:48
nturnerpacavaca_, cool.18:56
=== mup_ is now known as mup
f1gjamanyone know the release date for MaaS 2.020:21
brendandf1gjam, i guess you mean the final release? maas 2.0 is in xenial but not the final release yet21:18
f1gjambrendand, yes final release21:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!