[18:13] <roaksoax> rvba: don't take you are still around?
[20:18] <Mtl_> Hey there. I just installed MaaS and saw that It proceeds to automatic server installation with PXE+DHCP+IPMI/WakeOnLan. But I was wondering ... How can it be possible in a real datacenter like OVH ?
[20:33] <lifeless> Mtl_: you mean ovh.co.uk ?
[20:33] <Mtl_> yes sir.
[20:34] <lifeless> if they give you acccess to IPMI and your own layer 2 network for deployment it should work fine
[20:34] <lifeless> if they don't, then you'd need them to offer you a MaaS endpoint
[20:36] <lifeless> (or some other bare metal cloud API)
[20:36] <Mtl_> They offer a kind of "own network" called vRack http://www.ovh.co.uk/dedicated_servers/virtual_rack.xml
[20:36] <Mtl_> whitch connect dedicted servers with a virtual switch
[20:39] <Mtl_> By the way, I bet that the Ubuntu Cloud Infrastructure is nothing without MaaS
[20:39] <lifeless> what do you mean ?
[20:42] <Mtl_> That the deployment of a Ubuntu Cloud Infrastructure is not possible / useful without MaaS
[20:48] <lifeless> oh; I wouldn't agree with that statement
[20:52] <lifeless> though I guess it depends on the exact definition of UCI
[20:52] <Mtl_> Thanks for all
[20:53] <lifeless> but you can certainly deploy an OpenStack cloud using Ubuntu packages w/out MaaS
[20:53] <lifeless> probably still using Juju - e.g. Juju on top of Nova baremetal
[20:53] <lifeless> in fact https://help.ubuntu.com/community/UbuntuCloudInfrastructure describes three ways to install
[20:53] <lifeless> only one of which uses MaaS
[20:58] <Mtl_> Aah right.
[20:58] <Mtl_> And MaaS is really dedicted for HyperScale
[20:58] <Mtl_> Like if you have your own datacenter and racking a lot of servers
[20:59] <Mtl_> to avoid the installation process on workers
[21:52] <lifeless> Mtl_: yes, it is automation
[21:52] <lifeless> Mtl_: if you don't have enough hardware to pay off the (time, learning, etc) overhead of installing MaaS, then you don't need it.
[21:52] <lifeless> Mtl_: but you can still get UCI ;)
[21:55] <Mtl_> Thanks for help !


[16:04] <DarkTrick> Is there any discussion going on about changing the Alt+Mouse-accelerator to Super+Mouse? I couldn't find any related reports on launchpad
[16:04] <DarkTrick> I just figured out, that it collides with Qt's Alt+mousewheel default behavior for scrolling. And since it's a system shortcut, it might be better suited on Super?
[17:02] <Mmr> hallo, I have problem with wifi adapter
[17:05] <Mmr> I have replaced several linux distributions and I have a problem with driver wifi
[17:07] <Mmr> old fujitsu siemens amilo li 2727 new problem with old notebook
[18:22] <margelatu> Is there xubuntu support for i386?
[23:58] <ev-nar> Hey, I just installed xubuntu 20.04 LTS on my box; and I am having trouble with secure boot


[23:01] <talmage_> I'm looking for help making ubuntu touch work on my WeTab.
[23:02] <talmage_> I have ubuntu8-desktop-session-mir installed.
[23:02] <talmage_> I have mir-graphics-drivers-desktop installed.
[23:03] <talmage_> I can start the regular ubuntu desktop.  It's often finger friendly.
[23:03] <talmage_> When I start the touch desktop, I'm prompted to log in again.  There is no on screen keyboard.
[23:04] <talmage_> How do I enable the keyboard so that I can log in?
[23:06] <talmage_> I plugged in a USB keyboard so that I could log in.
[23:08] <talmage_> Now I have a window that says "Scopes".  It keeps closing and re-opening.
[23:08] <talmage_> Any clues for me?


