/srv/irclogs.ubuntu.com/2020/03/12/#juju.txt

narispohi, what can one do to deploy a recent hadoop/spark/solr/hbase stack? Apache Ambari ships Hadoop 2.7, Apache Bigtop, Hadoop 2.8, Slor 6.5. Jujucharms are based on Bigtop so also ship these unsupported/outdated/with-unfixed-cve versions.00:30
narispoSolr *00:30
=== _thumper_ is now known as thumper
thumpernarispo: to be honest I'm not sure, but perhaps ask on our discourse?01:03
narispothumper: I guess. Should probably reach to Canonical sales/engineering directly.01:05
thumpernarispo: canonical doesn't own those charms as far as I'm aware01:05
narispobigdata-charmers is community work?01:06
thumperah... I think it is at the moment...01:06
thumperit didn't used to be01:06
rick_hthumper:  narispo yes, it's community work01:28
rick_hwe've got some close folks in the community that leverage them but there's no team in canonical that maintains them01:28
narisporick_h: okay! well I'm looking into improving Bigtop itself with version upgrades right now so that we can deploy a recent Hadoop cluster. We care about Spark, Solr, HBase, with Hadoop. So Bigtop's next release (1.5) plans to update to Solr 6.6 (unsupported, very bad, latest is 8.4.1), Spark 2.4.5 (latest, very good), HBase 1.5 (outdated, bad, latest is 2.2.3), and Hadoop 3.2.1 (latest, very good).01:32
narispoSo that gives me HBase and Solr to look into and upgrade inside Bigtop.01:32
rick_hnarispo:  yea, I think you're finding the ones more used (up to date) and less used (out of date). It'll be awesome to have them brought up to speed. Thanks!01:33
narisporick_h: another disadvantage is that Bigtop doesnt seem to do patch releases.. so individual components may stay vulnerable to security issues for months until the next Bigtop release is out.01:35
narispoAnd that includes the big ones used by tons, such as Spark or Hadoop.01:35
thumperhttps://github.com/juju/juju/pull/11310 for anyone that wants a faster juju status03:42
tlmcan take a look in a bit thumper just wrapping something up03:49
=== jam1 is now known as jam
thumpertlm: thanks04:30
tlmlgtm thumper04:44
thumpertlm: thanks04:49
thumperI'll merge it once the 2.7.4 release branch has merged it04:50
thumpers/it/in/04:50
babbageclunkuh, what's happening with the 2.7 merge run?04:53
babbageclunkhttps://jenkins.juju.canonical.com/job/github-make-check-juju/4364/console04:53
babbageclunklooks like dep has hung?04:54
thumperbabbageclunk: it has only been going two minutes04:54
babbageclunkoh duh, missed that it was new04:55
babbageclunkthat would do it04:55
thumper:)04:55
thumperit's off and racing04:57
=== Guest63738 is now known as skay
achilleasarick_h: is it even possible for a unit to depart a peer relation?17:08
rick_hachilleasa:  ...thinking. The destroy process always confuses me because there is "I'm going away"17:15
rick_hachilleasa:  but it's not like a relation you can choose to opt out of17:16
achilleasayes, with the relation-created changes units will automatically be in a peer relation (even if they are is only a single unit)17:17
rick_hachilleasa:  right, makes sense17:25
achilleasahml: just to confirm, the TODO in `runCharmProcessOnRemote` in 11257 will be handled with an upcoming PR, right? I remember seeing a comment in the other PR18:28
hmlachilleasa:  yes18:29
hmlachilleasa:  working on the unit tests for the pr that resolves the TODO now18:30
achilleasahml: I think 11257 is good to go with your changes. Running the QA steps18:31
hmlachilleasa:  cool, ty18:31
achilleasahml: is this passing for you? WorkerSuite.TestInvalidDeploymentChange18:52
hmlachilleasa:  checking18:54
hmlachilleasa:  yes.  running with stress script18:54
hmlachilleasa:  130 successful runs19:00
achilleasahml: 11257 approved19:15
hmlachilleasa:  awesome!  ty19:15
achilleasahml: if you push the other one later today assign it to me so I can review it in the morn19:16
hmlachilleasa: ack19:16
wallyworldkelvinliu: tlm: bug 1867168 ... why would they be connecting to pods and not the service? I want to push back and tell them to use the service front end. do you agree it's bad k8s practice for extermal actors to use the pods and not the service?23:10
mupBug #1867168: No easy way to retrieve pod fqdn <juju:New> <https://launchpad.net/bugs/1867168>23:10
tlmtaking a look23:11
tlmwallyworld: want me to reply to it ?23:14
wallyworldtlm: do you agree with my assertion?23:14
tlmyep, there is use cases for what they want but there is an accepted way todo this through multiple services23:16
wallyworldtlm: gr8, if you could suggest the approach that would be good23:17
tlmwallyworld, we could implement what they want FYI23:19
wallyworldwe could but would prefer not to if it's bad practice23:20
wallyworldwe support valueRefs now etc, i asusme we'd use that if needed23:20
tlmdo we support multiple services ?23:21
wallyworldor they could use that, assuming k8s exposes such info that way23:21
kelvinliuprobably they want to maintain the mongodb replica set connection string23:21
tlmthe cases where I have seen this is where you have a db replicas and want to talk to masters and or slaves23:21
tlmbut the solution has always been run two services23:21
wallyworldwe support a core service for the app plus a headless one23:21
tlmor n services23:21
tlmwant to HO this before I finish reply ?23:22
wallyworldsure23:22
babbageclunkanastasiamac: could you take another look at https://github.com/juju/juju-restore/pull/8? I've made changes from your comments and also added getting ha-nodes from the backed-up agent.conf23:48
anastasiamacbabbageclunk: looking23:55
babbageclunkthanks!23:55

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