| vmorris | shouldn't no_proxy contain localhost? | 02:45 |
|---|---|---|
| gaurangt | we're facing an issue with MAAS while deploying a charm. The storage disk attached to the VM (sdb) is not getting picked up by the charm. The juju storage list always shows the disk status as pending. Any clues on what could be going wrong here? | 09:58 |
| gaurangt | the MAAS version we're using is 1.9 and that of juju is 2.0. | 09:58 |
| aluria | hi o/ -- I was looking for logstash plugins to parse juju logs -- I can't find none at https://www.elastic.co/guide/en/logstash/current/filter-plugins.html | 11:01 |
| === Guest91977 is now known as ahasenack | ||
| aluria | do you know if such plugin exists somewhere else? | 11:01 |
| === ahasenack is now known as Guest60864 | ||
| === Guest60864 is now known as ahasenack | ||
| === ahasenack is now known as Guest42345 | ||
| BlackDex | Hello there, i'm looking voor cholcombe or icey about the ceph-dash to get access to the private repo | 12:20 |
| === Spads_ is now known as Spads | ||
| autonomouse | hi folks, got a question about actions for anyone who wouldn't mind taking a shot: http://askubuntu.com/questions/842795/can-i-make-a-juju-action-pass-a-file-back-to-where-it-was-called-from | 12:59 |
| cholcombe | BlackDex, sure what's your launchpad id? | 14:40 |
| stokachu | can you not run 'config-set' in an action? | 15:37 |
| lazyPowe_ | stokachu - config-set isn't a thing. charms cannot set their own config | 15:39 |
| stokachu | if im running an action that upgrades a piece of software and i want to update the charm's config to reflect that what is the alternative? | 15:39 |
| lazyPowe_ | stokachu - unfortunately, charms cannot set their own config, that has to come from the operator | 15:40 |
| lazyPowe_ | i dont know that we have any examples for that pattern | 15:40 |
| === lazyPowe_ is now known as lazyPower | ||
| stokachu | lazyPowe_: so is preferred to update the actual software via actions? | 15:40 |
| stokachu | is it* | 15:40 |
| lazyPower | No, we tend to do that via config, or via resources. | 15:41 |
| stokachu | ok | 15:41 |
| lazyPower | stokachu - i would probably crib from the openstack charms for workflow there. they have a pretty solid upgrade story | 15:41 |
| stokachu | thanks | 15:42 |
| stokachu | i think using resources is the way to go | 16:04 |
| lazyPower | +1 | 16:04 |
| lazyPower | if you come up with an interesting strategy to manage resources in terms of traceability we're all ears over here on the kubernetes team | 16:05 |
| lazyPower | with many minor version releases and major releases every 3 months, we're up to our ears in resources | 16:05 |
| stokachu | lazyPower: mind elaborating on what you are looking for? | 16:05 |
| * stokachu just trying to understand | 16:05 | |
| lazyPower | stokachu - we're currently working on a binary pipeline to give us s'more traceability into whats out there that gets deployed via resource. We want things like "Build ID, git hash, fingerprint" | 16:06 |
| lazyPower | so when someone opens an SOS report, we have all that data handy | 16:06 |
| lazyPower | we can pull that bin, redeploy and verify the bug | 16:06 |
| lazyPower | not everyone will juju upgrade-charm when there is a new resource available (it just says charm upgrade available) | 16:06 |
| stokachu | ahh | 16:07 |
| lazyPower | so we have to have some level of accountability for what bins are out in the wild, and how we triage/treat support rquests for deployments that are not on the latest release. | 16:07 |
| stokachu | i use to remember you could run an elf tool on the binary | 16:07 |
| stokachu | to pull the buildid if it had one | 16:07 |
| lazyPower | well we're thinking about going even lower tech | 16:07 |
| lazyPower | just including a .release file with all that info | 16:07 |
| lazyPower | if you dont have that you're unsupported | 16:07 |
| stokachu | lazyPower: yea if you have that ability i would do that instead | 16:07 |
| stokachu | i had to try and pull the build-id out of kernel | 16:08 |
| lazyPower | ewww | 16:08 |
| stokachu | so it was embedded at the beginning | 16:08 |
| stokachu | but attaching a metadata file is easier | 16:08 |
| lazyPower | oh thats fair | 16:08 |
| lazyPower | thats less eww | 16:08 |
| stokachu | im working on my dokuwiki charm right now ill see what kind of info i can pull from that wrt traceability | 16:09 |
| lazyPower | stokachu the longer lived a charm is, the larger the resource trail will be too | 16:09 |
| lazyPower | thats another area we're interested in knowing. | 16:09 |
| lazyPower | i've considered putting together a simple little database so we have more detailed information than what the store-api is giving us, which is just hash and date uploaded. | 16:10 |
| stokachu | ah so, can you delete a resource form the charm store? | 16:10 |
| lazyPower | you cannot | 16:10 |
| lazyPower | once its in there, its in there | 16:10 |
| stokachu | wow ok | 16:10 |
| lazyPower | you can release a new resource attached to a charm id | 16:10 |
| lazyPower | but in terms of resource streams, its a forward progression (in unpublished) and you get little aliases per channel that the resource is released (when associated with a charm release) | 16:10 |
| lazyPower | so to be clear, you can shuffle a resource out, but it never goes away | 16:10 |
| stokachu | gotcha, yea querying the api may be the way to go | 16:11 |
| lazyPower | you're still only getting al imited subset, which is why i think it necessitates an additional meta source | 16:11 |
| lazyPower | no tonly in teh deliverable, but we're going to want a catalogue of what was published with what, when. | 16:11 |
| lazyPower | and the more automated we can make that process, the happier i'll be | 16:11 |
| lazyPower | release management sucks. point blank. | 16:11 |
| lazyPower | maybe someone out there likes it, i feel like its a time suck | 16:12 |
| stokachu | haha | 16:12 |
| stokachu | those guys get their own job title for a reason :) | 16:12 |
| lazyPower | +1 to that sentiment | 16:13 |
| stokachu | but yea, more automation would make everyone's life easier | 16:14 |
| lazyPower | we have a pretty good start to standing up jenkins + plugins + build workspace snapshot/restore | 16:14 |
| lazyPower | so we're getting there, its just a matter of time until we get the whole pipeline captured as code | 16:14 |
| jrwren | the problem with continuous deployment is that now you are deploying continuously. | 16:16 |
| * jrwren ducks | 16:16 | |
| lazyPower | jrwren fact | 16:17 |
| lazyPower | i dont think anyone said its easy ;) and if they did, their pants.. they are on fire. | 16:17 |
| jrwren | oh, it can be easy... when dealing with easy software on easy infrastructure. I've done that. it was easy. :] | 16:18 |
| lazyPower | jrwren - that smokey musty smell... i do believe your pants | 16:27 |
| lazyPower | they are on fire | 16:27 |
| === Guest42345 is now known as ahasenack | ||
| === ahasenack is now known as Guest79971 | ||
| jrwren | lazyPower: lol. | 16:35 |
| === freyes__ is now known as freyes | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| lazyPower | stokachu - when you were working with conjure to get resources working properly | 18:27 |
| lazyPower | stokachu did you file a bug for that? | 18:28 |
| urulama | stokachu: and did you manage to get it working in the end? | 18:30 |
| stokachu | yea we have resources working in conjureup | 18:43 |
| stokachu | we pull them down via the api if they exist | 18:43 |
| stokachu | lazyPower: urulama https://github.com/conjure-up/conjure-up/blob/master/conjureup/juju.py#L385-L403 | 18:44 |
| stokachu | using our macumba juju 2 api client | 18:44 |
| urulama | stokachu: ty! | 18:52 |
| stokachu | np | 18:53 |
| lazyPower | nice drop stokachu, thanks for the pickup :) | 18:53 |
| lazyPower | we just tag teamed a gui bug | 18:53 |
| stokachu | :D | 18:55 |
| stokachu | urulama: http://paste.ubuntu.com/23395090/ | 23:21 |
| stokachu | am i doing something wrong here? | 23:21 |
| stokachu | or anyone else having issues uploading resources to charmstore? | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!