[04:51] <nigelb> Morning
[04:51] <StevenK> O hai
[04:51] <nigelb> \o/ 20 landings
[05:16] <nigelb> StevenK: How do I know when my db patch is ready for landing again?
[06:22] <wgrant> nigelb: You don't, really. I'll try to arrange the remaining deployments on Monday.
[06:22] <nigelb> wgrant: cool, okay.
[07:10] <StevenK> Well, it can be worked it out. But only if you work for us.
[07:17] <nigelb> StevenK: I'm happy to. Except I seem to headed to set records for number of rejections :P
[07:25] <wgrant> Need to arrange cocoplum/germanium/librarian/codehosting/mailman deployments. Shouldn't be too hard.
[08:42] <lifeless> hmm
[08:42] <lifeless> why was registry removed from ~launchpad-translators?
[08:57] <wgrant> lifeless: It looks like it was removed from *everything* :/
[08:58] <wgrant> Hm, it's actually not been a member of much for ages.
[08:59] <wgrant> Ah, ~launchpad is in ~rosetta-admins, so we indirectly own ~launchpad-translators. Not sure we were a member, though.
[08:59] <wgrant> And oh wow that is a lot of mail.
[09:01] <StevenK> Oh?
[09:02] <wgrant> Roughly 10 shitloads of cronspam and wikispam.
[09:05] <StevenK> That much? :-P
[09:06] <nigelb> You never have too much email.
[09:06] <nigelb> Unless you have Nagios
[09:08] <StevenK> Right, Chapter Master finished
[09:11] <LPCIBot> Project devel build #1,082: FAILURE in 4 hr 16 min: https://lpci.wedontsleep.org/job/devel/1082/
[09:11] <wgrant> :(
[09:11] <StevenK> I think I need to disable Jenkins builds, anyway
[09:12] <wgrant> Why?
[09:12] <StevenK> $$$$
[09:12] <wgrant> :(
[09:12] <wgrant> Probably.
[09:12] <StevenK> And I can't get OpenStack working with Jenkins.
[09:13] <StevenK> And the jclouds plugin, which is the new hotness isn't finished and doesn't build.
[10:03] <LPCIBot> Project db-devel build #875: FAILURE in 3 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/875/
[10:22] <lifeless> mtaylor: ^
[11:03] <cjwatson> so how do I upload to dogfood for QA purposes?  it doesn't seem to have a poppy instance running - at any rate, nothing's listening on ftp
[11:05] <wgrant> cjwatson: Try 2121
[11:06] <wgrant> cjwatson: Should also have SFTP on 5022.
[11:36] <cjwatson> wgrant: neither of those is working for me, not even from chinstrap
[11:36] <StevenK> Lesse
[11:37] <StevenK> cjwatson: poppy is now running on mawson.
[11:41] <cjwatson> and on FTP port 21 - thanks, sorted
[11:42] <wgrant> Ah, someone must have fixed the firewall.
[11:44] <cjwatson> what's the rune for running the publisher?  LPCONFIG=dogfood /srv/launchpad.net/codelines/current/cronscripts/publish-ftpmaster.py -d deribuntu -q # ?
[11:59] <wgrant> cjwatson: I normally run publish-distro directly, but yeah, that should work.
[12:01] <wgrant> cjwatson: You're QAing the translations compression change?
[12:10] <cjwatson> yep
[12:10] <cjwatson> if you have the thing you normally run in shell history, that would be ideal, I don't want to be inventing things as I go :)
[12:15] <StevenK> There's a distro-run script somewhere on mawson, too.
[12:16] <cjwatson> not finding it ...
[12:20] <cjwatson> https://dev.launchpad.net/Soyuz/QA was somewhat helpful but only up to a point
[12:21] <cjwatson> (or do I want to use --all-derived?  https://dev.launchpad.net/Soyuz/TechnicalDetails/Publishing)
[12:24]  * cjwatson decides to go ahead with publish-ftpmaster -d deribuntu and see what happens
[12:26] <cjwatson> That seemed to work.  Lots of errors for missing files but they seem unrelated
[12:26] <cjwatson> http://paste.ubuntu.com/691497/
[12:31] <wgrant> cjwatson: Yeah, we don't have the whole pool, because it's slow and not small.
[12:31] <wgrant> cjwatson: That looks fine, then. Thanks for QAing it.
[12:33] <cjwatson> Marked qa-ok.  Thanks for the guidance
[12:36] <StevenK> wgrant: Can you think of any reason why queue-builder shouldn't be removed from the tree and burnt at the stake?
[12:37] <wgrant> StevenK: It's possible we might want to do a rescoring run at some point... maybe.
[12:37] <wgrant> StevenK: add-missing-builds also only works for a particular DAS, I think.
[12:37] <wgrant> If we generalise add-missing-builds to also work over a whole archive, or it does already, then we should rip cMB out of queue-builder, at least.
[12:37] <StevenK> I thought we hadn't run it for years?
[12:38] <wgrant> I think it was running until early last year.
[12:38] <wgrant> In --score-only, at least.
[12:38] <wgrant> I came across its logs a while back.
[12:38] <wgrant> It was a terrible experience.
[12:38] <StevenK> Haha
[12:39] <StevenK> add-missing-builds already takes an archive argument
[12:39] <wgrant> Yes, and I even made it work for the primary archive.
[12:39] <wgrant> But it requires an explicit arch list, which is possibly silly.
[12:39] <wgrant> OK for its original purpose, but that was short-sighted.
[12:41] <StevenK> So I'm free to gleefully rip cMB out of q-b?
[12:41] <wgrant>         sources_published = distroseries.getSourcesPublishedForAllArchives()
[12:41] <wgrant> From q-b.
[12:41] <wgrant> It works over all archives at once.
[12:42] <wgrant> (wow, how did that ever not take a week...)
[12:42] <wgrant> So, q-b still possibly has a purpose.
[12:42] <wgrant> And it's only like 180 reasonably unoffensive lines.
[12:44]  * StevenK is tempted to put the final nail in the coffin of canonical.lp
[12:44] <wgrant> Please don't.
[12:45] <wgrant> I have big plans for initZopeless.
[12:45] <wgrant> But there's more that has to be untangled first.
[12:45] <wgrant> I have a rough idea of how it is going to go down, but need to work out specifics.
[12:45] <StevenK> wgrant: My plan was to move it away so lib/canonical/lp can be deleted.
[12:45] <wgrant> No.
[12:45] <wgrant> That's the easy way out.
[12:45] <wgrant> But initZopeless is pointless now.
[12:45] <wgrant> It should die entirely.
[12:45] <wgrant> Moving it away just hides tech debt.
[12:46]  * StevenK rewrites lib/canonical/lp/ftests/test_zopeless.py, since it's utterly disgusting.
[12:46] <wgrant> I deleted most of that last week.
[12:46] <wgrant> All that's left is that doctest.
[12:46] <StevenK> But it isn't even a doctest!
[12:46] <wgrant> It is a doctest in a unittest!
[12:48] <wgrant> Things that remain:
[12:48] <StevenK> Which is disgusting
[12:48] <wgrant>  - untangling our dbuser change support.
[12:48] <wgrant>  - renaming "Zopeless" mail to non-queued mail
[12:48] <wgrant>    (and detaching it from initZopeless)
[12:49] <wgrant>  - Letting FunctionalLayer users specify a security policy.
[12:49] <wgrant>  - Porting *ZopelessLayer users to *FunctionalLayer, using PermissiveSecurityPolicy
[12:49] <wgrant>  - Delete initZopeless, because it no longer has a purpose.
[12:50] <wgrant> (Zopeless currently means three things: 1) non-queued mail, 2) DB user and isolation level reconfiguration, 3) PermissiveSecurityPolicy)
[12:51] <wgrant> I've got rid of most of the terrible old code, but we still have this awful tangled wrapper.
[12:51] <wgrant> Conflating these three largely unrelated things.
[12:53] <StevenK> wgrant: http://pastebin.ubuntu.com/691519/
[12:54] <wgrant> StevenK: You could do that, but the sole remaining callsite of isZopeless is Zopeless mail, which is next on the list to remove.
[12:54] <wgrant> So I would be surprised if that test wasn't deleted within a fortnight.
[14:58] <nigelb> Gah
[14:58] <nigelb> My nightmare with that bug continues
[15:27] <nigelb> wgrant / StevenK around?
[15:27] <nigelb> Hrm,looking at the time, I guess not.
[15:40] <LPCIBot> Yippie, build fixed!
[15:40] <LPCIBot> Project db-devel build #876: FIXED in 4 hr 50 min: https://lpci.wedontsleep.org/job/db-devel/876/
[16:09] <nigelb> If anyone has a few minutes to review an MP for a regression that'd be great! https://code.launchpad.net/~nigelbabu/launchpad/js-regression-849121/+merge/75858
[20:33] <lifeless> and again, deactivated. wtf
[20:34] <lifeless> should be ban untaintableangel ?


