=== scuttlemonkey is now known as scuttle|afk === urulama-afk is now known as urulama === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [09:53] 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] frankban: see bug 1374335 [09:53] 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

[09:55] 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] Bug #1359938: [FFE] request to update juju-quickstart to support JUJU env var [09:57] frankban: that depends. Are the versions stated actually required? [09:58] 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] rbasak: we usually use >= with versions in deb packages [10:00] rbasak: for development builds (in a virtualenv) we usually have precise versions for reproducible builds [10:01] 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] 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] rbasak: so quickstart assumes websocket-client==0.18.0 and jujuclient==0.18.4 are in utopic [10:05] well, >= [10:07] 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] frankban: backwards incompatible changes are worrying [10:15] frankban: that could impact the FFe [10:16] (for websocket-client) [10:16] Since there are other packages that depend on it too, and they could be impacted. [10:17] 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] perhaps hazmat could provide more info [10:17] python-docker also depends on python-websocket [10:18] If we update websocket-client, will we break python-docker? [10:21] frankban: apart from a newer websocket-client, does juju-quickstart 1.4.4 need a newer version of anything else? [10:22] rbasak: the new python-jujuclient has some bug fixes, so I'd say yes, quickstart needs that too [10:23] rbasak: urwid 1.2.1 is already in utopic universe [10:23] so yes, basically websocket-client and jujuclient are required [10:23] Yeah the others look like they're present. But I still want to know what versioned dependency I need to declare. [10:23] This is important especially for any future backport to Trusty. [10:29] 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] 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] rbasak: ok thanks [10:30] 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] rbasak: ack, thank you for looking at those [10:47] rbasak, incompatible? [10:48] 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] in utopic. the delta from 0.16 to 0.18.0 is just bug fixes [10:49] rbasak, jujuclient needs 0.18.0 there are some fixes in that release i contributed upstream specifically for it. [10:50] hazmat: cool SSL enforcement is what I was wondering about [10:51] 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] hazmat: that includes the other reverse depends that I know little about - python-docker and python-socketio-client. [10:52] hazmat: could you please update bug 1374335? [10:52] 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

