[08:49] <ffledgling> Hello, I was wondering if someone would happen to know how to delay installing packages until the last step/stage when cloud init runs?
[11:39] <Raboo> larsks if i use the NoCloud provisioner does it need the <url>/meta-data or is it sufficient with the <url>/user-data? So if i reply with an empty meta-data..
[14:04] <larsks> Raboo: the nocloud data source doesn't require any url; it gets metadata and userdata from files on disk.  See http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[14:32] <Raboo> larsks you can use SeedFrom clause
[14:32] <Raboo> larsks seedfrom: http://my.example.com/i-abcde
[14:35] <larsks> Sure, but you didn't say you were using that, and I am not a mind reader.  Looking through the code it *looks* as if you should be able to get away with only providing the user-data. Are you seeing different behavior?
[14:39] <Raboo> larsks did a fast try on a machine, it failed, but i don't know where since I couldn't login, so im going to add a static user to that image so I can login and debug
[14:39] <Raboo> larsks but first i wanted to know if the meta-data was a requirement, since i don't have that implemented I thought I would start there if it was.
[14:40] <larsks> Have you also tried providing some minimal meta-data just to see what happens?  That should be an easy test.
[14:40] <Raboo> haven't yet.
[14:40] <larsks> Just serve out the metadata from the nocloud examples as a static file or something.
[14:41] <Raboo> ok
[14:41] <Raboo> but it's a bit more than 'just' since it's a plugin for another tool


[10:54] <qwebirc10981> is anyone finding that since the update today mythtv-backend constantly crashes until it gets shut down?
[10:54] <qwebirc10981> mythbackend version: fixes/0.27 [v0.27-29-ge59e5f6] www.mythtv.org