[05:23] <jam> morning all
[07:35] <jam> rvba: morning
[07:35] <rvba> jam: Hi
[07:35] <jam> I don't know if you've seen this, but it appears that maas-region-controller gets *horribly* broken if you have your IP address changed.
[07:36] <jam> I'm trying to setup a 'large' region on EC2, and I shut it down while I went away, so when I started it again, it came back up with a different IP.
[07:36] <jam> lots of bits were broken, and so far, no luck actually getting it running.
[07:36] <jam> So I'm trying to just purge everything and reinstall.
[07:36] <rvba> jam: by horribly broken you mean that nothing tells you that the connection is broken?
[07:36] <jam> dpkg-reconfigure maas-region-controller  doesn't actually seem to reset things to get them to the right IP addresses and URLs.
[07:37] <jam> rvba: well, #1 I filed a bug on, which is that the cluster spins forever trying to connect to the region
[07:37] <jam> but fails
[07:37] <jam> and fails before it starts celery
[07:37] <rvba> Right.
[07:37] <jam> so it doesn't even have task_logger hooked up.
[07:37] <jam> but the maas-region-controller itself sits spinning.
[07:37] <jam> because we now set BROKER_URL
[07:37] <jam> and that is no longer valid after the IP address changes.
[07:37] <jam> also, rabbitmq-server is... unhappy at best.
[07:38] <rvba> I see.
[07:38] <rvba> Well, not really rabbitmq
[07:38] <jam> like 'service rabbitmq-server stop' claims that it is stopping the broker
[07:38] <jam> but 'beam.smp' is still running.
[07:38] <rvba> Celery will be unhappy.
[07:38] <jam> rvba: celery was at least logging that there was a problem.
[07:38] <rvba> That looks like a problem in rabbitmq itself.
[07:39] <jam> rvba: sure
[07:39] <jam> I'm not saying it is Maas's fault that rabbit is broken, but it was a lot of stuff that was just 'not working', and I couldn't really figure out how to fix it.
[07:39] <jam> note that squid was also ended up pointing to the wrong IP address, etc.
[07:40] <rvba> Interesting.
[07:40] <rvba> And scary :)
[07:40] <jam> rvba: also, there are some bits where it wasn't clear whether the dpkg-reconfigure wanted the URL or the IP Address.
[07:43] <rvba> jam: I'm surprised that restarting rabbitmq does not fix the problem (the problem with rabbitmq of course).
[07:44] <jam> rvba: well 'service rabbitmq-server stop' doesn't actually stop it, so the restart doesn't really work.
[07:46] <jam> rvba: the cluster controller also calls itself name='master', is there supposed to be a way to configure that?
[07:47] <rvba> jam: when the cluster controller connects to the region, it changed the name of the nodegroup using its UUID.
[07:47] <rvba> changes*
[07:47] <jam> rvba: http://ec2-23-23-14-48.compute-1.amazonaws.com/MAAS/api/1.0/nodegroups/?op=list
[07:47] <jam> not that I see
[07:48] <jam> rvba: though... it is still failing to startup, so there may be something else going on.
[07:49] <rvba> I can't get the page to load.  But I suppose you are still seing the cluster named 'master' ... this simply means that the cluster controller was unable to connect to the region.
[07:49] <jam> on the plus side, EC2 c1.medium are a lot faster than my VM, and I can do 10,000 nodes in 3s, vs the 12s I was seeing locally.
[07:49] <jam> rvba: ah, you aren't in the security group, I imagine.
[07:50] <jam> rvba: so I see 2 nodegroups listed
[07:50] <jam> so it is somehow getting a message through, but not enough to change its name.
[07:51] <jam> rvba: http://paste.ubuntu.com/1280693/
[07:51] <jam> (if you want to help, you can give me your ip address and I can add you to the security group)
[07:53] <rvba> jam: I have access now.  ta
[07:57] <rvba> jam: having 2 clusters named 'master' is really a weird situation.  Not really scary because the 'master' nodegroup is identified by picking the *first* nodegroup but still, the situation is really bizarre.
[10:30] <jtv> mgz: my diff has updated.  Thanks for reviewing it.  :)
[10:33] <mgz> jtv: I will now review for real :)
[10:33] <jtv> Thanks!
[10:34] <jtv> I'll have to go catch a train in a minute.
[10:36] <jam> well, I got up to 10 cluster controllers all talking to 1 master (so 11 total) and 4k nodes on each, for 44,000 nodes total. Rebuilds tags in about 15s, but the 2-cpu region controller is definitely the bottleneck.
[10:38] <jtv> jam: great to hear that you got that working... would be very interesting to know where the bottlenecks at finer granularities will be.
[10:38] <rvba> jam: that's very good news.
[10:39] <jam> jtv: well, in the immediate term I'm going to restart the central machine with c1.xlarge instead of a c1.medium, and see what I can get it to do.
[10:39] <jtv> Heh -- you did 44K nodes without even scaling up the central server?  That is happy news indeed.  :)
[10:39] <jam> jtv: well, there are certainly aspects of the system that aren't scaling well.
[10:39] <jam> You can't really load "http://.../MAAS" or "http://.../MAAS/nodes/"
[10:39] <rvba> The whole page is definitely one of them :)
[10:40] <jtv> The main page in particular might be nice to have working......
[10:40] <rvba> jtv: this is not completely trivial, txlongpoll is the component that should be improved/replaced.
[10:40] <jtv> mgz: Raphael got in first
[10:40] <jam> rvba: the big issue is that whatever lag is introduced into the system makes it *very* hard to play with it. 10s lag spike without interaction means I miss the whole time the rebuild is happening.
[10:41] <mgz> jtv: I also posted, with a note you may want to look at
[10:41] <jtv> Willdo
[10:41] <mgz> well, the last sentence, the rest is just me thinking
[10:41] <mgz> basically, expression should use // not / I think
[10:42] <jam> on the plus side, I discovered that you can tell Amazon that everything in a given *security group* should be able to talk to eachother on a given set of ports. So when you add new nodes, they automatically can talk to eachother.
[10:42] <jtv> mgz: I think you're right, but also I think it's a separate issue.  I haven't tried it out but I suspect the test picks numbers that happen to come out to an even amount in megs.
[10:42] <mgz> jam: yup.
[10:42] <jtv> FWIW I reviewed that branch and said please to document these little things...
[10:42]  * jtv -> train
[10:43] <jtv> See you tomorrow, folks!
[10:43] <mgz> >>> n>>20<<20 == n
[10:43] <mgz> False
[10:43] <mgz> so, nope...
[10:44] <mgz> I didn't understand the security group that permits itself idiom for ages, but it's actually quite handy.
[10:45] <jam> mgz: the downside is that I don't have a way to 'ssh' to all the machines and poke at them... which is what Juju would be nice to have.
[10:46] <mgz> hm, you do, but probably not in a handy way without writing a wrapper script
[10:46] <mgz> you can always permit 22 in the same group, or add default and that group, and the api will give you the hostnames/ips
[10:48] <jam> mgz: sure, but managing 10+ machines manually is certainly at the point of a bit of pain.
[10:49] <jam> add to it the multi-second latency spikes
[10:52] <mgz> hm, is trunk make broken currently?
[10:53] <mgz> I probably just need to clean first I guess...
[10:54] <mgz> clean not removing the stuff in bin/ and distclean removing a local egg cache is annoying
[10:55] <mgz> maybe I need to add a global egg cache to my setup script, but it's really not needed apart from if you blow away the working tree files
[11:08] <mgz> okay, this is fun
[11:10] <mgz> today's machine can't run tests, because it can't start the db, because pg_ctl is not installed... because the packaging thinks that conflicts with postgres itself?!

