| jam | thumper: wallyworld: so the reason the old code landed (without gomock in dependencies) is because it *didn't* have "pipefail", whatever patch that tried to introduce "pipefail" caused it to fail correctly, but doesn't seem committed to juju-qa-jenkins master branch. | 05:04 |
|---|---|---|
| jam | however, whatever added "set -o pipefail" just had a typo of "set +o pipefail" to turn it off again. | 05:04 |
| thumper | ah | 05:04 |
| thumper | ok | 05:04 |
| jam | but code has landed, and hopefully I updated and fixed the landing job. | 05:04 |
| thumper | thanks | 05:05 |
| veebers | jam, is this re: the juju merge job? I added pipefail handling today due to gofmt errors not failing the job. | 05:06 |
| jam | veebers: k. you didn't commit it to upstream/master AFAICT. , and you had a typo in it. | 05:06 |
| veebers | jam: 8sigh* I see, I broke it | 05:06 |
| jam | veebers: well, it broke correctly, because we were missing a godeps as well | 05:06 |
| jam | but I think I fixed both those issues | 05:06 |
| veebers | jam, sorry about that. Hah, lucked out. Ugh, did I not push either :-\ | 05:06 |
| jam | veebers: I kept trying to grep for "set +o pipefile" and couldn't find it anywhere, but did find it on grumpig in /tmp/jenkins*.sh | 05:07 |
| veebers | jam: ugh. Sorry I got distracted, the push command sits there with no return to make it so :-\ | 05:08 |
| thumper | veebers: so, with the 2.3.6 agents, I got IS to move the agent files | 05:08 |
| thumper | so the simplestream data probably still points to it, but they aren't there | 05:08 |
| jam | thumper: so its going to make my testing of how to get out of 2.3.6 a bit hard, but maybe I can make it fail | 05:08 |
| veebers | jam, is the removal of "set +e" correct? that will mean that the job will exit if make check fails (and thus won't get a test report written) | 05:08 |
| jam | veebers: I just replaced "set +e " with "set -o pipefail" and then "set +o pipefail". The bug was that you spelled the latter "pipefile" instead of "pipefail" | 05:09 |
| thumper | jam: you could always just build a 2.3.6 locally | 05:09 |
| thumper | and use --build-agent | 05:09 |
| jam | thumper: with the caveat of whether build-agent will work with an agent that it thinks exists in streams, but yes, something liket hat | 05:09 |
| thumper | it does... | 05:09 |
| thumper | 99% sure | 05:09 |
| veebers | jam: ack, we still need "set +e" otherwise the script will exit immediately, the pipefail is so any non-zero exit codes 'bubble' up the pipe chain (so if 'make check' fails it's not masked by 'tee') | 05:10 |
| jam | veebers: interestingly enough, http://ci.jujucharms.com/job/github-merge-juju/382/console says that "set +o pipfile" doesn't actually cause the script to exit immediately | 05:12 |
| jam | veebers: so it may be that we need to change the script from what I did. you're welcome to override my commit with yours and just fix the typo. | 05:13 |
| jam | veebers: (you can see the error at the end of the console output, but it still marks the commit a success) | 05:13 |
| veebers | jam, ack. I'll comfirm the use of +e and pipefail. Sorry again for the pain, if I had pushed (or ideally not hamfisted that) it would have been all good | 05:14 |
| jam | veebers: mostly it was just confusing to see something and not be able to figure out where that was being set. | 05:17 |
| jam | so the final "push" to github would have helped | 05:17 |
| jam | veebers: makes me wonder if there should be more of a "publish it to jenkins via github" sort of thing. | 05:17 |
| jam | veebers: I'm certainly just as guilty about do I commit and push first, or publish first, or did I forget to commit & push when I publish, etc. | 05:17 |
| veebers | jam: yeah, I think having a landing job for the jenkins job builder config that deploys on merge/landing would be great | 05:17 |
| veebers | aye, you want to make sure your changes actually work. Could be tiresome to push and wait see if a check job succeeds. Although you can do the test locally easily enough | 05:18 |
| veebers | jam: seems "set +e" is the 'default'. I've added it back in so it's explicit and we won't get tripped up if the script surrounding it changes. | 05:20 |
| * veebers has updated the job && pushed the changes. | 05:20 | |
| wgrant | How do I enable the audit log in 2.3? | 05:26 |
| wgrant | I have an audit.log but it is empty. | 05:26 |
| jam | wgrant: there seems to be "juju controller-config auditing-enabled" and "audit-log-capture-args" "audit-log-max-backups" "audit-log-exclude-methods=ReadOnlyMethods" | 06:00 |
| jam | wgrant: but probably "auditing-enabled=true" | 06:00 |
| jam | wallyworld: it looks ilke 'juju-force-upgrade' doesn't work because it has an assertion for "assert there is no current upgrade in progress" | 06:02 |
| jam | upgradeInfo, current, "d-" | 06:02 |
| jam | wallyworld: ok. I've worked out the upgrade and recovery steps and posted them to the bug. | 06:21 |
| wallyworld | jam: great, looking | 06:37 |
| wallyworld | jam: so we want to remove the prepared and applying txns? why prepared as well? | 06:40 |
| jam | wallyworld: all the prepared ones are *going* to be broken, they are just not applying yet because they ahave to apply the applying txn first | 06:41 |
| jam | wallyworld: everytime the upradesteps worker starts it creates a *new* txn that is going to do the same thing | 06:41 |
| wallyworld | and e are sure there aren't any prepared ones we should be keeping? | 06:41 |
| jam | it just doesn't notice until it goes to apply it that there are broken ones waiting. | 06:42 |
| jam | wallyworld: so if it is stuck in prepared, it couldn't be applied | 06:42 |
| wallyworld | ok | 06:43 |
| jam | wallyworld: if we just did an upgrade, theoretically all real changes are either before the upgrade step broke everything, or after, things before the upgrade step should be fully applied | 06:43 |
| jam | wallyworld: things after, couldn't have touched anything, because they never made it out of prepared. | 06:43 |
| wallyworld | i was thinking other non related tasks may have tried to update settings, but seems unlikely | 06:43 |
| jam | wallyworld: so yes, it is possible someone did "juju upgrade-juju" and then something like "juju config a=b" and we'll lose that latter one | 06:43 |
| wallyworld | yeah. changes of that though seem slim | 06:44 |
| jam | wallyworld: we could have them audit the actual list of changes that would be applied, by including more of the txn details in the find() | 06:44 |
| jam | wallyworld: but I don't think anyone other than us really has the stomach for that | 06:44 |
| jam | and it sucks even for us, because real model settings docs have like 30 items in them | 06:45 |
| wallyworld | i was thinking we could make the find more selective, yeah. but i think what we have might be ok | 06:45 |
| === frankban|afk is now known as frankban | ||
| jam | wallyworld: https://github.com/juju/juju/pull/8642 is merging 2.3 into develop, along with https://github.com/juju/juju/pull/8642/commits/6df4788963993eca81afc5bb1b165248604d1542 | 07:19 |
| jam | which just changes the settingsMap.GetBSON to always escape when writing | 07:20 |
| jam | wallyworld: for more restricting remove. we might be able to do something with o.c.???.container-image-stream ${exists: 1} | 07:25 |
| jam | wallyworld: I'd have to think quite a bit to figure out the exact syntax that would match | 07:25 |
| jam | *if* you stop the controller at *exactly* the right time it might also be possible to get a txn that is in Preparing (1) state. but it never gets blocked there, so is unlikely to exist | 07:29 |
| stub | tinwood: Can I get added to the relevant team for https://github.com/juju/charm-helpers ? | 07:40 |
| tinwood | stub, sure; I'll see if I can do it, or prod the person who can. | 07:58 |
| tinwood | stub, it's jamespage, marcoceppi or dpb1 that can add you to the charm-helpers team. | 07:59 |
| jamespage | stub: yeah I can do that | 08:03 |
| jamespage | stub: what's your github handle? | 08:05 |
| utking | Hey guys! We're having some troubles with openstack base | 08:10 |
| stub | jamespage: stub42, which you can confirm from my older commits of Canonical team membership | 08:10 |
| stub | c/of/or | 08:10 |
| utking | it works perfect when deployed, but when we add nova-compute and ceph to the last node (4 nodes) neutron-gateway goes to blocked | 08:10 |
| stub | (heh, #3 committer) | 08:11 |
| utking | services not running that should be, neutron-dhcp-agent, neutron-metadata-agent, neutron-L3-agent | 08:11 |
| utking | also another ntp is added to the fourth node that fails with hook-failed | 08:12 |
| utking | unit-nova-compute-0: 10:21:55 DEBUG unit.nova-compute/0.update-status ERROR no relation id specified | 08:22 |
| utking | any ideas? | 08:22 |
| utking | can't gateway run on the same node as nova-compute? | 08:30 |
| utking | openstack-base is bugged at least | 08:48 |
| jamespage | utking: -> #openstack-charmers good place to get help on the openstack charms and bundles | 09:22 |
| jamespage | stub: invited | 09:23 |
| jamespage | utking: can you clarify what you mean by "when we add nova-compute and ceph to the last node" | 09:24 |
| utking | Ah, yes! | 09:46 |
| utking | We deploy openstack-base to 4 nodes | 09:46 |
| utking | gateway on one, and 3 nova compute + ceph | 09:46 |
| utking | then we use add-unit nova-compute | 09:46 |
| utking | to the latest node | 09:46 |
| utking | but then neutron gateway goes to blocked | 09:47 |
| jamespage | utking: yes - the bundle is split intentionally that way - you can't place nova-compute and ceph on the neutron-gateway unit | 10:04 |
| jamespage | the charms won't co-exist on the same machine (nova-compute and neutron-gateway specifically) | 10:04 |
| utking | ah ok, how can we achieve this, if you won't mind me asking :) | 10:06 |
| utking | guess we could try by doing it with add unit commands instead then | 10:11 |
| TheAbsentOne | can an interface name contain a dash (-)? And are there any limitations like length to it, or is anything possible? | 10:53 |
| utking | Is there any way we can configure the charms ourself so they can co-exist together? | 11:35 |
| zeestrat | TheAbsentOne: Are you thinking about maas/juju or in general? Here's launchpad bug with some background info mostly on the length limitation: https://bugs.launchpad.net/juju/+bug/1672327 | 11:45 |
| mup | Bug #1672327: Too long names for bridges <cdo-qa-blocker> <maas-provider> <openstack> <uosci> <juju:Fix Released by wpk> <MAAS:Fix Released by mpontillo> <https://launchpad.net/bugs/1672327> | 11:45 |
| TheAbsentOne | zeestrat: It's about the juju layer interfaces, as soon as I asked the question I realised mysql-shared has a hyphen and I felt stupid xD | 11:47 |
| TheAbsentOne | thanks though! | 11:48 |
| zeestrat | TheAbsentOne: Ah, my bad, I just assumed you were talking about network interfaces :) I imagine there's some cap on the length, but there are a few wordy ones already: https://github.com/juju/layer-index | 11:50 |
| TheAbsentOne | yes exactly I took a look at the index too | 11:50 |
| TheAbsentOne | now the question remains do I choose generic-db or generic-database as it seems there is no real convention about using abbreviations or not | 11:51 |
| utking | Is there any way we can get this to work at all? it's for our bachelor thesis, and we really need to get a 4 node with compute openstack up and running | 12:14 |
| utking | https://pastebin.com/XS0sm4uG | 12:14 |
| utking | This is our script :) | 12:14 |
| stub | TheAbsentOne: I'm pretty certain they are the same standard juju identifiers found everywhere, but I haven't looked at the code to see what the rules are. I do know _ and - are fine, and characters juju uses as delimeters are not (so no : or /). I personally assume no punctuation apart from _ and -, case insensitive, and sane lengths since humans need to read them. | 12:34 |
| TheAbsentOne | Seems about right stub thanks for that insight! neutron-plugin-api-subordinate is also a layername so I guess I wont run into issues about the length either, perfect! ;) | 12:39 |
| jamespage | utking: sorry - in lots of channel - prefix my nick to get my attention | 12:56 |
| jamespage | utking: tl;dr no not without quite alot of coding work in the charms | 12:56 |
| jamespage | cory_fu: morning - quick q- I have a non-reactive charm interacting with my reactive implementation - I'm see string data items being double quoted '"str"' - is that intentional and how do I deal with that outside of reactive | 13:01 |
| jamespage | tinwood: might you have an idea ^^ | 13:05 |
| tinwood | hmm | 13:05 |
| tinwood | jamespage, that's new. Is that endpoint related? | 13:05 |
| jamespage | tinwood: I'm using a endpoint based interface on my provides end | 13:06 |
| tinwood | jamespage, I'll have a quick check ... | 13:06 |
| === freyes__ is now known as freyes | ||
| jamespage | tinwood: example data - http://paste.ubuntu.com/p/cJvht5dwjM/ | 13:07 |
| tinwood | jamespage, it's being jsonified in to_publish() | 13:09 |
| tinwood | what does your endpoing look like | 13:09 |
| jamespage | it does to_publish | 13:09 |
| jamespage | oops | 13:09 |
| tinwood | there's a to_publish_raw too | 13:09 |
| jamespage | what should I be doing? | 13:09 |
| tinwood | jamespage, https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/endpoints.py#L412 | 13:09 |
| tinwood | it's for not using JSON -- i.e. for pre- endpoint charms. | 13:10 |
| jamespage | tinwood: or I could do the right thing on the other end of the relation | 13:11 |
| jamespage | even thought its a non-reactive charm right? | 13:11 |
| tinwood | jamespage, oh yes; you'd just need to do a json.loads('"string stuff"') and it would strip off the string and check it. | 13:12 |
| tinwood | That would work too. | 13:13 |
| cory_fu | jamespage, tinwood: For reference, this is documented at https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.RelatedUnit.received but it could definitely be better surfaced. | 13:38 |
| tinwood | thanks cory_fu | 13:39 |
| cory_fu | We should probably add a section on converting existing interfaces to Endpoint | 13:39 |
| jamespage | cory_fu: ta - another quick question | 13:40 |
| jamespage | cory_fu: we have an action that unlocks a new set of capabilities in a charm - can I get the action code to re-trigger the main hook state loop thing once its done? | 13:40 |
| cory_fu | Oh, and the publish side of those docs is at https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Relation.to_publish | 13:40 |
| cory_fu | jamespage: Yes. Just call charms.reactive.main() | 13:41 |
| jamespage | awesome ta | 13:41 |
| cory_fu | jamespage: np | 13:42 |
| cory_fu | jamespage: Are you aware of using charm-env as your shebang line for actions? | 13:42 |
| jamespage | cory_fu: er no | 13:42 |
| jamespage | cory_fu: docref? | 13:43 |
| jamespage | cory_fu: I've been a bit way from the charm coalface for a few months... | 13:44 |
| cory_fu | jamespage: There was an announcement a couple of weeks ago on the mailing list about changing the deault in layer:basic for use_venv to True, so unless you're explicitly setting that back to False, then your charm will use a venv that needs to be activated for your action. | 13:44 |
| jamespage | oh ok | 13:44 |
| jamespage | we're not | 13:44 |
| jamespage | I wonder how its working? | 13:44 |
| cory_fu | jamespage: To make that easy, there's a wrapper at /usr/local/sbin/charm-env that can be used in place of /usr/bin/env in your shebang | 13:44 |
| cory_fu | jamespage: Unfortunately, I don't think charm-env is documented yet. I will try to get that done today. | 13:45 |
| jamespage | cory_fu: ta | 13:45 |
| cory_fu | jamespage: It's also useful when debugging charms, so you can do, e.g, juju run --unit charm/0 -- charm-env charms.reactive get_flags | 13:46 |
| TheAbsentOne | cory_fu: what is your timezone +/- I would love to have a private chat once my whole design is done to hear your thoughts. It will help me make choices as I'm a bit unsure what the best-practice approach is as of today | 13:46 |
| cory_fu | jamespage: I'm not sure how it would be working either, unless you have another charm on that unit (subordinate, perhaps) that happens to be setting it to False or was built before the default change | 13:47 |
| jamespage | well we use 'env' just not 'charm-env' | 13:47 |
| cory_fu | TheAbsentOne: Absolutely. I'm east coast US, UTC-4 | 13:48 |
| TheAbsentOne | cory_fu: noted, thanks in advance big sir! ^^ | 13:48 |
| cory_fu | TheAbsentOne: No problem. Do be aware that I'll be travelling next week for a planning sprint, so will be in a different timezone (UTC+2) and not generally available except maybe in the evenings. | 13:49 |
| TheAbsentOne | cory_fu: Ohn you are coming to Europe? I'm from Belgium :P Thanks for telling though! | 13:51 |
| cory_fu | TheAbsentOne: Belgium is great. I've been there once and loved it. I'll be in Berlin this time, though. | 13:53 |
| TheAbsentOne | Probably at config management camp to present juju a few years back. Love the talks ;) Have a great time in Berlin, man! | 13:54 |
| TheAbsentOne | and btw cory_fu the beer in Belgium is better x) | 13:54 |
| cory_fu | =D | 13:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!