| === 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 | ||
| 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:53 |
| 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:55 |
| rbasak | frankban: that depends. Are the versions stated actually required? | 09:57 |
| 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? | 09:58 |
| 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:00 |
| 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:01 |
| 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:04 |
| frankban | rbasak: so quickstart assumes websocket-client==0.18.0 and jujuclient==0.18.4 are in utopic | 10:05 |
| frankban | well, >= | 10:05 |
| 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:07 |
| rbasak | frankban: backwards incompatible changes are worrying | 10:15 |
| rbasak | frankban: that could impact the FFe | 10:15 |
| rbasak | (for websocket-client) | 10:16 |
| rbasak | Since there are other packages that depend on it too, and they could be impacted. | 10:16 |
| 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:17 |
| rbasak | If we update websocket-client, will we break python-docker? | 10:18 |
| rbasak | frankban: apart from a newer websocket-client, does juju-quickstart 1.4.4 need a newer version of anything else? | 10:21 |
| frankban | rbasak: the new python-jujuclient has some bug fixes, so I'd say yes, quickstart needs that too | 10:22 |
| 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:23 |
| 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:29 |
| 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:30 |
| frankban | rbasak: ack, thank you for looking at those | 10:31 |
| hazmat | rbasak, incompatible? | 10:47 |
| 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:48 |
| hazmat | rbasak, jujuclient needs 0.18.0 there are some fixes in that release i contributed upstream specifically for it. | 10:49 |
| frankban | hazmat: cool SSL enforcement is what I was wondering about | 10:50 |
| 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:51 |
| 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:52 |
| hazmat | rbasak, i'll double checkk them | 10:53 |
| rbasak | Thanks! | 10:53 |
| hazmat | re python-docker, python-socketio-client | 10:53 |
| jamespage | gnuoy, vxlan support landed | 11:25 |
| jamespage | gnuoy, looking at cells now | 11:36 |
| 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:02 |
| rbasak | hazmat: thanks. No rush - we'll need the FFes approved also before I can do anything. | 12:06 |
| jamespage | gnuoy, I appear to have a nova cells based deployed running :-) | 12:20 |
| gnuoy | jamespage, \o/ | 12:36 |
| jamespage | gnuoy, although the updates in openstack-charm-helpers for vxlan break gre configuration | 12:38 |
| jamespage | gnuoy, hmm | 12:38 |
| jamespage | gnuoy, hows scheduling dealt with when all of the hypervisors in a given cell are at capacity? | 12:45 |
| 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:46 |
| 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:47 |
| jamespage | gnuoy, to layer up the message busses without overloading to much on the top layer | 12:56 |
| 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:57 |
| 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 | 12:59 |
| 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:22 |
| hazmat | rbasak, the unit tests for it are dependent on a bitrotted nodejs socket server being setup manually outside of the tests. | 13:34 |
| hazmat | rbasak, yeah.. there are tons of open issues that this python-socketio-client is broken with the socketio 1.0 spec | 13:42 |
| hazmat | rbasak, added comments to the issue | 13:59 |
| jamespage | gnuoy, sorry got distracted | 14:00 |
| jamespage | gnuoy, back in a min | 14:01 |
| rbasak | hazmat: thanks, that's very useful. | 14:02 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| marcoceppi | ayr-ton: if you're going to be doing openstack for real, you're going to want about 8-10 machines | 14:11 |
| 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:15 |
| 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:17 |
| hazmat | ayr-ton, if you have a single beefy machine doing a virtual maas (libvirt kvm) is also visable. | 14:20 |
| hazmat | viable | 14:21 |
| hazmat | dinosaursareforever.blogspot.com/2014/06/manually-deploying-openstack-with.html | 14:21 |
| ayr-ton | hmmm | 14:27 |
| 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:28 |
| 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. | 14:29 |
| === roadmr is now known as roadmr_afk | ||
| 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:22 |
| frenda | Hi, | 15:30 |
| 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:31 |
| === scuttle|afk is now known as scuttlemonkey | ||
| 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:33 |
| 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:35 |
| frenda | What I get: 1. I can install juju under my servers 2. I can make an auto-installation process for my app | 15:37 |
| frenda | 3. Then, can user use my installed juju to install my app as a charm; user by user? | 15:38 |
| frenda | As I can see here: https://jujucharms.com/precise/ghost-0/machine/?text=ghost (i.e.), I can create mine! true? | 15:39 |
| frenda | Is https://jujucharms.com an open source software? | 15:41 |
| rick_h_ | frenda: yes, https://github.com/juju/juju-gui | 15:41 |
| rick_h_ | frenda: development is in #juju-gui if you have any questions or need a hand with anything | 15:42 |
| frenda | rick_h_, marcoceppi: thanks | 15:43 |
| === roadmr_afk is now known as roadmr | ||
| elujin | /msg NickServ help | 16:54 |
| elujin | /msg help | 16:54 |
| elujin | whois elujin | 16:55 |
| 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:25 |
| kwmonroe | ack jcastro | 17:26 |
| jcastro | yo jose | 18:50 |
| jcastro | how do we do this UOA thing? | 18:50 |
| jcastro | marcoceppi, tvansteenburgh: wanna hop on in a minute? | 18:51 |
| marcoceppi | jcastro: I'm ready when you are | 18:51 |
| tvansteenburgh | jcastro: be there in a min | 18:52 |
| jcastro | firing it up now | 18:53 |
| jcastro | https://plus.google.com/hangouts/_/hoaevent/AP36tYeqonNeIc-w5qNIq-whPk66nYi98w62Y1gpuwsag-owcyO3gw?authuser=0&hl=en | 18:54 |
| jcastro | http://youtu.be/VMHNi67htM0 if you just want to follow along. | 18:58 |
| === CyberJacob|Away is now known as CyberJacob | ||
| 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:02 |
| rick_h_ | natefinch: if you find anything please let me know as I have a big interest in that for some project stuff | 19:05 |
| 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:07 |
| 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:11 |
| === CyberJacob is now known as CyberJacob|Away | ||
| mbruzek | jcastro ^ link to Amulet tests | 19:12 |
| jcastro | ack | 19:12 |
| mbruzek | documenation | 19:12 |
| === CyberJacob|Away is now known as CyberJacob | ||
| === roadmr is now known as roadmr_afk | ||
| jcastro | marcoceppi, you went dark | 19:20 |
| marcoceppi | jcastro: sound went out | 19:20 |
| marcoceppi | reloading | 19:20 |
| 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:21 |
| marcoceppi | inbound | 19:22 |
| mbruzek | #ubuntuOnAir Charm testing url: http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html | 19:24 |
| marcoceppi | this is rediculous | 19:25 |
| === 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 | ||
| sebas538_ | more and more we are gonna see SOA's, so an OpenTSDB charm would be awesome! :) just saying... | 21:09 |
| === sebas538_ is now known as sebas5384 | ||
| === scuttle|afk is now known as scuttlemonkey | ||
| === scuttlemonkey is now known as scuttle|afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!