=== mjohnson15_2 is now known as mjohnson15
[00:23] <xibalba> know of a way to firewall a shell user on aa system? say i give you a shell on my box / 192.168.1.51. i dont want you accessing my home network at 192.168.0.0/24 but i , from my reza account, want ot be able to hit my home network
=== freeflying is now known as freeflying_away
[00:24] <Patrickdk> I can't remember if that is still supported with iptables or not
[00:24] <xibalba> i wonder if the ol' tcpwrappers could do it
[00:25] <Patrickdk> only if every program they used was build with tcpwrappers support
[00:25] <sarnold> xibalba: no, tcpwrappers is a voluntary deal, it wouldn't be a very good firewall
[00:25] <xibalba> ok
[00:25] <sarnold> xibalba: iptables --uid-owner is probably what you;re looking for, I've never tried it though.
[00:25] <xibalba> thanks i'll take a gander
=== thomi_ is now known as thomi
=== freeflying_away is now known as freeflying
=== peter is now known as Guest12214
=== marrusl is now known as marrusl_afk
=== marrusl_afk is now known as marrusl
=== gfrog_afk is now known as gfrog
=== freeflying is now known as freeflying_away
[09:15] <makara> i want to keep revisions of conf files
[09:15] <makara> i've read of RCS
[09:15] <makara> apparently the syntax is cumbersome
[09:15] <makara> just looking for something simple and local
[09:28] <jamespage> zul, urgh - the webob update that just trickled through busted nova
=== gfrog is now known as gfrog_meeting
[09:52] <makara> how can I measure the bandwidth savings that my squid proxy cache has provided?
[09:54] <makara> and is it possible for to get squid hooked up to avahi (like squid-deb-proxy) so I don't have to reconfigure my browser settings every time I come to the office?
[09:57] <makara> (i can't configure it as a transparent proxy)
[09:57] <yolanda> jamespage, i'm looking at the heat failure, missing a build-dep
[09:58] <jamespage> yolanda, yep - wanna propose a branch for that?
[09:58] <yolanda> sure
[10:01] <jamespage> yolanda, it might not build after that - webob just bumped version which is causing test failures as requirements < 1.3 in most projects
[10:01] <jamespage> but please do try :-)
[10:01] <yolanda> ok, trying now
[10:04] <yolanda> jamespage, it built!
[10:05] <jamespage> yolanda, if you wanted a bit of SRU practice: bug 1250654 looks like a good bit sized one
[10:05] <uvirtbot> Launchpad bug 1250654 in python-keystoneclient "memcache key length error " [High,Fix released] https://launchpad.net/bugs/1250654
[10:07] <yolanda> ok
[10:08] <yolanda> jamespage https://code.launchpad.net/~yolanda.robla/heat/icehouse_add_lockfile/+merge/198699
[10:08] <jamespage> yolanda, niggle but please leave the changelog entry as UNRELEASED  - and add your entries using dch -t
[10:09] <yolanda> jamespage, i added entry with dch -t, is there something wrong?
[10:09] <jamespage> yolanda, did you do a dch -r as well?
[10:09] <yolanda> no
[10:10] <jamespage> how did it change from UNRELEASED to trusty ?
[10:10] <yolanda> i manually edited that
[10:11] <yolanda> jamespage, updated MP
[10:12] <jamespage> yolanda, so we should not be updating from UNRELEASED until someone actually does an upload to the archive
[10:13] <jamespage> then they do dch -r which updates the target and the timestamp on the changelog and do the upload
[10:13] <yolanda> good to know
[10:13] <yolanda> i normally tend to set the latest distribution name
[10:43] <yolanda> jamespage, i have a question about SRU process explained here. https://wiki.ubuntu.com/StableReleaseUpdates
[10:44] <yolanda> it says i need to fill an [Impact] , [TestCase] and [Regression Potential] comments. Where do i have to do it, in the same bug?
[11:17] <jamespage> yolanda, yes - in the description
[11:18] <yolanda> jamespage, and then i grab the bugfix from trusty and i update the package for saucy?
[11:18] <jamespage> yolanda, no
[11:18] <jamespage> you will need to cherry-pick the fix from upstream github and make it work for the version on saucy.
[11:18] <jamespage> yolanda, the bugfix in trusty is a new upstream release - you can't sru that
[11:19] <yolanda> jamespage, i meant that, sorry
[11:19] <yolanda> just look at that commit
[11:27] <jamespage> yolanda, the bug reporter is quite friendly - maybe you could ask him for a more specific test case configuration
[11:27] <jamespage> I suspect he'd also verify a fix for you as well once its in the proposed pockets
[11:28] <yolanda> jamespage, and SRU comments should be filed in same bug description, or create some other bug? i saw that in Launchpad there are specific SRU bugs
[11:29] <jamespage> yolanda, same bug - why would you raise another one?
[11:29] <jamespage> the SRU fixes that bug after all
[11:29] <yolanda> jamespage, just asking because I saw other independent bugs in Launchpad, I want to be sure that i'm doing the right thing :)
[11:30] <jamespage> yolanda, if we have minor release exceptions, then yes we would probably raise a specific SRU bug
[11:44] <rbasak> smoser: are we treating bug 1250390 as resolved? I know I haven't verified it, but it should be fixed now, right?
[11:44] <uvirtbot> Launchpad bug 1250390 in maas "No published Saucy armhf ephemeral images" [High,Triaged] https://launchpad.net/bugs/1250390
[11:44] <rbasak> jamespage: ^^
[11:44] <jamespage> rbasak, ta
[12:31] <zul> jamespage:  of course it did
[12:31] <jamespage> zul, \o/
[12:32] <swaT30> hey guys, sorry if you had already answered this, but any ETA on 2013.1.4 to be pushed into updates? I see that it has been in proposed for a while
[12:32] <zul> jamespage:  ill look when i get in
=== PriceChild is now known as PriceChilde
=== PriceChilde is now known as Pricey
[12:40] <swaT30> @jamespage any idea?
[12:41] <jamespage> swaT30, sorry - about what (guess I must have missed something)
[12:41] <swaT30> any ETA on 2013.1.4 hitting updates in the UCA?
[12:41] <swaT30> :)
[12:49] <jamespage> swaT30, hmm - yes that has been sat in proposed for a while
[12:50] <jamespage> lemme kickoff the automated testing - if its all ok I'll promote today
[12:50] <swaT30> would be great to have it :)
[12:50] <swaT30> thanks !
[12:51] <swaT30> jamespage: I'll keep an eye on http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/grizzly_versions.html
[12:51] <swaT30> I assume that's as good a spot as any?
=== gary_poster|away is now known as gary_poster
[13:11] <makara> i've logged in as user JIM and I need to run a command as GAX
[13:11] <makara> what 2 do?
[13:12] <makara> i don't know GAX's password
[13:12] <jamespage> swaT30, yes - thats good
[13:12] <jamespage> swaT30, there is also a notifications ML
[13:30] <smoser> rbasak, its not fix-released for sure.
[13:31] <smoser> as in no 'released' images.
[13:37] <makara> any idea how to execute a script on system start as given user?'
[13:40] <rbasak> makara: there are various ways. You could add something to /etc/rc.local that uses su or sudo. Or add an upstart job to /etc/init/ that uses setuid/setgid. Or even an @reboot job to cron.
[13:44] <makara> rbasak, and if I put "su - teamcity runAll.sh" in /etc/rc.local then why wouldn't get hung up on asking me for a password?
[13:44] <makara> like it would in a shell
[13:45] <rbasak> makara: rc.local runs as root, which should be able to su to any user without a password. Check it works by using "sudo -i" to get a root shell, and then test the su command you propose there.
[13:48] <jamespage> swaT30, tested OK - should be out on the archive in the next 2 hrs
[14:04] <paws> hello, can anyone tell me whats a good Cloud storage software, that i can host on my own server ?
[14:05] <zul> jamespage:  whats patch-branches in nova icehouse packaging?
[14:06] <jamespage> zul, uh?
[14:06] <zul> jamespage:  yeah...
[14:06] <zul> jamespage:  anyways its gone
[14:06] <jamespage> zul, I don't see that
[14:07] <zul> jamespage:  its an empty file in the debian directory
[14:07] <jamespage> not a clue
[14:07] <Felipe_C> Hi all, Has anyone heard of or actually tried those Paralella Boards to create a proof of concept mini cloud cluster?
[14:08] <jamespage> zul, its been there along time
[14:08] <zul> jamespage:  yeah well if anything breaks then ill blame myself
[14:10] <zul> jamespage:  https://code.launchpad.net/~zulcss/nova/webob/+merge/198751
[14:13] <zul> jamespage:  https://review.openstack.org/#/c/61742/ as well
[14:22] <zul> yolanda:  i just merged your heat fixed
[14:22] <yolanda> thx
[14:24] <swaT30> jamespage: thanks! on the ML, got the notifications
[14:30] <zul> jamespage:  trove is in openstack-ci now
[14:41] <zul> jamespage:  https://code.launchpad.net/~zulcss/cinder/webob/+merge/198752
[14:54] <bittin> Hired an ubuntu server from azure :)
[14:56] <jamespage> zul, how do you always manage to remove dep headers from patches?
[14:56] <zul> jamespage:  i dunno its an art i think :)
[14:56] <jamespage> zul, I'm putting in a conditional wait in nova-compute upstart that if libvirt-bin is installed, it will wait for it to reach running before starting
[14:57] <jamespage> should close out a couple of race bugs I've seen
[14:57] <jamespage> I *think* we need todo the same with neutron-ovs-cleanup
[14:57] <zul> jamespage:  sounds good
[15:09] <zul> jamespage:  yay trove needs a unpackaged dep
=== freeflying_away is now known as freeflying
[15:16] <jamespage> zul, feedback on your MP
[15:16] <jamespage> sorry - git review
[15:17] <makara> exit
[15:17] <zul> jamespage:  i saw ill fix it up
[15:17] <jamespage> zul, I don't think we should unbound it - but < 1.4 is OK imho
[15:18] <zul> jamespage:  agreed
[15:23] <jamespage> zul, adam_g: https://code.launchpad.net/~james-page/nova/compute-plus-others/+merge/198763
[15:27] <zul> jamespage:  couple of things, while you are at it
[15:27] <jamespage> zul, sure
[15:27] <zul> jamespage:  i think the openssh-client can go away in the build-depends-indep
[15:28] <zul> jamespage:  curl can go away as well
[15:28] <jamespage> zul, what was that for?
[15:28] <zul> jamespage:  im not sure i think it was a diablo thing
[15:28] <zul> jamespage:  nova-uml should go away
[15:29] <jamespage> zul, actually openssh-client - still a runtime I think
[15:29] <jamespage> migrations
[15:29] <zul> jamespage:  ah yes
[15:29] <jamespage> live migrations and cold migrations
[15:29] <zul> ssh key-gen as well i guess
[15:30] <zul> jamespage:  but yeah git rid of uml as well :)
=== freeflying is now known as freeflying_away
[15:30] <jamespage> zul, we don't like uml do we?
[15:31] <zul> jamespage:  makes the package less complicated ;)
[15:49] <yolanda> jamespage, i added a fix to rabbitmq charm https://code.launchpad.net/~yolanda.robla/charms/precise/rabbitmq-server/ha/+merge/198768
[15:49] <d1n0> I am having problems with maas. I have imported the boot images, but when I try and pxe boot a node.. it doesn't see the pxe template
[15:52] <zul> jamespage:  https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769
[15:55] <yolanda> jamespage, currently rabbitmq is relying on HA to create clusters. That is different on active-active. Should we set a config var in rabbit to specify if we want active-active or active-passive?
[15:56] <jamespage> yolanda, can we not determine which mode using relations?
[15:56] <jamespage> its only HA if it gets related to hacluster
[15:57] <jamespage> zul, can't drop openssh-client
[15:57] <zul> jamespage:  ok cool
[15:58] <yolanda> jamespage, i see, and act differently and set different vars depending on it. For example in active-active i need to send all the rabbitmq hosts
[15:59] <jamespage> yolanda, yes - that's right
[15:59] <yolanda> i could set a var in rabbitmq to tell glance for example, if rabbit uses active-active or active-passive, and glance reacts and create proper config
[15:59] <yolanda> makes sense?
=== matsubara_ is now known as matsubara
[16:01] <jamespage> yolanda, I think it does - the current HA approach passed a VIP to signal its in HA mode right?
[16:01] <yolanda> yes
[16:02] <jamespage> yolanda, do we need rabbitmq >= 3.0.0 todo the active/active stuff? I think we might be not 100% sure
[16:04] <yolanda> jamespage, i don't think so, openstack doc says it's tested with 2.7.1
[16:04] <jamespage> yolanda, OK - the setting of HA policy in your change is scoped to >= 3.0.x
[16:05] <yolanda> jamespage, that's only needed for version >= 3.0.x, just followed openstack guide
[16:05] <jamespage> yolanda, ah - OK _ good-oh
[16:06] <yolanda> jamespage, i am starting with glance, to make glance react to rabbit_hosts needed to grab version from precise-havana
[16:06] <yolanda> doesn't seem to work with older versions
[16:20] <zul> Daviey:  when you get a chance can you look at pytyhon-designateclient for me (its in source new, dependency needed for openstack-trove)
=== malakhi_ is now known as malakhi
=== Jikai is now known as Jikan
[16:45] <hallyn_> rbasak: trusty is not supported by uvt-simplesreams-sync?
[16:48] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769
[16:50] <rbasak> hallyn_: it comes from a different stream. uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily release=trusty arch=amd64 or similar.
[16:50] <hallyn_> rbasak: any reason not to have uvt figure that out?
[16:50] <hallyn_> (lxc-create does :)
[16:51] <hallyn_> (you can see i'm big on not typing more than i need to :)
[16:51] <rbasak> hallyn_: it would be nice, yes. It's a bit of a tricky thing to do with the simplestreams API, and I think it should probably be pushed back there in some way. lxc-create will have the same issue when it's simplestreamed.
[16:53] <rbasak> hallyn_: I'd like to tell the simplestreams API "here are your streams, here are my filters, go". But I'm not sure about how multiple streams will interact that way.
[16:53] <rbasak> smoser: ^^
[16:55] <rbasak> hallyn_: btw, I uploaded the latest PPA earlier
[16:55] <hallyn_> cool, thanks.
[16:59] <jamespage> zul, OK - I think that nova mp is ready to go - ditto the neutron one
[16:59] <jamespage> zul, looking at that now
[16:59] <jamespage> why do we need to disable the tests?
[16:59] <zul> jamespage:  they are broken for now
[17:00] <zul> and we need to do a mir for nose
[17:03] <smoser> rbasak, i dont hink i follow
[17:04] <jamespage> zul, blimey - swift needs some love
[17:05] <jamespage> zul, which bit of nose?
[17:05] <zul> jamespage:  the functional test bits
[17:06] <jamespage> zul, yeah - I mean't which dependency?
[17:06] <zul> jamespage:  hold on lemme double check
[17:06] <smoser> rbasak, com.ubuntu.cloud.daily:server:trusty:amd64 is very explicitly different than com.ubuntu.cloud:server:trusty:amd64
[17:06] <smoser> that is by design.
[17:06] <smoser> i woudln't suggest munging that all together.
[17:07] <zul> jamespage:  libjs-jquery-hotkey, jquery-goodies, libjs-jquery-isonscreen, and javascript-common
[17:07] <jamespage> zul, is that for docs?
[17:07] <zul> jamespage:  i believe so
[17:09] <rbasak> smoser: yes, they are. But uvtool should munge them together, as an exception, for the development release.
[17:09] <rbasak> smoser: this makes them analogous to what people expect by setting their sources.list.
[17:10] <smoser> i dont think so.
[17:10] <smoser> there is no released trusty.
[17:10] <smoser> if you say trusty released, it can't get you such a thing.
[17:10] <smoser> if you say trusty and daily, it can
[17:10] <rbasak> I want the latest available of everything. For stable releases, I want the stable image. For the development release, I want the development release.
[17:11] <rbasak> Sorry. For the development release, I want the latest development image (ie. a daily).
[17:11] <smoser> why?
[17:11] <rbasak> uvt-just-give-me-it.
[17:11] <smoser> that daily might not work at all.
[17:11] <rbasak> That's fine. That's what using the development release means.
[17:12] <rbasak> The CLI should provide sensible defaults. If I specify a release, then the sensible default is the stable release image for stable releases, and the daily image for the development release.
[17:12] <jamespage> zul, sorry - don't get it
[17:13] <rbasak> It is fine for this to be uvtool-specific and Ubuntu-specific. I'm just saying that I want some way to explain this to the simplestreams API.
[17:13] <zul> jamespage:  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[17:13] <rbasak> Or else we need to figure out how uvtool should handle the interaction.
[17:13] <jamespage> zul, there is actually no point in running them - SKIPPING FUNCTIONAL TESTS DUE TO NO CONFIG
[17:13] <jamespage> https://launchpadlibrarian.net/154000942/buildlog_ubuntu-saucy-i386.swift_1.10.0-0ubuntu1_UPLOADING.txt.gz
[17:13] <smoser> i personally dont really think that "daily image for development release, but stable imgaes for all others" is likely whta a developer wants.
[17:14] <smoser> more likely i'd want dailies of everything.
[17:14] <zul> jamespage:  agreed
[17:14] <jamespage> zul, I don't see why that would require disabling tests
[17:14] <smoser> cstack does handles this. sanely.
[17:14] <jamespage> zul, also the swift-doc package is empty
[17:14] <zul> jamespage:  ok ill have a look at getting this fixed then
[17:15] <rbasak> hallyn_: ^^ interested in this conversation?
[17:15] <jamespage> zul, thats a regression - 1.10.0 has it
[17:15] <jamespage> populated
[17:15] <hallyn_> no? :)
[17:15]  * hallyn_ looks
[17:15] <rbasak> smoser: I think you assume that the CLI somehow knows that this is a developer speaking. It doesn't know that.
[17:15] <rbasak> smoser: given that it doesn't know, I think it's reasonable to default to the released image for stable releases.
[17:16] <rbasak> smoser: but given that the user just asked for "trusty", and that there is no released image for that, and it's known to be a development release, I think it's reasonable to provide a daily in that case.
[17:16] <hallyn_> 17:13 < smoser> i personally dont really think that "daily image for development release, but stable imgaes for all others" is likely whta a developer wants.
[17:16] <hallyn_> i disagree.  that's exactly what i want
[17:16] <smoser> its not what i want
[17:16] <smoser> and i'm a developer
[17:17] <hallyn_> it's myworkaround for you cloud image folks being too lazy to give mea  stable devel image
[17:17] <smoser> hallyn_, its not cloud image folks.
[17:17] <smoser> there is no stable devel image of any ubuntu
[17:17] <smoser> when there is (next thursday)
[17:17] <smoser> you'll have something in the stable stream of trusty
[17:17] <hallyn_> that's alpha1?
[17:17] <smoser> it will be correctly labelled 'alpha-1' rather than release
[17:18] <rbasak> I'm happy to add a --developer option that changes sync's default to use the daily stream.
[17:18] <hallyn_> in the end (ignoring smoser's being pedantic) i don't care who builts the smarts in - uvtool or simplestreams.
[17:18] <rbasak> However, ifi the user doesn't do that, I still want trusty to be available by default, on request. And I don't think it's reasonable to default to daily images across the board.
[17:19] <hallyn_> but i wanted to test something in canonical-kernel-team/ppa just now for trusty, and wanted the 'best' trusty cloud image i could find
[17:19] <hallyn_> <shrug> i'm with rbasak.
[17:19] <smoser> hallyn_, that would be the dailies ;)
[17:19] <rbasak> So I think "best" is released for stable releases, and daily for development releases, despite any alpha-1.
[17:20] <hallyn_> smoser: i'm just a user of uvtool.  i don't care where it comes from, i just want "the most stable" image that exists
[17:20] <smoser> no you dont.
[17:20] <rbasak> hallyn_: would you want alpha-1 or a daily for trusty, if both existed and the daily were newer?
[17:20] <smoser> so its fine with me if uvtool has logic like:
[17:20] <hallyn_> rbasak: i guess i'd want daily
[17:21] <smoser>  if release_requestsed == ubuntu_development_release(): change_stream_to_daily()
[17:21] <rbasak> smoser: trouble is that right now uvtool just passes through the release=... filter without understanding it.
[17:21] <rbasak> I would prefer to not special case that understanding.
[17:22] <smoser> you want a special case understanding
[17:22] <smoser> but you dont want to special case it
[17:22] <smoser> you want someone else to special case that
[17:22] <rbasak> I want a general way of handling this case.
[17:22] <smoser> but the someone else here thinks that when you say "released" you get "released". and when you say "daily" you get "daily"
[17:22] <rbasak> I'm fine with telling the simplestreams API about this understanding. I want to do it in an API call.
[17:23] <smoser> i dont think so. daily is explicitly and by design not released.
[17:23] <rbasak> If the user specifies released or daily, then that should override default behaviour and do what you asked for.
[17:23] <smoser> you can munge those two things together however you choose.
[17:23] <smoser> as i said, cstack does this "right" for me.
[17:23] <rbasak> If the user doesn't specify released or daily, released/dailiness should be based on the status of the release requested.
[17:24] <rbasak> And of course the release requested should also have a default, but that wouldn't change this behaviour.
[17:24] <smoser> rbasak, then you can implement that.
[17:24] <rbasak> smoser: you want me to parse simplestreams filter rules myself?
[17:24] <rbasak> smoser: I want the simplestreams API to do the parsing, but for me to give it the rule.
[17:26] <smoser> you want 2 completely different things. available only from 2 completely different, completely unrelated sources.
[17:27] <rbasak> Yet the release on one corresponds to the release on another.
[17:27] <rbasak> They are not completely unrelated.
[17:27] <smoser> happenstance
[17:27] <rbasak> No. I have a specific reason for wanting that relation. Therefore, provided that my reason is reasonable, they are related.
[17:28] <smoser> scott james remnant and scott moser are not related.
[17:28] <rbasak> They relate at the CLI. 1) "Trusty!"..."ok, you want daily." 2) "Saucy!"..."ok, you want released."
[17:29] <smoser> even if it would be convenient for robie basak if they were.
[17:29] <rbasak> The names precise, quantal, raring, saucy, trusty are related. The daily images are related to that set. So are the released images.
[17:29] <smoser> just like my example.
[17:29] <smoser> same name
[17:29] <smoser> different thing
[17:29] <smoser> i can't fix your chromebook.
=== yofel_ is now known as yofel
[17:29] <rbasak> The daily ends up being a released.
[17:30] <smoser> happenstance
[17:30] <smoser> honeslyt.
[17:30] <rbasak> Nothing like your example.
[17:30] <smoser> you're welcome to buildin the knowledge that 'com.ubuntu.cloud.daily' is somehow related to 'com.ubuntu.cloud'
[17:30] <rbasak> I think a problem here is that you do not accept the original use case that makes me want this.
[17:30] <smoser> but you have to go to 2 completely different end points of data to find those things.
[17:31] <smoser> i think this is easily solvable.
[17:31] <smoser> and i've told you I'm ok for you to solve it.
[17:31] <rbasak> Well, I can parse the simplestreams filters. So we can duplicate the code, and lock in the simplestreams filter query language. Great.
[17:32] <smoser> you can create filters. and mirror 2 streams to 2 different locations.
[17:32] <smoser> i dont see how that is duplicating anything.
[17:33] <rbasak> I need to do that automatically. Without expecting the user to set it up for me. And I need to handle the transition of a release, where I want to switch from use of a daily image to a released image.
[17:33] <rbasak> Oh look - they're related!
[17:34] <smoser> they're not related.
[17:34] <smoser> was that unclear ?
[17:34] <rbasak> Where I was using a trusty daily image, I will after release want to use a trusty released image. Thus they're related.
[17:34] <smoser> dont handle it.
[17:35] <smoser> after trusty is released, get the released stream
[17:35] <rbasak> The point of uvtool is to hide this complication, and just do what is reasonable.
[17:35] <rbasak> Automatically.
[17:36] <rbasak> The only way I can see of doing this is to either hardcode the assumption that the release key maps between daily and released, or to publish the mapping somehow.
[17:36] <rbasak> (oh look - they're related)
[17:36] <rbasak> I guess we're at an impasse, which basically just means that the pain will continue. Sorry hallyn_.
[17:37] <smoser> cstack does this right.
[17:37] <rbasak> Except that you've defined what you think is right, and we disagree.
[17:38] <rbasak> Somebody who says "precise", without any further information, can be inferred to mean "stable, please". And someone who says "trusty" presumably means "development, please".
[17:39] <smoser> and then based on some even that occurs at some point in the future, your interpretation of what they mean changes.
[17:39] <smoser> which is odd.
[17:39] <smoser> and unexpected.
[17:39] <smoser> just because the calendar says 2014-04-17.
[17:39] <hallyn_> that event being a release?
[17:39] <rbasak> It matches how Debian releases work, so is not at all unexpected.
[17:39] <hallyn_> that's not expected
[17:39] <hallyn_> uh, not unexpected
[17:39] <smoser> it is unexpected to the user.
[17:39] <rbasak> It is not, since that's what the release names are defined to mean.
[17:39] <rbasak> That's how we all use the term.
[17:39] <hallyn_> the user to whomthat is unexpected would nto specify a release at all, and run latest LTS
[17:40] <rbasak> You've invented your own system of daily and released for cloud images (with good reason), but that doesn't mean that these concepts apply to release names.
[17:40] <smoser> it is not good design for behavior to change
[17:41] <smoser> based on events non-controllable by the user
[17:41] <smoser> "I did nothing, yet it broke"
[17:41] <smoser> where "it broke" is "it behaved differently"
[17:41] <rbasak> "I had a bug in Trusty, which I fixed, but why isn't showing up in my uvtool test? Wait, why is it using alpha-1?"
[17:42] <rbasak> The development release is *defined* to behave differently.
[17:42] <rbasak> It is not good design to surprise the user.
[17:42] <hallyn_> would it help if 'uvt-s-s query' showed trusty entries in red for "danger"? :)
[18:04] <smoser> rbasak, i dont know how to solve your problem. with the interface you have.
[18:05] <zul> jamespage:  https://code.launchpad.net/~zulcss/trove/trove-cleanups/+merge/198803
[18:05] <smoser> since you'd have to look at 'release=' which could be 'release~([tT][rR].*)'
[18:05] <smoser> or something else that would match that.
[18:07] <smoser> perhaps you should, being an 'ubuntu' tool, explicitly know certain things about releases, and treat them as releases. rather than just as arbitrary keys.
[18:07] <smoser> ie: uvt-kvm trusty
[18:07] <smoser> rather than
[18:07] <smoser>  uvt-kvm release=trusty
[18:08] <smoser> that is the bit that cstack knows.
[19:27] <d1n0> where does a maas node get its sources.list from?
[19:27] <d1n0> its a pxe boot node, and im getting a 403 error when trying the packages
[19:28] <smoser> d1n0, it can be specified by maas.
[19:28] <smoser> but it should default to archive.ubuntu.com
[19:29] <d1n0> smoser; why would i be getting a 403 though, thats what confuses me
[19:29] <smoser> agreed.
[19:30] <smoser> that is confusing.
[19:30] <smoser> are you able to pastebin it ?
[19:30] <smoser> it == the console log
[19:31] <d1n0> Unfortunately not, because after it gets the 403.. the pxe boot fails and it shuts down.
[19:32] <d1n0> logfile: /var/log/squid-deb-proxy/access.log shows the 403 error
[19:34] <sarnold> d1n0: note that s3 systems return '403' when they mean '404'.
[19:34] <sarnold> it's confusing.
[19:35] <d1n0> hmm, now you confuse me even more.. lol
[19:36] <d1n0> smoser; how can I change what the maas sends over to it? I want it to use a local mirror
[19:36] <smoser> d1n0, it depends on what version of maas.
[19:37] <d1n0> whatever is in 13.10
[19:37] <smoser> but i think in cloud-tools version or saucy, it is in the web ui.
[19:37] <smoser> i think
[19:37] <d1n0> i thought so too, but it looks like they took it out between 12.04 and 13.10
[19:37] <smoser> sarnold, well, its not likely s3 is involved here.
[19:38] <smoser> and to be fair, thats general good practice for security.
[19:39] <smoser> ie, you dont tell the attacker "username not found" you tell them "username/password invalid".
[19:39] <d1n0> editing the node only allows editing the hostname and mac addresses (along with changing the default release)
[19:39] <sarnold> smoser: yeah, s3 seemed unlikely, but an s3 workalike crossed my mind. I figured I'd throw it out ;) hehe
[19:39] <smoser> i do agree it sucks for s3
[19:39] <smoser> mirrors explicitly.
[19:39] <smoser> d1n0, it wouldnt be on the node
[19:39] <sarnold> yeah; it's a reasonable enough position in general. hehe. :)
[19:39] <smoser> it would be somwhere else.
[19:39] <smoser> in d'setting' or something
[19:39] <smoser> settings.
[19:43] <d1n0> changed, now for another attempt at a pxe boot
[19:56] <d1n0> now back to my vague invalid mac address error
[20:14] <d1n0> nothing like getting one or more of your mac addresses is invalid when trying to commission a node :s
[20:20] <zul> adam_g:  ping can you +1 https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769 please
[20:20] <adam_g> zul, done
[20:21] <zul> adam_g:  thanks
[20:38] <hxm> hi
[20:39] <hxm> i have a server with many domains and I could want to let the users receive and send emails from their domains, as in example facebook does
[20:39] <hxm> forwarding emails, is that possible without using postfix and all those tools that are hard to set up properly for not get as spam
[20:42] <Demosthenex> so ubuntu LTS 10.04. after booting for FIVE MINUTES no one, not root, no accounts can login. timeout nonstop. ssh with key is ok, it seems to be a password authentication chain issue. ideas on debugging?
[20:48] <Demosthenex> ah, i had to remove smb crap from pam common-auth.
[21:29] <mgw> What is the purpose of the packages at http://archive.ubuntu.com/ubuntu/pool/?
[21:50] <mgw> To answer my question… it seems to host the actual packages pointed to from the various Packages.gz
[21:51] <mgw> There's a package in pool that works fine in precise (python-gnupg), but it's not in Precise's Packages.gz…. other than downloading the .deb, how could that be installed via apt?
[22:15] <smoser> hallyn_, its not perfect, but it bevaves the way you happen to think it should
[22:15] <smoser> https://code.launchpad.net/~smoser/uvtool/sm-features00/+merge/198838
[22:15] <smoser> rbasak, ^
[22:15]  * smoser gone
[22:16] <hallyn_> smoser: don't be angry
[22:16] <hallyn_> :)
=== jerrad is now known as Underbyte
=== gary_poster is now known as gary_poster|away
[22:49] <hallyn_> smoser: looks perfect
=== mibofra- is now known as mibofra