[00:20] <umbSublime> Budgie^Smore, magicaltrout I'm not even sure Canonical still uses those (pretty awesome) orange boxes for OS training anymore, IIRC they now use remote servers from different providers
[00:22] <Budgie^Smore> umbSublime pretty sure you are right there, those were still cool though
[00:22] <umbSublime> heck yah
[00:23] <umbSublime> they had me drooling when they first came out :p
[06:47] <stub> The orange boxes tend to get used where network connectivity is limited, cause they can be flown in with archive mirrors and whatnot prepopulated
[07:25] <kjackal> Good monrning Juju world!
[11:16] <BlackDex> Hello, can i run juju within a lxd when using MAAS as its cloud-provider?
[11:16] <BlackDex> i mean the juju bootstrap
[11:16] <BlackDex> so, i want to bootstrap juju within a lxd container and use maas for the rest
[11:16] <BlackDex> currently i'm creating a kvm instance and run the bootstrap on that
[11:29] <rick_h> BlackDex: not at this time. One "provider" per controller.
[11:34] <BlackDex> and if i create a lxd and let it detect by maas? Or that isn't an option?
[12:23] <rick_h> BlackDex: yes, if you load a vm of any sort into maas so that it's the maas api/provider that's in use you're ok
[12:30] <BlackDex> oke rick_h Thx, i will try that :)
[13:10] <kim0> Howdy folks .. I just tried to deploy kubernetes to Azure cloud .. And it is stuck .. I see 4 deployments have failed in Azure portal :/
[13:11] <kim0> Can anyone help me debug this or get it working
[13:18] <lazyPower> kim0: i can certainly try to lend a hand here. What units are failed and how did they fail?
[13:32] <kim0> lazyPower: actually not units .. I think it's machines that failed
[13:32] <lazyPower> kim0 ah, so azure failed to give you the machines?
[13:32] <kim0> https://www.irccloud.com/pastebin/r7A8WpgV/
[13:32] <kim0> yes .. the deployment to Azure failed
[13:32] <lazyPower> that certainly looks indicative that azure didn't give you the vms.
[13:32] <kim0> is there a way to delete those VMs and re-deploy them
[13:33] <lazyPower> you can try juju retry-provisioning 0
[13:33] <lazyPower> same with 1
[13:33] <kim0> interesting Ok
[13:33] <lazyPower> and it should re-request the machines from azure
[13:33] <kim0> I had done juju add-machine
[13:33] <lazyPower> but you may have to wait for them to enter a failed state
[13:33] <kim0> but it's not appearing into juju status for some reason
[13:33] <lazyPower> i dont think it will retry if they are marked as down
[13:34] <kim0> $ juju show-machine 0
[13:34] <kim0> model: gulfk8s
[13:34] <kim0> machines:
[13:34] <kim0>   "0":
[13:34] <kim0>     juju-status:
[13:34] <kim0>       current: down
[13:34] <kim0>       message: agent is not communicating with the server
[13:34] <kim0>       since: 04 May 2017 14:05:27+02:00
[13:34] <kim0>     instance-id: machine-0
[13:34] <kim0>     machine-status:
[13:34] <kim0>       current: provisioning error
[13:34] <kim0>       message: Failed
[13:34] <kim0> It says .. "Provisioning error" I guess juju should know it has failed :)
[13:36] <kim0> I tried juju "retry-provisioning 0" .. but as you expected, it's not retrying
[13:36] <kim0> any way to force-fail the old machines or something
[13:36] <kim0> it's been an hour really .. so I guess it might never fail them
[13:39] <kim0> lazyPower: Any ideas ^ .. Thanks!
[13:40] <lazyPower> kim0 I dont, the best i could offer woudl be to remove the model and try again.
[13:41] <kim0> yeah .. I tried deploying this a couple of months back, and got the same VM provisioning failure .. so a little :/
[13:41] <kim0> I can try one more time
[13:44] <lazyPower> kim0 : do you have any restrictions on your account or anything similar?
[13:45] <lazyPower> kwmonroe i know you have the broadest welath of knowledgea bout our azure provider
[13:45] <lazyPower> kwmonroe do you see failed provisioning often?
[13:47] <kim0> kwmonroe .. The error Azure portal gives me is like "PutVirtualNetworkOperation xxxx was cancelled and supersceeded by PutVirtualNetworkOperation yyy. Code: CancelledAndSuperseededDueToAnotherOperation)
[13:47] <kim0> To me .. this looks more like juju's fault than Azure's
[13:52] <kwmonroe> yup lazyPower.. bug 1673847 is the reference bug (kim0 has already commented).
[13:52] <mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
[13:52] <lazyPower> kwmonroe fantastic. Thanks for confirming
[13:52] <lazyPower> :(
[13:53] <lazyPower> well poo, wont fix on 2.1 which means you wont see it in this series, but 2.2 is right around the corner
[13:53] <kim0> Is it already fixed in 2.2 devel ? can I try that ?
[13:54] <lazyPower> I don't see anything related to "fix committed" which tells me its still present in 2.2 devel
[13:54] <kim0> kwmonroe: Thanks for confirming! Any advice to manually workaround this issue ?
[13:55] <kim0> The bug OP says he hits this .. 1 out of 10 times .. to me, I hit it the 2 times I tried juju :)
[13:55] <kim0> If I should just destroy the model & retry, I can do that too
[13:58] <kim0> I tried "juju add-machine" which seems to work .. The machine is started in azure portal .. put it is not listed under my k8s model .. not sure why
[13:58] <kim0> I was hoping to replace the ill machines with healthy ones
[14:02] <kwmonroe> kim0: my workaround (i'm the bug OP btw) is to "juju add-unit <application>" on anything that juju status reports as "provisioning error".
[14:02] <kwmonroe> kim0: it's not pretty, but it keeps any relations in tact and is a bit faster than totally removing the application and re-adding it with new relations later.
[14:03] <kim0> aha .. so that will allocate a new VM and
[14:03] <kim0> deploy on it
[14:03] <kwmonroe> correct kim0
[14:03] <kim0> my only worry, if unit/0 is "special"
[14:03] <kim0> Ok .. easyrsa/0 was down .. trying to add a unit on that
[14:04] <kwmonroe> kim0: it really shouldn't be.. there's no guarantee that /0 was the first unit to become ready (ie, you may have deployed 2 units at the same time and unit/1 just happened to beat /0 to ready state)
[14:04] <kwmonroe> kim0: so things like charm leadership and even tests should not be relying on /0 as any indication of "first" or "leader" or whatever.
[14:04] <kim0> For example .. etcd/0 is on a broken machine .. while etcd/1 & /2 are on working machines .. However it seems they are blocked waiting for etcd/0 !
[14:05] <kim0> Nice .. easyrsa/1 is now healthy!
[14:05] <kim0> kwmonroe: should I somehow remove the old easyrsa/0 ?
[14:05] <kwmonroe> kim0: i'm not too familiar with etcd -- lazyPower, is there something special about etcd/0?
[14:05]  * lazyPower reads backscroll
[14:06] <lazyPower> kim0 kwmonroe - shouldn't be blocked waiting on etcd/0. Which unit has the asterisk next to its name?
[14:07] <kwmonroe> kim0: i do remove the failed units because i can't stand being reminded of them every time i type juju status ;)  i think the syntax is "juju remove-unit easyrsa/0", but if that doesn't work, "juju remove-machine <machine-number-for-easyrsa/0>" should do it.
[14:07] <lazyPower> i would presume etcd/1* if it was the first to come active which would earmark it as the leader for the rest of the units coming online.
[14:07] <kim0> lazyPower: etcd/2 has the *
[14:07] <kim0> is the "every unit on a separate VM" the norm in juju world ?
[14:08] <lazyPower> kim0 - can you provide more detail as to where it appears they are waiting on etcd/0?
[14:09] <kim0> mm it was just saying "blocked" .. since then I add-unit one etcd .. and now it says ready!
[14:09] <lazyPower> Ok, it should only be blocked if its missing the easyrsa details
[14:10] <kim0> that was indeed the case .. I had also added unit on easyrsa
[14:10] <lazyPower> it requires TLS certs to operate as of about a year ago. I flipped the switch to disallow insecure connections
[14:10] <kim0> sorry I don't know the order of events :)
[14:10] <lazyPower> All good kim0 - its a learning experience :)
[14:10] <kim0> exactly
[14:10] <kim0> I'm trying to post the full juju status
[14:11] <kim0> http://paste.ubuntu.com/24511284/
[14:12] <lazyPower> ok that status message for etcd/2 should update within 5 minutes when it runs update-status again and it'll report 2 peers
[14:12] <kim0> What does the * besides etcd/2 mean
[14:12] <lazyPower> that denotes the current juju leader
[14:12] <lazyPower> in some instances like the etcd charm, we use the juju leader to coordinate cluster events
[14:12] <kwmonroe> kim0: ideally, each unit would be isolated (either on a totally separate machine or in a separate container).  the exception is for "subordinate charms".  these are things like nagios or ganglia monitors, rsyslog, etc that make no sense to stand alone in a VM.  in that case, both a principal charm (like etc) and a subordinate (like ganglia-node) would live side-by-side on the same unit.
[14:13] <kwmonroe> kim0: this ideal isolation is not enforced, so you *can* jam a whole bunch of charms onto the same unit, but that usually leads to package conflicts or other headache..
[14:13] <kim0> aha .. Ok! I was really thinking about container isolation (k8s style)
[14:14] <lazyPower> you can also colocate using lxd which doesn't suffer from that, however it comes with other nuances you have to be aware of. Cross host container networking is only supported in MAAS at this time.
[14:14] <kim0> nvm .. I'll keep separate VMs for now
[14:15] <lazyPower> kim0 as this is your first dpeloyment, next go-around you can start with a much smaller bundle - kubernetes-core, which only requires 3 units.
[14:15] <lazyPower> colocated 1 etcd/easyrsa, 1 master, 1 worker.
[14:15] <lazyPower> same kubernetes experience, smaller requirements. CDK is more of a production-facing minimal deployment, where you wish to have HA control plane, and resilient etcd
[14:17] <kim0> I actually care about a production ready deployment
[14:17] <kim0> it seems remove-unit  does not remove the underlying machine
[14:18] <kim0> I tried to remove the machine by hand .. but it either needs time, or is not working
[14:18] <kwmonroe> kim0: use a bigger hammer:  juju remove-machine --force <number>
[14:19] <kim0> Ok .. just did :)
[14:19] <kim0> removed
[14:19] <kim0> cool
[14:19] <kim0> seems to be converging to a working setup :)
[14:19] <kim0> is there a possibility to power-off all machines (to save money) .. yet start them tomorrow ?
[14:21] <kwmonroe> kim0: even powered off, i think clouds will still charge you (not for IOPS or cpu time, but for holding the underlying resources for you)
[14:21] <kim0> yeah I understand that .. but that cost is like 5% of the running cost
[14:21] <kwmonroe> kim0: so if you really don't need the cluster overnight, just destroy the model and re-deploy it when you need it again
[14:21] <kim0> well .. I've spent 2 hours on a bunch of add-unit / remove-unit / remove-machine --force
[14:22] <kim0> so if possible .. I want to keep it
[14:22] <lazyPower> kim0 it shouldn't have any issues coming back up from a stopped state
[14:22] <lazyPower> kim0 if you find issues there, i want bugs please <3
[14:22] <kim0> do I stop from azure or juju
[14:22] <lazyPower> the azure cp
[14:22] <lazyPower> you should be able to halt the vms or suspend them without any penalty to functionality
[14:23] <kim0> cool!
[14:23] <admcleod> or you could juju run shutdown
[14:23] <kim0> I am approaching an "all-green" state .. exciting :D
[14:23] <kim0> oh checking that out
[14:23] <lazyPower> yeah
[14:23] <lazyPower> juju run --all "shutdown -h now"
[14:23] <lazyPower> admcleod i'm not sure if that marks the vm as halted in azure cp tho
[14:23] <kim0> oh that's like a parallel ssh .. I see
[14:23] <admcleod> lazyPower: neither!
[14:23] <kim0> yeah .. it doesn't
[14:24] <lazyPower> i know some providers decouple the power state in th hypervisor from the state of the unit...
[14:24] <admcleod> *adds to notes*
[14:24] <kim0> I have to "deallocate" the VM .. so I'll use the azure tools
[14:24] <lazyPower> yeah
[14:24] <lazyPower> ^
[14:24] <lazyPower> do that
[14:24] <kim0> Awesome!
[14:24] <lazyPower> kim0 now, you're basically testing our failure recovery model :)
[14:24] <lazyPower> fyi
[14:24] <kim0> hhhh
[14:24] <kim0> hope it works :)
[14:24] <lazyPower> so if you do find bugs, i want them, plz plz plz dont let that go unnoticed
[14:24] <kim0> Sure thing
[14:24] <lazyPower> <3 appreciated
[14:25] <kim0> one last thing
[14:25] <kim0> Should I expect to be able to scale kubernetes worker nodes up/down & upgrade kubernetes versions from now on ?
[14:25] <lazyPower> yes
[14:25] <kim0> ie should the above work without a party ?
[14:25] <lazyPower> we're cutting a 1.6.2 release soon (probably today)
[14:25] <kim0> Awesome!!!
[14:25] <lazyPower> so you can test that function relatively soon
[14:25] <kim0> I will love to upgrade from 1.6.1 to that
[14:25] <lazyPower> :)
[14:25] <lazyPower> wish granted
[14:25] <kim0> Great .. I appreciate a ping after it's push
[14:26] <kim0> pushed*
[14:26] <lazyPower> sure
[14:26] <lazyPower> on here?
[14:26] <kim0> Yep
[14:26] <lazyPower> k
[14:26] <kim0> lazyPower: how many hours roughly to go
[14:26] <lazyPower> if you subscribe to the juju mailing list we also hit that, kubernetes users
[14:26] <admcleod> lazyPower: the release notification also goes to a list too doenst it?
[14:26] <admcleod> right
[14:26] <lazyPower> reddit
[14:27] <kim0> All VMs get public IPs right
[14:27] <kim0> do those VMs get security updates too ? :D
[14:27] <lazyPower> kim0 not without something like landscape client attached or installing unattended-upgrades
[14:28] <lazyPower> kim0 and ot respond to your question: SUCCESS! -- 146 Passed | 0 Failed | 0 Pending | 442 Skipped
[14:28] <kim0> :D
[14:28] <lazyPower> we're close, getting clean test results from e2e on our 1.6.1 => 1.6.2 on 2 clouds now
[14:29] <kim0> any way for juju to install unattended-upgrades on the nodes it's managing ?
[14:29] <kim0> or should I do ansible for that :)
[14:29] <rick_h> kim0: yea, sec. I highlighted that charm in the juju show last week
[14:30] <rick_h> kim0: https://lists.ubuntu.com/archives/juju/2017-April/008838.html
[14:30] <kim0> 👍
[14:33] <kim0> juju deploy unattended
[14:33] <kim0> ERROR cannot resolve URL "cs:unattended": charm or bundle not found
[14:35] <rick_h> kim0: sorry, it's just a user charm atm: https://jujucharms.com/u/paulgear/unattended/
[14:35] <rick_h> kim0: try the copy/paste command there.
[14:36] <kim0> it seems to use a local file ./unattended .. should I git clone it first
[14:36] <kim0> I expected "juju deploy paulgear/unattended" to work but it didnt
[14:37] <tychicus> rick_h: is the juju show something that is recorded?
[14:38] <rick_h> tychicus: it sure is, check out https://www.youtube.com/jujucharms and there's a playlist for just the juju show episodes
[14:38] <rick_h> kim0: the copy and paste should have gotten you juju deploy cs:~paulgear/unattended-2
[14:38] <tychicus> fantastic, thanks!
[14:39] <kim0> rick_h: sorry .. my eye totally missed that little box up there :)
[14:40] <rick_h> kim0: all good, helpful for making it dirt simple to get the right username/etc.
[14:44] <kim0> @channel .. Thanks for all the awesome help .. I have an all-green deployment now ;)
[14:44] <rick_h> kim0: <3 awesome
[14:59] <lazyPower> kim0 \o/ partyyyy
[15:00] <kim0> :+1
[15:00] <kwmonroe> kim0: head's up -- i just use the azure tools to put a machine in "Stopped (deallocated)", and when i restarted it, it got a new public ip.  this seems to cause juju to switch over to the 192.x private address, which is no longer addressable.
[15:01] <lazyPower> kwmonroe good catch. we're not going to recover from that
[15:01] <kim0> hmm
[15:02] <kim0> At least you guys should allocate static IPs I guess
[15:02] <kwmonroe> rick_h: is there a way for juju to "refresh" the public-ip from the provider?  or does it perhaps poll periodically to see if a public ip has changed?
[15:03] <rick_h> kwmonroe: so...I know there's open bugs about machines rebooting to different IPs. I'm not sure what the resolution of those bugs has turned to off the top of my head
[15:03] <marcoceppi> kwmonroe: from my experience the agent will recover, eventually
[15:03] <kwmonroe> ok - i'll at least give it the update-status window and see.  meanwhile i'll checkout some lp bugs
[15:03] <kwmonroe> thx rick_h marcoceppi
[15:04] <kim0> how much is that window
[15:04] <kwmonroe> 5 minutes
[15:04] <kim0> cool :)
[15:06] <kim0> Are charms written in a way such that any app is scalable .. For example, I see kubeapi-load-balancer and kubernetes-master and I jus don't know whether or not it's wise to try scaling those up
[15:06] <lazyPower> kim0 - each of those components are written in such a way that you can scale them
[15:06] <magicaltrout> you can scale charms, whether they expect to be scaled is up to the developer
[15:06] <kim0> do I get some error if something should not be scaled
[15:06] <lazyPower> an they will reconfigure when a scale event (up or down) happens.
[15:07] <lazyPower> kim0 the only charm in that bundle that doesn't expect to be scaled at this point is easyrsa
[15:07] <kim0> so what happens when I scaled that up
[15:07] <lazyPower> we have an open item of medium priority on that functionality. it involves cloning the CA, doing intermediate signing certificates, and a dance that i haven't fully wrapped my head around.
[15:08] <lazyPower> you'll get 2 separate Certificate Authorities, adding new units may be problematic at that point.
[15:08] <lazyPower> however existing units will be uneffected.
[15:08] <kim0> Ok thanks
[15:09] <kim0> I guess it should at least error out, that scaling easyrsa is not a recommended action or something
[15:10] <kwmonroe> kim0: the juju agent on my re-started unit does eventually sync / display the new public address, which means addressability is good again.  it took 15 minutes for me -- not sure why that amount of time, but i'll deallocate again and see if it's consistent.
[15:10] <kim0> Awesome, thanks
[15:11] <magicaltrout> marcoceppi: duno who monitors the form submission at developer.juju.solutions but if you find one from my new guy and a quality message that i didn't write at all
[15:11] <magicaltrout> can you send him some tokens?
[15:13] <kim0> Docs say "By default, the channel will be set to stable, which means your cluster will always be upgraded to the latest stable version of Kubernetes available." .. Does that auto-reboot nodes by default ?
[15:14] <marcoceppi> kim0: it won't reboot your machines at all, just updates the software running on them
[15:17] <kim0> marcoceppi: so a reboot is not even needed ?
[15:18] <marcoceppi> correct
[15:18] <marcoceppi> and if you combine that with things like live patching, you won't have to reboot for kernel updates either
[15:18] <magicaltrout> winning
[15:19] <kim0> cool stuff
[15:20] <kim0> you still have to reboot for glibc updates though :P hhh
[15:23] <kwmonroe> kim0: second deallocate/restart went faster.  the unit refreshed it's public ip 5 minutes after coming back up.
[15:24] <kim0> Very good!
[15:24] <lazyPower> that may cause an issue with the certs
[15:24] <kwmonroe> kim0: so that's all well and good, but if things expect a static ip, you still might be in trouble.
[15:25] <kwmonroe> right lazyPower
[15:25] <lazyPower> certs add the public IP as a SAN
[15:25] <lazyPower> at time of request
[15:25] <lazyPower> which we have an open bug to re-key infra, but that hasn't been started yet
[15:25] <kim0> afaik, the public IP isn't even "on" the VM ?
[15:25] <kim0> does it go through the trouble of finding it out to add it to the cert
[15:25] <lazyPower> sure does
[15:26] <lazyPower> unit-get public-address is passed in as a subject-alt-name on the CSR
[15:27] <kim0> is there a mode, where almost all VMs do not get public IPs to begin with
[15:28] <lazyPower> kwmonroe https://github.com/juju-solutions/layer-tls-client/issues/8
[15:28] <lazyPower> i filed a bug about this so we can track it and get layer-tls-client updated with some logic to re-key during normal operating events
[15:28] <kwmonroe> kim0: ^^ :)
[15:29] <kim0> 👍
[15:30] <kim0> so basically today, upon nodes reboot .. I should expect the cluster to break, right
[15:30] <magicaltrout> reboots are for wimps
[15:30] <kim0> hhhh
[15:31] <magicaltrout> real men redeploy from scratch
[15:32] <kwmonroe> kim0: no, you should not expect any OS-level reboot to change the IP.  it's only when you suspend/deallocate from the cloud control panel.
[15:32] <kim0> Aha got it
[15:33] <kim0> juju set-constraints kubernetes-worker mem=8G
[15:33] <kim0> mm that ^ is still not too helpful to help me get the SSD variant of Azure VMs :/
[15:40] <kwmonroe> kim0: docs will typically use the least-common-denom for application constraints.. in your case mem=8G is a common constraint that will work across aws/gce/azure/etc.  juju also supports cloud-specific constraints.  so in your case, if you're really sure you want azure, you could run "juju set-constraints <app> instance-type=Standard_D1_v2"
[15:41] <kim0> Thanks!!
[15:42] <kwmonroe> kim0: the list of instance types for azure (in order of cost) are here:  https://github.com/juju/juju/blob/2.1/provider/azure/instancetype.go#L29, and pricing here: https://azure.microsoft.com/en-us/pricing/details/cloud-services/
[15:42] <kim0> kwmonroe: Thanks for all the help!
[15:42] <kwmonroe> np!
[15:43]  * magicaltrout gives kwmonroe a supportive pat on the back
[15:43] <magicaltrout> well done kevin \o/
[15:43] <kwmonroe> heh
[15:47] <kim0> kwmonroe: fyi, it seems the instancetype.go is missing some newer VM types like Standard_DS1_v2 (actually all DSv2-series series) and Av2-series ..etc
[15:55] <kwmonroe> yeah kim0 - looks like instancetype.go is not the definitive list (sorry 'bout that).  juju does support DSX_v2, and you can see the full instance-type constraint list here:  http://paste.ubuntu.com/24511657/
[15:56] <kim0> cool np
[16:04] <kim0> When I try to deploy a VM with constraint "instance-type=Standard_DS1" .. I only get "current: provisioning error"
[16:04] <kim0> Any way to get more meaningful errors ?
[16:22] <kwmonroe> kim0: what region are you deploying to?
[16:22] <kim0> westeurope
[16:25] <kwmonroe> kim0: i was gonna say your region might not have DS machines available, but https://azure.microsoft.com/en-us/regions/services/ shows westeurope is supported
[16:25] <kim0> Can I see the error coming back from azure somewhere
[16:25] <kwmonroe> kim0: you can go through the azure portal, select your resource group, and then "Deployments"
[16:26] <kim0> kwmonroe: Got it .. I see the error
[16:26] <kwmonroe> kim0: is it the PutVirtualNetworkOperation from bug 1673847?
[16:26] <mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
[16:26] <kim0> Unable to create the VM bec this size is not available in the cluster where the availability set is created
[16:27] <kim0> Strange error .. first time to get this from Azure!!
[16:28] <kwmonroe> kim0: let's see if juju is exposing that with a different status format.. try "juju status <unit> --format=yaml"
[16:29] <kim0> not really the machine part is only saying "provisioning error"
[16:30] <kim0> http://paste.ubuntu.com/24511934/plain/
[16:31] <kim0> I guess this *might* be bec I'm using a test account
[16:34] <kwmonroe> ok kim0 - would you mind adding another comment to bug 1673847, listing this new error message?  i think minimally it would be nice if juju would expose these provisioning error messages rather than having to dig through the azure portal.
[16:34] <mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
[16:37] <kim0> kwmonroe: Done
[16:37] <kim0> kwmonroe: Are we nearing the 1.6.2 push :)
[16:38] <kwmonroe> kim0: that's a question for lazyPower / kjackal / ryebot.  they're mashing lots of buttons atm.
[16:38] <lazyPower> kim0 once my co-worker gets back from lunch we were planning on a release
[16:38] <kim0> Sorry confused
[16:38] <kim0> Awesome keep rocking :)
[17:29] <Budgie^Smore>  o/ juju world
[17:39] <lazyPower> \o Budgie^Smore
[17:39] <lazyPower> got a 1.6.2 release coming your way shortly
[17:44] <Budgie^Smore> lazyPower coolio, would need to find an environment to deploy it since I no longer have the setups I had :-/
[17:45] <lazyPower> Budgie^Smore apply for cloud developer credentials
[17:45] <lazyPower> help us find bugs
[17:45] <lazyPower> http://developer.juju.solutions
[17:46] <Budgie^Smore> lazyPower you know me, always happy to go bug hunting ;-)
[17:59] <Budgie^Smore> OK I have filled in the form, soooooo now we wait ;-)
[18:02] <lazyPower> awesome :) when marco isn't out doing sprint type stuff you should get an email with some creds
[18:02] <lazyPower> or a request for more info
[18:02] <lazyPower> either way, you'll hear back from us shortly
[18:06] <Budgie^Smore> well even if it a day or 2 it is still faster than HR ;-)
[18:07] <lazyPower> allright 1.6.2 has hit stable channels
[18:07]  * lazyPower raises a cuppa coffee to the sky
[18:07] <lazyPower> kim0 1.6.2 release ping
[18:07] <kim0> \o/
[18:08] <kim0> how do I upgrade to that
[18:08] <lazyPower> https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/
[18:54] <kim0> mm `juju status` does not show an upgrade is available .. just saying :)
[18:59] <Budgie^Smore> mmm is juju status suppose to show upgrade availbility or just the current status of the model?
[19:00] <kim0> Docs say: You can use juju status to see if an upgrade is available. There will either be an upgrade to kubernetes or etcd, or both.
[19:00] <kim0> kubernetes-master seems to have upgraded itself to 1.6.2!
[19:00] <lazyPower> juju status --format=yaml
[19:00] <lazyPower> smart output i think hides that notation
[19:01] <lazyPower> which is a good call, i had not thought about that.. one of those things i've just become accustomed to. inversely, if you're using the GUI, the GUI shows it under the charm detail
[19:01] <lazyPower> kim0 thats snaps in action ;)
[19:02] <kim0> even in the yaml format .. I cannot easily spot what should tell me there's an upgrade
[19:02] <kim0> @lazyPower .. so it's normal that master auto-upgrades right
[19:03] <lazyPower> kim0 only when there is an upgrade in its subscribed chanel.
[19:03] <lazyPower> it wont auto-uprade between minor releases, eg: when we cut and push 1.7 to stable
[19:04] <lazyPower> yo wont auto upgrade to 1.7, you will need to configure teh charms to look at that channel in order to receive the upgrade
[19:04] <lazyPower> but for minor patch releases, you get those automatically
[19:04] <marcoceppi> kim0: lazyPower juju searches for upgrades like daily
[19:04] <kim0> yeah .. so for -worker .. there is an upgrade (it's now on 1.6.1) .. but my eyes can't see where the upgrade is
[19:04] <marcoceppi> so you won't see an upgraded charm available for quite a while
[19:04] <marcoceppi> well, maybe 6 hours
[19:04] <kim0> master upgraded like 10 mins after you guys announced it :)
[19:04] <kim0> lucky me I guess
[19:04] <kim0> but -worker still waiting
[19:05] <marcoceppi> lazyPower: we should add a "refresh" action to master and worker, so people like kim0 can just get the latest "now"
[19:05] <lazyPower> kim0 juju upgrade-charm kubernetes-worker should get it prompting you to run the upgrade action.
[19:05] <lazyPower> @marcoceppi juju run-action kubernetes-worker/0 upgrade already does that ;)
[19:05] <marcoceppi> oh, udhhh
[19:05] <lazyPower> <3
[19:05] <kim0> Here's the yaml format: http://paste.ubuntu.com/24512609/
[19:06] <kim0> there's no hint there is an upgrade, or is there
[19:08] <lazyPower> kim0 - It may not tell you anything about the upgrade until the controller polls for upgrades to charms in the env.
[19:09] <lazyPower> kim0 marcoceppi stated that was ~ every 6 hours or so. perhaps daily. I'm not 100% positive on exactly when it does that either but i can certainly find out and ping back.
[19:09] <kim0> aha I see
[19:09] <marcoceppi> kim0: you can still run the upgrade, even if juju doesn't tell you about one
[19:09] <kim0> I triggered the update manually
[19:09] <marcoceppi> it'll check when you run the command
[19:09] <kim0> yep
[19:09] <kim0> I suppose that kills any running pods .. or does it
[19:10] <marcoceppi> that's why you'll get the prompt about having to run the upgrade action
[19:10] <lazyPower> Only in rare instances will it incur downtime, and thats why its gated behind an upgrade action.
[19:10] <lazyPower> but 90% of the time its only recycling kubelet, which has no effect on the running workloads
[19:10] <kim0> Well for me, there was no "prompt" .. it just did its thing
[19:10] <kim0> $ juju upgrade-charm kubernetes-worker
[19:10] <kim0> Added charm "cs:~containers/kubernetes-worker-23" to the model.
[19:10] <kim0> that was all .. no questions asked
[19:11] <kim0> Upgrade done! well .. I have to say, this is sweet!
[19:13] <lazyPower> kim0 thanks for the positive feedback :) the team appreciates it
[19:13] <kim0> What if I want to change the VM type of worker nodes
[19:14] <kim0> I can add a constraint, add new nodes .. but how do I get rid of the old ones
[19:14] <lazyPower> kim0 i would recommend blue-green style deployment
[19:14] <Budgie^Smore> kim0 you would have to add / destroy units for that
[19:14] <lazyPower> kim0 juju deploy cs:~contianers/kubernetes-worker  worker-beta --constraints="mem=16G"
[19:14] <lazyPower> add relations
[19:14] <lazyPower> wait for teh dust to settle
[19:14] <lazyPower> cordon the og nodes
[19:14] <lazyPower> juju run-action kubernetes-worker/0 pause
[19:14] <lazyPower> ... down the line...
[19:15] <lazyPower> once all nodes have been evacuated
[19:15] <lazyPower> juju remove-application kubernetes-wroker
[19:15] <kim0> Got it!
[19:16] <kim0> Why do I need to add relations manually
[19:16] <lazyPower> i have a lot fo doc updates i see
[19:16] <kim0> I didn't need that in the initial deployment
[19:16] <lazyPower> well when you do the blue-green style, there's nothing telling juju how to wire the deployment
[19:16] <lazyPower> bundles are pre-modeled applications in a specific formation for you to consume
[19:16] <kim0> ah
[19:16] <lazyPower> you could take the canonical bundle, and modify it with the alternative deployment and deploy it into the same model
[19:16] <lazyPower> it will converge
[19:17] <lazyPower> now that may come with its own flavor of challenges if you have mutated the model... which is why i would encourage you to do it manually
[19:17] <lazyPower> what you can do is just export the model as well
[19:17] <lazyPower> make changes in the yaml
[19:17] <lazyPower> then apply that yaml
[19:18] <lazyPower> there's a lot of options, but as a dev that really likes to know how things work, i'm always going to recommend the manual method. Keeps things simple when things go wrong and i can help you unwind or recover from that :)
[19:18] <lazyPower> its harder when we're playing trace the bug
[19:22] <marcoceppi> lazyPower:  it's easier to just juju set-constraints I think
[19:22] <lazyPower> or that
[19:22] <marcoceppi> kim0: we'll document this for sure
[19:22] <lazyPower> but i hope you remember you did that when you dont want that instance type anymore :)
[19:48] <lazyPower> https://www.reddit.com/r/kubernetes/comments/699v24/canonicals_support_for_kubernetes_162_released/
[19:48] <lazyPower> upboats appreciated
[19:53] <mwhudson> balloons: i think i need an illustrated map of the ppas you are using...
[20:24] <tychicus> is it possible to start a machine that is powered off via juju?
[20:27] <rick_h> tychicus: to power it back on with juju? how did you power it off via juju?
[20:28] <tychicus> juju run --machine=4 "shutdown -h now"
[20:29] <tychicus> machine is tied to maas, I know i can power it back on from maas, but I wasn't sure if there was a way to juju run —machine=x start
[20:31] <rick_h> tychicus: oh heh no. juju run works by ssh'ing to the machine
[20:32] <rick_h> tychicus: so it has to be listening to ssh for that to do anything unfortunately
[20:32] <tychicus> ok, that's what I throught
[20:32] <Budgie^Smore> OK I upboated that, now if only I had somewhere to "play" with 1.6.2! ;-)
[20:33] <tychicus> I couldn't find the upboat icon
[20:33] <Budgie^Smore> tychicus see the arrows at the side of hte link?
[20:34] <tychicus> ah those are the boat sails ;)
[20:38] <tychicus> I'll run through a cdk  deployment today, if only I could figure out why my floating IP's work in openstack, but directly connecting an instance to the ext_net does not :(
[20:55] <kim0> Would "upgrade-charm" also upgrade me to 1.7 when it's released
[20:56] <kim0> or is it involved
[21:01] <marcoceppi> kim0: you'll need to change configuration i beleive it just targets 1.6/stable
[21:02] <kim0> ok still easy enough :)
[22:26] <kim0> is it too much to ask for worker autoscaling for kubernetes :)
[22:32] <rick_h> kim0: have to see if https://jujucharms.com/charmscaler/ will work out for you
[22:33] <kim0> well that is interesting, however I really meant adding more nodes under k8s which this scaler doesn't seem to do


