[03:13] <AskUbuntu> Maas network connections | http://askubuntu.com/q/443149
[05:04] <jtv> bigjools: got time for some reviews?
[05:04] <bigjools> yeah I was just looking at your tgt one
[07:21] <jtv> gmb: any chance I could get some reviews out of you?
[08:07] <gmb> jtv: Sure.
[08:07] <jtv> Thanks.
[08:21] <gmb> jtv: Shifting to #maas because fists-of-bigjools-fury ;)… Yeah, IKWYM. No worries.
[08:21] <rvba> heh
[08:25] <rvba> bigjools: I see you've done 14.04 → none for bug 1187826.  For the fixes we backport to 1.5 I'm marking the related bug '14.04'… why is it wrong?
[08:25] <rvba> gmb: jtv Anyone knows? ^
[08:26] <gmb> rvba: From Jool’s email:
[08:26] <gmb> > Please make sure any bug fixes you land now are not on the 14.04 milestone,
[08:26] <jtv> Being left out of the backport as a new feature?
[08:26] <gmb> > we're done with uploads for that now (unless there's a critical bug).
[08:26] <rvba> gmb: oh
[08:27]  * rvba searches email
[08:27] <gmb> rvba: “Bug targeting and the 14.04 milestone"
[08:27] <gmb> Is the subject line
[08:28] <rvba> gmb: ah, okay.  Thanks.
[08:47] <jtv> By the way, don't be surprised: it looks like the lint checker has found a few new patterns to complain about.  A fix just landed.
[08:48]  * gmb -> afk for a little bit
[09:08] <rvba> jtv: added a comment on https://code.launchpad.net/~jtv/maas-test/no-import-ephemerals/+merge/213958, please consider what I say there.
[09:09] <jtv> rvba: perfect material for "file other bug"!
[09:09] <jtv> But... wasn't gmb working on this also?
[09:09] <rvba> Don't know, you guys sort it out :).
[09:10] <jtv> Well that _was_ sort of his cue to pop up and comment...
[09:25] <jtv> gmb: I take it your branch for the maas-test problem was more advanced than mine?
[09:53] <jtv> rvba: review it already!
[09:53] <rvba> jtv: hehe
[09:53] <jtv> Please?
[09:53] <rvba> Okay :).
[09:54] <jtv> Thanks.
[09:54] <jtv> I'll see if I can run my errand before it starts pouring down here.
[11:08] <jtv> allenap, gmb, rvba: once again I beg for reviews!  https://code.launchpad.net/~jtv/maas/boot-image-dict/+merge/214210
[12:56] <jtv> gmb: I wanted to ask if you were proceeding with your maas-test branch, or whether there is still a use for mine.
[13:35] <jtv> gmb: so... you're pursuing your maas-test branch, right?  Because mine is attracting far too much bikeshedding, and I'd love to just file cards/bugs and be done with it.
[13:35] <gmb> jtv: My brain is the same as yours except that it still runs m-i-e if we’re on a version of MAAS that needs it (i.e. one that has a bootresources.yaml.)
[13:36] <gmb> jtv: But I’m happy to land that if you want… We could do an end-run around all the complainers :)
[13:36] <gmb> branch
[13:36] <gmb> Not brain
[13:36] <gmb> My brain is *not* the same as yours.
[13:36] <jtv> Colder, for starters.
[13:36] <jtv> Which is probably good.
[13:36] <jtv> Anyway, we can file bugs then.
[13:37] <jtv> I hope I still can, because it's getting late and I'm falling asleep.
[13:38] <gmb> jtv: Okay. If not, let me know and I’ll file bugs. They might not be the same ones you’d file :)
[13:39] <jtv> Well they're all neatly laid out on my MP.... let me dig that up for you:
[13:39] <jtv> https://code.launchpad.net/~jtv/maas-test/no-import-ephemerals/+merge/213958
[13:50] <jtv> allenap, gmb, rvba: reviews!  Need reviews!  Please!  :)
[13:50] <gmb> jtv: Righto squire.
[13:50] <jtv> Thankee!
[13:51] <jtv> I'll file those new bugs for maas-test.
[14:02] <rvba> jtv: I also filed bug 1302617 (another consequence of the branch you're about to land).
[14:02] <jtv> Okay, I guess if everyone feels I'm about to land that branch, I guess I will.
[14:03] <rvba> heh
[15:34] <tych0> hi allenap, i have a question about the global http proxy
[15:34] <tych0> when i set it to something, nodes fail to commission because the packages can't be verified
[15:34] <tych0> or rather, the packages that the commissioning phase tries to install can't be verified
[15:35] <tych0> this seems like some sort of bug, i guess it is using my proxy instead of the squid deb proxy maas runs
[15:35] <tych0> and my proxy is doing something bad
[15:35] <tych0> but my proxy works just fine for m-i-e
[15:53] <allenap> tych0: I’ve not seen that problem. Can you file a bug report with info we need to reproduce it? Verifying packages doesn’t require special proxy support. Can you check the proxy logs to see if anything is being denied?
[15:54] <tych0> allenap: ah, something is getting denied
[15:55] <tych0> i guess that means my proxy is misbehaving?
[15:55] <allenap> tych0: Sounds like it :)
[15:55] <tych0> 1396625788.108      0 10.0.100.106 TCP_DENIED/403 3815 GET http://archive.ubuntu.com/ubuntu/dists/trusty-updates/universe/binary-amd64/Packages - HIER_NONE/- text/html
[15:55] <tych0> ok
[15:55] <tych0> so is it true that the user specified proxy should override maas' squid deb proxy, then?
[15:55] <allenap> tych0: Ah, that page doesn’t exist.
[15:55] <tych0> i guess that seems reasonable
[15:56] <tych0> oh
[15:56] <tych0> hm.
[15:56] <allenap> The “/403” might indicate HTTP 403 Forbidden.
[15:57] <tych0> yeah, that's what i was thinking
[15:57] <allenap> Ah, trusty-updates doesn’t exist yet, because trusty hasn’t been released.
[15:57] <allenap> No, it does.
[15:57] <allenap> Huh.
[15:57] <tych0> and then apt freaks out because it got a 403 and doesn't try to verify with the signatures
[15:58] <tych0> allenap: is there an easy way to see what is happening in the commissioning phase?
[15:58] <tych0> when it stops it dies and i have no way to look at apt's logs
[15:58] <allenap> tych0: No easy way. I don’t even know the hard way.
[15:58] <tych0> :-(
[15:58] <tych0> ok
[15:58] <allenap> roaksoax: Do you know ^?
[15:59] <tych0> this is in any case reproducable
[15:59] <tych0> if you set an http proxy (that isi a default squid3 intsall), it breaks commissioning
[15:59] <tych0> i'm not sure if that should be considered a maas bug or a PBKAC bug
[16:00] <tych0> i guess i don't really know what maas could do there, other than always use its own deb proxy for commissioning
[16:00] <allenap> I wonder why apt is getting upset when going through a proxy?
[16:01] <allenap> Ah, a default squid install probably doesn’t allow access from non-localhost?
[16:02] <tych0> well, it doesn't complain about not getting the packages
[16:02] <tych0> it complains about not being able to verify them
[16:02] <tych0> which is weird
[16:09] <roaksoax> tych0: can you update the host sources? sudo apt-get update
[16:09] <roaksoax> tych0: meaning, the maas machine running squid-deb-proxy might need to e updated to have the latest sources
[16:10] <roaksoax> tych0: that seems to be the problem
[16:10] <tych0> roaksoax: it isn't going through the squid deb proxy, though
[16:10] <tych0> it is going through my proxy that i set manually
[16:10] <tych0> which is not a squid deb proxy
[16:10] <tych0> that's what is causing it to fail
[16:12] <roaksoax> tych0: then you need to configure the proxy to let .deb pass through
[16:14] <tych0> roaksoax: i think it does let .deb through, just not the indexes or something?
[16:14] <Jeffrey_> So I came into work today, and was trying to boot some MaaS servers and all of a sudden TFTP started failing. I tried to telnet to port 69 on my Region/Cluster controller and TFTP isn't responding. How do I reset it?
[16:14] <roaksoax> tych0: that would make sense too
[16:15] <rvba> allenap: sorry to bother you with that but I've got a buildout question for you: I'm trying to build the docs for the 1.4 branch and I'm getting the usual 'Error: There is a version conflict. / We already have: Sphinx 1.2.2';  I tried adding 'no-site-packages = true' to ~/.buildout/default.cfg but it didn't work… any idea?
[16:15] <roaksoax> Jeffrey_: sydo service maas-pserv restart
[16:15] <roaksoax> Jeffrey_: check /var/log/maas/pserv.log
[16:15] <roaksoax> Jeffrey_: check /var/log/upstart/maas-pserv.log to see if it started fine
[16:15] <Jeffrey_> roaksoax: I checked pserv.log and it looks normal. I'll check the other log now.
[16:18] <Jeffrey_> roaksoax: The maas-pserv.log contains a line talking about replacing a pid file. The sudo service restart worked, but I am confused as to why it went down. There is nothing in either of those logs that looks out of place.
[16:18] <allenap> rvba: Are you building on trusty?
[16:18] <rvba> allenap: yes (I'm trying to)
[16:19] <roaksoax> Jeffrey_: what are you running? trusty
[16:19] <rvba> allenap: I _just_ want to build the docs.
[16:19] <allenap> rvba: And it’s all up-to-date?
[16:19] <roaksoax> ?
[16:19] <rvba> allenap: yes
[16:20] <allenap> rvba: bin/python -c 'import sphinx; print sphinx.__file__'
[16:20] <Jeffrey_> roaksoax: MaaS is 1.4+bzr1693+dfsg-0ubuntu2.3, and the cluster/region controller is running 13.10
[16:20] <rvba> allenap: using sphinx from my machine.
[16:20] <rvba> http://paste.ubuntu.com/7203914/
[16:21] <rvba> allenap: that's why it conflicts with what's in versions.cfg… but I can't make it not use the one from the machine…
[16:21] <allenap> rvba: Ah, 1.4! It wants sphinx 1.1.3. Trying apt-get purge python-sphinx.
[16:22] <allenap> Jeffrey_: That seems fairly old. Current in Trusty is 1.5+bzr2204-0ubuntu1.
[16:22] <rvba> allenap: but 'make install-dependencies' will re-install it…
[16:23] <allenap> Jeffrey_: Ah, sorry, misreading, you’re on 13.10. Sorry.
[16:23] <rvba> /var/lib/dpkg/tmp.ci/preinst: 17: /var/lib/dpkg/tmp.ci/preinst: Syntax error: "fi" unexpected (expecting "then")
[16:23] <allenap> rvba: Don’t run make install-dependencies then ;)
[16:23] <rvba> dpkg: error processing archive /var/cache/apt/archives/isc-dhcp-client_4.2.4-7ubuntu10_amd64.deb (--unpack):
[16:23] <rvba> Arg
[16:24] <rvba> allenap: that would work for a time but you see my problem, it's going to be a mess when we have to automate that on the machine in charge of generating the docs.
[16:25] <rvba> Damn, that problem with the dhcp-client package prevents me from removing python-sphinx.
[16:25] <allenap> rvba: The docs therefore need to be generated on machines that match their release, via containers for example.
[16:26] <rvba> allenap: this is a really painful constraint.
[16:26] <Jeffrey_> @allenap: Should I upgrade to Trusty?
[16:26] <allenap> rvba: We could create packages for them.
[16:27] <allenap> Jeffrey_: *I* would :)
[16:27] <rvba> allenap: we could (and we probably should)…
[16:27] <Jeffrey_> @allenap: Alright thanks.
[16:27] <rvba> Jeffrey_: you should.
[16:28] <Jeffrey_> @allenap: Trusty is still in beta. You would still recommend it over 13.10 for MaaS?
[16:28] <rvba> allenap: I thought we had a way to tell buildout to completely ignore the machine's packages?
[16:30] <allenap> Jeffrey_: I know that’s a cop out. We are making MAAS better all the time, so that’s an advantage of using Trusty. It’s not released yet, but not much is going to change for MAAS now. Also, Saucy was an interim release, so it didn’t get quite the same level of attention pre-release as Trusty is getting.
[16:31] <allenap> Jeffrey_: I just don’t want you to give me all the pieces if it breaks :)
[16:31] <Jeffrey_> @allenap: Yeah absolutely. Thanks for your help.
[16:32] <Jeffrey_> @allenap: I'll be coming to find you when it all fails :-P
[16:32] <allenap> rvba: It can be done, but we can’t do it because we need to use the system’s packages for non-testing deps.
[16:32] <allenap> rvba: We could add python-sphinx to required-packages/forbidden, then it’ll always get installed from PyPI.
[16:33] <allenap> rvba: However, I think the best solution here is to package it, depressing as that may be.
[16:33] <allenap> rvba: It might not be so bad: another binary package, but no new source packages.
[16:34] <rvba> allenap: isn't there a way to use PyPI for *all* the packages, just when running 'make doc'… something like a manual workaround…?
[16:35] <rvba> allenap: I'm trying to find a way to show all the docs for all the versions on the MAAS website… right now, I just need the 1.4 generated to do some testing… (i.e. I don't want to go trough creating a package just now).
[16:36] <allenap> Jeffrey_: Something that pserv in Trusty does that it didn’t in Saucy (iirc) is detect when network interfaces change, and re-bind accordingly. It can’t bind to *:69 For Technical Reasons™ so every so often (every 30 seconds, maybe) it checks.
[16:38] <allenap> rvba: Sure, don’t run make install-dependencies, or remove —system-site-packages from Makefile. However, some packages may not be found - they’re not on PyPI for example - or may not build. For example, psycopg2 depends on PostgreSQL’s libs. Building it from PyPI will require a C compiler and PostgreSQL’s headers.
[16:39] <rvba> allenap: okay, I'll fire up a canonistack instance and do the required surgery then ;).
[16:40] <allenap> rvba: And, in fact that may not work. We made an explicit decision to use system packages for non-testing-only dependencies, so you may find that some versions are not specified for them, or their dependencies.
[16:40] <allenap> and buildout gets fairly picky about that sort of thing.
[16:41] <allenap> rvba: Spin up Saucy on Canonistack then?
[16:41] <allenap> Or use an LXC container.
[16:41] <rvba> allenap: I'll see if I can manage without first; if it doesn't work, I'll spin up a Saucy machine.
[16:47] <allenap> rvba: I think packaging is an arcane and inhumane black art, but I bet adding a -doc package will not be that hard, then Launchpad can take care of building it, and the problem is solved for all time.
[16:48] <rvba> allenap: not entirely.  Consider the problem I'm trying to solve: we want to publish the documentation for all published versions of MAAS (on the same machine).
[16:49] <allenap> rvba: You won’t be able to install the packages, but you can download and unpack them.
[16:50] <rvba> allenap: right.  But that's still a manual process.
[17:09] <allenap> rvba: It can be scripted; that’s how MAAS gets shim-signed for example.
[17:11] <rvba> allenap: right.
[18:19] <xmltok-> do the images used for commissioning have a login that I can use to get on my node? they are not leaving the commissioning state and I want to see if the clock is in sync, i'm pretty sure it is
[18:27] <Jeffrey_> @allenap: Alright so I took the plunge and installed 14.04 and now none of the createsuperuser commands won't work. I've tried sudo maas createsuperuser and I've tried sudo maas createadmin.
[18:27] <Jeffrey_> All of MaaS is installed by the way.
[18:59] <xmltok-> i found my problem, it appears that WOL isnt enabled on my node or its not working, but booting up the nodes manually causes them to go to the ready state
[19:00] <xmltok-> now im getting somewhere!
[19:29] <xmltok-> hey, its working.
[19:29] <xmltok-> i suppose the requirement of WOL could be better defined in the installation docs
[19:30] <xmltok-> can maas install other operating systems? i am going to need to build enterprise linux boxes for the foreseeable future
[21:20] <xmltok-> can i change the ip of a maas node?