[09:53] <rbasak> frankban: I'm looking at juju-quickstart 1.4.4. It looks like dependencies have been bumped? We don't have a new enough websocket-client nor jujuclient in Utopic right now.
[09:53] <rbasak> frankban: see bug 1374335
[09:53] <mup> Bug #1374335: FFe: Sync websocket-client 0.18.0-1 (universe) from Debian unstable (main), juju-deployer 0.4.2, python-jujuclient 0.18.4 <juju-deployer (Ubuntu):New> <python-jujuclient (Ubuntu):New> <websocket-client (Ubuntu):New> <https://launchpad.net/bugs/1374335>
[09:55] <frankban> rbasak: yes, I mentioned it in bug 1359938 . we was told that those will be the versions of websocket-client/python-jujuclient in utopic, and so we reflected that. so I guess the exceptions are blocked until we have those in utopic?
[09:55] <mup> Bug #1359938: [FFE] request to update juju-quickstart to support JUJU env var <juju-quickstart (Ubuntu):New> <https://launchpad.net/bugs/1359938>
[09:57] <rbasak> frankban: that depends. Are the versions stated actually required?
[09:58] <rbasak> I don't understand why the version numbers are stated to match exactly. What if one of the dependencies needs a security update. Wouldn't that break it?
[10:00] <frankban> rbasak: we usually use >= with versions in deb packages
[10:00] <frankban> rbasak: for development builds (in a virtualenv) we usually have precise versions for reproducible builds
[10:01] <rbasak> frankban: OK, so do I need to bump the deb package version dependencies here, or will everything work with any version of the dependencies?
[10:04] <frankban> rbasak: I think we need to bump the version of the dependencies. unfortunately the expected utopic version of websocket-client includes backward incompatible changes, so we needed to reflect those changes
[10:05] <frankban> rbasak: so quickstart assumes websocket-client==0.18.0 and jujuclient==0.18.4 are in utopic
[10:05] <frankban> well, >=
[10:07] <frankban> rbasak: I built those dependencies (and quickstart 1.4.4 as well) in the juju stable ppa FWIW: https://launchpad.net/~juju/+archive/ubuntu/stable/+packages
[10:15] <rbasak> frankban: backwards incompatible changes are worrying
[10:15] <rbasak> frankban: that could impact the FFe
[10:16] <rbasak> (for websocket-client)
[10:16] <rbasak> Since there are other packages that depend on it too, and they could be impacted.
[10:17] <frankban> rbasak: the public API of websocket client did not change a lot, IIRC it's mostly a change in how wss certs are handled by default
[10:17] <frankban> perhaps hazmat could provide more info
[10:17] <rbasak> python-docker also depends on python-websocket
[10:18] <rbasak> If we update websocket-client, will we break python-docker?
[10:21] <rbasak> frankban: apart from a newer websocket-client, does juju-quickstart 1.4.4 need a newer version of anything else?
[10:22] <frankban> rbasak: the new python-jujuclient has some bug fixes, so I'd say yes, quickstart needs that too
[10:23] <frankban> rbasak: urwid 1.2.1 is already in utopic universe
[10:23] <frankban> so yes, basically websocket-client and jujuclient are required
[10:23] <rbasak> Yeah the others look like they're present. But I still want to know what versioned dependency I need to declare.
[10:23] <rbasak> This is important especially for any future backport to Trusty.
[10:29] <rbasak> frankban: OK, I've updated the bugs. I don't think it's worth testing except against the newer versions, so I'll leave it for now. We need those FFes approved and the newer version dependencies uploaded, and then I can look again.
[10:29] <frankban> rbasak: so our expectations were that websocket client >= 0.18.0 and jujuclient >= 0.18.4 are in utopic. for this reason, we updated quickstart to support and run on those new dependencies, and we tested quickstart 1.4.3 and 1.4.4 with those. I can quickly check if quickstart still works and tests pass after downgrading jujuclient and websocket client to trusty versions if you want
[10:29] <frankban> rbasak: ok thanks
[10:30] <rbasak> frankban: trouble is, given that there are changes that matter, we'd need to test again before bumping the dependencies. So probably best get a decision made on the FFes first.
[10:31] <frankban> rbasak: ack, thank you for looking at those
[10:47] <hazmat> rbasak, incompatible?
[10:48] <hazmat> rbasak, its actually forward compatible changes to python 3 for the most part. the pin to 0.12 previously was because it started doing ssl enforcement, but we already had 0.16 from debian that had that.
[10:48] <hazmat> in utopic. the delta from 0.16 to 0.18.0 is just bug fixes
[10:49] <hazmat> rbasak, jujuclient needs 0.18.0 there are some fixes in that release i contributed upstream specifically for it.
[10:50] <frankban> hazmat: cool SSL enforcement is what I was wondering about
[10:51] <rbasak> hazmat: I just need to know, given that we're way past feature freeze right now, that bumping the version is definitely not expected to break anything.
[10:52] <rbasak> hazmat: that includes the other reverse depends that I know little about - python-docker and python-socketio-client.
[10:52] <rbasak> hazmat: could you please update bug 1374335?
[10:52] <mup> Bug #1374335: FFe: Sync websocket-client 0.18.0-1 (universe) from Debian unstable (main), juju-deployer 0.4.2, python-jujuclient 0.18.4 <juju-deployer (Ubuntu):New> <juju-quickstart (Ubuntu):New> <python-jujuclient (Ubuntu):New> <websocket-client (Ubuntu):New> <https://launchpad.net/bugs/1374335>
[10:52] <rbasak> And then I just need the FFes to get approved, to know what versioned depends I should specify on juju-quickstart, and then I can test and upload.
[10:53] <hazmat> rbasak, i'll double checkk them
[10:53] <rbasak> Thanks!
[10:53] <hazmat> re python-docker, python-socketio-client
[11:25] <jamespage> gnuoy, vxlan support landed
[11:36] <jamespage> gnuoy, looking at cells now
[12:02] <hazmat> rbasak, so docker-py verified (0.3.2 which afaics is utopic version) with 0.18 websock-client .. still working on socketio-client there's some server dep for their tests i need to figure out.. out for the next hr on family errands. bbiab
[12:06] <rbasak> hazmat: thanks. No rush - we'll need the FFes approved also before I can do anything.
[12:20] <jamespage> gnuoy, I appear to have a nova cells based deployed running :-)
[12:36] <gnuoy> jamespage, \o/
[12:38] <jamespage> gnuoy, although the updates in openstack-charm-helpers for vxlan break gre configuration
[12:38] <jamespage> gnuoy, hmm
[12:45] <jamespage> gnuoy, hows scheduling dealt with when all of the hypervisors in a given cell are at capacity?
[12:46] <gnuoy> jamespage, cells capacities are reported back to the api cell. If a cell is full then requests should go to the next cell
[12:47] <gnuoy> or some of that may be delegated with grandchildren I guess
[12:47] <gnuoy> why anyone would do a grandchild deploy beats me
[12:56] <jamespage> gnuoy, to layer up the message busses without overloading to much on the top layer
[12:57] <jamespage> gnuoy, anyway - I think I hit some sort of race between nova pushing the scheduling request to a cell and it updating its capacity
[12:57] <jamespage> gnuoy, I was generating instances in series
[12:57] <gnuoy> jamespage, but with the trade off that losing a parent cell kill off its descendants
[12:59] <jamespage> gnuoy, so this is quite awesome work btw
[12:59] <jamespage> I have a few questions
[12:59] <gnuoy> fire away (and thanks :-) )
[12:59] <jamespage> but I need to get a coffee first
[12:59] <gnuoy> sure
[13:22] <hazmat> rbasak, k, out of curiosity what are the rdepends on python-socketio-client
[13:22] <rbasak> hazmat: I couldn't see any
[13:22] <rbasak> I'm not sure why that's packaged (in Debian)
[13:34] <hazmat> rbasak, the unit tests for it are dependent on a bitrotted nodejs socket server being setup manually outside of the tests.
[13:42] <hazmat> rbasak, yeah.. there are tons of open issues that this python-socketio-client is broken with the socketio 1.0 spec
[13:59] <hazmat> rbasak, added comments to the issue
[14:00] <jamespage> gnuoy, sorry got distracted
[14:01] <jamespage> gnuoy, back in a min
[14:02] <rbasak> hazmat: thanks, that's very useful.
[14:05] <ayr-ton> marcoceppi: One difficult question. I'm ready to start build the cloud for my project using openstack and juju. Do you think is a good idea do make a cluster with two intel nucs of 16GB for start?
[14:05] <ayr-ton> marcoceppi: It is realiable?
[14:06] <jamespage> gnuoy, I think the nova-api relation is redundant right (nova-cell charm)
[14:06] <ayr-ton> marcoceppi: And for the maas master, should I use a other machine for this? Or virtualize the maas master under one of the NUCs can be a start aproach?
[14:07] <ayr-ton> marcoceppi: Like, in this reference architecture: http://www.ubuntu.com/cloud/openstack/reference-architecture, how is the minimum specs for the first hypervisors.
[14:08] <ayr-ton> ?*
[14:08] <ayr-ton> At this moment, the best reference archicture for start, that I found, is that one: http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
[14:11] <marcoceppi> ayr-ton: if you're going to be doing openstack for real, you're going to want about 8-10 machines
[14:15] <jamespage> marcoceppi, ayr-ton: hmm - I disagree
[14:15] <jamespage> that really depends on how many compute nodes you need
[14:15] <jamespage> (8-10) machines
[14:17] <jamespage> ayr-ton, its possible to put most things under LXC using juju - apart from the quantum-gateway, ceph, swift-proxy and nova-compute charms
[14:20] <hazmat> ayr-ton, if you have a single beefy machine doing a virtual maas (libvirt kvm) is also visable.
[14:21] <hazmat> viable
[14:21] <hazmat> dinosaursareforever.blogspot.com/2014/06/manually-deploying-openstack-with.html
[14:27] <ayr-ton> hmmm
[14:28] <ayr-ton> hazmat: Okay. So if a have a big machine with a lot of ram, I could use a virtual maas. If I want to use NUCs, for example, except the ceph and etc, I could use two machines for start?
[14:29] <ayr-ton> And a MAAS master?
[14:29] <ayr-ton> And put a lot of things inside lxc?
[14:29] <ayr-ton> Except nova-compute.
[15:22] <ayr-ton> hazmat: One other question, is safe to use nested virtualization? As dinosaur post suggest?
[15:22] <hazmat> ayr-ton, if your hw supports it sure, its super slow though
[15:22] <hazmat> ayr-ton, in terms of running anything on the guest
[15:30] <frenda> Hi,
[15:31] <frenda> I'm going to illustrate about What I mean:
[15:31] <frenda> https://nodebb.org/pricing
[15:31] <frenda> https://payments.discourse.org/buy/
[15:31] <frenda> https://payments.discourse.org/buy/
[15:31] <frenda> etc
[15:33] <marcoceppi> frenda: what do you mean?
[15:33] <frenda> These open source applications have a hosted solution which make an isolated installation per user
[15:33] <frenda> Now
[15:33] <frenda> Can juju do something for my app?
[15:33] <frenda> something like them*
[15:35] <frenda> I mean can I use juju for ato-installation?
[15:35] <marcoceppi> juju can deploy these opensource apps, but it's all free (except for the cloud provider, you have to pay for the instances) but juju is a free and opensource software with no charge associated with it
[15:35] <marcoceppi> ah, auto-installation. You could, but it's not currently designed to do that. It does provide a websocket which you could use to automated deployments from something like this checkout page
[15:37] <frenda> What I get: 1. I can install juju under my servers 2. I can make an auto-installation process for my app
[15:38] <frenda> 3. Then, can user use my installed juju to install my app as a charm; user by user?
[15:39] <frenda> As I can see here: https://jujucharms.com/precise/ghost-0/machine/?text=ghost (i.e.), I can create mine! true?
[15:41] <frenda> Is https://jujucharms.com an open source software?
[15:41] <rick_h_> frenda: yes, https://github.com/juju/juju-gui
[15:42] <rick_h_> frenda: development is in #juju-gui if you have any questions or need a hand with anything
[15:43] <frenda> rick_h_, marcoceppi: thanks
[16:54] <elujin>  /msg NickServ help
[16:54] <elujin>  /msg help
[16:55] <elujin> whois elujin
[17:25] <jcastro> hey kwmonroe
[17:25] <jcastro> can you check this MP first when you start your shift? https://code.launchpad.net/~bloodearnest/charms/precise/squid-reverseproxy/trunk/+merge/235429
[17:26] <kwmonroe> ack jcastro
[18:50] <jcastro> yo jose
[18:50] <jcastro> how do we do this UOA thing?
[18:51] <jcastro> marcoceppi, tvansteenburgh: wanna hop on in a minute?
[18:51] <marcoceppi> jcastro: I'm ready when you are
[18:52] <tvansteenburgh> jcastro: be there in a min
[18:53] <jcastro> firing it up now
[18:54] <jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYeqonNeIc-w5qNIq-whPk66nYi98w62Y1gpuwsag-owcyO3gw?authuser=0&hl=en
[18:58] <jcastro> http://youtu.be/VMHNi67htM0 if you just want to follow along.
[19:02] <natefinch> anyone know if we actually have documentation of what values you can pass to juju set-environment?  and/or what can go into environments.yaml?
[19:05] <rick_h_> natefinch: if you find anything please let me know as I have a big interest in that for some project stuff
[19:07] <natefinch> rick_h_: I'm sure I can troll the source code to find it out.  It's sad that I have to do that.   I'll bring it up in Brussels and probably will spend time writing help docs for it.  Glaring deficiencies in help docs really bug me.
[19:11] <mbruzek> jcastro: https://juju.ubuntu.com/docs/tools-amulet.html
[19:11] <natefinch> (git blame cmd/juju/help_topics.go can attest to that ;)
[19:12] <mbruzek> jcastro ^ link to Amulet tests
[19:12] <jcastro> ack
[19:12] <mbruzek> documenation
[19:20] <jcastro> marcoceppi, you went dark
[19:20] <marcoceppi> jcastro: sound went out
[19:20] <marcoceppi> reloading
[19:21] <marcoceppi> hangouts isn't loading anymore
[19:21] <tvansteenburgh> doh
[19:21] <jcastro> pkill your chrome processes
[19:21] <jcastro> and doublecheck for zombies
[19:22] <marcoceppi> inbound
[19:24] <mbruzek> #ubuntuOnAir Charm testing url: http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html
[19:25] <marcoceppi> this is rediculous
[21:09] <sebas538_> more and more we are gonna see SOA's, so an OpenTSDB charm would be awesome! :) just saying...