=== vladk|offline is now known as vladk
=== CyberJacob|Away is now known as CyberJacob
[07:35] <rvba> bigjools: reviewing your 'api-reserve-sticky-ip' branch now.
[07:35] <bigjools> rvba: thanks
[07:35] <bigjools> it should be called "part1" really
[07:35] <rvba> Yeah, I figured :)
[07:36] <bigjools> rvba: do we pass mac address in to any API call anywhere?
[07:36] <rvba> bigjools: when creating a node I believe.
[07:37] <bigjools> ah I see somewhere else
[07:37] <bigjools> just making sure I am going to be consistent with the parameter name
[07:38] <rvba> Good thinking.  This hasn't been our forte thus far.
[07:52] <rvba> bigjools: about your branch: Do we really want to remove STICKY mappings when a node is deleted?  I thought they were mean to be completely under the user's control (i.e. "Pre-assigned and permanent until removed [*by the user*]").
[07:52] <bigjools> rvba: you need to re-read the types of IP addresses
[07:52] <bigjools> you're talking about a different type
[07:53] <rvba> Well, that's what I'm doing now.  It's not helping.
[07:53] <bigjools> USER_RESERVED in this case
[07:53] <bigjools> I keep asking people for a way to make this distinction clearer and nobody helps, they just complain :(
[07:53] <rvba> heh
[07:54] <rvba> Let me re-read the discussion about this in maas-devel then…
[07:54] <bigjools> rvba: STICKY is just a permanent IP for a node
[07:55] <bigjools> as opposed to the auto ones you normally get
[07:55] <rvba> The docstring says: "# Pre-assigned and permanent until removed."
[07:55] <rvba> Removed by who?
[07:55] <rvba> I guess everything is sort of "Permanent until removed" :)
[07:56] <rvba> It's a bit like "Alive until dead."
[07:57] <g0ldr4k3> hello everyone
[08:04] <g0ldr4k3> I'd like to know, after to have created a region controller with 2 cluster controller accepted and added 4 nodes per each cluster, in the region's UI I see only 2 cluster without the nodes associated on them. a question but which is the Region works is it can see just the custer and I can't manage the nodes? thanks
=== vladk is now known as vladk|offline
[08:31] <jtv> g0ldr4k3: the Clusters page only shows the clusters, not the nodes.  There's a separate Nodes page.
[08:33] <g0ldr4k3> and what is the Region Controller's goal in a MaaS infrastructure?
[08:34] <g0ldr4k3> if I can see just the CCs but not their nodes
[08:40] <jtv> The region controller is the central server.  The cluster controllers are closer to the nodes.
[08:40] <jtv> But the region controller also serves the UI.
[08:40] <jtv> You should see the nodes in the UI.
[08:41] <g0ldr4k3> It's my opinion but I think that RC should manage all the infrastructure, is as a main manager
[08:41] <bigjools> patches welcome
[08:43] <g0ldr4k3> in this case I 've only 2 CC each ones with 2/4 nodes and it's easy to manage that because the nodes are flew, in the case we have more of them How can manage that???
[08:44] <g0ldr4k3> RC should make this function......
[08:48] <bigjools> everything you need is on the RC,
[08:51] <g0ldr4k3> bigjools: my infrastructure is realized using 1 RC and 2 CC. each CC have 2 or more nodes installed and manage via virtio. both CC are accepted on the RC....my question is this, if the RC is the main controller it'd manage all infrastructure, why in its ui I can see just the CC an I cant manage their nodes
[08:52] <g0ldr4k3> bigjools: in this case I 've only 2 CC each ones with 2/4 nodes and it's easy to manage that because the nodes are flew, in the case we have more of them How can manage that??? RC should make this function, I mean I think that......
[08:56] <bigjools> g0ldr4k3: if you click the Nodes tab at the top, does it list any nodes?
[08:58] <bigjools> if you don't see node then your 4 nodes have not successfully enlisted into maas
[08:59] <bigjools> there could be many reasons for that, such as not configured to PXE boot, firewall problems, internet problems and so on
[08:59] <g0ldr4k3> nothing, I can see the nodes only on the CC. and their works well
[08:59] <bigjools> start by looking in the /var/log/maas/ logs
[08:59] <bigjools> the CC does not "show" nodes, so I don;t know what you are looking at
[08:59] <bigjools> please examine the logs
[08:59] <bigjools> it's my EOD here so someone else can help you
[09:03] <g0ldr4k3> 2 CCs work well with their nodes enlisted and allocated, the RC see only the CC but not their nodes......what is the RC's goal seeing just the CC, that's it? it's possible to manage also the nodes by RC?
[09:18] <g0ldr4k3> anyone can answer me?is there a way to manage the nodes of each single CC via RC? or RC can view only the CC on its web ui?
[09:20] <allenap> g0ldr4k3: I’m reading the history then I’ll try to answer.
[09:21] <g0ldr4k3> allennap:  thanks
[09:26] <allenap> g0ldr4k3: It sounds like you’ve installed 4 virtual machines on each machine that also runs each of your 2 cluster controllers, right?
[09:27] <allenap> g0ldr4k3: You then need to tell MAAS about those virtual machines.
[09:28] <g0ldr4k3> allenap: no, I've 3 VM - 1 is RC and 2 are CC. on each CC I've enlisted 2 nodes.
[09:28] <g0ldr4k3> then in the RC I've added the 2 CC.
[09:28] <allenap> g0ldr4k3: How did you enlist them?
[09:29] <g0ldr4k3> my question is: if the RC is the main Svr and its goal is to manage the infrastructure why I see only the CC and their respective nodes no?
[09:30] <g0ldr4k3> I've created first the CCs and enlisted and allocated the node. then I've create a RC and added the 2 CC
[09:34] <g0ldr4k3> allenap: i think RC should manage all infrastructure and not only accepted the CC and that's all.
[09:35] <allenap> g0ldr4k3: You can’t enlist a node with a CC on its own; the CC must be associated with the RC before enlistment can happen.
[09:35] <allenap> g0ldr4k3: Now that the CC is associated with the RC, try enlisting again.
[09:41] <g0ldr4k3> you right, but it's not clear as explaining or as way to operate. As you said I'd have to make first RC then 2 CC and then enlisted the nodes via RC, is it right? if I've already 2 or more CC and I can manage the their respective nodes (enlisted, allocated and running) and then added CC to RC I'd should see the CC with their nodes!!!
[09:45] <g0ldr4k3> allenap:  you right, but it's not clear as explaining or as way to operate. As you said I'd have to make first RC then 2 CC and then enlisted the nodes via RC, is it right? if I've already 2 or more CC and I can manage the their respective nodes (enlisted, allocated and running) and then added CC to RC I'd should see the CC with their nodes!!!
[09:47] <allenap> g0ldr4k3: There are 3 ways to add a node to MAAS, but all of them require a CC registered with an RC. There’s “auto-enlistment” where the node PXE boots under MAAS’s control, there’s manual enlistment where you use the Add Node button or the command-line, and there are also probes for specialist hardware.
[09:48] <g0ldr4k3> ok, in my case I've used the first one where the nodes can use the PXE boot
[09:50] <g0ldr4k3> allenap: so, let's me know, the best way to realize that is to create first a RC then the CCs and then make the enlist of the nodes via RC?
[10:04] <allenap> g0ldr4k3: Yes. When you create the CCs, make sure they’re registered with the RC. When you register the CC you’ll need to import the boot images (there’s a button for it in the UI). Then you can enlist via PXE. The machine you’re enlisting should boot then shutdown, and the node should then be visible in the UI.
=== vladk|offline is now known as vladk
[10:08] <g0ldr4k3> I know the steps of the enlist of the nodes, but I can't image that the procedure to create that infrastructure is that! in this way I can view the nodes and the CC but now Ive another q why in the CC tab I see that but the association of the nodes no?
[10:10] <g0ldr4k3> allenap:  I know the steps of the enlist of the nodes, but I can't image that the procedure to create that infrastructure is that! in this way I can view the nodes and the CC but now Ive another q why in the CC tab I see that but the association of the nodes no?
[10:11] <g0ldr4k3> allenap: I mean the CC are added to RC enlisted the nodes but I can't see the association of nodes to CC.
[10:13] <g0ldr4k3> allenap: and in my case where I've already RC and CC working how can I enlist the nodes registered on each single CC on RC?
[10:15] <allenap> g0ldr4k3: I’m not sure I understand. A node cannot be registered to a CC. The CCs act like a proxy for the RC; they can’t do much without the RC.
[10:18] <g0ldr4k3> allenap: I'm sorry I made a mistake, I want say that once enlisted the nodes and viewed them on RC why in the Cluster' tab on RC not see that nodes are associated on CC?
[10:19] <anarca> Hello, MAAS'm new and I'm having a lot of problems because I get to put the nodes in Ready state
[10:20] <g0ldr4k3> anarca: now you've to allocated to start the ubuntu installer
[10:22] <anarca> I have one server MAAS and six nodes but these nodes are in state Commissioning
[10:24] <anarca> I need to put in Ready state to begin with juju
[10:25] <g0ldr4k3> anarca: ok now you have to change their status from Commissiong in Ready to make that your nodes should have PXE boot active or you have to run it manually....
[10:26] <anarca> Because  juju bootstrap tells me that there is no valid node
[10:27] <anarca> I've added manually
[10:27] <g0ldr4k3> anarca: I'm sorry but I  can help you with JUJU there is a guide explains how to make that https://juju.ubuntu.com/docs/
[10:28] <anarca> My problem in this moment is with MAAS nodes
[10:28] <g0ldr4k3> maybe the problem is in the authentication of the nodes JUJU works with MaaS using ssh and PXE
[10:29] <g0ldr4k3> allenap:  and in my case where I've already RC and CC working how can I enlist the nodes registered on each single CC on RC?
=== roadmr is now known as roadmr_afk
[10:30] <anarca> My current problem is how to change the status of the nodes of Commissioning to Ready
[10:31] <g0ldr4k3> anarca: manually if you added your nodes not using PXE boot
[10:33] <anarca> I have done so through their mac address and its status is commissionig
[10:33] <g0ldr4k3> now start them again
[10:35] <anarca> Do I reset the MAAS server?
[10:35] <anarca>  Sorry, it's my first contact with this
[10:36] <g0ldr4k3> allenap: in my case where I've already RC and CC working and nodes added to CC, how can I enlist the nodes registered on each single CC on RC?
[10:37] <g0ldr4k3> anarca: no I've to start manually the nodes no using MaaS
[10:38] <allenap> g0ldr4k3: That’s not how MAAS works. A node doesn’t get enlisted with a CC then an RC, it’s either enlisted or not. The CC does not track state or nodes; that’s all done in the RC.
=== vladk is now known as vladk|offline
[10:41] <g0ldr4k3> allenp: ok for that, in my case is there a way to see the nodes enlisted on RC? or I've to remove that from each single CC and then enlist them using RC.
=== vladk|offline is now known as vladk
[10:44] <bigjools> g0ldr4k3: please read http://maas.ubuntu.com/docs/nodes.html
[10:46] <g0ldr4k3> bigjools: I've already made that... my problem is another. I've a RC and 2 CC, each CC have 2 node enlisted on it,then I've added 2 CC on RC but I don't see the nodes status on RC
[10:47] <bigjools> yes, you already said that
[10:47] <bigjools> and we have said that you cannot "enlist" a node on a CC
[10:47] <g0ldr4k3> allenap: or best say,  how can I see the status of each single node on RC? I've to remove the Node from each CC and then make the same procedure to enlist them on RC
[10:47] <bigjools> please read the docment, it explains how to add nodes
[10:49] <g0ldr4k3> I'm sorry but I can understand how MaaS works.....
[10:49] <bigjools> http://maas.ubuntu.com/docs/orientation.html
[10:50] <anarca> I read it but i do not understand, sorry
[10:51] <bigjools> if you cannot understand the document then maas is probably not for you
[10:51] <g0ldr4k3> bigjools: that's right, if I see the picture I understand that CC manage the node and the a RC manage all infrastructure!!!!
[10:52] <g0ldr4k3> the node are added to CC
[10:54] <anarca> Maybe but unfortunately I did not choose my work
[10:56] <g0ldr4k3> bigjools: maybe who created that or wrote that guide had to explain well the infrastructure of MaaS....
[10:57] <allenap> g0ldr4k3: The nodes are *not* added to the CC. The CCs are mostly stateless proxies for the RC. You cannot add a node to a CC.
[10:57] <g0ldr4k3>  bigjools: because as illustrated not explain what you said....
[10:58] <g0ldr4k3> allenap: now it's clear but If I see the picture illustrated in the link I see that the nodes are added to CC
[10:58] <g0ldr4k3> allenap: and than RC manage that....
[10:59] <g0ldr4k3> allenap and bigjools: the guide reported also this "For small (in terms of number of nodes) setups, you will probably just install the Region controller and a cluster controller on the same server - it is only worth having multiple region controllers if you need to organise your nodes into different subnets (e.g. if you have a lot of nodes). If you install the maas package, it will include both a region controller and a cluster control
[10:59] <g0ldr4k3> ler, and they will be automatically set up to work together."
=== vladk is now known as vladk|offline
[11:02] <g0ldr4k3> allenap: have you tried to install RC package on a base ubuntu svr without CC package ot separate the environment? during the installer there is a error ""psql: could not connect to server: No such file or directory Is the │" why???
[11:04] <g0ldr4k3> allenap: if the RC enlist the all nodes my question is which is the CC's function?
=== vladk|offline is now known as vladk
[11:08] <allenap> g0ldr4k3: I don’t know why you’ve seen that error. Sorry about that. If you have time please file a bug.
[11:10] <allenap> g0ldr4k3: A CC encompasses a DHCP server, a DNS server, a TFTP server, and boot resources. The RC controls those things by sending jobs to the CC.
=== roadmr_afk is now known as roadmr
[11:24] <AskUbuntu> MAAS/juju not cleaning up nodes | http://askubuntu.com/q/488396
[11:34] <gmb> allenap, rvba: A branch for to review, per favore: https://code.launchpad.net/~gmb/maas/fix-get_all_interface_addresses/+merge/224600
[11:38] <allenap> gmb: I’ll take it.
[11:38] <gmb> ta
[11:40] <allenap> gmb: +1, simple as dat.
[11:40] <gmb> Ta :)
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== vladk is now known as vladk|offline
=== vladk|offline is now known as vladk
[12:04] <g0ldr4k3>  allenap: thanks for your support now more thinks are more clear for me!!
[12:05] <g0ldr4k3> allenap: this different is not explain in that guide...
[12:07] <g0ldr4k3> allenap: try to install RC on a base ubuntu svr and CC on another Svr to separate the system and you'll see that on the RC will have that error during the installer.
=== vladk is now known as vladk|offline
[12:14] <anarca_> Hello g0ldr4k3, I'll explain the process I've done:   Working with VirtualBox, I have created a machine that will be my MAAS server on which I installed ubuntu 13.04 server and also the desktop.   After I have created more than 6 VM will my nodes and I've installed ubuntu 13.04 server.   I have manually added the mac address of these nodes to the MAAS server and I can not change the status of the nodes.
[12:16] <anarca_> I followed this guide http://www.ubuntu.com/download/cloud/install-ubuntu-cloud
[12:29] <cobradevil> i think i have figured out my issues with using a local mirror
[12:29] <gmb> allenap: You’ll love this; there’s a bug in netifaces, I think: http://pastebin.ubuntu.com/7705634/
[12:29] <gmb> allenap: Check out ‘addr’]
[12:30] <cobradevil> when entering my own mirror in the maas interface it does not work when commisioning a node
[12:30] <cobradevil> after investigating i see that when not entering my own proxy it will use the proxy from the maas install squid-dep-proxy
[12:31] <cobradevil> and that one is not configured for using a local mirror
[12:31] <cobradevil> this is related to: https://bugs.launchpad.net/maas/+bug/1288502 and https://bugs.launchpad.net/maas/+bug/1300266
[12:31] <ubot5> Ubuntu bug 1288502 in MAAS "archive and proxy settings not honoured for commissioning" [High,Triaged]
[12:31] <ubot5> Ubuntu bug 1300266 in MAAS "squid-deb-proxy returns 403 when admin configures a custom APT archive" [High,Triaged]
[12:34] <cobradevil> when adding my own mirror to /etc/squid-deb-proxy/mirror-dstdomain.acl.d it works and the cloud-init runs ok and the status gets updated to ready
[12:55] <allenap> gmb: Oh nice. We can work around that, but maybe we can fix it upstream too.
[12:55]  * allenap looks
[12:56] <gmb> allenap: I’ve worked around it for now. Haven’t looked at upstream yet.
=== vladk|offline is now known as vladk
[13:20] <allenap> gmb: The %eth0 bit seems to be returned by getnameinfo(3). I don’t understand why though.
[13:25] <allenap> gmb: I think it’s related to http://tools.ietf.org/html/rfc4007 and http://tools.ietf.org/html/rfc6874.
[13:28] <gmb> allenap: I’ll read those after, but I’ll take your word for it :).
[13:28] <allenap> gmb: Yeah, I’m going to print them out and shred them ;) Actually, I’m going to hope they’re mentioned in IPv6 Essentials.
[13:42] <blake_r> allenap: gmb: rvba: could I get a review of this https://code.launchpad.net/~blake-rouse/maas/global-licensekey-model/+merge/224284
[13:45] <rvba> blake_r: sure, I'll have a look now.
[13:45] <blake_r> rvba: thanks
=== vladk is now known as vladk|offline
[14:15] <rvba> blake_r: "Got this structure from somewhere else in MAAS." → don't hesitate to fix that as well as a drive-by fix.  Always good to raise the quality of the overall code base, little by little, every time it's possible.
[14:16] <blake_r> rvba: okay let me find it again
[14:17] <blake_r> rvba: it was in bootimage, but i think it was done for a reason, because of get_by_natural_key
=== CyberJacob is now known as CyberJacob|Away
=== Solution-X|AFK is now known as Solution-X
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
=== roadmr is now known as roadmr_afk
=== CyberJacob|Away is now known as CyberJacob
=== mfa298__ is now known as mfa298
[20:07] <dpb1> Hi -- is there a MAAS version that will retry poweron of AMT?  What I have seems to just give up after one failed attempt
[20:11] <blake_r> dpb1: you can modify the template to retry if you like
[20:11] <blake_r> dpb1: /etc/maas/templates/power/amt.template
[20:12] <dpb1> blake_r: thanks.  any reason maas won't do this externally?  seems weird that it allocates a machine to me that it can't turn on
[20:13] <dpb1> blake_r: for instance, it could have given me a different machine.
[20:15] <blake_r> dpb1: wip https://bugs.launchpad.net/maas/+bug/1273222
[20:16] <ubot5> Ubuntu bug 1273222 in MAAS "MAAS doesn't check return values of power actions" [High,Triaged]
[20:17] <dpb1> blake_r: great
[20:17] <dpb1> thanks
[21:01] <dpb1> hey, anyone know about this: 500 No Host option provided at /usr/bin/amttool line 126. -- seems like maas is failing to lookup addresses in arp, and then just calling the script with no hostname/ip filled into the template.
[21:11] <dpb1> I've confrimed that is at least one failure mode here (from inspection)
=== Guest8558 is now known as wallyworld
[21:53] <dpb1> FYI I filed: https://bugs.launchpad.net/maas/+bug/1334863
[21:53] <ubot5> Ubuntu bug 1334863 in MAAS "amt arp lookup seems flaky" [Undecided,New]
[22:06] <roaksoax> dpb1: amt itself is flaky. you nee dto modify the bios somewhere to increase the timeout time IIRC
[22:08] <dpb1> roaksoax: we have.  doesn't invalidate the bug. :)
[22:08] <dpb1> roaksoax: we've switched to using IP and skipping ARP, I'll see if we get better results.
[22:09] <roaksoax> dpb1: yup, depending on ARP is definitely not the way to go. If it is not in the ARP cache, then it won't work. Using IP'
[22:09] <roaksoax> dpb1: yup, depending on ARP is definitely not the way to go. If it is not in the ARP cache, then it won't work. Using IP's is definitely more reliable
[22:10] <dpb1> cool
[22:21] <rharper> maas + trusty + some hp box where biosdevname switches eth0 -> em1  -- this breaks the installed network config which sets up eth0 into br0 for juju;  if you then attempt to run a container on that host, the container fails to launch because it's configured to use br0 (which only shows up if eth0 exists)
[22:21] <rharper> anyone seen this?
[22:25] <allenap> gmb, rvba: An IPv6-enabled TFTP server: lp:~allenap/maas/ipv6-tftp-compat. Note that I’ve only tested that it binds to IPv6 addresses, I’ve not actually tested transferring data! I’ll do that tomorrow. Now, for me, sleep.
[22:28] <allenap> gmb, rvba: Diff: http://paste.ubuntu.com/7708255/
=== Guest28217 is now known as wallyworld
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob
[23:52] <AskUbuntu> MAAS Connection Refused 8000 | http://askubuntu.com/q/488665