[09:18] <LocutusOfBorg> cjwatson, thanks https://answers.launchpad.net/launchpad/+question/703952
[09:28] <LocutusOfBorg> hopefully I didn't mess up with the ticket url
[12:36] <LocutusOfBorg> s390x workers are still "cleaning" since 2 hours...
[12:58] <jugmac00> LocutusOfBorg: Thanks for letting us know. I have reset the builders, and I will have an eye on them whether they will recover properly.
[13:11] <LocutusOfBorg> thanks!
[13:18] <LocutusOfBorg> jugmac00, I'm not quite sure that worked...
[13:18] <LocutusOfBorg> but with huge queues, who knows
[13:43] <cjwatson> it didn't, needs openstack repair.  I've opened the internal IS thread on this back up


[01:11] <CIA-59> ubiquity: cjwatson * r2818 ubiquity/ (debian/changelog ubiquity/filteredcommand.py):
[01:11] <CIA-59> ubiquity: Fix mysterious crash if a debconffilter doesn't get started for some
[01:11] <CIA-59> ubiquity: reason (LP: #125538).
[04:17] <CIA-59> usb-creator: evand * r12 usb-creator/ (7 files in 5 dirs):
[04:17] <CIA-59> usb-creator: * Properly set the labels of the progress dialog on install startup.
[04:17] <CIA-59> usb-creator: * Do not make the dialogs modal.
[04:17] <CIA-59> usb-creator: * Elevate privileges using gksu.
[04:17] <CIA-59> usb-creator: * Added a .desktop file (LP: #267788).
[08:13] <davmor2> is cdimages.u.c down?
[09:00] <cjwatson> 02:39 <MattJ> Is cdimage.ubuntu.com down intentionally?
[09:00] <cjwatson> 02:41 <james_w> MattJ: http://<IP_ADDRESS>/ should get you there
[09:00] <cjwatson> 02:41 <MattJ> james_w: thank you so much :)
[09:00] <cjwatson> 02:41 <james_w> only some of the servers behind cdimage are down, so going directly to one that isn't works
[09:17] <davmor2> cjwatson: ta :) Rsync still worked so I got the images I just need to see if they would work :)
[09:44] <soren> cjwatson: Are you familiar with di-live?
[09:44] <cjwatson> no
[09:44] <soren> https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002239.html
[09:45] <cjwatson> beyond a general awareness that they've gone down a road I investigated and decided was ultimately doomed
[09:45] <soren> Ah :)
[09:45] <cjwatson> er, hmm, this doesn't seem to be the same as the live CD stuff based on d-i
[09:46] <cjwatson> ok, in this case I'm actually not familiar with it at all, sorry
[09:46] <soren> These people have devised a system for creating live CD's for servery kinds of things, and then use this "di-live" thing to run the installer from that running system.
[09:46] <soren> It might be worth a look.
[09:47] <cjwatson> it looks fairly competently done
[09:48] <cjwatson> they've taken quite a similar approach to ubiquity in some ways
[09:49] <cjwatson> soren: yeah, I quite like the look of that. Certainly don't reject it out of hand
[09:49] <cjwatson> you could invite them in here
[09:49] <soren> Certainly.
[09:52] <soren> done
[10:02] <xivulon> cjwatson would it be feasible to avoid O_DIRECT flags in parted_server?
[10:03] <cjwatson> did upstream say they couldn't fix it to actually work?
[10:04] <cjwatson> we could make parted fall back from O_DIRECT to !O_DIRECT
[10:05] <cjwatson> we can't just drop it - it was added for a reason
[10:05] <xivulon> I have asked both szaka and cking but got no reply so far, szaka mentioned in the bug he would add it to the todo list, but I am not sure how long that will take nor if he means honouring O_DIRECT or ignoring O_DIRECT
[10:06] <xivulon> fall back will do!
[10:06] <cjwatson> that should be straightforward
[10:06] <cjwatson> I doubt it matters much whether it's honoured or ignored, for loopback
[10:07] <cjwatson> it just needs to be not rejected
[10:07] <cjwatson> (at least from parted's point of view; I can see why szaka might feel it's hard to do properly)
[10:07] <xivulon> that is what I asked him to do indeed
[10:08] <cjwatson> hmm, open(2) documents that some file systems may ignore it
[10:08] <cjwatson> sorry, may not implement it - and may fail with EINVAL
[10:08] <cjwatson> so maybe working around it in parted is actually the right thing to do
[10:12] <xivulon> I have opened bug #269947
[10:14] <cjwatson> something like http://paste.ubuntu.com/47108/ should do it
[10:18] <xivulon> looks good, I could test that tonight
[10:19] <cjwatson> I'll upload it once I've done some basic testing
[10:19] <xivulon> thanks a lot
[10:20] <cjwatson> oh, hang on, soren already disabled O_DIRECT altogether
[10:20] <cjwatson> soren: would a fallback not be better?
[10:20] <davmor2> Guys give me a ping when you have a working solution that I can test and I'll run it on all versions of windows :)
[10:20] <soren> cjwatson: That's what I started out with, but Jim Meyering thought otherwise.
[10:21] <soren> Well, actually some dude from SuSE though otherwise, and Jim agreed.
[10:21] <cjwatson> really? interesting. so in that case why is the bug still open? :)
[10:22] <soren> It's not.
[10:22]  * soren whistles
[10:22] <soren> bug 252684
[10:23] <cjwatson> I'll dup, thanks
[10:23] <soren> http://lists.alioth.debian.org/pipermail/parted-devel/2008-August/002392.html
[10:24] <soren> Sorry about the lack of paperwork.
[10:25] <cjwatson> davmor2: today's image should already have Soren's fix
[10:28] <davmor2> cjwatson: cool I'll see how things go then :)
[10:28] <davmor2> xivulon: has the latest wubi been included on the cd yet?
[10:37] <xivulon> should be rev 507
[10:37] <xivulon> check also that busybox is the right version (ubuntu6 if I recall correctly)
[10:38] <xivulon> yes busybox is there too
[10:41] <CIA-59> ubiquity: cjwatson * r2819 ubiquity/ (apport/ubiquity.py debian/changelog): Add /var/log/casper.log to apport-generated bugs.
[10:42] <xivulon> davmor2 all seems in order, please test
[10:42] <davmor2> xivulon: Np's I'll give it a whirl after I get some smoke tests out of the way :)
[11:31] <cjwatson> OK. If you have a casper branch (assuming it's just following trunk, and that you don't have any extra revisions on it), then please remove it and check it out again.
[11:32] <cjwatson> If you have a non-trivial branch with some unmerged revisions, then please talk to me and we'll get it sorted out
[11:39] <davmor2> cjwatson: I've got issues with the display of the new partition viewer on ubiquity
[11:41] <davmor2> I'll take an image of it after and post it somewhere so you can see what I mean.
[11:52] <davmor2> Hmmm an attempt to configure apt to install additional packages from the CD failed not good :(
[12:06] <exodos> hi, im trying to use ubuntu-installer to install hardy on xen domU
[12:06] <exodos> (as described in here: http://wiki.debian.org/DebianInstaller/Xen)
[12:07] <exodos> the problem is d-i partitioning is not working so I'm looking for a way around it
[12:08] <exodos> i started terminal, created partitions and filesystems, and mounted the rootfs on /mnt
[12:09] <exodos> is there a way do say d-i that partitioning is already done and it can proceed with base system installation?
[12:13] <cjwatson> yes, but with caveats
[12:13] <cjwatson> you'll need to mount it on /target, not /mnt
[12:13] <cjwatson> you will need to create /target/etc/fstab
[12:14] <cjwatson> with that in mind, edit /var/lib/dpkg/info/partman-base.postinst and put 'exit 0' on the second line
[12:14] <cjwatson> stuff might go wrong later; this is not a usual path ...
[12:14] <exodos> cjwatson: I will check that, thx a lot!
[12:27] <exodos> are there any plans for future to make d-i working under xen?
[12:32] <cjwatson> I thought it was mostly a matter of providing a suitable kernel, but honestly I know very little about it
[12:36] <alonswartz> soren: I'm one of the developers behind TurnKey Linux, and the author of di-live. I heard you had some questions so I thought I'd drop in here and say hi.
[12:55] <davmor2> cjwatson: Any idea why if you try installing ubuntu on the live cd directly (rather than through live session) you get the wrong theme?
[12:56] <davmor2> you get the default gnome theme (grey/blue bar etc)
[13:07] <davmor2> xivulon: Yay it worked :)  Wubi in XP installed :)
[13:13] <xivulon> davmor2 good news :)
[13:13] <xivulon> davmor2: couple of things to test a) install a new kernel b) see if suspend/hibernation works
[13:14] <xivulon> the latter was disabled, but it __might__ be that the 27 kernel supports suspending to a swap file
[13:15] <xivulon> you might to enable hibernation manually or run the underlying commands (let me have a quick look)
[13:26] <xivulon> apparently uswsusp can support hibernation to a swap file...
[13:30] <cjwatson> davmor2: I've noticed that it seems to be a sort of halfway house (it's not quite the default GNOME theme, I don't think, but it's certainly not ours either), but I don't know why
[13:31] <cjwatson> alonswartz: I don't have any specific questions about di-live (I've only had a chance to glance over it), but I noticed there was some inspiration from ubiquity there and it seemed to be rather well-written, so I thought you should be invited in here and that this would be the best place for discussions of it
[13:33] <alonswartz> cjwatson: thanks for the invitation, and compliment.
[13:34] <cjwatson> also in case there was anything you were stuck on ...
[13:34] <alonswartz>  Yes, I built heavily on ubiquities design in leveraging d-i code. I originally thought that I would patch ubiquity to support installation from the console, but when I got into the thick of things, I realized that the way to go was modular...
[13:35] <cjwatson> the reimplementation of main-menu is a nice idea; I did try that sort of approach originally for oem-config (whose general design grew into ubiquity) but found there were too many crossovers
[13:35] <cjwatson> actually, if I were doing ubiquity over again I'd probably take that kind of approach. The current ubiquity main loop came from Guadalinex' code and I was never very happy with it.
[13:36] <cjwatson> most of ubiquity's complexity is due to the requirement for a designed UI rather than one generated from the debconf protocol, though.
[13:36] <cjwatson> I take it you're just using debconf's dialog interface?
[13:37] <alonswartz> yes, i noticed that. I understand that ubiquity came out of the need for a GUI installer, it was just a pity that d-i got wrapped up in that
[13:37] <cjwatson> mm, I didn't want to maintain two partitioners. :)
[13:37] <alonswartz> hehe...
[13:37] <alonswartz> in the long run it would have been easier ;)
[13:37] <cjwatson> in fact there were a lot of things where I felt the, uh, business logic was the hard bit and I still feel it's worth not duplicating that
[13:38] <cjwatson> plus I like d-i and wanted to make use of it. :)
[13:38] <alonswartz> in the future, it might be an idea to consider seperating the GUI code from the d-i code for maintainance and modular reasons
[13:39] <alonswartz> re-using d-i code is definately the way to go
[13:39] <alonswartz> no point in re-inventing the wheel
[13:39] <cjwatson> I'd like to figure out a clearer way to do debconffilter. I think it's the right general approach but it's undeniably hard to program in. Maybe the problem is that it isn't really testable
[13:39] <cjwatson> (automatically)
[13:40] <cjwatson> or maybe the problem is that most programmers have trouble wrapping their heads around state machines
[13:41] <cjwatson> the reason it's interwoven is that there are lots of cases where we need to advance the d-i code just a little bit (rather than by a whole component) in order to figure out how to update the UI
[13:41] <cjwatson> the partitioner is the really obvious case, but e.g. keyboard configuration too
[13:42] <cjwatson> originally I wanted to do it by way of cdebconf custom widgets
[13:46] <alonswartz> its a really interesting concept - creating a debconf filter layer for interception (and possibly injection), but undoubtably complex
[13:49] <alonswartz> how did you perform testing, seems to me like a nightmare, especially if you say that auto-testing is out of the questions
[13:54] <cjwatson> unfortunately most of the testing I did was system testing, just plug it in, watch the debug information, and see if it's driving it the right way
[13:54] <cjwatson> I don't think auto-testing is out of the question, but I'm not very good at building test harnesses
[13:54] <cjwatson> the trick is figuring out how to isolate the d-i code, I think
[13:55] <cjwatson> and instrument the bits you can't isolate
[13:55] <cjwatson> we've managed successful unit testing of some small bits of d-i, like the kernel selection code in base-installer, but nobody's managed to build a test harness for the partitioner yet
[13:56] <cjwatson> the usual failure mode with debconffilter is that the d-i code heads off down some path you didn't predict
[13:56] <alonswartz> one of the barriers i found when coding di-live, was testing. Most of my testing was done in a segregated chroot, but testing the partitioner was done in a vm. I can only imagine the extra hurdles you had to jump over with the debconf filtering layer...
[13:59] <alonswartz> have you thought of any other approaches than the filtering layer ?
[14:01] <cjwatson> only custom widgets (i.e. "Type: timezone_map" in a templates file that invokes special debconf plugin, that sort of thing)
[14:01] <cjwatson> the problem with that is that it tends to involve substantial changes to the d-i code, and you end up basically copying and pasting chunks of it into the GUI plugin since it needs to do much the same job
[14:02] <cjwatson> so in the end I rejected that idea as not viable
[14:06] <alonswartz> i have not given GUI interaction much thought, but it seems like an interesting problem to solve, especially the priority of code-reuse
[14:14] <alonswartz> when performing the copy of the live filesystem, you use /rofs as the source. From what I understand you do this for "maximum reproducability" - have you considered adding the option of copying the overlay aswell ?
[14:17] <alonswartz> overlay = live overlay (with possibly a  white or black list)
[14:24] <cjwatson> I'm open to suggestions, but I've never seen a way to do it well
[14:24] <davmor2> xivulon: it's todays cd and seems to be the most up-to-date kernel suspend failed to restart
[14:24] <cjwatson> mostly people want to copy user-level customisations and such, and those aren't just a matter of copying the overlay in a desktop environment; the username is different, and gconf has a habit of embedding the username into its database as well
[14:25] <cjwatson> so it would have to be quite a sophisticated operation
[14:25] <cjwatson> it's possible that it would work better in serverland
[14:28] <alonswartz> its a feature that i plan on working on in near future for di-live. implementing it in serverland should be easier though.
[14:30] <alonswartz> besides for user customizations, did you come across any instability issues regarding certain live content that you *don't* want in the installed system ?
[14:32] <cjwatson> well, the thing to be careful of with copying the live overlay is that the user's quite able to change files in e.g. /usr
[14:33] <cjwatson> you definitely can't copy the whole overlay, because it includes the customisations made by casper to make the system bootable as a live CD; you don't want those on the installed system
[14:33] <cjwatson> so you have to be selective. The easiest way to be selective is just to copy things in /home
[14:34] <cjwatson> then what if the user upgraded a package from backports (not that uncommon) on the live CD, and used it? That could easily result in data in /home that the installed system can't read, unless you figure out how to copy everything except for casper's modifications
[14:35] <cjwatson> at some point of course you might decide that you don't care, but I didn't want to have to deal with the sort of wildly complicated bug report that this could result in
[14:35] <cjwatson> I figured KISS was the way forward :)
[14:37] <xivulon> davmor2 did it use to work on your machine/vm in 8.04?
[14:37] <alonswartz> i suppose it depends on what the objective of copying the live system state to the hard disk would be.
[14:38] <davmor2> xivulon: can't remember I think it worked on the intel based machine I'll try it on vista after and see
[14:38] <alonswartz> in the case of a server type appliance the user might want to test out the system live, maybe configure a database, install or configure a cms or what ever, and then decide thats what he wants. it would then be nice to have the option whether to install the vanilla system, or the customized system
[14:39] <cjwatson> right, I agree that the appliance case is very different
[14:39] <alonswartz> i suppose its a all or nothing situation, if the user installs packages, customizes configurations, etc. then you have to take all the data across
[14:39] <cjwatson> one approach would be to extend casper to be able to reverse all its modifications reliably
[14:40] <alonswartz> we have highly customized casper btw, so its not really an issue
[14:40] <cjwatson> oh, of course you also have to figure out how to reliably remove di-live itself from the target system; the ease of that depends on how many dependencies it has
[14:41] <cjwatson> in ubiquity's case we remove it using python-apt, which is easier since we know the state of the copied filesystem
[14:41] <alonswartz> nice catch, its on my todo list...
[14:42] <alonswartz> don't you do i diff of the installed packages and the manifest, or something like that?
[14:43] <cjwatson> we do a diff of two manifests
[14:44] <cjwatson> you could do it even if further packages had been installed if you were careful; only resolve problems by removing packages if those packages are in the diff between the two manifests
[14:46] <alonswartz> can you point me to the code that uninstalls ubiquity ?
[14:50] <cjwatson> yes, remove_extras in scripts/install.py
[14:51] <alonswartz> thanks ;)
[14:57] <alonswartz> it seems pretty involved. i was thinking of just passing a list of packages to be removed to apt in the target chroot - what am i missing ?
[14:58] <CIA-59> usb-creator: evand * r13 usb-creator/ (debian/changelog gui/usbcreator.glade scripts/install.py):
[14:58] <CIA-59> usb-creator: Work around a bug in syslinux wherein it can only find the configuration
[14:58] <CIA-59> usb-creator: file for the option labels in the root of the device.
[14:59] <cjwatson> alonswartz: robustness - if you do that and just one of them fails, apt may not remove any of the rest, or may leave the system in some kind of half-broken state
[15:00] <alonswartz> is their any reason it would fail? the system should be in prestine state, as its a direct copy of /rofs
[15:01] <alonswartz> and if it does fail, we could intercept the exception - which would then be a bug, and should be reproducable...
[15:04] <alonswartz> cjwatson: unfortunately i gotta run off to a meeting. it was great to finally meet you, and thanks for the informative chat. i'm sure we'll be chatting soon again...
[15:28] <davmor2> cjwatson: I thought the landscape-client was being dropped from desktop installs?
[17:44] <kirkland> cjwatson: fyi, i have tested the latest ISO, and mdadm/boot-degraded fix is verified \o/
[17:44] <cjwatson> excellent
[17:47] <kirkland> cjwatson: i just thought i'd note that, since I was unable to verify one small part of that, before publication of the updated package
[17:59] <Goosemoose> hey cjwatson. im picking up from last week. http://pastebin.com/d14f645a7 shows how the installer is failing when trying to join the domain using my script as part of late_command. the error is: Error: Unable to start daemon [code 0x00080018]. Is there some reason likewise wouldn't start? Should I try starting it manually even though it says it tried to start it?
[17:59] <cjwatson> Goosemoose: I'm honestly not sure how much I can help with this. I don't know likewise at all
[18:01] <cjwatson> Goosemoose: maybe putting 'mount /proc' at the start of your post_install_tasks script and 'umount /proc' at the end would help; it's possible /proc isn't mounted in the chroot at that point
[18:03] <Goosemoose> ok
[18:03] <Goosemoose> ill try that
[18:03] <Goosemoose> i cant find much on preseed and likewise on the forums at all
[18:03] <Goosemoose> I did get this as well: Sep 12 22:18:03 log-output: /target/etc/nsswitch.conf: No such file or directory
[18:04] <Goosemoose> as I was trying to remove the nsswitch.conf so I could wget a new copy. Does this just mean it hadn't been created by that point in the install process?
[18:04] <cjwatson> did you put /target/etc/nsswitch.conf in your post_install_tasks script, rather than /etc/nsswitch.conf?
[18:04] <Goosemoose> yes
[18:04] <cjwatson> you shouldn't have done that
[18:04] <cjwatson> put it back to /etc/nsswitch.conf
[18:04] <Goosemoose> oh, I thought you said everything was installed in the /target dir until reboot
[18:04] <Goosemoose> my mistake
[18:04] <cjwatson> and I also said that putting 'chroot /target' in front of the call to post_install_tasks was all you needed, and said several times that you shouldn't add references to /target to post_install_tasks
[18:05] <Goosemoose> ahh , very true. sorry about that
[18:05] <cjwatson> 'chroot /target /post_install_tasks' means, roughly, that everything in the post_install_tasks is implicitly done with reference to /target
[18:05] <cjwatson> so you don't need to, and shouldn't, refer to /target in there
[18:05] <Goosemoose> yeah i forgot I had changed to do that
[19:16] <cr3> what's that kernel parameter I could pass during installation of the alternate to interrupt the installation at some point, perhaps around early command?
[19:17] <cjwatson> I don't know of such a thing. You could make your early_command return an error :)
[19:21] <cr3> cjwatson: hm, I thought I recalled something of way to interrupt the installer but I guess there's not much use case for that... and there's an easy workaround as you pointed out :)
[19:23] <cr3> cjwatson: I wrote a nifty little program in C this weekend to check the log file for patterns which I will wrap in a shell script to test for specific phases of the installation
[19:23] <cr3> I'm quite anxious to try it out
[21:14] <Goosemoose> cjwatson, it looks like i got it to join the domain, who knows more about likewise though because it through a bunch of pam errors
[21:14] <Goosemoose> and wont let me login as a domain user
[21:44] <cr3> might someone have a good example of a project using autotools and packaged using cdbs both as a deb and a udeb?
[22:03] <hardwire> cr3: wireless-tools ?
[22:04] <hardwire> maybe not
[22:04] <cr3> hardwire: heh, doesn't use autotools nor cdbs :)
[22:04] <hardwire> I'm not on my game today.
[22:04] <hardwire> can't you query the source package lists via those fancy dpkg query tools?
[22:05] <hardwire> or grep
[22:06] <hardwire> cat /var/lib/apt/lists/*Sources | grep cdbs -B 10 | grep autotool -B 10 | grep Package
[22:06] <hardwire> maybe I'm insane
[22:06] <hardwire> I'd like to think it's a possibility
[22:06] <cr3> for some reason, DEB_DH_INSTALL_SOURCEDIR only applies to the deb which calls dh_install with --sourcedir but that argument is not used for the udeb
[22:11] <cr3> ok, so cdbs seems to be borked when using DEB_DH_INSTALL_SOURCEDIR. using DEB_DH_INSTALL_ARGS := --sourcedir=$(DEB_DESTDIR) seems to work
[22:17] <Goosemoose> cjwatson: Sep 15 17:38:12 log-output: /post_install_tasks: 14: unmount: not found
[22:17] <Goosemoose> cjwatson: looks like unmount /proc isn't valid. i don't see an error for the mount which is strange
[22:27] <evand> Goosemoose: shouldn't that be umount?
[22:27] <Goosemoose> evand, that might explain it ;)
[22:27] <Goosemoose> thanks
[22:28] <evand> no problem
[22:29] <Goosemoose> time to restart and try another network install
[23:15] <xivulon> wubi 8.10 seems ok now
[23:21] <cjwatson> hardwire: grep-dctrl is your friend
[23:21] <cjwatson> Goosemoose: likewise> don't know, you could try #ubuntu-server
[23:21] <hardwire> cjwatson: totally.. I totally forgot the command
[23:22] <Goosemoose> cjwatson, that's where im trying right now


[00:13] <_mup_> ensemble/robust-hook-exit r290 committed by<EMAIL_ADDRESS>[00:13] <_mup_> Refactoring, doc strings, and better comments wrt review
[00:49] <_mup_> ensemble/debug-log-relation-settings-changes r274 committed by<EMAIL_ADDRESS>[00:49] <_mup_> Merged trunk
[07:30] <kim0> Morning all
[08:47] <jamespage> morning
[08:47] <jamespage> what do I need todo to get the jenkins and jenkins-slave formulas into principia? (see bug 793735)
[08:47] <_mup_> Bug #793735: import jenkins formula <new-formula> <Ensemble Formulas:In Progress> < https://launchpad.net/bugs/793735 >
[08:52] <jamespage> SpamapS: still around?
[08:59] <SpamapS> jamespage: insomnia seems to have caught me tonight. whats up?
[09:00] <jamespage> SpamapS: hey - I wanted to move forwards with the jenkins* formulas - wondered what needed to be done to get them accepted into principia?
[09:01] <SpamapS> Ok, I went ahead and approved you for ensemble-composers
[09:01] <SpamapS> bzr push lp:principia/jenkins will work.. but bzr push lp:principia/jenkins-slave will run into the dreaded "no package exists" ug..
[09:03] <jamespage> SpamapS: thanks - I fake something in a PPA to work around that :-)
[09:03] <jamespage> cheers
[09:03] <SpamapS> sweeeet
[09:32] <jamespage> SpamapS: both branches now pushed...
[09:32] <SpamapS> jamespage: fantastic
[09:33] <jamespage> I'll prob do some further work on them when jenkins lands in Oneiric
[09:33] <SpamapS> I saw that you are just blocked on NEW! :)
[09:34] <jamespage> yep
[09:34] <jamespage> 6  packages pending and then its in
[09:51] <adam_g> SpamapS: any specific reason why default_storage_engine is set to innodb on install of mysql via the formula?
[09:52] <SpamapS> adam_g: because MyISAM is a piece of S*** that should die an unholy death. :)
[09:52] <SpamapS> Err, I'll rephrase ina positive light
[09:53] <SpamapS> Because every time an alter table converts to InnoDB from MyISAM, an angel gets his wings.
[09:53] <adam_g> hehe
[09:54] <adam_g> wondering if it might be better to install defaults via install hooks, and let users tweak via their formula configs
[09:57] <SpamapS> Yeah its probably a good idea to just make it the default
[09:57] <SpamapS> I did it at first when I was doing the master/slave stuff to make the snapshot simpler.
[09:58] <adam_g> ah
[10:00] <SpamapS> wtf are you doing awake?
[10:00]  * SpamapS should be sleeping too.. :-P
[13:18] <niemeyer> Good morning all
[13:21] <wrtp> hiya
[13:21] <niemeyer> wrtp: Hey!
[13:24] <wrtp> niemeyer: i was looking at laptops to run ubuntu on. any good recommendations?
[13:24] <wrtp> (i saw the canonical recommended laptop list)
[13:25] <niemeyer> wrtp: I like the thinkpad series, and it's fairly common within Canonical
[13:25] <wrtp> i've still got an old thinkpad which i really liked
[13:25] <niemeyer> wrtp: Got the T410 at the moment
[13:25] <wrtp> (T21 possibly)
[13:25] <wrtp> do they still have three mouse buttons and a nipple?
[13:26] <niemeyer> wrtp: That's the second one.. my last one lasted 4+ years
[13:26] <wrtp> mine *should* be still working except the display went dodgy
[13:26] <niemeyer> wrtp: The model I use have both the nipple and the trackpad
[13:26] <niemeyer> wrtp: I tend to pop the nipple out
[13:26] <wrtp> which is a pity. i ran plan 9 on it for years.
[13:26] <niemeyer> (context is everything! ;-)
[13:27] <wrtp> i like the nipple much better than the trackpad. good for chording.
[13:27] <wrtp> :-)
[13:27] <wrtp> i liked the fact that the display was 1400x1200
[13:27] <wrtp> but i doubt i'd get one similar now
[13:28] <niemeyer> Yeah, they're pretty good laptops overall
[13:28] <wrtp> battery life?
[13:28] <niemeyer> wrtp: I'm pretty sure they still exist
[13:28] <niemeyer> wrtp: Long.. still get 5h+ nowadays
[13:28] <niemeyer> wrtp: Got an SSD as well
[13:28] <wrtp> not bad. and what about the X series? are they much smaller?
[13:29] <wrtp> SSD only? or SSD + hard drive?
[13:31] <niemeyer> wrtp: SSD only
[13:31] <niemeyer> wrtp: They are generally smaller, IIRC
[13:31] <wrtp> i bet that makes things fast.
[13:31] <niemeyer> wrtp: Like 13" or less
[13:31] <niemeyer> wrtp: It does.. boot times are unbelievable nowadays
[13:31] <wrtp> ok. i think T series it is
[14:00] <jcastro> wrtp: the T410's and 420's seems to be popular at Canonical
[14:04] <wrtp> jcastro: thanks. BTW what's the difference between T410 and T420? the levovo web site does not seem to want to talk about the T410
[14:07] <jcastro> wrtp: the 420 replaces the 410
[14:07] <wrtp> oh, that's easy then :-)
[14:10] <wrtp> i can't believe that displays have got *smaller* since i last bought a thinkpad in 2003!
[14:14] <kim0> SpamapS: hmm we're being compared to cloudformations .. http://cloud.ubuntu.com/2011/06/so-what-is-ensemble-anyway/#comment-1635
[14:15] <kim0> I think cloudformations only launches a collection of machines and that's it .. it doesn't really manage them afterwards ?!
[14:26] <jcastro> wrtp: they make "s" series with higher res screens, they are hard to find and more expensive, search for 410s and 420s.
[14:26] <jcastro> kim0: wow, some of the comments in that article, heh
[14:39] <niemeyer> wrtp: Yeah, I'm not a big fan of the widescreen laptops either..
[14:40] <niemeyer> wrtp: But I guess everyone else has won. ;-)
[14:40] <hallyn> niemeyer: :(
[14:41] <wrtp> jcastro: s series are still only 900 vertical pixels. my old one was 1050...
[14:42] <wrtp> niemeyer: yeah. boo hiss. i like my vertical space. still i'll survive!
[14:44] <jcastro> yeah but it's like they all stopped making 4:3
[14:46] <hazmat> wrtp, the x220 is doing pretty nice by me, although i think there are some sandy bridge graphics updates that need onieric, i'm using classic no effects.. the x220 can take two ssd drives (msata, and regular), although the regular has to be a 7mm device. speed and battery life are both very nice
[14:46] <hazmat> the ips screen rocks as well
[14:47] <hazmat> they also sell an optional battery slice for the x220, which can extend battery life to the 20+ hr mark in addition to a 9-cell
[14:48] <hazmat> the 's' identifier on a series identifies switchable/discrete graphics afaik.. they do sell high quality ips screens on some models without the 's'
[14:48] <jcastro> hazmat: yeah I have an X220 and it's pretty awesome
[15:14] <hazmat> niemeyer, ping
[15:14] <niemeyer> hazmat: Yo
[15:15] <hazmat> i took a step back and lookedat what's needed to finish up security. there's a question, i'd like to get your feedback on.. do you have time for a voice chat?
[15:23] <niemeyer> hazmat: Not right now, I'm about to leave for lunch
[15:23] <niemeyer> hazmat: and some friends just arrived to have lunch with us (which is why it took a moment, sorry)
[15:23] <niemeyer> hazmat: But will be happy to talk after lunch
[15:24] <hazmat> niemeyer, nevermind, there really is only way to look at the problem.. i think i've got it worked out, thanks and enjoy
[15:24] <hazmat> i'll paste my internal dialogue later ;-)
[15:24] <niemeyer> hazmat: Cool.. I've started looking at your new security branch already, btw
[15:25] <niemeyer> hazmat: It worked this time
[15:25] <hazmat> niemeyer, re the question.. https://pastebin.canonical.com/50336/
[15:25] <hazmat> niemeyer, i'm going to add to the add_machine_state, add_unit_state to create otp principals and store the token directly on the relevant states
[15:27] <niemeyer> hazmat: Cool, I'll put some thinking on that after lunch.. now I really need to step out!
[15:27] <niemeyer> biab
[15:36] <_mup_> ensemble/expose-provider-ec2 r301 committed by<EMAIL_ADDRESS>[15:36] <_mup_> Assign the provider machine its machine id in the provisioning agent to simplify provider APIs
[15:36] <SpamapS> negronjl: ping?
[15:41] <robbiew> m_3: ping
[15:41] <_mup_> ensemble/expose-provision-machines r292 committed by<EMAIL_ADDRESS>[15:41] <_mup_> Merged trunk
[15:42] <_mup_> ensemble/expose-provision-machines-reexpose r301 committed by<EMAIL_ADDRESS>[15:42] <_mup_> Merged upstream branch expose-provision-machines
[15:47] <negronjl> SpamapS: pong
[15:53] <SpamapS> negronjl: wondering about your gem issue.
[15:54] <negronjl> SpamapS: testing a workaround now.  I'll let you know
[15:56] <negronjl> SpamapS:  successfully worked around the issue by packaging bundler into a .deb ( so no gem install anymore ).
[15:57] <negronjl> SpamapS:  however the issue with ensemble still persists.  we just found a fix around the issue.
[15:58] <_mup_> ensemble/expose-provider-ec2 r302 committed by<EMAIL_ADDRESS>[15:58] <_mup_> Remove direct passing of machine_id for EC2 provider implementation and fix incorrect usage of Instance instead of ProviderMachine
[15:59] <SpamapS> negronjl: heh.. it really is a bug in gem... it shouldn't expect a login environment.
[16:02] <robbiew> SpamapS: hey...do you have the link to that google doc we had in dublin, listing all the projects we wanted to work with, e.g. HotandHairy ;)
[16:02] <SpamapS> robbiew: I think jcastro and m_3 have it
[16:02] <robbiew> jcastro: ^^...can you share that with me?
[16:10] <jcastro> on it
[16:16] <wrtp> hazmat: thanks, that's useful
[16:16] <jcastro> robbiew: doc title is "Ensemble & Principia"
[16:16] <jcastro> I don't own the doc so it won't let me reshare it with you
[16:16] <robbiew> jcastro: thnx
[16:16] <jcastro> I can jet you a copy via mail though if you just want to read it
[16:17] <jcastro> also, all the hot and hairy ones I filed, and have a "hot" tag in lp
[16:17] <robbiew> jcastro: who owns the doc, sabdfl?
[16:18] <m_3> robbiew: hey
[16:19] <jcastro> robbiew: jono
[16:20] <jcastro> robbiew: he likely owns all the other messaging ones too, I'll send him a note to add you as an owner to all of them
[16:20] <robbiew> jcastro: ffs
[16:20] <robbiew> jcastro: send me the link
[16:20] <robbiew> I should be able to view it...not showing up in a search though
[16:22] <robbiew> m_3: nevermind...jcastro responded ;)
[16:22] <m_3> cool... yeah, I'm not the owner either
[17:11] <jamespage> jcastro: ep-lite rocks BTW
[17:12] <jamespage> sooo much lighter than etherpad - it even runs in a t1.micro
[17:16] <m_3> jamespage: are you using that standalone or as part of some other "conference" stack?
[17:17] <jamespage> m_3: so we setup etherpad for UDS - but it was hard and the package is pretty ugly
[17:17] <jamespage> I just tried out ep-lite - http://ec2-46-137-10-1.eu-west-1.compute.amazonaws.com:9001/p/pad-with-daviey
[17:17] <jamespage> really small footprint compared to etherpad
[17:17] <jamespage> really small
[17:17] <m_3> ep-lite should just require node and npm
[17:18] <jamespage> m_3: yep - that was pretty much it
[17:18] <m_3> awesome
[17:18] <jamespage> npm pulled the rest of the deps
[17:18] <jamespage> it can backend to sqlite or mysql
[17:19] <m_3> did you do a formula?  that's on my list for node apps
[17:20] <SpamapS> jamespage: what services does it use for data storage?
[17:20] <SpamapS> oh
[17:20] <SpamapS> should read the whole conversation before joining
[17:20] <jamespage> m_3: not yet
[17:21] <jamespage> m_3: would you mind if I had a go at one?
[17:21] <m_3> jamespage: sure man... go ahead
[17:21] <jamespage> m_3: ta
[17:22] <m_3> jamespage: I've got some node/npm boilerplate you're welcome to
[17:22] <jamespage> m_3: point me at it :-)
[17:22] <m_3> lemme get it into lp (in github at the moment)
[17:28] <jcastro> jamespage: oooh, very nice.
[17:28] <jcastro> jamespage: yeah the page made a bunch of performance claims, but I wasn't ready to believe it until someone tried it. Great to hear it's slimmed down though
[17:29] <jcastro> it'd be a heck of a nice formula to have handy for conferences, LUGs, etc.
[17:30] <jcastro> and would also be a nice demo one too, since you could just fire it up, give people  the url, and then people could play with it right there
[17:32] <m_3> jamespage: lp:~mark-mims/+junk/nodeapp
[17:33] <jamespage> m_3: ta
[17:34] <niemeyer> Yo!
[17:36] <m_3> niemeyer: hey
[17:36] <niemeyer> m_3: Hey Mark
[17:39] <niemeyer> hazmat: SO, in the paste you provided earlier, it's not clear to me what you mean with "OTP serialization directly to the relevant nodes"
[17:52] <hazmat> niemeyer, basically the otp principal.. creates a permanent named principal with credentials stored to the otp node, along with acl using the otp credentials, the otp principal can be serialized to give a path:otp_user:otp_password info that can be utilized to retrieve the permanent credentials
[17:53] <hazmat> niemeyer, in particular i'm saying that machine_state and unit states would have that otp serialization directly as part of their contents
[17:53] <niemeyer> hazmat: That's the bit I don't get
[17:53] <hazmat> this allows say the  provisioning agent to access it from the machine state and then launch the machine agent with it
[17:53] <niemeyer> hazmat: Wasn't the plan to have a location where these OTP details are managed?
[17:53] <niemeyer> hazmat: It sounds like you're saying that OTP will be spread around, but I'm not sure if that's the case.  Is it?
[17:54] <hazmat> niemeyer, right but the otp credentials themselves need to be passed between multiple processes, i thought it was just a one time transfer from the launching process to the launched process. but really its needed much earlier (at the cli time) so we can associate the proper acl to named principal on created nodes
[17:55] <niemeyer> hazmat: The OTP principle and the timing sounds fine.. I'm wondering about the organization of nodes
[17:55] <hazmat> niemeyer, the permanent principal that the otp stores is stored in only one place, the otp serialization (access to that permanent principal) is stored on the relevant domain object for an agent, so that the process launching the domain object can access it to pass along to the domain agent
[17:56] <niemeyer> hazmat: Hmm.. it sounded to me like having a location where these exchanges happen would be cleaner
[17:57] <niemeyer> hazmat: Otherwise we can't really tell at any given point in time which OTPs are unclaimed, for instance
[17:57] <niemeyer> hazmat: Without having to dig through node content
[17:57] <hazmat> niemeyer, the otp is gone after use, and the launching process should remove it from the state when launching the domain agent
[17:58] <niemeyer> hazmat: Yeah, the above comment take that into account
[17:58] <niemeyer> takes
[17:59] <hazmat> niemeyer, on phone with isp.. trying to resolve internet issues.. bbiam
[18:00]  * hazmat is over his isp.. time for a new one..
[18:01] <hazmat> Nicke, the unclaimed otps are those that still exist, the otp serialization on the domain state, is removed prior to the launch of the domain agent
[18:02] <hazmat> their is a defined location for the exchange the otp node itself, but that has an acl protection to only allow access to someone with the otp credentials
[18:03] <niemeyer> hazmat: Ok, so maybe I misunderstood what you mean there
[18:03] <niemeyer> hazmat: This makes it sound like otherwise, for instance: " the otp serialization (access to that permanent principal) is stored on the relevant domain object for an agent"
[18:03] <hazmat> the otp credentials are stored transiently on the domain state, so we can allow for the indirection nesc to reference the named principal during domain node creation, and so the process that will create the corresponding domain state agent to access it to pass along
[18:04] <hazmat> i originally was going to forgo this and just have the otp created by the launching process, but its needed much earlier by the cli to associate the acls
[18:04] <hazmat> to domain objects created by the cli
[18:04] <niemeyer> hazmat: Sorry.. I don't understand stil
[18:04] <niemeyer> l
[18:04] <niemeyer> hazmat: What I mean is this..
[18:05] <niemeyer> There's a machine node
[18:05] <niemeyer> /machines/machine-0
[18:05]  * hazmat nods
[18:05] <niemeyer> This node is protected by an ACL so that it can only be read by relevant parties
[18:05] <hazmat> and a corresponding /otp/otp-xyz node
[18:05] <niemeyer> Yes..
[18:06] <niemeyer> When that gets put in place, which protection is /machines/machine-0 taking, and what's inside /otp/otp-xyz?
[18:09] <niemeyer> hazmat: Lacking some interactivity.. maybe we should video?
[18:12] <hazmat> niemeyer, i disconnected again..  could you repeat last line?
 When that gets put in place, which protection is /machines/machine-0 taking, and what's inside /otp/otp-xyz?
 hazmat: Lacking some interactivity.. maybe we should video?
[18:13] <hazmat> niemeyer, these are my last comments not sure what got missed https://pastebin.canonical.com/50354/
[18:13] <hazmat> niemeyer, sure
[18:14] <niemeyer> hazmat: Ok, I think we're on the same page
[18:14] <niemeyer> hazmat: The point I was missing was really about the "the otp serialization (access to that permanent principal) is stored on the relevant domain object for an agent" comment
[18:15] <niemeyer> hazmat: It felt like the domain object itself (e.g. /machines/machine-0) was protected by the OTP, and the real password was within it
[18:15] <hazmat> niemeyer, okay.. so that get's removed effectively when the domain agent is launched.
[18:15] <niemeyer> hazmat: But the description in the paste clearly states otherwise, so it's all good
[18:15] <hazmat> niemeyer, cool
[18:15] <niemeyer> hazmat: What gets removed when the domain agent is launched?
[18:16] <hazmat> niemeyer, the otp serialization (otp_node_path:otp_user:otp_pass) on the domain state
[18:16] <niemeyer> hazmat: Ok, we're still out of sync apparently.. you mean the domain object (/machines/machine-0) is protected by the OTP?
[18:17] <hazmat> niemeyer, no.. but the domain object has the otp serialization in it, after the launch of the domain agent, that data is stale
[18:17] <niemeyer> hazmat: Why does it need it?
[18:17] <hazmat> niemeyer, the domain agent doesn't need the otp serialization in the state, but the process that launches the domain agent does so it can pass it to the domain agent
[18:18] <niemeyer> hazmat: Ahh, I think I get it, ok
[18:18] <niemeyer> hazmat: Nice, makes sense
[18:19] <niemeyer> hazmat: That was the confusion.. it sounded like the OTP was *protecting* the domain node
[18:19] <hazmat> niemeyer, yeah.. after i thought it about their really weren't any options to work around it.. we need the named principals referenceable from the cli at state creation time, by the time the system is getting around to launching the domain agent, its too late for most of the acl grants
[18:20] <hazmat> niemeyer, ah.. yeah. the otp is serialized in the domain node, and only protects the named principal in the otp node
[18:21] <hazmat> niemeyer, so i took a step back yesterday to try and figure out how many more branches and work are needed to get both identity and security policies activated.. being realistic its probably about 1.5 weeks.
[18:22] <niemeyer> hazmat: That's fine
[18:23] <niemeyer> hazmat: Things are looking good.. and I won't do anything else today before killing that review queue :)
[18:23] <hazmat> niemeyer, cool
[19:27] <niemeyer> hazmat: First review on https://code.launchpad.net/~hazmat/ensemble/security-connection-redux/+merge/69369 delivered
[19:27] <niemeyer> hazmat: We'll probably need a voice conversation on some of the topics there
[19:57] <_mup_> ensemble/expose-provider-ec2 r301 committed by<EMAIL_ADDRESS>[19:57] <_mup_> Recover from bzr error
[19:59] <_mup_> ensemble/expose-provider-ec2 r302 committed by<EMAIL_ADDRESS>[19:59] <_mup_> Merged trunk and resolved conflicts.
[20:02] <jimbaker> So much for that attempt... argh, the only thing worse than a complicated conflict is bzr breaking down
[20:02] <jimbaker> (in addition to the conflict!)
[20:05] <niemeyer> jimbaker: How's it breaking down?
[20:05] <jimbaker> niemeyer, lost some of its metadata
[20:05] <niemeyer> Huh
[20:06] <jimbaker> i can recover the diff, but this is the context of merging upstream and resolving all the conflicts that was generated with the recent provider refactoring
[20:07] <niemeyer> hazmat: ping
[20:07] <niemeyer> hazmat: Not sure if your connection is flaky still, or if you're off
[20:09] <hazmat> niemeyer, back, its been flaky still, should have a new isp on monday though
[20:10] <niemeyer> hazmat: Cool.. not sure if you got this:
 hazmat: First review on https://code.launchpad.net/~hazmat/ensemble/security-connection-redux/+merge/69369 delivered
 hazmat: We'll probably need a voice conversation on some of the topics there
[20:11] <hazmat> niemeyer, nope i didn't thanks for the replay
[20:11] <niemeyer> hazmat: Oh my..
[20:11] <jimbaker> i hate to do this, but i'm going to break the commit into two pieces this time (the merge AND the conflicts)
[20:11] <niemeyer> hazmat: I think I messed up something
[20:12] <niemeyer> hazmat: Feels like I already reviewed security-policy-rules
[20:12] <niemeyer> hazmat: Hmm.. the connection-redux branch probably had it embedded
[20:12] <hazmat> niemeyer, yeah.. there are a pre-requisites on all the merge proposals
[20:13] <niemeyer> hazmat: Ok.. I'll copy over the review..
[20:13] <niemeyer> hazmat: Feel free to address specific points on the respective branches.
[20:13] <niemeyer> hazmat: This way you can merge stuff faster
[20:14] <_mup_> ensemble/expose-provider-ec2 r301 committed by<EMAIL_ADDRESS>[20:14] <_mup_> Merged upstream expose-provision-machines-reexpose (conflicts later)
[20:16] <niemeyer> hazmat: Alright, I think I fixed the mess
[20:16] <hazmat> niemeyer, your point #8 on security-connection bears some thinking about
[20:16] <hazmat> that's definitely got some implications for the rest of the approach
[20:16] <niemeyer> hazmat: security-policy-rules is the one that requires conversations
[20:16] <hazmat> niemeyer, yup
[20:16] <niemeyer> hazmat: security-connection-redux is back in review with a +1
[20:16] <hazmat> niemeyer, cool
[20:17] <niemeyer> hazmat: Only minor points there
[20:18] <hazmat> niemeyer, re why #2 on connection, the reason for the mixin is to ease testing, ssh conn requires ability to ssh into local host non-interactively.
[20:18] <hazmat> to test based on usage
[20:24] <niemeyer> hazmat: It can be a base then, and live within the same package
[20:25] <niemeyer> hazmat: Multiple-inheritance, separate packages, mixins.. feels like a lot for overloading a method
[20:26] <hazmat> niemeyer, sounds good, i'll probably end up with a second mixin to have policies active b4 we have transport level security for intra-environment communications
[20:26] <hazmat> er. second connection class using the mixin
[20:28] <niemeyer> hazmat: You don't need to have a second class using the mixin.. Just use that same base
[20:28] <hazmat> niemeyer, ah.. base, right, yeah.. that makes more sense
[20:29] <niemeyer> hazmat: Yeah ZK => SZK => SSHSZK
[20:29] <hazmat> SZK name is a bit of misnomer.. since its not transport level.. if you have an idea on rename.. i'm all ears. i was thinking PolicyConnection.. but that sounds strange as well.
[20:45] <_mup_> ensemble/expose-provider-ec2 r302 committed by<EMAIL_ADDRESS>[20:45] <_mup_> Resolved text conflicts, but some merge problems remain
[20:46] <niemeyer> hazmat: That wasn't a naming suggestion :-)
[20:46] <niemeyer> hazmat: Just illustrating the inhertiance
[20:47] <niemeyer> hazmat: Hmm
[20:47] <hazmat> niemeyer, understood, just making a naming request additional to that
[20:47] <niemeyer> hazmat: PolicyConnection?
[20:48] <hazmat> niemeyer, yeah.. i guess that makes as much sense.. it just felt strange
[20:48] <niemeyer> hazmat: RuledConnection :-)
[20:49] <hazmat> TheOneRing with s/connect/wear, doc string.. "And in the darkness bind them"  ;-)
[20:49] <hazmat> yeah.. policyconn sounds good
[20:59] <_mup_> ensemble/states-with-principals r298 committed by<EMAIL_ADDRESS>[20:59] <_mup_> a new method to OTPPrincipal, that creates a principal, adds it to token db, and returns the otp serialized data in one shot, also a general reuse test function to enable otp cleanup from tests that may encounter them.
[21:05] <_mup_> ensemble/expose-provider-ec2 r303 committed by<EMAIL_ADDRESS>[21:05] <_mup_> Added missing machine_id settings to mocks in test_launch
[21:07] <hazmat> niemeyer, the only place we really need topoloy data for things that might not be in the topology is the unit, since we need to retrieve the service
[21:08] <hazmat> niemeyer, we could remedy by just putting the service in the initial data for the unit node
[21:08] <hazmat> although that would change the rule interface to make them content based..
[21:08] <_mup_> ensemble/expose-provider-ec2 r304 committed by<EMAIL_ADDRESS>[21:08] <_mup_> Fix mock tests around the merged ProviderMachine
[21:08] <hazmat> perhaps a slippery slope
[21:09] <niemeyer> hazmat: Not sure I get what you mean.. there are more cases of topology being used for things that might not be in the topology in that branch
[21:09] <hazmat> niemeyer, most/all of the other use is for relations
[21:11] <niemeyer> hazmat: Yeah.. but e..g.
[21:11] <niemeyer> hazmat: How can you assign permissions to /relations/relation-10 based on the users of this relation, given that the id was just created?
[21:11] <hazmat> niemeyer, yeah.. the relation top level node also needs some consideration
[21:12] <niemeyer> hazmat: The path doesn't even include the sequence number!
[21:12] <hazmat> niemeyer, it could also be addressed the same way, using content
[21:12] <hazmat> as part of the rule interface
[21:13] <niemeyer> hazmat: Using content in what sense?>
[21:14] <hazmat> yeah.. as i noted in the mp.. i regard that branch as the most incomplete of the bunch.. its definitely going to need more work.. i just wanted to get more discussion ont he approach
[21:14] <hazmat> niemeyer, node data
[21:14] <hazmat> niemeyer, for a relation including the services and their roles.. for the unit node including its service
[21:15] <hazmat> the rule could then dispatch both on path and content, which as you correctly point out is needed for any sequence node acl to be contextually aware
[21:15] <niemeyer> hazmat: Do we have that data there today?
[21:16] <hazmat> niemeyer, not in the relation-id node.. we do have them in the role container node below
[21:16] <hazmat> most of the domain object nodes are empty nodes at create time
[21:17] <hazmat> machines, units, relations, etc.
[21:17] <niemeyer> hazmat: It feels awkward to be sending data to zookeeper to fix a deficiency in our API
[21:18] <hazmat> niemeyer, its effectively just identity storing identity information on the relevant domain nodes.
[21:18] <niemeyer> hazmat: It's storing data in zookeeper in a place that is not necessary, besides for fixing a deficiency in our API
[21:19] <niemeyer> hazmat: It's indeed a slippery slope..  I'd like to take a step back and ponder for a while about possible approaches that avoid that kind of cross-dependency entirely
[21:19] <hazmat> niemeyer, well.. we can choose not to store it ;-)
[21:19] <niemeyer> hazmat: LOL
[21:21] <_mup_> ensemble/expose-provider-ec2 r305 committed by<EMAIL_ADDRESS>[21:21] <_mup_> Fixed remaining mocks in ec2 provider tests
[21:21] <hazmat> one of the other nice things i like about the policy rule approach, its very easy to apply the acls to an entire tree, or diff a tree and see if there acls missing/etc, or do an upgrade on them en mass. its just a tree walk reusing the same rule interface
[21:22] <hazmat> niemeyer, in some sense the api we have right now is the strange, one we have domain objects with no identity information, because we store identity in a secondary index, but the object in isolation lacks any context.
[21:23] <hazmat> i'll think about alternate approaches and we can revisit, i should continue on with the identity work
[21:24] <niemeyer> hazmat: That's not entirely true
[21:24] <niemeyer> hazmat: The object owns its identity, and there is context about what is there in most contexts
[21:25] <niemeyer> hazmat: The "secondary index" is not an index, but a relationship description
[21:28] <niemeyer> hazmat: that's also interesting, because what is being looked for is not information about the domain object either, but about its relations
[21:29] <niemeyer> Well, for units that's not true
[21:43] <_mup_> ensemble/expose-provider-ec2 r306 committed by<EMAIL_ADDRESS>[21:43] <_mup_> Pass through machine data to DummyLaunchMachine.start_machine to fix common tests
[21:52] <niemeyer> hazmat: Btw, _very_ nice break up of branches
[21:52] <niemeyer> hazmat: Thanks a ton for that
[21:52] <niemeyer> It'd be crazy otherwise
[21:52] <hazmat> niemeyer, np... hoping to continue that with the rest of the work
[21:53] <niemeyer> hazmat: I'm getting to the end of the pile.. it feels like that issue we're both brainstorming on is the only critical..
[21:53] <niemeyer> hazmat: Let's think some more on that and tomorrow we can catch up for a decision
[21:53] <hazmat> niemeyer, yeah.. i'm going to think about it some more, we should reconnect about it tomorrow.
[21:53] <niemeyer> hazmat: +1 :)
[21:56] <hazmat> niemeyer, re identity its not true for units or relations nodes, they only have identity with the topology, and those are both the ones the topology gets consulted by the rules for.
[21:58] <niemeyer> hazmat: The _identity_ is the node name..
[21:58] <hazmat> niemeyer, unit-000000 ? relation-00000? without consulting the topology.. the unit doesn't know it services, nor the relation it services.
[21:59] <hazmat> its
[21:59] <niemeyer> hazmat: Exactly.. it doesn't know its relationships..
[22:00] <hazmat> niemeyer, its more than just relationships.. although arguable the relationships are lending identity here.. but for example the unit doesn't even know its name
[22:00] <niemeyer> hazmat: A bit like saying that the identity of /home/hazmat is in /etc/passwd..
[22:01] <niemeyer> hazmat: There's information in there about it, but it stands on its own
[22:01] <hazmat> niemeyer, but i know hazmat is the user name just from the path.. in the case of units.. the name itself is unknown
[22:01] <niemeyer> hazmat: hazmat is your id.. like unit-000000
[22:01] <niemeyer> hazmat: Your name is K.T.
[22:01] <niemeyer> hazmat: and is in /etc/passwd
[22:02] <niemeyer> hazmat: This is another thing I'm wondering about that.. it's not clear why we're using the service name rather than the id on the ACLs
[22:02] <hazmat> niemeyer, we probably should be using the id everywhere for acls
[22:03] <hazmat> niemeyer, i started doing that when i was working on machines more recently.. the machine_state.id == 0, 1, 2.. is not particularly useful in this context for identification
[22:03] <hazmat> er. internal_id everywhere
[22:04] <niemeyer> hazmat: Uh.. why not?  It's effectively the same thing?
[22:05] <hazmat> niemeyer, because the acl is a global namespace of principals, we should be able to identify a principal from its name, names like '0', '1', are rather ambigious compared to 'machine-xyz'
[22:05] <niemeyer> hazmat: Gotcha
[22:06] <hazmat> niemeyer, and in the case of service names, we don't prevent service name reuse
[22:06] <niemeyer> hazmat: Either way, "0" in this context is akin to "wordpress/2" for a unit name.. it's really oriented for users
[22:06] <hazmat> yup
[22:06] <niemeyer> hazmat: When we're handling it internally, internal_id is good
[22:12] <hazmat> hmm.. hard to store the otpprincipal data on the domain state with a known principal name against a sequence node, the name is ..
[22:13] <hazmat> perhaps an additional topology index matching domain objects to principal names
[22:16] <niemeyer> Yeah.. trying to lock the drawer with the key inside
[22:17] <niemeyer> hazmat: Actually, not really.. what's the actual issue?
[22:17] <niemeyer> hazmat: The otp just needs to be created beforehand
[22:17] <niemeyer> hazmat: so that the name may be stored within the domain node, if I get what you mean
[22:20] <niemeyer> Okay.. I'm heading to a dinner with a friend that is in town.  Will be happy to talk about these details tomorrow morning.
[22:24] <hazmat> niemeyer, the otp creates a named principal, typically that should correspond to the identity of the domain object, but for sequence nodes, identity is rather ambigious.
[22:24] <hazmat> i could just use random names based on type...
[22:25] <hazmat> and store in the topology, but then the lookup process for the identity token is complicated
[22:47] <hazmat> easier for sequence nodes to just be updated with acls post creation
[23:39] <jimbaker> negronjl_, i need to do some additional refactoring and docs on robust-hook-exit branch per the review. then i can merge it into trunk
[23:39] <negronjl_> jimbaker: thx I appreciate it
[23:41] <jimbaker> negronjl_, np. occasionally these branches prompt some appraisal that there's too much previous tech debt, so that's why it's taking some additional time
[23:53]  * SpamapS thinks the only tech debt that is troubling is all the hoops we jump through marked "Twisted"
[23:58] <jimbaker> SpamapS, i think the attention we are paying to move to deterministic tests is a good one, but it is hard to do for sure
[23:59] <jimbaker> it was so much easier to just write tests that would simply sleep 200 ms and sweep the problems under the rug


[13:22] <xnox> Laney, pitti: may i inquire about the bug #1615039
[13:23] <xnox> i have a merge done, testing at the moment, but i'm ready to upload it. Thinking to block it in proposed for a little while to see the fallout.
[13:23] <xnox> some say that cdimage infra and some such may blow up.
[14:07] <tjaalton> infinity: looks like I'm not attending the sprint, so any lts discussion would have to be online :)
[14:08] <apw> xnox, that sounds like the sort of breakage that won't be detected in -proposed ?
[14:11] <Laney> xnox: Might want to do it closer to the start of a cycle than the end?
[14:11] <Laney> Unless you have a very good idea of what might break and how to fix it
[14:12] <cjwatson> (and if you do, I'd like to know how to noninteractively delete a secret key using gnupg2, for test suite purposes ...)
[14:18] <xnox> Laney, all packages in the archive are fixed to deal with gnupg2 and our gpg-agent.service is solid (unlike debian's)
[14:18] <xnox> Laney, we already see syncs in 16.10 with versioned breaks that assume that gnupg2 -> gnupg migration has happened.
[14:20] <xnox> Laney, i don't know where gpg in invoked, and if that will affect anything.... launchpad signs things by itself. Somebody mentioned that livecd building may be using gpg for some things... but i'm not sure if that is happening in yakkety chroot or not.
[14:20] <xnox> ditto cdimage, i thought it's doing everything on the host and not inside chroots.
[14:26] <xnox> cjwatson, good question
[14:28] <jbicha> it feels a bit broken that seahorse in xenial suddenly uses gpg2 (only) so running gpg from the command line and running seahorse show different results
[14:29] <jbicha> (of course, the gnupg2>gnupg migration in yakkety doesn't help xenial)
[14:30] <seb128> is that a recent change in xenial due to a SRU?
[14:30] <jbicha> no, it was like that on release
[14:31] <seb128> k, I didn't parse what you wrote correctly then
[14:35] <cjwatson> xnox: snapd uses gpg1 because AFAICT this problem cannot be handled sanely in gpg2 as it stands ... (but seriously, don't spend huge amounts of time on it, I wasted half a day and gave up)
[14:35] <cjwatson> (but snapd can cope with the gnupg2 -> gnupg migration having happened, I was careful)
[14:36] <cjwatson> and yes, LP/cdimage does all the signing in the fixed base system and won't immediately be affected by a change in yakkety, AFAIK
[14:37] <xnox> cool.
[14:42] <Laney> xnox: there you go
[14:43] <xnox> cjwatson, gpg2 --batch --yes --pinentry-mode loopback --delete-secret-and-public-key 0x28E7DEFB99F919E1145F18F381565D68A1290D19
[14:44] <xnox> works... but public key is gone too.
[14:44] <xnox> so if you want to keep public key, export it first, stash, and re-import just public key.
[14:46] <cjwatson> xnox: --pinentry-mode loopback didn't work for me
[14:46] <cjwatson> I forget the exact details but I did try that and IIRC the error message was something like that the loopback mode was disabled
[14:46] <xnox> horum.
[14:48] <apw> isn't the public key in the normal place, and the secret key in its own per key file, you might be able to just remove those directly (what could go wrong)
[14:50] <cjwatson> ... yeah, um, not doing that.
[14:51] <xnox> apw, still cached in the agent, so one needs to kill the agent too.
[14:51] <cjwatson> even if I thought it would get past review which it wouldn't :)
[14:51] <xnox> but yeah rm private_keys-v1.d/*.key works
[14:51] <xnox> (i made typo above, for sake of people not copy & pasting)
[14:52] <apw> cjwatson, i truly hope not indeed :)
[14:55] <bdmurray> arges: Could you have a look at my livecd-rootfs upload in the Xenial queue?
[14:56] <arges> bdmurray: sure
[14:58] <apw> xnox, i am supprised --delete-secret-keys <fingerprint> --yes doesn't work from teh manual, but i assume that has been tested
[15:00] <xnox> yeah.
[15:04] <xnox> cjwatson, gpg --batch  --delete-secret-and-public-key $fingerprint </dev/null seems to work in debian sid chroot with gpg 2.1.14, and matching gnupg-agent
[15:05] <xnox> gpg --batch  --delete-secret-key $fingerprint </dev/null
[15:05] <xnox> too
[15:05] <cjwatson> when I tried that I'm pretty sure I got a pinentry prompt, but I'll try again at some point, thanks.
[15:06] <xnox> yeah, i get pinentry prompts or errors here on ubuntu desktop with gnupg 2.1.11
[15:11] <apw> cjwatson, some documentation implies --yes will prevent pinentry on that batch delete, though our version does not mention it
[15:12] <cjwatson> yes, the docs said that but they appeared to lie based on my experience + reading of the source
[15:12] <cjwatson> you are now about half an hour into my four-hour rabbit hole the other day :-)
[15:13]  * apw self flagilates
[15:15] <xnox> cjwatson, have you ever seen this before? http://paste.ubuntu.com/23116380/
[15:15]  * xnox has reconstructed chroots already, and there is nothing special in my schroot/sbuild
[15:15] <cjwatson> xnox: afraid not
[15:16] <cjwatson> isn't ESTALE mostly an NFS thing?
[15:16] <xnox> true. but i don't have any NFS....
[15:56] <jbicha> could fcl/armhf please be removed (Debian did this too) since it's holding up the tinyxml2 transition
[16:00] <LocutusOfBorg> bug #1617835
[21:29] <doko> gave back failed packages in -proposed. at least four now built and migrated
[21:43] <ginggs_> thanks doko - i received some mails about packages that still failed - btw how much do we care about things already in yakkety that ftbfs with gcc 6? e.g. LP: #1619035
[21:46] <doko> ginggs_: I'm usually fine with such requests, but would like to wait until that migrated to testing
[21:47] <doko> just to make sure we have a somehow clean migration
[21:48] <ginggs_> ok, thanks
[22:31] <bdmurray> slangasek: Could you merge https://code.launchpad.net/~mterry/ubuntu-archive-tools/phablet-teams/+merge/303163
[22:35] <slangasek> bdmurray, mterry: what's the reason for the switch from -bugs to -team? someone is eager to be overwhelmed with bug mail? :)
[22:38] <slangasek> I suppose since unity-api-bugs has no remaining members except for the two of us, a change of some sort is needed there
[22:41] <bdmurray> slangasek: the -team teams already exist and were subscribed to packages as it was, so to eliminate confusion.  People were submitting mirs with -team subscribed and didn't know about -bugs.
[22:41] <slangasek> right
[22:41] <slangasek> so as long as they're all happy with the resulting bug mail, that's fine
[22:42] <slangasek> (merged)
[22:42] <bdmurray> thanks


[18:01] <pavlushka> zaki: o/
[18:01] <u-la-la> pavlushka: 2019-09-07 - 23:01:56UTC <zaki> tell pavlushka :D
[18:01] <pavlushka> XD
[18:01] <zaki> hey pavlushka
[18:01] <pavlushka> hello
[18:02] <pavlushka> got your mail, nice
[18:20] <zaki> you can edit that xcf file
[18:21] <zaki> pavlushka, ^
[18:21] <zaki> edited it to put on door
[18:28] <pavlushka> zaki: sure, thanks and good night :)


[08:40] <Fudge> does the old f5 accessibility boot option still enable the accessibility profile for precise?
[21:35] <TheMuso> Fudge: Yes.
[21:36] <TheMuso> But I'd like us to get rid of that menu by the next LTS.
[21:36] <TheMuso> Because it will be easier to activate the profiles once the CD boots and ubiquity is running.
[22:12] <Fudge> TheMuso  I agree, Bill_T was using it last night and kept on having problems and no sound, when he Control S'd it was fine but daily from 28th crashed on ubiquity.
[22:38] <Fudge> the menu does offer more of a fail safe for those who do not get sound to hear the drums
[22:39] <TheMuso> Right.