| _mup_ | ensemble/machine-with-type r337 committed by kapil.thangavelu@canonical.com | 00:59 |
|---|---|---|
| _mup_ | machine state includes provider type | 00:59 |
| kim0 | Hey folks .. is LXC deployment actually working right now | 12:23 |
| kim0 | Another questions, is Ensemble known to run successfully client-side and cloud-side on Ubuntu 10.04+ ? | 12:34 |
| hazmat | kim0, no to both | 13:28 |
| hazmat | kim0, there used to be some compatible fixes for 10.04 cloud-init, but those got yanked, so it no longer works | 13:28 |
| kim0 | hazmat: so supported versions are 11.04+ ? | 13:29 |
| hazmat | the lxc work is in dev, i'm hoping to get it to a testing state for those who want to try off a branch by the end of the week, but first plumbers | 13:29 |
| kim0 | client and cloud ? | 13:29 |
| hazmat | kim0, for client 10.04 is fine | 13:29 |
| hazmat | for the cloud portion we need 11.04 or newer | 13:29 |
| kim0 | got it | 13:29 |
| kim0 | thanks | 13:29 |
| hazmat | np | 13:29 |
| hazmat | kim0, are you going to be at plumbers? | 13:29 |
| kim0 | nope | 13:30 |
| kim0 | Dustin is however | 13:30 |
| hazmat | kim0, oh.. i thought you where co-track lead? | 13:30 |
| hazmat | k | 13:30 |
| fwereade | hazmat: btw, I have done my best to review everything, but I ended up a bit tired by the time I got to bcsaller's LXC branch -- can I ask you to pick that one up please? | 13:50 |
| hazmat | fwereade, absolutely | 13:52 |
| hazmat | fwereade, also fwiw today's a national holiday in the us | 13:52 |
| fwereade | hazmat, cheers :) | 13:52 |
| fwereade | hazmat: ah, I missed that | 13:52 |
| hazmat | so the review queue might be sitting through till tomorrow.. i'll try to dig into some of that today though | 13:52 |
| fwereade | hazmat: no rush, I don't mean to demand you work on a day off ;) | 13:53 |
| hazmat | i'm going to spend most of the day getting ready for a presentation on wednesday anyways | 13:53 |
| hazmat | fwereade, no worries, wasn't planning on taking the day off | 13:53 |
| * niemeyer waves | 15:17 | |
| fwereade | niemeyer: heyhey | 15:18 |
| fwereade | niemeyer: hope you're ok? | 15:18 |
| niemeyer | fwereade: Yeah, mostly alright | 15:19 |
| fwereade | glad to hear it :) | 15:20 |
| niemeyer | fwereade: Thanks to modern medicine :-) | 15:35 |
| fwereade | niemeyer: what happened? | 15:36 |
| niemeyer | fwereade: Fuzzed around with a minor tooth issue a bit too much and made it into a bigger issue | 15:37 |
| fwereade | niemeyer: ouch :( | 15:37 |
| fwereade | niemeyer: I'd been vaguely wondering if you were, I dunno, into extreme mountain fighting or something ;) | 15:38 |
| niemeyer | fwereade: Haha, no.. I might feel less silly if that was the case, though :-) | 15:39 |
| niemeyer | fwereade: Thanks for the docstring changes | 16:03 |
| niemeyer | fwereade: Very nice to have it being standardized | 16:03 |
| niemeyer | fwereade: I'm slightly concerned it might be going overboard in terms of syntax in some cases.. not sure if the benefit of the linkage is worth the reduced readability in the code itself | 16:04 |
| niemeyer | fwereade: Simple example: | 16:04 |
| niemeyer | - @param instance_id: instance_id of the `ProviderMachine` you want. | 16:05 |
| niemeyer | vs. | 16:05 |
| niemeyer | 316+ :param str instance_id: :attr:`instance_id` of the | 16:05 |
| niemeyer | 317+ :class:`ensemble.machine.ProviderMachine` you want. | 16:05 |
| hazmat | it reads better html | 16:13 |
| niemeyer | hazmat: Yeah, I'm just not sure if the benefit of the linkage in HTML is worth the reduced readability in the code itself | 16:22 |
| niemeyer | hazmat: I suspect we'll be reading the code more often than the HTML | 16:23 |
| hazmat | niemeyer, yeah.. that particular example is a bit obtuse | 16:23 |
| hazmat | and self referential | 16:23 |
| fwereade | I did wonder about that, but I found it very hard to justify not having stuff linked if it were there | 16:25 |
| fwereade | I felt on balance that the awesomeness of the linkage made up for the ugliness of the code, for the simple reason that when we're reading the code we're reading the *code* -- I trust docstrings about as much as I trust comments, which is to say not at all ;) | 16:27 |
| fwereade | and so I end up viewing the docstrings as targeted more to a reader of the docs than a reader of the code | 16:27 |
| hazmat | fwereade, instance_id = opaque string identifier specific to the provider | 16:27 |
| hazmat | fwereade, where you able to build the html output? | 16:28 |
| fwereade | I was, yes, are yu having problems? | 16:28 |
| hazmat | fwereade, haven't tried.. jim mentioned some issue, wasn't clear if it was endemic or not | 16:28 |
| hazmat | fwereade, was that with the code linked using autodoc? | 16:29 |
| fwereade | hazmat: I didn't end up hitting jim's issue, so I'm not sure if it's waiting to trip me up as I rationalise the rest, or whether it was just an artifact of his approach | 16:29 |
| niemeyer | Will get some "food".. biab | 16:29 |
| hazmat | niemeyer, cheers | 16:29 |
| fwereade | hazmat: instance_id -- yes, I know; but I don't follow your train of thought | 16:30 |
| fwereade | hazmat: they're also how we identify machines at the provider level | 16:30 |
| hazmat | fwereade, ah.. i think i missed the context of the diff | 16:30 |
| hazmat | i thought that was on a provider machine, but ic now its actually more likely get_machine | 16:31 |
| fwereade | hazmat: I'd be sympathetic to an approach in which we used machine_id throughout, but it doesn't seem very convenient atm ;) | 16:31 |
| hazmat | fwereade, but you are using autodoc when building the html output? | 16:31 |
| fwereade | hazmat: yes, but I have a little script that does more than and less than that script jim linked the other day to build the structure we want | 16:32 |
| fwereade | hazmat: I output a very few directives basically just saying "autodoc this module here" | 16:32 |
| fwereade | hazmat: but the resulting structure is (IMO) nicer, and tests get excluded withot enormous hassle | 16:33 |
| fwereade | hazmat: anyway, I must dash, ttyl :) | 16:35 |
| * hazmat lunches | 16:44 | |
| hazmat | fwereade, cheers | 16:44 |
| hazmat | niemeyer, the formulas/ -> formulas- change was to accomodate openstack's s3server which didn't like the "/" separator on a key name | 18:06 |
| hazmat | i'm not entirely sure why as the trunk code of it, seems to do the right thing with the key (hash on key name b4 store in dir).. its possible its interacting poorly with the route dispatch logic | 18:07 |
| hazmat | but it seemed more expedient to change our storage key then pushing the fixes upstream... | 18:07 |
| hazmat | kirkland, ping | 18:09 |
| niemeyer | hazmat: WTF, seriously? | 18:13 |
| hazmat | niemeyer, indeed | 18:13 |
| niemeyer | hazmat: Cool, thanks for the explanation.. +1 | 18:14 |
| hazmat | niemeyer, its the bug where upstream explicitly noted s3 compatibility isn't a goal.. https://bugs.launchpad.net/nova/+bug/829880 | 18:14 |
| _mup_ | Bug #829880: object store doesn't like key with '/' <Ensemble:Triaged by hazmat> <OpenStack Compute (nova):Confirmed> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/829880 > | 18:14 |
| niemeyer | hazmat: Yeah, it's just not clear anymore why we're even talking about S3 in this context now | 18:15 |
| hazmat | niemeyer, well it is *just* enough s3 for ec2 compatibility.. which is all ensemble needs as well atm.... | 18:16 |
| niemeyer | hazmat: Yeah, I commented on it even.. it just wasn't so obvious to me until now that it's another beast entirely | 18:16 |
| hazmat | ah | 18:16 |
| * hazmat gets back to work on his presentation | 18:17 | |
| hazmat | niemeyer, also fwiw, i'll be offline most of tomorrow morning, entransit to plumbers | 18:18 |
| niemeyer | hazmat: Sounds great, thanks for your assistance today, btw | 18:20 |
| thebishop | hello, I'm interested in the new "Orchestra" feature. I know it's not the primary use, but can Orchestra be used as a Proxmox "private cloud" replacement as well? | 18:35 |
| hazmat | thebishop, proxmox ve looks like a commericial ovirt?... orchestra+ensemble+openstack is effectively auto private cloud provisioning.. its not clear what exactly proxmox ve is doing outside of providing a web ui ontop of a virt mechanism (kvm or openvz) | 18:42 |
| hazmat | ah.. ic http://pve.proxmox.com/wiki/Vision | 18:43 |
| hazmat | so ensemble does real encapsulation at a service level instead of just virtual image appliance management | 18:44 |
| hazmat | but it doesn't include backup/restore builtin or live migration atm | 18:44 |
| hazmat | lxc support for the latter features is still in the works | 18:45 |
| hazmat | ugh.. i really want to use the local dev for the talk | 19:51 |
| _mup_ | ensemble/machine-with-provider-type r359 committed by kapil.thangavelu@canonical.com | 19:55 |
| _mup_ | pull machine-with-type into local dev pipeline | 19:55 |
| _mup_ | ensemble/no-regex-option r338 committed by gustavo@niemeyer.net | 20:07 |
| _mup_ | Dropped unused class var, as pointed out by William. | 20:07 |
| _mup_ | ensemble/trunk r337 committed by gustavo@niemeyer.net | 20:10 |
| _mup_ | Merged no-regex-option branch [r=fwereade,hazmat] | 20:10 |
| _mup_ | This removes the regex configuration type, and renames 'str' to 'string'. | 20:10 |
| _mup_ | For the second change, it also introduces backwards compatibility logic | 20:10 |
| _mup_ | so that we can continue to work with 'str' for the moment while we warn | 20:10 |
| _mup_ | authors to move out of it. | 20:10 |
| === andreas__ is now known as ahasenack | ||
| _mup_ | ensemble/trunk r338 committed by gustavo@niemeyer.net | 20:18 |
| _mup_ | Merged simplify-iface-schema branch [r=hazmat,fwereade] | 20:18 |
| _mup_ | Minor simplification in the implementation of the interface schema. | 20:18 |
| _mup_ | ensemble/go r3 committed by gustavo@niemeyer.net | 20:35 |
| _mup_ | Merged go-iface-schemas branch [r=fwereade,hazmat] | 20:35 |
| _mup_ | This kicks off the formula schema support in the Go port. | 20:35 |
| _mup_ | ensemble/go r4 committed by gustavo@niemeyer.net | 20:43 |
| _mup_ | Merged go-initial-formula-meta branch [r=fwereade,hazmat] | 20:43 |
| _mup_ | This introduces metadata.yaml parsing in the Go port. | 20:43 |
| _mup_ | ensemble/go r5 committed by gustavo@niemeyer.net | 20:46 |
| _mup_ | Merge go-rename-short-types branch [r=hazmat,fwereade,jkakar] (!) | 20:46 |
| _mup_ | This makes the schema.M/L types more readable, as suggested by Kapil. | 20:46 |
| _mup_ | ensemble/go r6 committed by gustavo@niemeyer.net | 20:48 |
| _mup_ | Merged go-final-formula-meta branch [r=fwereade,hazmat] | 20:48 |
| _mup_ | This completes the parsing of metadata.yaml in the Go port. | 20:48 |
| _mup_ | ensemble/go-formulas r14 committed by gustavo@niemeyer.net | 21:44 |
| _mup_ | Added formula(_test).go files with the generic bits that were | 21:44 |
| _mup_ | all together in meta.go at first. | 21:44 |
| _mup_ | ensemble/go-formulas r15 committed by gustavo@niemeyer.net | 22:31 |
| _mup_ | Implemented initial config parsing. No variable validation using the | 22:31 |
| _mup_ | parsed schema yet. | 22:31 |
| _mup_ | Bug #842195 was filed: config.yaml handling is necessary in Go port <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/842195 > | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!