=== CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === freeflying is now known as freeflying_away === CyberJacob is now known as CyberJacob|Away === freeflying_away is now known as freeflying [03:13] bigjools: I'm thinking to address the issue by accepting zero as a vlan tag, but normalising it to None. [03:14] jtv: evil, but.... Django [03:14] In a word. [03:38] bigjools: by the way, have you seen those over-frequent DHCP config rewrites (and dhcpd restarts) lately? Or did they go away? [03:39] jtv: I have not checked, I can do so in a bit [03:39] I'd be grateful if you could. [03:39] will build a new package for my hp [03:41] And by the way, if you have time for a review... https://code.launchpad.net/~jtv/maas/zero-vlan-tag-is-not-unique/+merge/205073 [03:57] jtv: I don't suppose I can persuade you to go and edit the last migration that set this up? [03:58] You can, if you want to. [03:58] Having multiple migrations for the same new model is ugly as hell [03:58] I went with the safer option... If you want me to play dangerous with the schema, sure. :) [04:01] meh [04:10] bigjools: updated. [04:16] jtv: cheers [04:47] bigjools: one thing I didn't get around to bringing up... vlan tags: hex or dec? [04:52] jtv: either I guess, prefix with 0x if you want hex [04:57] If you want to get fancy, I say: separate card! [05:53] jtv: your signal fix has not worked [05:53] still getting lease write jobs after probes [06:04] Arrrrrgh. [06:04] O! [06:04] Wait... [06:09] No. For a moment I was hopeful that I'd simply forgotten to remove something. [06:10] bigjools: can you verify that you're running a version where src/maasserver/dhcp_connect.py connects dhcp_post_change_NodeGroupInterface to a _field change_ on NodeGroupInterface, not to a save? [06:11] jtv: I was running the daily build [06:11] 1.4+bzr1853+dfsg+1891+231~ppa0~ubuntu14.04.1 [06:11] so r1891 [06:11] I powered down the machine now so can't check code easily [06:11] From trunk, right, not 1.4? [06:11] yup [06:12] Ohdearohdearohdear [06:13] Hmm... was there really never a test for "does nothing if fields don't actually change"? [06:13] * jtv writes one [06:13] :) [06:15] Nope, nope, that passes. [06:15] So something else is triggering that signal. [06:15] * jtv throws some more hate at this use of signals [06:25] bigjools: I do see that leases are uploaded every minute as per the celerybeat schedule... [06:26] jtv: yes and then it writes dhcp and restarts server [06:26] Could you try it with a longer unconditional-dhcp-lease-upload schedule time? [06:26] can't today will come back tomorrow [06:26] OK. [06:27] It's just that this may be a side effect of the leases upload. [06:27] Which happens once a minute. [06:32] jtv: I am offski. Speak tomorrow. [06:34] nn bigjools === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [09:10] jtv: What I'm seeing is that the *DNS* config still gets rewritten every minute. [09:11] Different! [09:11] Julian said he saw the DHCP probe followed by the DHCP config rewrite. [09:12] He was running from package, so he wasn't looking at the "make run" output which combines all logs. [09:12] I don't see that. I see the DHCP probe followed by the DNS config rewrite. [09:12] In the same log? [09:12] I'm also running from a package. [09:12] I'm just making guesses about what he might have seen... [09:13] jtv: hang on, I forgot to look at one log file… [09:14] No trace of the DHCP rewrite. [09:14] (I'm using the daily package.) [09:14] So... progress. [09:15] jtv: Something else (but related): have a look at the apache log: http://paste.ubuntu.com/6884158/. As you can see, we first query ".../interfaces?op=list" and then we get redirected to "/interfaces/?op=list". If we could issue the right request from the start (with the '/' at the end), we would avoid one redirect every minute. This is a detail of course but I thought it was worth mentioning. [09:17] Yes... you can always file a tech-debt bug. :) [09:17] heh :) [09:21] jtv: src/maasserver/dns_connect.py says saving a NodegroupInterface triggers a full DNS rewrite… [09:21] Yes, DNS rewrites are more easily triggered. I was just looking for a DHCP rewrite... [09:40] bigjools: can you double check that you're still seeing the DHCP config being rewritten every minute? [09:41] bigjools: I just tested the daily package and I don't see that. I see the *DNS* config is still being rewritten every minute. [09:41] rvba: no I can't, sorry. But I was using the daily and it was definitely doing it on the cluster celery. [09:42] probe » config write » restart dhcp [09:43] I don't see that. And I've got a DHCP server configured and running. [09:44] ok I'll check again tomorrow [09:44] too late for me now [09:44] Okay. [09:44] eating with plate on my lap and the laptop on the arm of the chair here [10:11] A recipe for success... [10:14] jtv: bug filed: https://bugs.launchpad.net/maas/+bug/1276985 [10:14] Launchpad bug 1276985 in MAAS "The "Edit cluster interface" page shows an undocumented "Foreign dhcp ip" field." [Medium,Triaged] [10:14] bigjools: ^ (with screenshot ;)) [10:14] Thank you ubot5 [10:15] rvba: grar, docs [10:15] rvba: why do you keep talking about editing it? You can't edit it. [10:16] rvba: oh I see the page [10:16] my bad. WTF. That didn't used to be there. [10:17] bigjools: :) [10:19] * jtv is glad to see that the screenshot was of some use. [10:54] jtv: time for a tiny review? https://code.launchpad.net/~rvb/maas/fix-none-vlan/+merge/205119 [10:55] Sure [10:56] Thanks. === marcoceppi_ is now known as marcoceppi [13:57] hi, how can i completely remove maas? i have executed sudo "apt-get purge maas ; sudo apt-get autoremove" and rebooted the server, but after reboot, i am still able to open the MAAS dashboard... [14:06] ok, i have it already [14:31] hi, after executing "$ maas-cli maas node-groups import-boot-images" i get 'HttpResponse' object has no attribute '_is_string' [14:31] does anyone know what's the problem here? [14:44] tomixxx3: Can you try running `maas-cli refresh` and see if that fixes it? [14:44] gmb: hmm, now i have already started sudo maas-import-pxe-files [14:44] gmb: should i abort that? [14:45] gmb: furthermore, i have executed sudo add-apt-repository cloud-archive:tools and sudo apt-get-update before installing MAAS but it seems i always get version 1.0... [14:45] tomixxx3: No, just let it run [14:46] tomixxx3: What does `apt-cache policy maas` return? [14:47] gmb: ah, it says 1.4+bzr16934+ [14:47] gmb: but i see not the very same output and screens like described here: http://maas.ubuntu.com/docs/install.html#post-install [14:47] tomixxx3: Okay, what *do* you see? [14:48] gmb: slightly different screens and output most of the time ;) [14:48] gmb: for example, i cannot enter the IP address at start, i need to call dpgk-reconfigure... afterwards [14:48] gmb: on start i get a (wrong) IP assigned [14:48] gmb: furthermore, "--password" is missing in the createadmin statement [14:49] last but not least, i cannot execute maas-cli maas node-gruops import-boot-images [14:50] tomixxx3: Okay, one thing at a time. [14:50] tomixxx3: Have you created an admin yet? [14:50] gmb, i have done this installation for mulitple times now [14:51] gmb: i can create an admin, but i have to add "--password=xxxx" [14:51] thats not the problem [14:51] tomixxx3: So which of the things that you listed as a problem is actually the problem? :) [14:52] gmb: none of them [14:53] gmb: ah, when i set the http proxy in the maas dashboard, save, and delete the proxy again, it seems that the proxy does not appear even if it is not displayed anymore [14:53] gmb: but that's a looooooooong story [14:53] gmb: but the reason why i reinstall maas at the moment [14:55] another thing: nodes are not able to download packages [14:55] but maybo this is because of my tricky architecture [14:56] -appear, +disappear [14:56] but i know, we don't live in a perfect world ;) [14:58] tomixxx3: I'm not sure that this is something that we can solve easily over IRC — partly because you'll have to explain the whole architecture to me. Can you file a bug for the proxy issue please (https://bugs.launchpad.net/maas/+filebug) with instructions for reproducing the problem? [14:58] tomixxx3: Usually with nodes not being able to download packages that's a routing issue [14:59] tomixxx3: (Although they should just use the proxy if they can) [14:59] in short the architecute is: 2 nodes + 1 maas server connected via switch. additionally, a 2nd network interface in the maas-server connects the server to an external (university) network which is more or less a black box to me ;) [15:00] but i need the connection to the university in order to get internet-access - at least - at the maas-server [15:00] tomixxx3: Okay, that's not all that tricky; it's just that the nodes on the private / MAAS-managed network need to be able to get out to the internet *via* the MAAS server. [15:01] yeah... i have not achieved this milestone yet [15:01] however, i have tried a lot of things, i guess [15:01] tomixxx3: Two things you can do (assuming DHCP is set up correctly in MAAS; it should be from what you've said): [15:02] yep, dhcp works [15:02] tomixxx3: Okay, so, gimme a sec here... [15:02] k [15:02] gmb: altough, the problem is, also my university has a dhcp proxy which wants to give all my beautiful nodes some beuatiful IP :-) [15:03] therefore, i have two network interfaces [15:03] tomixxx3: Ah, okay, so you're *not* having to route all traffic out through the MAAS server then? [15:03] The nodes have two NICs each? [15:04] And one of those NICs on each node is connected to the university network [15:04] The other to MAAS [15:04] gmb: yes, they have fixed IPs from uni [15:04] gmb: but the problem is, if they get Ip from university and dhcp from university, they try to download images from university instead from maas server [15:05] tomixxx3: So. There's no need to plug them in to the university network *if* we configure the MAAS server to act as a gateway. [15:05] That should solve both that problem. [15:05] gmb: that's right. therefore i have 2 network interfaces at the server [15:05] gmb: the private network works together with the private maas dhcp [15:05] gmb: only problem left: how do the nodes are able to download their packages? [15:06] tomixxx3: Well, once the MAAS server is configured properly as a getaway (i.e. IPTables is set up, IP forwarding is turned on and so on) the nodes will be able to connect to the outside world through the MAAS server — essentially as though it were just a firewall. [15:06] Have you touched IPTables on the MAAS server already? [15:07] s/getaway/gateway/ [15:07] i have alredy tried sth with iptables but it did not work [15:07] but maybe i just misconfigured sth [15:07] i dont know well about iptables [15:08] i would appreciate if u could offer me some iptables statements just to put into "interfaces" file ;) [15:09] well, i can tell what i ve tried: "post-up iptables -t nat -A POSTROUTING -o eth1 -j Masquuerade" [15:09] i put this statement to eth0, which is connected to the nodes [15:09] and eth1 is the interface card which connects me to the university network and to the internet [15:09] tomixxx3: Okay, just working on a script for you to try. [15:10] gmb: kk, thank you, i really appreciate this! [15:18] tomixxx3: Try this script: http://paste.ubuntu.com/6885719/ [15:18] (on the MAAS server, run it as root) [15:19] kk, i do not have to modify the scrip in some way? [15:20] eth0 = private network, eth1 = university network [15:20] tomixxx3: I've already put those values in. [15:20] gmb: kk, thank you very much! [15:21] tomixxx3: No worries. [15:23] gmb: i have a question: [15:23] tomixxx3: Sure. [15:23] gmb: the dhcp packages from my maas-server will not travel to university-network? [15:23] gmb: i dont want do destroy university network [15:23] tomixxx3: If you've set up DHCP correctly it will *only* work on the private network. [15:24] gmb: even if lets say the range is 10.0.0.100 to 10.0.0.200 in my private network but also at the universtiy this range is used= [15:24] ? [15:25] tomixxx3: Well, I'd suggest using a different IP range — 192.168.1.0/24 for example — just to avoid confusion. [15:25] Otherwise you're going to have sad times if you do get it wrong. [15:25] Because you won't be able to tell which interface was on which network. [15:26] gmb: so i have to ask a network admin, if the ip range 10.0.0.100 to 200 is free? [15:26] just to clairfy [15:26] tomixxx3: No. [15:26] tomixxx3: It's a private network [15:26] You can use whatever range you like [15:26] tomixxx3: And it won't ever leak out into the outside world. [15:26] tomixxx3: Because the MAAS server is NAT'ing all the packets coming through it from the nodes. [15:27] and the server is only able to send dhcp pacakgeS WITHIN the private network [15:27] Correct. [15:28] but it would be different if i would BRIDGE both interfaces, right? [15:29] YES. [15:29] DO NOT DO THAT. [15:29] KK :-) [15:29] OR BAD THINGS (POTENTIALLY) HAPPEN [15:30] NAT on university networks is _much_ safer :) [16:50] i'm still new enough that i don't understand the stages a system goes through in maas. after i have a working MAAS server up and running and i power cycle a different node, that node netboots from MAAS and is "discovered" correct? [16:51] after "discovery" the node is powered down. next, i tell MAAS to "Commission" the node. the node is powered back up, netbooted from maas; maas runs some things on it and then powers it down again, correct? [16:52] i have a node whose status is "Commissioning" and is still powered up and has been this way since last week === CyberJacob|Away is now known as CyberJacob === zz_mwhudson is now known as mwhudson [23:04] bjf: your understanding is correct. Either the power detection is not working or it didn't PXE boot. [23:08] bigjools, ok, thanks [23:09] bigjools, it's beta HW so could be several reasons why it's "stuck" [23:09] bjf: you can check the power detection worked by going into the edit node page and see if the parameters are correct. which power type are you using? [23:09] ah ok :) [23:10] bjf: the other possibility is that the commissioning scripts are hung [23:10] which is always possible on new hardware [23:14] bigjools, i'm using CDU