[11:12] <mgz> probably the same as usual need to update my package lists locally...
[11:31] <mgz> okay, this latest bit is derived from there being no python-selenium package
[11:33] <jam> everyone say hello to our newest blue squad member, dimitern
[11:34] <mgz> need to add multiverse... why did this not break earlier I wonder
[11:34] <mgz> her dimitern
[11:34] <mgz> *hey
[11:34] <mgz> dammit, can't even greet without tyop
[11:35] <dimitern> mgz: hey :)
[11:36] <dimitern> glad to meet your guys!
[11:38] <mgz> gah, what is borked with postgres...
[11:39] <mgz> okay, rm -rf db && make sampledata worked
[11:39] <mgz> the error reporting for this stuff is painful, CalledProcessError is not very helpful
[11:58] <rvba> Hi dimitern, welcome aboard.
[12:00] <dimitern> rvba: hey :) 10x
[12:45] <jam> mgz, dimitern: so I'm currently load testing MAAS with 1 Region Controller, and 10 Cluster Controllers, each with 4000 node records (in EC2)
[12:46] <jam> I made the Region controller a C1.xlarge, so it has 8 cores, and the individual nodes are c1.mediums with 2 cores.
[12:46] <jam> If I just issue 1 tag to be rebuilt, it finishes in 9s.
[12:46] <jam> (as measured by the time for all requests to complete, the first one completes in a lot less time)
[12:46] <jam> If I rebuild 2 concurrently, it goes up to 12s.
[12:47] <jam> Anything higher than that, and it just serializes (presumably because the cluster nodes only have parallel = 2)
[12:47] <jam> I also think we are roughly at capacity for 1 MAAS controller, because it is going from 9s to 12s when running simultaneous requests.
[12:48] <jam> Certainly all 8 Apache WSGI processes are 'active' at >25% CPU during this time
[12:48] <jam> (there should be on the order of 20 concurrent requests.)
[12:48] <jam> I wonder about over-committing for Apache, though.
[12:48] <mgz> that sounds as expected
[12:51] <jam> mgz: well setting wsgi parallel = 20, and I still only ever see ~8 apache processes consuming memory.
[12:51] <jam> sorry, consuming cpu
[12:53] <jam> mgz: I also only see postgres consume at most 4 CPUs and normally <3. Is there a good way to tell if postgres is bottlenecking, or do I need to move that onto another machine.
[12:54] <jam> rvba: what is a reasonable way from python/api to decommision 4k nodes?
[12:54] <jam> (I want to get rid of all nodes in the 'master' group)
[12:55] <rvba> jam: I guess you can simply delete() them.  From python directly I mean.
[12:55] <jam> rvba: Node.delete() ? Or NodeGroup.node_set.delete() ?
[12:55] <jam> or is the latter only deleting the linkage?
[12:55] <rvba> jam: the latter is fine.
[12:56] <rvba> It will delete the nodes.
[12:56] <jam> rvba: 'RelatedManager has no attribute delete'
[12:56] <rvba> jam: nodegroup.node_set.all().delete()
[12:57] <jam> rvba: right, vs nodegroup.node_set.clear() which would just remove the linkage.
[12:57] <rvba> Yep.
[12:57] <jam> rvba: interestingly, the bottleneck when deleting 4k nodes is actually' django-admin'.
[12:58] <jam> Presumably lots of python hooks on the delete method?
[12:58] <jam> (It has to delete mac addresses for each node it deletes.)
[12:58] <jam> maybe we should have had a pre-join there :)
[12:58] <rvba> Yeah, very probably.
[13:07] <rvba> jam: deleting mac addresses should be handled at the db level (delete cascade).
[13:08] <jam> mgz: definitely seems to be a 'thundering herd' issue here. Many of  the processes finish significantly before the rest. It appears that they all get their first request started on time, but they tend to get starved out for that first 'give me all the nodes to work on' request.
[13:08] <jam> rvba: well it should, but we have custom code in Node.delete
[13:08] <rvba> Yeah, to update the DNS config.
[13:08] <rvba> I mean we have signals hooked up to node.delete() to update the DNS config.
[13:08] <jam> ah
[13:08] <dimitern> jam: how many VMs I need to setup to run maas locally? is 1 enough or I'll need more?
[13:08] <rvba> That might be heavy.
[13:09] <jam> dimitern: I use just 1
[13:09] <dimitern> jam: 10x
[13:09] <jam> if you actually want to test the PXE booting, etc. You'll want more VMs for that.
[13:09] <jam> But just for running a server, and poking at the metadata, 1 is enough.
[13:09] <dimitern> yeah, that's what i figured
[13:09] <dimitern> i'll setup pxe later, once the webapp is running
[13:11] <allenap> rvba: FORCE_SCRIPT_NAME and STATIC_URL are driving me up the wall. Do you have time this afternoon to talk about it?
[13:11] <jam> rvba: so I might have been at fault for the first IP change mess-up. I did it again this time (rebooting to a larger Instance), and all I needed was to do the dpkg-reconfigure on all the machines.
[13:11] <rvba> allenap: sure
[13:12] <rvba> jam: all right.  Having to do that is normal given the state we are in.
[13:13] <rvba> allenap: I can talk now if you're free.
[13:15] <allenap> rvba: Yeah
[13:43] <allenap> rvba: Fwiw, this is my solution: http://paste.ubuntu.com/1281102/
[13:45] <rvba> allenap: looks good to me.  It even fixes using settings.STATIC_URL in src/maasserver/middleware.py which is wrong.  Never actually exercised but still wrong.
[13:46] <rvba> allenap: even in debug mode on a prod instance, apache serves the static files btw, so this is actually never used in production.
[14:58] <flacoste> roaksoax, rvba, allenap: anyone looked at bug 1066421 yet?
[14:58] <roaksoax> flacoste: yeah, it is duplicate from bug 1065763
[15:00] <roaksoax> rvba: so, is there any way we can use the same queue from txlongpoll?
[15:00] <roaksoax> rvba: using say... a different vhost?
[15:01] <rvba> roaksoax: well, a queue belongs to a vhost.
[15:01] <rvba> roaksoax: can you remind me what you're trying to do again?
[15:02] <roaksoax> rvba: so during the installtion from cd/preseed, we need to start rabbitmq server (in the chroot) to be able to create the queues (running a daemon in the installer is against policy).
[15:02] <roaksoax> rvba: so the queue for txlongpoll is being created correctly, but the one for the celery wprkers is not
[15:02] <roaksoax> so we need to find a workaround for that
[15:02] <roaksoax> either by using same suser/password and different vhost
[15:02] <roaksoax> or osmething
[15:05] <rvba> roaksoax: AFAIK the queues are created dynamically.  We are only creating users and vhosts in the postinst scripts.
[15:05] <rvba> Am I missing something?
[15:06] <roaksoax> rvba: right, so that's what I meant
[15:06] <roaksoax> rvba: the users/vhosts are created for txlongpoll
[15:06] <roaksoax> rvba: but not for the workers
[15:06] <roaksoax> rvba: and that's during the installer only
[15:08] <rvba> roaksoax: how are the workers' user/vhost different from those of txlongpoll?
[15:09] <roaksoax> rvba: it is not a problem of the postinst
[15:10] <roaksoax> rvba: it is a problem from running rabbitmq daemon in the installer (chroot), which goes against policy
[15:10] <roaksoax> but for some reason it does work for the first, (txloinpoll user/vhost create) but not for the second one (celery user worker/vhost creattion)
[15:11] <roaksoax> rvba: so that's why I was wondering if we would be able to use the same username/password created for txlongpoll, with a different vhost
[15:11] <rvba> roaksoax: It would be nice to understand why it works for the first and not for the second.
[15:11] <rvba> roaksoax: there is no real reason why not.  But it's a bit ugly to use the same credentials for two completely unrelated stuff.
[15:12] <roaksoax> rvba: that's what I'm trying to figure out, but it seems that the first part gets created because rabbitmq is running correctly, but then gets killed and the rest of the stuff doesn't get done
[15:12] <roaksoax> i've tried to work around it without success
[15:13] <roaksoax> rvba: i'll further investigate now as I have a couple of other ideas on how to fix it
[15:13] <roaksoax> rvba: but the issue is basically rabbitmq not running during the installer
[15:14] <allenap> roaksoax, rvba: Another (better? harder?) solution might be to get the region to configure all this stuff at runtime instead of install-time.
[15:16] <rvba> allenap: it would be one step towards having less stuff in the packaging.  But obviously we don't really have the "framework" in place to do that properly.
[15:16] <roaksoax> indeed
[15:16] <roaksoax> i think ti would be to risky to do it at this point
[15:16] <roaksoax> being so close to release
[15:16] <allenap> Fair point.
[15:22] <dimitern> guys, can you help with errors like this when running buildout on maas src root: Error: There is a version conflict.
[15:22] <dimitern> We already have: distribute 0.6.28dev-r0
[15:24] <allenap> dimitern: Are you on Quantal or Precise?
[15:24] <dimitern> quantal
[15:25] <dimitern> i did a vanilla install of 12.04 server, updated/upgraded, did release upgrade to 12.10 and called make install-dependencies, then i got this
[15:28] <dimitern> I read some forums about this error, which recommended to list the package = version in versions.cfg explicitly
[15:28] <roaksoax> rvba: http://pastebin.ubuntu.com/1281273/
[15:29] <dimitern> I did that, but then it complains about other packages further on (like ampqlib)
[15:30] <roaksoax> rvba: i found out what's the issue... i'm such a dumbass
[15:30] <allenap> dimitern: Here, I have python-setuptools 0.6.28-1ubuntu2 installed, but virtualenv provides 0.6.24 when I create a new env. Can you try:
[15:31] <rvba> roaksoax: what's the issue?
[15:31] <allenap> dimitern: virtualenv foo && foo/bin/python -c 'import setuptools; print setuptools.__file__'
[15:32] <roaksoax> rvba: i just remmebered that we work around it creating the rabbitmq stuff on the upstart job to address this issue
[15:33] <dimitern> allenap: so I need to run buildout in a virtualenv?
[15:33] <roaksoax> rvba: btw... the worker stuff is for maas-region-celery.upstart
[15:33] <allenap> dimitern: Ah. Just type `make` and it'll sort it out for you.
[15:35] <allenap> dimitern: The virtualenv was a hack to make buildout behave a little better. I suspect we'll actually get rid of buildout eventually, or scale back its role.
[15:35] <dimitern> allenap: ok, now vbox issues... I'll dig into it some more (shared folders/read only filesystem error)
[15:36] <dimitern> allenap: it seems to have worked after chown -R :) now it's installing, 10x
[15:36] <allenap> Cool.
[15:46] <roaksoax> rvba: the worker stuff is used when running maas-region-celery right?
[15:47] <rvba> roaksoax: right.
[16:01] <dimitern> any help on how to resolve this?: maas@maas1:~/work/maas$ make syncdb
[16:01] <dimitern> bin/database --preserve run -- bin/maas syncdb --noinput
[16:01] <dimitern> initdb: Postgres-XC node name is mandatory
[16:40] <roaksoax_> rvba: ok so we are gonna need a wrapper to start maas-region-celery
[16:40] <roaksoax_> rvba: http://paste.ubuntu.com/1281418/
[16:54] <roaksoax> '
[17:09] <roaksoax> rvba: still around?
[17:09] <rvba> roaksoax: yeah, but I'll need to bugger off real soon.
[17:12] <roaksoax> rvba: ciukd you please help me test this? http://paste.ubuntu.com/1281498/
[17:12] <roaksoax> rvba: i'm at ODS and network is crap
[17:12] <roaksoax> and can't really test it
[17:12] <roaksoax> rvba: start-region-celery -> create one on /usr/sbin
[17:13] <roaksoax> rvba: and just modify the upstart job accordingly
[17:14] <rvba> roaksoax: why a custom script instead of the exec /usr/bin/celeryd ?
[17:15] <roaksoax> rvba: we need to create rabbitmq credentials on upstart job if tey had not being created on the installer
[17:15] <roaksoax> rvba: which is the actual workaround we made for txlongpoll
[17:15] <rvba> roaksoax: yes, I understand that part, but why do you need another startup script?
[17:15] <roaksoax> rvba: but the upstart job cannot do so because we set the uid,gid to maas
[17:15] <roaksoax> rvba: cannot run rabbitmq
[17:16] <roaksoax> rvba: so the best approach is tyo simply make a "wrapper" that runs celery d
[17:16] <rvba> Ah ok.  I take it it's not possible to setuid maas/setgid maas just before executing exec /usr/bin/celeryd…
[17:16] <roaksoax> rvba: nope unfortunately :(
[17:16] <roaksoax> rvba: it applies to everything
[17:18] <rvba> roaksoax: ok, I'll test that for you, but then I'll need to run.
[17:18] <roaksoax> rvba: awesome thank you
[17:18] <roaksoax> rvba: i'm tethering from my phone cause internet sucks here
[17:26] <rvba> roaksoax: looks like it works ok, the celeryd daemon gets started all right.
[17:26] <rvba> roaksoax: I've manually deleted the user maas_workers.
[17:26] <rvba> In that case it fails because the pre-start script tried to create the vhost which was already there.
[17:27] <rvba> roaksoax: if I also delete the vhost it is fine.
[17:28] <rvba> roaksoax: note that this /usr/sbin/start-region-celery utility is very similar to a helper function we already have so it would be better to share the code.


[08:02] <oSoMoN> good morning desktoppers
[08:02] <oSoMoN> and happy Friday!
[08:07] <duflu> Morning oSoMoN
[08:08] <oSoMoN> good afternoon duflu
[08:10] <jibel> tsimonq2, canary images are not published anywhere yet.
[08:10] <jibel> good morning everyone
[08:15] <duflu> Hi jibel
[08:16] <jibel> cpaelzer__, hi, I still have bug 1761497 which is pretty annoying for manual iso testing. Is there a way to listen to events like key strokes received by the guest?
[08:16] <ubot5`> bug 1761497 in virt-manager (Ubuntu) "syslinux menu is displayed when a desktop ISO is powered from virt-manager" [Low,Confirmed] https://launchpad.net/bugs/1761497
[08:18] <cpaelzer> jibel: re-reading old bug ...
[08:19] <oSoMoN> salut jibel
[08:20] <jibel> cpaelzer, it's like the VM receives a keyboard event on boot
[08:20] <cpaelzer> jibel: is still the different host HW the only difference between good&bad systems?
[08:21] <cpaelzer> jibel: also if on an affected machine you start it via virt-manager but without a view of the guest graphics open - does it work then
[08:22] <cpaelzer> i.e. does the UI hve to be attached to trigger the issue?
[08:23] <jibel> cpaelzer, it's only on one machine, the HW is the only difference between good vs bad systems.
[08:24] <jibel> cpaelzer, and yes, the UI seems to have a role in triggering the bug
[08:25] <jibel> and it happens with any release booted on the guest (i tried with trusty)
[08:25] <cpaelzer> for the sake of trying to be a friendly helper I tried to reproduce this once more now - but it doesn't trigger
[08:26] <cpaelzer> let me think about potential debugging options that I might have forgotten
[08:27] <jibel> yeah, I think it's really a problem with the host difficult/impossible to reproduce on other hw
[08:28] <jibel> cpaelzer, if I start the VM directly from the manager without the view it works as expected
[08:28] <cpaelzer> you can send-key extra keystrokes, but I don't know of monitoring them
[08:28] <cpaelzer> might be an unwanted big-brother feature after all
[08:30] <cpaelzer> jibel: for the sake of trying almost random things - switching the video backend between spice/vnc maybe?
[08:30] <cpaelzer> not sure how your guest looks like atm
[08:32] <jibel> cpaelzer, ah, actually switching to vnc solves the problem
[08:32] <cpaelzer> jibel: are by any accident the working systems already on vnc only instead of spice?
[08:33] <cpaelzer> jibel: and/or is this a sufficient workaround for you for now?
[08:36] <jibel> cpaelzer, the working systems are using spice.
[08:37] <jibel> cpaelzer, The workaround is sufficient, thanks for your help.
[08:37] <jibel> I'll see if I can dig further
[08:49] <willcooke> morning
[08:58] <duflu> Morning willcooke
[08:59] <willcooke> hi duflu
[08:59] <willcooke> re: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons/+bug/1821933
[08:59] <ubot5`> Ubuntu bug 1821933 in gnome-shell-extension-desktop-icons (Ubuntu) "Touch input is offset with two screens (even appearing on the wrong screen)" [Undecided,New]
[09:00] <willcooke> I dont have any scaling set, do you want me to set it and retest?
[09:00] <duflu> willcooke, no if you can reproduce it with 100% then that's plenty
[09:00] <willcooke> roger
[09:02] <willcooke> comment posted
[09:03]  * duflu stops typing and looks
[09:04] <duflu> willcooke, thanks. Back to being a pure gnome-shell bug. I did search for prior reports yesterday but found none
[09:04] <duflu> I can imagine the cause though
[09:04] <willcooke> jibel can reproduce, so I'm happy its not just me
[09:04] <duflu> The stage covers all monitors and possibly touch input is being scaled to that
[09:05] <duflu> So the rubber band would appear at the proportion of the full stage that's the same as the proportion across the touch screen
[09:05] <duflu> Or any touch would
[09:05] <duflu> I happened to order a tiny external monitor yesterday for such bugs but it is not touch
[09:13] <willcooke> duflu, do we need T_revinhos eyes on it?
[09:14] <duflu> willcooke, I can probably find the offending code myself but couldn't test any fix right now
[09:15] <willcooke> if you can stick it in a ppa, I'm happy to test
[09:15] <willcooke> as and why, like
[09:15] <willcooke> *when
[09:17] <duflu> willcooke, actually jibel beat you to it (bug 1723039)
[09:17] <ubot5`> bug 1723039 in gnome-shell (Ubuntu) "With 2 monitors, touches to the touch screen appear across both (and in the wrong place)" [Undecided,New] https://launchpad.net/bugs/1723039
[09:17] <duflu> which to use?
[09:18] <willcooke> I think that's different
[09:18] <willcooke> it talks about turning off one screen
[09:18] <duflu> willcooke, no he's only suggesting a solution I think
[09:19] <willcooke> "With an external monitor attached and the internal display being a touch screen, set the output to the external display only."
[09:19] <duflu> willcooke, oh, no. Same bug occurs even when the touch screen is off
[09:19] <willcooke> that's not the same thing
[09:19] <duflu> Still the same bug
[09:19] <willcooke> oki
[09:19] <willcooke> That bug is from 2017, but my machine has been find on cosmic and bionic
[09:20] <willcooke> so there's a regression there
[09:20] <willcooke> my bug has a video too, so..... ;D
[09:23] <jibel> duflu, different bugs
[09:23] <duflu> jibel, different situations yeah but the same fix should do it
[09:23] <duflu> Also there might have been a separate fix already to stop touches responding when a screen is off
[09:23] <jibel> no, my case was about disabling the touch screen when the display is off
[09:24] <duflu> Yes
[09:24] <jibel> the other one is about the offset when 2 screens are on. How is it the same thing?
[09:25] <duflu> jibel, oh, yes I see. When you say actions are visible you mean actions without a touch location.
[09:25] <jibel> yes
[09:25] <duflu> jibel, OK no problem. Sounds familiar so I think that might have been fixed in recent years
[09:25] <duflu> Now checking
[09:27] <willcooke> morning jibel
[09:29] <willcooke> oops
[09:33] <duflu> jibel, your bug is magically fixed. Apparently
[09:37] <willcooke> ah, now then....
[09:37] <willcooke> If I turn off the laptop screen, which is the touch screen
[09:37] <willcooke> and only have video out on the external monitor
[09:37] <willcooke> then touch events still work
[09:37] <willcooke> and
[09:38] <willcooke> they are positioned on the external screen, more or less in the right place
[09:38] <willcooke> like, if I touch in the middle of the (disabled) laptop screen, the event happens more or less in the middle of the external screen
[09:38] <willcooke> I assume "more or less" because the screens are different sizes and resolutions
[09:45] <duflu> willcooke, hmm. I just closed that because I found the fix in mutter 3.31.4
[09:46] <duflu> I guess it's not fully off?
[09:53] <willcooke> I guess so, the laptop lid is up but it looks like the backlight is off
[10:15] <duflu> willcooke, it took me longer to remember how to PPA than to actually write a patch
[10:15] <duflu> Give it some minutes
[10:16] <willcooke> duflu, this can wait if it's already EOW for you
[10:16] <duflu> willcooke, fair point. But wait for the build and let me know: https://launchpad.net/~vanvugt/+archive/ubuntu/lp1821933
[10:16] <willcooke> duflu, merci
[10:19] <duflu> willcooke, ugh. Actually the math is wrong and there is missing info I can't just fix :(
[10:19] <willcooke> nw
[10:19] <willcooke> Sounds like I should open a bug uptream
[10:21] <willcooke> I'll test on Fedora too
[10:22] <duflu> willcooke, yeah that can't hurt to log an upstream bug. The problematic function is the one in the patch I mentioned, but a fix would need to actually cover more code than that. If it's possible at all right now
[10:23] <duflu> willcooke, I guess my faulty patch might work only for cases where the touch screen is at the top left
[10:25] <willcooke> I'll test it anyway, see what happens
[10:27] <duflu> I think if the touchscreen and the LCD below it are the same resolution AND placed at the top left of all monitors, THEN it might work
[10:29] <duflu> So it may have the illusion of working in the end, but should not be proposed as a fix
[10:29] <willcooke> kk
[10:30] <willcooke> duflu, so for an upstream bug, do you think it should go against gnome shell?
[10:30] <duflu> willcooke, no it's purely mutter
[10:30] <willcooke> kk
[10:30] <duflu> I'd just leave a gnome-shell task in Launchpad to help others find it. That minimizes duplicates
[10:30] <duflu> Also minimises
[10:31] <willcooke> :)
[10:31] <duflu> Night
[10:31] <willcooke> see you!
[10:31] <willcooke> have a good one
[15:47] <tsimonq2> jibel: ack, but they are meant to be published at some point?
[15:47] <tsimonq2> jibel: I ask because Lubuntu would like to jump on the train, so to speak. :)
[16:00] <jibel> tsimonq2, yes, once it's installable.
[16:00] <jibel> I'll tell you
[16:02] <tsimonq2> jibel: Fair enough. Are the remaining issues in the tooling or the packages that are in the PPA?
[16:06] <jibel> tsimonq2, just lack of time
[16:07] <jibel> tsimonq2, actually it should work with ubiquity, I'll try to push a build somewhere for you next week if you want to have a look
[16:13] <tsimonq2> jibel: Oh, is this the one with the stacked squashfses?
[16:13] <tsimonq2> If that's the case, it's a two-liner in Calamares, I just need to verify and test it.
[17:53] <willcooke> night all, have a nice weekend


[03:29] <popey> how odd
[03:29] <Hobbsee> yes
[03:29] <Hobbsee> and the guy *clearly* didnt learn about the enter key.
[03:30] <Hobbsee> which effectively negates his entire post as him being off the planet.
[03:30] <Hobbsee> on a marketing mailing list and all.  wow.  you'd have thought that the people there would have been the *best* at getting the desired information out.
[03:37] <popey> you know, he reminds me of patrick frank
[03:37] <Hobbsee> urgh.  twitch.  shudder.
[03:38] <Hobbsee> popey: no, no, patrick frank tends to accuse women of sleeping their way to get anywhere, whereas this guy would take whoever, as long as they had the required skills.