[00:11] <SpamapS> RoAkSoAx: you've been quiet.. I trust things are going well?
[00:14] <_mup_> ensemble/security-connection r282 committed by<EMAIL_ADDRESS>[00:14] <_mup_> additional tests for security policy connection integration.
[00:16] <_mup_> Bug #813856 was filed: Security policies need to be integrated into zookeeper connections <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/813856 >
[00:18] <_mup_> ensemble/security-connection r283 committed by<EMAIL_ADDRESS>[00:18] <_mup_> mixin the security policy connection integration into the existing ssh zk client.
[00:21] <adam_g> any reason why relation-changed would fire two or more times in a row? is a relation-changed fired for every relation-set on the other side of the relationship?
[00:26] <hazmat> adam_g, relation changed gets fired after relation-joined as well
[00:26] <adam_g> hazmat: in all cases, on both ends?
[00:27] <hazmat> adam_g, yes.. it also gets fired when a hook does a relation-set (although only once for the hook, regardless of how many times it does relation-set in the hook)
[00:29] <adam_g> hmm. ok
[00:29] <hazmat> we used not to do after joined automatically, but noticed some of the formulas where getting their behavior wrong, as they where waiting on values in relation-changed.. but those values may have already been set by the remote end by the time the relation-joined hook fired locally so the relation-changed wouldn't have ever fired... ideally the hooks should have checked for the values in relation-joined and we could have avoided the spurious relation-
[00:29] <hazmat> change, but we figured it would be easier for formula authors this way (fire the relation-changed after a relation-join)
[00:30] <hazmat> re relation-set multiple times within a hook, the sets are all buffered to after the hook is executed so there's a single change event for all the related units.
[00:38] <smoser> hallyn, did you really just say "jaunty" ?
[01:06] <RoAkSoAx> SpampS yeah everything is going well...  changes made by william william have improved some things and some others have tp be rewritt
[01:06] <RoAkSoAx> argh from cell phonr
[01:41] <hallyn> smoser: I did indeed
[09:13] <fwereade> does anyone recall the details of the test failure in which "<ClientEvent changed at blah state:connected>" != "<ClientEvent changed at blah>"
[09:13] <fwereade> I seem to recall it's something to do with the packages we're using
[09:54] <hazmat> fwereade, it needs an update of txzookeeper
[09:54] <hazmat> fwereade, the __repr__ of client event changed
[09:54] <fwereade> hazmat: I appear to be up to date
[09:55] <hazmat> fwereade, you should check if that's the version/checkout being used
[09:55] <fwereade> hazmat: I have my PYTHONPATH set; is there anything else I should do?
[09:56] <hazmat> fwereade, you can startup python, import txzookeeper, print txzookeeper it will show the on disk location, verify that version is the one you think and is the latest
[09:57] <hazmat> sometimes if your mix packages, or do setup.py install you'll end up with a different copy on your system
[09:58] <hazmat> fwereade, you installed txzookeeper from?
[09:58] <hazmat> ppa or bzr?
[09:58] <fwereade> hazmat: ppa
[09:58] <fwereade> should it be in /usr/lib/pymodules/python2.7?
[09:58] <fwereade> or does that indicate I have the wrong one again somehow?
[09:59] <hazmat> fwereade, what version of the package do you have?
[10:00] <fwereade> hazmat: 0.8.0
[10:00] <fwereade> hazmat: is there somewhere I can check what version I *should* have without asking people?
[10:02] <hazmat> fwereade, the bzr revision number should be in  the package versionthere.. so as far being able to determine this by yourself, the package version bzr revision should match that of txzookeeper trunk (rev 43)
[10:02] <fwereade> hazmat: hm, good to know
[10:03] <fwereade> hazmat: so my life would probably be easier if I just kept a checkout of txzookeeper and installed that whenever it changed?
[10:03] <fwereade> hazmat: or should I actually be watching trunk for many things?
[10:04] <hazmat> fwereade, txzookeeper is pretty stable, maybe one change every couple months at this point. i use virtualenvs and run it with python setup.py develop which links the source tree into the python package dir, so updating the source tree is sufficient.
[10:05] <hazmat> fwereade, can you confirm the exact package version ?
[10:05] <hazmat> s/exact/full
[10:06] <fwereade> hazmat: 0.8.0 is what I get from txzookeeper.version
[10:06] <hazmat> fwereade, apt-cache show txzookeeper will show the package version
[10:07]  * fwereade raises eyebrow ("no packages found")
[10:08] <hazmat> fwereade, so that would imply it wasn't installed by ppa
[10:09] <fwereade> hazmat: hmm
[10:09] <fwereade> hazmat: I just re-added the repository and updated again
[10:09] <hazmat> or maybe its python-txzookeeper
[10:09] <fwereade> hazmat: ooh, that rings a bell
[10:09] <hazmat> doesn't look like it from here.. https://launchpad.net/~ensemble/+archive/ppa?field.series_filter=natty but it sounds sensible ;-)
[10:09] <fwereade> hazmat: 0.8.0-0ensemble43~natty1
[10:10] <hazmat> hmm.. that's the latest
[10:10] <fwereade> hazmat: which looks right based on what you've been saying
[10:10] <hazmat> fwereade, which test is it that's failing
[10:15] <fwereade> hazmat: sorry, bad time for system to fall over
[10:15] <fwereade> hazmat: let me recover my state...
[10:15] <hazmat> fwereade, no worries
[10:15] <fwereade> hazmat: rerunning suite now, but you can find it by grepping for ClientEvent
[10:17] <fwereade> ensemble.state.tests.test_relation.???.test_watch_user_callback_invocation_delays_node_watch
[10:18] <fwereade> UnitRelationStateTest
[10:18] <fwereade> hazmat: trunk works for you then?
[10:23] <hazmat> fwereade, yeah.. works fine for me
[10:23] <fwereade> hazmat: bah :)
[10:25] <fwereade> hazmat: well, not to worry for now, I'll poke around and see if I can figure something out
[10:25] <fwereade> hazmat: thanks for your help
[10:26] <hazmat> fwereade, yeah.. i'm not sure what the issue is.. i'm firing up an ensemble instance to verify the unit tests there
[11:28] <hazmat> fwereade, just verified the failure using txzk package on ec2
[11:30] <hazmat> hmm
[11:32] <hazmat> it looks like i'm pushing and pulling from different branches
[11:32] <hazmat> they have the same content though
[11:51] <daker> hey i am blocked at preseed conf file for my formula, can anyone explain how it works ?
[12:13] <_mup_> ensemble/trunk-merge r271 committed by<EMAIL_ADDRESS>[12:13] <_mup_> merge trunk
[13:03] <fwereade> hazmat: hey, soory I missed you
[13:04] <fwereade> hazmat: yeah, I verified that from my perspective it really is the tests that are wrong (all the txzookeepers I can find repr with state: connected), and thought I'd wait to hear back
[13:13] <hazmat> fwereade, it looks like that test is broken
[13:13] <hazmat> fwereade, the repr of the client event now has the connection status
[13:13] <hazmat> the test needs an update to reflect that
[13:13] <fwereade> hazmat: cool (well, not cool, but at least it's not my own mistake :p)
[13:14] <fwereade> hazmat: I already have a local fix, shall I create a bug and propose a merge?
[13:14] <fwereade> hazmat: or should we complain to whoever last merged?
[13:14] <hazmat> fwereade, its a trivial, typically just paste the diff, get an ack, and commit to trunk
[13:15] <fwereade> hazmat: http://paste.ubuntu.com/649098/ look ok to you?
[13:16] <hazmat> hmm.. looks like ben merged the failed test in last rev
[13:16] <hazmat> fwereade, looks good +1
[13:16] <fwereade> hazmat: cheers
[13:16] <fwereade> hazmat: just rerunning the tests for paranoia's sake
[13:18] <hazmat> it looks like some other test logic got removed in that merge
[13:18] <hazmat> unrelated to this fix
[13:47] <RoAkSoAx> fwereade: o/ I have a few issues to show you in just a second
[13:47] <fwereade> RoAkSoAx: cool, just shout when you need me
[13:49] <RoAkSoAx> fwereade: will do in just a few secs
[13:49] <RoAkSoAx> or minutes :)
[13:51] <RoAkSoAx> fwereade: can I start using trunk to test the orchestra integration instead of the bootstrap branch?
[13:51] <RoAkSoAx> fwereade: as all your change shave already been merged tright?
[13:51] <RoAkSoAx> and I think I might use of a couple of bugfixes
[13:52] <fwereade> RoAkSoAx: trunk has the big refactoring
[13:53] <fwereade> RoAkSoAx: there's some stuff in lp:~fwereade/ensemble/cobbler-connect-production that might be of use to you
[13:53] <RoAkSoAx> fwereade: so is it safe to use my work with that branch?
[13:53] <fwereade> RoAkSoAx: it's a hopefully-useful CobblerConnect implemented with twisted
[13:54] <fwereade> RoAkSoAx: and it should be just enough to maunch a machine, without passing anything useful to it whatsoever
[13:54] <RoAkSoAx> fwereade: right now im getting erros that doesn't seem related to the refactoring
[13:54] <RoAkSoAx> that's why I'm asking
[13:54] <fwereade> RoAkSoAx: I'm going to give it a final once-over and then propose a merge
[13:55] <fwereade> RoAkSoAx: like what?
[13:55] <RoAkSoAx> fwereade: unhasable dict
[13:55] <RoAkSoAx> error
[13:55] <RoAkSoAx> when trying to deploy
[13:56] <fwereade> RoAkSoAx: sorry, doesn't ring a bell :(
[13:56] <fwereade> RoAkSoAx: paste a traceback?
[13:57] <RoAkSoAx> fwereade: yeah I'm gonna reproduce with a clean zookeeper machine
[13:57] <RoAkSoAx> I'm deploying it atm
[14:07] <RoAkSoAx> fwereade: now I can't even bootstrap
[14:07] <RoAkSoAx> http://pastebin.ubuntu.com/649146/
[14:07] <fwereade> RoAkSoAx: is that on trunk?
[14:08] <RoAkSoAx> fwereade: bot, ensemble-bootstrap
[14:09] <fwereade> RoAkSoAx: what it (probably) means is that OrchestraLaunchMachine is returning a string (name?) instead of a deferred list of OrchestraMachines
[14:10] <Daviey> eek
[14:10] <RoAkSoAx> fwereade: yeah, and the thing is that from yesterday till today nothing changed and yesterday there was no error :)
[14:12] <fwereade> RoAkSoAx: wait, I misread
[14:13] <fwereade> RoAkSoAx: that's the result of get_zookeeper_machines
[14:13] <RoAkSoAx> fwereade: heh never mind found the error. the same thing that's giving error when launching machines, is the thing that's giving error when bootstrapping if I comment out the first thing
[14:14] <RoAkSoAx> fwereade: but yeah, I've bumped into stuff that seems to still be ec2 specific
[14:14] <RoAkSoAx> let me re-check
[14:14] <fwereade> RoAkSoAx: very probable... I did my best, but it's still all a bit new to me ;) what in particular
[14:17] <RoAkSoAx> fwereade: yeah we are both learning our way here:)
[14:17] <daker> fwereade, yo i have just pushed the changes https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038
[14:17] <fwereade> daker: cool, thanks, I'll take a look
[14:22] <fwereade> daker: tiny tweaks :)
[14:23] <fwereade> RoAkSoAx: I'm just firming up my tests a little, shout if I can help
[14:24] <daker> fwereade, ah you mean that between the two sub_parser.add_argument there should a break, right ?
[14:24] <fwereade> daker: sorry, no
[14:25] <fwereade> daker: I just meant that the original source line was over 80 chars
[14:25] <daker> and ? the help text should be reduced ?
[14:26] <fwereade> daker: and so a line break, probably just before the "help=", would make the code nice without needing to touch the text
[14:26] <fwereade> daker: the text looks fine to me
[14:27] <fwereade> daker: if the source is still over 80 characters even with that break, you can just do something like the following (give me a moment...)
[14:28] <daker> fwereade, is it good like that http://paste.ubuntu.com/649169/ ?
[14:29] <fwereade> daker: that just breaks 80 chars, how about http://paste.ubuntu.com/649177/
[14:30] <daker> ah ok i understand now!
[14:30] <hazmat> bcsaller, the merge of config-set-lifecycle looks like it had some testing regressions added
[14:31] <hazmat> bcsaller, fwereade took care of the failing test, but it looks like (as noted in review) that some other tests also lost some of their logic
[14:45] <RoAkSoAx> fwereade: what should __check_state from findzookeepers.py return?
[14:47] <fwereade> RoAkSoAx: thinking
[14:48] <fwereade> RoAkSoAx: it should *eventually* return a list of OrchestraMachines
[14:48] <fwereade> RoAkSoAx: (with just one element for now)
[14:48] <fwereade> RoAkSoAx: ...ok, I put that badly
[14:48] <fwereade> RoAkSoAx: it can return whatever it wants, but the callback should be able to turn *that* into a list of etc
[14:49] <fwereade> RoAkSoAx: the callback chain should end up returning a list of machines
[14:49] <fwereade> RoAkSoAx: am I making sense?
[14:50] <RoAkSoAx> fwereade: i think so :) yes!
[14:51] <fwereade> RoAkSoAx: cool :)
[14:51] <fwereade> RoAkSoAx: as long as we get the expected results/errors from .run(), how you do it is up to you
[15:04] <fwereade> jimbaker: hi
[15:06] <fwereade> jimbaker: I haven't managed to induce any errors in EC2BootstrapTest, try as I might
[15:06] <fwereade> jimbaker: any pointers?
[15:06] <fwereade> jimbaker: however, I *have* found a different test that will fail pretty soon if run with -u
[15:15] <fwereade> RoAkSoAx: you know the kickstart file on the cobbler server?
[15:16] <fwereade> RoAkSoAx: that I had to make a little change to to get past the system install step?
[15:17] <fwereade> RoAkSoAx: such a file must have a certain set of properties before we can actually deploy an ensemble machine running it, right?
[15:18] <fwereade> RoAkSoAx: ...but those files are not actually part of ensemble
[15:19] <bcsaller> hazmat: all the tests on trunk are passing for me. I thought I did it properly, though I did have to clear .pyc files before it worked
[15:19] <bcsaller> hazmat: maybe you can point me at what you're seeing?
[15:24] <fwereade> bcsaller: is your txzookeeper up to date?
[15:24] <daker> fwereade, can you take a look now https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 ?
[15:24] <fwereade> bcsaller: if you search the source for ClientEvent you'll find the test
[15:25] <bcsaller> fwereade: ahh, the state stuff in the repr
[15:25] <fwereade> bcsaller: yep
[15:26] <fwereade> bcsaller: I know there was something funny -- I hit something similar on the sprint -- and niemeyer went off, discussed packaging with someone, and magically fixed it
[15:26] <fwereade> bcsaller: ...but I don't know the details
[15:27] <fwereade> bcsaller: regardless: the current version does have "state: connected" in the __str__, so I changed the test to expect it
[15:27] <bcsaller> fwereade: I updated my txzk, I'll give it another pass
[15:27] <fwereade> bcsaller: that one's already fixed, I think hazmat was concerned about something else, but I didn't review so I don't know what it is
[15:27] <jimbaker> fwereade, which test is that?
[15:28] <hazmat> bzr qdiff -c -1 on trunk will show the fix from fwereade, the fix that remains is for the tests that have lost logic.. as per bzr qdiff -c -2
[15:28] <fwereade> jimbaker: ensemble.state.tests.test_agent.AgentDomainTest.test_connect_agent
[15:28] <jimbaker> fwereade, yes that one fails on a regular basis
[15:28] <fwereade> jimbaker: ah, cool :)
[15:29] <fwereade> jimbaker: well, not cool :p
[15:29] <jimbaker> fwereade, just wonder why the bootstrap tests fail for me
[15:29] <hazmat> most of these bits are missing from test_hook https://pastebin.canonical.com/50069/
[15:29] <hazmat> bcsaller, ^
[15:29] <bcsaller> fwereade: yeah, didn't realize there was a txzk version issue there, its working on trunk now.
[15:29] <bcsaller> hazmat: those bits don't apply, we inlined and removed that api
[15:30] <fwereade> jimbaker: how often are you seeing the bootstrap failure?
[15:30] <hazmat> bcsaller, the flush logic at the top does
[15:30] <jimbaker> if i run -u, it will eventually fail
[15:30] <hazmat> fwereade, also the tests now fail if you run them disconnected
[15:30] <jimbaker> seems like less than 10 iterations
[15:31] <hazmat> the calls to determine the image id aren't being mocked
[15:31] <fwereade> jimbaker: for that specific test method?
[15:31] <jimbaker> fwereade, when i ran just the bootstrap tests, for example
[15:31] <fwereade> hazmat: I have noticed that, I didn't think it was me, but given that I was hitting that code most recently I guess it was
[15:32] <fwereade> jimbaker: weord, I've tried with all variants from .providers on up
[15:32] <fwereade> jimbaker: quick thought
[15:32] <jimbaker> fwereade, which is generally how i will isolate: run a section of tests w/ -u (test/test suite/script if possible)
[15:33] <fwereade> jimbaker: is your machine under noticeably low or high load?
[15:33] <jimbaker> fwereade, low load
[15:33] <fwereade> jimbaker: bah, so has mine been
[15:33] <jimbaker> fwereade, however i will retry now, on both my laptop and desktop
[15:34] <fwereade> hazmat: shall I pick that issue up?
[15:34] <jimbaker> fwereade, curiously i was seeing it fail in the same place on my macbook pro yesterday
[15:34] <fwereade> jimbaker: I'm sure it's a real problem, I just wish I could figure out how to repro it
[15:34] <hazmat> fwereade, if you want/time allows, else just file an issue for it
[15:34] <hazmat> fwereade, the cobbler work is higher priority
[15:35] <jimbaker> SpamapS, you had asked earlier about osx, the 2.7ism that apparently snuck in was around argparse
[15:35] <fwereade> hazmat: true
[15:35] <fwereade> hazmat: cheers
[15:35] <fwereade> bbs, diconnecting to get the error list
[15:35] <jimbaker> SpamapS, this shouldn't impact actualy client usage however - it's just testing against specific error messages, and these got changed in 2.7
[15:36] <jimbaker> probably need to change the tests
[15:36] <RoAkSoAx> SpamapS: ping
[15:36] <jimbaker> the actual mac failures were all about different temp file paths
[15:37] <jimbaker> and also uninteresting
[15:40] <_mup_> Bug #814144 was filed: test errors when no network available <Ensemble:New> < https://launchpad.net/bugs/814144 >
[16:06] <jimbaker> fwereade, given the network dependency in bug 814144 on the same tests mentioned earlier as having looping problems (./test -u ensemble.providers.ec2.tests.test_bootstrap), maybe this theory explains things
[16:06] <_mup_> Bug #814144: test errors when no network available <Ensemble:New> < https://launchpad.net/bugs/814144 >
[16:07] <jimbaker> 1. yesterday i was running the tests at a coffee shop w/ a so-so network, and they were eventually failing, maybe because of additional timing
[16:07] <jimbaker> 2. today, i'm running them at home w/ a good low-latency network, no failures
[16:11] <fwereade> jimbaker: ah-ha!
[16:11] <fwereade> jimbaker: very plausible
[16:12] <fwereade> jimbaker: consider me on it
[16:12] <jimbaker> fwereade, sounds good
[16:14] <daker> fwereade, is my MP good now ?
[16:14] <fwereade> daker: so sorry, I think I lost you in a context switch
[16:15] <daker> no worries https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038
[16:15] <fwereade> daker: would be good to lose the spaces before the colons, sorry I notied them late
[16:16] <fwereade> if confirmed..., if value.strip()...
[16:16] <fwereade> but lgtm otherwise
[16:16] <jimbaker> shang, we met in budapest, right?
[16:18] <daker> fwereade, i am lost :/
[16:24] <fwereade> daker: sorry again
[16:25] <fwereade> if confirmed is False :
[16:25] <fwereade> should read
[16:25] <fwereade> if confirmed is False :
[16:25] <fwereade> if confirmed is False:
[16:25]  * fwereade winces
[16:25] <fwereade> ...and there's another one a couple of lines later
[16:26] <fwereade> it's just for consistency's sake ;)
[16:29] <jimbaker> i'm pretty certain anything like that would be picked up by the pep8 tool
[16:29] <jimbaker> i recommend always running pep8/pyflakes (reviewers certainly do)
[16:32] <jimbaker> also, in this particular case, best to say something like: if confirmed: ...
[16:33] <jimbaker> no need to say is False, certainly the argparse setting ensures it's True or False, and if even if it didn't, i don't see that it would matter if it were 0 or None
[16:51] <SpamapS> RoAkSoAx: pong, sup?
[16:54] <RoAkSoAx> SpamapS: howdy!! I was working on the load_state stuff, and doing that, http://pastebin.ubuntu.com/649258/, returns something like: exceptions.AttributeError: 'str' object has no attribute 'get'
[16:54] <RoAkSoAx> any ideas?
[17:03] <SpamapS> RoAkSoAx: reading now
[17:04] <hazmat> RoAkSoAx, the state being returned by load_state is a string it appears, does the error happen if you remove the bottom line
[17:04] <hazmat> RoAkSoAx, you also can't do this interactively since there are deferreds in the mix
[17:05] <daker> fwereade, sorry again, can you give a final look https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038 ?
[17:05] <SpamapS> Its possible the state that was saved wasn't properly serialized
[17:05] <hazmat> the reactor needs to be started and the result processed either with a callback or with @inlineCallbacks and yield
[17:05] <RoAkSoAx> hazmat: yeah I'm working on that ;)
[17:08] <fwereade> daker: looks great to me, my approve stands :)
[17:10] <hazmat> daker, just added a review comment to it
[17:18] <daker> hazmat, i hope it's good now ツ
[17:19]  * daker crosse his fingers
[17:28] <hazmat> daker, looks good, except for the missing test
[17:30] <fwereade> hazmat: golly, we even have tests for the command line, I didn't even think to demand them...
[17:30] <fwereade> hazmat: I think the laxity at my last place has damaged my brain :/
[17:30] <fwereade> hazmat: I used to test *everything*
[17:31] <fwereade> hazmat: ...I'm so happy to be here :D
[17:31] <hazmat> fwereade, in this case the cli is our primary interface, if we're not testing it.... then bad things ;-)
[17:31] <fwereade> hazmat: quite... I just got used to being happy when tests for *anything* showed up ;)
[17:32] <fwereade> hazmat: ok, that's not fair, but we didn't test anything like as much as we did at the place before
[17:33] <fwereade> anyway, I think I'm degenerating into friday evening rambling, and I should be off
[17:33] <fwereade> bye all :)
[17:33] <robbiew> Friday?
[17:33] <robbiew> lol
[17:33]  * robbiew notes that fwereade is on holiday tomorrow
[17:34] <_mup_> Bug #814194 was filed: Implement support for expose and unexpose hooks <Ensemble:New> < https://launchpad.net/bugs/814194 >
[17:34] <hazmat> daker, here's a test for it btw, if you could add this to your branch in ensemble/control/tests/test_shutdown the branch should be good.. https://pastebin.canonical.com/50078/
[17:35] <daker> oh good thanls hazmat
[17:36] <hazmat> daker, np, thanks for working on it
[17:36] <daker> hazmat, would be good if you can put it on paste.u.c, i don't have permission  access that site
[17:37] <daker> to*
[17:37] <hazmat> daker, http://pastebin.ubuntu.com/649319/
[17:39] <daker> hazmat, one last question, how can i run the test ?
[17:40] <hazmat> daker, the easiest option assuming you have the zookeeper package installed (and the zk server running) is just trial ensemble/control/tests/test_shutdown.py
[17:40] <daker> ok
[17:48] <daker> any thoughts http://paste.ubuntu.com/649326/ ?
[17:49] <daker> hazmat, ^
[17:49] <hazmat> PYTHONPATH=/home/daker/Projects/small-fix/ trial ensemble/control/tests/test_shutdown.py
[17:49] <hazmat> daker, ^
[17:49] <hazmat> trial is from the twisted pkg
[17:50] <daker> hazmat, is the test includes the -y argument ?
[17:50] <hazmat> daker, the test i pasted does
[17:51] <daker> ok hazmat the test succeed
[17:51] <hazmat> daker, the error is because the test is being run directly, which A) isn't going to work as the test runner won't be invoked b) relative imports need a fully qualified reference to work correctly when the script is being run this way the current module doesn't really know its package
[17:51] <hazmat> daker, cool, i tested before i pasted, but its good to have confirmation ;-)
[17:57] <daker> hazmat, done! https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038
[18:03] <niemeyer> Yo all
[18:04] <jimbaker> niemeyer, hi
[18:07] <_mup_> ensemble/security-groups r285 committed by<EMAIL_ADDRESS>[18:07] <_mup_> security groups
[19:22] <_mup_> ensemble/security-groups r286 committed by<EMAIL_ADDRESS>[19:22] <_mup_> group principal membership management and connection attaching.
[20:02] <_mup_> Bug #814260 was filed: Ensemble security group principals <Ensemble:New for hazmat> < https://launchpad.net/bugs/814260 >
[20:12] <_mup_> ensemble/security-groups r287 committed by<EMAIL_ADDRESS>[20:12] <_mup_> add get_token to groupprincipal for parity with normal principal
[20:16] <_mup_> ensemble/trunk-merge r272 committed by<EMAIL_ADDRESS>[20:16] <_mup_> merge trunk
[21:06] <_mup_> ensemble/security-otp-principal r289 committed by<EMAIL_ADDRESS>[21:06] <_mup_> otp principal for passing credentials via insecure channels
[21:18] <_mup_> ensemble/robust-hook-exit r281 committed by<EMAIL_ADDRESS>[21:18] <_mup_> Use processExited as the normal end of the process, while making processEnded available for purposes like testing
[21:28] <_mup_> ensemble/robust-hook-exit r282 committed by<EMAIL_ADDRESS>[21:28] <_mup_> PEP8
[21:40] <_mup_> ensemble/robust-hook-exit r283 committed by<EMAIL_ADDRESS>[21:40] <_mup_> Doc string
[22:02] <_mup_> ensemble/security-otp-principal r290 committed by<EMAIL_ADDRESS>[22:02] <_mup_> minimal principal interface for otp, using the otp consumes it
[22:07] <_mup_> Bug #814320 was filed: Need OTP for passing credentials to an external process <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/814320 >
[22:09] <hazmat> phew.. i think thats all the core security machinery needed
[22:09] <hazmat> sigh.. "Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal.  It was logged with id OOPS-2028MPJ3.  Sorry for the inconvenience.
[22:09] <hazmat> "
[22:09] <hazmat> oh well


 I still have the issue when changing section (which just toggles the visibility of a page on and off). I put some questions in it based on yesterday's discussion. If you can grep on "ZSOMBI:" you should find them all :)
