[00:03] <roaksoax> stokachu: after pxeboot id say you need to connect to the image and debug it
[00:04] <roaksoax> tych0: check restart pserv maas-dhcp-server etc
[00:04] <roaksoax> maas-pser
[00:07] <tych0> roaksoax: no luck with maas-pserv and maas-dhcp-server
[00:09] <roaksoax> tych0: try restarting rabbitmq-server maas-cluster-celery in that order
[00:09] <roaksoax> then maas-dhcp-server and maas-pserv
[00:11] <tych0> roaksoax: arg, no luck there either. gotta run, though, any other tips are welcome :-)
[00:20] <roaksoax> tych0: vms?
[00:20] <roaksoax> killbthe vm and start it again
[00:20] <roaksoax> dont just restart
[06:00] <AskUbuntu> Problem with IP Openstack MAAS | http://askubuntu.com/q/352570
[06:00] <AskUbuntu> MAAS login error | http://askubuntu.com/q/352573
[07:22] <nesusvet> hello everyone! )
[07:23] <nesusvet> Node writes the following massage: juju.state open.go:88 connection failed, will retry: dial tcp 127.0.0.1:37017
[07:24] <nesusvet> I opened the /etc/mongodb.conf file
[07:24] <nesusvet> and find out that mongodb port is port = 37017
[07:24] <nesusvet> ohh sorry, I mean 27017
[08:30] <jtv> nesusvet: you may have to ask someone in #juju what that implies first.
[08:32] <jtv> Juju runs MongoDB itself.  It may still be a MAAS problem, but the immediate meaning of the error message relates to Juju.
[08:34] <nesusvet> thanks jtv
[08:38] <freeflying> can I add mac address to a commissioned node in maas?
[12:37] <roaksoax> jtv2: around?
[12:42] <jtv> Hi roaksoax
[12:44] <roaksoax> jtv: howdy! so i figured things out so no worries :)
[12:58] <jtv> Ah
[14:48] <stokachu> is maas-region-controller forcing a preconfigure even if setting non interactive flag in apt?
[16:26] <stokachu> im attempting to force non interactive with maas install " apt-get install -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' -f -q -y maas maas-dns maas-dhcp" however the maas/installation-note template is being shown regardless
[16:29] <dpb1> stokachu:  DEBIAN_FRONTEND=noninteractive in front of all that?
[16:29] <stokachu> dpb1: yea
[16:29] <dpb1> and what about < /dev/null at the end?
[16:30] <stokachu> ah didnt add that
[16:30] <stokachu> lemme try with that
[16:32] <roaksoax> allenap: around?
[16:32] <roaksoax> allenap: could you please add maas-maintainers as bug subscriber for https://launchpad.net/ubuntu/+source/djorm-ext-pgarray
[16:33] <allenap> roaksoax: Sure.
[16:33] <roaksoax> allenap: thanks!
[16:37] <stokachu> dpb1: sweet that worked!
[16:37] <stokachu> thanks :D
[16:38] <dpb1> nice.  when in doubt, old shell tricks to the rescue
[16:38] <stokachu> dpb1: most definately
[16:46] <allenap> roaksoax: Where's the best place to see commissioning errors?
[16:47] <roaksoax> allenap: in the image itself
[16:47] <roaksoax> allenap: you'd need to connect to the image
[16:48] <allenap> roaksoax: Doesn't it shut down when commissioning is complete?
[16:48] <roaksoax> allenap: you can prevent it from doing so: https://lists.launchpad.net/maas-devel/msg00808.html
[16:53] <roaksoax> allenap: that's why we were requesting a way to store that info in maas and make it available
[16:54] <allenap> roaksoax: That shouldn't be too hard to do now, with built-in commissioning scripts.
[16:54] <roaksoax> allenap: indeed, but I think they do report back to maas
[16:54] <roaksoax> smoser: ^^
[16:55] <allenap> roaksoax: Btw, thanks for your help.
[16:55] <roaksoax> np
[16:56] <kentb> which cloud-tools ppa do I need to be connected to to get the latest stable juju / maas packages for precise? Is it "deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/cloud-tools main" ?
[17:00] <stokachu> kentb: yea thats what ive been using
[17:00] <kentb> stokachu: ok. cool. thank you
[17:00] <stokachu> np
[17:04] <smoser> kentb, stokachu, roaksoax uploaded a new maas to saucy yesterday
[17:04] <smoser> but its not into that cloud-tools yet.
[17:04] <kentb> ok. thanks for the heads up
[17:04] <smoser> roaksoax, allenap you should be able to post back results. errors or othereise.
[17:04] <smoser> right ?
[17:05] <stokachu> smoser: cool thanks
[17:05] <roaksoax> stokachu: we are waiting for approval from the release team
[17:06] <allenap> smoser: Yeah, you can.
[17:06] <allenap> smoser: It's limited to 1MB right now, but we could extend that.
[17:07] <smoser> i'd think you shoudl extend it, but that shoudl'nt be a problem.
[17:07] <smoser> realistically, thats a hell of a lot of text
[17:08] <stokachu> im running maas in a vagrant-lxc container
[17:08] <stokachu> pretty sweet
[17:20] <roaksoax> smoser: how do we enable the use of curtin now?
[17:22] <smoser> tags i think
[17:22] <smoser> http://bazaar.launchpad.net/~smoser/+junk/xinstall/view/head:/maas-usage.txt
[17:24] <roaksoax> smoser: thanks
[17:38] <kentb> so if I wanted to run maas - 1.4+bzr1551 on raring, is there a way to get that?
[17:39] <stokachu> kentb: if you needed it right now you could use backportpackage
[17:39] <stokachu> and just backport from saucy
[17:39] <kentb> stokachu: ok. yeah, good idea
[17:40] <stokachu> kentb: im not sure what maas devs release schedules are like to know when it would land in raring
[17:40] <kentb> stokachu: ok. makes sense.
[17:41] <stokachu> kentb: i would say use this but it hasn't been built yet
[17:41] <stokachu> https://launchpad.net/~maas-maintainers/+archive/dailybuilds?field.series_filter=raring
[17:42] <stokachu> kentb: looks like i have access to request builds
[17:42] <stokachu> kentb: just launched it for raring
[17:42] <kentb> stokachu: sweet! thanks!
[17:42] <stokachu> np :)
[17:44] <stokachu> kentb: crap it just does 1.3
[17:45] <stokachu> kentb: i would just use backportpackage then
[17:52] <kentb> stokachu: ok
[18:44] <smoser> roaksoax, tell me you fixed bug 1231693
[18:47] <roaksoax> smoser: nope, I thought you were looking at it
[18:47] <smoser> well, i have a fix attached to it. but i was hoping you would hyave picked it up.
[18:48] <smoser> can you take a look and see if you have a better idea for how to patch it?
[18:48] <roaksoax> smoser: looks good to me
[18:49] <smoser> k. i'll do a MP. to lp:ubuntu/maas
[18:49] <roaksoax> smoser: could you please do it to lp:maas-maintainers/maas/packaging?
[18:49] <smoser> yeah
[18:49] <roaksoax> smoser: that way It can be solved in the next upload
[18:49] <smoser> what is the relationship to that and trunk ?
[18:49] <smoser> ah
[18:50] <smoser> i see
[18:50] <roaksoax> smoser: packaging trunk is lp:maas-maintainers/maas/packaging
[18:50] <smoser> trunk has no debian/
[18:50] <roaksoax> correct!
[20:28] <roaksoax> smoser: let me know when you propose for merging the upstart thing so I can upload a new maas today
[20:29] <smoser> roaksoax, i'm working on it.
[20:54] <roaksoax> smoser: did narinder talk to you about enabling curtin in saucy?
[20:54] <roaksoax> with the new preseed and stuff?
[20:54] <smoser> asked about enabling, yes
[20:56] <smoser> roaksoax, i dont think that this bug should exist
[20:56] <roaksoax> smoser: how so?
[20:56] <smoser> dpb1, bug 1231693
[20:56] <smoser> because current packaging only assumes precise
[20:56] <smoser> err...
[20:57] <smoser> assumes the behavior found in quantal
[20:57] <smoser> (quantal or later)
[20:57] <smoser> of isc-dhcp-server
[20:57] <smoser> and cloud-archive cloud-tools will only have isc-dhcp-server at that level.
[20:57] <roaksoax> smoser: right, but also assumes that we would be using the isc-dhcp-server on precise was the same as is on the precise archives (and the CA is backporting a version of isc-dhcp
[20:58] <smoser> look at the current packaging branch
[20:58] <smoser> debian/maas-dhcp.maas-dhcp-server.upstart
[20:58] <smoser> there is no "if precise" logic htere.
[20:58]  * dpb1 reads scrollback
[20:58] <roaksoax> if [ "$RELEASE" = "precise" ]; then
[20:58] <roaksoax>         owner_group="dhcpd:dhcpd"
[20:58] <roaksoax>         dhcpd_owner_opts=""
[20:58] <roaksoax>     else
[20:58] <roaksoax> smoser: ^^
[20:58] <smoser> roaksoax, where did you see that ?
[20:59] <roaksoax> smoser: in debian/maas-dhcp.maas-dhcp-server.upstart for saucy (which is what you are backporting to the CA)
[20:59] <roaksoax> s/you/we/
[20:59] <roaksoax> smoser: the problem is that the cloud-tools-next pocket is *also* backporting a isc-dhcp from *saucy*
[20:59] <smoser> what the hel
[21:00] <roaksoax> smoser: hence, the upstart jobs goes "if release is precise, I assume we are using isc-dhcp *from* precise"
[21:00] <roaksoax> hence, set owner_group to dhcpd:dhcpd
[21:00] <dpb1> backporting is fun
[21:00] <roaksoax> smoser: but since the cloud-tools-pocket next is providing a isc-dhcp-server that requires ownership to be *root:root* then it fails
[21:00] <smoser> shoot.
[21:01] <smoser> i had out of date bzr here.
[21:01] <smoser> the fix that was put in
[21:01] <smoser> adding that logic around "if release"
[21:01] <smoser> is what actually broke this for us if we had cloud archive
[21:01] <roaksoax> smoser: not really the logic, because the logic assumes that we are using isc-dhcp *from* precise
[21:01] <smoser> since cloud-archive is quantal-style behavior for isc-dhcpd
[21:01] <smoser> right.
[21:01] <roaksoax> and the cloud-archive is providing isc-dhcp *from* saucy
[21:01] <smoser> but if they didn't add that logic
[21:01] <smoser> they would have acted like saucy
[21:01] <smoser> and worked
[21:02] <smoser> because cloud-archive isc-dhcp-server is saucy
[21:02] <roaksoax> smoser: yes, but that logic was added under the assumption that we *will* be using isc-dhcp *from* precise
[21:02] <roaksoax> not from saucy
[21:02] <smoser> right.
[21:02] <smoser> and that assumption is wrong.
[21:02] <smoser> so
[21:02] <smoser> we have 2 options
[21:02] <dpb1> smoser: didn't your patch change it to a behavior based evaluation, not release-based?
[21:02] <roaksoax> smoser: not really, it is not wrong because it was the assumption that the fix for client-uids would have landed in precise too
[21:03] <smoser> a.) code a more complex fix (like shown int hat bug) that accounts for different behaviors of isc-dhcp
[21:03] <smoser> b.) do not support trunk maas on precise without isc-dhcp-server > 4.2
[21:03] <smoser> roaksoax, it would still be wrong there.
[21:03] <smoser> as if we backported the client-uuids to precise it would not change the ownershp behavior to saucy/quantal behavior
[21:04] <roaksoax> saucy/quantal use root:root
[21:04] <smoser> right.
[21:04] <smoser> and that is waht cloud-archive uses
[21:04] <smoser> as it uses saucy isc-dhcp-server
[21:04] <roaksoax> smoser: correct, but the idea was to backport the minimum possible in the CA
[21:04] <roaksoax> correct?
[21:04] <dpb1> change the package dependencies, and take out the if clause, is that what you are proposing, smoser in b.)?
[21:04] <roaksoax> so that client=-uids fix would have landed in precise with the appropriate technical board exception
[21:05] <roaksoax> hence, not requireing us to backport an isc-dhcp to the CA
[21:05] <roaksoax> which means, that the fix would have worked
[21:05] <roaksoax> that is the reason why that distiction exists
[21:06] <smoser> roaksoax, wrong. the idea is to use ubuntu-current-release versions backported.
[21:06] <roaksoax> because there was the assumption that the client-uids fix will land in *precise* (which never did), *and* at the time, we never had the idea that we will have a cloud-tools pocket
[21:06] <smoser> ah. yeah, so that would be a possbility.
[21:06] <smoser> if we want ot support that.
[21:06] <smoser> i dont really want to
[21:07] <roaksoax> smoser: correct, so at the end of the day, I agree that we can drop that from saucy'
[21:07] <smoser> the easiest thing to do is just depend on > 4.2 and say sorry, trunk maas only works on precise with cloud-archive version of isc-dhcp-server
[21:07] <roaksoax> smoser: correct, so at the end of the day, I agree that we can drop that from saucy's packaging
[21:07] <roaksoax> i was just making sure why this was done that way
[21:07] <smoser> right
[21:07] <roaksoax> so you could understand the logic placed there
[21:07] <roaksoax> smoser: ok, so let's just drop that
[21:07] <roaksoax> and we should be good to go
[21:10] <smoser> roaksoax, funny
[21:10] <smoser> it doesn't work anyway
[21:10] <smoser> i'im confused on how it workd
[21:10] <roaksoax> it should work
[21:10] <smoser> because if you try to run this on 12.04 isc-dhcp-server
[21:10] <smoser> then it app-armor fails
[21:10] <smoser> [ 6638.305979] type=1400 audit(1380748171.914:45): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/dhcpd" name="/var/lib/maas/dhcp/dhcpd.leases" pid=16582 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=106 ouid=106
[21:10] <smoser> ah. no i see m
[21:11] <smoser> maas delivers a fix for that and  I didn't have it.
[21:21] <smoser> roaksoax, http://paste.ubuntu.com/6185681/
[21:21] <smoser> thats my complex patch
[21:21] <smoser> i'm way past "have to go now"
[21:21] <smoser> could you just disable that "run on precise" logic and fix it?
[21:32] <smoser> roaksoax, https://code.launchpad.net/~smoser/maas/packaging.1231693/+merge/188932