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