[07:21] <didrocks> zsombi: but from what I understand, any RowLayout for example can get an implicitHeight automatically based on children's height (contrary to for instance, Item or Rectangle…)
[07:21] <zsombi> didrocks: no, you did not understand it right :)
[07:21] <didrocks> zsombi: tell me once you get a chance to have a look, thanks a bunch in advance!
[07:22] <zsombi> didrocks: I did not say yesterday that the RowLayout does that, I said the Row does that
[07:22] <zsombi> didrocks: I said RowLayout works same way as Item or Rectangle
[07:23] <didrocks> zsombi: that's weird, because from my tests, it does seem to me that RowLayout does it (you will see in my // ZSOMBI: that some examples have no height)
[07:24] <zsombi> didrocks: heh?
[07:24] <didrocks> zsombi: for instance (when you get some time to look), the "id: priceRow" seems to have that behavior to me
[07:24] <didrocks> it's a RowLayout and its height seems to be set by its content
[07:25] <didrocks> zsombi: feel free to have a look when you have the time (you can maybe even commit your answers if you prefer this way)
[07:25] <zsombi> didrocks: which one is that file_
[07:25] <zsombi> ?
[07:26] <zsombi> ah, DetailsPage.qml
[07:26] <didrocks> yep :)
[07:28] <zsombi> didrocks: that component makes no sense... why do you use RowLayout there, if none of the component sare using the layouting? Then, each UITK component has an implicit size
[07:29] <zsombi> didrocks: I see TextArea uses the maximumWidth, doe sthat work at all?
[07:30] <zsombi> didrocks: so in this case the layout works as positioner, as the size is not decided by the layout, but by the components themselves, and the layout cannot affect its sizes
[07:30] <didrocks> zsombi: it's indeed for the maximumWidth in the TextArea, and it seems to work?
[07:31] <zsombi> didrocks: what happens if you size the view to be smaller in width_
[07:31] <zsombi> ?
[07:31] <didrocks> zsombi: setting it to 3 gu and it works as expected
[07:31] <zsombi> didrocks: no, resize the view with the mouse
[07:31] <zsombi> didrocks: I did not ask to change the value
[07:32] <zsombi> of the component, the view
[07:32] <didrocks> zsombi: ah, so it's basically fallbacking to width: maxWidth
[07:32] <zsombi> didrocks: will the text area resize? no
[07:32] <didrocks> and it's set
[07:32] <didrocks> so no resizing
[07:32] <zsombi> didrocks: no, it doesnát
[07:32] <zsombi> did if you set the minimumWidth to ex 10GU?
[07:34] <didrocks> yeah, I see, basically the width is set, without resizing capability
[07:34] <zsombi> didrocks: as the first and the last label layouting is not set, nothing will happen
[07:34] <didrocks> so RowLayout is transformed as a positionner
[07:34] <didrocks> and so, the height is implicit from children
[07:34] <didrocks> that's right?
[07:36] <zsombi> didrocks: have you printed its height out onHeightChanged?
[07:38] <didrocks> zsombi: just did that, get one event (I guess once all children are initialized)
[07:38] <zsombi> didrocks: and the height is set?
[07:38] <didrocks> yeah
[07:39] <zsombi> didrocks: hmm... interesting then! so then somewhat acts as the positioner... I did remember it differently, seems they fixed that
[07:40] <didrocks> zsombi: that's a behavior which makes sense to me (at least ;)), but yeah, maybe they changed it if too many people were puzzled about it
[07:40] <zsombi> didrocks: but then woudl be interesting to see how it works with the proper layouting used... try to set minimum and maximum for both blabels and text area, then resize the window runtime
[07:41] <didrocks> zsombi: I guess that's the case of id: tipRow (a little bit lower)
[07:41] <didrocks> it has one element with Layout.fillWidth: true
[07:41] <didrocks> no height set
[07:42] <didrocks> and indeed, the slider changes its width based on parent's size, and the height is set (the event is fired once with a value)
[07:42] <zsombi> didrocks: no, there you have a width set for the RowLayout
[07:43] <zsombi> didrocks: I meant to set the max and min inside this RowLayout, where you don't have width or height set
[07:43] <zsombi> didrocks: in the priceRow
[07:45] <didrocks> zsombi: well, without any set width on RowLayout, as you told, minimum/maximumWidth doesn't work
[07:45] <didrocks> I just have a set width on my TextField, when resizing the window (the whole RowLayout is shifting)
[07:46] <zsombi> didrocks: yes, but I asked you to set all min and max for the two labels and the text area
[07:46] <zsombi> didrocks: or you say you've set it and it doesn't work?
[07:48] <didrocks> zsombi: I have set min/max to all of the children (so the 2 labels and text area), the RowLayout don't have any width and it doesn't work (it has the behavior I explained above ^)
[07:49] <zsombi> didrocks: as expected
[07:49] <zsombi> didrocks: so the auto-height seem to be fixed in the layouter, so I'd expect the same in the ColumnLayout
[07:50] <didrocks> zsombi: yeah, that removes some of my questions.
[07:50] <zsombi> didrocks: so then make sure you set the width
[07:50] <didrocks> zsombi: yeah, or I'm using a Row, which makes more sense in that one
[07:50] <zsombi> didrocks: but instead of width: parent.width binding, I'd suggest you to switch to anchoring
[07:50] <didrocks> ah?
[07:50] <didrocks> why?
[07:51] <zsombi> didrocks: well, depends, if you want to control the width of the text area to fill the remainder space, you should use RowLayout
[07:51] <zsombi> didrocks: it is more performant to use anchors than width bindings
[07:51] <didrocks> zsombi: good to know, changing that and pushing a new rev then
[07:51] <zsombi> didrocks: width binding is evaluated each time the width is changed, anchors do not do that
[07:52] <didrocks> of course! didn't think about it :)
[07:52] <didrocks> zsombi: I guess TextField and Label's height are implicitely set based on Font's size?
[07:52] <zsombi> didrocks: I mean they do, but that is solved under the hood, and does not go through the binding system, which width: parent.width doies
[07:52] <zsombi> didrocks: nopez
[07:52] <zsombi> Label height is, TextField not
[07:53] <didrocks> zsombi: hum, so if you look at billName, I didn't set an height for it?
[07:53] <zsombi> didrocks: Label paintedHeight is, I mean. the size is not
[07:56] <didrocks> zsombi: any idea why I didn't need to set the height on billName thus?
[07:57] <zsombi> didrocks: implicitHeight = clientRect.height, that's why :)
[07:57] <zsombi> childrenRect not clientRect, sorry... childrenRect.height takes into account the paintedHeight
[07:57] <didrocks> so, it does set an implicitHeight based on its content?
[07:57] <didrocks> ok :)
[07:57] <zsombi> and this is done internally
[07:59] <didrocks> zsombi: ok, changed this and switched to anchors (pushed a new rev). So there are only 2 remaining ZSOMBI: question in the code (one about the icon size and one about the element one) + there is then this bug when clicking on sections
[08:00] <zsombi> didrocks: could you point me to the files having those Qs?
[08:01] <didrocks> zsombi: sure, one is in Main.qml, and the other in pages/DetailsPage.qml (at the very end)
[08:01] <zsombi> didrocks: so Page?
[08:01] <didrocks> zsombi: sorry, the other one is in components/AddRemoveInt.qml
[08:01] <didrocks> zsombi: yeah, Page
[08:02] <didrocks> I guess it's its internal implementation doing that
[08:02] <zsombi> didrocks: Page fills its parent automatically... that was a mistake we have to live with... and header is always overlayd the Page content, and MainView is responsible on scrolling in/out the header
[08:02] <zsombi> overlaid
[08:02] <didrocks> zsombi: ok, that's what I reckoned
[08:03] <zsombi> didrocks: if you want to disable this, set anchors.fill: undefined, then you have to do the anchoring youtself!
[08:03] <zsombi> didrocks: but beware that header management may get broken afterwards!!!
[08:03] <zsombi> next
[08:03] <didrocks> zsombi: yeah, that makes sense ;)
[08:03] <didrocks> so the Button + icon?
[08:04] <zsombi> didrocks: hmm....
[08:05] <zsombi> didrocks: the Button reisizes its width automatically... unless you set a width, or a maximumWidth
[08:05] <zsombi> didrocks: is that what you are asking there?
[08:06] <didrocks> zsombi: well, the resizing is weird for the last element in DetailsPage.qml
[08:06] <didrocks> zsombi: if you uncomment //iconName: "add", then the size is way bigger than just the icon's additional width space
[08:08] <zsombi> didrocks: uh, I checked the AddRemoveInt.qml... not at the DetailsPage yet
[08:09] <zsombi> didrocks: DetailsPage, when you set an icon, it also adds some margins, perhaps that is what you see... screenshot?
[08:12] <didrocks> zsombi: the margins are a little bit large (;)) as you can see here: http://people.canonical.com/~didrocks/qmltest/withicons.png
[08:12] <didrocks> in comparison of: http://people.canonical.com/~didrocks/qmltest/withouticons.png
[08:12] <zsombi> didrocks: wow!!! that's bad!
[08:13] <zsombi> didrocks: smells of a bug!
[08:14] <didrocks> zsombi: isn't it? ;) I wonder if that's due to the RowLayout around the Buttons…
[08:16] <zsombi> didrocks: as long as you don't have any layouting property attached, it shouldn't, but it would be good to check that
[08:16] <zsombi> didrocks: byt the button is not in the RowLayout, it is below it, right?
[08:17] <didrocks> zsombi: right, sorry, it's in an Item
[08:17] <zsombi> didrocks: and all you do is you anchor it to th eright of the item...
[08:17] <didrocks> right, the first to the left, the second to the right
[08:17] <zsombi> exactly
[08:28] <didrocks> zsombi: ok, I have a minimal reproducer, let me open a bug
[08:28] <didrocks> zsombi: http://paste.ubuntu.com/11952349/ is enough
[08:33]  * zsombi break, bbl
[08:34] <didrocks> bug #1478839
[08:35] <mcphail> popey: have been away for the weekend so just got your message. I haven't documented anything about a non-minimal SDL as it is basically just the minimal SDL with most of the config options switched on! I see bschaefer has opened an interesting new branch which I'm keen to test
[08:35] <didrocks> zsombi: thanks a lot for your answer on the layout system! Now that it seems that the RowLayout changed its behavior compared to what we discussed yesterday, things make sense to me! :)
[08:35] <zsombi> didrocks: yeah... I was outdated on that front, sorry :)
[08:36] <didrocks> zsombi: no worry, I prefer that that me being totally out of any rationale understanding on why that was different from my observations :)
[10:10] <popey> Kaleo: is https://bugs.launchpad.net/camera-app/+bug/1468341 being worked on?
[10:10] <popey> (Got bitten by this at the weekend, annoyed that video taken on mx4 was 720p and not 1080p 🙁 )
[12:08] <dpm> hi JamesTait, I've been pointed out to bug 1478653 - do you happen to know where the "Highlights of the week" message can be translated? I can't find it on the templates here: https://translations.launchpad.net/software-center-agent/trunk/
[12:17]  * JamesTait looks
[12:31] <JamesTait> dpm, https://translations.launchpad.net/software-center-agent/trunk/+pots/devportal/ru/+translate?direction=backwards&memo=1030&start=1020 is where it appears.
[12:32] <JamesTait> dpm, in fact, https://translations.launchpad.net/software-center-agent/trunk/+pots/devportal/ru/+translate?batch=10&show=all&search=highlight is probably better. ☺
[12:32] <dpm> JamesTait, ah, thanks. It seems the bug report mistakenly said highlight*s*, which is why I could not find the string!
[12:34] <JamesTait> dpm, it took me a couple of attempts as well. ☺
[14:13] <didrocks> kalikiana: hey, are you sure that bug #1271973 was fixed? I can confirmed that I don't get the whole document
[14:32] <kalikiana> didrocks: lemme check
[14:34] <kalikiana> didrocks: that was not fixed. the bug status is correctly set to Confirm. there was a change meant to address it but it broke ABI
[14:35] <kalikiana> didrocks: the better approach is here https://code.launchpad.net/~kalikiana/u1db-qt/indexRoles/+merge/211771
[14:36] <kalikiana> not sure what the state of it is, though, I haven't had time for a while to actively work on things
[14:37] <didrocks> zbenjamin: maybe you can give a look (I saw that you reviewed other u1db branches) on that one? ^
[14:37] <didrocks> kalikiana: any workaround for now than listing in Indexes all fields you need?
[14:38] <kalikiana> didrocks: I don't think so
[14:41] <didrocks> kalikiana: ok, do you think you have time for pushing this MP a little bit? I think that's quite a bad one for developer experience in particular
[19:34] <cwayne_> hiya, is there a way to programatically get my app's writable directory path?


