/srv/irclogs.ubuntu.com/2015/01/07/#juju.txt

designatedCan anyone tell me if configuration options are changed after deployment of an openstack charm, if that information will automatically get updated in the database?  As an example, will changing the VIP update the keystone endpoint list in the DB?01:50
=== negronjl is now known as negronjl-afk
marcoceppidesignated: it should04:02
marcoceppidesignated: however, there are a few configuration options that are immutable, I don't think that is one of them though04:03
=== lamont` is now known as lamont
mwak_hey10:54
=== frankban__ is now known as frankban
stubCan I get a peer unit's public-address ?12:24
stubHmm... I guess I can set it myself on the peer relation12:25
marcoceppi_stub: you'd have to set it on the wire13:21
marcoceppi_as you allueded to13:21
=== kadams54 is now known as kadams54-away
=== negronjl-afk is now known as negronjl
=== kadams54-away is now known as kadams54
=== mwak_ is now known as mwak
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
mwakmarcoceppi_: ping.15:39
dpb1rick_h_: happy new year!  the store is out of date with bzr for https://jujucharms.com/landscape-client/trusty/10 and https://jujucharms.com/landscape-client/precise -- there are two more revisions for each16:02
rick_h_dpb1: otp will look16:04
mbruzekdpb1 did I see you committed changes to the landscape charm to fix automated testing errors?16:06
dpb1mbruzek: yes16:07
mbruzekdpb1 it is a happy new year16:08
dpb1hah16:08
dpb1:)16:08
lazyPower\o/16:19
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
skaylogistics question. I've never submited MR for a charm. and also haven't used bzr much. do people prefer getting small logical MR for something, or is that a pain due to the review process?18:22
skaye.g. I want submit 2 changes in how pip is handled to the python django charm. 1. support extra args for pip. 2. stop using deprecated options18:23
skayin some projects, it would be the custom to submit those separately, what is the preference here?18:24
lazyPowerskay: small chunks are fine for MR's18:25
lazyPoweryou can make chained dependencies on Merge proposals18:25
lazyPowerthe smaller the change, the more likely it is to be merged fairly quickly18:25
skaythanks lazyPower, I like small changes. (I didn't know about the chained thing)18:25
skayI forgot where in the docs it lists which config types are allowed. I would like to use a list, but I can't remember if that's allowed18:38
skayright now I do a split on ' ' or ',' in some places, and a list would probably be more natural18:38
skayoh derp. I found it. sorry for the trigger happy question18:39
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
dpb1rick_h_: gentle ping reminder. :)18:46
rick_h_dpb1: yes, just finished phone calls and starting to look.18:46
dpb1ty18:46
rick_h_dpb1: will be out first time using out fancy ingestion log so looking up how we can use it.18:46
dpb1oooh, hopefully it's easier this time!18:47
rick_h_dpb1: these were updated a while ago?19:11
dpb1let me check the revno19:12
rick_h_looks like back mid-dec19:12
dpb1ya, sounds right19:12
rick_h_trying to see how far back I can get logs for19:12
rick_h_logging every 15min means that's a while back19:12
dpb1:)19:12
rick_h_did find this for you as an fyi https://pastebin.canonical.com/122931/19:12
dpb1rick_h_: ok... will look at that as I work up the stack19:24
rick_h_dpb1: well the good news is I found the logs from that timeframe19:27
rick_h_dpb1: the bad news is that I don't see any reference to your charms in any warning/error logs so no closer to knowing wtf19:27
dpb1:(19:28
rick_h_dpb1: so creating a card and will get it assigned to chase it down but probably more time than a quick "oh, there's your problem"19:28
dpb1rick_h_: ok, thanks for looking. it's not super urgent, as long as we get it fixed.19:29
rick_h_promise that19:29
=== roadmr is now known as roadmr_afk
=== kadams54_ is now known as kadams54-away
=== kadams54-away is now known as kadams54_
=== kadams54_ is now known as kadams54-away
skay\o/ yay, I submitted a small merge request for python-django.20:23
skaydoes the ci job get kicked off automatically, or do I need to ask for it here?20:23
=== roadmr_afk is now known as roadmr
=== kadams54-away is now known as kadams54_
jcastroanyone: I've got a PR to juju-solutions.github.io to add a containers page if someone wants to ack it pls.20:39
marcoceppi_skay: it'll be kicked off by whoever is doing review21:48
lazyPowermarcoceppi_: mbruzek: https://bugs.launchpad.net/juju-core/+bug/140846721:49
mupBug #1408467: juju help-tool does not reflect all options available to relation-set <audit> <docs> <help> <juju> <papercut> <juju-core:Confirmed> <https://launchpad.net/bugs/1408467>21:49
mbruzekOh I hate that bug!21:50
mbruzekWe should fix that one!21:50
marcoceppi_bah, what a horrid bug!21:51
johnny_shiehlearning to write charms following tutorial found on web22:03
johnny_shiehcan create/launch the demo wordpress22:03
johnny_shiehwould like to log into container22:04
lazyPowerjohnny_shieh: if you dont mind me asking, which tutorial are you following?22:04
johnny_shiehbut ssh <ipaddress> fails with permissions issue.22:04
lazyPowerjohnny_shieh: try doing juju ssh service/#22:04
lazyPowereg: juju ssh wordpress/022:04
johnny_shiehhttps://juju.ubuntu.com/docs/22:04
johnny_shiehhmmm, let me try22:05
mbruzekhttps://bugs.launchpad.net/juju-gui/+bug/140847222:05
mupBug #1408472: The juju-run command on the unit does not have help  <docs> <help> <juju> <papercut> <juju-gui:New> <https://launchpad.net/bugs/1408472>22:05
lazyPowerOo another one!22:05
lazyPowerwe should fix that one too22:05
mbruzekI know!  ... Right?!22:05
johnny_shiehthanks lazyPower22:06
johnny_shiehworked22:06
* lazyPower hat tips22:06
johnny_shiehthx for help, be back in a few days with actual, real problems.  ha-ha22:07
* arosales heads over to the review can for some review time.22:11
arosaless/can/queue22:11
arosalesmarcoceppi_:  mbruzek: any ideas/opions on how we should handle the MPs for tests that are currently failing auto test?22:12
arosalesmarcoceppi_: mbruzek: I presume these are due to the charm and not the test as the charm tests do not touch the charm code.22:12
arosalesit seems like it would be good to have these tests included in a charm that failing. Specifically, when someone comes along to fix it then can run the tests and have seed tests to build off from.22:13
mbruzekarosales: tvansteenburgh had some strong opinions22:13
mbruzekon this subject.22:13
mbruzekarosales: I reluctantly agree with you and tvansteenburgh22:14
mbruzekBut that still feels "bad"22:14
arosalesmbruzek: is the concern that the charm is failing auto charm testing but the MP is still accepted?22:15
mbruzekarosales: yes because that sets a bad precedent, other folks are going to ask them to merge their changes while the tests STILL fail22:15
arosalesmbruzek: I see that point. Whats interesting here is that for tests they don't touch charm code.22:17
arosalesand in the case for failing tests adding tests actaully may help debug the charm.22:17
mbruzekarosales: agreed22:17
arosalesmy opinion is that it helps get the charm into a better passing state22:17
arosalesso the decision is to nack or ack the MP22:17
arosaleson the one had if you nack, then the next person doesn't have seed tests or a charm tests to run against the charm to see what the failure was22:18
arosaleson the other hand if you ack, then at least the next person has a test to run and try to reproduce and a seed test to build off from.22:18
* arosales 2 cents22:18
mbruzekarosales: we already get requests to merge MPs that fail charm proof, or other minor problems that "the change did not touch"22:19
arosalesare those tests or charm code?22:19
arosalesjose, dbp, marcoceppi_, mbruzek, lazyPower, niedbalski, tvansteenburgh, lazyPower: any opinons ^22:20
mbruzekcharm code, that someone is adding, they say since they didn't make the charm proof any worse they want their MP merged22:20
arosalesits a fair question and good point for not accepting the charm test.22:21
tvansteenburghif adding tests to to a charm that has none, i'd merge even if they fail22:21
tvansteenburghb/c at least now we know there's a problem22:21
arosalesmy 2 cents is that the charm tests actaully help get the charm into a good state (passing tests) and thus should be accepted there. A charm code MP may not be able to state that, in general.22:21
mbruzekarosales: to be clear I agree with you and tvansteenburgh, we should merge the failing tests22:21
arosalesmbruzek: I appreciate you are trying to weight both sides.22:22
arosalesMy proposal is to get a few charms, at least 3, to agree so we can clear out the queue with these MPs.22:22
arosalesbeen in there far too long22:23
arosalesso two charmers +1 any others?22:23
mbruzekwe should resume this conversation when marcoceppi_ has a chance to comment.  I suspect he has strong feelings one way or the other.22:23
* mbruzek believe marcoceppi_ is eating now.22:23
mbruzekthe force is strong with that one22:25
tvansteenburghhe agrees22:25
* arosales pinged other charmers too22:25
arosalesat least the ones I could recall.22:25
* arosales will wait patiently22:26
arosalestvansteenburgh: mbruzek: in the mean time is there any thing I can to to help wth those MPs?22:26
arosalesleave a comment in them or does a charmer just need to take action on them once the decsion is made?22:26
mbruzekpull requests to fix why the test is failing22:27
mbruzekIn the end that is what we are after22:27
tvansteenburgh:)22:27
arosaleslol mbruzek22:27
arosalesnice one22:27
mbruzekYou can pull request against me or marco's branch to fix the test22:27
mbruzekor pull request against the charm.22:27
arosalesunderstood :-)22:28
arosalesmarcoceppi_: when you return, for lp 1387465 can you let me now what action is needed to get this item out of the queue?22:34
arosalesmarcoceppi_: same thing for 138746722:34
* arosales taking a +1 look @ 139623722:40
lazyPowerwat22:44
=== kadams54 is now known as kadams54-away
lamontlazyPower: brain dump to follow...22:47
lazyPowermbruzek: ^22:47
lamontwhat we have: maas node with 2ea openvpn-server charms and 1 openvpn-p2p charm forced onto one node (along with a few subordinates).  the other side of the p2p link is outside of maas/juju, as is the entire pki infra.  ergo, the openvpn-server and p2p charms have a bunch of config vars to delvier ca.crt and host key/cert and such22:49
lamontwhich makes reading/deploying the charms problematic for someone using just juju (no PKI wat?)22:49
lamontenter the openvpn-pki charm, which optionally relates to the other 2, and provides a PKI infra (most notably, today it delivers the ssh pubkey and IP address that will be doing the syncing)22:50
lamontcurrently coded as "when this relation comes up, dump some config vars into a file on the unit, and silently override the juju config variables with the actual answers from the openvpn-pki unit)22:51
lazyPowerlamont: i can understand the situation you're trying to solve - however relationship data should not overwrite config data coming from teh user - that alone would get a nack on a charm review. My thoughts would be if you have a third party PKI utility - it should either proxy the information in from your existing infra, or allow those bits to be set by the user, that way the onus of where the config is coming from is not on the openvpn server22:51
lazyPoweritself but on the PKI charm you're relating to the unit. In which case - depending on if its coming from a proxy or being set by the user is dependent on how the charm is deployed22:51
lamontwhich is vomitworthy22:51
lazyPowerand you could then send that information via the relationship to openvpn and not worry about this22:51
lazyPowerthis way both scenarios are modeled in the juju language, and both are actionable22:53
mbruzekSo lamont what happens to the ca.cert if the user sets a ca.cert on the openvpn charm and then the openvpn-pki charm comes by with a different ca.cert?22:53
lazyPoweryou can then say "if user config data" is present, that will override any relationship data - so it follows the juju tenants, and if that data is not present, it sends the data from the proxy22:53
lamontI was just thinking...  how horrible would it be to have the charm behave correctly, and then have a subordinate charm that eliminates the need for a relationship to openvpn-pki?22:54
lazyPowera subordinate woudl be a fine approach too - you dont necessarily need to tie up a unit for data-pass22:54
lazyPoweractually - a sub would be the preferred route forward22:54
lamontmbruzek: as it sits, openvpn-pki wins:  code says "conf = config(); if-file-exists { read yaml and overwrite into conf}'22:54
mbruzeklamont that would break the user experience.22:55
lamontmbruzek: hence the "how much would you guys scream" that brought me here...22:55
lazyPowerlamont: <322:55
mbruzeklamont: if a user sets something with config-set or from the gui we should do EVERYTHING possible to preserve that22:56
lamontif I understand this, the correct solution is: openvpn-pki <-> openvpn-{server,p2p} quietly delivers the info over the relation (and server/p2p spill it to a file which is used in config), and an "openvpn-external-pki" subordinate provides all of the variables for juju set to let a non-juju pki be used instead of the charm.22:57
mbruzekMaking the user know/care about the order of charms deployed is ALWAYS a "bad idea"22:57
lamontand server/p2p do not have settable variables for the pki meta22:57
lamontmbruzek: If it helps, I was feeling dirty.22:58
lazyPowerlamont: that soudns correct to me in the ascii diagram above - the subordinate allows for you to either proxy the info in or configure it, correct?22:58
mbruzeklamont: clean your self up this is a family show.22:58
lamontit felt _wrong_, which led me to seek help22:58
lamontso that summary sounds right?22:59
mbruzeklamont: Yes I like you ascii diagram solution22:59
lamontascii ftw22:59
lamontall of which means I have my work cut out for me.22:59
mbruzeklamont: dont' forget to write the README.md too.22:59
lamontand stupid question: subordinate charms... will I need a relationship there, too?23:00
mbruzekThe openvpn-p2p readme was VERY sparse23:00
lazyPowerwell, *good* charms can be difficult to write as complexity grows. but a bundle/bundle(s) will make this simple for users to get setup and moving with, and we'll give you much fanfare when it lands23:00
lamontmbruzek: there is this significant feedback item about how terse (or, conversely, verbose) my explanations are.  working onit.23:00
lazyPowerlamont: expect some blogging / an instructional video when it lands tho - we'll give ya the red carpet for your efforts.23:01
mbruzeklamont: subordinate charms relate on the juju-info relationship to a container charm (non subordinate)23:01
* lamont still gets grief from a former coworker from many years ago for a program of several hundred lines, with the singular comment "do stuff" in it.23:01
mbruzeklamont: so you get the subordinate relationship for "free"23:01
sarnoldlamont: at least it wasn't misleading or incorrect, right? :)23:02
lamontmbruzek: for the charm writer of poor literacy.... does that mean that config() in the container charm returns the set variables from the subordinate?23:02
mbruzeklamont: something that lazyPower and I talked about just *today* was that subordinates can have peers too, so one subordinate can be related to different container charms and the subordinates can use the peer relation23:03
lamontsarnold: fact23:03
lamontactually, hrm.23:03
lazyPowersarnold: *rimshots*23:03
lazyPowero/23:03
skayhehe do stuff23:03
lamontsarnold: it's from the "self documenting code" era23:03
skayI like "read my mind and do what I want"23:04
lazyPowerlamont: re: your question to mbruzek - no, config() will continue to only return the config data from that charm. Data being sent over the wire is in relation-get23:04
lamontsarnold: that code used a 400MB (yes, MB) disk to transfer files between a un*x box and a non-un*x box.  beacuse of reasons23:04
lamontlazyPower: and the relation is "just there" by right of the subordination?23:05
lazyPowerlamont: now we're talking about interfaces and properly consuming/documenting interfaces+data in the readme/contributing documents. But when you get to that point, feel free to tap me in and i'll help.23:05
lazyPoweryou define it by every variable you send OTW via relation-set23:05
sarnoldlamont: at least it wasn't "literate programming".. I'll take self-documenting code any day :)23:05
lazyPowerthis is why its super important to document it, otherwise users have to read teh code to know what its doing, and we as charmers will hate you forever. we already have a truckload of interfaces to document23:05
mbruzeklamont: re: config - No the subordinate configuration are not in the container charm's config23:05
lamontlazyPower: I'm guessing that I still need Provides/Requires?23:05
lazyPowerlamont: thats depreciated, its the wild west with interfaces - no forced gets/sets23:06
* lamont drops the side conversation with sarnold. :p23:06
lazyPowerits even been removed from the documentation23:06
lazyPoweryou just arbitrarily set them, and consume them23:06
lazyPowerskay: sounds about right :D23:06
lamontok.  this'll be fun. :D23:06
lamontconfig-changed only triggers on juju set, correct?23:07
lazyPowerconfig-changed triggers when the charm config changed23:07
lazyPowerso 'yes' to juju-set triggering it23:07
lazyPowerbut it also runs after install and upgrade-charm23:07
mbruzeklamont:  don't forget the gui23:07
lamontmbruzek: right.  was thinking api-speak.23:08
lazyPowerrelation-name-changed triggers when relation-set is called on any of teh charms in the relationship chain "do stuff" that sets a variable.23:08
lamontsometimes, I hate computers23:08
lamontlazyPower: and (duh) relation-setting doesn't trigger config-changed23:08
lamontis it true that both hooks will never run concurrently? (only one hook to a unit, at a time, yes?)23:09
lazyPowercorrect23:09
lamontwhat I really want is a juju status item that says "and no hooks are queued or running at this time"23:10
lamont(though there could be one queued/starting right after the status, don't care)23:10
lazyPowerlamont: we all want that. its a work item in the near cycle(s) to get better information from status about whats going on in the unit23:10
lamont\o/23:11
lamontwith that, time to go rewrite some charms.23:11
lazyPowerlamont: all the best o/ cheers23:14
lamontexample of a subordinate charm that does things by the new /current method?23:20
lazyPowerlamont: one doesn't exist as we dont have many/any ['proxy','configurable'] subordinates that I'm aware of. But again, tap me in and I can help when you get to writing the hooks23:21
lazyPowerand/or planning of said charm23:22
lamontah, well... that'd be "about now", since it basically consists of ripping out a bunch of config vars from openvpn-serfver and creating said charm.23:22
lamonthere, or /pm?23:22
lazyPowerLets do it here so others can benefit from our riffing23:23
lamontok.23:24
lamontcategories:23:24
lamont  - misc23:24
lamontsubordinate: true23:24
lamont:D23:24
lazyPoweryou'll need to add a requires relation that is scope: container23:24
lazyPowerhttps://juju.ubuntu.com/docs/authors-subordinate-services.html23:24
lamontrequires:23:25
lamont  openvpn-pki-recipient:23:25
lamont    interface: openvpn-pki-sync23:25
lamont    scope: container23:25
lamontcool23:25
lazyPowerok, so you've now got an openvpn-pki-recipient ['joined','changed','broken','departed'] relationship on both sides23:25
lazyPowerthe subordinate unit itself shoudl relation-set the relevant parts, if its coming from proxy or from user config (possibly both are user config, depends on how you build it)23:25
lazyPowerand the openvpn-pki-recipient service itself will need to consume whats being sent via relation-set23:26
marcoceppi_mbruzek: why is lp 1408472 targeted at juju-gui?23:26
lazyPowerseem straight forward enough?23:26
lazyPower(so far anyway)23:26
lamontlazyPower: yep23:26
lamontta23:26
arosaleslazyPower: any opinions on the earlier conversation on approving MPs that only add tests even though the charm is failing those tests?23:27
lamontin config-changed (yes), how do I find the relations(s) to do the relation-set calls? (python, with charmhelpers)23:27
mbruzekmarcoceppi_: because I made a mistake23:27
lamontlazyPower: (in a clean/current way - I'm learning that nagios-external-master is not a charm to crib from)23:28
mbruzekno23:28
marcoceppi_arosales: I just linked a new branch and initiated tests against the new branch so that we can know if it passes or not for 1387465.  1387467 needs another test run executed. I just queued it up23:29
mbruzeklamont: we have several flagbearer charms23:29
marcoceppi_mbruzek: <323:29
lazyPowermbruzek: fyi - rails is not one of them, i've gone back through and started re-working that one, so anyone asking about chef - send them to me direct until I can get the charm reworked and the docs updated to reflect the new pattern i'm working on.23:29
marcoceppi_arosales: I'm a plus one, but we have another issue steming from that. Whos responsible to fix that? Should we hault all further changes to that branch until someone fixes it? or just keep merging things that address issues even though the tests continually fail23:30
arosalesmarcoceppi_: once those tests are done for 1387465 and 1387467 will those fall out ofthe queue. Seems odd they are still in the queue even though the bug is marked as "Fix Released"23:30
mbruzeklamont: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-flag-bearer-charms23:30
lamontta23:31
marcoceppi_arosales: that is weird.23:31
mbruzekpersonally I recommend the lamp charm for the tests, but I don't remember if the _charm_ code is any good23:31
marcoceppi_arosales: one sec23:31
arosalesmarcoceppi_: in regards to charm tests. Per policy https://jujucharms.com/docs/charm-unmaintained-process23:31
* mbruzek knows the tests are "awesome" because he wrote them.23:31
mbruzekThat is all from me tonight, I have guests coming over and need to go for the evening.23:32
lazyPoweroh nice - rails didnt make the list. <323:32
arosalesif the charm continues to fail tests (ie deploy is broken) then it becomes a candidate to move into un-maintained if no action is take on it to fix it23:32
* mbruzek waves23:32
lazyPoweri'll get that fixored eventually23:32
lazyPowerarosales: how long is that period after we start accepting contributions? anotehr 15 day grace period?23:32
marcoceppi_arosales: fixed23:32
arosalesmarcoceppi_: thanks I don't see them in the queue anymore23:33
arosaleslazyPower: sorry I didn't properly parse your question23:33
* marcoceppi_ decides to do a bunch of fixes to the review queue tonight23:34
arosaleslazyPower: in regards to unmaintained charms; if a bug is logged against a charm and no action is taken to fix it 1 month after the bug is failed the charm will then be moved into the unmaintained branch.23:34
=== marcoceppi_ is now known as marcoceppi
lazyPowerarosales: right - but you were saying if the tests continually fail23:35
lazyPowerat this point, we know there is an issue with the charm when we start accepting these contributions cognisent of them having failing tests23:35
arosaleslazyPower: ah23:35
lazyPowerit doesn't seem right to just merge that in and reset the countdown timer on unmaintained.  Maybe i'm being a stickler though23:35
arosalesthe way I read policy is that if active work is going on in the charm then the charm is not a candidate for unmaintained23:35
arosalesthe issue is when there is a bug against a charm and no work is being done to address it23:36
lazyPower10-423:36
lazyPowerso if i'm reading htis properly - we file a bug about the failing test23:36
lazyPowerif nobody comes around to fix that, but they keep adding MP's we just ignore the failing test for the time being until someone gets around to fixing it23:36
arosalescurrently auto testing will only run against a charm when there is a MP agaist it which would signal an effort to bring the charm into good standing.23:36
lazyPowerok, i mean seems fair enough as we dont really know what the community at large will do with this information against their charms, we only have a handfull right now failing tests right? ~ 30 or so?23:37
lazyPoweror am i looking at the wrong data sheet23:37
arosalesya, I think it was around 3023:38
marcoceppiI hope to add failing charms in to the review queue soon23:38
marcoceppias a section23:38
lazyPowermarcoceppi: <3 you and the rev queue magic, all the new queues and what not23:38
marcoceppiyeah...as soon as they show up...one day23:38
lazyPowermarcoceppi: i have an idea that we kind of riffed out tonight about the store + recommended that I want to send to teh charmers team for pre-feedback in the near future23:38
marcoceppilazyPower: okay, there is the monthly thingy23:38
lazyPowerit will address a few different areas that we're experiencing pain in one move23:38
lazyPowerwe are still doing that?23:38
lazyPoweri thought we didnt want to do that23:39
arosaleslazyPower: so to mbruzek's earlier point if an MP comes in and touches charm code but the charm tests are failing a charmer would need to decide if that MP should be accepted23:39
arosaleslazyPower: so I don't think we should ignore the failing tests23:39
lazyPowerarosales: i'll put on my "take me seriously hat" and put googley eyes on the review about the tests.23:39
arosalesbut what we shouldn't do is move the charm into unmainted as there is "active" work on it.23:39
lazyPoweryeah, i'm +1 for that... We already have a high bar for getting into recommended status23:39
lazyPowerif we just start nuking charms because we have a stickler for tests, we will be alienating people working23:40
arosalesya moving to unmaintained is really a last resort when a charm is broken and there is zero work to bring the charm back  to a working state.23:40
* lazyPower recalls there being a yoda image at one point that summed it up nicely23:41
arosalesthe thought being that the recommeded charm store should always have charms that are in a working state or at least a state of being fixed23:41
lazyPowerwell i'm a fan of ~recommended being the de-facto best of the best23:41
lazyPowernamespaces are around for the rest, for in-dev, community love, and development focus23:42
arosalesso lazyPower marcoceppi: my original question to the charmers team is do you guys agree the oustanding MPs in the queue to add tests should be accepted even though the charm is failing tests?23:42
lazyPowerbut this is starting to touch on what i want to riff with marcoceppi and other ~charmers about - kind of our curation process and bits - but it is goign to take a lot fo fleshing out as i'm sur ei've got gaps in what i'm thinking.23:42
arosalesmy comment was that the tests actually help get the charm fixed as it provides a reproducibile failing environment, and add seed tests to the next person wanting to improve the charm. Plus the tests don't touch charm code.23:43
marcoceppiarosales: I agree, but with reservations23:43
lazyPowerarosales: yeah, if there's work going on towards a charm - and it doesnt effect the tests - file a bug against the charm about tests and move on23:43
lazyPowerkeep making it happen23:43
lazyPowermarco will have a test failure queue soon(ish) that we can address when we have more info about longevity of a charms failure rates23:43
arosaleslazyPower: in this case we don't know if there is work on the charm outside of the tests23:43
arosaleswe only know that marcoceppi and mbruzek added seed tests to charms23:44
lazyPowerwelp, getting the tests in there is the first step right?23:44
arosalessome of those charms fail the tests23:44
arosalesso we got a load of those in the charm queue23:44
lazyPowerseems wrong to stop progress at step 1 if we have a course of action to completion23:44
arosalesand we just need to make a decision to nack or ack those23:44
marcoceppiI was going to say it's the author of the tests job to fix the charm23:44
marcoceppithen I realized how much more work that was for me23:44
marcoceppiand decided to not say that23:44
marcoceppiexcept right then23:44
arosaleslazyPower: agreed23:44
marcoceppiwhen I said it23:44
lazyPowerarosales: because that basically says "We gave basic deploy tests, and its failing - so due dilligence is needed. No maintainers in 30 days step up? time to hit the eject button"23:45
lazyPowerthis will do a couple things23:45
lazyPowerditch some old charms people dont want to undertake updating, and give us metrics to empower the decision23:45
lazyPowerand i'm all for making data driven decisions23:45
arosaleslazyPower: ya I agree it helps get the charm into a fixed state by first identiying there is a problem23:45
lazyPowerarosales: so, can we make that the workflow? file a bug after the MP lands with the failing est23:46
arosalesthus my proposal is for the charmers to accept charm tests even if the charm is failing those tests23:46
lazyPowerand that kicks off the countdown timer23:46
lazyPowerarosales: i'll be happy to go through and verify everything that i run across during review time if you leave a breadcrumb trail that its been filed and identified as a failure23:46
lazyPowerand we can pass off a notice to other charmers that this is what we are donig23:46
lazyPower*doing23:46
arosaleslazyPower: so all the charms @ http://review.juju.solutions/23:47
lazyPowerarosales: woo all of them are failing? hooo boy23:47
* lazyPower puts on his firemans hat23:47
arosalesfrom mbruzek and marcoceppi with "add-tests" or "tests" branch are what need approval23:47
lazyPower10-423:47
lazyPowerif you pre-triage i'll follow behind you before i EOD or first thing tomorrow23:47
lazyPoweri still owe for review this week - i managed to miss my slot on Tuesday23:47
arosalesalso tvansteenburgh and mbruzek +1ed accepting these tests23:47
arosalesjsut wanted at least charmers to +123:47
lazyPoweryeah, still need votes from jose, dpb1, and niedbalski if they are around and want to chime in23:48
lazyPowerbut i'm all for it23:48
arosalesso if lazyPower and marcoceppi +1 then it sounds like it ok for your to accept these tests for the above reasons23:48
lazyPoweryou sold me, good salesmanship23:48
* arosales already pinged them ealier23:48
lazyPowerah, then we'll silently discard those votes if they are negative ;)23:48
arosalesno replies yet23:49
lazyPower<3 if they read scrollback23:49
arosaleswell you have the majority of charmers +1ing it23:49
arosalesbut I would be interested to hear an objection if there is one23:49
lazyPoweryeah i'm just being obtuse. its late in the day.23:50
* lazyPower goes back to hacking on subordinate logic23:50
arosaleslazyPower: I am happy to traige those test MP,  what specific action do you need from me a +1 on the syntax of the charm tests?23:50
lazyPowerI would say that, and i'll go through and add bugs to the charms when the MP's land for failing tests23:51
lazyPowerthat way its part of my wrap-up email to the list23:51
lazyPowerwhich can serve as day 1 of notice23:51
lazyPower30 days to fix failing tests, unless other active dev is going on - if active dev is going on - they get an extension to fix the tests basically. but it puts us 1 step closer to trimming the warts on the store.23:51
arosalessounds good23:52
arosalesI am going to finish up my review of OpenID/SSO  and then work on the testing MPs23:52
arosaleslazyPower: thanks!23:52
* lazyPower hat tips23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!