[15:29] <zerosum>  can anyone help with installing ubuntu 13.04 with a usb, i get to the grub boot menu select install ubuntu, then nothing happens black screen


[03:19] <cody-somerville> python-launchpadlib is not currently installable from launchpad ppa on natty:
[03:19] <cody-somerville>  python-launchpadlib : Depends: python-lazr.restfulclient (>= 0.11.2-1) but 0.11.1-1build1 is to be installed
[03:19] <cody-somerville>                        Depends: python-lazr.uri (>= 1.0.2-4) but 1.0.2-3build1 is to be installed
[03:41] <wgrant> cody-somerville: Natty's no longer supported for Launchpad development.
[03:41] <cody-somerville> It hasn't even been a year since Natty was released.
[03:42] <lifeless> cody-somerville: its best effort only
[03:42] <lifeless> cody-somerville: not deliberately broken, but no effort made to spport it
[03:46] <wgrant> Everyone else who has wanted to run Launchpad has been running either Lucid or the latest stable.
[03:46] <wgrant> Nobody complained when we proposed not actively maintaining Natty in ppa:launchpad, so we stopped.
[03:46] <cody-somerville> is python-launchpadlib getting backported in another PPA?
[03:47] <lifeless> you can use the one in natty itself
[03:50]  * cody-somerville manually patches his launchpadlib with https://code.launchpad.net/~leonardr/launchpadlib/handle-unknown-token/+merge/51563
[05:37] <StevenK> cody-somerville: Are you subscribed to launchpad-dev? That's where I announced that Maverick was removed from the LP PPA.
[05:38] <cody-somerville> StevenK, I am. I use natty not maverick though.
[05:39] <StevenK> I announced that Natty might get shot in the face, though.
[05:39] <StevenK> wgrant: I figured out why my rev broke. IBugSet.createBug() calls notify() *then* _setInformationType()
[05:40] <StevenK> wgrant: But I'm not sure how to test that. The fix, of course, is to call _setInformationType() right after the bug is created.
[05:47] <wgrant> StevenK: Right, that's what I suspected immediately :)
[05:47] <wgrant> StevenK: Should be very easy to test.
[05:47] <wgrant> StevenK: You just have to create a private bug on a product with a structsub, and check the notification recipients.
[05:52] <wgrant> StevenK: And no, the fix is to merge _setInformationType into whatever creates the bug.
[05:52] <wgrant> StevenK: private/security_related exist only for compatibility; they should not permeate that far into the model.
[05:54] <StevenK> I'm still questioning if they will die completly.
[05:55] <StevenK> But yes -- I can bring forward convert_to_information_type() in adapters.bug from the next branch and pass in private, security_related and information_type to the Bug() call.
[06:13] <wgrant> Differences (ndiff with -expected +actual): - Time zone: Europe/London (UTC+0000) + Time zone: + Europe/London + (UTC+0100)
[06:13] <wgrant> Hah
[06:13] <wgrant> I guess that'll affect all builds for the next view months...
[06:13] <wgrant> few
[06:17] <StevenK> wgrant: Oh sigh
[07:20] <lifeless> StevenK: yo can subscribe, create a bug, in your handler check the information type
[07:24] <wgrant> But you also need the integration test that I outlined above.
[07:24] <StevenK> I tried to write it, it fails either way.
[11:18] <czajkowski> aloha
[19:33] <rick_h> 080254
[22:36] <lifeless> http://www.soapatterns.org/masterlist_c.php
[22:39] <bigjools> lifeless: people still run php!
[22:40] <lifeless> very many
[22:40] <lifeless> probably generates most pages on the internets
[22:40]  * bigjools was being tongue-in-cheek
[22:41] <bigjools> glad you are thinking about the patterns anyway
[22:41] <bigjools> it's nice to see some abstractions written down
[22:42] <wallyworld_> bigjools: boo!
[22:42] <bigjools> wallyworld_: enjoy your drag club?
[22:42] <wallyworld_> how's your ticker this morning?
[22:42] <wallyworld_> yes, *very* informative
[22:52] <StevenK> wgrant: http://pastebin.ubuntu.com/899767/  is my test complete bong?
[22:53] <wgrant> StevenK: Does it work?
[22:54] <wgrant> (no, it doesn't -- so yes, complete bong :))
[22:55] <wgrant> StevenK: You need to check the recipients *at creation time*.
[22:55] <wgrant> This is well after.
[22:55] <wgrant> You could do what lifeless said, or you could create a bug and inspect the BugNotificationRecipient table afterwards, or preferably both.
[22:56] <StevenK> I'd rather just one nice test.
[22:56] <StevenK> But okay, I need to reach into BugNotificationRecipient with Storm.
[22:59] <wgrant> StevenK: You need an integration test.
[22:59] <wgrant> But both would be preferable.
[23:01] <StevenK> wgrant: I thought the one I pasted was?
[23:01] <lifeless> wgrant: StevenK: checking the BNR table afterwards is a test I would delete
[23:01] <wgrant> lifeless: Why?
[23:01] <lifeless> notificationservice won't have that table
[23:01] <wgrant> .............
[23:01] <wgrant> notsureifserious
[23:01] <lifeless> totally
[23:01] <wgrant> Then you'd change the test to check the notification service?
[23:02] <lifeless> use abstractions, don't test across them
[23:02] <bigjools> completely
[23:02] <wgrant> lifeless: THen mock out the notification service.
[23:02] <wgrant> But don't just mock out one of the Zope subscribers and check that single callsite.
[23:02] <wgrant> Not for something like this.
[23:07] <StevenK> wgrant: Right, and there should be *one* notification to the reporter?
[23:08] <StevenK> (Currently, I have two)
[23:08] <wgrant> StevenK: And potentially one to the security contact or bug supervisor.
[23:10] <lifeless> StevenK: you probably have two due to bug
[23:10] <StevenK> lifeless: Yes, I know, thank you.
[23:10] <lifeless> bug 132300
[23:10] <_mup_> Bug #132300: mail for new bugs inconsistent with other bug mail (ignores mail-on-my-actions disabled, missing footers, duplicate mail vs structural subscriptions) <email> <lp-bugs> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/132300 >
[23:11] <lifeless> StevenK: ^ was digging the number up
[23:11] <StevenK> lifeless: I have two due to the critical filed on the weekend.
[23:11] <StevenK> The one I've been thinking about, and kicking myself for since I found about it.
[23:13] <lifeless> StevenK: bug 963539 ?
[23:13] <StevenK> lifeless: Yah.
[23:14] <StevenK> wgrant: http://pastebin.ubuntu.com/899792/  Given that test (which passes), what other test do I need?
[23:14] <wgrant> StevenK: There's no existing API for that?
[23:15] <StevenK> Not that I could see.
[23:15] <wgrant> And that test fails before the reversion?
[23:16] <StevenK> wgrant: Yeah, I resurrected the changes, and the test failed. Applying the diff I wrote in anger on Sunday fixes it.
[23:17] <lifeless> wgrant: equally, or better, mock out the existing notification api to check its private. Oh wait, thats what I suggested.
[23:18] <wgrant> lifeless: Mocking out the API called by the subscriber, maybe.
[23:18] <wgrant> But the subscribers are too muddy now to safely mock out directly.
[23:19] <wgrant> Erm
[23:19] <wgrant> Who is this Eike character, and why did they readd the crap that you removed from that bug description? :/
[23:19] <StevenK> wgrant: I can reach into BugNotification and pull out the record and then call .recipients() on it, or I can just Join() through to BNR.
[23:19] <StevenK> I picked the latter.
[23:20] <lifeless> wgrant: i suspect a bug in 'bug-repo-syncer'
[23:21] <wgrant> Indeed it is.
[23:22] <wgrant> ./bug_repo_syncer/common.py:        #Match discovery bug link: "[@[@BUGLINK "bug #123"@trac @]@]"
[23:22] <_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[23:22] <lifeless> bug 964862
[23:22] <_mup_> Bug #964862: something is damaging the bug description in bug 936502 <bug-repo-syncer:New> < https://launchpad.net/bugs/964862 >
[23:25] <wgrant> lifeless: So, yes, ideally we'd mock out the notification API, except that LP's "lol what's an abstraction" policy makes that difficult to do reliably without checking the DB tables.
[23:26] <StevenK> wgrant: So I've fixed and can put this up for review again, or I need another test?
[23:27] <wgrant> StevenK: Is information_type now handled natively?
[23:28] <StevenK> wgrant: information_type is now set correctly when the bug is created.
[23:29] <lifeless> thats a different question :P
[23:29] <wgrant> All three attributes need to be set correctly in the initial INSERT
[23:29] <wgrant> And preferably the method only takes information_type
[23:30] <wgrant> Calculating private and security_related from that.
[23:30] <StevenK> wgrant: All three attributes are set correctly when the bug is created.
[23:30] <wgrant> They were last time too.
[23:30] <wgrant> What we care about is *in the initial INSERT statement*.
[23:31] <StevenK> Sorry, yes, set correctly during the initial INSERT.
[23:31] <wgrant> Sounds reviewable :)
[23:33] <StevenK> wgrant: http://pastebin.ubuntu.com/899809/
[23:34] <wgrant> Indeed.
[23:40] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/bugs-use-information_type-redux/+merge/99236 if you're offering
[23:43] <wgrant> StevenK: Will look in a sec.
[23:43] <wgrant> Trying to convince the staging mailbox to function...
[23:44] <wgrant> "Downloading message header 1 of 345783"
[23:44] <StevenK> Haha
[23:44] <StevenK> Hmmmm. Mail. I should read that.
[23:47] <wgrant> StevenK: btw, you may have seen that cocoplum scripts are nodowntime now.
[23:47] <StevenK> I have, yes.
[23:47] <wgrant> StevenK: This means that everywhere that touches the DB is nodowntime.
[23:47] <wgrant> So we no longer have to inject cocoplum deployment sequence points.
[23:48] <wgrant> For this sort of thing.
[23:48] <lifeless> poppy still has a DB connection
[23:48] <wgrant> lifeless: Yes, but it doesn't use it.
[23:48] <wgrant> So it doesn't matter.
[23:48] <lifeless> wouldn't it be a lot safer to remove it
[23:48] <lifeless> so that there is no timebom
[23:48] <wgrant> Oh yes.
[23:48] <lifeless> b
[23:48] <wgrant> I actually looked last week at deleting poppy from the tree.
[23:48] <lifeless> o\o/
[23:48] <wgrant> Sadly it would require the extraction of the SSH server stuff.
[23:49] <lifeless> so ?
[23:49] <wgrant> Which is slightly less than trivial, so I didn't JFDI.
[23:49] <lifeless> that needs extraction anyhow
[23:49] <wgrant> Sure.
[23:49] <lifeless> fair enough
[23:49] <wgrant> Had it not required that, it would have been an obvious JFDI task.
[23:50] <wgrant> StevenK: Can I expect a followup in the near future that makes information_type the native form?
[23:51] <StevenK> wgrant: That's in the branch that was reviewed on Friday
[23:51] <wgrant> Ah
[23:51] <wgrant> Indeed.
[23:51] <StevenK> Which depends on two DB patches
[23:51] <wgrant> Does not.
[23:51] <wgrant> The change I want is purely internal API changes.
[23:51] <wgrant> Currently things still pass private/security_related flags around.
[23:52] <wgrant> When they should only deal with information_type.
[23:52] <StevenK> Right. That's the next branch.
[23:52] <wgrant> The Bug model can deal with mapping that to private/security_related.
[23:52] <wgrant> StevenK: I think I mentioned this in the last review, but from the diff it looks like bug.private writes were previously permitted by the security policy, but I don't see any ZCML changes in this brnach to prevent that.
[23:58] <StevenK> wgrant: wgrant: private/security_related aren't in the ZCML, so I'm not sure how to tell it "forbid anyone setting these"