[03:28] <ScottK> It doesn't.
[04:08] <micahg> ScottK: would you mind a featureful upload for bug 375038 in precise?  i.e. add the enable flag and upload with a +xps version
[04:24] <jbicha> micahg: libgxps is in universe in Precise though, right?
[04:58] <ScottK> micahg: Is it a regression?
[05:01] <jbicha> ScottK: no, it's a new feature
[05:03] <ScottK> Then I do mind.  It's not SRU material. It should be done in backports.
[05:19] <ajmitch> micahg: someone submitted seamonkey to the arb. I pointed them in your direction but I'm not entirely convinced they'll contact the team :)
[05:19] <micahg> ScottK: I was asking for backports, sorry :)
[05:36] <micahg> ajmitch: hrm, it needs to be updated every 6 weeks, if it's easier to do that through the ARB, then go for it
[05:36] <micahg> with someone willing to commit
[05:36] <micahg> ajmitch: unless bkerensa objects (he's working on it for the distro)
[05:37] <micahg> I'm normally against such things, but it's a real bear
[05:37] <ajmitch> micahg: definitely not a candidate for the ARB due to size
[05:37] <ajmitch> I know you probably don't want to commit time to it
[05:37] <micahg> ajmitch: ok, well, as I told bkerensa, I'm willing to sponsor uploads if people are willing to do the work to maintain it
[05:38] <micahg> jbicha: yeah, that's why I was thinking backports ;)
[05:39] <bkerensa> ajmitch: Whats up?
[05:39] <bkerensa> >.<
[05:39]  * bkerensa looks up
[05:40] <bkerensa> the arb handles packages too?
[05:40] <bkerensa> Hmm is someone looking to maintain seamonkey or whats the purpose of going to the arb versus having someone sponsor it?
[05:40] <ajmitch> what do you mean by 'handles packages'?
[05:41] <ajmitch> they submitted a binary tarball
[05:41] <bkerensa> ajmitch: I thought they only did like applications for independent developers or something that needs introduction not established things
[05:41] <bkerensa> ahh
[05:41] <bkerensa> ajmitch: do you not what version of Seamonkey the tarball they submitted was?
[05:42] <ajmitch> 2.10.1
[05:42] <ajmitch> & yes, submissions ought to be from someone associated with the project
[05:44] <bkerensa> well I dont object... In fact I might welcome it especially if they are interested in collaborating on maintaining it
[05:44]  * jbicha points to the confusingly named Debian package http://packages.qa.debian.org/iceape
[05:45] <ajmitch> bkerensa: I told him to contact the mozilla team if he's interested in helping out
[05:47]  * micahg keeps getting mails about chromium
[05:47] <ajmitch> offers of help?
[05:48] <micahg> no, questions where people can get updates ;)
[05:48] <ajmitch> hah
[05:48]  * micahg should just say Debian unstable :)
[05:49] <micahg> we really need someone like fta :)
[05:49] <ajmitch> what, someone with lots of time & energy?
[05:50] <micahg> yes, and crazy computing power :)
[05:52] <jbicha> did Canonical ever fill that Webkit/Chromium job they were hiring for?
[05:53] <jbicha> I'm assuming not
[05:55]  * micahg doesn't see the opening on the website
[06:18] <micahg> xnox is going to be so happy that boost1.50 just landed in unstable :)
[06:18] <ajmitch> heh
[06:19] <ajmitch> so glad you found a willing maintainer ;)
[06:19]  * micahg never touched the stuff :)
[06:20] <ajmitch> you're missing out
[06:20]  * micahg will add it to his bucket list....
[06:20] <ajmitch> 101 easy ways to make you want to kick the bucket?
[06:21] <micahg> heh
[06:22] <bkerensa> micahg: the emails are probably my fault
[06:22] <bkerensa> >.<
[06:22] <micahg> bkerensa: I'm just glad it linked to my LP profile :)
[06:23]  * ajmitch still can't reach svn.webkit.org, it's rather odd
[06:23] <bkerensa> micahg: oh I wouldnt put anyones public e-mail
[07:04] <dholbach> good morning
[07:05] <ajmitch> hi dholbach
[07:06] <dholbach> hey ajmitch
[07:11] <bkerensa> gnight micahg ajmitch
[07:12] <ajmitch> night bkerensa
[07:12] <micahg> night bkerensa
[07:16] <dupondje> bdrung: there ? :)
[08:57] <AmberJ> Hello
[08:57] <AmberJ> Do I get it right that we do 'debuild -S -sa
[08:59] <AmberJ> *Do I get it right that we run 'debuild -S -sa' on the host system to create the source package (and do only 'pbuilder build file.dsc' inside pbuilder chroot)?
[09:00] <AmberJ> Do we only build inside pbuilder chroot? Or, are we supposed to create source package (using 'debuild -S') inside pbuilder chroot as well?
[09:01] <_ruben> do you dont do any chroot'ing yourself, the pbuidler command will do the building within a clean chroot environment, the source package indeed is built in the host system
[09:03] <AmberJ> yes, we don't do chrooting ourself.. but I thought maybe we are supposed to use
[09:03] <AmberJ> Damn RETURN key!
[09:04] <AmberJ> **yes, we don't do chrooting ourselves.. but I thought maybe we are supposed to use 'pbuilder --execute' to create source package inside pbuilder chroot as well
[09:04] <AmberJ> I just thought of confirming. Ok, I'll create source package on host system then. Thanks _ruben
[09:07] <tumbleweed> normally, building the source pa ckage doesn't actually require all the dependencies
[09:08] <tumbleweed> so it can easily be done on whatever you are running
[09:08] <tumbleweed> if it won't build, just disable cleaning (-nc) if you're are doing all your building in a pbuilder, that'll be safe to do
[09:23] <AmberJ> ok
[09:25] <AmberJ> And, if I have package from a Launchpad PPA as a build dependency, the preferred way to install it inside chroot is to use 'pbuilder --execute' to install package from PPA inside pbuilder chroot?
[09:27] <Zhenech> tumbleweed, clean should work (and be done) always, or you end up with a diff.gz that is unclean and refuses a new build when someone downloads it
[09:30] <tumbleweed> Zhenech: if you haven't done anything to make it dirty, it'll be clean
[09:30] <Zhenech> tumbleweed, but then -nc wouldnt be needed :)
[09:30] <tumbleweed> Zhenech: I don't follow
[09:33] <Zhenech> tumbleweed, rereading your sentence: you meant -nc when building *source*, not *binary*?
[09:33] <tumbleweed> yes, if you do all your binary building in a pbuilder
[09:34] <Zhenech> ok, my mind read *binary* at the first occurence too -.-
[09:34] <Zhenech> coffee please
[09:34]  * tumbleweed re-reads and sees it was totally unclear :)
[09:35] <Zhenech> two coffee then :)
[09:36] <tumbleweed> it's been a frustrating morning. international connectivity is crawling because a submarine cable is down :/
[09:37] <Zhenech> homeoffice today here, so rather chilly :)
[10:58] <bdrung> dupondje: now
[11:03] <dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/1018087
[11:03] <dupondje> got a patch for audacious
[11:04] <dupondje> want to do a fix in debian and then sync or?
[11:10] <bdrung> dupondje: the best way would to get the patch into upstream before getting it into Ubuntu through Debian (because audacious upstream is difficult and often complained about ubuntu patching bugs into it)
[11:11] <dupondje> bdrung: its upstream for 3.3.x
[11:12] <dupondje> https://github.com/audacious-media-player/audacious-plugins/commit/1957913f4857df0845ae7e15dadc93e38c248a0e
[11:12] <bdrung> dupondje: good.
[11:12] <dupondje> but its not clean imo
[11:12] <dupondje> it will break on GTK+ < 3.5
[11:13] <bdrung> hm
[11:13] <dupondje> they should keep the hack for GTK+ < 3.5
[11:13] <dupondje> but ok :p
[11:15] <Laney> add something like "#if !GTK_CHECK_VERSION(3,5,0)" then
[11:15] <bdrung> gtk 3.4 is in unstable, so we need an improved patch
[11:15] <dupondje> see http://redmine.audacious-media-player.org/issues/138
[11:15] <dupondje> I proposed a patch with GTK_CHECK_VERSION ...
[11:17] <Laney> oh well, maybe they want the stock behaviour
[11:18] <dupondje> Laney: applying their patch, will change the behavious for current users ...
[11:18] <dupondje> so
[11:18] <dupondje> its not preferred I guess :)
[11:19] <Laney> but you're only going to have it in quantal.
[11:20] <dupondje> Laney: depends if bdrung prefers to upload it first in debian :)
[11:20] <Laney> why would he do that when it definitely would change behaviour? and one day before the freeze.
[11:21] <bdrung> dupondje: it prefer debian first. i can do the upload if you give me a patch
[11:21] <bdrung> the patch should work for gtk < 3.5
[11:21] <Laney> sounds like you're poking upstream with a stick there
[11:21] <Laney> he explicitly refused that patch
[11:22] <dupondje> http://redmine.audacious-media-player.org/attachments/download/89/slider_fix.patch
[11:22] <bdrung> okay, then let's carry that patch in ubuntu
[11:23] <dupondje> upstream should get slapped
[11:23] <dupondje> breaking current behaviour for GTK+ <= 3.4
[11:24] <dupondje> so bdrung, just do it in ubuntu ?
[11:24] <bdrung> dupondje: upstream is not very packager friendly
[11:24] <bdrung> dupondje: yes
[11:24] <dupondje> i'll fix it then :)
[11:24] <bdrung> dupondje: can you state in the commit that this patch can be dropped in 3.3?
[11:25] <dupondje> sure
[11:44] <dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/1018087 could you upload it for me ? :)
[12:20] <dupondje> thx :)
[12:50] <ScottK> micahg: For backports, things like that are totally fine as long as it's an actual backport (fix it in the development release first).
[16:34] <PaoloRotolo> Hi all!
[18:44] <jbitcm-> hello can you help me to undestand how i can adopt a package
[18:47] <ScottK> jbitcm-: Ubuntu doesn't have a concept of package maintainers, so adoption is purely informal and something you do by just doing the work to keep the package in shape.
[18:48] <jbitcm-> ScottK, thanks for answer but now i have a pbuilder system and i want to help to package in ubuntu
[18:49] <ScottK> OK.  That's a much more general question.  My usual advice is to find bugs in things that you use and are bothering you and then see if you can figure out how to fix them.
[18:53] <tumbleweed> if you are looking for something easy to get started with: https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[19:14] <ScottK> ajmitch: boost1.50 just hit quantal (in Universe, not Main).
[19:14]  * ScottK waits for the twitch.
[19:33] <micahg> autosync FTW
[19:41] <Laney> ajmitch is The Boost Guy now?
[19:41] <ScottK> Definitely.  Him or xnox.
[19:42]  * Laney likes them apples
[19:42]  * ScottK too.
[20:19] <ajmitch> ScottK: micahg told me about 1.50 earlier. The responsibility has definitely passed to xnox
[20:20] <ScottK> Fortunately he doesn't hang out here, so he can't defend himself.
[20:22] <ajmitch> even better
[20:31] <AmberJ_> I'm trying to get extra packages installed in pbuilder.
[20:31] <AmberJ_> I'm using: sudo pbuilder update --extrapackages python-software-properties sudo
[20:31] <AmberJ_> But it won't install 'sudo' ... I'm sure I'm messing up with the format of command.
[20:32] <micahg>  --extrapackages [packages-to-add on pbuilder create]
[20:34] <AmberJ_> micahg: Do I need to add those square brackets as well?
[20:34] <micahg> AmberJ_: no, that just means it only works on create, not update
[20:34] <tumbleweed> but you can do anything you want with a pbuilder login --save-after-login
[20:35] <AmberJ_> micahg: Ah, that means I should use something like 'sudo pbuilder create --extrapackages PAC1 PAC2 ...' ... right?
[20:36] <xnox> Who has been talking about me, behind my back?!
[20:36] <xnox> ajmitch: ScottK ????
[20:36]  * ScottK whistles.
[20:36] <ajmitch> I wouldn't do a thing like that
[20:36]  * Laney wonders how information managed to leak out of this fortress
[20:37] <tumbleweed> he must have an informer
[20:37] <ajmitch> as long as he gets boost uploaded...
[20:38] <AmberJ_> tumbleweed: 'man pbuilder' says (about --login): "Only use this for temporary and debugging purposes." ... So I thought of staying away from --login
[20:39] <tumbleweed> AmberJ_: it's the easiest way to make changes to the chroots
[20:39] <micahg> pbuilder hooks are a good way to make temporary or per-build changes
[20:40] <xnox> It was discussed on the release team bug about boost1.49, that boost1.50 will be released in time, but there will not be another boost transition! It takes 2-3 months to do in Debian.
[20:41] <xnox> And I do not want more than one boost transition in a cycle, thank you very much.
[20:41] <xnox> =))))))))))))))))))))))))))
[20:41] <ajmitch> but they're fun
[20:41]  * micahg doesn't think we should have 2 versions of boost
[20:41] <xnox> well we currently, already do!
[20:41] <ajmitch> and it already causes issues
[20:41]  * micahg files for removal
[20:42] <xnox> 1.46 and 1.49
[20:42] <micahg> 1.46 is going away
[20:42] <xnox> well yeah.
[20:42] <micahg> and we're early enough for another transition
[20:42] <xnox> when are archive rebuilds scheduled for?
[20:43] <xnox> micahg: will boost1.50 bee blacklisted?
[20:43] <micahg> after DIF
[20:43] <xnox> cause I fear that loads of packages that do not link against boost, but use it's templates may FTBFS in funny gcc-4.7 kind of ways
[20:43] <micahg> xnox: well, if I file for removal, yes
[20:43] <xnox> micahg: please do ;-)
[20:44]  * xnox is busy packing the house for moving
[20:44] <micahg> ScottK: does this sound reasonable?
[20:44] <AmberJ_> ok, I'll try --login and hooks now..
[20:45] <ScottK> micahg: I think having 1.50 in Universe is OK.
[20:45] <ScottK> Some developers always want the latest boost, so it's good to provide it.
[20:45] <AmberJ_> Thanks micahg tumbleweed!
[20:45] <ajmitch> except when they build-depend on a package whcih depends on an older boost
[20:45] <ScottK> Yes.  Then it can get fun, but you can't have everything.
[20:45] <xnox> boost1.50 by itself is fine, as long as boost-defaults doesn't get switched with an autosync
[20:46] <ScottK> xnox: Exactly.
[20:46] <ScottK> Debian isn't changing the default now, so it's fine.
[20:46] <ajmitch> with debian freezing, I doubt that there'll be a switch to 1.50 there
[20:46] <xnox> but we can do the rebuilds easily if boost1.50 is in the archive
[20:46] <micahg> ok, well, it doesn't seem to get updated in stable anyways, so it can stay :)
[20:47] <xnox> simply have a ppa with boost-defaults switched to 1.50, build depend on that and voila rebuild environment ready
[20:47] <ScottK> Yep.
[20:47] <xnox> ajmitch: I have been killing packages that build-depend on versioned boost-dev libs.
[20:47] <xnox> ajmitch: I adjusted the tracker to take those into account. But maybe I need more
[20:48] <xnox> regexp/different tracker to kill all of those
[20:48] <ajmitch> xnox: just trying to recall if the problem I came across was something that was in the archive or not
[20:48] <ajmitch> upstream was using 1.48 features, anyway
[20:48] <xnox> ajmitch: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[20:49] <xnox> ajmitch: oh boost1.48 was funny. It was in the archive, but it never became the boost-defaults (not in ubuntu at least) as far as I can see
[20:49] <xnox> ajmitch: what is your launchpad id?
[20:49] <ajmitch> right, because it was transitioning in debian too late, causing too many issues
[20:49] <ajmitch> my lp id is ajmitch
[20:50] <xnox> for boost1.49 transition these are the remaining bugs: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=boost1.49
[20:50] <ajmitch> the situation with 1.48 is what we're talking about with 1.50 - get it in, but don't make it default
[20:50]  * ajmitch got suckered into patching boost one day to fix a python problem
[20:51]  * ajmitch blames ScottK for that one
[20:51] <ScottK> ;-)
[20:52] <ScottK> xnox: For packages that are actively maintained in Ubuntu, I think the versioned build-depends are fine.  Personally, I don't want to change boost versions by accident.
[20:54] <xnox> ScottK: actively maintained packages don't typically cause any issues. It's unmaintained stuff which causes the most amount of time
[20:55] <ScottK> Yeah.  I just mention it so you don't go overboard on killing off the versioned ones.
[20:55] <xnox> ScottK: I am actually very conservative, at least I think so....
[20:55] <ScottK> OK.
[20:57] <AmberJ_> How do you guys test your build inside pbuilder chroot if your build depends on Launchpad PPA?
[20:58] <AmberJ_> How do you tell pbuilder chroot to include the PPA as build depends?
[20:59] <xnox> AmberJ_: https://wiki.ubuntu.com/PbuilderHowto#Building_With_Local_Packages
[21:00] <xnox> AmberJ_: or you can do --login --save-after-exec
[21:00] <xnox> add the sources line, update / dist-upgrade
[21:00] <xnox> logout
[21:00] <xnox> and do your builds again
[21:00] <AmberJ_> Right thanks xnox.
[21:01] <AmberJ_> The wiki page link reminds me that I should read the whole wiki page first before asking questions!
[21:05] <xnox> ScottK: who does / did ubiquity Qt/KDE frontend?
[21:05] <ScottK> Various people over time.  Of the people that are still around, Ridell has done the most.
[21:06] <xnox> ok. I will ping him about LVM/LUKS stuff then
[21:07] <xnox> as far as I know I didn't break Qt frontend with my bits, but I didn't implement LVM/LUKS for Qt either
[21:21] <ScottK> My recollection is that cjwatson said foundations was going to do that (not you necessarily).
[21:21] <ScottK> It's critical for dropping the Kubuntu alternates.
[21:37] <xnox> I know
[21:38] <xnox> ScottK: It's just I only fiddled with pyqt for a couple of hours back in the qt3 time
[21:38] <xnox> and I don't know C++ / Qt
[21:38] <ScottK> It's PyQt/PyKDE anyway.
[21:39] <xnox> i can read C++ and I did many patches.... but I still claim that I have no formal knowledge of these technologies.
[21:39] <xnox> with gtk+ it's like: "huh?! why would you write this, when you can do this in a rather less complicated and more straight forward way"
[21:40] <xnox> but again, I am one of those people who loves and enjoys C *a lot*
[22:14] <Laney> xnox: 29/06 23:11:23 <rlb> fwiw, emacs24 has been uploaded to unstable
[22:16] <xnox> Laney: YEAH! =)
[22:16] <ajmitch> now that has to make it into precise-backports
[22:17] <xnox> Laney: can't find dsc
[22:17] <Laney> probably NEW?
[22:20] <xnox> Laney: can't see in NEW, nor incomming, nor the archive
[22:20] <Laney> Timestamp: 29.06.2012 / 22:00:06 (UTC)
[22:20] <Laney> want to bet it's there next time?
[22:22] <xnox> Laney: should we make emacs24 default in quantal?
[22:22] <Laney> I guess
[22:22] <ScottK> What's default in Wheezy?
[22:22] <Laney> depends on the rdeps I suppose
[22:22] <xnox> me, you, barry and loads of other people will be happy!
[22:22] <xnox> ScottK: emacs23
[22:23] <ScottK> Then we're on our own for updating rdepends.
[22:23] <ScottK> I'd investigate how much work that is before deciding.
[22:23]  * xnox runs emacs24 from the ppa with no trouble what's so ever
[22:23] <xnox> but then again i am a light user of rdepends
[22:24] <xnox> ScottK: there is an AppStore for emacs24 now, so if it isn't the default it should still be ok.
[22:31] <Laney> I suppose we should have it as a non-default option for a while.
[22:31] <xnox> Laney: are you going to snitch the dsc from new and upload it?
[22:32] <Laney> you can't get files out of new
[22:32] <xnox> =((((( incomming?
[22:32] <Laney> no
[22:32] <xnox> =(((((
[22:32] <xnox> ok
[22:32] <Laney> well, you can in general, but that doesn't work for new stuff
[22:32] <Laney> we'll just have to wait
[22:33] <xnox> patience is a virtue
[22:33] <Laney> I imagine it might sneak its way into wheezy
[22:33] <xnox> *grin*
[22:34] <xnox> good night everyone!
[22:34] <xnox> off to bed
[23:16] <AmberJ> Laters


[00:15] <goddard> juliank: thanks ill keep waiting
[15:54] <SonikkuAmerica> Is there a Unity 8 preview image for 16.04 LTS?
[23:04] <goddard> the ubuntu sdk in qt creator has a memory leak
[23:04] <goddard> it makes the IDE crash


[01:38] <charles1> I make my living full time running a computer store .. Ubuntu and Apple only ... no windows
[01:38] <charles1> are there any others doing this???