[02:50] <cherylj> why is restore so broken?
[02:50]  * cherylj sighs
[02:51] <anastasiamac> cherylj: coz it's meant to be weekend?..
[02:51] <anastasiamac> and public holidays on monday in US...
[02:51] <cherylj> I see what's causing the failure in CI, and it's an easy fix
[02:52] <cherylj> but it turns out that restore hasn't been working as the code thinks it should
[20:33] <thumper> morning folks
[20:52] <rick_h__> howdy thumper
[20:52] <thumper> o/ rick_h__
[20:55] <rick_h__> thumper: got a sec?
[20:56] <thumper> yeah... call?
[20:56] <rick_h__> thumper: yea, real fast https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1
[23:15] <axw> wallyworld: apparently I never sent a PR for this, thought I did the other day: http://reviews.vapour.ws/r/3855/
[23:15] <axw> some time after standup...
[23:15] <wallyworld> sure
[23:47] <rick_h__> wallyworld: axw I'm trying to create a model on rax for a demo in alpha2 and getting "ERROR provider validation failed: got default value for unknown field "control-bucket""
[23:47] <rick_h__> but I've got no defined field there in the config yaml for the control-bucket?
[23:48] <wallyworld> rick_h__: when you say config.yaml, you mean environments.yaml?
[23:48] <rick_h__> wallyworld: well both. when running create-model I pass the --config= for the creds/etc
[23:48] <rick_h__> wallyworld: and control-bucket appears in neither file
[23:48] <wallyworld> and the controller was bootstrapped without a control-bucket also?
[23:49] <rick_h__> yes
[23:49] <wallyworld> does juju get-env have control bucket?
[23:50] <rick_h__> ERROR unrecognized command: juju get-env
[23:51] <wallyworld> oh, doh, that's the old cli, sorry, i can't remember wht the new one is
[23:51] <wallyworld> i'll check
[23:51] <rick_h__> no tab complete for my zsh :(
[23:51] <wallyworld> get-config
[23:52] <rick_h__> that's for a service though?
[23:52] <wallyworld> get-model-config
[23:52] <rick_h__> yea, got it, looking
[23:53] <rick_h__> no control bucket there
[23:53] <rick_h__> "set-numa-control-policy" is only hit for for control in thats
[23:53] <wallyworld> hmmm
[23:54] <wallyworld> let me check the code
[23:54] <rick_h__> wallyworld: k, let me know if I should file a bug


[04:45] <YokoZar> So, it seems like the -virtual kernel is actually the -server kernel in disguise  https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/307924  -- my friend has linux-image-virtual and uname -a gives: 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux
[04:46] <ubot3> YokoZar: Error: Could not parse data returned by Malone: The read operation timed out
[04:48] <cooloney> YokoZar, do you mean bug 307924
[04:48] <ubot3> Malone bug 307924 in linux-meta "linux-image-2.6.27(-7)-virtual contains server kernel ..." [Undecided,New] https://launchpad.net/bugs/307924
[04:49] <YokoZar> Yes, it appears it's still live in the released Jaunty
[04:49] <YokoZar> He upgraded his 8.10 virtual server to 9.04 and now it has the server kernel
[04:50] <YokoZar> http://packages.ubuntu.com/jaunty/linux-image-virtual --- if you follow that into the current numbered linux-kernel package and do list files you'll see how they're all misnamed
[04:53] <YokoZar> http://packages.ubuntu.com/jaunty/amd64/linux-image-2.6.28-11-virtual/filelist
[05:30] <cooloney> YokoZar, actually, -virtual flavor was removed since Intrepid 810
[05:31] <cooloney> YokoZar, so since Intrepid 810, we use server image for virtual usage
[05:31] <YokoZar> cooloney: shouldn't the -virtual metapackage have been dropped then?
[05:31] <YokoZar> and automatically shifted to -server?
[05:32] <YokoZar> Or is there another reason for keeping the metapackage around? (LTS to LTS update?)
[05:32] <cooloney> YokoZar, i am not sure, but I will ping other guys in kernel team who know this issue
[05:33] <cooloney> YokoZar, linux-meta contains lots of packages which will be discussed in this Karmic UDS
[05:33] <cooloney> some of them might be dropped in the Karmic
[05:34] <YokoZar> ok that makes sense
[05:34] <YokoZar> The bigger problem is that the package description for the -virtual doesn't show that it doesn't exist anymore
[05:34] <YokoZar> eg apt-cache show linux-image-2.6.28-11-virtual
[05:39] <cooloney> YokoZar, i agree, that is very confusing
[06:50] <soren> cooloney, YokoZar: The virtual and server kernels were always almost identical. The only difference was the selection of included modules. In Intrepid we took the natural consequence of that and made the -virtual kernel package use the exact same kernel image, with a stack of modules filtered out.
[06:50] <YokoZar> soren: that makes sense, although my friend got scared by possible breakages when he googled the issue and found that bug report
[06:51] <YokoZar> if it were clear that -virtual was basically nothing special he might not have worried
[06:51] <soren> I'll make a note on the bug.
[06:51] <cooloney> soren, thanks, i understand that
[06:53] <cooloney> soren, so for user space application such as xen-hypervisor-3.3, it is same as -server and -virtual?
[06:59] <soren> cooloney: I'm not completely sure I understand the question, but I think the answer is "yes".
[07:01] <cooloney> soren, since the kernel image is the same for both -server and -virtual, i guess user space application has no difference for this two flavors.
[07:02] <soren> Usually, yes.
[07:02] <cooloney> actually, IIRC, there is a bug for such application xen-hypervisor-3.3, they think we dropped -virtual flavor, which means ubuntu does not support virtual
[07:03] <cooloney> with your help, i can answer that question now, i think
[07:03] <soren> "they"?
[07:03] <cooloney> the bug reporter
[07:09] <cooloney> sorry, i fail to find the LP bug URL
[07:27] <Z3ro3X> Is there a repo that will allow me to always have the latest stable kernel?
[07:44] <YokoZar> Z3ro3X: define "stable"
[09:58] <mnemo> FYI: this bug report indicates that jaunty probably carries a sauce patch that accidently forces swrast powerbook G4's machines... see discussion here --> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/370200 and also this upstream bug --> https://bugs.freedesktop.org/show_bug.cgi?id=21367
[09:58] <ubot3> Malone bug 370200 in mesa "r300 on "PowerBook G4" mac: only swrast after booting and backgrounds render blue instead of black" [Undecided,New]
[17:19] <G__81> hi everyone
[18:39] <manjo> ogasawara, ping
[20:28] <shadowland> I'm trying to run "make pdfdocs" on linux kernel directory, but it complains about not having passivetex, which doesn't seem to exist in repositories
[20:28] <shadowland> Anyone know how to build the pdfdocs?


[08:57] <james_w> anyone have any ideas about https://bugs.launchpad.net/juju-core/+bug/1374159 ?
[08:57] <mup> Bug #1374159: Complains about wanting juju-local installed when it is <juju-core:New> <https://launchpad.net/bugs/1374159>
[08:57] <james_w> It's preventing me from using juju currently
[08:57] <james_w> as it doesn't work for long enough to complete a deploy of my test environment
[10:08] <jamespage> gnuoy, the unit test fix is to add hooks.hooks._config_save = False
[10:08] <jamespage>
[10:09] <jamespage> to the relations tests for the openstack charms - I have this in my https split branches
[10:09] <gnuoy> jamespage, yes, corey and I did that to the quantum-gateway charm last night
[10:09] <gnuoy> jamespage, oh, that's not exactly what we did
[10:10] <gnuoy> jamespage, so you want the implicit save on when the charm is running for realz ?
[10:10] <jamespage> gnuoy, yeah
[10:10] <jamespage> gnuoy, it does not hurt - we might want to use it later on
[10:10] <jamespage> gnuoy, so disabling it for testing is just fine
[10:11] <gnuoy> k
[10:11] <jamespage> gnuoy, we could just land that in as a resync + a trivial change
[10:12] <gnuoy> jamespage, will do
[10:16] <gnuoy> coreycb, after talking to james ^ I've tweaked the config_save  in the quantum-gateway next charm http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/quantum-gateway/next/revision/65
[11:40] <coreycb> gnuoy, ok good to know
[11:47] <rick_h_> marcoceppi: lazyPower any chance you all can help reshare/get the word out today? https://plus.google.com/116120911388966791792/posts/9KaLE7m9hv9 and https://twitter.com/jujuui/status/515467739951923200
[12:13] <james_w> anyone have any ideas about https://bugs.launchpad.net/juju-core/+bug/1374159 ?
[12:13] <mup> Bug #1374159: Complains about wanting juju-local installed when it is <juju-core:Incomplete> <https://launchpad.net/bugs/1374159>
[12:13] <james_w> It's preventing me from using juju currently as it doesn't work for long enough to complete a deploy of my test environment
[12:22] <james_w> rick_h_: nice screencast, it looks really slick, congrats to those involved
[12:22] <rick_h_> james_w: ty much, sorry I don't have any clue on your bug to trade for the nice comments :/
[12:23] <james_w> no problem
[12:23] <james_w> rick_h_: what can provide the hardware details in the machine view?
[12:23] <rick_h_> james_w: so there was a bug in MAAS that was fixed and I think is in 1.20.8 (but this video was before then)
[12:23] <james_w> ah, ok
[12:24] <rick_h_> james_w: and ec2 shows it, you can see it in makyo's video https://www.youtube.com/watch?v=pRd_ToOy87o&list=UUJ65UG_WgFa_O_odbiBWZoA
[12:24] <james_w> rick_h_: I'm only sad that we can't really use this work.
[12:24] <rick_h_> james_w: so it's we'll hopefully get it everywhere in time
[12:24] <rick_h_> james_w: :( why is that?
[12:25] <james_w> rick_h_: a couple of reasons really
[12:25] <james_w> 1. we don't have access to our production environments
[12:25] <james_w> 2. manual modification of environments doesn't suit our workflow
[12:25] <james_w> we want an approval workflow that is driven from a desired state in version control
[12:25] <rick_h_> james_w: ah yea, though with juju auth support coming we've still got the idea of read only and such
[12:26] <james_w> yeah, that will be nice
[12:26] <james_w> so we can poke around
[12:26] <rick_h_> james_w: true, however we'll also be adding some things like linking directly to exposed ip/ports per unit in machine view and such
[12:26] <james_w> but we'll miss out on the really nice uncommitted changes features etc.
[12:26] <rick_h_> so now that we show you a real 'per unit' look we can hopefully provide some useful stuff like 'kill that unit' or what would be cool with canary upgrade work to show progress in machine view
[12:26] <rick_h_> gotcha, yea
[12:27] <james_w> but this all looks really nice
[12:27] <james_w> and I'm sure it goes over well with customers
[12:27] <rick_h_> definitely, well hopefully some people who don't use the gui much will have some real use for it and thanks for that feedback.
[12:27] <james_w> yeah
[12:27] <rick_h_> it helps us know what things we can look to offer that we don't currently
[12:28] <rick_h_> and check out the roadmap
[12:28] <james_w> I'm trying to think if it could evolve such that we could use the modification features of the gui
[12:28] <james_w> I think it would only really be useful for testing out changes, and then exporting a diff when finished
[12:29] <james_w> without some very substantial modifications
[12:38] <johnmc> rick_h_: The updated gui looks excellent. A very impressive step up. I see I can get the source on github. Is there a ppa or other repo I can download it from?
[12:38] <rick_h_> johnmc: juju deploy juju-gui
[12:38] <rick_h_> johnmc: well juju deploy trusty/juju-gui
[12:38] <johnmc> rick_h_: of course. Thanks.
[12:39] <rick_h_> johnmc: if you mean source for hacking, there's a LP release tarball as well https://launchpad.net/juju-gui/+download
[12:39] <rick_h_> johnmc: but yea, deploy it to check it out in your environment
[13:26] <rm4> is it possible to avoid haproxy being a single point of failure by adding extra instances with add-unit
[13:29] <aisrael> rick_h_: nice work on the new gui. Watching the ghost walkthrough now. That's slick.
[13:29] <rick_h_> aisrael: thanks, team worked long and hard on that and exciting to get it out there.
[13:33] <rick_h_> rm4: I'm not 100% sure but it looks like it provides some peer relation-fu that would seem to work towards that end. http://bazaar.launchpad.net/~charmers/charms/precise/haproxy/trunk/view/head:/hooks/hooks.py#L563
[13:33] <rick_h_> rm4: it'd be a good bug on the charm to update the readme to address your question directly as I'm sure others wonder the same thing
[13:47] <rm4> rich_h_: I can create the peering and get the following
[13:48] <rm4> backend haproxy_service
[13:48] <rm4>     mode tcp
[13:48] <rm4>     option tcplog
[13:48] <rm4>     balance leastconn
[13:48] <rm4>     server haproxy-0 <IP_ADDRESS>:81 check
[13:48] <rm4>     server haproxy-1 <IP_ADDRESS>:81 check backup
[13:50] <rm4> so it does peer fine however not sure if it has a vip keepalived for example as when I destroy the  the first server then its ip address is not accessible
[13:51] <lazyPower> rick_h_: Consider it done :)
[13:52] <rick_h_> lazyPower: ty much
[13:58] <avoine> hey bloodearnest how went your presentation at pycon uk?
[14:02] <rm4> rick_h_: I have submitted bug 1374465
[14:02] <mup> Bug #1374465: Readme does not have a peering section allthough peering is permitted. <haproxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1374465>
[14:03] <rick_h_> rm4: awesome thanks!
[14:04] <rm4> rick_h_: of course
[14:09] <bloodearnest> avoine: went ok thanks. Some issues with the gui freezing up prevented the full demo
[14:09] <bloodearnest> avoine: but mfoord is dping the same demo in pycon india this weekend
[14:09] <rick_h_> bloodearnest: :(
[14:09] <rick_h_> bloodearnest: any hint what was up?
[14:10] <bloodearnest> rick_h_: well, it was a mac, using parallels to run a vm, deployed to local provider, and untested. We had to use mfoord's mac because my laptop wouldn't connect to the projecter :/
[14:11] <rick_h_> bloodearnest: ok, well let me know if there's anything we can help take a look at
[14:11] <bloodearnest> avoine: I added some support for the django charm to cope with multi-unit postgres services, and it handles failover nicely
[14:11] <rick_h_> bloodearnest: and let mfoord know machine view is out for any follow up talks in case it fits the demo/material you all covered
[14:12] <bloodearnest> avoine: also, added dj-static as a simple static asset solution. We're using it in prod, with a squid infront it works well. Simple deployment.
[14:12] <bloodearnest> rick_h_: yeah, we didn't get to the bottom of it. But I think macs hate me, so that's probably it. Feeling's mutual :)
[14:12] <rick_h_> bloodearnest: hah ok
[14:13] <lazyPower> sinzui: question for you. I have ~ 4 bugs i need to retarget away from teh charms collection to point to a personal branch - and i can't seem to do that in launchpad via the project data point - any hints would be helpful : https://bugs.launchpad.net/charms/+bug/1374267
[14:13] <mup> Bug #1374267: ctap-sampleapp crashes on logout <Juju Charms Collection:New> <https://launchpad.net/bugs/1374267>
[14:13] <sinzui> lazyPower, Lp only permits projects, distros, and distro-packages to have bugs
[14:14] <lazyPower> so i can't retarget these bugs against the users namespaced charm?
[14:14] <sinzui> lazyPower, that's right
[14:15] <lazyPower> D: that seems... not right
[14:15] <sinzui> lazyPower, a branch is personal
[14:15] <lazyPower> as a personal namespaced charm is still a project in LP
[14:15] <lazyPower> or am i misunderstanding a core tenant of LP's structure?
[14:15] <sinzui> lazyPower, when issues are shared by a group, the branch needs to be promoted to the project level...but Lp is to ass-backwards to explain that
[14:16] <avoine> bloodearnest: yeah, I saw your MP, it is pretty cool. I'll definitely check dj-static
[14:16] <marcoceppi> lazyPower: we need to create the packagae in lp for charms first off
[14:17] <bloodearnest> avoine: the implementation of installing in the charm and running collectstatic is a quick hack, I think it could be done better
[14:17] <sinzui> lazyPower, Lp is not about the individual, it actually alienates the opportunistic developer by calling work +junk. Lp wants groups to collaborate, but never explains one person needs to create something valuable, then share it as a project
[14:17] <bloodearnest> avoine: collectstatic is not actually needed with dj-static
[14:17] <lazyPower> i guess what confuses me is https://bugs.launchpad.net/charms/trusty/+source/hsenidmobile-ctap-sampleapp - leads me to believe i could do this without much fuss
[14:18] <avoine> bloodearnest: I was planning adding a subordinate that install django-storage and connect to s3 or swift
[14:18] <avoine> but for now I was using this: https://code.launchpad.net/~patrick-hetu/+junk/django-contrib-staticfiles
[14:18] <marcoceppi> lazyPower: we need to make a new tag, that's like "not-a-charm"
[14:19] <lazyPower> marcoceppi: agreed. I'll tag these with that exact phrasing
[14:19] <marcoceppi> that we can have review-queue ignore for the time being
[14:19] <marcoceppi> I'm releasing new review-queue today, I can add that in there
[14:19] <sinzui> lazyPower, since the developer is the "first" community, Lp was never going to attract developers like github
[14:20] <lazyPower> sinzui: thanks for the clarification. I'm a little saddened by this news but its not the end of the universe.
[14:21] <bloodearnest> avoine: swift is not yet good as s3 for serving static assets
[14:21] <bloodearnest> avoine: we are taking the approach of using dj-static and sticking squid in front
[14:21] <avoine> bloodearnest: yeah I bet that work pretty well
[14:22] <bloodearnest> avoine: two big advantages are 1) single deployment target (just your django units need updating) and 2) same in dev as in prod (as dj-static works in dev too)
[14:22] <bloodearnest> avoine: but for a lot of large assets, s3 might be better
[14:22] <bloodearnest> like videos
[14:22] <bloodearnest> and mp3s
[14:23] <avoine> yeah
[14:24] <avoine> bloodearnest: any thoughts on the python vs ansible approach?
[14:29] <bloodearnest> avoine: so, I'm a bit confused. You are using ansible, but *not* the hooks integration, just apply_playbook. And you also have ansible for controlling juju from the hosts?
[14:33] <avoine> bloodearnest: I was planning to use AnsibleHooks and using it with Juju on the hosts
[14:33] <avoine> bloodearnest: but I'm not sure if the overhead of Ansible worth the trouble
[14:33] <bloodearnest> avoine: great. I'd be happy to help with that.
[14:33] <bloodearnest> avoine: right.
[14:34] <lazyPower> avoine: are you planning on submitting this charm for recommended status from the charm store?
[14:34] <avoine> lazyPower: no not soon
[14:34] <avoine> lazyPower: I'll stick with the pure python for now
[14:34] <lazyPower> ok. I was going to interject that if you want help wrapping that up in proper charm format, we have an ansible charm template for use, and integrating it into juju hooks is pretty straight forward
[14:35] <lazyPower> if you're using a recent edition of charm tools `charm create -t` gives you some options for that
[14:35] <avoine> nice I didn't know that
[14:39] <bloodearnest> lazyPower: nice!
[14:39] <lazyPower> uh oh, i get the feeling we haven't been very forthcoming with the information about charm create -t
[14:40]  * lazyPower prepares an email to the list
[14:45] <bloodearnest> lazyPower: also, have you seen my charm helpers branch that adds super-simple "actions"? We make extensive use of juju run <unit> "actions/some-action a=b c=d" type stuff, which this branch makes easy to integrate with ansible
[14:45] <lazyPower> bloodearnest: i have not, but if its not in the review queue chances are I didn't see it
[14:45] <bloodearnest> https://code.launchpad.net/~bloodearnest/charm-helpers/ansible-actions/+merge/233428
[14:45] <lazyPower> http://review.juju.solutions
[14:52] <johnmc> As discussed yesterday with natefinch and sinzui, I can no longer create LXC containers using juju-maas on one of my machines.
[14:52] <johnmc>  Working back through my history to the last thing I did before it broke, I might have found something.
[14:53] <johnmc> I checked-out (bzr branch) the precise haproxy charm onto my machine and tried to deploy it into a trusty LXC machine
[14:53] <johnmc> I then back-tracked and realised I should have been working with hacluster under trusty
[14:53] <bloodearnest> lazyPower: I don't see my branch on there, what to I need to do to make it appear? It should be under tools, right?
[14:54] <johnmc> Does anyone know if that could explain my now-broken environment
[14:54] <lazyPower> bloodearnest: that queue may not be implemented yet. I know we're moving at breakneck speed on the new queue
[14:55] <johnmc> I'm also finding it impossible to deploy hacluster linked to glance.
[14:55] <bloodearnest> lazyPower: coolio
[14:55] <lazyPower> bloodearnest: maybe its worth while to open a bug against the review queue so we can track progress on implementation
[14:56] <lazyPower> bloodearnest: for now it lives here but will eventually be moved to github.com/juju-solutions  --- https://github.com/marcoceppi/review-queue
[14:58] <johnmc> When I deploy the glance charm and fire-up a new pair of glance instances, then link that to a new hacluster instance, I het this in the logs: http://pastebin.com/ZtNA7UmT
[15:01] <johnmc> That big long list of "INFO hanode-relation-changed Cleaning up res_glance_haproxy:0 on juju-machine-.-lxc-.." lines represent every glance instance I think I've ever had an subsequently destroyed.
[15:01] <johnmc> Things look really badly broken. Can anyone help?
[15:05] <johnmc> natefinch: Are you around to help?
[15:05] <natefinch> johnmc: yes, but trying to drum up someone more helpful ;)
[15:06] <natefinch> johnmc: glance and hacluster are beyond my knowledge
[15:07] <natefinch> johnmc: did you get any more help from sinzui last night?  I saw you got an upgrade half-finished, which is never a great place to be
[15:07] <sinzui> Ah, no, I had to switch to OS X to complete the release
[15:08] <johnmc> natefinch: I didn't make any progress on that. sinzui said that the upgrade can't be done while those LXC (requested) machines are there. I have no idea how what to do next.
[15:09] <sinzui> johnmc, When the containers are there, but the machine/unit agents are down, you can restart each
[15:10] <johnmc> natefinch: I'm hoping that the attempt to install the precise haproxy charm into trusty might turn out to be a common cause of both the LXC problem, and the hacluster problem.
[15:10] <sinzui> johnmc, I have a brittle arm64 machine that I do this from time to time. I think restarting the machine agent first is best
[15:11] <johnmc> sinzui: the containers don't actually exist. I requested their creation, but they were never actually created.
[15:11] <sinzui> johnmc, 1.18.x was a bad time for arm64, so I did restarts of the agents, then the queued upgrade was dequeued and 5 minutes later the upgrade was complete, and the agents stayed up
[15:11] <johnmc> sunzui: I have restarted the machine agent (on the base system) many times
[15:12] <johnmc> sinzui: there are no agents, because there are no LXC containers. That is how my system is broken.
[15:12] <sinzui> restarting the state-server agents are orthogonal
[15:14] <sinzui> johnmc, If lxc gets blocked on a machine a lot of manual work is needed to unblock http://pastebin.ubuntu.com/8427862/
[15:14] <sinzui> johnmc, I think you need to confirm which containers exist with sudo lxc-ls --fancy
[15:15] <johnmc> I have already been through that in detail with nate yesterday. The LXC containers do not exist. I pasted this output yesterday
[15:15] <sinzui> johnmc, Since you cannot destroy your env and start over, I think you need to use remove-unit or destroy-machine to make juju forget about the failed containers and try again
[15:16] <sinzui> johnmc, I don't have experience with destroying maas lxc containers
[15:16] <johnmc> http://pastebin.com/aGUAyizu
[15:17] <sinzui> johnmc, is this trusty with cloning enabled?
[15:17] <johnmc> sinzui: I have used "destroy-machine" and used --force to no avail
[15:18] <johnmc> sinzui: This is trusty. How is cloning enabled/disabled? I'm not familiar with that setting.
[15:18] <johnmc> I followed on online guide
[15:19] <sinzui> johnmc, are there locks named after lxc in /var/lib/juju/locks/
[15:21] <johnmc> sinzui: No such lock files on either the host system (machine 1) or the juju-agent machine. Where should I be looking for these?
[15:22] <sinzui> johnmc, the machine with the containers. When lxc doesn't create containers we investigate the host machine
[15:24] <sinzui> johnmc,the state-server doesn't do work. other machines ask it for a list of tasks. so when a machine has issues, we visit to investigate the local problem
[15:24] <johnmc> sinzui: There are no lock files.
[15:25] <johnmc> sinzui: As I explained to natfinch yesterday, there is no evidence that the host system ever received any request for new LXC contianers
[15:25]  * mgz reads log
[15:26] <mgz> johnmc: do you want to just clean up the lxc container stuff completely?
[15:26] <sinzui> johnmc, interesting, but the order of events is the host machine agent asks for the state server for work. status shows the state-server is waiting of the machine to do it's part
[15:29] <johnmc> sinzui: This failure appears to be totally silent with regard to log files. No files under /var/log change at all on the host system in response to a new LXC request.
[15:29] <johnmc> sinzui: If we had any log output at all we might get somewhere. How is this to be done?
[15:31] <sinzui> johnmc, I only know to look for logs in /var/log/juju. when there are no logs or logging stops, that might mean the files were removed, confusing the agents. restarting the agents will recreate the logs an there will be a flood of dequeued messages
[15:32] <johnmc> sinzui: As requesting new LXC containers has no impact, is it possible to there is a blocked queue of requests?
[15:33] <johnmc> sinzui: I've restarted the jujud for machine-1 many times, and verified (just now) that there are no deleted files being written to.
[15:33] <johnmc> sinzui: I used lsof to check open files. /var/log/juju/machine-1.log is used by jujud and is present
[15:34] <johnmc> sinzui: it's as though the juju-agent machine sends no requests to the host machine at all.
[15:37] <sinzui> oh...
[16:04] <johnmc> sinzui: Where do I go from here?
[16:10] <sinzui> johnmc, I am not sure what to do in this case. I don't have any experience with this. When the machine agent cannot talk to the state server, the logs will scream about it. You don't see this issue in the machine-1.log though.
[16:12] <sinzui> johnmc, I assume the machine-1.log you are reading never mentions ERROR.
[16:14] <johnmc> sinzui: The machine agent connects to the server. Netstat shows this has an open tcp connection to port 17070. However, no activity takes place. Shouldn't the jujud on the juju-agent server log something somewhere?
[16:16] <sinzui> johnmc, The machine-1  log should be stating it called home. The all-machines.log on the state server is puts all the actions in context.
[16:16] <johnmc> sinzui: the machine agent seems to lose it's connection to the juju-agent at least once a day. This is the latest log: http://pastebin.com/2PP8CK8G
[16:17] <sinzui> johnmc, This is obviously a bug. Can you report the issue at https://bugs.launchpad.net/juju-core and attach the all-machine.log for the developers. Please review the log though, Juju likes to include certs and password that you will want to redact
[16:19] <sinzui> johnmc, which version of juju did the env start as, and which have you upgraded too
[16:24] <johnmc> sinzui: it was 1.18.1 originally
[16:27] <sinzui> okay, that explains the upgrade already at 1.18.4 message
[16:27] <sinzui> though it implies something has not completed an upgrade to 1.18.4
[17:21] <bic2k> juju have any plans to directly support deploying a Docker container.
[17:30] <natefinch> bic2k: we've talked about docker a lot internally... you can certainly write a charm that deploys a docker container, in fact I wrote such a charm very recently.   Docker and juju work fine together now... what would you like to see done differently?
[17:32] <bic2k> natefinch: I also just finished writing a charm for deploying some internal docker services. Perhaps thats all we need :-)
[17:33] <natefinch> bic2k: I think the one thing that makes docker charms special is that it's relatively "safe" to deploy multiple of them to a single machine, rather than needing to put each of them in a separate LXC container (since they're already contained, of course)
[17:35] <bic2k> natefinch: Private docker registry was a bit of a challenge for us.
[17:35] <lazyPower> https://plus.google.com/100016143571682046224/posts/PaVGh51FYCR - i'm just going to leave this here...
[17:35] <natefinch> bic2k: ahh, yeah, I was deploying from a publicly available image, so that wasn't a concern
[17:36] <bic2k> natefinch: You deploying on 12.04 or 14.04?
[17:36] <natefinch> bic2k: 14.04
[17:37] <bic2k> natefinch: We hit some issues with getting docker installed on 12.04 through apt. Mostly the CLI tools to add a repo insist on adding deb-src and then failing when it isn't there.
[17:38] <natefinch> bic2k: why are you using 12.04?
[17:38] <bic2k> natefinch: our cluster is old and thats what its on :-)
[17:38] <natefinch> bic2k: ahh :)
[19:40] <avoine> lazyPower: what is the bundletester command I should run to test the python-django charm like you do?
[19:41] <avoine> lazyPower: also are you testing with python3 ?
[19:41] <lazyPower> avoine: negative. python2
[19:41] <avoine> ok
[19:41] <lazyPower> avoine: just `bundletester -F` after i cd into the charmdir
[19:41] <avoine> ok
[19:41] <lazyPower> pip install bundletester into a venv
[19:41] <lazyPower> then you get the same results we do when testing / CI does
[19:41] <avoine> ok
[19:42] <lazyPower> avoine: hth - i'm EOD'd for the rest of the day to prep for my show. If you need anything else, i'll be around this weekend/monday
[19:42] <avoine> ok, thanks
[20:42] <sebas538_> hi!
[20:42] <sebas5384> question: how bundle.yaml deals with local charms?
[20:43] <sebas5384> in the charm property, could be like
[20:43] <sebas5384> charm: local:precise/drupal
[20:43] <sebas5384> but how I specify the local repository
[20:44] <sebas5384> ?
[21:10] <sebas5384> the machine view is in https://jujucharms.com \o/
[21:10] <sebas5384> uhuu!! testing already :)
[21:23] <arosales> lazyPower|Spinni: just the stream for your session correct?
[21:23] <arosales> not hangout or anything like that
[21:26] <lazyPower|Spinni> arosales: not this week. maybe after brussels we'll setup a live in studio session to go with it.
[21:26] <lazyPower|Spinni> replies will be latent, i setup a mixing table this week.
[21:26]  * lazyPower|Spinni afk's again
[21:44] <d4rkn3t> hello guys, one question for MaaS and juju, is there a way to make the security upgrade on nodes added on MaaS and for the charms on juju, without make that one by one? thanks. If not it may be a suggest to add as app on MaaS anyone can answer me?
[21:44] <bic2k> d4rkn3t not that I have tried this, but you may be able to use the ssh command to run the appropriate apt-updates one machine at a time
[21:45] <d4rkn3t> I'd like to avoid that, because we've 500 virtual svr
[21:46] <d4rkn3t> i'd like to use MaaS to make that
[21:46] <d4rkn3t> for example select the nodes and launch the upgrade!!!
[21:47] <d4rkn3t> it's take too long time make that one by one
[21:50] <d4rkn3t> the same think is valid also for the charms deployed with juju
[21:51] <d4rkn3t> if I'd want to make the upgrade for example of MySQL deployed using juju, is there a procedure to make that?
[22:48] <rick_h_> d4rkn3t: there's a juju run command, and landscape is great at updates across hardware.
[22:49] <rick_h_> d4rkn3t: so in the mysql sense I'd juju run that across my mysql service.
[22:51] <rick_h_> d4rkn3t: https://www.youtube.com/watch?v=2d5KdQjXCBs is a cool video on juju run and juju run --help has some basic info.
[23:16] <lazyPower> I deny knowing anything about juju run :P
[23:16] <lazyPower> rick_h_: good looking out - i just got off stream and was going to suggest the same thing. hi5
[23:22] <hazmat> rick_h_, lazyPower  juju run --all "apt-get update && apt-get upgrade"
[23:24] <mwenning> marcoceppi, can you specify constraints when you deploy amulet?


