[00:00] <Daviey> jtv: are you alive yet?
[00:04] <mgz> why are you still alive Daviey...
[00:12] <Daviey> dammit.. it was HIM i wanted
[00:12] <Daviey> git!
[08:12] <Daviey> allenap: Mornin'
[08:22] <Daviey> mgz: Mornin'
[08:22] <Daviey> mgz: I could do with chatting to you :_
[08:24] <mgz> Daviey: sur
[08:25] <mgz> er... sure, not french for on.
[08:26] <Daviey> mgz: Well.. tags.. they should be working right?
[08:26] <Daviey> as in, commissioning should be discovering some characteristics ?
[08:26] <mgz> Daviey: yup.
[08:27] <Daviey> mgz: If i told you it was returning an empty set for arm and G-lab, what would you say?
[08:27] <mgz> we don't create any default tags at the moment, so you need to set them up yourself
[08:27] <Daviey> Oh!
[08:28] <Daviey> how come?
[08:28] <mgz> but filling in cpu_count and memory uses a similar mechanism, so if your nodes have those then tags will works
[08:28] <mgz> mostly because we don't know what people actually want
[08:28] <Daviey> mgz: ii'm just seeinf []
[08:28] <Daviey> seeing*
[08:28] <mgz> I like the idea of documentation explaining how to do things and having examples
[08:29] <Daviey> mgz: I imagined we'd get defaults of mem-$(free -g) and cpu-(numbr of cores) at least
[08:30] <mgz> well, we have that anyway with the mem and cpu values
[08:30] <Daviey> how do i query it then?
[08:30] <mgz> via what means? you use the juju constaint form, either when acquiring a node, or on the nodes page on the site
[08:31] <Daviey> mgz: http://pb.daviey.com/E2TV/
[08:31] <mgz> ie, http//maas.dev:5240/nodes/?query=cpu=4
[08:32] <mgz> right, unless you add some tags, your nodes will not have any tags :)
[08:32] <mgz> so, use the commandline client to create some
[08:33] <Daviey> mgz: I'm sorry if i am being dumb.. but how does that work?
[08:33] <mgz> you supply a tag name, a definition, and optionally a comment
[08:33] <Daviey> how does a definition work?
[08:34] <mgz> the name is what you use to look up against nodes, the definition is an xpath that runs against the lshw output
[08:34] <Daviey> mgz: http://192.168.9.1/MAAS/nodes/?query=cpu=24 is null by default?
[08:34] <mgz> a trivial test is using 'true' as the definition, that will then be set on all nodes
[08:34] <Daviey> mgz: Ok, is this captured in doc's?
[08:35] <mgz> you have nodes with 24 or more cpus?
[08:35] <Daviey> yes
[08:35] <Daviey> 15 of them :)
[08:35] <mgz> if you select one of them, do they have the correct cpu count?
[08:36] <Daviey> ah, interesting.. they do no
[08:36] <Daviey> they show 2!
[08:36] <mgz> there is no user-facing docs yet, we needed code in for freeze, we need docs for release
[08:36] <Daviey> and 49152 MB mem
[08:36] <Daviey> (should be 42GB!)
[08:37] <mgz> okay, so the trick will be to find out if it's the lshw output that's wrong, or our query
[08:37] <mgz> if you can extract that and post it somewhere, will tell you if it's a platform bug or a maas bug
[08:37] <Daviey> ok
[08:38] <mgz> so, if you look at that output, there may be some other facet you care about, which you can then add a tag for
[08:38] <mgz> (it's not that useful with an entirely homogeneous cluster)
[08:39] <Daviey> http://pb.daviey.com/fKJs/
[08:39] <mgz> ...we probably want an easy way of getting that lshw stuff as I suspect this might be a common support question
[08:40] <mgz> that lists two cpus.
[08:40] <Daviey> hmm, only showing two cpu's.. but multiple cores i guess
[08:40] <Daviey> this one has 24 cores, ubuntu@node-0025904c7eb4:~$ cat /proc/cpuinfo  | grep processor | wc -l
[08:40] <mgz> with multiple cores and threads per cpu
[08:40] <Daviey> 24
[08:41] <mgz> what's the actual box? two hexacore chips with hyperthreading?
[08:41] <Daviey> mgz: So.. is physical cpu, or core more important ?
[08:41] <Daviey> mgz: NFI
[08:41] <Daviey> ubuntu@node-0025904c7eb4:~$ sudo dmidecode | pastebinit
[08:41] <Daviey> http://pb.daviey.com/SOhU/
[08:42] <mgz> probably the core count.
[08:42] <mgz> plus or minus hyperthreading
[08:43] <mgz> okay, so example tag to match that
[08:43] <mgz> I'm not sure the exact thing you use via the client, but it's along the lines of
[08:46] <mgz> *... addtag* --name dual_hexacore --definition "count(//node[@class='processor']/configuration/setting[@id='cores' and @value=6]) = 2"
[08:47] <Daviey> mgz: Do you have ideas how we could add some common ones OOTB?
[08:47] <Daviey> such as that
[08:47] <mgz> well, that one doesn't seem common, but adding anything you suggest as examples would be fine :)
[08:47] <Daviey> Users can always delete them.. but this feels so complex, that nobody will bother using it without some already provided
[08:47] <mgz> right, so one option is to fake instance types a little
[08:48] <Daviey> mgz: Do you want to list some viable defaults ?
[08:48] <mgz> so, have a few set tags that are "box with about cpu/mem/other of X'
[08:49] <Daviey> sounds reasonable
[08:49] <Daviey> what do others think?
[08:50] <mgz> the downside is composite tags like that will be very complicated compared to single purpose ones that just look at one detail of a box
[08:50] <Daviey> right
[08:50] <mgz> so, it's good to provide them, but they're bad examples to work off
[08:51] <mgz> Daviey: can you file a bug about your cpu_count and attach that lshw output?
[08:51] <mgz> because that wants fixing regardless I suspect
[08:53] <Daviey> mgz: cpu_count should be cores rather than physical cpu's?
[08:54] <mgz> that makes more sense to me
[08:58] <mgz> jam: it's meant to be your day off!
[08:58] <mgz> bad jam.
[08:59] <lifeless> Daviey: prob /proc reported cpus, so neither physical nore cores.
[09:02] <Daviey> lifeless: I'm not qutie sure what i am seeing.  I assumed /proc/cpuinfo == lshw :)
[09:02] <Daviey> but it does not.
[09:14] <jam> mgz: I'm off, I'm browsing for cars, and figured I'd check email.
[09:14] <jam> too much crap to do when moving...
[09:15] <jam> mgz: what do you think about leaving out the 'bank:' in the xpath
[09:15] <jam> better to have it or not have it?
[09:15] <jam> It feels like we're getting to the place where that XPATH expression should be a configuration variable, so it can be tweaked in the field.
[09:23] <jam> mgz: plus, if I can spend 5-10 min to keep you guys unblocked, as long as my wife doesn't notice, it is time well spent :)
[09:24] <rbasak> Daviey: please could you see bug 1065763? This is dannf's issue from yesterday.
[09:25] <rbasak> As a dpkg-reconfigure maas-region-controller fixes it, I'm concerned that there's a postinst ordering issue
[09:27] <mgz> the startswith() is a bit ugly, maybe using @class instead would help, but from the two compeltely different ways of listing memory it's a bit tricky to make one sane expression
[09:28] <mgz> I am getting the the point of thinking we need to give people a really easy way of getting at the lshw output if it's going to be this variable
[09:28] <Daviey> rbasak: ugh
[09:28] <mgz> otherwise trying to workout what's wrong with an expression will be taxing...
[09:29] <mgz> the one issue with having the cpu and mem expressions stored as data rather than code is the migration needs them, and has limited access to stuff, but can probably get around that
[09:29] <Daviey> rbasak: Have you identified what is exactly not happening ?
[09:30] <rbasak> Daviey: no, I've not looked at all. I can't reproduce.
[09:30] <rbasak> I've not attempted to reproduce by altering postinst ordering mind.
[10:18] <jam> mgz: as for data vs code, we could always have a default, and a way to poke a new expression into the system. (store in the db, rather than in the config)
[11:45] <jtv> allenap, jam: it's getting busy in the review department...  remember to claim reviews you're working on, to cut down on duplicate effort!
[12:36] <mgz> okay, posted pagination bits.
[13:46] <roaksoax> rbasak: it doesn't seem to me that the postinst ordering is the problem
[13:47] <roaksoax> rbasak: it seems to me that credentials for maas_workers in rabbitmq are the problem
[13:47] <roaksoax> rbasak: that's why it works on reconfigure
[13:47] <roaksoax> Daviey: ^^
[13:47] <rbasak> roaksoax: ok
[13:47] <rbasak> roaksoax: I'm not familiar with the packaging
[13:48] <roaksoax> dannf: do you happen to have an installed system that failed to install maas without reconfiguring?
[13:50] <roaksoax> rbasak: thank your for looking at it though :)
[13:50] <Daviey> roaksoax: Have a fix?
[13:51] <roaksoax> Daviey: trying to reproduce and see if it is exactly what i think it is :)
[14:02] <jtv> Oh, hi Daviey, hi roaksoax -- better help output for maas-cli is ready to land.  Unfortunately the cron job doesn't seem to be landing it yet.
[14:07] <roaksoax> Daviey: http://pastebin.ubuntu.com/1274979/
[14:10] <Daviey> jtv: sweet
[14:10] <jtv> The formatting may look a bit crap; I'm working on that.
[14:11] <roaksoax> Daviey: it seems rabbimq issue
[14:11] <Daviey> crap
[14:11] <Daviey> i saw a race with that earlier
[14:15] <jtv> allenap: trying the regular HelpFormatter for maascli... actually looks better!  Any idea why we're using the RawDescriptionHelpFormatter?
[14:19] <roaksoax> Daviey: yeah so the user doens't get created
[14:21] <allenap> jtv: Because the default formatter mangles the help text that contains :param foo: bits. It also smushes everything into a single paragraph.
[14:22] <roaksoax> Daviey: ok, so the postinst creates 2 rabbitmq users. The first one creates correctly. However, for the installer, before we create the user we restart rabbitmq (force restart).
[14:23] <roaksoax> Daviey: now, that we have 2 rabbitmq users... the fix seems to be that we should restart rabbitmq *again* for the installer
[14:23] <roaksoax> Daviey: this will restart rabbitmq 2 times on install
[14:29] <jtv> allenap: ah yes...  I guess I'll just have to format the input text then.
[14:30] <Daviey> roaksoax: why does it need restarting ?
[14:31] <roaksoax> Daviey: in the installer... because we should not run dameons on installation? and apparently after the user creation it dies or somthing happens
[14:31] <roaksoax> Daviey: that's the same issue we had last cycle
[14:32] <roaksoax> Daviey: so we had to force rabbimq to be running during the installer
[14:32] <Daviey> I wonder if dpkg-triggers could do what we need
[14:34] <roaksoax> Daviey: it would be the same wouldn't it?
[14:34] <roaksoax> Daviey: because it would also happen during the install when we need rabbitmq running
[14:35] <Daviey> roaksoax: Hmm, i'm not sure
[14:35] <Daviey> my gut says it's the solution, but i'd need to dig deeper
[14:56] <roaksoax> Daviey: doesn't seem to be fixed by trying to restart rabbigmq again
[14:56] <roaksoax> rabbitmq
[14:56] <Daviey> poop
[15:01] <dannf> roaksoax: i don't, but i can recreate one
[15:03] <roaksoax> dannf: no worries, I know what the issue is
[15:22] <roaksoax> Daviey: ok so it seems that there's no easy way to fix this
[15:23] <Daviey> roaksoax: what is the hard fix?
[15:23] <Daviey> roaksoax: Are you sure dpkg-trigger isn't the right fix?
[15:23] <roaksoax> Daviey: so i tried trying to restart again, it doens't really create the user
[15:23] <roaksoax> Daviey: i tried to force the start (as we do with postgresql), it doesn't work
[15:23] <Daviey> 677840
[15:24] <roaksoax> Daviey: i have a couple of other ideas but we'll see
[15:24] <roaksoax> Daviey: and for the little I read... maybe not
[15:24] <roaksoax> bug #677840
[15:25] <roaksoax> Daviey: is that a bug number?
[15:25] <Daviey> err, no
[15:25] <Daviey> it was an accidental OTP :)
[15:25] <roaksoax> lol
[15:40] <roaksoax> Daviey: well it seems tha triggers might be an option but idk whether that will work on a reboot
[15:45] <Daviey> i thought they should work 'when satisfied'
[15:48] <roaksoax> Daviey: right, so this would involve modifying rabbitmq
[15:49] <roaksoax> Daviey: "This feature is heavily used to track changes of packaged files in a list of predefined directories, and to update other files based on this."
[15:50] <roaksoax> uhmmm these talks about files
[15:50] <roaksoax> but this cause is not handling filse, is having a server daemon running
[15:53] <roaksoax> allenap: maas already supports https?
[16:51] <roaksoax> smoser: around?
[16:51] <smoser> here
[16:51] <roaksoax> smoser: could you verify bug #1065259 please?
[16:53] <smoser> roaksoax, i can try
[16:53] <roaksoax> smoser: thanks!
[16:54] <roaksoax> Daviey: ok.. so ... tried many things by fixing the postinst and still no lock, os no idea of what might be wrong
[16:54] <Daviey> urgh
[16:54] <Daviey> This is potentially a big deal
[16:54] <smoser> roaksoax, whats wroong?
[16:55] <Daviey> maas install bug from cd
[16:55] <roaksoax> smoser: idk whether you recall that during last cycle, we needed rabbitmq running in the installer in order for us to create the longpoll rabbitmq user, and etc
[16:55] <Daviey> ie, release critical
[16:56] <roaksoax> smoser: so now, we not only create 1 rabbitmq user, but 2, and the second one doesn't get created
[16:57] <roaksoax> smoser: or how can I add -proposed automatically?
[16:57] <roaksoax> to eh enlist user-data
[16:58] <roaksoax> smoser: this is the installre bug #1065763
[16:58] <smoser> roaksoax, enlistment?
[16:58] <roaksoax> smoser: yeah, so i'd like to add -proposed on cloud-init user data, is that possible?
[16:59] <roaksoax> i mean, so that the userdata can grab the enlist image from there
[16:59] <smoser> roaksoax, well, you dont really have to.
[16:59] <smoser> you can, but in a daily, the maas-enlist is already there.
[16:59] <smoser> the most recent daily
[17:00] <smoser> i copied the SRU'd maas-enlist to maas-ephemeral ppa
[17:00] <roaksoax> smoser: ok so then we can mark it as verified then?
[17:01] <smoser> well, if you verify it you can :)
[17:02] <roaksoax> smoser: that's why I was asking.. in order to verify we need to get it from proposed :)
[17:03] <smoser> ok.
[17:03] <smoser> a.) you dont need to do that. you could just use the daily of precise. it would have it.
[17:03] <roaksoax> smoser: right but we need to veirfy what's in proposed not on the daily even though you copied it :)
[17:03] <smoser> b.) you can (i suggest trying it) add a ppa by adding the appropriate cloud-config content to /usr/share/maas/preseeds/enlist_userdata
[17:04] <smoser> apt_sources:
[17:04] <smoser>  - source: deb $MIRROR $RELEASE-proposed main
[17:04] <smoser> roaksoax, ^ add that and "should work"
[17:05] <roaksoax> smoser: cool thanks
[17:08] <roaksoax> allenap: does maas already support HTTPs?
[17:21] <smoser> roaksoax, do you want me to try to do this?
[17:21] <smoser> to verify?
[17:21] <roaksoax> smoser: i already did
[17:21] <smoser> oh. ok.
[17:21] <roaksoax> thanks tho
[17:22] <smoser> so my advice worked?
[17:22] <smoser> did you use a daily ephemeral?
[17:24] <roaksoax> smoser: no i haven't upgraded ephemerals and yes i used -proposed
[17:25] <smoser> cool
[18:59] <roaksoax> flacoste: howdy!1 unrelated question that you might help me with. Why do PPA's don't allow upoading a package, which is in the Ubuntu Archive, but has a different tarball?
[19:05] <flacoste> roaksoax: you mean same version number than in the archive but actual different tarball?
[19:07] <roaksoax> flacoste: yep
[19:07] <roaksoax> flacoste: so I'm trying to upload a precise version of it, which has a different tarball
[19:07] <flacoste> roaksoax: it's a good question, i know we don't allow two publication of the same version number with a different tarball
[19:08] <flacoste> ah
[19:08] <flacoste> but that would prevent the precise version from being upgraded when going to quantal, no?
[19:08] <flacoste> so in this case, that check does make sense
[19:10] <roaksoax> flacoste: right, but even if the quantla version has a higher ubuntu revision number, the upload fails
[19:10] <roaksoax> flacoste: anyways, i guess this might prevent an SRU from happening due to this check
[19:11] <roaksoax> because the upstream tarballs are gonna be different
[19:11] <roaksoax> the precise version has to include python-tf-tftp and yui3
[19:11] <flacoste> roaksoax: the only check that i am aware of is that we don't allow two publication of the same package version with two different tar ball
[19:11] <flacoste> now, i wasn't aware that this was cross archive
[19:12] <flacoste> i have no idea if this is intentional or not
[19:12] <flacoste> best thing is to file a bug if you think it is
[19:12] <roaksoax> flacoste: this is the message: "File maas_0.1+bzr1264+dfsg.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents."
[19:12] <flacoste> and more knowledgeable folks will assess if it is or not
[19:12] <roaksoax> flacoste: will do
[19:12] <flacoste> roaksoax: right, so it seems that it's a cross archive check
[19:12] <flacoste> hmm
[19:13] <roaksoax> flacoste: indeed
[19:13] <flacoste> my guess is that this is intentional
[19:13] <flacoste> to prevent a ppa from hijacking a ubuntu package
[19:13] <roaksoax> yeah it seems like it
[19:13] <flacoste> or shadowing if you prefer
[19:14] <roaksoax> right
[19:14] <roaksoax> flacoste: alrught, thanks for the info
[19:46] <lifeless> its a consistency thing
[19:47] <lifeless> I *think* it applies to pockets as well
[19:47] <lifeless> e.g. ubuntu-security/ubuntu-release