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