[05:11] <mborzecki> morning
[05:40] <mborzecki> mvo: hi
[05:46] <mvo> hey mborzecki
[05:46] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/5756 looks like an easy win
[05:47] <mvo> mborzecki: indeed, thank you. technically this needs a review from jamie from security but I'm not sure its really needed for such a trivial one
[05:48] <mvo> mborzecki: how are tests this morning?
[05:48] <mborzecki> mvo: yeah, those files are just manufacturer an product human readable strings :)
[05:49] <mborzecki> mvo: hard to tell, restarted a few jobs, but those were failures from yday
[05:50] <zyga> Good morning
[05:52] <zyga> Mborzecki I could use some HO time today
[05:52] <zyga> I found a case that doesn’t work (not trespassing, that is ok)
[05:52] <zyga> And I wanted to discuss if
[05:52] <zyga> It
[05:52] <mborzecki> zyga: ok
[05:53] <mvo> zyga: good morning
[05:54] <mvo> mborzecki: I will merge once tests are green
[05:54] <zyga> Essentially the case is this: you have a symlink a->b in writable space, you want a->c instead
[05:54] <zyga> Hey. School saga day two
[05:54] <zyga> Today we just bail
[05:55] <zyga> I was thinking we should I link and symlink
[05:55] <zyga> I link and symlink
[06:40] <mborzecki>  build has failed
[06:40] <mborzecki> Build #24748 was borken
[06:40] <mborzecki> hm we're not out of the woods yet
[06:43] <mborzecki> wonder if we could use the fakestore in those tests
[06:49] <mborzecki> mvo: can you upload the release files to github?
[06:50] <mvo> mborzecki: yes, sorry, will do so in a minute
[06:50] <mborzecki> mvo: thanks!
[06:51] <mvo> also looks like master has a problem building on various arches in master :/ oh well, I look at this in a little bit too
[06:57] <mvo> mborzecki: done
[06:57] <mborzecki> mvo: thank you
[06:58] <mborzecki> mvo: i'll drop snapd.failure.service and snap-failure at the package level for now
[06:58] <mvo> mborzecki: please do
[06:59] <mborzecki> a siminiar thing will be needed for fedora (neal if offline?) and opensuse (cc zyga)
[07:16] <mborzecki> arch package updated
[07:16] <zyga> re
[07:16] <zyga> what's the problem?
[07:16] <zyga> btw, I'm entirely re-working suse packaging
[07:17] <zyga> it's a bit of a sad/happy story that I can share during the standup
[07:19] <mborzecki> zyga: https://aur.archlinux.org/cgit/aur.git/commit/?h=snapd&id=a23bdc8eb207c2a1312d74377dfcf8e56e25094f
[07:19] <pstolowski> mornings
[07:20]  * zyga looks
[07:20] <zyga> hey pawel :)
[07:20]  * zyga is working from a restaurant garden today
[07:20] <zyga> ahhh
[07:20] <zyga> I see
[07:20] <zyga> thank you for sharing mborzecki
[07:21] <mborzecki> pstolowski: hey
[07:21] <mborzecki> btw. have you noticed something about ohmygiraffe, or maybe it's our pulseaudio interface
[07:22] <mborzecki> when i restart pulseaudio (pulseaudio -k) and start ohmygiraffe after that, there's no sound
[07:23] <zyga> mborzecki: probably different filename/cookie value
[07:24] <mborzecki> zyga: right, but it's read from .pulse-cookie
[07:25] <zyga> is it?
[07:25] <zyga> it's unlikely
[07:27] <mborzecki> zyga: i'd gues .pulse-cookie contains the cookie, it's different each time pulseaudio starts, but at the same time i'd expect libpulse to read and use the new cookie
[07:27] <zyga> but the cookie is in a dot file in HOME
[07:27] <zyga> so it's probably not read from that
[07:27] <zyga> probably read from the x server root window
[07:28] <mborzecki> the log with PULSE_LOG=4 shows it's trying /run/user/1000/snap.ohmygiraffe/pulse/native to no avail
[07:29] <mborzecki> and $XDG_RUNTIME_DIR/pulse is indeed empty
[07:29] <mborzecki> i have a vague recollection we fied that in desktop helpers?
[07:30] <zyga> maybe
[07:30] <zyga> but I'd look at xprops
[07:30] <mborzecki> heh, symlinked in in snap shell, works now
[07:30] <mborzecki> ln -s ../../pulse/native $XDG_RUNTIME_DIR/pulse/native and magically works :/
[07:31] <mborzecki> zyga: xprop -root |grep -i pulse comes up empty
[07:32] <zyga> hmm
[07:32] <zyga> and without pulse?
[07:32] <zyga> anything else there?
[07:34] <mborzecki> zyga: with or without looks the same
[07:34] <zyga> are you on wayland?
[07:37] <mborzecki> zyga: no x11
[07:38] <mborzecki> ok, so it'd be nice to rebuild the snap to pick up the fixes in snapcraft-desktop-helpers
[07:38] <zyga> in that case my theory is broken, no idea
[07:38] <mborzecki> we have a fix there already (apparently i was the one to add it) whcih exports PULSE_SERVER
[07:40] <mborzecki> popey: any chance you could rebuild ohmygiraffe using more recent snapcraft?
[07:42] <zyga> mborzecki: I'm re-working the restricted/desiredPath into a structure that holds the pair
[07:45] <mborzecki> need conffee
[07:48] <zyga> cofefe
[07:49] <Raboo> how do I figure out what settings a snap has?
[07:49] <Raboo> btw snapcraft.io times out alot since yesterday
[07:55] <Raboo> ah there is a get
[08:01] <zyga> Raboo: hey
[08:01] <zyga> yeah, the store was wonky yesterday, it's all resolved I heard though
[08:01] <zyga> Raboo: snap configuration doesn't have a schema yet but you can indeed use get to look at the data that is set right now
[08:01] <Raboo> zyga ok
[08:01] <mborzecki> zyga: doesn't look resolved to me
[08:02] <zyga> oh?
[08:02] <zyga> the store is still wonky?
[08:02] <Raboo> trying out the chromium-mir-store
[08:02] <Raboo> s/store/kiosk/
[08:02] <mborzecki> zyga: afaict it is
[08:02] <Raboo> zyga still wonky
[08:02] <zyga> :/
[08:02] <ppisati> ogra_: xenial or bionic only? if we could find a way to reproduce it, it would be nice
[08:04] <wgrant> zyga: It was all resolved, but is having some minor trouble now. Should be working again.
[08:04] <sparkiegeek> zyga: please just look at (and refer people to) https://status.snapcraft.io
[08:05] <zyga> thank you, will do
[08:05] <sparkiegeek> we (store team) will keep that up to date, and avoids "I heard" games of Telephone
[08:07] <Raboo> does the chromium-mir-kiosk people hang here? I'm wondering what I need to do to enable audio and webcam
[08:09] <mvo> Chipaca: good morning!
[08:10] <mvo> Chipaca: I think you tricked me into writing tests for store.go:download() ;)
[08:10] <Chipaca> mvo: morning!
[08:10] <mvo> Chipaca: we do not test this explicitly, do we?
[08:10] <Chipaca> mvo: only that if wasn't covered!
[08:10] <Chipaca> mvo: probably not explicitly, the tests will be fore Download
[08:10] <Chipaca> or whatever
[08:11] <Chipaca> mvo: can't you parametrise one of the existing tests?
[08:11] <Chipaca> mvo: as in, TestDownload(*C) -> testDownloadMaybeWithRateLimit(*C, bool)
[08:11] <mvo> Chipaca: not sure, afaict we mock func download away pretty much everywhere
[08:11] <Chipaca> hmm
[08:11]  * Chipaca looks
[08:13] <mvo> Chipaca: I looked at storeTestSuite and in SetUpTest it mocks it away and I don't see where its unmocked :/ but again, maybe blind :)
[08:16] <zyga> hey John, good morning
[08:16] <zyga> mborzecki: hey
[08:16] <zyga> do you have a sec for HO?
[08:16] <mborzecki> sure
[08:16] <mborzecki> sec
[08:17] <mborzecki> zyga: ok, i'm there
[08:17] <zyga> k, joining
[08:18] <pedronis> Chipaca: mvo: we should have some tests for download,  what I'm not sure is whether we have tests for Download calling download
[08:18] <Chipaca> pedronis: mvo: look for TestActualDownload
[08:18] <Chipaca> pedronis: mvo: there are a bunch
[08:19] <Chipaca> coverage is bright green, not the pale green of only-barely-covered
[08:19] <Chipaca> zyga: hey zyga
[08:19] <Chipaca> zyga: I'm assuming you mean me when you say 'hey John' :-)
[08:20] <pedronis> Chipaca: mvo: SetUp stores it away to restore, it doesn't mock it  afaict
[08:20] <mvo> Chipaca: clearly the tea then, thanks, I will add
[08:21] <pedronis> s.origDownloadFunc = download
[08:21] <mvo> Chipaca: to that family plus adding one that does the download directly
[08:21] <Raboo> This is my interfaces http://termbin.com/nm9z, do I need to connect anything more to enable camera and audio for chromium-mir-kiosk?
[08:21] <mvo> pedronis: yeah, thanks. I see it now, sorry for the noise
[08:21] <pedronis> mvo: well store_test.go is a bit of a jungle
[08:22] <pedronis> but at least this bit is kind of straighforward
[08:22] <mvo> pedronis, Chipaca would you mind if I change this to use MockDownload ? to make it a bit more like the other parts?
[08:22] <mvo> pedronis: yeah, sorry again
[08:22] <mvo> (probably in a separate PR)
[08:22] <pedronis> I don't know
[08:22] <Chipaca> pedronis: mvo: it wasn't obvious fwiw, I had to add a panic() to the download() :-)
[08:22] <pedronis> it's a step in the right direction otoh  I think that file needs a more general attack
[08:22] <mvo> Chipaca: heh, thanks for comforting me :)
[08:23] <mvo> pedronis: I would move the actual download tests into its own suite plus add mocking via export_test.go as a first step. but I'm fine leaving it if there is a bigger plan in place
[08:23] <pedronis> mvo: there are not bigger plans
[08:24] <pedronis> mostly noticing that Mock* is not used  much around there
[08:24] <pedronis> mvo: the main issue is really that   store_test.go  is "package store"
[08:25] <pedronis> only unclarity comes from that
[08:25] <Chipaca> store really needs some love, yes
[08:25] <pedronis> it and daemon are the few places left doding that
[08:25] <mvo> pedronis: yeah
[08:25] <Chipaca> daemon is 100% my fault :-|
[08:25] <mvo> pedronis: I have a look
[08:25]  * pedronis is only morning and I cannot type
[08:25] <mvo> Chipaca: its the fault of history
[08:25]  * mvo hugs Chipaca
[08:26] <Chipaca> :-)
[08:27] <Chipaca> anyway, back to snapshotstate tests for me
[08:38] <popey> mborzecki: sure, what's the issue I'm solving by rebuilding omg?
[08:41] <Chipaca> HAH! found you, you nasty effluvia
[08:43] <ackk> hi. where is "snapctl" localed in the snap? it seems it's not in path by default in hooks
[08:43] <ogra> ppisati, ubuntu core 16 ... 4.4 kernel
[08:44] <Chipaca> ackk: /usr/bin/snapctl
[08:44] <ackk> Chipaca, oh, wait it seems it's missing in core18?
[08:45] <Chipaca> ackk: shouldn't be, but :-)
[08:45] <Chipaca> ackk: do you have core, or snapd snaps?
[08:45] <ogra> ppisati, the systems are all the same, running a webcam with mjpg-streamer (so there is a lot of data going over the net) ...
[08:45] <ackk> Chipaca, I have "core" but the snap I'm working on is based on core18
[08:46] <ackk> Chipaca, confirmed, no snapctl in core18
[08:46] <Chipaca> ackk: right, core18 doesn't ship any of snapd; that's shipped in the snapd snap (in the new world) or in the core snap (in the old world)
[08:46] <Chipaca> ackk: snapd should be smart enough to find it and put it where it's expected though
[08:46] <Chipaca> mvo: any issues here ^?
[08:46] <ackk> Chipaca, so how do I base a snap on core18 and use hooks?
[08:47] <Chipaca> ackk: as I say, it should just work -- you shouldn't need to care
[08:47] <Chipaca> ackk: you've found a bug, maybe
[08:47] <Chipaca> ackk: waiting for word from mvo who is the god of core18 and hugs
[08:47] <ackk> Chipaca, should I have a "snapd" snap as well?
[08:47] <ackk> I don't
[08:47] <Chipaca> ackk: no you should not need it
[08:47] <Chipaca> ackk: can you check if it's in /usr/lib/snapd/ ?
[08:48] <Chipaca> snapctl i mean
[08:48] <mvo> ackk: are you using the "beta" or "edge" of core18 ? if not, please try that
[08:48] <ackk> Chipaca, it's not
[08:48] <ackk> mvo, no I'm using stable, I'll try edge
[08:49] <ackk> mvo, that worked, thanks
[08:49] <ackk> mvo, btw are pre-refresh and post-refresh hooks already supported in released snapd?
[08:49] <mvo> ackk: that should work, yes
[08:50] <ackk> cool
[08:50] <ackk> Chipaca, mvo  thanks
[08:55] <Chipaca> pedronis: that thing where the cleanup test would freeze that had me stumped? was an actual bug :-D
[08:55] <pedronis> Chipaca: ok
[08:56]  * pstolowski -> school run
[08:57] <ackk> Chipaca, unrelated, do you know if it's possible to run ssh confied in a snap? I've been trying but it fails on setgroups call and I can't log in
[08:58] <Chipaca> ackk: ssh should work (there might even be an interface to let it get the host keys); sshd might need tweaking
[08:58] <mborzecki> popey: the one i know of is it'll get properly exported PULSE_SERVER, so even if you restart pulseaudio the sound will work
[08:58] <zyga> Chipaca: indeed
[08:58] <ackk> Chipaca, right, I want sshd
[08:58] <Chipaca> ackk: if you arm yourself with logs and patience jd_strand might be able to help
[08:59] <Chipaca> ackk: sshd has a lot of levers you can pull via config :-)
[08:59] <Chipaca> ackk: but: if it tries to setuid, it won't work
[08:59] <ackk> Chipaca, right, I've been trying that, including AllowedUsers/Group and so on, but I couldn't get it to work
[08:59] <Chipaca> setgroups sounds like part of that family
[08:59] <ackk> Chipaca, right, I suspect it would work if it could use a "nobody" user
[09:00] <ackk> Chipaca, basically I wanted an isolated sshd so that I can use it as a target for sshuttle-based VPNs
[09:00] <Chipaca> ackk: nice
[09:00] <ackk> Chipaca, it would be if it worked :)
[09:01] <Chipaca> ackk: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461?u=chipaca fwiw
[09:02] <ackk> Chipaca, yeah I know about that thread, it's something we'd like for the maas snap too
[09:06] <Chipaca> k
[09:13] <niemeyer> ackk: We discussed the idea of introducing a "daemon" user early on, using the same model of the final design.. might work for those cases before the whole thing is fleshed out
[09:13] <niemeyer> Mornings, btw
[09:16] <ackk> hi niemeyer, yeah I think that would be enough for our use case
[09:16] <ackk> (daemons that refuse to run as root)
[09:17] <niemeyer> ackk: Yeah, that's indeed the reason why that idea came up
[09:18] <Chipaca> pedronis: Settle(t) always take t? I thought it was a maximum but in practice it looks like a mminimum (at least when there's cleanup involved)
[09:19] <thresh> popey, sparkiegeek ping vlc stuck in store
[09:20] <sparkiegeek> thresh: hmm, sorry about that :/ I've re-triggered the checks again on 3.0.4
[09:20] <thresh> sparkiegeek, np and thanks!
[09:24] <pedronis> Chipaca: it's complicated,   t doesn't cover time some scenarios
[09:24] <Chipaca> pedronis: hmm
[09:24] <Chipaca> pedronis: what I'm seeing is that cleanup gets called again and again
[09:25] <Chipaca> hmm
[09:25] <Chipaca> pedronis: if cleanup returns error it just gets called again?
[09:25] <pedronis> Chipaca: ah, yes,  no basically cannot return errors from cleanups
[09:25] <pedronis> unless you think being called forever is what you want
[09:26] <Chipaca> pedronis: thank you for having me write these tests ;-)
[09:40] <dot-tobias> Hi everyone. Quick question concerning the Ruby plugin: Is there a way to preserve a built Ruby version across iterations as long as I don't change the ruby-version keyword? I'm experimenting with different stage-packages and the plugin rebuilds Ruby from source on every iteration.
[09:58] <sparkiegeek> thresh, popey: it is now unstuck
[09:59] <Chipaca> dot-tobias: I'm not sure who, short of sergiusens or kyrofa, can answer that
[10:11] <zyga> mborzecki: I think I found another logic quirk in my code
[10:11] <zyga> eh eh
[10:11] <zyga> but I'll commit everything and push it for review
[10:11] <mborzecki> ok
[10:11] <zyga> then work on your branch
[10:11] <zyga> mborzecki: essentially the call to LiftRestrictions is fine
[10:11] <zyga> mborzecki: but what if we did /rofs/<mimic>/a
[10:11] <zyga> mborzecki: and want to make /rofs/b then?
[10:11] <zyga> mborzecki: we remember that /rofs is a tmpfs we made
[10:12] <zyga> mborzecki: so we'll make b
[10:12] <zyga> that will work
[10:12] <zyga> mborzecki: but /rofs/a/c
[10:12] <zyga> mborzecki: that will go to rofs, it's a tmpfs so we carry on, then we will see an _existing_ directory a and bail out
[10:12] <zyga> (because we may not attempt writes there)
[10:12] <zyga> it's non-trivial :/
[10:13] <zyga> mborzecki: because as I coded it so far, we only lift restrictions when making a new directory on top of a tmpfs mount point
[10:13] <zyga> mborzecki: to allow /rofs/a/c we'd have to keep track of other mount ops and ensure that /rofs/a/ is not populated
[10:13] <zyga> mborzecki: it can be a fix on top of this branch I suspect
[10:13] <zyga> but meh, this is hard stuff
[10:14] <mborzecki> heh, maybe we should try whiteboard instead :P
[10:15] <zyga> mborzecki: we need the "are you evil" bit
[10:16] <mborzecki> zyga: it feels like you'd need to comb through the ops and match the longest prefix of current path
[10:16] <zyga> mborzecki: we also need to keep track of mount changes we started with (current mount profile)
[10:16] <zyga> mborzecki: well, not sure, it's all complex (you can have filesystems and symlinks there)
[10:19] <mborzecki> zyga: we could track just the current state, but then symlinks don't show up because it's kind of side channel
[10:19] <zyga> mborzecki: we cannot track just the current state, we are called _update_ ns for a reason
[10:21] <mborzecki> zyga: i meant tracking the 'current state' after each change, but that's not helping either
[10:22] <mborzecki> zyga: btw. what if symlinks were applied last?
[10:22] <zyga> mborzecki: we know in order
[10:22] <zyga> mborzecki: I mean, we know it all
[10:23] <zyga> but it's hard to come up with an algorithm can respond reliably to the set of questions we have
[10:31] <zyga> mborzecki: pushed!
[10:33] <zyga> I'm making the PR now,
[10:36] <zyga> mborzecki: I have an idea how to fix /rofs/a/c
[10:36] <zyga> if we know /rofs/a and we can fstat it we can check the device major number
[10:37] <zyga> (and the magic/type value)
[10:37] <zyga> *fstatfs
[10:37] <zyga> Then we can fstatfs /rofs/a/c and also allow it iff it is still a tmpfs and has a major number that matches one of the past ones we've checked
[10:37] <zyga> since we must have traversed /rofs/a/ we will know the major number
[10:38] <zyga> anyway
[10:38] <zyga> that's a follow-up
[10:43] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/5760
[10:43] <zyga> mborzecki: I'll look at your PR now
[10:48] <zyga> mborzecki: just to double check: https://github.com/snapcore/snapd/pull/5758
[10:49] <zyga> this one?
[10:54] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/5713
[10:54] <mborzecki> zyga: well, you can do both :)
[10:55] <zyga> ok
[10:59] <zyga> mborzecki: quick question: why didn't you make the changes to apparmor?
[10:59] <zyga> mborzecki: there are some typos in parallel in the PR :)
[11:07] <mborzecki> zyga: default template?
[11:08] <zyga> or instance specific template, either way
[11:08] <zyga> anyway, reading on
[11:17] <mborzecki> pedronis: hi, another one for you https://github.com/snapcore/snapd/pull/5761 :) this is first step to get the stable instance key across refresh requests (cc wgrant)
[11:19] <wgrant> ooh
[11:20] <baimafeima> hello, I'm curious whether it'll be possible to get snaps to run on Haiku OS: https://www.haiku-os.org/
[11:20] <zyga> baimafeima: hey, that's unlikely as snaps rely on a number of linux technologies
[11:21] <zyga> baimafeima: I'm not a haiku expert but I don't suppose haiku can run unmodified linux executables today
[11:21] <baimafeima> Yeah
[11:21] <zyga> baimafeima: so apart from the extra requirements of snapd (related to container technologies and sandboxing) you would have existing problems of just running unmodified apps that people release
[11:21] <baimafeima> I just wonder whether there's any ambition among snap developers to even move beyond the linux ecosystem
[11:22] <baimafeima> to make it more "universal"
[11:22] <zyga> baimafeima: one by one ;)
[11:22] <zyga> baimafeima: I think the answer is that it's unreasonable outside of "let's run it in a VM"
[11:23] <zyga> baimafeima: I doubt the number of users there would justify the engineering work required to attempt that
[11:23] <zyga> baimafeima: allowing snaps on windows would be more interesting for example
[11:24] <baimafeima> zyga, yeah, I just happen to be really fascinated about haiku :D
[11:24] <baimafeima> and well, they really lack software
[11:29] <zyga> baimafeima: I understand that
[11:29] <zyga> baimafeima: good luck with haiku!
[11:30] <pedronis> mborzecki: ack
[11:31] <baimafeima> zyga, thanks for the info though
[11:36] <zyga> mborzecki: wow, https://github.com/snapcore/snapd/pull/5760 is green on first go :)
[11:37] <zyga> no need to re-trigger tests
[11:37] <zyga> that's fun :)
[11:42] <wgrant> mborzecki: RequestSeed will be persisted in state somewhere, I guess?
[11:42] <wgrant> I suppose it needn't be a per-snap value. Machine-global would be fine.
[11:42] <mborzecki> wgrant: i planned to use seed-time which is machine global for that
[11:45] <mborzecki> off to pick up the kids
[11:48]  * zyga preps for lunch
[11:49] <zyga> mborzecki: review of 80% sent, I'll grab some food now
[11:49] <zyga> mborzecki: and there are lots of conflicts in that PR
[11:49] <zyga> anywAY
[12:30] <zyga> re :)
[12:30] <zyga> mborzecki: resuming the review
[12:34] <pstolowski|lunch> a lot of "error: unable to contact snap store" today, still
[12:35] <noise][> pstolowski|lunch: we are still battling some performance issues so having internmittent timeouts
[12:35] <pstolowski|lunch> noise][: ack, thanks
[12:36] <pstolowski> niemeyer: thanks for the yesterday's udev review! the followup https://github.com/snapcore/snapd/pull/5632 is now much smaller (and also finally green again)
[12:39] <mborzecki> re
[12:41] <niemeyer> pstolowski: Thanks!
[12:41] <mborzecki> zyga: yeah, the conflicts are expected, parts of the PR were landing independently
[12:44] <Chipaca> state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
[12:44] <Chipaca> :'(
[12:44] <Chipaca> noise][: ^ is that another form of intermittent timeout?
[12:45] <noise][> yes, we lock you up until the timeout is reached
[12:46] <pedronis> Chipaca: we should move catalog fetching to a task btw
[12:49] <ogra> noise][, given that https://forum.snapcraft.io/t/solved-request-failures-to-the-store/7177/6 claims "solved" perhaps someone from store could answer here https://forum.snapcraft.io/t/snapd-not-connecting-to-the-store-what-to-test-do/7190
[12:49] <ogra> (since the latter one is more specific)
[12:52] <Chipaca> ogra: "solved" y un jamón :-)
[12:52] <jdstrand> I'm here
[12:52] <noise][> yes, we'll get the notices updated, sorry for the delay on those
[12:53] <ogra> jdstrand, do you highlight "jamón" lately ?
[12:53] <jdstrand> no
[12:53] <ogra> :)
[12:53] <jdstrand> I saw the store failures bit
[12:53] <ogra> ah
[12:53] <jdstrand> but seems you are talking about different things
[12:54] <zyga> jdstrand: hello
[12:54] <ogra> yeah ... the review-tools are fine on 16.04 ... 18.04 still fails though
[12:54] <jdstrand> I'll sync with roadmr when he is online. a new revision of the review tools should've hit prod yesterday but it doesn't seem to have
[12:54] <zyga> ogra: jamon? :D
[12:54] <jdstrand> ogra: yeah
[12:54] <ogra> zyga, see Chipaca's last line :)
[12:54] <zyga> jdstrand: I revived the trespassing fix for layouts, some churn still but at some point I'll ask you to sanity check
[12:54] <jdstrand> ogra: so, depending on what he says, I'll do the same for 18.04 that I did for 16.04
[12:54] <jdstrand> zyga: hey, sure
[12:55] <zyga> jdstrand: there's also some related change in mount table sorting we are doing for instances
[12:55] <zyga> jdstrand: I'll go through it now, to poke holes
[12:55] <zyga> jdstrand: but if I fail I'll ask you to double check that aspect
[13:07] <jdstrand> roadmr: good morning! what is the status of getting r1123 of the tools into prod?
[13:07] <roadmr> hi jdstrand ! we've had some issues with breakage in the store since yesterday which have preempted any rollouts :/
[13:08] <roadmr> jdstrand: but once the fire is out, rolling r1123 and a couple of other changes is highest priority for us
[13:09] <jdstrand> roadmr: should I roll a downgraded deb for bionic or does that fire seem to be out?
[13:10] <jdstrand> roadmr: (I can do the same for base: core18 snaps as I did for regular snaps. that would help some, but then there are non-LP/snapcraft.io builds that need r1123)
[13:10] <jdstrand> (I can't do anything about those)
[13:11] <roadmr> jdstrand: it's probably still affecting users building on 18.04
[13:12] <jdstrand> roadmr: which 'it'? I know lack of r1123 is affecting users (that is what I'm wondering about with uploading a downgraded bionic). ie, is the fire almost out and therefore r1123 will make it in the next few hours, or should I prepare that downgraded deb?
[13:17] <roadmr> jdstrand: it == the new snapcraft that emits those new keys :)
[13:17] <roadmr> jdstrand: we might be able to do the rollout this afternoon but no promises - it might be reasonable to downgrade bionic :(
[13:17] <jdstrand> roadmr: right, ok
[13:17]  * jdstrand does that
[13:18] <roadmr> jdstrand: because it'll be a couple of hours before we know more, and what we end up finding out may be "it's all still borked, we can't roll out yet"
[13:18] <roadmr> jdstrand: sorry - this issue we've hit had particularly bad timing :(
[13:18] <jdstrand> no worries
[13:59] <mvo> niemeyer: the snapd snap failover test: https://github.com/snapcore/snapd/blob/master/tests/core18/snapd-failover/task.yaml
[13:59] <mvo> niemeyer: sorry that I did not find it earlier, it is under the core18 subsection, I forgot about this
[14:02] <niemeyer> mvo: Thanks!
[14:02] <niemeyer> mvo: and np at all
[14:10] <ogra> mvo, https://forum.snapcraft.io/t/core18-included-binaries/7191 ( <-- and probably also niemeyer )
[14:12] <sergiusens> kjackal: hey there, can you direct me to where the microk8s project lives?
[14:12] <Chipaca> niemeyer: wrt changing 'okay' to 'ack', was your expectation also that the user-facing command would become 'ack'?
[14:12] <Chipaca> (maybe as an alias for 'acknowledge'?
[14:12] <Chipaca> )
[14:12] <pedronis> Chipaca: snap ack exists already,  for assertions
[14:12] <niemeyer> Right, on both counts
[14:13] <pedronis> that's why we went with okay here originally, I think
[14:13] <niemeyer> Oh, wait.. the command doesn't work.. :(
[14:14] <mvo> ogra: ta
[14:14] <niemeyer> It's a bit awkward to see it as a verb.. it was also unexpected to see it mixed
[14:14] <niemeyer> Hmmmmm
[14:14] <Chipaca> niemeyer: 'snap okay' comes straight from the whiteboard fwiw
[14:14] <niemeyer> Ack
[14:15] <niemeyer> (or okay? :P)
[14:16] <zyga> "snap dismiss"
[14:16] <zyga> snap read NN (like in gentoo)
[14:18] <Chipaca> snap conform
[14:19] <niemeyer> zyga: That's pretty good, but as something we need to type out often "okay" feels practical, and sort of okay
[14:19] <niemeyer> I cannot find any better options right away, unsurprisingly..
[14:19] <roadmr> haha so just like typing any two letters on a unix system does *something*, snap $ANY_VERB is bound to eventually also do something :D
[14:19] <niemeyer> We probably spent a good while finding it in the sprint
[14:20] <pedronis> looking at synomyms of "acknowledge" there is nothing useful that is not many word, or long and uncommon
[14:22] <Son_Goku> does anyone know why the forums are inaccessible?
[14:22] <Son_Goku> hmm
[14:22] <Son_Goku> was a blip
[14:22] <Son_Goku> it works now
[14:26] <niemeyer> Chipaca, pedronis: alright, I we want to go with "okay", indeed it sounds better to go end-to-end with it so we use the same terminology everywhere
[14:26] <niemeyer> Chipaca: sorry for the false lead.. I forgot we had such a strong meaning for ack already
[14:32] <roadmr> jdstrand: hey! the script that sends USN notifications for snaps, that lives in the reviewer-tools repo, right?
[14:38] <zyga> niemeyer: yeah, I think okay is okay :)
[14:39] <niemeyer> Okay then!
[14:42] <Chipaca> zyga: I think ack is ack
[14:48] <zyga> ack, okay
[14:48] <zyga> meh
[14:48] <zyga> can we have "snap meh"
[14:48] <zyga> doing something useful? :)
[14:49] <pedronis> snap blink and snap nod
[14:49] <zyga> snap wink wink wink
[14:52]  * mvo likes snap nod
[14:55] <mborzecki> snap aye, snap nay?
[15:09] <zyga> snap popey the sailor
[15:19] <diddledan> https://www.youtube.com/watch?v=grtchH6SfGE
[15:21] <jdstrand> Saviq: hey, can you trigger a new build for subsurface? LP/snapcraft.io should now have a downgraded snapcraft to work around the review issue
[15:22] <jdstrand> roadmr: the meat of the script is there, yes. there is a small cron script that drives it that is not
[15:23] <roadmr> jdstrand: ok... but the cron script mostly calls the usn script itself, right? does it by chance do a snap search to the /api/v1/snaps/search endpoint? (I think not, but checking something)
[15:25] <sergiusens> jdstrand, roadmr: I am about to dput a new snapcraft, is the review thing resolved? If not I will git revert the version thing and leave it to you guys to add back when ready
[15:25] <roadmr> sergiusens, jdstrand : I'm about to request the rollout with tools r1123, very likely that'll be out today
[15:26] <sergiusens> roadmr: ok, sounds good
[15:27] <Saviq> jdstrand: ack
[15:43] <jdstrand> roadmr: thanks! that'll help people directly uploading with 'snapcraft push'
[15:44] <roadmr> yep, sorry it took so long :/
[15:44] <roadmr> but... fire :)
[15:44] <jdstrand> roadmr: sorry, let me check
[15:44] <roadmr> jdstrand: (it's not there yet :)
[15:44] <roadmr> rollout has been requested, but takes a while to process/run/etc
[15:44] <jdstrand> I understand
[15:44]  * jdstrand is getting you the answer to your question
[15:47] <roadmr> thanks :)
[16:21] <ogra> mvo, did you see my last comment on the core18 binaries thread ? where are netplan and console-conf in core18 ? are they not supposed to be included anymore
[17:13]  * Chipaca wanders off
[17:14]  * anarcat waves
[17:15] <anarcat> so what should i do with this bug report? https://forum.snapcraft.io/t/apparmor-error-after-debian-buster-upgrade/7026
[17:15] <anarcat> it still, as far as i know, affects debian
[17:34] <cyphermox> ogra: could you please clarify? netplan and console-conf not supposed to be included? I expect that's a mistake
[17:36] <jdstrand> sergiusens: I see you closed https://github.com/snapcore/snapcraft/pull/2234. I commented there since I was reading backscrolled and asked to do so
[17:37] <sergiusens> jdstrand: yeah, I reopened another one
[17:37] <sergiusens> jdstrand: https://github.com/snapcore/snapcraft/pull/2235
[17:37] <sergiusens> but I will look into your comments
[17:37] <jdstrand> anarcat: I think zyga is looking at that
[17:39] <sergiusens> jdstrand: good comments, these are the smallest snaps we can come up with to trigger each scenario as we do like our speed
[17:40] <sergiusens> jdstrand: this will not however give us a 100% coverage on all the possible scenarios for keys to be generated. But we should strive to keep the ones you care about compatible, we do not plan on making backwards incompatible changes, but you never know when taking on new dependencies :-)
[17:42] <jdstrand> sergiusens: are you planning on adding new keys? maybe I should adjust the tools to not care about unknown ones
[17:43] <jdstrand> it isn't as interesting to report unknown manifest.yaml keys
[17:43] <sergiusens> jdstrand: no, no plans; I just worry that someone will create a snap that triggers things you have not seen yet (like source-commit or those keys that only show up on very special occasions)
[17:44] <jdstrand> possibly
[17:44] <sergiusens> jdstrand: that said, maybe you cover everything already and I just need to check
[17:45] <sergiusens> jdstrand: but, the case can be made that the snap directory of a snap is not part of the snap format
[17:45] <jdstrand> sergiusens: https://git.launchpad.net/review-tools/tree/clickreviews/sr_common.py#n67
[17:45] <sergiusens> it is just an artifact that snapcraft creates
[17:45] <jdstrand> right
[17:45] <jdstrand> I mean, snapd doesn't look at it
[17:45] <jdstrand> looks like I do not have source-commit
[17:46] <sergiusens> right, anything part of the snap format is in meta
[17:46] <jdstrand> sergiusens: how about I add all the missing keys, but then I make it non-fatal if something is added?
[17:46] <sergiusens> jdstrand: source-commit is part of snapcraft.yaml inside snap (alongside manifest.yaml)
[17:47] <sergiusens> you may not be checking it at all from a quick search
[17:47] <jdstrand> sergiusens: we don't look at snapcraft.yaml at all
[17:47] <jdstrand> sergiusens: only manifest.yaml and only because our tool looks at it
[17:48] <sergiusens> jdstrand: that's perfect, I would still treat it as json API, ignoring what you do not know about to be able to add new keys we agree upon
[17:48] <jdstrand> sergiusens: ok, am I missing anything from manifest.yaml? is there somewhere I should look?
[17:48] <sergiusens> well, your choice, we will most likely only add keys there that make sense to you and maybe when we decide to tackle reproduceable builds for real
[17:49] <anarcat> jdstrand: cool
[17:50] <sergiusens> jdstrand: it is pretty much hand crafted to not sneak in things https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta/_manifest.py#L28
[17:53] <jdstrand> ok, thanks
[17:54] <sergiusens> jdstrand: I will let you know if anything changes
[17:55] <jdstrand> sergiusens: thanks. the added tests will be very worthwhile in that regard. I'm also removing the unknown check
[17:58] <mvo> ogra: are you looking at stable? that is very small right now, beta/edge should be more current
[18:00] <pedronis> mvo: is version really intended to be just "18"  in edge?
[18:03] <ogra> mvo, aha, i'll make the same list fro edge then, thanks
[18:03] <ogra> *for
[18:13] <mvo> pedronis: there is an open pr to make it date based we could make it month based
[18:13] <mvo> ogra: yw, sorry that its a bit confusing currently
[18:46] <kyrofa> Hey mvo, although the yaml spec doesn't guarantee it, will the `environment` dict be evaluated in order?
[18:52] <kyrofa> I assume so, just want to double check
[18:59]  * cachio afk
[19:36] <ogra> jdstrand, i see very curious things in my log from the hexchat snap ...
[19:36] <ogra> kernel: audit: type=1400 audit(1536089686.295:34656): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name=2F686F6D652F6F6772612F736E61702F686578636861742F33392F2E636F6E6669672F686578636861742F7363726F6C6C6261636B2F7562756E747520736572766572732F23626561676C652E747874 pid=4797 comm="hexchat" requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
[19:37] <ogra> (hexchat obvously works just fine ... as i'm just typing in it ... but this line repeats every 10 sec or so, growing my logs)
[19:39] <ijohnson> ogra: you can decode the name there using aa-decode from the apparmor-utils package
[19:41] <ogra> ijohnson, !
[19:43] <ogra> ijohnson, thanks a lot, that helps
[20:12] <mvo> kyrofa: hey, sorry for the slow reply. iirc the goyaml we use gives us a stable ordering, I can double check tomorrow
[20:30] <niemeyer> It does..


[11:59] <alish_> hi. I tried installing lubuntu 18.04 last night but it freezed at initializing install.
[11:59] <alish_> anyone had this issue?
[12:00] <alish_> i can't get log
[12:00] <diogenes_> alish_, try with nomodset
[12:00] <alish_> the page going black after some splash.
[12:00] <alish_> diogenes_: ok
[14:46] <krabador> beware of cristian_c
[19:50] <lars_> !suspend
[19:50] <lars_> !sleep
[20:05] <krabador> lars_ ulrich ?
[20:07] <lars_> I`m a fiddle player player, so I play some music, but apart from that I don`t think I resemble Lars Ulrich very much krabador :)
[20:08] <krabador> :D
[22:07] <lars_> I have this ancient macbook from 2007 and after hibernation the screen is black, so I`ve had to turn that off.  Anyone familiar with this?