[10:52] 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] rbasak, i'll double checkk them [10:53] Thanks! [10:53] re python-docker, python-socketio-client [11:25] gnuoy, vxlan support landed [11:36] gnuoy, looking at cells now [12:02] 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] hazmat: thanks. No rush - we'll need the FFes approved also before I can do anything. [12:20] gnuoy, I appear to have a nova cells based deployed running :-) [12:36] jamespage, \o/ [12:38] gnuoy, although the updates in openstack-charm-helpers for vxlan break gre configuration [12:38] gnuoy, hmm [12:45] gnuoy, hows scheduling dealt with when all of the hypervisors in a given cell are at capacity? [12:46] 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] or some of that may be delegated with grandchildren I guess [12:47] why anyone would do a grandchild deploy beats me [12:56] gnuoy, to layer up the message busses without overloading to much on the top layer [12:57] 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] gnuoy, I was generating instances in series [12:57] jamespage, but with the trade off that losing a parent cell kill off its descendants [12:59] gnuoy, so this is quite awesome work btw [12:59] I have a few questions [12:59] fire away (and thanks :-) ) [12:59] but I need to get a coffee first [12:59] sure [13:22] rbasak, k, out of curiosity what are the rdepends on python-socketio-client [13:22] hazmat: I couldn't see any [13:22] I'm not sure why that's packaged (in Debian) [13:34] rbasak, the unit tests for it are dependent on a bitrotted nodejs socket server being setup manually outside of the tests. [13:42] rbasak, yeah.. there are tons of open issues that this python-socketio-client is broken with the socketio 1.0 spec [13:59] rbasak, added comments to the issue [14:00] gnuoy, sorry got distracted [14:01] gnuoy, back in a min [14:02] hazmat: thanks, that's very useful. [14:05] 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] marcoceppi: It is realiable? [14:06] gnuoy, I think the nova-api relation is redundant right (nova-cell charm) [14:06] 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] 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] ?* [14:08] 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] ayr-ton: if you're going to be doing openstack for real, you're going to want about 8-10 machines [14:15] marcoceppi, ayr-ton: hmm - I disagree [14:15] that really depends on how many compute nodes you need [14:15] (8-10) machines [14:17] 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] ayr-ton, if you have a single beefy machine doing a virtual maas (libvirt kvm) is also visable. [14:21] viable [14:21] dinosaursareforever.blogspot.com/2014/06/manually-deploying-openstack-with.html [14:27] hmmm [14:28] 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] And a MAAS master? [14:29] And put a lot of things inside lxc? [14:29] Except nova-compute. === roadmr is now known as roadmr_afk [15:22] hazmat: One other question, is safe to use nested virtualization? As dinosaur post suggest? [15:22] ayr-ton, if your hw supports it sure, its super slow though [15:22] ayr-ton, in terms of running anything on the guest [15:30] Hi, [15:31] I'm going to illustrate about What I mean: [15:31] https://nodebb.org/pricing [15:31] https://payments.discourse.org/buy/ [15:31] https://payments.discourse.org/buy/ [15:31] etc === scuttle|afk is now known as scuttlemonkey [15:33] frenda: what do you mean? [15:33] These open source applications have a hosted solution which make an isolated installation per user [15:33] Now [15:33] Can juju do something for my app? [15:33] something like them* [15:35] I mean can I use juju for ato-installation? [15:35] 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] 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] What I get: 1. I can install juju under my servers 2. I can make an auto-installation process for my app [15:38] 3. Then, can user use my installed juju to install my app as a charm; user by user? [15:39] As I can see here: https://jujucharms.com/precise/ghost-0/machine/?text=ghost (i.e.), I can create mine! true? [15:41] Is https://jujucharms.com an open source software? [15:41] frenda: yes, https://github.com/juju/juju-gui [15:42] frenda: development is in #juju-gui if you have any questions or need a hand with anything [15:43] rick_h_, marcoceppi: thanks === roadmr_afk is now known as roadmr [16:54] /msg NickServ help [16:54] /msg help [16:55] whois elujin [17:25] hey kwmonroe [17:25] 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] ack jcastro [18:50] yo jose [18:50] how do we do this UOA thing? [18:51] marcoceppi, tvansteenburgh: wanna hop on in a minute? [18:51] jcastro: I'm ready when you are [18:52] jcastro: be there in a min [18:53] firing it up now [18:54] https://plus.google.com/hangouts/_/hoaevent/AP36tYeqonNeIc-w5qNIq-whPk66nYi98w62Y1gpuwsag-owcyO3gw?authuser=0&hl=en [18:58] http://youtu.be/VMHNi67htM0 if you just want to follow along. === CyberJacob|Away is now known as CyberJacob [19:02] 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] natefinch: if you find anything please let me know as I have a big interest in that for some project stuff [19:07] 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] jcastro: https://juju.ubuntu.com/docs/tools-amulet.html [19:11] (git blame cmd/juju/help_topics.go can attest to that ;) === CyberJacob is now known as CyberJacob|Away [19:12] jcastro ^ link to Amulet tests [19:12] ack [19:12] documenation === CyberJacob|Away is now known as CyberJacob === roadmr is now known as roadmr_afk [19:20] marcoceppi, you went dark [19:20] jcastro: sound went out [19:20] reloading [19:21] hangouts isn't loading anymore [19:21] doh [19:21] pkill your chrome processes [19:21] and doublecheck for zombies [19:22] inbound [19:24] #ubuntuOnAir Charm testing url: http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html [19:25] this is rediculous === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === scuttlemonkey is now known as scuttle|afk === scuttle|afk is now known as scuttlemonkey === fuzzy is now known as Ponyo === Ponyo is now known as Fuzai === Fuzai is now known as Ponyo === roadmr_afk is now known as roadmr === scuttlemonkey is now known as scuttle|afk [21:09] more and more we are gonna see SOA's, so an OpenTSDB charm would be awesome! :) just saying... === sebas538_ is now known as sebas5384 === scuttle|afk is now known as scuttlemonkey === scuttlemonkey is now known as scuttle|afk