[00:06] <negronjl> jose: I'm in the middle of something ... give me a few minutes ( about 30 I'm afraid )
[00:06] <jose> I have time :)
[00:07] <jose> ping me when you're available :)
[00:23] <negronjl> jose: I'm back ... what's up ?
[00:39] <jose> negronjl: I'm having some troubles with the charm
[00:39] <jose> because of the err_and_quit you defined instead of the set -x
[00:39] <jose> now I'm getting some weird django errors, too
[00:40] <negronjl> jose: let me deploy it so I can see as well
[00:40] <jose> second
[00:40] <jose> oh, go ahead
[00:41] <negronjl> jose: What are you deploying on ?  precise? trusty?
[00:41] <jose> precise
[00:41] <negronjl> jose: ok ... hold on ... bootstrapping
[00:41] <jose> np :)
[00:43] <negronjl> jsoe: Where are you deploying this ?  ec2? something else ?
[00:43] <negronjl> jose: ^^
[00:43] <jose> ec2
[00:44] <negronjl> can you ssh into the instance ?
[00:44] <jose> but the error I get is an unbound variable one
[00:44] <jose> I'm in right now
[00:44] <jose> oh, no
[00:44] <jose> lemme redeploy
[03:26] <negronjl> jose: changes pushed
[03:27] <jose> negronjl: ack, thank you!
[08:17] <mhshams> ERROR bootstrap failed: waited for 10m0s without being able to connect: Permission denied (publickey,password).
[08:18] <mhshams> hi, I'm trying to bootstarp a private cloud (openstack) with juju, but getting above error.  where should i set the user/pass for the image that I'm using for bootstrap?
[08:29] <mhshams> Hi, I'm trying to bootstarp a private cloud (openstack) with juju, but getting above following error.  where should i set the user/pass for the image that I'm using for bootstrap?    ERROR bootstrap failed: waited for 10m0s without being able to connect: Permission denied (publickey,password).
[09:54] <mhshams> ls
[09:57] <mhshams> hi, after successfully bootstraping juju with my private openstack, when I try to deploy a charm (wordpress for example), it's complaining that network is unreachable. because it's trying to use private netowrk IP, not the public (floating) one.
[10:05] <marcoceppi> mhshams: did you set "use-floating-ip" to true in the environments.yaml?
[10:06] <mhshams> yes, i did. in fact bootstrapping is done with public ip, but only deploy is trying to use private one.
[10:38] <mhshams> marcoceppi: even when i try to run "juju status", the result is the same:   ERROR state/api: websocket.Dial wss://<IP_ADDRESS>:17070/: dial tcp <IP_ADDRESS>:17070: network is unreachable
[10:39] <marcoceppi> mhshams: bootstrap wasn't done with the public IP address if deploy is trying to use the private one
[10:45] <mhshams> marcoceppi: but the private network is not visible from my machine (juju installed). how can juju bootstrap with ip that is not visible in the network?
[10:47] <marcoceppi> mhshams: when juju bootstrap runs, it connects to the OpenStack install and uses the API to spin up an instance. If use-floating-ip isn't set to true before you bootstrap for the first time, then when it requests metadata about the instance to cache where the bootstrap node is, it'll just get the first address it responds with which will likely not be the floating-ip
[10:50] <mhshams> marcoceppi: in my configuration, use-floating-ip is set to true, and I can see the juju-openstack-machine has the public ip assigned. i can connect to the machine with it's public ip.
[12:09] <BradCrittenden> hi rbasak
[12:18] <jose> mhshams: if it's not production, try destroying the environment and re-bootstrapping. easiest way.
[12:21] <rbasak> bac: hi!
[12:21] <rbasak> bac: let me just read your email again
[12:21] <bac> rbasak: cool.  hey could you join us in #juju-gui in case someone else there is interested?
[13:10] <mhshams> @jose: i did tried that, and the result was the same. one thing to clarify is that, i'm creating the image metadata locallay and using this bootstrap with --metadata-source.  ( juju bootstrap --metadata-source=/home/<user>/.juju/metadata)
[13:11] <jose> I'm no openstack expert
[13:11] <jose> someone else should be able to help
[13:13] <jcastro> Hey guys, I''m going to move the LXC/juju session from thursday to wednesday so didrocks and I can be there
[14:19] <lazyPower> jamespage: ping
[14:19] <jamespage> lazyPower, OMG it must be ping jamespage hour
[14:19] <jamespage> lazyPower, hey!
[14:19] <lazyPower> oh, i'm sorry :(
[14:20] <lazyPower> I was curious if you had a chance to review teh vxlan-gateway that we sync'd on a while back, and what your notes were if any. Its come back up in the rev queue
[14:22] <jamespage> lazyPower, I've not looked yet
[14:22] <jamespage> lazyPower, (and no problem about the ping :-))
[14:23]  * lazyPower takes notes to not ping jamespage before 10:45 EDT
[14:23] <lazyPower> can i interest you in a coffee, or a crepe while I have your attention?
[15:07] <tech2> if you have a charm that has peers, how would you instantiate an additional instance of the peer on a particular host/vm/container? Is it just juju add-unit --to <name>  ?
[15:09] <marcoceppi> tech2: yes
[15:10] <tech2> More to the point I suppose. If I had a setup akin to US East, Europe (in terms of data-centres), how would I add units to one of those collections of VMs rather than to a particular machine?
[15:10] <marcoceppi> though, you will probably want to use add-unit --to (kvm:lxc):Machine#
[15:10] <tech2> thanks Marco.
[15:10] <marcoceppi> tech2: that's something you would do with constraints, there is a "zone" constraint landing in juju which will allow you to dictate which zone to create a new machine
[15:11] <tech2> marcoceppi: zones aren't here yet (assuming that's what you mean with the future-tense word "landing")?
[15:11] <marcoceppi> tech2: correct, code just landed in trunk for zones
[15:11] <marcoceppi> so it'll likely be in the next release of juju
[15:12] <tech2> marcoceppi: thanks
[15:13] <tech2> marcoceppi: is there a writeup about this anywhere (something I can show to others). I'm trying to upsell the virtues of juju at the moment and these are the kinds of issues being raised.
[15:14] <marcoceppi> tech2: there's no real document on zones, it just follows the normal constraint pattern, https://juju.ubuntu.com/docs/charms-constraints.html
[15:14] <tech2> thanks
[15:14] <marcoceppi> Once it lands in a release the docs will be updated
[15:17] <marcoceppi> tech2: for the exact format, here's the bug against the doc: https://github.com/juju/docs/issues/86#issuecomment-45469055 let us know if you and your team have any other questions about juju! Happy to help
[15:18] <tech2> marcoceppi: no doubt I'll be in and out over the coming months, thanks again for the help.
[15:37] <tech2> Is there a tool for web-managing multiple environments (much like juju-gui is for a single env), or is that Landscape?
[15:43] <marcoceppi> tech2: Landscape does a bunch of stuff, but I don't think it does management for multiple juju environments, it can and does know about multiple but won't give you the same experience as the GUI
[15:43] <tech2> marcoceppi: so the only way of really using a web-ui for multiple environments at the moment would be to have multiple instances of juju-gui (one per environment)?
[15:45] <marcoceppi> tech2: correct, that's the way at the moment
[15:45] <tech2> marcoceppi: My issue is that we have an obligation to keep different clients' data on different instances such that we could do things like provide them with ssh access for an audit etc. I figured environments might be the cleanest way to do that but that sadly increases the devops overhead a bit.
[15:46] <marcoceppi> tech2: I can see your point in increasing the overhead a bit. However, juju is fully drivable via a websocket per environment
[15:46] <marcoceppi> so you could append functionality to easy the devops world by building tools to help drive deployments
[15:47] <tech2> Right, there's always a cost, it just depends who has to pay it :)
[15:47] <avladu> hello there :). can someone help me on how to connect to the mongodb server, on the juju bootstrap node?
[15:47] <marcoceppi> core is also pretty responsive to users needs, so if there are shortcomings for your team feature requests can be opened,e tc
[15:47] <marcoceppi> avladu: any reason why in particular? it's strongly discouraged given the schema changes and it's not guarenteed to work between releases
[15:48] <avladu> I just want to see if some relation ids are correct
[15:48] <avladu> judebug reasons only
[15:48] <avladu> debug reasons only
[15:49] <marcoceppi> avladu: there's a python tools called juju-dbinspect which will allow you to connect to the mongodb and pull data out with Python
[15:49] <marcoceppi> avladu: https://github.com/kapilt/juju-dbinspect
[15:49] <avladu> marcoceppi: thanks
[15:49] <marcoceppi> alternatively, you can just `juju ssh 0` then connect to the mongo instance running there
[15:51] <avladu> marcoceppi: yes, I have done: juju ssh 0
[15:51] <avladu> marcoceppi: I do not know the credentials to connect to the jujudb
[15:55] <marcoceppi> avladu: that information is stored somewhere... not entirely sure, but the juju-dbinspect gets you around that
[15:56] <lazyPower> nice session jcastro
[15:56] <jcastro> ugh local provider
[15:57] <lazyPower> yeah, minor snafu
[15:59] <jose> and when lazyPower wanted it to fail, it didn't
[15:59]  * lazyPower flips tables
[16:17] <avladu> marcoceppi: thanks, with a few hacks, the juju-dbinspect worked
[16:27] <jcastro_> lazyPower, remind me, did you solve your logstash problem or just figure out what was wrong?
[16:27] <jcastro_> iirc a version mismatch?
[16:29] <alexisb> jcastro_, rick_h_, do you guys have some slides for the roadmap discussion?
[16:29] <alexisb> for UDS
[16:29] <alexisb> I am trying to figure out how I should prep
[16:29] <jcastro_> some people do slides, other just do a status report
[16:30] <jcastro_> up to you
[16:30] <rick_h_> alexisb: I was just going to walk through and try to demo a little bit.
[16:44] <bloodearnest> I assume you guys know that upstream lxc has go bindings to the lxc api?
[16:57] <lazyPower> jacekn: i figuredo ut what was wrong, i have WIP on fixing it
[16:57] <lazyPower> s/jacekn/jcastro/
[17:14] <jcastro> marcoceppi, I'll need you at the top of the hour for "State of the Charm Store"
[17:30] <sparkiegeek> lazyPower: cory_fu: hi there, do you think you'll get a chance to look over https://bugs.launchpad.net/charms/+bug/942032 this week?
[17:30] <_mup_> Bug #942032: Charm Needed: Review Board <Juju Charms Collection:Fix Committed by adam-collard> <https://launchpad.net/bugs/942032>
[17:30] <lazyPower> sparkiegeek: you bet!
[17:31] <lazyPower> I'll promote it to first thing when i switch off from what i'm working on and move back into the rev queue
[17:31] <sparkiegeek> lazyPower: excellent :) looking forward to seeing the feedback
[17:37] <jose> sparkiegeek: I'll go ahead and do a community review at the moment (I'm not a charmer), taking a look at it
[17:37] <sparkiegeek> jose: ah great, any and all reviews gratefully received
[17:38] <jose> :)
[17:38] <alexisb> jcastro, rick_h_, I know have a conflict for the 15:00 UTC time
[17:38] <alexisb> would it be possible to move the UDS gui/core roadmap session to 16:00 UTC?
[17:39] <jcastro> otp, one sec
[17:39] <alexisb> or up to 13:00 UTC
[17:39] <jcastro> arosales, can you move it?
[17:39] <alexisb> nws
[17:40] <arosales> I can take a look
[17:40] <sparkiegeek> I had some trouble using Amulet with the PostgreSQL charm. The latter has a concept of "allowed_units" which charms that relate to it should poll to see if $UNIT_NAME is in.
[17:41] <sparkiegeek> the way Amulet inserts sentries between the two relating services means it'll never see it's own UNIT_NAME in allowed_units
[17:42] <lazyPower> sparkiegeek: its not a perfect solution, and thats oen we are aware of
[17:42] <lazyPower> theres a project called juju-db-inspect that we are looking at dropping in to aid in relationship inspection vs using sentries
[17:43] <arosales> alexisb: are you free at 16:00 UTC on Wed?
[17:43] <sparkiegeek> lazyPower: ok, sounds interesting
[17:43] <lazyPower> sparkiegeek: because it is a bit troublesome that the sentry can interfear with the relationships being defined.
[17:43] <sparkiegeek> lazyPower: indeed
[17:43] <arosales> alexisb: looking at switching "Juju with LXC containers for local dev" with "Juju Core and GUI Roadmap"
[17:44] <alexisb> arosales, thanks
[17:44] <arosales> alexisb: so to confirm that time slot works for you, correct?
[17:44] <alexisb> yes it does
[17:45] <arosales> ok
[17:47] <jose> what's the next charm store session going to cover?
[17:52] <marcoceppi> jose: ack
[17:52] <marcoceppi> jcastro: ack
[17:57] <jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYdk_oApTaoYDWAv5eeR9zK3n8oUHTI8sE1WL4RptTN0lOaLpQ?authuser=0&hl=en
[17:57] <jcastro> marcoceppi, ^^^
[17:57] <marcoceppi> jcastro: ack
[17:57] <jcastro> and whoever wants to join
[18:02] <jose> jcastro: what's the topic on this one?
[18:03] <alexisb> arosales, let me know if you were able to make the switch, otherwise I will have to try and delegate the core roadmap discussion
[18:05] <jose> sparkiegeek: mind a PM?
[18:05] <arosales> alexisb: the schedule is locked so I am pinging mhall119
[18:05] <sparkiegeek> jose: WFM
[18:05] <mhall119> arosales: it's not locked, track leads can edit it
[18:06] <arosales> mhall119: ah looks like jcastro or marcoceppi will have to make the edit
[18:06] <arosales> mhall119: thanks. I forgot I wasn't a lead this go around
[18:06] <mhall119> arosales: yeah, you're only a lead on Ubuntu Development, if it's a devops session they can do it
[18:06] <mhall119> arosales: also,sorry for the delay in replying, was hosting Mark's keynote
[18:07] <arosales> mhall119: no worries
[18:08] <arosales> mhall119: could i bug you to switch or add me as a lead to the Cloud DevOps?
[18:09] <mhall119> arosales: sure
[18:09] <arosales> mhall119: thanks
[18:09] <mhall119> give me one minute to do that
[18:10] <arosales> mhall119: ok thanks
[18:12] <mhall119> arosales: done
[18:13] <arosales> mhall119: thanks
[18:13] <arosales> :-)
[18:21] <arosales> alexisb: all set for wed
[18:22] <arosales> thanks again mhall119 :-)
[18:22] <alexisb> arosales, your the man, thank you!
[18:23] <arosales> alexisb: no worries, easy fix
[19:01] <jose> mbruzek: you know how to run a test in an already bootstrapped env, with constraints?
[19:16] <mbruzek> jose you might be able to put the constraints in the Deployer class
[19:16] <mbruzek> method
[19:16] <jose> oh, thanks
[19:17] <mbruzek> I don't think I have done constraints within Amulet yet.
[19:17] <mbruzek> if you can't find it please let me know.
[19:19] <mbruzek> jose It might be possible to set constraints in bootstrap and then all future deploys will have same constraints
[19:19] <mbruzek> https://juju.ubuntu.com/docs/charms-constraints.html#working-with-constraints
[19:21] <jose> I'll check then :)
[19:30] <jcastro> marcoceppi, let's talk local template lock LXC-hates me
[19:30] <marcoceppi> okay
[19:30] <marcoceppi> hangout or in here?
[19:31] <jcastro> either
[19:31] <jcastro> actually, hangout
[19:31] <jcastro> go to the daily standup hangout
[19:33] <jose> jcastro: session set up, youtube set up, will set up the page tomorrow morning
[20:31] <sebas5384> lazyPower: ping
[20:39] <lazyPower> sebas5384: pong
[20:39] <sebas5384> lazyPower: hey!
[20:39] <lazyPower> Whats up?
[20:40] <sebas5384> we sell the first juju project! :)
[20:40] <sebas5384> to a client hehe
[20:40] <lazyPower> Thats awesome news!
[20:40] <lazyPower> congrats
[20:40] <sebas5384> so now i can be actually working in something thats goes to production
[20:40] <sebas5384> yeah! thanks! :)
[20:40] <sebas5384> so thats why i was lost these days
[20:41] <lazyPower> np :)
[20:41] <lazyPower> I've been occupied i assure you
[20:41] <sebas5384> yeah i imagine!
[20:42] <sebas5384> but hey! we must have our meeting to talk about vagrant and juju
[20:42] <sebas5384> and other devops stuff hehe
[20:42] <lazyPower> can we schedule it for end of week again? UDS has set me back in terms of time
[20:43] <sebas5384> yeah absolutely :)
[20:43] <sebas5384> let's talk trough the week then
[20:48] <lazyPower> sebas5384: surely
[21:55] <sebas5384> cmars: ping
[21:55] <cmars> sebas5384, pong
[21:55] <sebas5384> hey! cmars o/
[21:55] <cmars> hi
[21:55] <sebas5384> i'm doing a drupal charm in ansible
[21:55] <cmars> oh, neat
[21:56] <cmars> i really like the ansible helpers
[21:56] <sebas5384> and i wonder if you can help me with a doubt
[21:56] <sebas5384> yeah!! thank you for your work on ansible+charms
[21:56] <sebas5384> :)
[21:56] <sebas5384> well
[21:57] <sebas5384> the thing is i was reading the helper code
[21:57] <cmars> oh, that's not mine..
[21:57] <sebas5384> to whats all about the tags
[21:57] <cmars> i'm just a fan
[21:57] <sebas5384> ooh hehe
[21:57] <sebas5384> yeah thats right duh!!
[21:57] <sebas5384> hehe
[21:58] <sebas5384> sorry about that
[21:59] <cmars> no, i just don't want to take the credit. you should thank noodles775
[21:59] <cmars> :)
[21:59] <sebas5384> well the doubt i have is, there's some way i can declare some default tags for the playbook
[21:59] <sebas5384> thanks noodles775 !! :)
[21:59] <sebas5384> hehe
[22:00] <sebas5384> btw here is the repo https://github.com/sebas5384/charm-drupal
[22:00] <sebas5384> :)
[22:00] <sebas5384> maybe noodles775 can help me with these then :P
[22:01] <cmars> you might be able to find help in #ansible as well. could be a way to set tags in the ansible env
[22:01] <sebas5384> yeah i was looking some info about that
[22:02] <sebas5384> thanks cmars :)
[22:02] <sebas5384> oh! and i didn't forgot to do the changes in the pull request for the juju-nat
[22:02] <sebas5384> i'm still going to do that, just need time hehe