#juju 2012-02-06
<koolhead11> hi all
<_mup_> juju/robust-test-removed-service-unit r457 committed by jim.baker@canonical.com
<_mup_> Fix test in use of watch so it doesn't assume that it will see all changes to a ZK node (because it won't)
<_mup_> juju/increase-session-timeout r448 committed by kapil.thangavelu@canonical.com
<_mup_> allow managed zk to specify longer timeout
<hazmat> adam_g, ping
<adam_g> hazmat: pong
<hazmat> hi adam_g i was playing around with deploying dependencies to create automated tests that can verify relations, and smoser pointed out that for openstack there is a required ordering to make it work.. i was just curious about some of the details, the sample test plan i have for nova-compute is.. http://paste.ubuntu.com/831927/
<hazmat> also i wanted to talk about the dependencies for the swift charm, it seemed strange to me that swift-storage both requires and provides swift, seems like it was intended that it provides 'swift', and the proxy requires it.
<adam_g> hazmat: sure, one sec
<adam_g> hazmat: so, wrt ordering.. service like nova-volume and nova-compute are basically useless without functioning [nova-cloud-controller, rabbitmq, mysql]. all the nova-* components require access to the database and rabbit queue
<SpamapS> hazmat: this goes back to what I said, which is that relations shouldn't actually be established until all of a service's required relations are established
<adam_g> hazmat: for nova's authentication to work, the nova-api server (part of nova-cloud-controller) needs a relation to the keystone service.. which, ideally, has a relation to a database. its possible to not use an external database and store in a local sqlite database, but if a new data store is introduced through a new relation, all existing auth + service entries need to be migrated to the new db.
<hazmat> SpamapS, it goes beyond that, its assuming a global ordering to the required relation establishment.
<adam_g> hazmat: nova-compute + cloud-controller then need another relation to the glance service in order for images to function. glance also requires a database and a keystone relation
<hazmat> adam_g, so it sounds like, what SpamapS said, if all the required relations for a service are deployed for a service then its provided interfaces can have relations established
<hazmat> ie. it doesn't need a particular ordering of dependency established, ie. add rabbitmq before keystone or mysql for nova-compute
<adam_g> hmm
<adam_g> (looking thru charms)
<adam_g> hazmat: so,   deploy keystone, nova-*, glance.  for each, satisfy required relations. once each components required relations are established, add relations between each depending on what is provided. ?
<hazmat> adam_g, yeah
<adam_g> hazmat: is it an issue that keystone is a required relatin of both nova-* and glance? it may end up that things do adhere to some global order depending on what interfaces exist, even if its not defined explicitly
<hazmat> adam_g, that's fine re keystone
<adam_g> hazmat: fwiw, this is what a deployment looks like currently, in terms of ideal ordering: http://paste.ubuntu.com/831987/
<koolhead17> m_3: hello there
<adam_g> hazmat: about swift. yea, you're right. the interfaces are poorly / incorrectly named. that charm is a bit dated and ive got work items this cycle to rewrite it. for now, i can propose an update along the lines of: swift-proxy provides proxy:swift-proxy, swift-storage provides storage-ring:swift-storage
<hazmat> adam_g,  that sounds good
<adam_g> hazmat: i'll also propose merging those changes to interfaces we talked about last week. i had gotten distracted and forgot about that, sorry
<hazmat> adam_g, thanks
<hazmat> adam_g, fwiw, here's what i get for an automated ordered relation list http://paste.ubuntu.com/832017/
<hazmat> for nova-compute
 * koolhead17 scratching his head to try this whole OS charms!! :P
<adam_g> hazmat: is this the oneiric charms?
<SpamapS> hazmat: That looks awfully close to "establish required relations before provided relations start working"
<SpamapS> hazmat: I don't think you have to assume global ordering. Juju can simply see that nova-cloud-controller isn't ready to start providing things until the requires: are satisfied.. so it would do nothing with the relations established to its provide side, until the requires side is done.
<SpamapS> hazmat: the problem there is that the relations have no way of saying "I am established"
<ejat> hi, is there a way to generate admin-secret & control-bucket
<ejat> for environments
<jimbaker> SpamapS, i don't understand that statement, isn't that the point of relation settings to say stuff like that?
<hazmat> SpamapS, your right it is just establish required first, i was concerned it might be more than that, wrt to relation established just identifying a steady state for a timeout wrt to status changes for the rel should suffice
<SpamapS> hazmat: I suppose steady state is achieved if all hooks exit 0 w/o relation-set
<SpamapS> jimbaker: relation settings are for the other side of the relation. They're meaningless to juju itself.
<SpamapS> hazmat: Actually, this could work.
<jimbaker> SpamapS, agreed on their meaning to juju. i guess the problem here is you want more explicit support from juju on relations being established
<hazmat> SpamapS have you seen smoser's deployer script, i'm thinking about just feeding these plans into that
<hazmat> http://bazaar.launchpad.net/~smoser/+junk/juju-deployer-concurrent/view/head:/deployments.cfg.jstack
<jimbaker> stacks, nice :)
<hazmat> jimbaker, SpamapS we can add a helper script to juju-tools for better external rel inspection and watching
<jimbaker> hazmat, just for inspection, or also used to control the adding of relations in a stack?
<adam_g> hazmat: i wrote that script btw, the weight'ing was my naive solution to the issue of 'i need keystone up first before anything else'
<hazmat> adam_g, oh.. cool, i like it :-)
<hazmat> jimbaker, just for inspection, but inspection against a rel is a timeout against a steady state of no change, we can either have the timeout on status change or just use the related watch
<jimbaker> hazmat, ok, such tools at least tell us the real needs here. ideally there would be no need to have the deployment script need to manage having keystone up before it can do anything else
<adam_g> jimbaker: well, keystone should ideally have a relation to its back end database before taking relations from any services on the interface it provides.
<jimbaker> adam_g, sure, it just seems that this can be negotiated using relation settings
<hazmat> jimbaker, agreed, bcsaller's described implementing subordinates that way before.. which gave the properties/effect that deploying things with unfufilled requirements where a noop.
<jimbaker> hazmat, albeit it seems like an orthogonal concern to subordinates. anyway, real code will give us a better understanding of what's missing in juju, so certainly adam_g's plan sounds good
<bcsaller> hazmat: well, the service state is still created and appears in status, but no units are allocated and no machine assigned
<SpamapS> I don't think any drastic change is necessary.. except that people would be confused by nothing happened when required relations aren't established..
<SpamapS> Basically right now relations are just watched and acted on, but the unit agent would have to delay acting on provides relations until all required relationships have reached a steady state where all hooks have exitted w/o changing any settings.
<SpamapS> So there would need to be another state beyond 'up' which would be 'steady' or something like that... and that would be managed by the unit agents on both sides.
#juju 2012-02-07
<SpamapS> Should be pretty simple too.. if hook=changed && len(relation_changes) == 0: relation.set_state('steady')
<jimbaker> SpamapS, i just don't understand why that isn't a relation setting itself
<SpamapS> jimbaker: so you're going to make state a special relation setting?
<jimbaker> you could put any number of such state variables in the relation settings, just need to agree on a conention
<jimbaker> convention
<SpamapS> that seems to violate the encapsulation that is around relation settings right now
<jimbaker> i just don't see the special treatment required, that's all. it's just between service units anyway imho
<SpamapS> The convention I'm agreeing on is that the hooks decide not to change anything, so this is a clear intent: that side of the relationship is steady.
<SpamapS> If both sides of a relationship are steady, it would be considered fully established.
<jimbaker> sure, that might be useful from a status perspective
<SpamapS> from an ordering perspective, its vital
<SpamapS> I need to know that keystone has mysql and rabbitmq before I start asking it for credentials
<jimbaker> i guess i just don't understand why relation settings are not powerful enough to express this
<SpamapS> jimbaker: they're *too* powerful
<SpamapS> jimbaker: they're free form, and can be anything... juju shouldn't imply anything by any of the relation settings.
<SpamapS> But you can absolutely imply that the relationship is fully estblished if neither side sets any values.
 * SpamapS feels that perhaps code is needed.
<jimbaker> SpamapS, right, but again, i don't understand why juju should do anything except sit back and orchestrate. anyway, agreed on the utility of saying this in status
<SpamapS> It is going to sit back and orchestrate. Right now it is providing relationships that it cannot possibly satisfy
<SpamapS> jimbaker: keystone simply cannot provide 'interface: keystone' until it has mysql and rabbit
<SpamapS> jimbaker: if you make a relation setting special, that will work. But there's no need for tampering with relation settings. You have an implied state already.
<jimbaker> SpamapS, i definitely don't want to make any relation setting special
<jimbaker> other than whatever interface two services agree upon, without juju making any special assumptions about that
<SpamapS> right so I think we're talking past eachother then
<jimbaker> SpamapS, no worries. i'm sure it will be clearer with some good code examples
<jimbaker> and we should definitely put this api change out there for juju status and 'steady'
<jimbaker> and see if that's something that can be done or not
<SpamapS> I don't necessarily think it has to be an API change at first
<SpamapS> well yeah, using a second state would be lame
<SpamapS> but really, this has almost *nothing* to do with status output
<SpamapS> thats just a nice side effect
<jimbaker> SpamapS, changing the unit lifecycles is an api change, even if it's pretty trivial as above
<SpamapS> jimbaker: aye
<adam_g> hazmat: still around?
<hazmat> adam_g, yup
<SpamapS> going through the steady state idea in my head.. I think its doable.. but would break ZK backward compatibility
<SpamapS> since you'd need a new state for unit relations
<adam_g> hazmat: im adding some of these optional required relations to the nova charms, as per our conversation last week. now i'm hitting the 'Ambiguous relation' errors. is that just a PITA atm or are actually charms not meant to provide multiple interfaces?
<SpamapS> adam_g: you were just meant to always be explicit about which relation you meant to use. :)
<hazmat> adam_g, if a charm provides the same interface multiple times, the name has to be specified when adding the relation
<adam_g> ok
<hazmat> adam_g, this was in regard to nova-compute and nova-volume depending on nova-controller?
<SpamapS> hazmat: thats actually a pretty big problem... we'll break lots of deploy scripts any time we add an optional relation for convenience purposes or something. :-(
<ejat> hazmat & SpamapS : mind to help with this http://paste.ubuntu.com/832099/
<adam_g> hazmat: yes, about having an optional cloud-controller interface that is listed in the metdata but actually has no hooks. there is also another interface on cloud-controller that is specific to compute nodes, which is causing the ambiguity
<SpamapS> ejat: you forgot 'local:'
<ejat> if i want to try at ec2 ?
<hazmat> SpamapS, true, either we spec them explicitly or avoid the use of multiply providing it.
<hazmat> ejat, its still local: prefix to the charm
<ejat> repository ?
 * ejat blur
<SpamapS> adam_g: no hooks? doesn't that sort of mean that its not the same interface?
<SpamapS> ejat: symfony should be 'local:symfony'
<hazmat> adam_g, yeah.. that sounds odd
<ejat> SpamapS: owh okie
<hazmat> adam_g, so take nova-compute.. http://charms.kapilt.com/~gandelman-a/precise/nova-compute
<hazmat> its depending on nova-volume, but its using a generic interface 'nova'
<adam_g> as we discussed last week, there is the issue that nova-compute and nova-volume will never have a direct relationship between them, but listing them in the metadata helps model the dependencies of the entire deployment, at least IIRC
<hazmat> which is also used by nova-cloud-controller
<hazmat> there are different interfaces
<hazmat> s/there/those
<hazmat> adam_g, the ambiguity was that both 'nova-cloud-controller' and 'nova-volume' provide the 'nova' interface
<hazmat> thats actually two interfaces, they don't provide the same thing
<adam_g> right
<adam_g> nova-volume will now provide instance-storage:nova-volume
<hazmat> sounds good
<adam_g> nova-cloud-controller cloud-controller:nova
<hazmat> ok
<adam_g> nova-volume + nova-compute both interface with cloud-controller:nova
<hazmat> so now nova-compute depends on nova, and nova-volume, and nova-volume depends on nova
<hazmat> eek hard to parse
<adam_g> hazmat: i guess whats fuzzy to me is the dependency between nova-compute and nova-volume.  there will never be a direct relation, but IIRC last week we discussed listing it in nova-computes metadata as an optional require:, is that right?
<hazmat> adam_g, they depend on the interface not the named interface, but sounds good, why doesn't nova-compute have a dependency on the 'nova-volume' interface
<SpamapS> I'd guess because they can exist w/o eachother.
<adam_g> nova-compute and nova-volume never talk to one another directly, the message bus and database provide that
<hazmat> adam_g, what's the api endpoint?
<adam_g> and yes, one can exist w/o the other, tho the features its exposed to would then be limited
<hazmat> adam_g, do nova-compute and nova-volume both have different api endpoints?
<ejat> http://paste.ubuntu.com/832105/ .. i follow wordpress charm
<adam_g> hazmat: they dont have api endpoints
<hazmat> adam_g, what component offers the nova api?
<adam_g> hazmat: nova-cloud-controller
<adam_g> (nova-api, nova-scheduler)
<SpamapS> ejat: sweet
<hazmat> adam_g, then nova-cloud-controller has the dependency on nova-volume and nova-compute
<adam_g> hazmat: right
<ejat> but it wont expose :(
<adam_g> hazmat: and nova-compute + nova-volume have no knowledge of each other, in terms of metadata/hooks. correct?
<SpamapS> ejat: state: pending ... you need 'state: started' ;)
<hazmat> adam_g, right
<adam_g> ok i think we're on the same page now :)
<hazmat> cool
<ejat> apache not start ?
<SpamapS> hazmat: so, whats the idea here? that you can relate them to aid with what?
<SpamapS> ejat: ssh in and look at /var/lib/juju/units/symfony-0/charm.log
<ejat> thanks .. forget -y :)
<ejat> brb ..
<ejat> fixing it ..
<hazmat> SpamapS, no need for the additional relation, just trying to unambigiously identify the dependencies for a charm
<hazmat> SpamapS, the current nova-compute has an ambigious dependency around 'nova' which could be satisified by nova-volume or nova-cloud-controller, but it sounds like really that dependency doesn't exist, and instead its the nova-cloud-controller that depends on unique interfaces of -volume and -compute
<SpamapS> hazmat: yeah it sounds like the nova interface was accidentally overloaded
<ejat> SpamapS: http://paste.ubuntu.com/832120/
<ejat> which charm sample should i refer
<ejat> for the mysql thingss
<SpamapS> ejat: there is already a mysql charm. Why are you deploying mysql?
<ejat> owh .. thnaks remind .. sorry ..
<ejat> removing it ..
<SpamapS> ejat: its perfectly normal to have mysql + another thing in one charm.. just seems odd
<ejat> bcoz just now i test it all in one ..
<SpamapS> ejat: anyway, if you use the juju from the PPA, instead of oneiric.. you'll get DEBIAN_FRONTEND=noninteractive when you run 'apt-get -y install foo' it won't ask these questions.
 * SpamapS hopes to SRU that back to oneiric.. if we fix the bug where you can't SRU juju because it won't allow pulling from proposed. :-P
<ejat> already put -y
<SpamapS> anyway, I have to go
 * SpamapS disappears
<ejat> ok ..
<adam_g> hazmat: sent some merge proposals to fix the interfaces on the oneiric branches. need to update that deployer script those ambigious relations before fixing precise, else our CI breaks
<hazmat> adam_g, why do you have ambigious relations?
<adam_g> hazmat: nova-cloud-controller provides a second interface to nova-compute for nova-network configuration
<hazmat> nova-cloud-controller afaics shouldn't be providing interfaces to nova-x services. it should be depending on all of the nova-x's
<hazmat> nova-cloud-controller depends on nova-network, nova-volume, nova-compute interfaces
<adam_g> hazmat: there is currently no nova-network charm. depending on which networking flavor is configured, nova-network may run on the cloud-controller or compute node.
<ejat> hazmat: http://paste.ubuntu.com/832144/
<adam_g> hazmat: configuring FlatManager requires nova-network on the cloud-controller + a bridge interface manually configured on -compute + -cloud-controller. FlatDHCPManager requires no bridge configuration, but nova-network running on the compute node with a couple of flags set in config
<hazmat> adam_g, sounds like something which needs to be driven off the 'nova-compute' relation between -cloud-controller and -compute, in those cases its not really a separate charm
<hazmat> adam_g, with quantum does the network component still have to be installed on the compute nodes?
<adam_g> hazmat: im not sure, i haven't touched quantum yet. AFAIK, its a seperate service that runs somewhere in the deployment with nova-network configured to use a pluggable QuantumManager driver like it would FlatDHCPManager
<niemeyer> Good mornings!
<jcastro> SpamapS: may I G+ you when you're around?
<jcastro> I need maybe 10 minutes of feedback from you and then I'll be done. :)
<SpamapS> jcastro: server team meetings have me busy from now until 2+ hours from now
<jcastro> ok, can I have dibs after?
<jcastro> :)
<SpamapS> jcastro: you had dibs at hello
<SpamapS> jcastro: You had dibs at *HELLO*
 * SpamapS breaks down
<koolhead17> SpamapS: good morning sir!! :)
<mpl> SpamapS: Hello?
<mpl> feeling any better now? :)
<_mup_> Bug #928348 was filed: Charm bundles should work with symlinks <juju:New> < https://launchpad.net/bugs/928348 >
<SpamapS> mpl: hi!
<mpl> :-)
<hazmat> m_3, SpamapS, adam_g fwiw i've put the automated charm testing tools i've been experimenting with over here https://code.launchpad.net/~hazmat/+junk/charmrunner
<hazmat> currently it can generate an automated test plan for deps and setup an environment from a json file (the environment is reusable between setups)
<jcastro> SpamapS: available yet?
<SpamapS> jcastro: meetings over soon
<SpamapS> jcastro: t-minus 5 minutes
<SpamapS> jcastro: GO
<jcastro> SpamapS: hangout firing up
<otubo> Hello guys, I was wondering if the 'stop' hook is called when calling 'destroy-environment' command.
<otubo> My idea is to backup my data and upload it (to dropbox, for example) before actually destroying the instance.
<SpamapS> otubo: Currently stop is never called.
<SpamapS> otubo: destroy-environment == rm -rf
<SpamapS> otubo: be careful. :)
<otubo> SpamapS, roger that! Thanks :-)
<hazmat> bcsaller, adam_g, SpamapS  fwiw, i ended up doing this for service watching.. http://bazaar.launchpad.net/~hazmat/+junk/charmrunner/view/head:/charmrunner/watcher.py
<SpamapS> oh this is weird
<SpamapS> $ juju set jenkins plugins='openid instant-messaging ircbot bazaar'
<SpamapS> Expected `option=value`. Found `instant-messaging`
<SpamapS> no way to do a space delimited value
<hazmat> SpamapS, i think you just need the right escape there
<SpamapS> juju set jenkins plugins=openid\ instant-messaging\ ircbot\ bazaar
<SpamapS> that doesn't work
<SpamapS> I wonder if this is argparse's problem
<hazmat> SpamapS, it might be a problem with the parse logic.. i'd try a double qoute..
<SpamapS> juju set jenkins "plugins=openid instant-messaging ircbot bazaar"
<SpamapS> does not work
<SpamapS> sh -c 'juju set jenkins "plugins=openid instant-messaging ircbot bazaar"'
<SpamapS> *that* worked
<Atlantic777> m_3: hi! Hen you held an class in #ubuntu-classroom during ubuntu developer week you were using something to show us juju via ssh. What tool was thta?
<Atlantic777> When*
 * Atlantic777 has to change keyboard...
<m_3> Atlantic777: hey
<m_3> Atlantic777: I was using a charm called juju-classroom... it's just a specialization of byobu-classroom
<Atlantic777> m_3: a friend of mine wants to start irc classrooms so I find this a useful thing for him. :)
<Atlantic777> thanks
<m_3> Atlantic777: sure thing
<m_3> there're plans to scale this... it's limited by ajaxterm atm
<m_3> somethiung like 20 connections at once or so
<Atlantic777> m_3: native ssh client is more interesting :D
<m_3> yup... that should scale nicely
<SpamapS> Yeah should be able to scale out using a simple tiered approach where every node ssh's once time into the backend byobu and then all ssh clients just join that screen.
#juju 2012-02-08
<_mup_> Bug #928624 was filed: cached unit public addresses are problematic when public ip address changes <juju:New> < https://launchpad.net/bugs/928624 >
<Ruetobas> hi, how do i "de bootstrap" juju ?
<Ruetobas> or, how do i tell juju that new systems are available for it to use ?
<ejat> SpamapS:  how to expose the services .. already run juju expose services .. the web services not appear in browser http://paste.ubuntu.com/833602/
<ejat> or can someone help me with that ?
<jorge> Hi all! I need some help with two issues. I'm trying to use juju charms. I would like to use hadoop-master and hadoop-slave formulas from https://code.launchpad.net/~charmers/. Apparently all is working fine with juju because I can use the mysql and mediawiki charms normally. But, with the hadoop charms the problem is that the service stops at some point.
<jorge> So, I've tried https://juju.ubuntu.com/docs/write-charm.html#debugging-hooks to debug. I could connect to instance and run the install script from charm manually. When I run the script manually at the instance, I get no error! But with juju deploy I get some errors.
<jorge> Are there some test to do?
 * hazmat yawns
<koolhead17> hi all
<gary_poster> SpamapS, hazmat, hi.  two questions about units.  (1) if you are talking to a unit, is there a way to identify that other unit uniquely? (2) Can you have different units with different configuration?  I'm guessing no, but that's kinda limiting.
<gary_poster> For question 1, I'm interested particularly in relation-changed and relation-joined
<SpamapS> gary_poster: I don't understand question 1 , but for question 2, that would violate the point of juju.. two separate configurations of a service are two separate services.
<hazmat> gary_poster, 1) the unit is passed to hooks 2) the units can coordinate among themselves if they need different state (a leader vs slave), but they share the same service configuration,
<SpamapS> gary_poster: can you perhaps provide a more concrete example of what it is you want to do?
<gary_poster> SpamapS, for 2, ok, let's step back to use case then.  for the case of a build slave connecting to a build master, you will want to have multiple build slaves each running different tests.  Having different charms for each kind of test config that might run would be annoying--not very lightweight for something that should be lightweight
<gary_poster> hazmat, so for 1, does unit-get refer to the one on the other side?  It seemed like it was talking about itself.  If not unit-get, how do we get that unit?
<SpamapS> gary_poster: right, so each build slave is then its own instantiation of each charm as service1, service2, with different config settings.
<SpamapS> gary_poster: so you'd juju deploy build-slave slave-config1 --config config1.yaml
<SpamapS> gary_poster: so you'd juju deploy build-slave slave-config2 --config config2.yaml
<gary_poster> SpamapS, ah!  ok.  perfect thanks
<SpamapS> gary_poster: note that the master needs to be smart about relationships with > 1 service. Some charms don't do that (like haproxy)
<hazmat> 1) the local unit id is available as an environment variable ($JUJU_UNIT_NAME) to all hooks, and unit-get refers to information about the local unit
<gary_poster> SpamapS, can you point us to a master that is smart about that kind of multi-relation?
<hazmat> the remote unit that triggered a local hook execution is available in the env as JUJU_REMOTE_UNIT
<gary_poster> I mean, a charm
<gary_poster> hazmat, got it, https://juju.ubuntu.com/docs/charm.html#hook-environment thanks & sorry for not seeing it
<hazmat> gary_poster, np
<hazmat> i've been playing with this same topic (build slaves), i ended up having the slaves register with the master with an identity and local env information, and have the master divy out work appropriately to different queues (distro release, arch, etc) which the categorized slaves listen to.. but thats all application level
 * hazmat  goes back to reviews
<gary_poster> SpamapS, am I right that in your deploy example you would set up a relation between the master and slave-config1, right?
<SpamapS> gary_poster: mysql is very smart about that
<SpamapS> gary_poster: it creates a database based on the related service name.
<gary_poster> hazmat, yeah, that's cool.  We need to have a custom environment in some cases, so being able to control that at a service level is nice.  Otherwise when the work is divvied out, all of a sudden you have a lot of environment prep work that needs to be done.  having it done once would be good.
<SpamapS> hazmat: please.. tell me you didn't rewrite jenkins
<SpamapS> in scala
<SpamapS> blindfolded
<SpamapS> ;)
<hazmat> SpamapS, of course not ;-) i used go
<gary_poster> heh
<hazmat> although i was tempted by clojure
 * SpamapS knows hazmat is a code ninja
<gary_poster> yay clojure!
<gary_poster> SpamapS, awesome, thanks, will look.  FWIW, we do have one small bug we think we have encountered: setting a relation value on a master and then retrieving that relation's value on the next relation-changed on the master fails to get the value we just set.
<gary_poster> I'll file a bug.
<gary_poster> coming up with a small charm to dupe may take a bit.
<SpamapS> gary_poster: relation-get does not fetch the values you just set
<SpamapS> gary_poster: relation-set exposes it to the other side of the relation.
<gary_poster> Not even in (immediately) subsequent hook
<gary_poster> ?
<SpamapS> gary_poster: and it is not flushed and exposed to the other side of the relation until the hook that called relation-set exits
<gary_poster> transactional-ish--I had figured, yes
<SpamapS> gary_poster: so if you are seeing that changed is executed on the other side of a relation without the values you just relation-set .. its possible something else caused changed to be executed
<SpamapS> gary_poster: changed is *always* executed once... and you have to write changd hooks tolerant of not having any values yet
<gary_poster> SpamapS, here's scenario: service 1 sets relation value in relation with service 2; service 2 gets value and does other stuff, including changing the relation again; service 1 is therefore re-called with a relation-changed, and wants to see if it has already told service 2 that value, so it checks with relation-get.  IIUC, that last usage is unsupported?
<gary_poster> (in the last step, if we have not told service 2 a value, we generate a new one)
<gary_poster> (which is why juju doesn't save us from ourselves)
<SpamapS> gary_poster: ah, I see the confusion
<SpamapS> gary_poster: there are *two* buckets of values there
<SpamapS> gary_poster: service1/0 has values, and service2/0 has values
<gary_poster> ah, and the twain don't meet
<SpamapS> gary_poster: Because relation-get and relation-set are context sensitive, you can't look at your own values.
<gary_poster> SpamapS, gotcha.  Thank you
<SpamapS> gary_poster: if you need to avoid repeating an action, keep track of state locally. If you're worried about endless loops of changed hooks with the same values.. you don't have to. Hooks are only fired when the values actually change.
<gary_poster> SpamapS, yeah, we'll do it locally thanks.  We were changing (generating) the values, which is why we had a problem
<SpamapS> !jenkins
<juju-jenkins> SpamapS did you mean me? Unknown command ''
<juju-jenkins> Use '!jenkins help' to get help!
<SpamapS> hazmat: figured out the problem with the jenkins test failing
<SpamapS> hazmat: juju can't run its tests from a tree with any spaces in it
<SpamapS> [pid   446] execve("/var/lib/jenkins/jobs/juju", ["/var/lib/jenkins/jobs/juju", "tests/workspace/bin/unit-get", "private-address"], [/* 9 vars */]) = -1 ENOENT (No such file or directory)
<SpamapS> koolhead17: go to sleep!
<koolhead17> SpamapS: i can once done with the tiny piece :)
<_mup_> Bug #929030 was filed: Test suite fails when run from within a directory with spaces in its name <juju:In Progress by clint-fewbar> < https://launchpad.net/bugs/929030 >
<gary_poster> OK here's something odd
<gary_poster> in relation-joined on slave we set a value in the relation
<gary_poster> and that never gets in the log of the master
<SpamapS> gary_poster: no guarantees it won't be set by then
<SpamapS> oh wait
<SpamapS> I read that wrong
<SpamapS> gary_poster: are you sure the changed hook didn't execute again on the master?
<gary_poster> SpamapS, it executed twice...ah nm.  We were called but made an error, and expected to see the value in the master logs.  our error, sorry.
<SpamapS> gary_poster: its ok.. the juju dance can be a bit dizzying at first.. :)
<gary_poster> :-)
<hazmat> SpamapS, huh?
<hazmat> that's seriously odd
<hazmat> and worth a bug
<SpamapS> hazmat: ^^ 929030
<SpamapS> hazmat: I'm now tumbling down the twisted spawnProcess rabbit hole to see if it is doing something stupid with the PATH
<SpamapS> hazmat: you showed me once how to run the test suite under pdb
 * koolhead17 whistling juju juju loudly !!
<hazmat> SpamapS, ./test -b
<hazmat> SpamapS, you have to target a particular test, it catches on all errors (even caught ones)
<SpamapS> yeah thats cool
<hazmat> SpamapS, alternatively just adding import pdb; pdb.set_trace() anywhere
<SpamapS> oh, that sounds better
<hazmat> but if you hit a yield the stack is gone
<hazmat> so you want it as close to the point of inspection as possible
<SpamapS> hazmat: I think its actually create_hook's fault.. its creating a shell script but not escaping the spaces
<SpamapS> ye olde "not escaping the spaces" scurvy dog.. YAR
<hazmat> Argh!
<SpamapS> #!/bin/sh
<SpamapS> /var/lib/jenkins/jobs/juju tests/workspace/bin/relation-get --format=json -
<SpamapS> yup
<SpamapS> simple fix actually.. phew
<juju-jenkins> Project juju tests build #4: STILL FAILING in 1 hr 30 min: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/4/
<juju-jenkins> Project juju tests build #5: ABORTED in 1 min 11 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/5/
<SpamapS> hazmat: http://paste.ubuntu.com/834350/
<SpamapS> hazmat: build #6 should pass.. its applied on the jenkins box. :)
<juju-jenkins> Project juju tests build #6: STILL FAILING in 7 min 5 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/6/
<hazmat> SpamapS, lgtm
<m_3> SpamapS: thanks for thjenkins plugins... I'll pull those into charmtester as well
<michael_tn> good day all,
<michael_tn> i'm trying to spin up some ubuntu orchestra/juju
<michael_tn> i have orchestra/cobbler running
<michael_tn> juju bootstrap fails to see my active systems
<michael_tn> cobbler list shows these systems
<michael_tn> systems:    node064    node066 systems:    node064    node066
<michael_tn> juju bootstrap errors with
<michael_tn> 2012-02-08 15:29:58,775 ERROR Could not find any Cobbler systems marked as available and configured for network boot.
<_mup_> juju/unit-stop r423 committed by kapil.thangavelu@canonical.com
<_mup_> clean up stop spec
<hazmat> michael_tn, have you setup the orchestra classes in environments.yaml and assigned machines to the $available-mgmt-class
<hazmat> juju will use machines only that have the available-mgmt-class applied and are setup for netboot i think.
<SpamapS> hazmat: yes thats how it works
<juju-jenkins> Project juju tests build #7: STILL FAILING in 6 min 38 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/7/
<juju-jenkins> Project juju tests build #8: STILL FAILING in 6 min 55 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/8/
<juju-jenkins> Clint Byrum: [trivial][r=hazmat] Fix running of test suite inside sub-dirs that have spaces or other special shell chars
<SpamapS> http://paste.ubuntu.com/834557/
<SpamapS> hazmat: ^^ .. that test seems to have a race in it
<SpamapS>         # Do this as late as possible to prevent zk background logging
<SpamapS>         # from causing problems.
<SpamapS> That race seems to be hitting quite often on my little m1.small
<SpamapS> I'm a little confused why it sets LOG_LEVEL_INFO ..
 * hazmat pokes at the source
<SpamapS> bzr log -c 146.2.1
<SpamapS> ask bzr, and ye shall receive. ;)
<SpamapS> hazmat: seems like LOG_LEVEL_ERROR would be more appropriate given that the warnings are not fatal..
<SpamapS> hazmat: its really hard to understand at all what that test even wants to be doing
<hazmat> SpamapS, there's a race from when it sets the log level to when the operation is done
<hazmat> SpamapS, that test can be removed imo
<SpamapS> hazmat: it seems like that test is testing txzookeeper, not juju. ;)
<hazmat> its hard to test without adding a new method to the zk bindings
<hazmat> its trying to test a juju cli default behavior
<SpamapS> That behavior being.. return no output after removing a unit?
<SpamapS> So we could also just filter out all ZK log messages. Right?
<hazmat> SpamapS, by default we do
<hazmat> SpamapS, that test basically sets it to a level that would log, and then invokes juju since juju will set it to disabled, but there's a race between the two that is outside tests control
<hazmat> and then it tries to verify that nothing was logged, but that fails since between juju cli being run and the activation of logging, the zk extension/binding io thread does some logging
<hazmat> all we really want is to verify self.assertEqual(zookeeper.get_debug_level(), 0)  but that method doesn't exist
<SpamapS> hazmat: so its almost by definition a non-deterministic test because the logging is not forced.
<hazmat> SpamapS, yes, the io thread is outside of python's control.. its basically  setting up a fail scenario, and then trying to assert it didn't fail, but there is  a window for failure
<hazmat> SpamapS, we could minimize the window by moving the mocker.replay call up, but there will always be a window with that test, and frankly its a test i'd be fine with yanking.. alternatively we patch and upstream the new method call onto the bindings
<SpamapS> hazmat: I'm +1 on just removing the test
<SpamapS> hazmat: and opening a bug on python-zookeeper to add the call
<hazmat> SpamapS, sounds good to me
<SpamapS> or is that even further up, to libzookeeper itself?
 * hazmat checks
<juju-jenkins> Project juju tests build #9: STILL FAILING in 6 min 53 sec: http://ec2-23-20-64-9.compute-1.amazonaws.com:8080/job/juju%20tests/9/
<hazmat> SpamapS, its libzookeeper as well
<SpamapS> argh, no JIRA in launchpad still. Bummer.
<hazmat> SpamapS, ah.. we could just mock it
<hazmat> that would work well
<_mup_> Bug #929187 was filed: juju.control.tests.test_remove_unit.ControlRemoveUnitTest.test_zookeeper_logging_default is non-deterministic and should be removed <juju:In Progress> < https://launchpad.net/bugs/929187 >
<SpamapS> mock the zookeeper calls?
<SpamapS> hazmat: you want to take that?
<SpamapS> hazmat: I know I could do it, but I'm not so good w/ recording stuff for mocker. :-P
<koolhead17> so its juju add-unit  wordpress will add extra unit but juju add-unit wordpress --n=5
<koolhead17> add 5 units all toagther
<SpamapS> koolhead17: right
<hazmat> SpamapS,  http://paste.ubuntu.com/834593/
<koolhead17> Multiple charms can provide the same service and can be easily switched.   Does it mean charm like mysql and pgsql doing same
<hazmat> bcsaller, jimbaker could you look over this trivial ^
<jimbaker> hazmat, looking
<SpamapS> hazmat: oh snap :)
<SpamapS> hazmat: I constantly forget about replace. :)
<hazmat> SpamapS, it still feels a little suspect, mocker matching is a little magic, it doesn't execute just once, nor just twice, but some schrodinger cat polystate
<hazmat> jimbaker, thanks
<jimbaker> hazmat, +1, the right approach given this nondeterminism
<SpamapS> hazmat: I'll give you a bug #, since I already started writing it up
<SpamapS> hazmat: err, actually its 929187
<SpamapS> saved already
<koolhead17> SpamapS: yay!! am finally done!! :)
<niemeyer> hazmat: ping
<niemeyer> SpamapS: ping
<SpamapS> niemeyer: a-ding-dong? :) pong
<niemeyer> SpamapS: :-)
<niemeyer> SpamapS: Was wondering about the boolean stuff
<niemeyer> SpamapS: Do you know if it's made its life into juju yet?
<SpamapS> niemeyer: looks like no, according to bug #885551
<_mup_> Bug #885551: config.yaml should have boolean types <juju:In Progress by hazmat> < https://launchpad.net/bugs/885551 >
<niemeyer> SpamapS: Cool, thanks
<niemeyer> SpamapS: I've just run another import round in the repository
<SpamapS> niemeyer: much cleaner I hope
<niemeyer> SpamapS: A lot.. thanks for that
<niemeyer> SpamapS: It still has the boolean stuff
<SpamapS> niemeyer: mostly m_3's doing :)
<niemeyer> SpamapS: and includes just a few new items related to symlinks
<niemeyer> 126 charms total
<niemeyer> Well.. unique URLs
<SpamapS> niemeyer: I was just polishing up an edit to charm proof that checks for non-relative symlinks
<SpamapS> niemeyer: seems like eventually your code should supersede charm proof
<niemeyer> 22 issues only
<niemeyer> SpamapS: I hope this becomes "juju publish"
<SpamapS> though perhaps there is value in having a second implementation of the known rules.
<niemeyer> SpamapS: Yeah, I think there will always be room for a lint tool
<niemeyer> SpamapS: Since you can recommend conventions there
<niemeyer> SpamapS: The repository is black-or-white
#juju 2012-02-09
<hazmat>  niemeyer pong
<niemeyer> hazmat: Heya
<niemeyer> hazmat: Was just wondering about the boolean stuff, but Clint already mentioned it's still on going
<hazmat> hmm. wasn't appearing in the kanban view the other branch masked it
<niemeyer> hazmat: Most of the remaining issues seem related to it
<niemeyer> hazmat: Also a couple of new cases related to symlinks
<SpamapS> niemeyer: I've only seen basic symlinks in charms.. the kind where they link  foo -> ./common.sh
<niemeyer> SpamapS: Yeah, these are still fine
<niemeyer> SpamapS: We'll prevent only the symlinks pointing out of the charm
<niemeyer> SpamapS: The are only two occurrences in the entire repo
<niemeyer> There are
<SpamapS> I'd bet those are not in the reviewed charms
<niemeyer> SpamapS: I've sent the output of the import round to the list
<niemeyer> SpamapS: It's
<niemeyer> ----- lp:~yellow/charms/oneiric/buildbot-slave/trunk
<niemeyer> and
<niemeyer> ----- lp:~openstack-ubuntu-testing/charms/precise/nova-cloud-controller/trunk
<niemeyer> It's really unfortunate that we didn't start revisions on 1'
<jimbaker> finally, reproduced bug 912812 in a simple test
<_mup_> Bug #912812: Error condition on relation hooks locks events processing <juju:In Progress by jimbaker> < https://launchpad.net/bugs/912812 >
<jimbaker> (about time ;) )
<_mup_> juju/purge-queued-hooks r454 committed by jim.baker@canonical.com
<_mup_> Added test to verify queued hooks are purged after error
<niemeyer> jimbaker: What was it about?
<jimbaker> niemeyer, per the above bug, there may be queued hooks (say -changed after a -joined) that are waiting to run. but what if -joined exits with an error? the workflow (and its underlying state machine) at this point is in an error and it cannot run any such hooks
<niemeyer> jimbaker: Hmm, right.. but isn't that expected?
<jimbaker> niemeyer, sure. hence the bug
<niemeyer> jimbaker: Sorry, I mean.. isn't the fact that it stops event processing expected?
<niemeyer> jimbaker: What's the bug?
 * niemeyer reads
<jimbaker> niemeyer, the state machine freezes
<jimbaker> and the unit is consequently dead
<niemeyer> jimbaker: Ah, ok.. the problem isn't that it stops processing events, but that it stops processing *EVERYTHING* ;-)
<jimbaker> niemeyer, correct
<_mup_> juju/purge-queued-hooks r455 committed by jim.baker@canonical.com
<_mup_> Ensure accompanying -changed hook does not execute if -joined fails
<jorge> could anyone help me with a juju test to deploy hadoop-master charm? the detailed scenario is pasted here http://pastebin.com/CrBab8RY ... Thanks! :)
<m_3> jorge: hi, I'll give it a try on my end... it looks like it can't see the ppa
<jcastro> http://askubuntu.com/questions/102698/juju-wont-run-on-orchestra-due-to-ssh-error
<jcastro> new question if someone has time to check it out
<jorge> m_3: hum... but, when I run the same install script manually, from the same instance, it works. the instance has the proxy env variables set up (http_proxy no_proxy ....). so, i would like to understand how juju run the script. maybe this is the problem.
<m_3> jorge: yeah, I just got it to 'started' state
<m_3> and the tests have been passing for hadoop-master
<m_3> try it again if you would... destroy-service, then terminate-machine, then deploy it again
<m_3> trying to determine if it was just spurious dns fail or something else
<jorge> ok
<jcastro> niemeyer: heya, I'm not clear about something when you do these imports.
<jcastro> do we need to have those 22 bugs fixed before the store can go live?
<jcastro> basically, should I be making an effort to find people willing to help fix those?
<m_3> jcastro: I think it's more a warning that these won't be visible to the charm-store
<jcastro> ok, so they're not like "we need to fix these now or we are doomed"
<m_3> jcastro: I'm watching the official "~charmers" ones closely... the rest shouldn't matter, they're just personal branches
<m_3> afaik
<jcastro> ok, that clears it up for me, thanks
<m_3> I think the boolean may've landed recently... I'll verify, but once it does the remaining `~charmers` branches can be fixed
<jcastro> we have a guy setting up juju with orchestra if someone wants to answer these: http://askubuntu.com/questions/tagged/juju?sort=unanswered&pagesize=50
<SpamapS> niemeyer: will there be somewhere that people can go to see the reason their charm failed to import?
<m_3> SpamapS: good question... rather than waiting for reports thru email
<SpamapS> even email is dicey IMO.. we don't have a contact field yet
<hazmat> SpamapS, we do indirectly
<hazmat> if its from a ppa, the owner is known
<hazmat> and if its in charmers, the responsible group is known
<SpamapS> hazmat: true. I think I'm just anti-email because I have 400 unread
<niemeyer> SpamapS: Yo
<niemeyer> SpamapS: Sorry, was off for a while
<niemeyer> SpamapS: Absolutely.. the only reason I've been sending those reports to the list is because I've been working on the importer and the store itself
<niemeyer> SpamapS: Tailoring restrictions and fixing bugs as I go
<niemeyer> SpamapS: So it feels like a good idea to share the whole-repo intermediate results so that the repository may be improved while we don't have the final thing
<niemeyer> SpamapS: In the future, juju publish will give immediate feedback
<m_3> jcastro: post sounds good.. ship it
<jcastro> <3 thanks
<m_3> I think it's asking for help in exactly the right way... getting peeps to think about what sort of customizations they might already do
<jcastro> right
<m_3> ... and sharing them
<jcastro> so if like everyone is saying "everyone knows you use nginx with wordpress"
<jcastro> then we should ship that!
<m_3> right
<jcastro> of course people will argue about the nitnoid details, but even if you follow most of the things people agree on it's still better than what we have now
<m_3> and other choices that people like can just be config options
<jcastro> right!
<m_3> or fork
<jcastro> I should flesh out that detail better.
<m_3> that's another post :)
#juju 2012-02-10
<koolhead17> hi all
<gary_poster> SpamapS, hazmat, hi.  we are planning to be ready for a charm review next week, Tues or Wed, so we'll try to find someone willing to work with us then.  We also plan to take time to assemble thoughtful feedback about what we've experienced with juju so far.  Our thoughts are that we ought to write that out among ourselves before the review, because we think it would be good to have a "before we've heard a lot of explanations
<gary_poster>  of what we did wrong or misunderstood" perspective.  Then we'd send that to the juju@ list or something.  However, the only reason to do that is to try to be helpful to you all.  So, should we do something like that?  Any suggestions??
<hazmat> gary_poster, that sounds very useful and should help us improve how to give new users a good experience and things that need to worked on. i'm hoping some of it is just better documentation, in which case i'd invite you guys to help contribute to make it better its at lp:juju/docs
<hazmat> use case, or review, problems encountered, feedback is good
<gary_poster> hazmat, us helping with docs: definitely willing to do that, if we all settle on that being a valuable action item for a given item
<gary_poster> cool thanks hazmat, we'll proceed with plans.
<koolhead17> hi all
<jcastro> SpamapS: m_3_ can we have a G+later to catch up on charms?
<jcastro> I have questions and ideas!
<koolhead17> okey guys am done with my juju presentation today and there goes the slides http://www.slideshare.net/koolhead17/juju-11516934
<m_3_> jcastro: sure man
<SpamapS> now is good for me
<SpamapS> jcastro: ^^
<jcastro> ok
<jcastro> starting up G+
<m_3_> yeah, I guess now's a good time
<jcastro> m_3_: SpamapS invite sent
<jcastro> can someone review my docs mp: https://code.launchpad.net/~juju/juju/docs/+merge/90757
<jcastro> hazmat!
<jdstrand> hey, is it possible to specify the mirror I want to use to debootstrap with juju?
<jcastro> hazmat: if you make a "juju-reviewers" subteam in charge of lp:juju/docs I'd be more than happy to rock that for you.
<jcastro> and then I can fix the docs.
<jdstrand> SpamapS: is it possible to specify the mirror I want to use to debootstrap with juju?
<SpamapS> jdstrand: it uses apt-cacher-ng I think
<SpamapS> jdstrand: so maybe you can tell apt-cacher-ng to use your preferred mirror?
<jdstrand> ok, thanks
<jdstrand> apt-cacher-ng did seem to get pulled in
<SpamapS> hmm maybe not
<jdstrand> backends_ubuntu.default
<SpamapS> jdstrand: the debootstrap part only happens once per release of Ubuntu per week..
<jdstrand> that has http://archive.ubuntu.com/ubuntu/
<SpamapS> jdstrand: so /var/cache/lxc/{oneiric,precise,etc}
<SpamapS> jdstrand: its possible that just setting 'MIRROR' before calling 'juju bootstrap' will actually work
<jdstrand> interesting
<SpamapS> jdstrand: but there's so much indirection between calling 'juju bootstrap' and calling 'debootstrap' .. no guarantees ;)
<jdstrand> ok, I'll fiddle with it
<SpamapS>     debootstrap --verbose --components=main,universe --arch=$arch --include=$packages $release $cache/partial-$arch $MIRROR
<SpamapS> Thats where its called.. as part of /usr/lib/lxc/templates/lxc-ubuntu
<jdstrand> ah
<SpamapS> no.. its called via sudo .. so probably will be sanitized out
<SpamapS> bummer
<SpamapS> oh .. hmm. maybe not
<jdstrand> sudo dpkg-reconfigure -pmedium apt-cacher-ng might be all I need
<jdstrand> if it indeed will use it
<jdstrand> SpamapS: I'm sorry. I feel like I am doing something wrong. I can't seem to get my juju/lxc out of state 'pending'
<jdstrand> SpamapS: is there some juju/lxc docs I can be pointed at?
<jdstrand> SpamapS: I don't mean to be a bother-- pointing me a docs or someone else to pester is fine
<m_3_> jdstrand: it takes a long time for the first service to come up... it's installing an image in /var/cache/lxc
<jdstrand> m_3_: how long is 'long'? how can I monitor its progress?
<m_3_> if it's longer than 30mins, then there's a problem
<m_3_> juju status, /var/log/juju/, lxc-ls, and `ls /var/lib/lxc`
<m_3_> have you had it working before?
<m_3_> or is this a virgin install?
<jdstrand> no. first time is today
<m_3_> ok, so things to check out... `groups | grep libvirt` shows something
<m_3_> you;'ve rebooted since installing libvirt (juju lxc container)
<jdstrand> well, I am not new to libvirt
<m_3_> `virsh net-list --all` shows something
<jdstrand> I did instalI did get through bootstrap ok
<m_3_> that's another potential problem... :) ... do you have existing libvirt nets defined?
<m_3_> ok, then we're probably just waiting for the initial lxc image to be cached
<jdstrand> this is in a precise vm. I redefined the libvirt default network to use 192.168.123 like I normally do when testing libvirt
<jdstrand> I am in the libvirtd group
<hazmat> jdstrand, you can verify if the containers are running with lxc-ls if its listed twice its running
<hazmat> jdstrand, can you pastebin the contents of $data-dir/units/master-customize.log
<jdstrand> that bit I was not sure about (I am new to lxc)
<jdstrand> is lxc-ls supposed to require sudo access?
<hazmat> no
<jdstrand> $ lxc-ls
<jdstrand> jamie-local-0-template	jamie-local-nagios-0  jamie-local-wordpress-1
<jdstrand> /usr/bin/lxc-ls: line 35: cd: /sys/fs/cgroup/cpuset///lxc: Permission denied
<jdstrand> ls: cannot access jamie-local-wordpress-1: No such file or directory
<jdstrand> ls: cannot access jamie-local-nagios-0: No such file or directory
<hazmat> odd
<jdstrand> so I think I may be missing another group
<jdstrand> this vm doesn't have an admin group
<jdstrand> (only 'sudo')
 * jdstrand looks at lxc-ls
<hazmat> jdstrand, that $data-dir/master-customize.log might have some useful debug information, $data-dir from environments.yaml for the local provider
<ejat> hazmat: where to define for exposing the ports/services ?
<m_3_> jdstrand: right, not /var/log/juju, but $data_dir/**/*.log
<jdstrand> I don't seem to have a master-customize.log
<jdstrand> ./jamie-local/units/wordpress-1/unit.log
<jdstrand> ./jamie-local/units/wordpress-1/container.log
<hazmat> jdstrand, it would be in jamie-local/units/master-customize.log
<hazmat> ejat, invoke open-port /close-port in your hooks
<jdstrand> hazmat: yeah, that file doesn't exist. sudo find . -name master-customize.log returns nothing
<hazmat> jdstrand, strange indeed.. the container.log and unit.log might have useful info.. if the links there are active, then at least things are starting up
<ejat> at any file ?
<hazmat> ejat, from within any hook
<_mup_> Bug #930404 was filed: timestamps in status <juju:New> < https://launchpad.net/bugs/930404 >
<jdstrand> units/wordpress-1/container.log claims the container is running
<jdstrand> I'm going to blow away the vm and try again
<jdstrand> and make sure the vm is up to date precise
<ejat> hazmat: wondering why juju asking my key passphrase ?
<hazmat> ejat, it stuffed the public portion of the key onto the containers, if your connecting to a container via ssh, and the key has a password, ssh will prompt for it
<hazmat> s/it/its
<ejat> im just checking juju status
<ejat> previous its not given me any prompt
<hazmat> ejat, it shouldn't do that with local provider
<ejat> ec2
<hazmat> ah
<hazmat> sorry mixing the streams
<hazmat> ejat, yeah.. the ssh connection is nesc to allow the client to communicate with juju's db (zookeeper)
<hazmat> ejat, you can specify a key without password via environments.yaml or use an ssh agent if you want a password protected key
<ejat> noted .. me trying to destroy environment 1st then trying to redo .. btw .. i already put open-port 80/tcp in my file but its not exposing the service
<hazmat> ejat, you also have to do juju expose <service-name>
<ejat> already did .. but .. let me rerun the test so i can post the status
<hazmat> ejat, which hook are you doing the open-port in?
<ejat> since i referring to wordpress hook
<ejat> so its in the db-relation-changed
<ejat> hazmat: brb
<jdstrand> ok, so it seems juju is changing the perms on /sys/fs/cgroup/cpuset///lxc
<jdstrand> I started a new vm, made sure it was up to date, did the bootstrap and everything was ok
<jdstrand> I then di juju deploy --repository=/usr/share/doc/juju/examples local:oneiric/wordpress
<jdstrand> I immediately did 'lxc-ls' and it worked without error and returned jamie-local-0-template
<jdstrand> later I ran it to see how my machine was coming up and I got:
<jdstrand> $ lxc-ls
<jdstrand> jamie-local-0-template	jamie-local-wordpress-0
<jdstrand> /usr/bin/lxc-ls: line 35: cd: /sys/fs/cgroup/cpuset///lxc: Permission denied
<jdstrand> (notice jamie-local-wordpress-0 is there now)
<jdstrand> the permissions on /sys/fs/cgroup/cpuset///lxc are 700 now
<jdstrand> this is with up to date precise
<jdstrand> I have a master-customize.log now
<jdstrand> juju status tells me that wordpress/0 is still pending
<jdstrand> and I see the problem:
<jdstrand> Err http://archive.ubuntu.com/ubuntu/ oneiric-updates/main libfreetype6 amd64 2.4.4-2ubuntu1.1
<jdstrand>   Could not connect to 192.168.122.1:3142 (192.168.122.1). - connect (111: Connection refused)
<jdstrand> that should be 192.168.123.1 in my configuration
 * jdstrand wonders where to adjust that
<jdstrand> providers/local/network.py looks promising
<jdstrand> looks like the 122 could be changed...
<jdstrand> ok, if I destory the service lxc-ls works again
<jdstrand> but /sys/fs/cgroup/cpuset///lxc is still 700
<ejat> hazmat: http://paste.ubuntu.com/837113/
<ejat> state : started but open port null
<hazmat> ejat, i'd check the unit log on the symphony unit, and verify the hook output containing open-port
<hazmat> ejat, the relation doesn't exist, so the db-relation-changed hook hasn't been executed
<ejat> owh ..
<ejat> so i need to remove the db-relation ? then where is suggested to put the open-port /
<ejat> for now .. i dont want to make a relation to db yet .. (next step)
 * ejat since im still crawling making the charm
<hazmat> ejat, that's a relation hook, its only going to be called when the relation is established.. if you always want the same port for the unit you can just do it install in start or even install.. alternatively in your current environment.. you can deploy a database and add a relation between it and symphony so the db-relation-changed hook is executed, and the port is opened
<hazmat> port opening is a two step process, the user has to have had exposed the service, and a charm has to have executed a hook that calls open-port
<hazmat> s/charm/service unit
<ejat> so can i put the open-port in install ?
<jdstrand> hazmat: how do I specify that my container and everything should be using the 192.168.123 network that I configured with libvirt?
<jimbaker> ejat, if that makes sense for your charm, sure
<ejat> jimbaker: ok .. thanks . ill try to do that way 1st and see the outcome
<jdstrand> I'm hoping it is something in .juju/environments.yaml
<m_3_> jdstrand: I think virbr0 is hard-coded... didn't think the 122 was though, I thought it picked it up from the default network
<jdstrand> I don't mind the virbr0 bit
<jdstrand> $ virsh net-dumpxml default|grep 192
<jdstrand>   <ip address='192.168.123.1' netmask='255.255.255.0'>
<jdstrand>       <range start='192.168.123.2' end='192.168.123.254' />
<m_3_> is default using virbr0?
<jdstrand> but if I use sudo lxc-netstat --name jamie-local-wordpress-0 -ie I can see it has 192.168.122.185
<jdstrand> oh, virbr0 does have 192.168.123.1
<jdstrand> your right
<jdstrand> (that was eth0 that had 192.168.122.185
<jdstrand> )
<m_3_> so your default's on virbr0, active, and rewritten to use 123?  hmmmmm
<m_3_> dang, that should totally be working
<jdstrand> the host's ip is 192.168.122.185
 * m_3_ vaguely remembers something about lxcbr0 in precise
<jdstrand> lxcbr0 is there and has 10.0.3.1
<jdstrand> hmm, so maybe it is something else
<m_3_> but I tdon't think anything's listening
<m_3_> dnsmasq is up for 123
<jdstrand> yes
<jdstrand> libvirt's dnsmasq is 123
<m_3_> grrrr
<jdstrand> lxc's is 10.0.3
<jdstrand> well, remember, I did reconfigure my default network
<jdstrand> I am running juju in a libvirt vm
<m_3_> lemme spin up a precise vm and playing with rewriting default
<jdstrand> so my 'host' in this case is a vm that is trying to spin up lxc guests
<m_3_> right... we do this all the time, but in ec2
<jdstrand> ok
<m_3_> so the 122's free :)
<jdstrand> I was trying to save the company some mony and use lxc :)
<jdstrand> m_3_: fyi, I am using the steps I outlined in bug 930430 (which hallyn asked me to file)
<_mup_> Bug #930430: lxc-ls requires root access after deploying an LXC instance <juju (Ubuntu):New> <lxc (Ubuntu):New> < https://launchpad.net/bugs/930430 >
<m_3_> `find /usr/share/pyshared/juju -name "*.py" | xargs grep 122` => <sad_face>
<m_3_> jdstrand: ok, thanks for the ref
<jdstrand> m_3_: bummer. I was hoping I could do something like:
<jdstrand> environments:
<jdstrand>   local:
<jdstrand>     type: local
<jdstrand>     ...
<jdstrand>     subnet: 123
<jdstrand> or something
<jdstrand> (in the yaml)
<m_3_> I filed a bug for juju to create and use its own libvirt network... so it wouldn't conflict with existing ones
<jdstrand> I thought I saw '131' floating around in there
<m_3_> but I like the idea of it being an environments.yaml setting better
<hazmat> jdstrand, juju will use the 'default' libvirt network
<m_3_> really 'subnet' should be probably the virsh network name?
<m_3_> hazmat: but he's changed 'default' to 123
<hazmat> m_3_, shouldn't matter
<hazmat> m_3_, we query the attributes/netinfo out, and just define the default if it doesn't exist
<m_3_> right... his default sounds like it's up and working correctly... we're not picking it up tho... it's catching onto a 122 net first as I understand
<jdstrand> let me get apt-cacher-ng out of the equation (it was recommended to be installed)
<hazmat> m_3_, hm.. yeah
<jdstrand> ok, so the image did pick up a 192.168.123 address
<jdstrand> 192.168.123.67
<jdstrand> (seen in syslog)
<hazmat> jdstrand, can you ssh into it?
<jdstrand> I tried and a get a prompt
<hazmat> i'm curious if its resolv.conf is wrong
<jdstrand> so that is good, but I am not automatically logged in
<jdstrand> is there a password I should use?
<hazmat> jdstrand, it should have setup key auth
 * jdstrand wonders why each step forward was pain...
<jdstrand> that is what I thought
<jdstrand> I specifically did 'ssh-keygen -t rsa -b 2048'
<hazmat> jdstrand, do you have a master-customize.log in your $data-dir/units directory?
<jdstrand> hmm
<hazmat> this time
<jdstrand> .ssh directory has wrong perms
<jdstrand> fixed perms, ssh -i ./.ssh/id_rsa 192.168.123.67, still password
<hazmat> m_3_,  jdstrand, it is  hardcoded to 192.168.122.1 for the nameserver config, thats a bug
<m_3_> jdstrand: use ubuntu@192...
<jdstrand> durr
<jdstrand> m_3_: thanks!
<m_3_> hazmat: good catch
<jdstrand> I made it in :)
<hazmat> same for the apt-rpoxy
<jdstrand> actually, the resolv.conf picked up nameserver 192.168.123.1
<m_3_> local provider can get that from SSH_CLIENT maybe?
<jdstrand> ok, so the machine is up. state is still pending and even though I exposed the service, public-address is null and no open-ports
<jdstrand> (this is just workpress with no relations)
<jdstrand> wordpress
<jdstrand> juju ssh wordpress/1
<jdstrand> 2012-02-10 16:27:55,163 INFO Waiting for unit to come up.
<hazmat> m_3_, i wonder if its because we're installing getting nested libvirt installations because of the recommends
<jdstrand> I can ping www.ubuntu.com from the guest
<hazmat> jdstrand, cool
<m_3_> hmmm
<jdstrand> but the 'juju' commands don't seem to be working. maybe I haven't it right
<m_3_> we definitely need to do the no-install-recommends and at least take that moving part away
 * jdstrand tries to read up on that
<m_3_> jdstrand: `ip addr show | grep virbr` on the instance
<jdstrand> m_3_: in the lxc guest? nothing
<m_3_> ok, thanks
<jdstrand> on the kvm host running the lxc guest, I can give you that (it is 192.168.123)
<m_3_> jdstrand: right... just checking that we weren't installing another layer of libvirt on each instance... we were doing that for a while
<jdstrand> oh
<jdstrand> no libvirt in the lxc instance
<m_3_> ec2 got... um... sluggish in the last few minutes
<m_3_> netflix spinning up on the east-coast
<m_3_> and hulu.. and <insert fav stream svc>
<ejat> jimbaker: i try my install script in local machine manually on precise is working fine
<ejat> but when i try on oneiric
<ejat> something happen that require updating the instances then its work
<ejat> how ?
<ejat> need to put the update & upgrade into the install ?
<ejat> hazmat & jimbaker : is it ok if my charm to have this result : http://ec2-175-41-185-95.ap-southeast-1.compute.amazonaws.com/symfony/web/
<ejat> then ill try to work out the db-relation
<ejat> since its a php framework
<_mup_> juju/purge-queued-hooks r456 committed by jim.baker@canonical.com
<_mup_> Added purge queued hooks test
<jimbaker> ejat, i'm not familiar with this charm, but it is exposed :)
<ejat> yeah .. finally ..
 * ejat need to some additional to my install hooks .. since its differ deploying through juju and manual install at the instance
<ejat> to do*
 * ejat wondering ... 
<jimbaker> ejat, in general you probably don't want to open-port until the service is ready. so you shouldn't see an intermediate state like the current page. of course, it's good for debugging right now
<ejat> yups .. agreed ..
<ejat> its more toward file n folder permission
 * ejat hmm ... 
<TheTinyToon> Hi everyone - I've started to test an ubuntu private cloud with some local virtualbox instances. I've created an orchestra server and two nodes. However, upon running "juju status", I get an error connecting to the environment. --verbose shows, that orchestra tries to connect to port 2181 on the (possible?) zookeeper node, but netstat does not show anything behind that port. Any hints?
<TheTinyToon> I've found this IRC log of this channel, where jorge seems to have the same problem: http://irclogs.ubuntu.com/2012/01/26/%23juju.txt
<TheTinyToon> however, destroying the environment did not help me, as did installing the zookeeper-package.
#juju 2012-02-11
<SpamapS> jdstrand: still fighting with juju?
<SpamapS> jdstrand: I had to run out for a bit..
<TheTinyToon> okay, I manually installed zookeeperd and was able to successfully run "juju status", which is now waiting Environment initialization. Could anyone explain, what juju is waiting for here?
<_mup_> juju/purge-queued-hooks r457 committed by jim.baker@canonical.com
<_mup_> Ensure test loops
<SpamapS> TheTinyToon: did you do 'bootstrap' yet?
<SpamapS> TheTinyToon: it will talk to the orchestra/cobbler server and allocate a machine to run zookeeperd, you should not have to install it manually.
<_mup_> juju/symlink-guard r454 committed by kapil.thangavelu@canonical.com
<_mup_> internal symlink support
<jdstrand> SpamapS: yeah-- after some time I was able to get instances to start but not services. I'll poke at it more and if I'm still having trouble next week, I'll ask. thanks
<jdstrand> m_3_, hazmat: thanks to you too :)
<jdstrand> have a good weekend
<TheTinyToon> SpamapS: I did bootstrap on the orchestra server. However, I wasn't able to do anything else (e.g. a "juju status"), because it couldn't connect to port 2181 on the worker node I created.
<TheTinyToon> If I uninstall zookeeperd, destroy the environment and run bootstrap again, "juju --verbose status" still shows connection errors.
<TheTinyToon> 2012-02-11 11:04:06,410 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="node01.fluffy" remote_port="2181" local_port="44172".
<TheTinyToon> 2012-02-11 11:04:06,965:30696(0xb6662b70):ZOO_ERROR@handle_socket_error_msg@1603: Socket [127.0.0.1:44172] zk retcode=-4, errno=112(Host is down): failed while receiving a server response
<TheTinyToon> 2012-02-11 11:04:06,964 ERROR Connection refused
<_mup_> juju/local-respect-series r451 committed by kapil.thangavelu@canonical.com
<_mup_> remove series default values inline, series is required
<grapz> Hi. I've made a small patch for some docs, and pushed it to LP. It says 'Ready for review for mergin into lp:juju'. Do I need to do anything else, or is it in the review queue, and will be processed eventually?
<_mup_> juju/local-respect-series r452 committed by kapil.thangavelu@canonical.com
<_mup_> unit deploy passes series to container
#juju 2012-02-12
<_mup_> juju/purge-queued-hooks r458 committed by jim.baker@canonical.com
<_mup_> Cleanup
<Leseb> Hi everyone
<Leseb> Does someone can take a look at their thread? http://askubuntu.com/questions/102698/juju-wont-run-on-orchestra-due-to-ssh-error/103618#103618
<_mup_> Bug #103618: [Feisty] Firefox Crash amd64 <mt-needretrace> <firefox (Ubuntu):Invalid by mozilla-bugs> < https://launchpad.net/bugs/103618 >
<Leseb> *this
#juju 2014-02-03
<hobbyBobby> this ssh to bootstrap thing is perplexing
<jcverdie> Is there a trick with juju get and set ? I try to "get" the settings from one charm, and a simple set with the same file does not work (says "no settings found for <charm>"
<jcverdie> Hi, what is the best way to modify a charm? Are the charm recipes kept somewhere incache on my pc?
<natefinch> jcverdie: the code for charms is kept in source control on launchpad. The best way to modify a charm is to branch from the main repository for the charm.
<natefinch> jcverdie: if you go to the charm you want to modify on jujucharms.com, there will be a link to the source under the name of the charm on the left, like this one for mongodb: https://jujucharms.com/precise/mongodb-21/
<jcverdiee> thanks, but gerrit charm is not mainstream it comes from cs:~canonical-ci/precise/gerrit-59
<jcverdiee> so i'm confused where to find the sources
<jcverdiee> and where to send patches (I found a couple of misbehaviour)
<facebook> guys, can someone please take a look at this? it's been sitting there for around two months waiting to get reviewed/promoted. https://bugs.launchpad.net/charms/+bug/1125869
<_mup_> Bug #1125869: New charm: postfix <Juju Charms Collection:New for jose> <https://launchpad.net/bugs/1125869>
<jcverdie> if I go to https://bazaar.launchpad.net/%7Ecanonical-ci/charms/precise/gerrit/trunk/files I get unauthorized ? Any help :)
<jcverdie> i asked to join the charmers team, hope to get access :)
<jcverdie> but the canonical-ci page is private :(
<tomixxx> hi, i have tried to deploy multiple juju charms on a single node with the command "juju deploy X -to lxc:0" but sth went wrong as it seems. Please have a look at the output of the "juju status" command: http://pastebin.ubuntu.com/6867420
<tomixxx> so, the "agent-state-info" indicates some error and the charms itself stay in the state "pending"
<tomixxx> is there a way to UNDEPLOY a single charm?=
<tomixxx> what sources in source.list do i need for juju?
<lazyPower> tomixxx: you can destroy a single unit, or the service to "undeploy" the charm
<lazyPower> tomixxx: typically you will want to add ppa:juju/stable - and run off the stable tree of juju for your production environment.
<tomixxx> yeah, i have already found out the command: juju destroy-service mysql for example
<jcverdie> Hi lazyPower, hope you had a wonderful superbowl party yesterday :) I solved & deployed my gerrit...Thanks for your help!
<lazyPower> Hey thats great news jcverdie! glad I was of some service.
<jcverdie> if I go to https://bazaar.launchpad.net/%7Ecanonical-ci/charms/precise/gerrit/trunk/files I get unauthorized access... So I can't file bugs & submit patches to complete  a clean install of this charm
<lazyPower> jcverdie: ah, yeah I am on that list too. It appears that since its only intended to be used by Canonical internally we aren't privvy to the launchpad assets.
<tomixxx> lazyPower: how do i add "ppa:juju/stable"?
<jcverdie> so what's the idea here? I can't even fork it to fix it :( ?
<lazyPower> tomixxx: apt-add-repository ppa:juju/stable
<tomixxx> lazyPower: thx
<lazyPower> jcverdie: email the list, and someone on the team may be able to work something out for you.
<tomixxx> lazyPower: Is there a possibility to clear the log message in agent-state-info when i call "juju status"?
<tomixxx> lazyPower: how can i destroy a lxc container?
<lazyPower> tomixxx: whatare you trying to do? if you're trying to delete a lxc container that juju is managaing you will encounter some issues as the bootstrap node handles all that.
<jcverdie> lazyPower: done:)
<tomixxx> lazyPower: excactly, i want to delete an lxc container because thre creation of the container failed
<tomixxx> lazyPower: http://pastebin.ubuntu.com/6867420
<tomixxx> i could also do "destroy-environment" but it needs a lot of time to reset juju at all
<lazyPower> tomixxx: you can run the lxc-destroy command to remove the containers, but you will encounter an issue with juju thinking the containers are still around in an error state and will desync your local provider from the bootstrap node. at least thats the behavior I have seen when i've remoevd lxc containers without juju's help
<tomixxx> ok, so what could i do instead?
<lazyPower> personally, i would rebootstrap the environment
<lazyPower> destory & rebootstrap
<tomixxx> lazyPower: ok but it seems "apt-add-repository ppa:juju/stable" was not sufficient abecause it failed again to get http:s//cloud-images.ubuntu.com/query/precise/server/released-dl.current.txt"
<tomixxx> ah i guess i have to call sudo apt-get update
<tomixxx> sorry :(
<rkpaul> marcoceppi: hello
<marcoceppi> rkpaul: hello!
<marcoceppi> rkpaul: what happens when you go to https://store.juju.ubuntu.com/charm-info?charms=cs%3A~marcoceppi%2Fprecise%2Fdiscourse in your browser?
<rkpaul> on the host system, I'm getting some json. When I wget it in the VM, I'm getting a cert error
<rkpaul> ERROR: cannot verify store.juju.ubuntu.com's certificate, issued by â/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287â:
<rkpaul>   Issued certificate not yet valid.
<marcoceppi> rkpaul: yeah, it seems you don't have the CA chain on theVM
<marcoceppi> and it's a 13.10 VM?
<rkpaul> yeah
<marcoceppi> rkpaul: can you make sure ca-certificates is installed
<rkpaul> yeah, already installed
<marcoceppi> rkpaul: well this is unfortunate and very odd. I've got 13.10 on my laptop without issue it seems to be missing some root ca in your chain to validate the godaddy cert
<rkpaul> very weird
<rkpaul> I'll try spinning up a new vm with 13.10 and see what happens
<marcoceppi> rkpaul: please, I'm in Europe right now so it's nearing my EOD, but I'll hang around for a bit.
<marcoceppi> rkpaul: the charm is also broken, I can try to patch it, but upstream changed the way production database configuration options are stored
<marcoceppi> so you're already walking in to a bit of a trap ;) It's one of the reasons I've not submitted the charm to the charm store, given how fast upstream is moving
<rkpaul> ok, no worries. I was just messing around with discourse and figured it'd be an interesting way to start looking at juju
<marcoceppi> rkpaul: feel free to give it a whirl anyways, there's an earlier version of discourse that will work with the charm
 * marcoceppi looks it up
<marcoceppi> rkpaul: you can run `juju deploy cs:~marcoceppi/discourse`; then immediately after run `juju set discourse release=v0.9.8.1`
<marcoceppi> which is the version right before the config change
<rkpaul> cool, thanks!
<marcoceppi> rkpaul: cheers, feel free to pop in with any questions about juju!
<rkpaul> very weird, new VM isn't exhibiting the cert issue
<marcoceppi> wonky
<marcoceppi> hopefully you can press forward without any other weirdness
<rkpaul> sorry to have bothered you with it, thanks for helping! :-)
<marcoceppi> rkpaul: np anytime!
#juju 2014-02-04
<jcverdie> Hi all, does anyone know how/if I can deploy a juju framework on a pre-existing amazon instance? I have reserved instances which I'd like to use for this
<jcverdie> e.g. instead of adding machines which are created by juju, using my own machines...
<axw__> jcverdie: yes, using manual provisioning. it works well in the latest dev release, it's a bit flakey in the stable release
<axw__> jcverdie: I have to run, but the docs are here: https://juju.ubuntu.com/docs/config-manual.html
<axw__> (a little out of date, but mostly still true)
<jcverdie> thanks Im gonna look
<tomixxx> hi, when i try to assign multiple charms to the same machine, i get an error in agent-state-info. it seems that the machine cannot download some things from http://cloud-images.ubuntu.com. Please have a look on the output of the terminal when i call "juju status": http://pastebin.ubuntu.com/6873041/ As u can see in the output, i have tried it now several times but every time the lxc container failed to create
<tomixxx> can i install "juju" if i have installed "juju-core"?
<lazyPower> tomixxx: juju is a metapackage, It won't harm anything.
<tomixxx> lazyPower: i still have the problem that i cannot assign multiple charms to the same machine
<lazyPower> do you have the juju-local package installed?
<tomixxx> lazyPower: no i have not installed this package
<lazyPower> tomixxx: you will need to destroy your environment, install the juju-local package, then rebootstrap your local environment
<lazyPower> tomixxx: https://juju.ubuntu.com/docs/config-LXC.html
<tomixxx> lazyPower: ok i will do this
<lazyPower> Best of luck. Ping me if you get stuck
<tomixxx> ty
<tomixxx> lazyPower: i have followed your guide and then i have called "juju deploy mysql --to lxc:0" again but i got the same error
<lazyPower> tomixxx:  shoot me a pastebin of your juju-status output again please
<tomixxx> lazyPower: http://pastebin.ubuntu.com/6873459/
<jcverdie> Hi I'd like to deploy to a EC2 instance which I already have, but as it's a regular EC2 i have to use PEM to connect to it, and I can't find how to do it with juju ?
<lazyPower> tomixxx: does the machine you're bootstrapping juju on have internet connectivity?
<tomixxx> lazyPower: no
<lazyPower> jcverdie: what you're attempting to do is manual provisioning
<lazyPower> jcverdie: thats still very much in beta phases at this point
<jcverdie> lazyPower: I did it (juju switch null)
<jcverdie> but juju bootstrap fails : ERROR failed to enable bootstrap storage: failed to create storage dir: exit status 255 (Permission denied (publickey).)
<lazyPower> tomixxx: you will need to get that machine to have connectivity before creating the containers will work. Its dependent on the cloud-tools to bootstrap the node.
<jcverdie> because when i ssh it i have to do ssh -i mykey.pem
<tomixxx> lazyPower: My architecture is as follow: my maas-server is connected to two nodes via switch. the maas-server has to network interfaces: one interface is connected to the switch and the other interface connects me to the internet
<lazyPower> jcverdie: ok, so its an ssh auth error. Can you add your sshkey to the authorized_keys on the host?
<jcverdie> and I don't know how to tell juju to do it
<jcverdie> i'll try
<lazyPower> tomixxx: The only resolution here is to get internet connectivity to the host that is bootstrapping those lxc containers, i'm sorry.
<lazyPower> jcverdie: ssh-copy-id -i $PATH_TO_KEY ubuntu@host
<tomixxx> lazyPower: lazyPower: ok
<jcverdie> lazyPower: i have the public .pem and my own public rsa in the authorized keys on the server
<lazyPower> Ok that should be good. When you ssh to that host, you no longer have to specify the key, correct?
<jcverdie> lazyPower: right, but juju bootstrap still fails :(
<lazyPower> jcverdie: still on object storage?
<jcverdie> yep, exactly the same error
<lazyPower> hmm.. is juju using a different keypair than what you have provided to the host?
<jcverdie> no, i've put my 3 keys on the server
<jcverdie> could it be somethign wrong in my environments.yaml ?
<lazyPower> well, one second
<lazyPower> is juju trying to use your personal user and not ubuntu? there's a config flag for the user
<lazyPower>     # bootstrap-user:
<jcverdie> i've set bootstrap-host, bootstrap-user
<lazyPower> I'm not sure then :| that should have been a green light to juju
<jcverdie> and there's a storage-auth-key which I haven't set but it's there
<lazyPower> yeah, you should be fine without that. I haven't used the configuration field in my trial tests of the manual provider
<jcverdie> :(
<lazyPower> jcverdie: i'll keep brain bending on this, but i'm not sure why that's not working. can you pastebin me all the non-sensitive stuff relating to the null provider from your environments.yaml?
<jcverdie> sure
<jcverdie> did you get it ?
<lazyPower> tomixxx: another thing, make sure your lxc bridge device is pointed at the proper ethernet port to get internet connectivity too. The bootstrap process will be downloading bits from the itnernet as well.
<lazyPower> i did
<jcverdie> brb
<tomixxx> lazyPower: how do i check this?
<lazyPower> tomixxx: lxcbr0 (the default bridge device created by juju) is by default attached to eth0 ( i'm pretty sure ) and if you need to change that
<lazyPower> the configuration of the bridge interface is found in /etc/lxc/default.conf - but it doesn't look like it has the bridged interface there...
<tomixxx> lazyPower: ok, in my case, eth0 has no internet, but eth1 has
<lazyPower> tomixxx: ah its in /etc/default/lxc
<lazyPower> you can configure the LXC virtual bridge device / vnet in that file. it will require a restart to take hold however. I don't believe that sudo service networking restart will affect the LXC bridge device.
<tomixxx> lazyPower: hmm, LXC_ADDR="10.0.3.1"
<lazyPower> if you don't want to reach the containers that LXC is spinning up on your network thats fine. Juju's local provider occupies that ip range by default
<lazyPower> if do you DO however want to reach your LXC containers, you will need to do some configuration magic
<tomixxx> lazyPower: i have to use lxc-containers because i have only 2 nodes
<lazyPower> tomixxx: I understand. I have an intranet deployed in my house using juju and lxc containers.
<lazyPower> it works really well, but I don't know that its something I would want to use in production. It does get a bit wonky here and there.
<tomixxx> lazyPower: do i need to change my "interfaces" file in order to enable the cloud-nodes to access the internet?
<lazyPower> I don't believe so
<tomixxx> lazyPower: Ok, so there is no need to configure a "bridge" or sth like that?
<lazyPower> thats what i pointed you at, the LXC bridge configuration
<tomixxx> lazyPower: k, but what do i have to change there?
<lazyPower> tomixxx: not knowing how your network is configured, or the host machine, thats difficult to say.
<tomixxx> lazyPower: my network is configured as follow: http://pastebin.ubuntu.com/6873735/
<tomixxx> lazyPower: eth1 connects me to the internet and eth0 connects me to the cloud-nodes
<lazyPower> tomixxx: there's a discussion on this in the forums, read through this - http://ubuntuforums.org/showthread.php?t=2137446
<tomixxx> lazyPower k, ty
<tomixxx3> i have tried to NAT the traffic from the LXC bridge to the internet-capable network interface eth1: http://pastebin.ubuntu.com/6874102
<tomixxx3> the problem is it does not work
<tomixxx3> i get the same error when i call "juju status" -> "failed to get https://cloud-images.ubunt.com/..."
<tomixxx3> lazyPower: do i have to rebootstrap juju if i have changed lxc bridge settings?=
<marcoceppi_> tomixxx3: possibly
<tomixxx3> marcoceppi: i have only modified the "interfaces" file, in detail. i added some port-forwarding lines
<tomixxx3> marcoceppi: i have already restarted the maas-server but it seems still not work because i cannot create lxc containers
<marcoceppi_> tomixxx3: didn't realize you were driving lxc with maas
<tomixxx3> marcoceppi: i have deployed juju on top of maas because i want to use openstack
<tomixxx3> marcoceppi: in order to deploy juju charms, i need to have multiple charms on a single machine
<tomixxx3> marcoceppi: and therefore, i need lxc containers
<marcoceppi_> tomixxx3: right, but are the LXC containers in maas, or are you using juju deploy --to lxc:# ?
<tomixxx3> i use "juju deploy XXX --to lxc:x"
<marcoceppi_> tomixxx3: you won't need to re-bootstrap
<marcoceppi_> but I'm not sure if anything else is required
<tomixxx3> k, the problem is, when i try to deploy sth i call "juju status" after it and then i can see that the creation of the lxc container failed because the container was not able to download sth
<marcoceppi_> right, so some networking issue
<marcoceppi_> what version of juju are you using?
<tomixxx3> if its "agent-version" it is 1.16.5.1
<tomixxx3> marcoceppi: the output of "juju status" looks like the following: http://pastebin.ubuntu.com/6874176
<marcoceppi_> tomixxx3: yeah, I think lxc bridge stuff was patched in 1.17.2, but the person who would know that is not online right now
<tomixxx3> marcoceppi: as u can see, i have tried it multiple times
<tomixxx3> marcoceppi: 0/lxc/4 was last try ;)
<tomixxx3> maroceppi: so, do you mean it make sense to go to version 1.17.2?
<tomixxx3> marcoceppi: i mean latest, not last
<marcoceppi_> tomixxx3: for LXC stuff, yes
<marcoceppi_> it's something thats actively beinig worked on in juju at the moment
<tomixxx3> marcoceppi: i fear that the main problem is that i have made some mistake when configuriering or installing sth
<cjohnston> Is there a way to get juju to automatically clean up the security group spam it creates?
<marcoceppi_> cjohnston: no, but there is a tool you can compile with go to do it
<marcoceppi_> cjohnston: though it's a bit...over zealous
#juju 2014-02-05
<mhall119> marcoceppi_: http://tannerfilip.me/the-status-of-discourse/
<marcoceppi_> mhall119: thanks for the info, looks like he has more of an issue with juju than the charm directly
<marcoceppi_> their loss
<kenn> Hey all. I'm using juju to deploy my stuff, but would like to add regular backups of my database. I have a script to do it, but I need to shut down the main application while the backup is running. Without adding that code to the database charm, what would be the best way of going about doing that?
<kenn> Both charms are running on the same box
<lazyPower> kenn: you could write a subordinate charm to handle that task. Or write a non-subordinate charm, and deploy it to the same machine using relationships to bind the db details so its portable.
<tomixxx3> hi, how can i configure juju so that it uses MAAS as a http proxy?
<dannf> help w/ the manual provider? bootstrap is giving me an ssh-looking error, though i can ssh just fine
<dannf> http://paste.ubuntu.com/6879654/
<dannf> not clear from the logs what is ssh'ing to where
<lazyPower> dannf: have you provisioned with the manual provider before?
<dannf> nah
<dannf> i worked around it by adding my ssh key to the authorized_key of the ubuntu user that bootstrap created
<dannf> now its installing packges
<dannf> lazyPower: hm.. next issue. cp: cannot stat ï¿½ï¿½ï¿½/var/lib/juju/storage/tools/releases/juju-1.17.0-trusty-amd64.tgzï¿½ï¿½ï¿½: No such file or directory
<tomixxx3> lazyPower: do u know how can i set the maas-server as a http-proxy for the juju-bootstrap node?
<dannf> (from cloud-init-output.log on bootstrap node)
<lazyPower> tomixxx3: I do not sorry
<tomixxx3> lazyPower: k, np
<lazyPower> dannf: try bootstrapping with --upload-tools?
<dannf> trying
<dannf> lazyPower: bingo
<dannf> ERROR error detecting hardware characteristics: unrecognised architecture: aarch64
<dannf> well, wanted to see how far i could get - i guess that's it :)
<lazyPower> dannf: yeah Manual provider is still a WIP
<dannf> lazyPower: so is aarch64
<lazyPower> its coming along though, lots of new improvements
<niedbalski> hey guys , is this https://travis-ci.org/juju/juju-core the official CI?
<nicholaswyoung> Does anyone have experience using Juju with Vagrant for local development
<nicholaswyoung> ?
<lazyPower> nicholaswyoung: i've used it on my mac, what would you like to know specifically?
<nicholaswyoung> lazyPower: That's exactly what I'll be doing. I'm looking to bootstrap a VM with Vagrant, then create a development environment with MongoDB, Ruby, etc on that VM using Juju - much like I would traditionally use Chef or Puppet.
<nicholaswyoung> Is this something Juju is capable of? From reading the docs, I assume so - but I want to make sure I'm using the tool correctly.
<lazyPower> it is, but juju sits a layer above what you're doing. Juju is more about service orchestration - however it does provide you with raw hooks so you can in turn write your own configuration management in say, bash, salt, puppet, chef, ansible, compiled binaries, etc.
<lazyPower> however there is nothing wrong with using juju as your configuration manager if you so choose to do that.
<nicholaswyoung> Gotcha. So for this use case, I'm better off using the traditional configuration management tools. Or at least that's what it sounds like.
<nicholaswyoung> I think I initially saw Juju as a more-powerful successor to those tools -- none of which I like very much.
<lazyPower> again, theres nothing stopping you from charming your development environment
<sarnold> juju might be a better fit if you were starting several VMs, one or more per service
<lazyPower> ^
<lazyPower> beat me to it sarnold
<nicholaswyoung> I will be deploying to Ubuntu in the next week or so, and if writing Charms (or downloading them now) will save time then, awesome.
<nicholaswyoung> Would it be reasonable to write charms (or download them), provision via Vagrant, use the charms -- then somehow wire that up to the cloud provider of choice?
<lazyPower> nicholaswyoung: yep! that's the idea behind the vagrant box, is to provide a test bed for developers not running ubuntu full time.
<nicholaswyoung> I mean, eventually the DB, Rails stack, etc will all have their own VM.
<roadmr> I'm having trouble with the openstack-dashboard charm (the version of django from cloud-tools doesn't work with this version of horizon), anybody had success with this?
<nicholaswyoung> lazyPower: That makes sense. Could I (or should I) just drop Vagrant and use Juju to build virtual dev environments?
<nicholaswyoung> lazyPower: The less complexity and "magic" in my rig, the better.
<sarnold> nicholaswyoung: yes, that sounds like something juju can help with -- you could do your tests locally, with vagrant, one vm per service, and then turn around and deploy those services on ec2 or azure or hp
<nicholaswyoung> sarnold: But Vagrant is still valuable, correct? Because I'm not attached to it specifically either. If I could use straight-up Juju, so far, it seems to fit my style better. But if I still need Vagrant to provision, so be it.
<nicholaswyoung> lazyPower: I finally understood what you meant by 'full-time'. In other words, those running Ubuntu as the primary, host OS. Your answer makes much more sense in that context. I apologize for being slow.
<lazyPower> nicholaswyoung: I could have been a bit more specific. Since i run juju as my host os, i have the afforded opportunity of using LXC containers which are great for development of charms
<sarnold> nicholaswyoung: juju just asks a "cloud provider" to provision machines; in your case, that would be vagrant during development, and aws or whatever during deployment
<nicholaswyoung> sarnold: Understood. Then, once a box is provisioned, Juju configures the defined services.
<sarnold> nicholaswyoung: right
<nicholaswyoung> sarnold: I finally have a clear picture of what Juju is, and how it will help. Thank you!
<nicholaswyoung> lazyPower: and thanks to you too. This is by far the most valuable IRC visit I've ever had.
<sarnold> nicholaswyoung: cool! have fun :)
<nicholaswyoung> sarnold: I'm certainly going to try!.
 * lazyPower hat tips
<sarnold> lazyPower: well done :) good tag-team
 * lazyPower hi5's
 * sarnold ^5
<lazyPower> very nice, great success (devops borat)
<sarnold> haha
<timrc> Is there a way to deploy a charm with multiple config yamls?  Specifically I'd like to deploy a charm with all the default config options but override two of them at deploy time rather than after
<marcoceppi_> timrc: yes
<timrc> marcoceppi_, using --config with deploy doesn't seem to be working in my case :(
<marcoceppi_> timrc: it needs a specific format
<marcoceppi_> timrc: https://juju.ubuntu.com/docs/charms-config.html#config-deployment
<timrc> marcoceppi_, Thanks for the help
#juju 2014-02-06
<timrc> Wow one super annoying side effect of putting every hook into one file and then symlinking is if there is an error... you potentially have to "resolve" a lot of failed states if you're not careful where you put things
<bradm> anyone about who knows about the swift-storage charms?
<JoshStrobl> Hey guys, I have a question regarding Juju charm development. I am currently developing a charm that pulls down my open source database system, which is PHP-based and only requires an HTTP server like nginx / apache. Is it correct that I'd only need to define a single "requires" of website: interface: http (which is set to optional since it merely puts the database in the root of the http server, such as /var/www/). Would it be
<JoshStrobl> correct that the relation hooks should be website-relation-*, even if they are optional.
<stefano-palazzo> Hi guys! The wiki links on this page are down: http://www.ubuntu.com/download/cloud/install-ubuntu-cloud (under "real-world deployment")
<jcastro> stefano-palazzo, heya, if you can file a bug on lp:ubuntu-website I'll make sure someone sees it
<stefano-palazzo> will do
<stefano-palazzo> https://bugs.launchpad.net/ubuntu-website/+bug/1276996
<_mup_> Bug #1276996: Dead links to wiki pages on OpenStack into page <maas> <openstack> <Ubuntu Website:New> <https://launchpad.net/bugs/1276996>
<stefano-palazzo> looks like a couple of them went bad when maas.ubuntu.com was set up. no big deal, the information's still there
<stub> juju-test.conductor.01_lint.test DEBUG   : Running 01_lint.test (tests/01_lint.test)
<stub> make: *** [lint] Error 1
<stub> juju-test.conductor.01_lint.test DEBUG   : Got exit code: 2
<stub> juju-test.conductor.01_lint.test RESULT  : â
<stub> oh, foot gun. Its quiet cause I told it to me.
<stefano-palazzo> thanks jorge
<stub> When a local environment is destroyed, ~/.juju/environments/foo.jenv should be removed, yes?
<stub> Hmm... I think juju test is swallowing my stdout if I have stderr
<marcoceppi> stub: it is, there's a bug about jenv not being removed
<marcoceppi> stub: try running juju test with -v flag
<marcoceppi> JoshStrobl: you want to provide an http interface for the website realtion
<stub> marcoceppi: ta, I thought that was the problem but hadn't been  able to engineer a repeatable failure yet.
<marcoceppi> JoshStrobl: the charm should then insall nginx, apapche, whatever it needs to run the php codd
<marcoceppi> timrc: yeah, a better pattern is to put all the methods in a file, then stub them in each hook file
<JoshStrobl> marcoceppi: Yea, figured http interface for website relation. My install script already does proper dependency checking as well :) I'm just wondering if I need to provide the website-relation-* hooks, since the website is considered optional and nothing technically ties into the charm *yet*.
<stub> marcoceppi: Do you know if tests in the tests directory are supposed to run as root, or an unprivileged user? I thought root, but saw one MP with 'sudo apt-get-install' lines, so am unsure.
<JoshStrobl> marcoceppi: The Charm is primarily meant for easier deployment of the system, though I intend in the future of having services that tie into it.
<marcoceppi> stub: the tests will be run by a user with at least sudo access
<stub> ta
<marcoceppi> JoshStrobl: all you reall need is a website-relation-joined hook with one line to make it tie in to other charms
<JoshStrobl> marcoceppi: Thanks for your help. I do appreciate it =)
<marcoceppi> JoshStrobl: here's an example: https://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/view/head:/hooks/website-relation-joined
<JoshStrobl> Yea I've been looking at the website-relation-joined of Wordpress :) Just was doing it via the Juju Charms website.
<marcoceppi> replace port with whichever port you have the webserver running on
<JoshStrobl> marcoceppi: It'll still be port 8080 since the system directly ties into an nginx or apache install, so doesn't really look like I have to change much at all.
<stefano-palazzo> I'm trying to set up a juju box with the null provider. bootstrapping works fine, but add-machine gives me this error:
<stefano-palazzo> ERROR Get http://cloud:8040/provider-state: dial tcp 10.15.124.116:8040: connection refused
<stefano-palazzo> anybody know what that's about?
<cjohnston> When deploying with juju... should I be getting one security group per machine deployed?
<marcoceppi> cjohnston: that sounds about right
<marcoceppi> well, about "right"
<cjohnston> marcoceppi: its killing me :-(
<sarnold> (I'd guess one per service instead, but ti's a guess..)
<cjohnston> either way.. it makes life miserable
<marcoceppi> sarnold: you get one per unit, then one per service
<marcoceppi> cjohnston: one per service group makes "more" sense
<marcoceppi> they're going to be working on fixing that, are you on hp cloud cjohnston?
<cjohnston> marcoceppi: yup
<marcoceppi> cjohnston: just join live help, ask for 100 sec groups
<marcoceppi> and then ask for like 100 machines
<marcoceppi> and they'll just do it (tm)
<marcoceppi> that's how I got around that problem
<cjohnston> ta marcoceppi
<sarnold> marcoceppi: ah, that makes sense
<marcoceppi> sarnold: well, one per service should be sufficent, since you shouldn't have units doing different things
<marcoceppi> it's a bit of overkill to have so many sec groups
<vila_> marcoceppi: related to hp secgroups, https://bugs.launchpad.net/juju/+bug/1027641 , it's said there to use 'firewall-mode: global', will my current 'juju bootstrap' node take that into account or should I destroy/bootstrap again ?
<_mup_> Bug #1027641: assigning a unique security group to each machine uses up security group quotas in HPCloud (openstack) <pyjuju:Triaged> <juju-core:Fix Released by niemeyer> <https://launchpad.net/bugs/1027641>
<marcoceppi> vila_: firewall-mode global does work, but you have to re-bootstrap
<vila_> marcoceppi: thanks !
#juju 2014-02-07
<stokachu> are all methods in apiserver/client.go exposed over a websocket?
<stokachu> is the username in an api request just the "Tag": "machine-#"?
<hazmat> stokachu, yes
<hazmat> username = tag
<Muki_> hi
<marcoceppi> Hello Muki_
<Muki_> machine or human
<hatch> cyborg
<hatch> marcoceppi has bash running through his veins
<Muki_> cyborg. can you give me some advise
<marcoceppi> Muki_: feel free to ask a question and we'll see what we can do
<hatch> :)
<marcoceppi> hatch: I'm bourne again!
<hatch> haha
<hatch> Jason Bourne?
<Muki_> I have some malfunction with my pc
<marcoceppi> Muki_: is it a juju malfunction? Ubuntu malfunction? Other?
<Muki_> other
<Muki_> it is about some services
<Muki_> I need to know services who is responsible to machine chipset function
<Muki_> How controll acpi function
<jose> marcoceppi: hey, not using ubuntu on air for this one?
<marcoceppi> jose: I guess we are?
<marcoceppi> Jorge usually runs it
<marcoceppi> and he's not here
<jose> marcoceppi: I can help you with that
<marcoceppi> jose: okay!
<jose> mind if I PM?
<marcoceppi> jose: nope
<ashipika> Hi all.. How can one join the charm school on Google Hangouts? (1300EST)
<jose> ashipika: you will be able to watch it at ubuntuonair.com
<ashipika> thanks!
<marcoceppi> Charm School starting in a few mins! http://ubuntuonair.com
<ppetraki> any questions from charm school audience?
<urulama> ppetraki: can we make snapshots of charms? suppose we need to kill machine with mongo, can we preserve the data there?
<ppetraki> urulama, good question
<ashipika> i guess that depends on what the stop hook does, doesn't it
<ppetraki> urulama, ashipika, better?
<urulama> thans for the answer guys
<urulama> "thanks"
<ppetraki> you also have access to the service -> machine-id, so if you have the cloud specific tools install you may be able to snapshot the entire machine
 * ppetraki  hasn't tried this
<ashipika> i like the disk snapshot idea.. something that would enable me to quicky re-create my environment should something go VERY wrong
<ppetraki> o/ :)
#juju 2014-02-09
<marcoceppi> jamespage: it seems we actually have a juju unset to revert to default values
<marcoceppi> so I need to propose to the list about allowing None as a valid default type for configuration for charm proofing, but I think it's acceptable now given that unset exists
<jamespage> marcoceppi, excellent
<jamespage> I noticed that the default "" stuff already got into the rabbitmq-server charm
<jamespage> I'm going to revert that
<JoshStrobl> Hey guys, I've been trying to debug my install hook for a while now, changed the set -e to set -x to do line-by-line debugging and aside from the usual running commands not as root (I'm under the impression the charm install hook will run as root to download packages), can't really figure out the issue (juju status states the service agent-state-info: 'hook failed: "install"'. Someone mind taking a look at the script?
<JoshStrobl> http://pastebin.com/MHV91wKQ
<JoshStrobl> charm proof only provides a copyright and maintainer warning, no errors.
<marcoceppi> JoshStrobl: change the install hook to `set -eux` then copy the output of the charm log
<JoshStrobl> will do
<marcoceppi> JoshStrobl: also, line 70 is kind of silly to have, since you call wget around line 15
<marcoceppi> also, apt-get install is safe to invoke multiple times
<marcoceppi> so just having apt-get install <pks> will exit 0 if the packages are installed or not (unless there was an error during installation)
<JoshStrobl> ah yea the wget on line 15 is silly :D
<JoshStrobl> marcoceppi: so it won't do an unnecessary re-install?
<marcoceppi> JoshStrobl: sorrect
<marcoceppi> correct*
<JoshStrobl> alrighty
<JoshStrobl> I'll apply some changes and try again then :)
<marcoceppi> JoshStrobl: http://paste.ubuntu.com/6905382/
<JoshStrobl> ah :D
<JoshStrobl> been a while since I've used Ubuntu myself, to be honest
<JoshStrobl> Sorta sticking with archlinux nowadays until 14.04.
<marcoceppi> :D
<JoshStrobl> Thanks again marcoceppi :)
<JoshStrobl> I'll let you know how things go!
<marcoceppi> np! cutting down the complexity might reveal where the install hook is breaking better
<JoshStrobl> Well, eliminating unnecessarily complexity is always a good thing anyways, makes easier to maintain. Just sorta figured apt-get might do unnecessary package re-installs, hence why I implemented those checks. But w00t, glad it doesn't.
<JoshStrobl> Oh and if you're wondering why I'm using echo rather than juju-log, it's because set -e kept failing on juju-log "anksdnfkas" calls, despite me having juju and juju-core installed (running on a local Juju server)
<JoshStrobl> where are charm logs typically stored?
<marcoceppi> JoshStrobl: /var/log/juju/unit-*.log on the machine
<marcoceppi> JoshStrobl: if you're using local provider, you can find them in ~/.juju/local/log/unit-*
<JoshStrobl> marcoceppi: ah ok, was about to say there wasn't anything in /var/log/juju :D
<marcoceppi> JoshStrobl: there is if you do `juju ssh <unit>` then cd to /var/log/juju :)
<JoshStrobl> I think I've found the issue
#juju 2015-02-02
<halcyon> hello
<halcyon> i am new user to ubuntu juju
<6A4ABBR4J> gnuoy, dosaboy: we should look to make plugin management in rabbitmq-server charm better - the version we have (3.4.3) does not require restarts for enabling/disabling plugins
<6A4ABBR4J> unlike older versions
<jcastro> marcoceppi, do you have a link to the services framework? negronjl_ wants to check it out
<marcoceppi> jcastro: negronjl_ https://pythonhosted.org/charmhelpers/examples/services.html
<negronjl_> marcoceppi, thx
<marcoceppi> negronjl_: it's best viewed in an implemented charm
<jcastro> which charm should I show him?
<jcastro> chamilo?
<marcoceppi> jcastro negronjl_ http://bazaar.launchpad.net/~charmers/charms/precise/chamilo/trunk/files
<marcoceppi> jcastro: yeah, chamilo
<negronjl_> marcoceppi, thx
<drbidwell> If I am going to deploy using juju to a VmWare environment, which mode of juju would I use?  local?
<drbidwell> This would be my first production deployment of juju and I would like a juju server that deploys multiple servers.
<Odd_Bloke> drbidwell: You want to use multiple VMs running in a VMWare environment as Juju machines?
<drbidwell> Odd_Bloke: yes
<Odd_Bloke> drbidwell: I _think_ your best bet is probably the manual provider.
<drbidwell> Odd_Bloke:  Thanks.  I will try that.
<seal> It appears all the rails and nginx-passenger does not work for trusty series, has any one manage to get this to work? or should I just write my own charm?
<ejat> hi ... if i use exported bundle charms for openstack , how do i retrieved the username n password for openstack-dashboard ?
<Guest60551> hello guys i get this error, https://juju.ubuntu.com/docs/authors-hook-debug.html
<Guest60551> sorry the error is " no relation id specified"
<Odd_Bloke> Guest60551: Could you use http://paste.ubuntu.com to paste what you are trying to run and its output?  The output of juju status would also be helpful. :)
<Guest60551> Odd_Bloke: I am getting the following error plz help
<Guest60551> neutron net-list
<Guest60551> Could not find Service or Region in Service Catalog.
<Guest60551> after deploying the quantum gateway charm
<Odd_Bloke> Guest60551: I'm afraid I don't know anything about the OpenStack charms.
<Guest60551> Odd_Bloke: k anyways thanks ...
<Guest60551> guyz..... i am stuck with the quantum-gateway charm , rest of my openstack setup is working well , need help
<Guest60551> also there is no networks tab in openstack dashboard
<blr> Does anyone have any advice for managing multiple charm branches in development? I'm deploying my charm locally with --repository=/home/$USER/src/charms/ local:trusty/app where /src/charms/trusty/app is a symlink to the branch, which seems to work but juju complains that it cannot find metadata.yaml in the _parent_ directory of the symlink which seems odd.
<saltlake> Experts, looking for a way to finish the openstack install using juju. I have 9 VMssetup -1 - maas controller and 8 clients and juju bootstrap is done. However I do not know what is the next step. seems unclear after this:http://maas.ubuntu.com/docs/juju-quick-start.html
<saltlake> anyone: after the bootstrap.. I need some pointer on how to setuip openstack. Any help would be great!!
<saltlake> I find this link "http://askubuntu.com/questions/144531/how-do-i-install-openstack" but can't figure if this will work with VMs
<saltlake> Wow this link appears to not require any maas setup or VMs but does all of it!!
<saltlake> Is that true
<saltlake> ?
<saltlake> hi
<saltlake> champs, really trying to get the last few steps of openstack deplyed .. however after this link it is not clear what needs to be done :http://maas.ubuntu.com/docs/juju-quick-start.html.
<saltlake> Eg which charms are necessary to install and deply as the easiet example.
#juju 2015-02-03
<hazmat> tvansteenburgh, dpb1 could either of you add me back to juju-deployers team
<tvansteenburgh> hazmat, if i can figure out how...
<tvansteenburgh> hazmat, nothing on the lp page that indicates i can do it
<hazmat> tvansteenburgh, no worries, i'll ping robbie looks like the leave script switched ownership to him
<tvansteenburgh> hazmat, ack
<dpb1> hazmat: bah, no.
<dpb1> hazmat: hulk time it is
<skay> I can't run `charm add tests` http://paste.ubuntu.com/10025926/
<skay> it's probably trying to find bzr in the wrong place
<catbus1> Hi, there is recent update on openstack charms, are there any changelogs?
<beisner> catbus1, https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1501
<sebas5384> ping
<catbus1-afk> beisner: thank you!
<TimNich> Just getting started with juju on trusty. Having an issue as juju-log is missing and doesn't seem to be part of juju-core (currently 1.21) but is required at least by the python hooks.
<marcoceppi_> TimNich: what do you meanit's missing?
<TimNich> Well the command 'juju-log' does not exist, but is invoked by 'charmhelpers.core.hookenv.log' in charm-tools
<TimNich> '/usr/bin' has juju, juju-backup, -bundle, -charm etc but no -log
<marcoceppi_> TimNich: right, that doesn't get installed in /usr/bin
<marcoceppi_> they're only available to the hooks at the time of invocation
<marcoceppi_> TimNich: what are the steps you performed to reach this error?
<TimNich> I was trying to test my install hook by running it stand alone, but it fell over, and by simplifying and looking at the back trace it was clear the command â¦hookenv.log
<marcoceppi-sast> TimNich: right, so you can't just execute it. When a hook executes it wraps the hook with a modified environment (new env vars, etc)
<marcoceppi-sast> you can test it, it it's deployed, using `juju debug-hooks`
<marcoceppi-sast> TimNich: depending on which version of juju you have, you can do `juju debug-hooks unit/# install`
<TimNich> I hadn't got as far as deplying it, I was trying to test bits as I went along.
<marcoceppi-sast> TimNich: you have to deploy to test a hook
<marcoceppi-sast> unless you're doing things like unit testing
<marcoceppi-sast> when you juju deploy something, juju installs an agent and a set of tools on that machine
<marcoceppi-sast> part of those tools are things like juju-log, etc
<TimNich> OK,  thats very helpful. The bash version install can be tested standalone, so it wasn't obvious to me that the pyhon one couldn't. But the ptython one seemed to have some useful libs so I thought I would try it.
<marcoceppi-sast> TimNich: none of the hooks can reliably be tested outside of juju
<TimNich> Hmm. Some unit testing sure would help
<marcoceppi-sast> TimNich: right, you can totally unit test without needingto deploy
<marcoceppi-sast> you just need to mock the calls made to charmhelpers
<marcoceppi-sast> as those are already tested
<TimNich> Right. I was just being a tad simplistic trying to tset sections without doing proper unti testing!
<TimNich> Thanks for your help.
<TimNich> marcoceppi-sast: I see you are the maintainer of charm-tools. I notice that the python hooks structure created uses one .py file per hook function plus a couple of imports, but the structure documented at http://pythonhosted.org/charmhelpers/index.html shows a single hooks.py with sym links to it for each function. Which structure is the one to expect going forward?
<marcoceppi-sast> TimNich: we don't really dictate how to structure your charm, we simply help model different patterns. As far as the code in the charm and structure as long as you follow the outline that you implement X hooks that juju expects, everything else is up to you
<marcoceppi-sast> TimNich: there's also two different python templates, there's the `python-basic` and then "python" which is our "services framework" teplate
<marcoceppi-sast> you can see these options running `charm create -h`
<TimNich> ahh. hadn't spotted the python<->python-basic difference, and the pythonhosted docs use 'â¦-t pythonâ¦.', but then show the python-basic dir structure!
<skay> I've got bzr installed, but `charm add tests` is returning http://paste.ubuntu.com/10025926/
<marcoceppi-sast> o/ skay
<marcoceppi-sast> skay: did you install charm-tools from pypi or source?
<skay> marcoceppi-sast: at this point that is lost to the sands of time. I can't remember
<marcoceppi-sast> skay: I used to have a cleanup script
<skay> marcoceppi-sast: which charm and juju tell me /usr/bin/<charm | juju>
<marcoceppi-sast> but if you install from apt it will always work. The problem is /usr/local takes precenece over other things
<marcoceppi-sast> skay: try this: sudo rm -rf /usr/local/lib/python*/dist-packages/charm*
<marcoceppi-sast> then run `charm add tests`
<skay> marcoceppi-sast: I still get the stacktrace. I may have installed bzr via pip (I can't remember at this point) due to wanting git-lp and needing to muck about with bzr
<marcoceppi-sast> skay: is it installed with apt?
<marcoceppi-sast> are you getting the same trace?
<skay> marcoceppi-sast: I am assuming charm-helpers are installed with apt, because when I do sudo apt-get install charm-helpers it tells me that it is already installed
<marcoceppi-sast> well, charm-helpers are not charm-tools
<skay> marcoceppi-sast: derp. that was a thinko
 * marcoceppi-sast nods
<skay> marcoceppi-sast: just checked and apt says it is already the newest version
<skay> marcoceppi-sast: I might take this to the mailing list because I need to switch context to work stuff. thanks for triaging
<skay> marcoceppi-sast: I want to be able to compare the generated test scaffolding to the python-django existing tests to see how different things are. ultimate goal is make MRs for the changes in my fork nrpe-external-master is useful, pip_extra_args is useful but I can't get tests to pass yet (http://reports.vapour.ws/charm-tests/charm-bundle-test-10877-results ) and once I fully grok proper testing I want to get those things in
<marcoceppi-sast> skay: ack
<skay> python-django question, I recall that an ansible fork is being worked on. Is fabric support getting dropped? https://bugs.launchpad.net/charms/+source/python-django/+bug/1416108/comments/2
<mup> Bug #1416108: [test] Python-Django test plan <test> <python-django (Juju Charms Collection):New for nicopace> <https://launchpad.net/bugs/1416108>
<nicopace> skay: mup: that means that it has no point for me to implement test on the current python-django charm till the ansible fork is merged?
<skay> nicopace: I don't know, so let's see what the project maintainers thing
<skay> lazyPower: I remember talking to you about python-django, I think?
<skay> nicopace: I'm only a user
<nicopace> skay: (y)
<skay> nicopace: I'm making a reply for you in the issue
<mbruzek> jog ping
<jog> hi mbruzek, I'm stepping out to bring the kids to school, I can ping you back in a bit
<mbruzek> jog ok
<mwak_> hi
<mbruzek> Hello mwak_
<whit> tvansteenburgh, are you the new maintainer of deployer?
<tvansteenburgh> whit: i'll never admit to that
<whit> tvansteenburgh, :D
<whit> tvansteenburgh, if hypothetically, you were the new maintainer of deployer, where would I submit bugs?
<tvansteenburgh> whit: https://bugs.launchpad.net/juju-deployer
<whit> tvansteenburgh, thnks
<jog> mbruzek, ping
<mbruzek> Hi jog, I was not seeing the results from the jobs I kicked off yesterday 02/02/2015.
<mbruzek> http://reports.vapour.ws/charm-summary/kubernetes
<mbruzek> I see them now, was there something that changed?  Or does the ingestion only run so often
<jog> mbruzek, ok I fixed that... should be there now?
<jog> mbruzek, it should be happening every 15 minutes
<mbruzek> jog can the result page show the bundle that was used?  we are passing a -b bundlepath/bundlename to the command now.
<mbruzek> tvansteenburgh: added the bundle feature for us, right now I can not tell which bundle was used to start which test.
<jog> I'll take a look
<mbruzek> jog as an example I am running the command like this:  -envs 'aws,hp,azure,joyent' -b specs/head-latest-release-v0.8.2.yaml gh:whitmo/bundles-kubernetes
<mbruzek> I would hope to see specs/head-latest-release-v0.8.2.yaml in the charm column
<mbruzek> Because the bundle URL will always be the same.
<tvansteenburgh> jog, i added a bundle key to the json
<jog> yup, I see it there
<jog> I can add that information to the report
<mbruzek> thank you jog and tvansteenburgh
<jog> mbruzek, although I don't think I'll replace the URL... since this report is used for other charms that may not have the bundle information
<mbruzek> jog Yes I understand, I just want to know what version that is
<icetoad> I have different physical servers i want to use for specific packages.  Is there a way to link the MAAS name and setup to a specific machine in Juju?  Seems they deprecated the Maas-name tag.  I was able to use the add-machine ssh:maas_server_name_here command, but then Juju Doesnt apply a name to the machine that correlates to anything.
<tvansteenburgh> icetoad: maybe you can use constraint tags? see `juju help constraints`
<icetoad> yea, i tried the constraints, but the tags dont exist any more
<icetoad> they eliminated the maas-name constraint tag
<icetoad> seems like juju is meant to just grab a machine from a pool and go, but if the machine died, i would have no idea which physical server it was without trying to hunt through ips and configurations
<tvansteenburgh> icetoad: this should still work: https://maas.ubuntu.com/docs/tags.html
<icetoad> i was assuming it did, but even if i tag the machine(talking about tagging 1000 plus machines here), will the tag show up in the JuJu gui?
<icetoad> sorry, i forgot the juju status command shows the maas name....  perhaps its not as a big a deal... it would just be easier if that were exposed on the juju gui
<icetoad> i can target the machine with the add-machine ssh command, but i guess i could play with tags to see if i can add a step in the preseed to add the tag automatically
<icetoad> i understand why they got rid of the maas name tag, but i wish they had just fixed the issue
<lazyPower> skay: o/
<lazyPower> allo, you had some questions?
<skay> lazyPower: I can't remember if you are a python-django maintainer. are you? I had a question aobut whether fabric is getting deprecated in favor of ansible
<skay> lazyPower: nicopace has a test plan, and if fabric will be around a long time, it makes sense to be included in the test plan. but if that isn't true, then we should let nicopace know
<blr> skay: fabric 2 with python 3 support is still under development afaik, I don't think it has been abandoned.
<roadmr> fabricccc! I don't want to have to use crapistrano for deployment!! aaah
<skay> roadmr: I've used fabric, not the other
<roadmr> skay: it's mostly a joke; most python tools have ruby equivalents, capistrano is roughly equivalent to fabric
<skay> roadmr: I'm working my way from fabric to ansible
<skay> roadmr: heh, it went over my head. I thought capistrano was more complicated than fabric
<skay> roadmr: ansible is a gazillion deeply nested directories of yaml files
<roadmr> oh the horror.yaml :(
<skay> roadmr: I haven't decided how bad it would be if I don't follow the custom. people probably do it that way for a reason
<skay> roadmr: you haven't had enough java in your life, I bet.
<skay> roadmr: more like horror.xml
<roadmr> NOOOO
<roadmr> I have had to translate xml files by hand - spit out by some horrid microsoft web development framework, I recall
<skay> like finding 4 sided dice on the floor with your bare feet, is xml
<roadmr> ouch...
<lazyPower> skay: ah good catch. I'm not a maintainer, but i will definately take a look at the merge chain and see how things are going.   Patrick Hetu has been the primary developer on the charm, and it probably warrants a touch base with him
<lazyPower> skay: thanks for taking a vestd look and reaching out - i'll make sure to follow up on that now so i dont forget
<skay> lazyPower: thanks, maybe he can leave comment here https://bugs.launchpad.net/charms/+source/python-django/+bug/1416108
<mup> Bug #1416108: [test] Python-Django test plan <test> <python-django (Juju Charms Collection):New for nicopace> <https://launchpad.net/bugs/1416108>
<lazyPower> skay: ta
<skay> o/
<nicopace> skay: lazyPower: thanks for that, i'll be working on the python-django charm in a couple of days
<lazyPower> nicopace, skay: correspondance has been sent. nicopace - i cc'd you as well.
<nicopace> (y)
<lazyPower> :thumbsup:
<lazyPower> irc needs more emojii
<nicopace> :D
<nicopace> thanks lazyPower, i lack the connections you guys have ;)
<skay> lazyPower: :thumbsup: is bd
<skay> lazyPower: bd can also be batman
<lazyPower> NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN WATMAN!
<lazyPower> https://www.destroyallsoftware.com/talks/wat <- i cite my reference
<skay> oh I LOVE that talk.
<nicopace> Hi guys... you know, the monitors relation (belonging to nagios) is really badly documented... it would be great if we add at least some of this content to this relation's documentation: https://maas.ubuntu.com/2012/09/05/nagios-is-from-mars-and-mysql-is-from-venus-monitoring-part-2/
<lazyPower> nicopace: can you file a bug?
<nicopace> sure :D
<lazyPower> a good majority of our charm interfaces are widely undocumented
<nicopace> that's not good at all :S
<skay> also the death of yavascript one. which has inspired some other great talks. one at an open bio conference by Titus Brown, https://www.youtube.com/watch?v=uwsjwMO-TEA
<lazyPower> and thats not a great story to have - but if we can identify the low hanging fruit like that - we can knock out a good chunk of them.
<lazyPower> skay: another great reference :)
<nicopace> sure! i'll pay attention to that while i implement the tests
<lazyPower> nicopace: thanks a million mate. tag them with 'doc' and 'interface' and i'll keep a running sort on them so i can try to assist as i get time
<skay> lazyPower: I should do that too, I was wondering bout how to auto-discover the servername of the apache2:reverseproxy so that I could think of adding the ability to the python-django charm to inject it in to ALLOWED_HOSTS but the interface def in metadata.yml does not indicate anything
<skay> lazyPower: and maybe I should file a bug?
<skay> likewise for python-django for its http interface.
<skay> but I got to wondering whether it was an expected practice or if those were widely documented somewhere that I hadn't discovered yet
<lazyPower> skay: yeah - if none of the interfaces are documented, i think its fine at this point to just mention that the interfaces are undocumented, which makes the integration path = diving through code.
<lazyPower> its not documented :(
<lazyPower> marco has been dangling a carrot in front of me while we keep piling work on him
<nicopace> https://bugs.launchpad.net/charms/+source/mysql/+bug/1417753
<mup> Bug #1417753: Document monitors interface <doc> <interface> <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1417753>
<lazyPower> so i think bugs + tags for now will start that ball rolling in docs, and if we ever get a moment to build an interface listing, we'll aggregate it in one spot for quick reference
<lazyPower> skay: i was thinking about building a chart on something like interfaces.juju.solutions - where you can plug in a charm name and get back the listed interfaces, and the data pass
<nicopace> my way of understanding what a relation does, is looking over the README, and diving throught the code
<lazyPower> along with examples
<lazyPower> nicopace: yeah :( that sucks :(
<lazyPower> i dont like that :( its totally user friendly </sarcasm>
<skay> lazyPower: that would be excellent. right now if you click on an interface you get a view all the things that use the interface, at least
<skay> yeah, I have had to do that a lot too
<nicopace> lazyPower: it seems that there was an interface in the past, but it is not there anymore:http://jujucharms.com/interfaces/monitors
<lazyPower> skay: yeah - which is a good first step - but trying to integrate without knowing what the datapass is, is the pitts
<lazyPower> and i was vehemently opposed when i supported gets/sets in metadata.yaml
<lazyPower> so now it kind of needs a central registry to view that information
<lazyPower> jsut for simplicity sake (bare minimum, stuff it in the readme)
<nicopace> that link was retrieved from "Interface docs" from here: https://manage.jujucharms.com/interfaces/monitors
<nicopace> the problem seems to be that the interfaces don't belong to anyone
<nicopace> so, who would be responsable of documenting it?
<nicopace> lazyPower: skay ^
<lazyPower> nicopace: the provides is the owner actually
<lazyPower> requires is just a consumer of the provides relationship
<lazyPower> its a loosely coupled contract
<nicopace> but for example, mariadb and mysql both provide the same interfaces
<nicopace> and the http interface is provided by a lot of services
<lazyPower> nicopace: https://speakerdeck.com/chuckbutler/service-orchestration-with-juju?slide=25
<lazyPower> take a look at this slide deck i've been using to teach juju since FOSDEM
<lazyPower> relations are the declarative language juju provides to expose how one service will interact with another - in either a provider or a consumer fashion. This is bi-directional, so the actual "ownership" of the interface, would be the responsibility of the provider - since there is no actual registry or uniform standard that you have to conform to
<skay> lazyPower: did fosdem manage to get a video of the talk?
<lazyPower> skay: i have no clue :(
<lazyPower> i can reach out to kris and find out - but later. I've been bugging him like mad lately with cfgmgmtcamp
<skay> lazyPower: it's okay, I have friends of friends who are involved inf osdem video
<nicopace> ok... so for the majority of the relations, as they are almost one-to-one with provider charms, there is no problem
<lazyPower> skay: nice! if you find out - let me know :D
<lazyPower> nicopace: correct.
<nicopace> ok... so it would be great to have that docs arround...
<nicopace> lazyPower: where does they go? metadata.yml?
<nicopace> it would be super-easy to do an automated script that checks if a charm's providing relations have documentation or not
<lazyPower> nicopace: the relationship definitions are in metadata.yaml - the interfaces are loosely defined contracts between two services - so presently there is no easy way to discern what data is being handed over the wire except grepping the code for relation-set
<nicopace> from this docs, there is no way to specify documentation of a relation: https://jujucharms.com/docs/authors-charm-metadata
<nicopace> (not structured at least)
<lazyPower> nicopace: correct, that was actually recently removed
<nicopace> why removed?
<lazyPower> and by recently i think it was october 2014 - give or take, when the gets/sets key was removed from metadata.yaml
<nicopace> is this a bug that needs to get addressed (by juju)?
<lazyPower> because we like making things hard I suppose :( i dont have a good reason for you, as i was on the party that voted against this.
<lazyPower> but, what i can do is ask when marco returns. I know he's got a well formed answer for this
<lazyPower> allright, i'm outy 5000 for now. its late here in belgium.
<lazyPower> ty for all the feedback, ideas, and enthusiasm nicopace
<lazyPower> if you need anything dont hesitate to ping
<lazyPower> o/ skay - thanks again for being awesome :D
<nicopace> sure lazyPower See you tomorrow then :P
<skay> :D
<ctlaugh> I have some nodes that are cpu-cores=8 and cpu-cores=4.  Is there a way to force juju to add one of the lower-core machines?  When I use --constraints "cpu-cores=4", it is still picking a machine with 8 cores.
<marcoceppi-sast> ctlaugh: set cpu-cores=3
<hazmat> there's an open bug on this
<hazmat> https://bugs.launchpad.net/juju-core/+bug/1380989
<mup> Bug #1380989: juju picking randomly from available machines instead of best fit <constraints> <deployer> <ubuntu-engineering> <juju-core:Triaged> <juju-deployer:Invalid> <https://launchpad.net/bugs/1380989>
<hazmat> only applies to machines already in the environment without workloads
<ctlaugh> marcoceppi-sast: I tried... still gives me an 8-core :(
<ctlaugh> hazmat: Mine are in MAAS and haven't been added to juju environment yet.  I guess I can use tags, but I was trying to avoid that.
<hazmat> ctlaugh, hmmm, that could be an issue on the maas side then, juju basically passes those through afaicr
<hazmat> ctlaugh, what version of maas?
<ctlaugh> hazmat: 1.7.1~rc5+bzr3341-0ubuntu1~trusty1
<hazmat> ctlaugh, interesting
<hazmat> ctlaugh, looks like maas picks the first one it finds by natural db order that matches the constraints
<ctlaugh> hazmat: oops
<hazmat> ctlaugh, would you mind filing a bug?
<ctlaugh> hazmat: Yes - just about to.  Here? https://bugs.launchpad.net/maas
<hazmat> ctlaugh, yup
<ctlaugh> hazmat: https://bugs.launchpad.net/maas/+bug/1417793
<mup> Bug #1417793: MAAS selection of node for juju constraints does not choose "least-capable" match <MAAS:New> <https://launchpad.net/bugs/1417793>
<hazmat> ctlaugh, cool, thanks
#juju 2015-02-04
<bloodearnest> it there a bug open for better formatting of the stdouts of a multi-unit juju run? Because it's unreadable at the minute
<lazyPower> bloodearnest: not that i found on a quick search
<bloodearnest> lazyPower, yeah me neither, just wanted to check here before I filed one
<lazyPower> bloodearnest: you made mention you wanted to use the slides i dropped on speakerdeck. do you want the impress template?
<bloodearnest> lazyPower, yeah, that'd be sweet, thanks
<lazyPower> https://www.dropbox.com/s/pxapq90ma326nw3/service-orchestration.odp?dl=0
<bloodearnest> lazyPower, sounds like you had fun :)
<lazyPower> bloodearnest: it was intense. one man show, 8 speaking events, 3 weeks notice. I was dancing, non stop :)
<lazyPower> well i had prior notice, but nothing was confirmed prior to 3 weeks before the conf.
<hazmat> lazyPower, intense
<lazyPower> hazmat: \o/
<lazyPower> hazmat: signs of life! i thought you were going to be MIA for a while
<hazmat> lazyPower, i am for most of the day, restricted networks
<lazyPower> oi
<lazyPower> hazmat: did you have a chance to follow any of the slide work i published?
<lazyPower> i'm curious to get your take on what i put out there
<hazmat> lazyPower, checking
<hazmat> lazyPower, pretty solid
<lazyPower> hazmat: thanks for the review. Means quite a bit that you stamp it with approval :D
 * lazyPower hat tips
<jcastro> hatch, ping
<hatch> jcastro: hey
<jcastro> hey so check this out
<jcastro> https://jujucharms.com/ceph/
<jcastro> one revision behind, but james and crew pushed a new version on thursday
<hatch> did their version pass proof?
<marcoceppi-sast> https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/ceph
<jcastro> aha!
<hatch> :)
<jcastro> E: Unknown relation field in relation nrpe-external-master - (gets)
<jcastro> yeah, got it, thanks!
<hatch> jcastro: np - we should probably have some indicator somewhere of something somehow for this :)
 * hatch intentionally leaves that very open ended :D
<hatch> jcastro: typically if your charm doesn't show up in under an hour something went wrong :) it's on a 30min loop so depending on when you catch that loop...
<jcastro> ack
<jcastro> hatch, would it make sense to autofile a bug on the charm if it fails?
<hatch> jcastro: tbh I'd like to see some kind of a status page somewhere where you could check
<jcastro> well, not for me
<jcastro> for people who push and have no idea why it didn't show up
<hatch> right - it would be in the docs "go here for charm ingestion status"
<hatch> that could even possibly be linked by the page on jujucharms.com
<hatch> I'm totally just throwing out an idea here
<jcastro> iirc the original plan was to have the "status lights" on the charm's actual page
<hatch> yeah I think that filing a bug would be hard - I'm not sure that the proper people would see it for promulgated charms
<hatch> I don't think I see bugs filed for Ghost if it's on the promulgated charm?
<jcastro> hatch, found the problem, charm tools is returning 0
<jcastro> so the ceph guys lint check, it's just returning(!) zero
<lazyPower> hatch: couple things about that
<lazyPower> 1) we already have the review queue - why not attach diagnostic messages like that to the review item?
<hazinhell> jcastro: the new store should have some events support .. ie if you use juju publish it should give you feedback
<lazyPower> 2) Why am i checking a page when you have the maintainer field in metadata and can contact the maintainer?
<jcastro> hazinhell, oh awesome, that sounds great.
<hatch> lazyPower: people can push to their own namespace (it'll still fail if proof fails) and it doesn't touch the review queue
<hatch> and the maintainer field isn't always accurate
<hazinhell> jcastro: its been supported for a few years fwiw (re events and juju publish for store feedback).. haven't tried it with the new store impl that's extant but it should work
<jcastro> right so instead we just say `juju publish fail, please run charm proof and fix your stuff
<hatch> is it normal for the debug-hooks command to not dump you into the hooks context on the 'start' hook?
<hazinhell> hatch: yes it dumps you into a empty window, and the others pop up in response to hooks executing, but if there is no active hook you won't be in a hook context
<hatch> ahh that's probably what's happening
<hatch> I wish I didn't have to spam debug-hooks after deploy
<hazinhell> hatch: there's some arcana involved but if you want to poke around at the unit context, you can use juju-run on the unit to examine its state.
<hazinhell> hatch: cory_fu made some nice debugging tools to avoid having to do the double poke (debug and resolved --retry)
<hatch> is there a reason why we don't say 'ok you asked for debug-hook, but the unit isn't up yet, so we'll wait till it is'
<hazinhell> hatch: no, there is no reason.. feel free to file it as a cli ux bug, there's a few like that
<hatch> Will do! thanks
<hatch> looks like there is already a bug :) https://bugs.launchpad.net/juju-core/+bug/1278831
<mup> Bug #1278831: debugging first run of install hook is not straight forward <debug-hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1278831>
<hatch> now to figure out how to use tmux in a tmux :)
<hazinhell> hatch: its easy.. rebind control key on the outer one ;-)
<hazinhell> hatch: that requires forethought.. the other way if they match on controls is to double hit the control char
<hatch> yeah there was definitely no forethought here :P
<dbart> mbruzek: ping
<mbruzek> hello dbart
<mbruzek> What can I do for you?
<dbart> mbruzek: hey there! I was working with lazyPower on the MariaDB charm
<mbruzek> dbart: Yes I heard that
<dbart> we had an issue with the charm on P8, but I think I've just solved it
<mbruzek> dbart: OK great news!
<dbart> MariaDB on P8 is built with IBM's Advanced Toolchain, and without the runtime package, MariaDB won't install
<dbart> so the issue was how to get the runtime
<mbruzek> dbart:  "was" so you solved it?
<dbart> so what I've done is added the package to our MariaDB repository, so now when the charm goes to install mariadb-server it sees and pulls in the runtime package
<mbruzek> dbart:  what is the package name?
<dbart> advance-toolchain-at8.0-runtime
<dbart> our packages (correctly) depend on it, but on the test box lazyPower was testing on the package wasn't in any of the configured repos, so apt-get failed
<mbruzek> $ apt-cache search advance-toolchain-at8.0-runtime
<mbruzek> I see no results for that dbart when I search on a power 8 system.
<dbart> exactly, it's generally found in a separate IBM repository
<dbart> so by adding it to our P8 repo when you try to install mariadb-server apt can find it
<mbruzek> dbart: This conversation seems familiar.  Have we talked about this before?  Does MariaDB need to be built with that package?
<dbart> IBM really wants us to build with it, it's not absoultely required, but performance is better when it's used
<mbruzek> dbart: It is my understanding that the advanced toolchain was needed for people who build with older kernels, and this was a way to get the new compiler to older level of kernels.  My understanding is if you use modern kernels and compilers they are often newer than advanced toolchain.
<mbruzek> dbart: If the performance is better then I am not arguing
<mbruzek> dbart: From the conversations I have had it was obsolete and no advantage.
<mbruzek> to have the toolchain.
<dbart> ok, I don't know about all that, I just know that our devs are still building with it...
<dbart> I could ask them about it
<kwmonroe> negative mbruzek - AT brings cpu flags to the table that gcc hasn't brought yet
<mbruzek> dbart: I don't want to conflate the issue, if you have a fix that is great!  I just was telling you what my understanding was of the advanced toolchain.  Because we (Canoncial) asked about using advanced toolchain for other instances and I seem to remember that it was not needed.
<mbruzek> kwmonroe: ahh very good, thank you for correcting me.
<dbart> ok, understood :)
<kwmonroe> event based branching comes to mind.. as a power8 cpu feature that's not in gcc, but is available for AT
<kwmonroe> hardware transactional memory is another.. why buy a p8 if you're not gonna STEP UP TO THE POWAHHHHH?!?!
<dbart> mbruzek: so just a few minutes ago, with the runtime package in the repo, I was able to install MariaDB on the test instance lazyPower gave me access to
<mbruzek> dbart: it seems my memory is not as good as it used to be.  Disregard my earlier statements about AT.
<dbart> :)
<mbruzek> dbart: how can I help?
<dbart> I'm going to be going afk now, and I don't know what else there is that needs to be done... lazyPower was working on testing the charm, but hit the repo issue
<dbart> so now that the repo issue is solved (and MariaDB can actually be installed) I assume testing can be resumed, but I don't know what lazyPower was going to do next on that
<mbruzek> dbart: what is your branch?
<dbart> https://code.launchpad.net/~dbart/charms/trusty/mariadb/trunk
<mbruzek> dbart so let me see if I understand, your install hook now installs the toolchain that was needed for mariadb to pass on ppc64le?
<dbart> there's an issue with the amulet tests (they don't account for the enterprise instructions in the README)
<mbruzek> dbart can you give me a hint?
<dbart> you basically need to create a ent.yaml file that has the correct information in order for the enterprise repo to work (which is where the P8 packages are)
<dbart> I don't know how lazyPower was doing the tests (since the amulet tests, out of the box, don't work)
<mbruzek> dbart: passing the amulet tests are something that are required for a charm to go into the recommended section of the charm store.
<mbruzek> dbart: Do you know what is needed to make them work?
<dbart> yes, so those need to be fixed, that's probably the next step
<kwmonroe> i know mbruzek.. the ./tests/10-deploy test is trying to install the "normal" maria packages first.  that adds a repo and does an apt-get install mariadb.  that's great, except the repo doesn't have a ppc64le arch.. so 10-deploy fails right off the bat when testing locally.
<dbart> kwmonroe: yup, that's it in a nutshell
<kwmonroe> on an arch that *does* exist in the mariadb repo, the next setp in 10-deploy is to "upgrade" the repo to use the secret enterprise url.  but running the test natively on power, we can't get past step 1 to get to step 2.
<dbart> by using an ent.yaml file and passing that to deploy, you can set it up right of the bat
<kwmonroe> yup - just like the readme tells ya to do ;)
<kwmonroe> so mbruzek, the problem is making the amulet test do what the readme says.
<dbart> we really need a better solution for those that want to use the Enterprise repo, but what's outlined in the readme is all I've got at the moment
<dbart> lazyPower was working on updating the tests I think, but I don't know how far he got
<mbruzek> dbart: Can you refactor the amulet test to do that?  I haven't seen or used mariadb in quite some time, a bit out of the loop
<kwmonroe> i think it gets even stickier dbart.. if you want to test the enterprise repo (which is the only option for p8), you need to expose a user:password in the amulet test.
<dbart> yup, that's the other issue
<dbart> I've been complaining to our team about removing the login requirement (nothing but trouble IMO), but as of today it's still needed
<dbart> tomorrow I can look into refactoring the test
<kwmonroe> dbart: is there perhaps an x-day trial user/pass?
<dbart> perhaps, I'd need to look into it
<dbart> anyway, I've got to go now, but I'll work on the tests (and see if lazyPower got anywhere with them) tomorrow
<dbart> thanks all
<kwmonroe> sure dbart - i'll help you manana in case you're sick of mbruzek
<kwmonroe> ;)
<dbart> thanks!
<dbart> :)
<mbruzek> dbart lazyPower is traveling across the ocean so I doubt he will be working on them
<dbart> oh yeah, he mentioned that... :-)
<mbruzek> dbart see you tomorrow let kwmonroe know if you need help refactoring the tests
 * mbruzek ducks
#juju 2015-02-05
<seal> does juju quickstart work in manual based environment e.g digital ocean?
<jrwren> seal: try and find out?
<jrwren> seal: it looks like it does.
<seal> I keep getting error
<hazinhell> seal: quickstart doesn't work afaik, but the juju-digitalocean plugin does
<seal> thanks, I already use juju-digitalocean which is great
<hazinhell> seal: quickstart doesn't support manual provider afaik.
<seal> how would you deploy a bundle using juju-digitalocean?
<marcoceppi-sast> seal: that's a good question
<marcoceppi-sast> seal: you could use the Juju GUI
<marcoceppi-sast> since that supports placement
<marcoceppi-sast> but you'd need to first juju docean add-machine
<marcoceppi-sast> Since digital ocean plugin runs only client side juju can't create the units for you from the API
<seal> I can confirm that deploy works via gui. I was hoping to automate this via script. Thanks for your response anyway.
<hazmat> seal: quick answer.. you have to juju docean add-machine -n size_of_bundle
<hazmat> before deploying
<seal> thanks
<seal> hazmat: juju-quickstart: error: cannot use the docean environment:
<seal> a value is required for the bootstrap host field
<seal> this the error I am getting as the environment is set as bootstrap-host: null
<swifty> hi guys
<swifty> having a problem with juju-quickstart
<swifty> anyone can help me?
<frankban> swifty: on call but I'll try
<swifty> thanks, frankban
<swifty> well, we deployed a well working openstack on a server
<swifty> it has all components running and working - glance, nova, neutron, swift, etc.
<swifty> I'm trying to work on this openstack via juju on my laptop
<swifty> we are both connected on the same lane (10.0.0.0/24)
<swifty> I ran juju quickstart
<swifty> set all the parameters
<swifty> and get this error:
<swifty> http://paste.ubuntu.com/10074672/
<swifty> need paste of environments.yawl?
<frankban> I'll look asap
<cmagina> is there a limit to how much data you can deploy as part of a charm?
<jrwren> cmagina: practical limits like disk on juju state server.   if you are deploying local charms, there was a bug in some older verions of juju which caused state server to load entire charm into memory, which would lower that practical limit a lot.
<cmagina> jrwren: hmmm....1.20.14-trusty-amd64 should be new enough
<cmagina> jrwren: the charm has 240M of data between two tarballs
<cmagina> so nothing crazy, just wasn't sure if that was a place to look
<jrwren> cmagina: nope, that is fine. we use charms of a very similar size all the time with no problems.
<cmagina> jrwren: ok, cool, thanks, i'll keep looking for the problem
<hazmat> seal quickstart doesn't play nice it sounds like, its also reading the environments.yaml instead of jenv it sounds like.
<nicopace> hi guys... i'm trying to access this url, but it is telling me that there is an error on openid authentication: http://pad.ubuntu.com/uos-1406-simpler-charms-with-ansible
<nicopace> can anyone of you test if you can access with your ubuntu openid info?
<sarnold> nicopace: worked for me; I saw the redirect page for .2 seconds, then clicked the button to share my ubuntu-etherpad membership
<nicopace> sarnold: :( my auth page appears, but nothing is there to authorize!
<nicopace> sarnold: http://imgur.com/BfzClis
<nicopace> any idea what that could be?
<nicopace> it also happens with the juju review queue :S
<sarnold> nicopace: hmm, odd. sorry, no idea :/
<nicopace> well.. now http://review.juju.solutions/ is working (y)
<nicopace> but not etherpad
<nicopace> any idea who i can talk to about this?
<sarnold> nicopace: give this site a shot: https://login.ubuntu.com/
<sarnold> nicopace: there's a 'support' link at the bottom that goes to https://forms.canonical.com/sso-support/
<nicopace> great! i'll ask them. thanks sarnold!!
<sarnold> good luck nicopace :)
<avoine> nicopace: the pad is empty
<avoine> nicopace: there is only the video here: https://www.youtube.com/watch?v=ctoiBQQrDog
<nicopace> thanks avoine... i've contacted the support group :)
#juju 2015-02-06
<lathiat> Hi Folks.. using juju local/kvm container (as part of openstack-install single-machine), trying to figure out how I can add a second disk to the machines when I deploy ceph/ceph-osd.  Can anyone point me in the right direction?
<sebas5384> what happened with the service's settings in the juju-gui ?
<cindy_> good morning guys
<cindy_> having problems with bootstrap
<cindy_> can somebody help me?
<hazmat> any charmers around, can someone add me to charmhelpers, i've got pending merge i wanted to land
<jujuer> good morning guys
<jujuer> having problems with bootstrap
<jujuer> may you help me?
<roadmr> jujuer: go ahead and describe your problem, if someone knows how to solve it, you'll get help :)
<jujuer> roadmr: thanks!
<jujuer> well, I have a server where
<jujuer> we deployed an all in one solution of openstack: glance, nova, neutron, swift, etc.
<jujuer> now, I'm trying to "juju" to this server with my laptop
<jujuer> we are on the same LAN: 10.0.0.0/24
<jujuer> naturally, I'm sure both my laptop and the server have internet access
<jujuer> also the VMs have internet access and can access to them via floating IPs with no problems
<jujuer> I've set the parameters of my environments.yawl
<jujuer> but... bootstraping always fails
<jujuer> need logs?
<jujuer> environments.yawl: http://paste.ubuntu.com/10092804/
<jujuer> my terminal log: http://paste.ubuntu.com/10092884/
<jujuer> btw, juju successfully creates a VM and a container on my openstack
<jujuer> but it can't bootstrap... who knows why
<roadmr> jujuer: hm are you sure about --metadata-source /opt/stack ? it seems unable to fetch data from there, check your log file
<roadmr> jujuer: I haven't used that option before, so I'm not sure if it's OK, but that may be a good clue
<jujuer> I'm pretty sure it does - as I said, it is able to instantiate the VM on the cloud
<roadmr> jujuer: what happnens if you don't use that metadata source?
<jujuer> you mean, the parameter?
<roadmr> yep :)
<jujuer> gonna try
<jujuer> roadmr: I get an "earlier" error, logs incoming
<jujuer> roadmr: http://paste.ubuntu.com/10093161/
<roadmr> jujuer: oohh ok... well then :/ heh
<jujuer> roadmr: this seems quite hard to fix :)
<roadmr> jujuer: yes, I haven't deployed to openstack a lot so I'm not sure if I can help :/
<roadmr> jujuer: when I did, I didn't use the metadata-source flag and everything worked fine, but clearly my config may have been different
<frankban> tvansteenburgh: if you have time, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-auth/+merge/244984 ?
<jujuer> nobody has ideas, guys?
<tvansteenburgh> frankban: looking
<roadmr> jujuer: if there's no reply I suggest you post a question in askubuntu.com :( sorry you haven't had any replies yet :(
<frankban> tvansteenburgh: thanks
<tvansteenburgh> frankban: commented with a suggestion. happy to discuss if you disagree or i'm missing something
<hazmat> jujuer: thats an  interesting error
<jujuer> hazmat: I'm literally going crazy... can't figure what to do
<hazmat> jujuer: i pinged on #juju-dev to see if someone can come over here
<jujuer> hazmat: thanks :)
<hazmat> jujuer: it looks like a mongodb error getting setup.. how big of an instance type are you using?
<jujuer> hazmat: what do you mean exactly?
<hazmat> jujuer: how big is the machine your bootstrapping
<hazmat> jujuer: how much memory / cpu / disk?
<frankban> tvansteenburgh: reasonable suggestion, but since that deployer path is GUI server specific, and since the GUI server always use the deployer embedde in the Juju GUI charm, we do not have the backward compatibility problem. Actually, a fork of the deployer with that change has been included in the charm from quite a while now. for the enwxt release, we'd like to restore the upstream version (new deployer release)
<jujuer> well, I'm not telling juju how much it's big... I'm simply running "juju bootstrap --metadata-source /opt/stack --upload-tools -v --debug"
<frankban> next release even
<hazmat> frankban: i already  merged that
<jujuer> but, if you want, I can see on OpenStack how big it is instanced
<frankban> hazmat: oh, didn't notice that
<tvansteenburgh> lol
<jujuer> well, hazmat, it creates a m1.small | 2GB RAM | 1 VCPU | 20.0GB Disk machine
<hazmat> frankban: next release is roughly next week
<frankban> hazmat: great thank you!
<hazmat> jujuer: k, thanks. it does look like a config issue, just not clear what
<frankban> tvansteenburgh: sorry about that
<tvansteenburgh> frankban:  no worries
<hazmat> frankban: np
<jujuer> hazmat: you mean, my configuration is bad?
<hazmat> jujuer: we have alot folks traveling atm unfortunately, they'll be back next week. no.. i think its a juju internal configuration error afaics. its setting up an invalid mongo replication config
<jujuer> aw, fine. That's weird since I can't google any other guy having mine problem
<hazmat> jujuer: yeah.. its not something i've seen before
<hazmat> jujuer: but its pretty clear what the error is .. juju initializing a replica set on mongo without the required config on replicaset members
<hazmat> jujuer: actually probably best is to file a bug for now
<jujuer> hazmat: have I got any control on this?
<jujuer> hazmat: or I can do nothing atm?
<hazmat> jujuer: use an older version of juju (1.20)
<hazmat> jujuer: your on osx?
<jujuer> no - I'm using a Xubuntu 14.04 on the laptop where I'm trying to run juju bootstrap, and an Ubuntu server 12.04 on the openstack server
<jujuer> hazmat:
<hazmat> jujuer: so default juju in trusty/14.04 is currently 1.20.11 it looks like
<hazmat> jujuer: i'd try that
<jujuer> hazmat: sorry, I haven't understood much :/
<hazmat> jujuer: what does juju --version show?
<jujuer> on my laptop? 1.21.1-trusty-amd64
<hazmat> jujuer: so its a little unclear where that version came from.. i'd guess from a ppa, i'm suggesting you might want to try uninstalling that version/ purging the ppa/ and then install the default distro version which is 1.20.11
<jujuer> hazmat: installed juju via these two commands: sudo add-apt-repository ppa:juju/stable  sudo apt-get update && sudo apt-get install juju-core
<hazmat> jujuer: but please do file a bug with that pastebin, its something that needs looking at http://bugs.launchpad.net/juju-core
<jujuer> sooo hazmat ... should I purge juju and reinstall everything?
<hazmat> jujuer: you have to apt-get remove juju / sudo ppa-purge ppa:juju/stable (if you don't have that you have to remove the ppa from /etc/apt/source.list.d and the apt-get update) / then apt-get install juju
<TimNich> Agggh! Tried a juju bootstrap on my MAAS set up and it randomly chose a node that was unavailable, so the whole process hung. I aborted and tried to "juju destroy-environment" but that too tries to access the broken node and hangs. So I am now stuck with what the system thinks is a bootstrapped environment (but isn't) and I can't re bootsrap onto a specidied node until I persuade it its not! But as "juju destroy-environment" wont work how can I d
<TimNich> that (catch22)?
<hazmat> TimNich: juju destroy-environment --force
<TimNich> hazmat: Thnaks
<jujuer> hazmat: SOME BIG NEWS HERE!
<jujuer> mongodb works, now I hit my head on a new error that comes later
<jujuer> need logs?
<jujuer> hazmat: http://paste.ubuntu.com/10094040/
<hazmat> jujuer: sure, but hopefully someone else can help... i've got get back to work. i'll check back in a bit though.
<jujuer> hazmat: aw ok, thanks anyway
<hazmat> jujuer: that error is because you need to upload / create some 'simplestreams' data for juju to consume. its basically tells juju which images it should launch... see juju-metadata generate-image -h for more info
<hazmat> and also juju-metadata validate-images
<hazmat> jujuer: should be covered here https://juju.ubuntu.com/docs/howto-privatecloud.html
<jujuer> hazmat: as long as I try, I can't solve that issue
<jujuer> hazmat: it's strange since juju actually starts the right VM on the openstack
<hazmat> jujuer: agreed it is strange
<jujuer> hazmat: lol
<jujuer> hazmat: sooo... have you got any suggestions?
<dbart> lazyPower: around?
<lazyPower> o/ dbart
<dbart> lazyPower: I fiddled a little with the test, based on what you did prior to flying home, it looks like the 10-deploy-and-upgrade test now passes on the p8 machine
<lazyPower> dbart: AWESOME
 * lazyPower throws confetti and sounds trumpets
<lazyPower> dbart: let me get someone thats on shift verify that for you and when I get back from my meeting I can run the gambit on getting mariadb ack'd
<dbart> I wanted to get your opinion about the "test_enterprise_eval(self)" test, I'm thinking it might not be needed
<lazyPower> are those changes checked in to bzr?
<dbart> no, not yet
<lazyPower> dbart: yeah that was a check to go from community => entp right?
<dbart> yes, but currently it just starts with enterprise
<lazyPower> its still a valid path that we need to account for, but it will consistently fail on p8 as the community edition doesn't have an installation candidate
<dbart> yes
<lazyPower> so that test works on x86 arch
<lazyPower> I was thinking on this on the plane ride home - about how we want to address that as either split it out into another test suite that only gets kicked on p8, or if we add some conditional checks to find out which methods to run
<lazyPower> kwmonroe: mbruzek: - Could really use your input as to how you feel we should proceed here wrt testing on p8
<dbart> yes, something that can detect when it's on p8 and not run a new test that tests community installs
<lazyPower> kwmonroe: mbruzek: the situation is - MariaDB Community edition doesn't exist on p8, just the enterprise installation. Our CI infra will test x86 all day every day, but if we get p8 added, this is a consistent failure we will see.
<lazyPower> kwmonroe: mbruzek: so is this where we add some additional logic to the runner, or do we do an arch check in the test itself, and say "do this when x, do this when y"
<dbart> I'm also waiting on a request I made on my side for proper test credentials
<mbruzek> lazyPower: yes that!
<lazyPower> dbart: We can probably get around some of that by stealing some logic from mojo
<mbruzek> lazyPower: It would be ideal to have a passing test on both architectures
<lazyPower> mojo has hiding test credentials baked in by default
<lazyPower> mbruzek: agreed - i just dont know how we want to do this. if thi sis amulet's responsiblity or the tests responsibility.
<mbruzek> lazyPower: But I understand the situation and would be OK with x86 only right now.
<lazyPower> right, as we dont have p8 added to our CI - the tests in their current incantation are the proper path forward - but this is a short road until we get p8 added aiui
<mbruzek> I would code the test to detect the architecture and react accordingly
<lazyPower> ok. I'll file a bug on that and get cracking
<lazyPower> mbruzek: do you have time to inspect kwmonroe's p8 box he lent me and validate dbart's assertions we are g2g for p8 mariadb?
<lazyPower> i'm leaving in 8 minutes to head downtown
<mbruzek> we have a meeting in 5 minutes, I could take a look after that, but I haven't touched mariadb in a while.  I was unware of the enterprise difference
<mbruzek> I peeked at the branch yesterday.
<lazyPower> mbruzek: its a pretty straight forward review - I gave the code a review 2 days ago.
<lazyPower> this is mostly asserting that we're g2g for the turbolamp book
<mbruzek> hrmm....
<lazyPower> so we can unblock there and any "fringe" issues like tagging and what nto can be taken care of as follow up - if the installation path doesn't change
<lazyPower> which it shouldn't
<mbruzek> lets separate those two concerns
<lazyPower> ack
<lazyPower> I'm focused on clearing teh critical path first :)
<mbruzek> understood
<lazyPower> dbart: hi5 on your work there. Thanks for circling back so quickly
<dbart> lazyPower: you're welcome!
<lazyPower> dbart: i'll sync with mbruzek when i get back if you two aren't in a communication loop
<dbart> sure thing
<mbruzek> lazyPower: OK
<lazyPower> mbruzek: thanks a million for taking a look
<lazyPower> you're the best
<lazyPower> i gotta jet gentlemen, see you shortly
<jujuer> hazmat: no ideas? I dunno what to do, :/
<brandonclark> I want to get the name of the attached relation for a mongodb server.  what would I use?  >>>  `relation ???`
<hazmat> jujuer: not really, but i'm busy doing other things atm, hopefully someone else might be able to help
<hazmat> or dig in
<brandonclark> is there a `relation-get ` reference?
<brandonclark> oh never mind i get it, relation-get pulls from the config.yaml
<mbruzek> brandonclark: config-get pulls from config.yaml
<mbruzek> brandonclark: relation-get pulls from what another charm did relation-set on
<jujuer> have a good weekend everyone
<brandonclark> yep thats what i meant. but there is a better way of getting the relation name i am reading on relation changes '$JUJU_REMOTE_UNIT'
<brandonclark> good job on putting together some good usage documentation.  Nice to have it!
<brandonclark> is it just me or is the magic key for the terminal commands slow to react? Maybe because I have it bootstrapped to a low process server?
<whit> is there anyway for a charm to know that it's been added to machine 0? (other than sniffing around the filesystem)
<lazyPower> o/ mbruzek
<mbruzek> lazyPower: How was lunch?
<lazyPower> whit: i do believe so, and its exposed in an env var i do believe
<lazyPower> whit: otherwise, no i dont think so
<lazyPower> mbruzek: i just got back - did you get a chance to peek at mariadb?
<mbruzek> lazyPower:  notyet
<lazyPower> ok, i'll take that work item and run it now that i'm back in office
<lazyPower> ta
<mbruzek> lazyPower: I still mean to get to it, perhaps we can pair
<lazyPower> sounds good 2 me
<mbruzek> but today is your swap day
<lazyPower> i just remoted into the box
<mbruzek> so go away!
<lazyPower> yeah well, i just got back from running a meeting with shift interactive downtown - i've got a small business that wants juju
<lazyPower> ;)
<lazyPower> and... get this
<lazyPower> its our "feature rich environment" that they are interested in
 * lazyPower rimshots
<mbruzek> troll
 * mbruzek trolls his eyes
<lazyPower> not even :D
<lazyPower> legit, the fact they are primarily a wordpress based business, but we are giving them full stack agility is whats the real story here
<lazyPower> there's some additional tooling I need to get built so they can run isolated environments for customers and hand those off easily - but 99% of the magic is raw juju
<lazyPower> dbart: have you EOD'd?
<lazyPower> mbruzek: ping when you're ready
<mbruzek> lazyPower: Will do
<kwmonroe> hey lazyPower mbruzek, i did the deed
<lazyPower> kwmonroe: ?
<kwmonroe> bundletester does the business http://paste.ubuntu.com/10097741/
<lazyPower> kwmonroe: <3
<lazyPower> you crack me up
<kwmonroe> and i poked on mediawiki to verify mariadb was hooked up
<mbruzek> kwmonroe: awesome!
<mbruzek> Thank you!
<kwmonroe> but i wouldn't commit that test.  it's got dbart's special sauce in it.
<lazyPower> All thats left of this is ensuring we have a good path forward for our CI story
<lazyPower> yeah
<lazyPower> I think we may have to steal some mojo schenanigans to isolate the credentials
<lazyPower> as i do believe mojo gives us some inroads to keeping credentials out of the test suite
<kwmonroe> i do think we should switch on uname.. x86 gets comm source, ppc64le gets dbart's.  and if we do that, the test_enterprise_eval can go away.
<lazyPower> kwmonroe: either way there's still a requirement of having that repository set of credentials around
<kwmonroe> ack
<lazyPower> *set of repository credentials
<lazyPower> my english, is not so good
<kwmonroe> yeah, i didn't read what you wrote.. just ack'd so you'd be quiet.
<lazyPower> zing!
<kwmonroe> Pow! (er)
<lazyPower> You've been hanging aroudn randall too much
<kwmonroe> he's gonna buy me a car.. so yeah.
<mbruzek> lazyPower: no schenanigans on the tests they are fragile enough
<lazyPower> kwmonroe: http://imgur.com/Oym36MG
<kwmonroe> nice
#juju 2015-02-07
<TabletCube> Hi
#juju 2015-02-08
<bodie_> `juju unexpose` doesn't seem to be doing anything; digitalocean via JuDO, I'm tailing the unit log and I just see "got service change" "no new charm event"
<bodie_> it changes the value of "exposed" for the service in `juju status`
<bodie_> I have multiple services running on a single machine, but the other services are also not exposed
<bodie_> it's trusty/wordpress
<bodie_> open-ports shows 80/tcp
<bodie_> juju 1.23-alpha1-utopic-amd64 cilent
<bodie_> client*
<bodie_> http://paste.ubuntu.com/10118085/
<bodie_> that might be due to having "firewall-mode: instance" in my environments/digitalocean.jenv
<bodie_> no, instance is what I want
<bodie_> ah, looks like expose triggers a hook which is expected to implement the desired effect, and it's not implemented in trusty/wordpress
<hazmat> bodie_: there's no net sec on digital ocean
<hazmat> bodie_: effectively digital ocean has no multi-tenant private networking, and manual provider (which do plugin uses) is a no-op with net sec
<hazmat> bodie_: there isn't a hook for exposed afaik, there was discussion of one many moons ago, but afaicr nothing extant
<bodie_> hazmat, I see.  there's some doc on it on a site which *I think* is caching something old? https://juju-docs.readthedocs.org/en/latest/internals/expose-services.html
<bodie_> hazmat, but it could definitely be done on DO using iptables in the hooks, it's simply not an API level hosting option on their service.  that makes sense now though.
<hazmat> bodie_: those docs are ancient, they applied to the python juju impl against zookeeper
<hazmat> and even then "These hooks will be implemented at a future time."
<hazmat> is in those docs
<bodie_> thanks for clarifying
<bodie_> could be a good use-case for actions :P
<hazmat> bodie_: i've advocated for juju to use a iptable based expose/unexpose (ie universality first).. only issue is relations don't nesc. model tcp conn. there's some work ongoing with the network model which seeks to address that.
<hazmat> as is expose/unexpose work against providers that implement network security.. (azure, ec2, google, openstack).
<hazmat> and for the others they are no-ops
<hazmat> bodie_: not sure how that relates to actions, but hammers and nails i guess
<bodie_> something like that
<bodie_> more like, if I need the ability to control iptables, I can add that to a charm I'm using as a stopgap
<SimplySeth> what's a good charm to copy to begin deciphering how to build a mesos-master charm ?
<lazyPower> SimplySeth: Whats your choice in config management toolkits?
<SimplySeth> lazyPower: Charm-Helpers and Ansible
<lazyPower> SimplySeth: charm create -t ansible
<lazyPower> if you have charm-tools installed (apt-get install charmtools)
<SimplySeth> lazyPower:  yeah I already brew installed charm-tools
<SimplySeth> lazyPower: thanks
<lazyPower> np
<lazyPower> there are some patterns we employed for the docker charm (hyper simple, only delivering the docker plumbing) that are written in ansible
<lazyPower> there's also the elasticsearch charm which is seemingly more complex, and uses ansible as well
<lazyPower> https://github.com/chuckbutler/docker-charm
<lazyPower> here's the outline of ansible logic we used: http://chuckbutler.github.io/docker-charm/dev/ansible-patterns.html
<SimplySeth> coool
<SimplySeth> lazyPower: thanks for the help
<lazyPower> np
#juju 2016-02-08
<haasn> A juju bootstrap got interrupted (failed connecting to the newly provisioned server via ssh due to a bad known_hosts entry), can I continue it or do I have to re-provision the server from scratch?
<rick_h___> haasn: I think it's best to re-provision. It'll be hard to know how far it got and how best to recover.
<rick_h__> https://twitter.com/search?q=%23cfgmgmtcamp&src=typd
<haasn> Is it Juju's official error handling strategy that when something goes wrong, you nuke and start over again?
<haasn> I'm running into errors like services being stuck on âfailed hookâ or machines being stuck on âpendingâ forever
<haasn> At an alarmingly often rate
<haasn> And every time there does not seem to be a reliable solution other than nuking everything and starting over, at least in terms of the stuff I added
<BrunoR> haasn: you can try 'juju resolved --retry' https://jujucharms.com/docs/1.25/authors-hook-errors
<stub> haasn: For 'pending' stuckage, juju destroy-machine --force {machineno} is your best bet. I get this a lot with Juju 1.25 and the lxc provider.
<stub> haasn: For 'failed hook', 'juju resolved --retry unit/42' is your only option unless you want to debug the charm.
<jrwren> haasn: no, that is not juju's official error handling strategy.
<sharan> Hi
<sharan> How do i know last unit in the relation-joined?
<sharan> without using relation-list
<marcoceppi> sharan: there's no way to really know since the model is always mutating. At anytime a user could add or remove unit and you no longer have a "last" unit :)
<sharan> marcoceppi: ok, so we are not able to find the last unit :( , if user adds only 4 units and he will not perform any operation by add or removing unit. At this scenario is their any possibilities??
<marcoceppi> sharan: no, not really. Juju is a fluid system there really is no expectation of idempotent state. What are you trying to solve ultimately?
<sharan> marcoceppi: in my Websphere extreme scale(WXS) charm i need to restart the server every time when it has a peer relation with another WXS. I am stopping the server if server is started in relation-joined and again starting the server in relation-changed hook.
<sharan> marcoceppi:is this the right way to restart the server?
<marcoceppi> sharan: yeah, there's really nothing you can do at this point except to use something like leadership to help coordinate. You can't really use relation-list because that's not a continued state of the environment and won't show all 4 right off the bat
<sharan> marcoceppi: you mean leadership concept is better over the relation-joined and relation-changed for restarting the server whenever it has a peer relation.
<marcoceppi> sharan: possibly, what information do you need in the peer relation?
<sharan> marcoceppi: is it possible to have peer relation between 2 products? i mean 1 product have peer relation and second product also have peer relation, is it possible to have again a realtion between these products?
<icey> how hard is it to have two separate charms relate to the same database in Postgres?
<marcoceppi> icey: not very
<icey> I just ran into an issue where the 2nd relation added did not have roles to acces the database -_-
<marcoceppi> icey: thta's weird
 * marcoceppi takes a look
<icey> marcoceppi: trying to have the charm add roles as well as request the given database now
<smartbit> Marco, after last weeks juju charm summit I failed to get juju to work https://bugs.launchpad.net/juju-gui/+bug/1542652
<smartbit> What can I do in the mean time to get started with juju?
<mup> Bug #1542652: juju-gui hangs on "Connecting to the Juju environment" <juju-gui:Triaged> <https://launchpad.net/bugs/1542652>
<marcoceppi> smartbit: you don't really need the gui to use Juju. If you ssh into the vagrant box you can just "juju status" or issue any other of the juju commands to start interacting with the environment
<smartbit> I understand, but would like to get a hands-on with it. Particular on juju 2.0 alpha.
<smartbit> hands-on with the GUI
<marcoceppi> smartbit: hum, if you'd like you could apply here: https://developer.juju.solutions and we can give you AWS cloud run time
<marcoceppi> smartbit: that way you won't need to use vagrant and the GUI will work there
<smartbit> seems resonable. I'll take the AWS route for now.
<haasn> stub: retry on the unit just gave me the same error again, I had to physically destroy the machine it was on (because there's no way to force-destroy a unit afaik) and everything it was connected with and start over from scratch. Also âjuju destroy-machine --forceâ is my definition if nuking it and starting over
<haasn> Especially when it means I'm trying to deploy, say, the âopenstack-monitoringâ solution, and afaik there's no way to âpartiallyâ add that solution except painstakingly and by hand, so I have to nuke every other service and start from scratch again
<haasn> .. and of course if another machine gets stuck on âpendingâ the second time around, again
<haasn> and so on
<haasn> It just doesn't seem like a very reliable design
<smartbit> marco: submitted the request
<marcoceppi> smartbit: you should have an email in a few mins
<asanjar> randleman: hi there, are you going to be at IBM Interconnect
<lazypower|travel> asanjar o/
<asanjar> hi lazypower|travel, how are you my friend
<lazypower|travel> Really good :) bumming around in Oxford UK on mini-cation. Dropped in to check messages
<asanjar> lazypower|travel: wow Mr. traveler
<lazypower|travel> Tryin anyway :)
<asanjar> lazypower|travel: are you enjoying the weather? you must go to an EPL game
<lazypower|travel> Well, I saw a Rugby match yesterday at the pub where I went to watch an ice hockey game. The weather has been miserable since I arrived, but thats to be expected for the time of year
<marcoceppi> stub: you about?
<haasn> Hmm. I can so reliably reproduce this issue that I'm really struggling to think of what's going on
<haasn> Basically I add a machine in juju (configured with a MAAS environment). It acquires a node and starts deploying it, and the deployment process completes + the machine shuts down afterwards
<haasn> And.. that's it
<haasn> The machine never turns itself back on, and even if I turn it on manually again juju just sits there and does nothing
<haasn> it's supposed to ssh into the machine and start running apt updates etc.
<haasn> and it works on some machines, just inexplicably not others. The ones it fails on are all VMs, but I'm not sure if that's just a coincidence
<haasn> but it _has_ worked on VMs just fine, too
<haasn> seems pretty random
<haasn> Hmm, I think I'm getting closer: ssh into the machine and `sudo reboot` also does not work, it just shuts down
#juju 2016-02-09
<haasn> Weird. Destroying the VM and re-creating it and now everything seems to work. Must have been some weird failure due to the way I batch-created the VMs
<haasn> Have to go through the VMs all and recreated them manually I guess :/
<haasn> 2016-02-09 00:18:31 ERROR juju-log FATAL ERROR: Could not determine OpenStack codename for version 7.0.1
<haasn> Huh?
<stub> marcoceppi: ETIMEZONE
<haasn> What does âincomplete relationsâ mean?
<haasn> It's obviously different from âmissing relationsâ in some sense
<haasn> Revelation: Writing configs by hand is faster, easier, more efficient, more robust and more scaleable than attempting to use juju for anything other than setting up a basic wordpress site
<apuimedo> jamespage: did you see the merge proposal I sent last night for fixing liberty support?
<jamespage> apuimedo, I saw the charm mp - is there a charm-helpers proposal as well?
<jamespage> I've not looked yet...
<apuimedo> heh
<apuimedo> lack of sleep
<apuimedo> Totally forgot about updating it in charm-helpers
<apuimedo> I'll send it now
<apuimedo> jamespage: https://code.launchpad.net/~celebdor/charm-helpers/plugin_pkg_fix/+merge/285458
<marcoceppi> stub: ping
<stub> marcoceppi: pong
<marcoceppi> stub: love the apt layer, but have some concerns symlinking the reactive directory into lib. I feel it'd be better to instead move the 4 or 5 methods you want to expose to other layers as a charms.apt module
<marcoceppi> which is the pattern a lot of other layers are starting to use
<stub> marcoceppi: That is a hack until I can get absolute imports working with charms.reactive (I've got a pull request up for that)
<marcoceppi> what do you mean?
<stub> https://github.com/juju-solutions/charms.reactive/pull/51
<stub> So if that gets rejected, yeah, I'll need to split things into $CHARM_DIR/reactive and $CHARM_DIR/lib
<stub> The branch fixes absolute imports, relative imports, and other import weirdness I've seen.
<marcoceppi> To me, it seems that reative/* files are basically main() methods for dispatching. i wouldn't want people importing or relying on them. whereas things in lib/ are the public apis I'm exporting
<stub> I've got reactive stuff as my charm specific stuff, and lib for non charm/non juju stuff.
<marcoceppi> right, but I think putting reactive stuff would be okay in lib/charms/ since this prefaced as a charm thing. I wouldn't want people importing my reactive/ files because they're basically just glue for managing states
<stub> But in any case, it would be nice to get imports in reactive and hooks/{reactive,relations} working as expected.
<marcoceppi> if cory_fu is around today I'll chat with him about it
<stub> Yes, it could go in there. In my case, reactive *isn't* just glue and is documented that way. But I can change that.
<marcoceppi> I'll chat with cory on goals and vision
<stub> It was all working fine for me until I switched to the standard hook stubs and lost $CHARM_DIR from my sys.path ;)
<stub> You want files containing handlers to be able to import other files containing handlers in any case, as sometimes they are triggered by state and sometimes you want to invoke them directly
<stub> marcoceppi: I'll still shuffle things around to $CHARM_DIR/lib/apt.py if that is where things like this should go - no point being unnecessarily different
<stub> marcoceppi: The leadership layer will have the same thing, and the coordinator layer (which I was blocking announcing until that pull request got commented on)
<marcoceppi> stub: I'd appreciate it, at least for the apt layer, as it'll make integration easier for some of the other layers. As for the others coordinator and leadership there may be a use case there for them to import reactive directly, I'll let cory_fu judge that from a library maintainer perspective
<stub> I've got gpg keys, json data files, and a few small Python helpers lurking in lib. Its a bit of a grab bag.
<stub> marcoceppi: oh, that was an issue. In particular for the apt layer. 'import apt' will get the system apt module. I'd need to stick it in charms/reactive/apt since this is specificly reactive framework stuff.
<marcoceppi> stub: we've been prefacing modules by placing them in lib/charms/
<stub> marcoceppi: at which point I'm stomping around in cory's namespace.
<marcoceppi> that way it's from charms import apt
<marcoceppi> that was the guidance I got from him originally
<stub> Right. Not as reactive specific as I'd like, but it will do in a pinch.
<stub> I guess reactive *is* the new charms
<marcoceppi> stub: maybe we should namespace further in the charms module to be like charms.layers or possibly a lib/reactive/ ?
<marcoceppi> something work discussing
<stub> that is what I did with the symlink hack ;)
<marcoceppi> yeah, but I think it went a little too far with the symlink to reactive dir
<marcoceppi> either way
<marcoceppi> I'll ping cory to chat about it either today or tomorrow
<stub> ta
<marcoceppi> I think he's still taking vacation after last week
<marcoceppi> will mail the list with the discussion
<stub> marcoceppi: Have you noticed the potential migration path for charmhelpers/core/hookenv.py yet? ;)
<marcoceppi> stub: I've been playing with a few ideas
<stub> marcoceppi: Was thinking if these layers and similar get accepted, the code they wrap could move directly into the layer.
<stub> Old functionality, new, consistent api.
<Shruthima> Hi Mbruzek, IBM installation manager is a prerequisite tool for many IBM products installation such as WAS, DB2, HTTP Server.  So, it doesn't have database relation or web interface. Can we charm without using any interface ? Could you please suggest me which interface i can use for IBM-Installation manager charm..?
<mbruzek> Hello Shruthima
<mbruzek> Shruthima: If IBM IM is a pre-requisite that tells me that is should be a layer that other charms could include.
<mbruzek> Shruthima: https://jujucharms.com/docs/devel/developer-layers
<Shruthima> ok thanks
<mbruzek> Shruthima: So to answer your question, if software X is a pre-requisite and has no known relations that is the perfect reason to make a layer. The trick is to make it useful so that ALL the other IBM charms can use that layer, and they would not have to have any IBM IM code in their charms.
<mbruzek> I wrote a tls layer for one charm, that is now used in 2 charms.  https://github.com/mbruzek/layer-tls
<mbruzek> Shruthima: Although that layer is quite different than IBM IM, you may be able to use that as an example
<Shruthima> yes ,i feel it right . will check on layers and try to do it is a layer.
<mbruzek> Shruthima: You _can_ write the layers in bash, but it may be easier to do in Python
<mbruzek> (less code, easier to maintain, etc)
<Shruthima> oh k thank you if any queries will check with you.
<mbruzek> Shruthima: Good luck!
<cory_fu> stub, marcoceppi: Sorry for the late reply.  Got a late start today because I'm sick following the summit.  I'm torn on the issue of importing within reactive/.  On the one hand, I like the idea of cleaning up the import code.  On the other, I'm leaning strongly against reactive handlers being imported directly for anything other than tests.
<cory_fu> I prefer to think of files under reactive/ as executables and thus anything that is common to multiple handler files should be factored up into a lib/charms/* location
<cory_fu> Maybe we could reserve a namespace specifically for helpers that a given layer provides?  We currently have lib/charms/layer.py used in the base layer for the layer.yaml options support, but maybe we could restructure that and reserve lib/charms/layer/<layer-name> for each layer to put its own helpers?  So, the apt layer would have helpers you would access via "import charms.layer.apt"
<marcoceppi> cory_fu: I think an explicit namespace for helpers that layers provide would be good
<marcoceppi> in this case, the layer.py would just be __init__.py with those few methods?
<marcoceppi> or possibly charms.layers.config for the base layer stuff?
<jeiworth> hi all
<jeiworth> quick question, i am using juju deployment in aws and have the landscape-client charm deployed and connected to my instances. my landscape i have standalone in another environment. first, i configured the landscape client from ssh cli and all was good, i later adapted the same configuration through the juju-gui of the charm and since then it apparently does't recognize reboots? i can still update packages through landscape and if i send t
<cory_fu> marcoceppi: Yeah, I'm fine w/ an __init__.py for the options helpers
<jeiworth> ...sooo any ideas welcome... :-)
<marcoceppi> jeiworth: I will take a look in a min!
<jeiworth> marcoceppi: thanks!
<bdx> Hows it going everyone? Does anyone know how to switch the source of a deployed charm?
<marcoceppi> bdx: the charm source?
<stokachu> http://paste.ubuntu.com/15004365/, anyone else seeing this issue with juju from master?
<stokachu> i see the Deploy function under the Service api type though
<bdx> marcoceppi: say you deploy local:trusty/nova-compute, following which you want to switch to cs:trusty/nova-compute
<marcoceppi> bdx: juju upgrade-charm --switch cs:trusty/nova-compute nova-compute
<bdx> marcoceppi: exactly
<bdx> thanks mon!
#juju 2016-02-10
<mhall119> marcoceppi: is there any way I could get a juju gui showing off the developer.ubuntu.com staging deployment?
<stub> marcoceppi, cory_fu : I think fixing imports is a separate issue, and should be done in any case. It makes things cleaner and less magic, and avoids hacks in situations that need it (eg. an @hook('upgrade-charm') wanting to invoke @when handlers directly). Python3 spent a lot of effort getting it working in the odd situations it didn't work in Py2, because occasionally you do need it and not having it is a pain in the bum.
<stub> marcoceppi, cory_fu : If the convention is to put APIs and callable or shared non-handlers in lib/charms, thats fine. I had things in reactive because I wasn't aware of the convention, and it felt quite nice having it in the same package.  It was handlers and methods and helpers called by handlers, and some of those methods also designed to be called by handlers in other layers.
<stub> (you call things directly rather than set state when you want a particular invocation order, have things invoked inside a context manager, interleave calling handlers with other code...)
<jamespage> apuimedo, hey - I will get to your MP's today - just need to sortout an issue in our QA cloud with liberty
<apuimedo> very well jamespage ;-)
<stub> Has anyone wired up a Juju charm integration test suite to travis-ci ?
<marcoceppi> stub: we did for a few layers irrc
<marcoceppi> but not the integration stuff
<marcoceppi> (like amulet)
<stub> lxc test runner needs a kick - failing to bootstrap due to port in use
<smartbit> Where can I find the recording of the first day at cfgmgmtcamp 2016, that includes Mark Shuttleworth's talk? I found it a couple of days ago, but lost it :-/
<marcoceppi> smartbit: I'm not sure we've published it yet? I'll see if I can find them
<marcoceppi> smartbit: we typically publish them here: https://www.youtube.com/jujucharms/videos but none have been uploaded yet
<marcoceppi> smartbit: I'll ping James who was doing the recordings
<smartbit> marcoceppi: Found it through http://eventifier.com/event/cfgmgmtcamp/videos : https://www.youtube.com/watch?v=sp_Re8Mx9xk&t=4095
<smartbit> Recordings of day 2 & 3 juju charner summit 2016: https://www.youtube.com/playlist?list=PLzSGDpUWtiotngRgVqpa8jeCBQ2CCjzfo
<marcoceppi> \o/
<icey> can I `juju add-machine` with an existing machine, in essence bring the manual provider stuff to a regular deployment?
<rick_h__> icey: I've not tried it, but I *think* so?
<icey> well then rick_h__ I'll let you know how it works :)
<icey> I need a very much not standard machine for a demo tomorrow so wanted to build the /machine/ by hand and then let juju have at it
<marcoceppi> icey: yes you can
<icey> glad to have it confirmed marcoceppi
<marcoceppi> juju machine add ssh:user@address
<marcoceppi> icey: ^^
<jamespage> apuimedo, neutron-api and charm-helpers fixes landed thankyou!
<apuimedo> I just got the email
<apuimedo> thank you ;-)
<apuimedo> I made some improvements to midonet-api today
<apuimedo> to prevent races when running in HA
<apuimedo> if you want an ha liberty bundle yaml let me know
<stub> marcoceppi: Just looking at the apt layer, I have an install_queued method that may be called directly that is also a handler called automatically. So if I split it, there is going to be some silly duplication.
<jamespage> apuimedo, bundles good
<jamespage> yes please
<apuimedo> very well
<jamespage> apuimedo, hows the polish on lint, unit and amulet tests going?
<apuimedo> lint should be fixed. unit tests are almost there
<apuimedo> amulet tests I basically have to remove the old ones
<apuimedo> the new one I added that can also install the enterprise edition, should be good
<stub> Yeah, lib/charms/apt.py ends up ok but reactive/apt.py is a bag of dead chickens and the bootstrap/setup method.
<shruthima> <mbruzek>: Hi,I will be developing IBM-IM as layer and I explored to make use of basic layer which is present in the "interfaces.juju.solution". and I am not sure about which interface that i can use it for IM from "interfaces.juju.solution",...? or do we need to develop IM interface seperately?? Can you please guide me on this?
<mbruzek> shruthima: Hello again!  From the information you gave me yesterday the IBM IM layer would be a charm layer not an interface layer (which is like a relation).  So your layers.yaml would import from the layer:basic.
<mbruzek> That will give you a starting point and you can create a charm layer in a repository such as Github or Launchapd.
<mbruzek> at this point you shouldn't need to worry about interfaces.juju.solutions, you can make a layer off-line on your own machine. Then when you run "charm build" it will go to interfaces.juju.solutions to pull the basic layer just once
<cory_fu> stub: While I enjoy your colorful metaphor, I'm not sure I understand why you're unhappy with the resulting reactive/apt.py?  Do you have it committed, perchance, that I might take a look?
<shruthima> <mbruzek>: oh ok thank you.
<cory_fu> A branch, perchance?  :)
<mbruzek> shruthima: Other people on the team know about layers and reactive, you can ask technical questions about layers and reactive here and others should be able to respond.
<mbruzek> here == #juju
<shruthima> okie :)
<jacekn> hello. I'm having problems understanding juju storage documentation: https://jujucharms.com/docs/1.25/storage I am looking for list of possible values for "type" parameter. I can see "type: block" in an exmaple but it's not documented anywyere
<jacekn> also "type: filesystem" seems undocumented
<jacekn> will something like this work at all? https://pastebin.canonical.com/149486/
<stub> cory_fu: https://git.launchpad.net/layer-apt/tree/?h=apipackage
<stub> cory_fu: Its not terrible, but it seems worse than what I started with.
<stokachu> marcoceppi: \p/
<stokachu> :(
<jacekn> hello. I have not heard anything regarding this bug I filed 2 weeks ago: https://bugs.launchpad.net/charms/+bug/1538573 can somebody tell me if it's on charmers's radar?
<mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1538573>
<cory_fu> stub: Do you really think that users will need to manually call install_queued or ensure_package_status instead of just relying on the state system to invoke them?
<cory_fu> marcoceppi: https://github.com/juju-solutions/layer-basic/pull/33  Thoughts?
<marcoceppi> cory_fu: weeeee LGTM
<cory_fu> It's untested, though.  ;)
<cory_fu> (Testing it now)
<jcastro> https://www.youtube.com/user/TheSmartbit
<jcastro> does anyone know who this is so I can credit them in the summary?
<marcoceppi> jcastro: it's probably smartbit
<jcastro> yeah I was looking for a real name
<stub> cory_fu: Sometimes. A simple linear @hook('install') might be preferable to half a dozen state handlers. I was also calling install_queued from inside a context manager at one point.
<cory_fu> stub: If that's the case, might it not be cleaner to just use the existing tools in charmhelpers?
<stub> cory_fu: I think the API is tidier in what I have, and if people like it, this would be where this bit of charmhelpers migrates too
<stub> So I would like to support both calling styles. There doesn't seem to be any reason to not support it.
<cory_fu> Fair enough
<cory_fu> btw, you could avoid doing explicit aliasing if you just import those functions directly
<stub> Which is certainly an argument in favour of sticking things in lib/charms
<stub> Oh, duh.
<cory_fu> I see what you mean, though, about the reactive file just ending up a place to add decorators to existing functions.  I'm not sure that I consider that a bad thing, though.
<stub> I can argue it both ways
<stub> I don't think these 'library' layers are typical.
<stub> I'll go with the split unless people have other use cases for putting an API in reactive.
<stub> But I still think it is worth doing the imports better ;)
<stub> Given the PEPs Python3 has implemented to get absolute and relative imports working in all other cases, it will be surprising and seem broken whenever people discover it doesn't work in built charms.
<cory_fu> Yeah, I don't disagree
<stub> When you say 'just a place to add decorators to existing functions' I have flash backs to Zope3 and ZCML ;) At least we don't need to use XML to decorate them :)
<wesleymason> Are there any good examples of a reactive charm using the nrpe interface? I can't seem to get the bloody thing to work.
<marcoceppi> wesleymason: not that I'm aware of - what are you having problems with?
<bolthole> question about juju and lxc. https://jujucharms.com/docs/1.24/troubleshooting-local-lxc doesnt mentoin how to view the actual lxc containers juju uses. doing "lxc list" doesnt show anything?
<marcoceppi> bolthole: is this lxc local provider or lxc in a deployed environment?
<marcoceppi> bolthole: also, if you're not using 1.24 of juju, I recommend going to the /stable/ version of the docs
<bolthole> juju with local environment
<bolthole> setup with juju bootstrap, etc.
<bolthole> as far as version of docs.. I go to what google pulls up. So you guys may have some tweaking to do for google search optimization ;->
<marcoceppi> bolthole: we've been trying to kill juju from crawling our versioned docs, so far that has been fruitless :\
<marcoceppi> bolthole: does `lxc-ls` work instead?
<bolthole> anyways, content is identical.
<marcoceppi> bolthole: sure, but just a point in general
<bolthole> lxc-ls shows nothing. (and isnt it just an alias for lxc list?)
<marcoceppi> bolthole: `lxc list` and lxc-* are two different versions of lxc. one, lxc list, is the new LXD frontend, and the other is traditional lxc
<marcoceppi> bolthole: do you have services deployed?
<marcoceppi> does `lxc-ls -a` show anything?
<marcoceppi> err `lxc-ls --fancy`
<bolthole> nope
<wesleymason> marcoceppi: effectively, deploy my charm, deploy nrpe, add-relation, I have a handler with a @when('local-monitors.available'), and it never fires.
<wesleymason> Same for nrpe-external-master if I used that instead
<marcoceppi> bolthole: what does you juju status output look like?
<marcoceppi> wesleymason: weird, that's not the intended design
 * marcoceppi checks interface
<marcoceppi> wesleymason: do you mean nrpe-external-master?
<wesleymason> marcoceppi: well using either, local-monitors for nrpe
<marcoceppi> wesleymason: we don't have a local-monitors interface in the interface listing
<marcoceppi> haha
<marcoceppi> I can't read
<marcoceppi> wesleymason: what does your metadata.yaml look like?
<bolthole> rebuilding it right now, so cant answer :-/  but if someone with workig juju local wants to post THEIR ouptput, that would be great :)  meanwhile, I am going to be afk for a while
<marcoceppi> bolthole: I've been running the alpha1 for a while and am using the new lxd provider - so much more awesome :)
<wesleymason> marcoceppi: https://github.com/1stvamp/juju-errbot/blob/master/metadata.yaml
<marcoceppi> wesleymason: that's the problem
<marcoceppi> wesleymason: you don't require local-monitors, you provide it. The interface library is a bit incomplete - it only has one side of the protocol implemented, the more common side, which is providing local-monitors
<marcoceppi> https://github.com/cmars/local-monitors-interface
<wesleymason> marcoceppi: aaaaaah nuts, yes, I see it now
<wesleymason> marcoceppi: been staring at that metadata for ages, blind
<marcoceppi> wesleymason: it's all good. we should consider adding a check at build time that "you provide X interface but interface library does not have provides.py"
<wesleymason> marcoceppi: good idea, I should also check my glasses prescription ð
<marcoceppi> wesleymason: https://github.com/juju/charm-tools/issues/105
<wesleymason> marcoceppi: ð
<wesleymason> marcoceppi: also interface working fine now ð
<marcoceppi> \o/
<wesleymason> Quite close to a fully working errbot charm now
<smartbit> jcastro: Bart Smith >smartbit :-)
<wesleymason> marcoceppi: out of interest, what's the generally accepted way to package/ship a charm built from a layer? Are people just checking into separate repos/branches, or shipping built tarballs somewhere etc?
<marcoceppi> wesleymason: people are starting to use the charm command to upload/publish them into the store
<marcoceppi> wesleymason: but that's still a private beta, otherwise, they're putting their layers into VCS they like then the charm artifcat that's built is just uploaded to bzr like charms have been in the past
#juju 2016-02-11
<jamespage> gnuoy, one minor comment on https://code.launchpad.net/~gnuoy/charms/trusty/keystone/add-dnsaas-svc/+merge/283922
<jcastro> lazypower|travel: I need your slides from the summit/FOSDEM when you get a chance
<lazyPower> jcastro - ack. lemme fish those up
<jcastro> <3
<jcastro> marcoceppi: aisrael: you guys need anything?
<marcoceppi> jcastro: ?
<jcastro> feel free to ask if you need some mwc prep thing done
<marcoceppi> huh?
<jcastro> you guys were working on an mwc demo no?
<marcoceppi> yeah, still are
<lovea> Hi. For a given charm deployed on a given Unit, how would I go about retrieving a list of all relation names for that unit? All the charm helpers such as relation-list seem to require a relation name to begin with. What I'm trying to do is run a script at the end of the upgrade-charm hook that looks for all existing relationships for that unit and somehow trigger a relationship-set so that the original relation config is reinstated.
<Ursinha> hi all, is it possible to get a unit out of the blocked state? similar to juju resolved for when unit is in error state
<Ursinha> it's missing relations to a unit that has already settled
<lazyPower> lovea : great question. i forget if its relation-list or relation-ids that spits out all the currently established relations
<lazyPower> but one of those commands will give you what you're looking for - or at least the first step to start probing/inspecting
<Ursinha> and I've been waiting for ~20 mins or so, it's not going anywhere
<lazyPower> Ursinha - can you give me a little more context?
<Ursinha> lazyPower: I'm deploying openstack and ceph-radosgw is blocked missing relations on ceph-moin
<Ursinha> *ceph-mon
<lovea> lazyPower: definitely not relation-ids so I'll try relation-list
<lazyPower> Ursinha - blocked status messages, if not cleared properly in the charm code - can be misleading. status messages are arbitrary notices from the charm author, and its entirely likely that a charm may be operating nominally but the status message was never cleared giving it the apperance of still being in a blocked state
<Ursinha> but ceph-mon is already ready and idle
<lazyPower> Ursinha: and when you juju status ceph-mon, do you see the relation established in the output? (specifically when using --format=yaml to juju status ceph-mon)
<Ursinha> lazyPower: juju logs show in ceph-radosgw that relations are missing
<Ursinha> lazyPower: let me try that specifically
<lazyPower> icey - ping if you're around :)
<icey> pong lazyPower
<lazyPower> icey - are you familiar with the ceph-radosgw charm?
<icey> little bit, reading the conversation lazyPower
<lazyPower> <3 this is why you're one of my favorites
<icey> Ursinha: just to confirm, you're using my ceph-mon charm that you're using the ceph-mon in my personal namespace?
<Ursinha> lazyPower: hm no. it's not showing in the relations list -- but then I tried to add it and it failed saying the relation already existed, I tried to remove it and it said nothing, but won't allow me add a new one
<icey> (as far as I know, there's nothing that should have changed with the radosgw relation)
<Ursinha> haha yes, hi icey :)
<Ursinha> I think this might be a bug in the charm, but I wanted to know if it would be possible to do something about the "blocked" state in any case
<lovea> lazyPower: relation-list also expects a relation name to be passed. I can see a way of starting at the top of the tree and discovering relation names, then relation ids, then acting on the ids.
<lazyPower> lovea: that sounds right
<icey> Ursinha: when I add blocked states, it's always resolvable by the user ;-) Sometimes by adding a required relation, sometimes it needs to be retried; sadly, I didn't add the blocked to the radosgs one so I'm not sure yet
<lovea> lazyPower: typo, I can't see a way!
<lovea> lazyPower: Might just have to hardcode the charm relation names for now.
<icey> Ursinha: the only thing that's changed with the radosgw stuff recently is adding in a broker, I can dig in in a bit to see if I can reproduce the error
<icey> radosgw stuff in ceph/ceph-mon
<Ursinha> icey: hmm right, I ran a resolved --retry but it seems to work only with units in error state
<Ursinha> icey: I found this bug: https://bugs.launchpad.net/charms/+source/ceph-radosgw/+bug/1517940
<mup> Bug #1517940: workload-status is wrong <openstack> <sts> <ceph-radosgw (Juju Charms Collection):New> <https://launchpad.net/bugs/1517940>
<icey> yeah Ursinha, how to resolved blocked does depend ;-) I try to make it reasonable
<lazyPower> lovea: as the charm author, you can reasonably tell what relations are in the assembled charm...
<lazyPower> lovea: i'll bring this up at our charmer office hours though, so tune in :)
<Ursinha> icey: so it's basically reading the message, hoping the developer was reasonable and try to do something to fix that? :)
<icey> Ursinha: Ed's report comes up before this last change so I'll definitely have to dig
<lovea> lazyPower: Yeah. That's what I figured. Thanks for listening.
<icey> Ursinha: yeah, remember: state and messages are freeform so you have to hope the author did the right thing
<lazyPower> lovea np, sorry i didn't have a better answer, but what you're asking is going to become a more requested feature - as interface layers are really going to accellerate the consumption of connectivity
<Ursinha> icey: will keep that in mind, thanks for the info
<lazyPower> pre-fab interfaces make it trivial
<icey> Ursinha: I'll try to take a look at reproducing this today, probably won't get to it until later
<Ursinha> icey: that is fine, it's not happening every time so I'm not blocked, but as I just hit it I wanted to +1 the issue
<Ursinha> icey: thank you :)
<icey> yeah, the transient failure makes it much harder to repro Ursinha
<lovea> lazyPower: Indeed. Connected subordinate charms can add up too. Really liking Juju though so many thanks.
<apuimedo> jamespage: ping
<jamespage> apuimedo, hello
<lazyPower> np lovea :) love that feedback!
<apuimedo> is it possible to enable amulet tests for merge proposals run on my charms?
<apuimedo> or will that only be once they are promulgated?
<apuimedo> (I can see why that would be a whitelist thing)
<apuimedo> lazyPower: do you have swarm charmed?
<lazyPower> apuimedo - i have a layer for it, its not "official" as i've run into a roadblock with the TLS generation that I hiaven't gotten back to
<lazyPower> but its well on its way, let me fish you up a link to the layer
<apuimedo> cool
<lazyPower> https://github.com/chuckbutler/layer-swarm
<apuimedo> some people want to try kuryr with swarm and I was thinking I could just make a charm
<lazyPower> yeah buddy!
<lazyPower> Dude, let me work with you on that
<lazyPower> like, dont block on me, but i def want to be a fly on the wall while you work with these layer(s), and get some solid feedback on how i've got this layed out
<apuimedo> I have to read up on the layers first
<lazyPower> ping me if you need help :)
<apuimedo> cause I didn't use them yet
<apuimedo> but I'll probably get to that at the end of next week
<apuimedo> (weekend)
<lazyPower> if you've got time next week i can reasonably pencil you in for a quick charm school to get you up to speed with layers
<lazyPower> i'll have to clear it with my workload first, but i'm 80% certain that an hour is expendable for this
<apuimedo> lazyPower: I'll also want to give a look at the kubernetes work you have
<apuimedo> but that one you have completely ready, right?
<lazyPower> Mostly, there's still some work to be done to make it "enterprise grade" but you get a functional/scaleable k8s cluster if you're building from tip of our layers
<apuimedo> I want to use it to give devs a kubernetes environment o develop kuryr integration with
<apuimedo> so we'll tear kube-proxy down
<apuimedo> and flannel too
<lazyPower> love it, thats a one liner fix to remove that integration
<lazyPower> just gank the layer: flannel directive from layer.yaml, rebuild and you've got a vanilla k8s setup according to google's deployment guide
<apuimedo> cool
<lazyPower> you'll also want to adjust the pod/service definitions in the layer
<lazyPower> but that should be it
<apuimedo> which series is it?
<lazyPower> trusty
<lazyPower> we're currently piloting a xenial deployment, i'll know more about that by end of day today
<apuimedo> cool
<wesleymason> So say I want to include and install a wheel of a library in my built charm, is there a way of defining that in my layer and having charm build include it, or do I have to include it in my layer?
<jamespage> dosaboy, hey does https://code.launchpad.net/~hopem/charm-helpers/lp1518975/+merge/285734
<jamespage> mean that you can provide the key after the | in the openstack-origin?
<jamespage> wesleymason, yes - just add it to a wheelhouse.txt in your charm/layer
<jamespage> layer-basic does this already
<wesleymason> jamespage: is that a pip requirements file?
<jamespage> same format
<wesleymason> ta
<jamespage> dosaboy, the key might be better passed as an additional config option ?
<dosaboy> jamespage: i've tried it this way and it works quite nicely if you use the yaml multiline syntax
<dosaboy> no need for an extra config option
<jamespage> dosaboy, pastebin?
<dosaboy> 1 sec
<dosaboy> jamespage: http://paste.ubuntu.com/15016527/
<jamespage> dosaboy, ok - lgtm - +1 from gnuoy as well
<dosaboy> \o/
<dosaboy> jamespage: shall i merge the os charms as well?
<dosaboy> i've already synced them
<jamespage> onesec
<jamespage> merging ch now
<dosaboy> they're a clean sync ftr, no additions
<jamespage> dosaboy, I was +1 on approach - but I think we need to preserve import_key as a function
<marcoceppi> wesleymason: is it a wheel you have built?
<marcoceppi> wesleymason: or one in pypi?
<jamespage> its part of the api, so renaming is not so great imho
<wesleymason> marcoceppi: will be both
<wesleymason> one I have built *and* it's on pypi ð
<jamespage> dosaboy, does that make sense - import_pgp_key could just use the existing function... rather than subsuming it
<dosaboy> jamespage: sorry yes, i'll switch it back
<dosaboy> jamespage: gimme few mins to get it all synced
<marcoceppi> wesleymason: you put pypi deps in wheelhouse.txt as you would a requirements.txt file
<marcoceppi> wesleymason: and the rest you should create a wheelhouse directory and put a source wheelhoues in there
<marcoceppi> wesleymason: and as I'm typing this I realize this should be documented
<wesleymason> :D
<dosaboy> jamespage: charm-helpers patch ready, charms on their way
<dosaboy> jamespage: done.
<jamespage> dosaboy, charm-helpers landed - please resync charms and let osci do it stuff
<jamespage> dosaboy, +1 on landing those pending lint, unit and amulet test confirmation is OK
<dosaboy> jamespage: charms are all synced
<jamespage> dosaboy, gooh-oh
<bolthole> Hey juju guys! I'm back, with followup questions to my juju-local + lxc debugging :)
<bolthole> I have now got a working local environment, and I notice the following oddity:
<bolthole> "sudo lxc list" shows nothing. But "sudo lxc-ls --fancy" shows stuff.  Um... wahts up with that?  (note: I'm a complete lxc noob)
<bolthole> i m mentioining this, becuase there is nothing about this stuff on https://jujucharms.com/docs/stable/troubleshooting-local-lxc
<bolthole> and on a different subject, my logs are getting spammed with:
<bolthole> juju.worker.diskmanager lsblk.go:116 error checking if "fd0" is in use: open /dev/fd0: no such device or address
<bolthole> I googled that, and found that allegedly restarting the whole machine shoudl clear it up. but it didnt.
<lazyPower> bolthole - the log spam is a bug and should be filed http://bugs.launchpad.net/juju-core/+filebug
<lazyPower> bolthole - regarding lxc-ls --fancy showing data where lxc-ls is not, thats... odd....
<lazyPower> i'm not sure what would cause that
<bolthole> correction: lcs-ls and lcs-ls --fancy both work. its "lcs list" that does not.
<bolthole> I just read why taht is. but I think that info needs to be on the juju docs page mentioned above.
<lazyPower> bolthole - https://github.com/juju/docs/issues - a bug would be <3
<bolthole> awwright i filed a bug.   wierd that it would be in github not launchpad.
<bolthole> lazypower: taht was a bug for the dogs. fur the /dev/fd0 thing.. that is already a bug somewhere.
<lazyPower> bolthole - ack. Thanks for getting that filed.
<lazyPower> bolthole - regarding the log bug, 10/4 - those seem to get lower priority in the -dev queue, but with it filed we should get that sorted soonish :)
<bolthole> https://bugs.launchpad.net/juju-core/+bug/1509747
<mup> Bug #1509747: Intermittent lxc failures on wily, juju-template-restart.service race condition <cloud-installer> <lxc> <wily> <juju-core:Invalid by cherylj> <systemd (Ubuntu):Invalid by pitti> <https://launchpad.net/bugs/1509747>
<bolthole> since oct
<bolthole> wait how is it marked invalid??? WTH
<cherylj> bolthole: is that the right one?  shows that's a bug I opened
<bolthole> yeah you did.
<bolthole> i'm hitting it everyh time
<bolthole> in azure, AND in a regular ubuntu-on-metal install
<bolthole> ubuntu 15.10
<cherylj> bolthole: attach the /var/lib/juju/containers/<container name>/* to the bug and I can re open it
<bolthole> alternatively... rather than going through extended bug analysis... maybe you can just stop Checking For Floppy Disks, Seeing as how it is 2010+ now??? :)
<bolthole> cherylj: waitaminit.. I just noticed it's only whining about machine-0.
<bolthole> which, funily enough, isnt present in that container directory
<cherylj> bolthole: bug #1509747 was not opened for /dev/fd0 messages
<mup> Bug #1509747: Intermittent lxc failures on wily, juju-template-restart.service race condition <cloud-installer> <lxc> <wily> <juju-core:Invalid by cherylj> <systemd (Ubuntu):Invalid by pitti> <https://launchpad.net/bugs/1509747>
<bolthole> symptoms the same though.
<bolthole> "/var/log/juju-ubuntu-local/all-machines.log just spits out a series of  machine-0: 2015-10-28 08:27:55 ERROR juju.worker.diskmanager lsblk.go:116 error checking if "fd0" is in use: open /dev/fd0: no such device or address  but doesn't otherwise seem to do anything."
<bolthole> difference being, after a very long time... my install of juju actually stabilitzed and I could use it.
<bolthole> but its still spamming errrors
<bolthole> waitanminit... now it's spaming a different set of errors :-/
<bolthole> diskmanager": cannot list block devices: lsblk failed: fork/exec /bin/lsblk: cannot allocate memory
<bolthole> Which is odd, since the machine supposedly has 128 GIGABYTES of memory and is doing nothing else.
<bolthole> but maybe the virtual machine has too little allocated to it?
<bolthole> oops sorry thats a different machine. wrong window. sigh.
<bolthole> thje 128gig azure VM is still spamming "checking if "fd0" is in use:" errors.
<bolthole> Which seems a pretty clera error, since
<bolthole> open /dev/fd0: no such device or address
<bolthole> If there's no dev, you would think it should shut up and stop trhying to check the device.
<bolthole> i'l open a new bug
<bolthole> https://bugs.launchpad.net/juju-core/+bug/1544724
<mup> Bug #1544724: repeatedly checks /dev/fd0 when it doesnt even exist <juju-core:New> <https://launchpad.net/bugs/1544724>
<apuimedo> lazyPower: do you know if there is a way to specify the security group on openstack juju environments?
<lazyPower> I do not... but ddellav or beisner may know
<beisner> apuimedo, afaik, juju manages creation and cleanup of secgroups and their naming, and there looks to be only one knob to turn.  https://jujucharms.com/docs/1.25/config-openstack
<apuimedo> I only saw "use-default"
<apuimedo> or something like that
<beisner> apuimedo, right that's all i see too.
<apuimedo> it's a bit of a bummer, for some reason the open ports doesn't trigger anything on the security groups
<apuimedo> so my amulet tests fail :/
<lazyPower> waiiiiiittttt
<beisner> hm
<lazyPower> open-port should most def be poking at those sec groups
<beisner> right
<beisner> seems like that'd be a bug
<lazyPower> which version of juju is this apuimedo?
<apuimedo> 1.25
<apuimedo> 1.25.0 to be precise
<lazyPower> apuimedo - is it at all possible its racing? and the port is getting open in the sec group, but later than the test is expecting?
<apuimedo> nope
<lazyPower> oi
<apuimedo> I leave the instances on
<apuimedo> and even now
<apuimedo> 15 minutes later
<lazyPower> yeah it may be a regression then, and thats odd as we have test coverage around that i'm pretty sure
<apuimedo> no entry for 8080
<apuimedo> I guess I'll have to disturb my maas environment for amulet tests :(
<apuimedo> lazyPower: beisner: does the aws provider work well?
<marcoceppi> apuimedo: it should
<apuimedo> ok
<apuimedo> thanks marcoceppi
#juju 2016-02-12
<catbus1> Hi, I am using juju-deployer to deploy workload in lxc containers. I have containers all created and started in RUNNING state, but some of them got IP addresses, some don't. For those that don't have IP addresses, there is no corresponding /var/log/juju/machine-#-lxc-#.log.
<catbus1> How do I find out why those containers didn't get an IP?
<catbus1> http://pastebin.ubuntu.com/15020637/
<catbus1> There is enough IP address in the DHCP pool.
<apuimedo> jamespage: the three charms have been updated
<apuimedo> jamespage: I put https://bugs.launchpad.net/charms/+bug/1453678 back to new so that you see the new message I wrote
<mup> Bug #1453678: New charms: midonet-host-agent, midonet-agnet, midonet-api <Juju Charms Collection:New> <https://launchpad.net/bugs/1453678>
<apuimedo> I couldn't assign it to you somehow
<apuimedo> I'll not be reachable tomorrow, public holiday
<jamespage> dosaboy, your MP's need to be synced from lp:charm-helpers for the source configuration stuff (just spotted that)
<dosaboy> jamespage: they are already synced
<dosaboy> jamespage: in fact i just re-synced and there was still no diff
<jamespage> dosaboy:
<jamespage> -branch: lp:charm-helpers
<jamespage> 6	+branch: lp:~hopem/charm-helpers/lp1518975
<dosaboy> jamespage: hmm that must have crept through, lemme check
<dosaboy> jamespage: ah its just the cinder MP, i'll fix that one
<jamespage> dosaboy, hah - that was the first I looked at :-)
<jamespage> dosaboy, if they are passing please merge away - I have a few xenial fixes to follow up with once you have that landed
<dosaboy> jamespage: sure, atcually there are a couple of amulet failures, heat and nova-compute
<dosaboy> jamespage: heat is a test that was previously broken but i'm gonna see if i can fix
<dosaboy> nova-compute not sure yet
<jamespage> dosaboy, I can re-run if need be
<dosaboy> jamespage:  k i'll ping when ready
<gnuoy> dosaboy, jamespage, got any time for https://code.launchpad.net/~gnuoy/charm-helpers/keystone-v3-support/+merge/285689 ?
<dosaboy> jamespage: gonna merge all but heat until it passes since the rest are +1 now
<dosaboy> gnuoy: maybe soon...
<gnuoy> ta
<jamespage> gnuoy, maybe in a bit - on a half day today and wading through midonet reviews atm
<gnuoy> ok np
<wesleymason> Well here's an odd one
<wesleymason> it seems every time I've invoked charm build since the last time I rm -rf'd the built charm, I've ended up with an embedded build inside the last one
<wesleymason> so I have: trusty/errbot/trusty/errbot/trusty/errbot/trusty/errbot/trusty/errbot/
<wesleymason> 5 levels deep
<wesleymason> bet if I call charm build again I end up witha  6th
<wesleymason> That can't be expected behaviour, right?
<wesleymason> I'm guessing it's not blacklisting the trusty and deps dirs when building in "." (as opposed to a JUJU_REPOSITORY)
<wesleymason> https://github.com/juju/charm-tools/issues/106
<jamespage> thedac, thanks for the reviews - I've landed swift-storage, nova-* are updated and I've added neutron-gateway which I missed befor
<jamespage> I've disable mitaka tests for now; we can re-enable once all of those land
<icey> Ursinha: do you by chance have a bundle of what you deployed yesterday that ran into #1517940 ?
<mup> Bug #1517940: workload-status is wrong <landscape> <openstack> <sts> <ceph-radosgw (Juju Charms Collection):New> <https://launchpad.net/bugs/1517940>
<Ursinha> icey: let me check
<icey> Ursinha: I just had it hang for a while at blocked: mon relation missing, and then start executing
<Ursinha> icey: so... we don't do bundles
<icey> thought that may be the case, no worries
<icey> do you have any special config on the mon or radosgw side?
<icey> (feel free to pastebin them and PM me)
<icey> Ursinha:
<Ursinha> icey: done :)
<icey> thanks Ursinha, will keep digging
<Ursinha> icey: thanks for looking into that
<Ursinha> icey: out of curiosity, for how long you waited until the relations settled?
<icey> 5 minutes? on AWS
<icey> will try to test on OpenStack in a bit
<Ursinha> ah, right,
<sparkiegeek> icey: the unit should transition out of blocked as *soon* as it sees the relation is established - it should go into maintenance state when it's busy doing things but no longer requires action from the user
<icey> sparkiegeek: agreed, and that's what I saw happen
<sparkiegeek> 5m is way too long for the charm to spend /noticing/ that it has the relation (even if it has a bunch of stuff to do before all the work for that relation is still ongoing)
<icey> but it did take a few minutes between adding the relation and the state changing / hook running
<icey> sparkiegeek: I'm curious about how long juju took to trigger the hook execution
<icey> I've seen hook execution take a long time to start when juju is fairly heavily loaded before
<icey> and not just with the radosgw charm sparkiegeek
<icey> either way, need to do mroe digging though
 * sparkiegeek nods
<sparkiegeek> FWIW we've only seen this with ceph-mon charm, none of the others
<sparkiegeek> hence the belief it's a charm bug :)
<icey> I've seen it with other charm relations, just not for /that/ long
<sparkiegeek> sorry, I mean with radosgw charm relation to ceph-mon
<jcastro> http://www.jorgecastro.org/2016/02/12/super-fast-local-workloads-with-juju/
<jcastro> jamespage: ^^^
<jcastro> I set it all up yesterday
<rick_h__> jcastro: <3
<jamespage> jcastro, nice...
<rick_h__> jcastro: safe to share out or still in editing?
<jcastro> share like the wind
<stub> icey, sparkiegeek: Was the hook you expected to be triggered actually triggered, or was it the update-status hook? If something was messed up, such as a hook missing executable permissions, the update-status hook kicks in every five minutes or so and can hide the problem.
<icey> stub: the hook is a relation joined hook
<icey> and the hook usualyl runs fine
<icey> occaisonally, it seems like the hook doesn't run (or just takes forever to run)
<icey> well, it's a relation-changed and relation-joined so it should have been run
<stub> Hooks running on subordinates block other hooks running on the same unit, which might apply here
<icey> both of the sides of the relation are primary charms
<icey> no subordinates deployed
<stub> I think juju run might block hooks too
<icey> no juju run
<icey> juju deploy x3
<icey> juju add-relation(s)
<icey> one of the relations never seems to  get related
<icey> Ursinha: correct me if I'm wrong
<Ursinha> icey: it's like the relation exists but isn't relating :)
<Ursinha> I have to remove it and readd
<icey> jcastro: already top 10 on HN
<jose> freyes: ping
<freyes> jose, pong
<jose> freyes: hey! I have a quick question on a merge you proposed
<jose> have a couple mins to figure this out?
<freyes> jose, sure, which one?
<jose> freyes: https://code.launchpad.net/~freyes/charms/trusty/memcached/lp1525026/+merge/281254
<jose> there's a test in there, test 20. it checks for the 'public-address' on the instance and makes sure it's the same on the memcached.conf file, however, could it work with the private address instead of the public one as well?
<freyes> jose, right, that is failing for AWS, because the replication is configured over the private address, and I changed the test to use private-address, the problem with it is that the sentry doesn't have 'private-address'
<jose> I thought it did...
<freyes> I have to dig in it yet, not sure why that happens
<freyes> yup, I thought the same
<jose> marcoceppi: do sentries in amulet have private addresses? e.g. AWS with public-address and private-address on config-get
<jose> freyes: the other option would be to have it as a `juju-run` and get it from there
<freyes> jose, yes, not happy with that approach, but could be enough to get it passing
<sparkiegeek> icey: Ursinha: stub: there /are/ subordinates in play here
<thedac> jamespage: wrt, xenial MPs. great. I'll shepherd any remaining ones in today.
<rick_h__> juju on hackernews ftw #4 atm make sure to vote and keep an eye out in case of questions and such https://news.ycombinator.com/news
<marcoceppi> rick_h__: you mean #2 :)
<rick_h__> marcoceppi: it's moving up and up wheeee
<sparkiegeek> I need to find where jcastro keeps his bug tracker
<sparkiegeek> jcastro: s/ubuntu-trust/ubuntu-trusty/ in the lxc launch command
<marcoceppi> sparkiegeek: he's at an appointment, atm but his bug tracker is overflowing - best to just ping him directly ;)
<marcoceppi> rick_h__: how do i make a charm I published public?
<marcoceppi> what's the change-perms encantation?
<rick_h__> marcoceppi: charm2 change-perm cs:xxxx --add-read=everyone ?
<rick_h__> atm I think
<marcoceppi> thta's it
<marcoceppi> rick_h__: all I have to do now is create an account in juju with the username "everyone" ;) ;)
<rick_h__> marcoceppi: pretty sure it's not allowed
<rick_h__> marcoceppi: oh you mean juju...but you have to charm login so it's not the same
<marcoceppi> rick_h__: everyone worked, thanks! I love the instant gratification of stuff landing in the sore
<marcoceppi> stor
<marcoceppi> e
<rick_h__> marcoceppi: instant gratification is most gratifying
 * rick_h__ runs for lunchables
<cory_fu> marcoceppi: Did you by chance get the juju-deployer apt package updated for the plebs like me that occasionally still use it?  :)
<marcoceppi> cory_fu: no, not yet
<marcoceppi> I've had to run errands all day
<bdx> icey, jamespage: I'm getting "No block devices detected using current configuration" Message for one of my ceph-osd nodes  .... I'm wondering if there is some insight you can give on this before I jump in .... you can see my devices all exist -> http://paste.ubuntu.com/15025182/
<cory_fu> marcoceppi: No worries.  Just keeping it on your radar.  :)
<icey> bdx what's your config look like for osd-devices?
<cory_fu> marcoceppi: btw, I'm going to be spending time today on these issues for the charm-tools deadline: https://github.com/juju/charm-tools/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0
<icey> bdx: can look after lunch, solid meetings around lunchtime so be back soon
<cory_fu> Let me know if you disagree with any of those being required for 2.0
<bdx> icey: http://paste.ubuntu.com/15025196/
<marcoceppi> cory_fu: LGTM make sure to target the road-to-2.0 branch for these
<cory_fu> Will do, thanks
<icey> bdx: any chance that it has settled and found the devices now?
<bdx> icey: https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1545079
<mup> Bug #1545079: "No block devices detected using current configuration" <ceph-osd (Juju Charms Collection):New> <https://launchpad.net/bugs/1545079>
<icey> bdx: the charm won't get around to adding storage until it can confirm that the cluster is bootstrapped, which requires the osd be able to talk to the mon quorum
<bdx> icey: it can talk to the mons just fine .... it just didn't have dhcp assigned to its repl/cluster interface
<bdx> icey: now that it has an ip on the cluster network ... it deploys.
<icey> yeah bdx, if it can't talk on its cluster network, it won't bootstrap :-P
<icey> glad it works now!
<bdx> icey: yeah ... totally .. didn't pay attention to the node interfaces getting wiped clean at commissioning. thanks!
<jcastro> sparkiegeek: I fixed that, my CDN might or might not be caught up wherever you are
<cory_fu> lazyPower: Do you have a copy of the stacktrace for https://github.com/juju/charm-tools/issues/102
<lazyPower> cory_fu not off hand but i can make one really quick, gimme a sec to fire up a container and pip install charm-tools without git installed
<cory_fu> Thanks
<cory_fu> lazyPower: Nevermind, I reproduced it
<lazyPower> cory_fu - awesome, sorry i got distracted
<cory_fu> lazyPower: No worries.  Your explanation on how to reproduce it clued me in
<cory_fu> marcoceppi: The road-to-2.0 branch is behind master by several commits.  Any objection to me bringing it up to date before I start creating MPs against it?
<marcoceppi> cory_fu: not at all
<cory_fu> marcoceppi: It won't ff merge.  Do you prefer a rebase or non-ff merge?
<marcoceppi> cory_fu: rebase, tbh
<marcoceppi> since it's a feature branch
<cory_fu> Ok, that's my preference as well, but they were your commits that will be rewritten
<admcleod-> is there a document which lists environment variables that should be set for juju2.0?
<jcastro> 10 minute warning until office hours!
<jcastro> jose: around?
<marcoceppi> jcastro: you setting up the hangout?
<marcoceppi> cory_fu: I seem to agree that charms.layer should be split to it's own library at this point
<jcastro> https://plus.google.com/hangouts/_/j74qty46pdo6how2xcj4j573aea
<jcastro> marcoceppi: ^^^
<jcastro> anyone who wants to join the office hours hangout is welcome to do so, see the above link
<lazyPower> urgh, i want to attend but the hangout plugin keeps crashing here :( i guess i'll just listen
<marcoceppi> o/
<lazyPower> man! Even hacking around on maas 1.9, nicely done Gilbert!
<MemeTeam6> who /tpg/ here
<marcoceppi> https://lists.ubuntu.com/archives/juju/2016-February/006447.html
<arosales> https://lists.ubuntu.com/archives/juju/2016-February/006447.html
<lazyPower> MemeTeam6 - thinkpad user?
<marcoceppi> ppa:juju/devel
<lazyPower> wooo multi-model-stateserver!
 * lazyPower throws confetti
<kwmonroe> woohooo juju deploy bundle!
<lazyPower> argh i said it again... i mean multi-model-controller
<lazyPower> All these awesome features in succession, i wonder if the watchers really get how much progress this really is we just showed in under 60 seconds
<arosales> https://lists.ubuntu.com/archives/juju/2016-February/006498.html  -- juju release notes
<lazyPower> marcoceppi - charms.ansible landed during the summit, which is a supporting extension of michael nelsons work
<lazyPower> https://github.com/chuckbutler/charms.ansible - readme and proper documentation forthcoming in ~ a week
<lazyPower> it'll move to juju-solutions after its documented
<lazyPower> and put under CI
 * lazyPower fanfares @ NS950 and their doc contributions
<arosales> "ERROR the name of the model must be specified"
<arosales> on juju bootstrap
<rick_h__> arosales: have to give the controller a name on bootstrap
<rick_h__> arosales: because now you can bootstrap several times, each with their own name e.g. staging and production
<marcoceppi> arosales: juju bootstrap -m "environment-name"
<rick_h__> arosales: the error should be 'controller name' vs 'model name'
<rick_h__> which is interesting, will have to talk to wallyworld about that one.
<arosales> -m was the key there
<rick_h__> oh hmm, shouldn't be behind a flag according to the spec
<arosales> note the juju docs for "juju help bootstrap" does not state the -m is mandatory
 * rick_h__ goes and double checks
<arosales> so "juju bootstrap -m aws-east1" is what worked for me
<arosales> given my environment.yaml file in ~/.local/share/juju and has a aws-east1 stanza
<rick_h__> arosales: ok yea, that'll turn ingo "juju bootstrap $controllername $credentialname"
<rick_h__> arosales: but looks like it's not there yet
<arosales> rick_h__: ack, juju help bootstrap just told me "usage: juju bootstrap [options]" which I am sure is just a case of the alpha help commands not being updated
<rick_h__> arosales: yea
 * arosales finally bootstrapping though after moving my environments.yaml file and appending -m <env-name> on bootstrap
<arosales> thanks rick_h__ and marcoceppi
<lazyPower> arosales - we both hit that today :D rick_h__ showed me up by sneaking out -alpha2 with a full announcement while i wasn't watching
<lazyPower> awesome office hours gents!
<arosales> +1
 * arosales learned a lot
<lazyPower> arosales - know what my favorite part was?
<arosales> lazyPower: mbruzek orange shirt?
<lazyPower> arosales - thats a close second -  jujusolutions/charmbox:devel already had *everything* i needed :P  simply update an alias and we're ready to goooooooo
<rick_h__> lazyPower: is the recording up?
<lazyPower> rick_h__ if you hit ubuntuonair.com its there and ready for you
 * lazyPower is currently watching a resources demo
 * lazyPower is pretty excited about this!
<arosales> lazyPower: nice
 * rick_h__ loads it up
<arosales> man jorge I should have mentioned how folks can try xenial in AWS
 * arosales to send that to the list
<arosales> xenial with juju that is.
<lazyPower> arosales oh yeah!! do that!
<arosales> will do
<lazyPower> i'll send you a pizza :D
<jcastro> omg
<jcastro> on the flipside of the create-model being fast
<jcastro> destroy-model is instant
<arosales> mmmm pizzza :-)  lazyPower
<arosales> all meat please
<jrwren> do pizza bribes work well here, I'll start using them often if they do.  ;]
<marcoceppi> rick_h__: does the gui team know of the alpha2 login issues?
<cloudguru_> Need to know who is working on a layer-docker charm for openVswitch as an SDN layer for MWC
<jrwren> marcoceppi: yes, we know. we cry about it every night. I'm filling a bucket with tears as i write this.
<marcoceppi> cloudguru_: you should ping lazyPower
<cloudguru_> thx.  already done.
<lazyPower> cloudguru_ o/ heyo
<lazyPower> i'm still here
<rick_h__> jrwren: this is that the gui isn't 2.0 api ready? Or something else?
<jrwren> rick_h__: it is that exactly. Better not be something else.
<rick_h__> jrwren: k
<lazyPower> cloudguru_ i'm really out/offline today, but i stuck around to do office hours. anything specific I can answer? is this coming up to crunch time and causing an issue?
<rick_h__> jrwren: yea, just making sure it's not a different bug/etc. I'd not heard of anything there.
<cloudguru_> @lazyPower .. all good.  We can the scripts but docker charm for OVS is preferred
<lazyPower> cloudguru_ that initial stab at the layer for OVS was basically an encapsulation of that script
<lazyPower> should be able to juju deploy the built charm --to 0 and bypass the entirety of running the script
<cloudguru_> re: lxc lBR clusters for openstack .. you guys are right.  I'm pretty such this is how the nebula appliance worked under the covers on a single (huge) appliance.
<lazyPower> as its delivered on furst run
<lazyPower> *first run
<cloudguru_> Nice !!!
<lazyPower> i need to step out, i have somewhere to be in 45 minutes across pittsburgh, but i left you my # in an im cloudguru_  - feel free to call
<lazyPower> sorry i'm pressed for time :\
<cloudguru_> LXC OpenStack on full killer .. pretty much OpenStack Magnum
<rick_h__> lol at marcoceppi wanting to make sure "no one wants to look at my face"
<jose> jcastro: just got your ping, was stuck at work with no internet
<jcastro> no worries, I was just editing ubuntuonair
<cory_fu> marcoceppi: Did you see I updated https://github.com/juju/charm-tools/pull/108 ?
<jcastro> ok with a new machine I need to test it, any hardcore bundles that can exercise my system?
<rick_h__> jcastro: I'd think kwmonroe's would be best
<marcoceppi> cory_fu: thanks!
<marcoceppi> jcastro: juju deploy -n 1000 cs:~jorge/trusty/boinc
<jcastro> rick_h__: that didn't really break a sweat
<rick_h__> jcastro: add moar units?
<jcastro> I suppose I could actually run something in hadoop
<rick_h__> jcastro: was that the realtime-syslog-analytics?
<jcastro> yeah
<marcoceppi> hey cory_fu
<cory_fu> Yes?
<marcoceppi> https://github.com/juju/charm-tools/issues/115 should we just create a `$JUJU_REPOSITORY/build/<charm_name>` instead? or just put <charm_name> in JUJU_REPOSITORY?
<rick_h__> marcoceppi: cory_fu just a heads up on the series in metadata. The UI team was working on updating the charmstore to support that and the jujucharms.com website
<rick_h__> marcoceppi: cory_fu and I'm not 100% sure where that's left off (e.g. might be comitted but not yet deployed)
<marcoceppi> rick_h__: right, but it will make it to 2.0 ?
<rick_h__> marcoceppi: cory_fu definitely
<marcoceppi> this is all work planned for charm-tools 2.0
<marcoceppi> not the 1.11.2 release
<rick_h__> marcoceppi: cory_fu ah ok np then
<cory_fu> marcoceppi: Crap.  I would have liked to get some of these changes that I landed today into 1.11.2.  I assume we can backport them?
<marcoceppi> cory_fu: we can totally backport
<marcoceppi> cory_fu: 2.0 will be released with the new charm command from uros team
<marcoceppi> cory_fu: which I need to get into xenial like tomorrow
<marcoceppi> cory_fu: so I will upload charm/charm-tools 2.0 to the juju/devel ppa
<marcoceppi> but we can still do 1.X releases
<cory_fu> marcoceppi: Cool.  And as for the directory layout, I'm not sure.  I guess we should come up with a different recommendation than suggesting $LAYER_PATH etc be subdirectories of $JUJU_REPOSITORY
<marcoceppi> and we can worry about backports later
<marcoceppi> cory_fu: I think it's a good idea still, tbh
<cory_fu> marcoceppi: What's still a good idea?
<marcoceppi> cory_fu: it's kind of like the GOPATH stuff
<marcoceppi> cory_fu: $JUJU_REPOSITORY being an umbrella for stuff
<marcoceppi> cory_fu: though, it doesn't have to live in JUJU_REPOSITORY, since LAYER_PATH and INTERFACE_PATH are individual settings
<cory_fu> Ok, but how is the new juju going to handle "juju deploy foo" where foo is checked out locally?
<marcoceppi> cory_fu: gooooood point
<marcoceppi> cory_fu: so we could just put the charm_name in the $JUJU_REPOSITORY
<marcoceppi> $JUJU_REPOSITORY/charm
<cory_fu> There's nothing really stopping us from keeping the same pattern and having a "layers" directory under $JR.  It just means no one can have a charm named "layers" (or "interfaces")
<marcoceppi> right
<marcoceppi> which seems silly
<marcoceppi> cory_fu: I could also see someone doing $JR/src/layers,interfaces
<cory_fu> I like something like $JR/{layers,interfaces,charms}
<cory_fu> I'd be ok with that, too
<marcoceppi> cory_fu: we should figure out how juju will handle $JR now in 2.0 though
 * marcoceppi is off to #juju-dev unless rick_h__has feedback
<marcoceppi> cory_fu: as a work around we could do $JR="$HOME/stuff/charms"; $LAYER_PATH=$JR/../layers; etc
<cory_fu> I guess.  Though that breaks my handy dev env switching aliases that change $JR and allow me to have, e.g., a pristine $JR for RQ
<cory_fu> Including layers, interfaces, etc
<cory_fu> But I can work around it
<marcoceppi> cory_fu: well would ranter not do that then
<cory_fu> Also, this only really applies to the default values for LAYER_PATH etc.  If they're set manually, they can be whatever the user wants
<marcoceppi> true
<apuimedo> jcastro: nice article about the juju lxd that jamespage told me he was using
<apuimedo> I'm getting some issue when doing the bootstrap
<apuimedo> ERROR there was an issue examining the model: invalid config: Can not change ZFS config. Images or containers are still using the ZFS pool
<cory_fu> marcoceppi: Updated https://github.com/juju/charm-tools/pull/113
<apuimedo> any idea about that error?
<koaps> hi guys, I'm having an issue with juju ha, wondering if anyone could help me troubleshoot
<apuimedo> koaps: juju ha? hacluster?
<koaps> apuimedo: juju ha
<koaps> my two addition servers just stay in adding-vote
<apuimedo> koaps: servers of which charm?
<koaps> juju ensure-availability --to 1,2
<koaps> the server 1 and 2 never get vote
<koaps> this has worked
<koaps> but we are rebuilding the environment, now it's not
<aisrael> marcoceppi: I got it working \m/
<koaps> seems like some software package changed and mongodb isn't working right
<apuimedo> sorry, I've only got experience developing charms with ha support, haven't tried the "ensure-availability" command
#juju 2016-02-13
<arosales> did the gui log in issue get resolved that we say in the office hours
 * arosales is running into that too
<marcoceppi> arosales: it's a known issue
<marcoceppi> arosales: I think GUI will have it fixed in next release
<arosales> marcoceppi: ack, any known workaround?
<marcoceppi> arosales: suffer
<marcoceppi> :)
<arosales> marcoceppi: I am suffering
<arosales> with no gui action :-)
<marcoceppi> arosales: you could downgrade to alpha1
 * arosales guesses this is a symtom of a 2.0 alpha depoy
<marcoceppi> but I'm sure the GUI team will have an updated Juju gui release soon
<arosales> ok
<arosales> gotcha
<arosales> marcoceppi: thanks for the info
<arosales> and downgrade, never
<rick_h__> arosales: marcoceppi I know they were hacking on the new API for 2.0 in the sprint this week
<arosales> rick_h__: good to know
<bdx_> thedac, charmers, openstack-charmers: https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1545342
<mup> Bug #1545342: Need haproxy-client-timeout, haproxy-server-timeout config params <percona-cluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1545342>
<marcoceppi> bdx_: thanks for the report
<bdx_> marcoceppi: can you help me get some heat on that? I'm trying to stand a deploy up using percona-cluster, and that is the last thing stopping me ...
<marcoceppi> bdx_: it's saturday so I'll flag the openstack charmers on Monday
<bdx_> sweet, thanks!
<bdx_> have a nice weekend
#juju 2016-02-14
<stormmore> hi so I am doing my first PoC deployment and I am trying to understand why I am having problems getting juju to deploy lxc containers
<agunturu> Hi, I am trying to use charm actions, and all the charm actions seem to be failing with âPermission deniedâ.
<agunturu> root@juju:~# juju action fetch 7b9b575d-7853-49d9-82ae-7b9fd3d1a6f7
<agunturu> message: 'exec: "/var/lib/juju/agents/unit-cwaio-cwims-vnfd-b-3/charm/actions/create-update-user":
<agunturu>   permission denied'
<agunturu> status: failed
<agunturu> timing:
<agunturu>   completed: 2016-02-14 16:35:42 +0000 UTC
<agunturu>   enqueued: 2016-02-14 16:35:41 +0000 UTC
<agunturu>   started: 2016-02-14 16:35:42 +0000 UTC
<agunturu> Appreciate any help on this.
<Dystrakti0n> This may be more of a maas question, but it's also a bootstrapping question. I have recently installed 40Gbe infiniband with switch {Mellonox} between a homebuilt server/ ZFS NAS, which is hosing my MAAS nodes. Nodes are connected to the internet via stand alone PFSense box, one netgear 24port prosafe POE, and a Cisco 48 port managed switch. PFSense is forwarding all BootP requests to MAAS box,
<Dystrakti0n> but handling all other DHCP/DNS requests. IMPI works for enlisting and initial provisioning of nodes. I am wanting to put the Jujubox into a VM, pass both the Gbe Lan and IB networks to the VM, then be able to deploy clusters, or openstack via JUJU using the IB network for the storage network, lan for command and control/inet I have an R900 with 4 hex core 1.8Ghz processors, 120 Gb ddr2 5300F,
<Dystrakti0n> connected to a Tesla S1070, and Tesla S2090. linked to IB and Ethernet, 2 Dell C6105 3 node servers, 2 Dell 2950s, 2 reporposed dualcore nodes, and a couple of home built boxes. All set to boot from pxe over the lan link, but also connected to the IB network. MAAS is handling DNS/DHCP for IB subnet, but not eth0. I have gotten a VM enlisted and configued in MAAS but it times out when trying to
<Dystrakti0n> bootstrap Juju, I have already set the juju timeout to 3600 in the config. Thoughts?
<Dystrakti0n> anyone?
<stormmore> can any help understand what ERROR saving bootstrap endpoint address actually means?
<stormmore> is there a way to get juju to âredeployâ a machine and itâs services?
<blr> stormmore: I generally rely on `juju destroy-machine --force, juju upgrade-charm, juju add-unit
<stormmore> would that work for bundles too?
<blr> stormmore: there may be a more elegant way to achieve the same thing, I'm uncertain.
<stormmore> that is still more elegant that destroy environment and rebuild when one machine doesnât come up in time
<blr> right, much faster than that.
<stormmore> I have already lost a machine this weekend as it wonât respond to wakeonlan anymore
<stormmore> I blew the lab managerâs mind when I showed him MAAS last week
<blr> hah yeah, MASS is pretty cool.
<blr> err MAAS even.
<stormmore> it was what he wanted a few years back and never got
<stormmore> but wow does juju really make maas powerful :)
<stormmore> my mine was almost blown away with juju-gui
<stormmore> and that is is hard to say about any modern tech for me
<stormmore> love watching the juju status --format tabular when launching a bundle using quickstart
<stormmore> now if only I could get the networking right on this proof of concept
<stormmore> donât think I have enough routebale IPs for it at the moment... only have 12
<marcoceppi> stormmore: yeah --format=tabular is so awesome it'll be the new default in 2.0
<marcoceppi> agunturu: are the files in actions/ executable (chmod +x)?
#juju 2017-02-06
<aisrael> Any conjure-up folks around? I installed the snap from the beta channel and `conjure-up` fails with: ImportError: No module named 'conjureup'
<aisrael> https://github.com/conjure-up/conjure-up/issues/652
<Odd_Bloke> stokachu: ^
<aisrael> stokachu, for context: I'm at the Juju Summit, and wanted to test conjure-up before my talk. We're pushing conjure-up pretty hard, so I'm hoping my failure is just a one-off
<stokachu> aisrael, you are running the snap one from /snap/bin/conjure-up?
<aisrael> stokachu, yep
<stokachu> aisrael, one sec
<stokachu> aisrael, hmm, do you have any pyenv environment enabled?
<stokachu> on a fresh 16.04 install i dont see this problem
<aisrael> stokachu, nope, nothing special wrt pyenv
<stokachu> aisrael, hmm..
<stokachu> aisrael, whats the output of `env`?
<aisrael> http://pastebin.ubuntu.com/23940964/
<stokachu> starting up a fresh system again to make sure
<stokachu> aisrael, xenial?
<aisrael> stokachu, Yep, 16.04.1, up to date as of this morning
<stokachu> ok
<stokachu> aisrael, hmm im having trouble reproducing, i just did a fresh maas deploy of 16.04.1
<stokachu> aisrael, maybe create a fresh user account and try running it with that user
<aisrael> stokachu, ok. I'll fire up an lxd container and see if I can reproduce it locally. It might just be something on my system, and if so, I'll try to debug and provide steps to reproduce.
<stokachu> aisrael, thanks, the python plugin for snap is pretty specific when it comes to the interpreter it runs
<stokachu> so it may be something with that im missing
<aisrael> I can also try building the snap locally and see if that changes anything
<stokachu> aisrael, thanks, it uses python 3.6 within the snap, and unsquashfs -l conjure-up*snap should show you the module path
<stokachu> aisrael, http://paste.ubuntu.com/23941001/
<stokachu> so the module is definitely there
<aisrael> I only have python3.5 installed. Does the snap include the 3.6 runtime?
<stokachu> yea it does
<stokachu> aisrael, any luck?
<stokachu> mup, ping
<mup> stokachu: I apologize, but I'm pretty strict about only responding to known commands.
<admcleod> hi - im trying to use a bundle (juju 2.1, juju deploy) with manually provisioned machines. the machines are provisioned and numbered 0,1,2,3,4, the bundle refers to them as such also, and the placement of the charms in the bundle refers to them either as that number (e.g. charm ceph-mon, to: 1, or to: - lxd:1, etc) - but when i try to deploy, it tells me "cannot create machine for holding"
<bdx> admcleod: sup, the machines specified in the bundle don't correlate to the machine numbers in the juju environment
<admcleod> bdx: thats what i was thinking
<bdx> the machine placement directives in the bundle are context sensitive to that bundle, and deploying a bundle will always try to provision new machines, not map to the machines in the bundle :(
<admcleod> bdx: well, thats peculiar since the rest of the error says:
<admcleod> cannot add a new machine: use "juju add-machine ssh:[user@]<host>" to provision machines
<admcleod> right. but they're already there...
<bdx> yeah .. that would make sense, because the bundle doesn't know about them, and because manual provider, juju doesn't have access to a hoard of resources to create new machines with
<admcleod> bdx: right. but if it says 'add a machine manually', then if i was to do that, presumably it wouldnt know, and ask me to add another machine manually
<bdx> yea .. exactly
<admcleod> bdx: that seems like a bug
<bdx> bundle deploys <-> manual provider have never worked for me ... yea totally
<sparkiegeek> wasn't there a ML thread about this?
<bdx> admcleod: but what if you want new machines? ^ doesn't fit the rest of the use cases though
<admcleod> sparkiegeek: ??
<sparkiegeek> admcleod: https://lists.ubuntu.com/archives/juju/2016-December/008367.html
<admcleod> sparkiegeek: thanks
<sparkiegeek> admcleod: np
<stokachu> aisrael, were you able to get conjure-up going?
<aisrael> stokachu, not yet. Just finished with my talk, though, so I'll give it a try
<Zic> hi, if somebody of the CDK team is here, I got the same error (Unable to authenticate the request due to an error: crypto/rsa: verification error)on a fresh brand new cluster
<Zic> with no operation post-install
<Zic> we just poweroff-ed one master to test the HA, and when we poweron-ed it, it came back with this error which totally mess the whole cluster :/
<Zic> http://paste.ubuntu.com/23941613/
<magicaltrout> hmm dunno if jcastro has irc open to ping one of the CDK guys
<magicaltrout> they're all in Gent
<Zic> the last time, this error appeared few days after some operations on our side, so we didn't know how to reproduce
<Zic> but here, it's *just* after the end of the install (when all juju status was green)
<magicaltrout> i've tried to ping them on twitter Zic
<Zic> thanks :)
<magicaltrout> we shall see how connected they are
<Budgie^Smore> or the mailing list, I know lazy said he would see things there
<magicaltrout> yeah but its not real time is it! ;)
<rick_h> The signal fires are lit
<magicaltrout> hehe
<lazyPower> magicaltrout - state the nature of your kubernetes emergency
<magicaltrout> hehe
<magicaltrout> not mine
<Budgie^Smore> speak of the devil! ;-)
<Zic> lazyPower: guess who is crashing everything? \o/
<magicaltrout> Zic here has broken his cluster
<lazyPower> Zic - ah, i could have guessed :) I spoke about you today in my talk
<lazyPower> ok so what seems to be the trouble Zic?
<magicaltrout> was it something like "poor guy, keeps testing our code and breaking things?" ;)
<Zic> lazyPower: you remembered the credential error with "Unable to authenticate the request due to an error: crypto/rsa: verification error"?
<lazyPower> magicaltrout - nah, it was actually describing how he was able to make an irrecoverable state change, and i was quite impressed
<Zic> I had it after some days of operation and it was not clear how we can reproduce it
<lazyPower> Zic i do remember something about this
<lazyPower> Zic did you manage to reproduce it? or is just showing up again without a clear indicator as to why?
<Zic> here, I just deployed a brand new cluster and just after the end of install (`juju status` showed all green) it starter immediately after we rebooted one of the 3 masters
<Zic> started*
<lazyPower> ahhh
<lazyPower> so restarting a master has triggered a cryptographic verification error?
<Zic> yeah
<lazyPower> Zic - we definitely need to document that in a bug and take a look
<Zic> we did the check that you pointed me to the last time : check that /srv/kubernetes corresponding with openssl x509, it does not change
<Zic> maybe it's the k8s token? but I don't know how they work
<lazyPower> ah good, so the TLS cert was verified
<lazyPower> good call, i bet i know whats happened Zic
<lazyPower> Zic - those tokens need to be syc'd among the masters, and they aren't right now. so you've got a new token that it loaded into the k8s object store during turn up
<lazyPower> and its not agree'ing with what the other msters have.
<lazyPower> which would be why it showed up after reboot, not before
<lazyPower> actually i'm kind of perturbed we didn't find this before reboot
<Zic> we think about his because one of the event of the Ingress controller was about readyness
<Zic> kube-dns also
<lazyPower> Zic - they mount the default service token right?
<Zic> -> requests that ask the API with token
<lazyPower> Zic - so the token is different across all 3 masters
<Zic> lazyPower: how can I confirm that?
<lazyPower> 1 sec i'm turning up k8s on my laptop
<lazyPower> Zic - check in /srv/kubernetes/known_tokens.csv
<lazyPower> all 3 masters will have a different token in that file is my guess
<Zic> http://paste.ubuntu.com/23941724/
<lazyPower> Zic - seems like thats the culprit
<lazyPower> Zic - great pointer on this one
<Zic> lazyPower: just before this error (and just after the install, no additionnal extra OP) we discovered that something went wrong because kube-dns and one of the Ingress controller was in CLBO
<Zic> do you confirm it can be tied to this problem? as it probes the readiness through API I believe
<lazyPower> Zic - yeah you should be able to confirm that with a kubectl describe
<lazyPower> Zic - if its failed contacting the API with that token, i'm mostly certain you'll get that as output in the kubectl describe of that pod
<lazyPower> i may be incorrect and it only say it entered a failed/crashed state
<lazyPower> but i'm mostly certain it'll give you more detailed info w/ regards to an api contact failure
<Zic> http://paste.ubuntu.com/23941761/
<Zic> (for kube-dns)
<lazyPower> yap, i'm wrong
<lazyPower> it would have to be verified with log output
<aisrael> stokachu, I'm running into a problem building the snap. It wants me to install the core snap, but I try and it won't because ubuntu-core is already installed (and uninstallable). Run into that before?
<Zic> mp          10m         11m         18        zk-0               Pod                                 Warning   FailedSync         {kubelet mth-k8s-01}          Error syncing pod, skipping: failed to "SetupNetwork" for "zk-0_mp" with SetupNetworkError: "Failed to setup network for pod \"zk-0_mp(c5559d40-eafe-11e6-a57e-0050569efde9)\" using network plugins \"cni\": \"cni0\" already has an IP address different
<Zic> from 10.1.6.1/24; Skipping pod"
<stokachu> aisrael, what about `sudo snap refresh ubuntu-core`
<stokachu> aisrael, see if it'll update and rename it
<aisrael> no updates available
<stokachu> try sudo snap refresh core
<Zic> lazyPower: I have this one also, but it's on the old cluster (not the fresh one) don't know if we can link all this bugs
<lazyPower> Zic - that CNI failure seems to be bubbling up FROM CNI itself though
<lazyPower> Zic - wsa this similar in symptom though?
<aisrael> stokachu, no luck. can't refresh 'core', can't find 'core'
<lazyPower> it started with cryptographic errors and yielded broken behavior?
<stokachu> aisrael, what does `snap version` show
<lazyPower> Zic - also, why aren't you here :) :) We could be hacking on this in real time
<aisrael> snap    2.21
<aisrael> snapd   2.21
<aisrael> series  16
<aisrael> ubuntu  16.04
<stokachu> well wth
<Zic> lazyPower: because I'm stick with the customer to debug this x)
<lazyPower> Zic - also, thanks for following up with this.
<stokachu> aisrael, can you hop on #snappy on freenode
<lazyPower> Zic ah good reason. I'll see if i can get this fixed up in a branch tonight fo you to deploy and test with.
<Zic> lazyPower: but I'm counting on you to tell me all your stories about the Juju Summit :p
<lazyPower> Zic ah, let me show you this :D
<lazyPower> https://docs.google.com/presentation/d/1kJ-OeazxivyMkQbDC20wD-NDkW4T-H8BUTfQNxw3wOE/pub?start=false&loop=false&delayms=3000&slide=id.g1c62525350_1_90
<Zic> or we'll be glad to welcome you at my company x)
<Zic> it's not to far from where you are :)
<lazyPower> hehe great :D
<Zic> Gent -> Paris, and we offer you pizza :D
<Zic> lazyPower: the best part is about "Operators and devs be like" slide :p
<Zic> lazyPower: can I do something for you before the hotfixing comes? to help you with?
<lazyPower> Zic -well
<lazyPower> you're gonna be the primary driver of testing
<lazyPower> that's enough for me. I don't think there's anything other than ensuring the bug is filed so i can link it on the commit.
<Budgie^Smore> So etcd is becoming the new duck tape is what I like to say :P
<lazyPower> Budgie^Smore - hahaha
<lazyPower> nailed it
<Budgie^Smore> lazyPower was your talk recorded by chance?
<xnox> stokachu, what is the difference between "kubernetes core" and "canonical distribution of kubernetes" when doing conjure up?
<lazyPower> Budgie^Smore - it was
<lazyPower> xnox - kubernetes-core is a much lighter bundle, it only rqeuires 3 units
<lazyPower> xnox canonical-distribution-of-kubernetes requires 9 units out of the gate, and introduces an API LoadBalancer to work around kubernetes not properly contacting the masters in an HA formation (they only contact the first)
<lazyPower> so those are the 2 initial differences
<xnox> lazyPower, is the charm and the binary that runs kubernetes the same?
<lazyPower> xnox correct
<xnox> good
<xnox> lazyPower, thanks a lot!
<Budgie^Smore> lazyPower I think I found a problem with the loadbalancer, was trying to use helm the other day and it couldn't do a port-forward command
<lazyPower> xnox no problem :) happy to help
<lazyPower> Budgie^Smore - we documented a work-around for the mean time
<xnox> lazyPower, where can i do the lookup to where the conjure up "recipe is", bundle, and charms?
<lazyPower> its known that helm hates our LB, it doesn't talk SPDY
<Budgie^Smore> OK :) just checking, decided not to use helm at the moment and just use their charts as templates to self deploy
<Zic> ok, I will fill the bug lazyPower :) https://github.com/juju/juju is the right place?
<lazyPower> Zic - github.com/kubernetes/kubernetes
<lazyPower> Budgie^Smore - ok, we're goig to be replacing the current APILB with a layer4 reverse proxy
<lazyPower> so that issue should have a shelf life
<Budgie^Smore> awersome, might have a use for helm stuff then :)
<stokachu> xnox, https://github.com/conjure-up/spells/tree/master/canonical-kubernetes
<stokachu> xnox, metadata will have a link to the bundle location
<xnox> spell - that's the word!
<lazyPower> man, as much as i like interfacing with you people but im ready to get back to engineering :P
<lazyPower> as i'm sure you who are patiently waiting for fixes are ready for too
<Budgie^Smore> nope, coming up with work aroundsi in the meantime ;-)
<stokachu> xnox, were you able to navigate the ui without it freezing?
<stokachu> xnox, i saw you mention that earlier
<xnox> stokachu, i have not. but i was advised at fosdem that maybe i should not be trying to do this with: zesty, on ipv6 only network
<stokachu> xnox, ah
<stokachu> xnox, yea ipv6 :(
<xnox> stokachu, at fosdem they have ipv6 networking only by default with dns64
<xnox> ( https://fosdem.org/2017/ )
<stokachu> xnox, fancy :)
<xnox> it's a free event as well =)
<xilet> Working on my first charm, are there any simple ways to have a templated config file brought in that does a simple replace on hostname? ( All of the samples I found were specific to applications requiring a good bit of python ). I mean I can always use a language to do it but I don't know if the charm system has something already in place.
<stokachu> xilet, you doing it in bash?
<stokachu> xilet, are using charmhelpers?
<xilet> Right now all of the hooks are in bash
<xilet> Let me ask a concrete example. If I wanted to add a line to /etc/hosts with <ip address> juju_server_<unit ID>     what would be the best way to accomplish that?
<vagarwal> thanks to all the speakers and organizers - nice talks today
<stokachu> aisrael, your talk go ok today?
<stokachu> arosales, conjure-up work out for you all?
<arosales> stokachu: so far so good. More work shop time tomorrow
<stokachu> arosales, cool man
<arosales> but encouraged folks to try what they saw in presos today with conjure
<stokachu> arosales, sweet hopefully you'll get some good feedback
<arosales> and increased usage of conjure
<stokachu> yea im looking at the numbers now
<stokachu> 10 for spark processing today
<stormmore> so has anyone worked on securing the CDK API load balancer so it doesn't use HTTP?
<catbus1> stokachu: hi, I tried  to install conjure-up on 16.04 but it says --classic flag is unknown.
<catbus1> stokachu: do you know if there is any change to the flag? This is what usermanaul says $ sudo snap install conjure-up --classic --beta
<catbus1> using apt install instead
<magicaltrout> any charmers awake?
<magicaltrout> kwmonroe: you alive?
<kwmonroe> yo yo magicaltrout
<kwmonroe> how may i direct you to cory_fu today?
<magicaltrout> lol
<magicaltrout> all your counterparts over here are shit
<magicaltrout> and have gone to bed
<magicaltrout> charm push . cs:~spiculecharms/apache-solr
<magicaltrout> ERROR cannot post archive: unauthorized: access denied for user "spicule"
<magicaltrout> any idea?
<cory_fu> magicaltrout: Sorry, I'm EOD and headed to bed.  ;)
<cory_fu> magicaltrout: Kidding.  Have you tried doing "charm logout" and "charm login"?
<magicaltrout> just did that
<magicaltrout> same result
<cory_fu> Hrm
<magicaltrout> we were discussing you earlier. I made the point drinking is so much easier when you aren't around! ;)
<cory_fu> magicaltrout: Go to jujucharms.com and log out / in there, then charm logout/in again
<cory_fu> ha
<magicaltrout> i have this cool trick of hitting weird bugs the night before a talk
<kwmonroe> magicaltrout: i'm gonna guess this is because you have all these identities.  who does "charm whoami" think you are?
<magicaltrout> bugg@tom-laptop2:~/Projects/charms/builds/apache-solr$ charm login
<magicaltrout> Login to Ubuntu SSO
<magicaltrout> Press return to select a default value.
<magicaltrout> E-Mail: tom@analytical-labs.com
<magicaltrout> Password:
<magicaltrout> Two-factor auth (Enter for none):
<magicaltrout> bugg@tom-laptop2:~/Projects/charms/builds/apache-solr$ charm push . cs:~spiculecharms/apache-solr
<magicaltrout> ERROR cannot post archive: unauthorized: access denied for user "spicule"
<magicaltrout> bugg@tom-laptop2:~/Projects/charms/builds/apache-solr$ charm whoami
<magicaltrout> User: spicule
<magicaltrout> Group membership: apachefoundation, apachesoftwarefoundation, charm-contributors, containers
<magicaltrout> bugg@tom-laptop2:~/Projects/charms/builds/apache-solr$
<magicaltrout> hmm
<magicaltrout> so i should be a member of my own group right?
<magicaltrout> group/team
<magicaltrout> whatever launchpad calls it
<kwmonroe> indeed you should
<kwmonroe> also, how in the heck did you get into the containers group?  those folks are picky.
<magicaltrout> cause i'm bloody amazing
<magicaltrout> anyway
<kwmonroe> lol
<magicaltrout> how did i end up out of my own group
<magicaltrout> and how do i get back into it?
<cory_fu> magicaltrout: You are a member of the group, but the charm store needs to refresh from LP.  Did you go to jujucharms.com like I said?
<kwmonroe> yeah magicaltrout, it does look like spicule is in the group:  https://launchpad.net/~spiculecharms/+members.  do what cory said.
<magicaltrout> i did cory_fu
<magicaltrout> as if i wouldn't do something cory_fu suggested!
<cory_fu> magicaltrout: Hrm.  I don't know.  That's a known issue and that's the fix for it.  Maybe try charm logout, jujucharms.com logout, jujucharms.com login, charm login?
<cory_fu> :)
<cory_fu> I've definitely had that fix that issue before
<kwmonroe> yeah - it's gotta be in an order iirc.  luckily there aren't many permutations to try ;)
<kwmonroe> magicaltrout: as a workaround, could you push to ~spicule and use the charm from there?
<kwmonroe> then sort out the group membership at a more reasonable hour?
<magicalt1out> same fail
<magicalt1out> great i'm locked out of pushing my own charms \o/
<cory_fu> O_O
<magicalt1out> i'll deploy locally and complain on the mailing list
<magicalt1out> weird though
<kwmonroe> magicaltrout: can you push to one of those other listed groups?  apachefoundation, apachesoftwarefoundation, charm-contributors, containers
<magicalt1out> testing
<magicalt1out> yes kwmonroe
<magicalt1out> that works fine
<catbus1> Hi, I tried to add maas cloud to conjure-up, but it errors out with trackback: unable to find: <home folder>/.local/share/juju/accounts.yaml. And there is also 'cattle' not found in juju's bootstrap-config.yaml error message. Is there something I need to do between maas and juju prior to setting this up in conjure-up?
<cory_fu> catbus1: I believe those errors are due to not having had run any juju commands before.  I thought conjure-up was updated to resolve that; can you verify if conjure-up is at the latest version?
<cory_fu> catbus1: Otherwise, you should be able to run any juju command, such as: juju status
<cory_fu> magicalt1out: Sorry I couldn't be of more help.  I really do have to EOD now
<magicalt1out> yeah no worries
<catbus1> cory_fu: I have the latest conjure-up in 16.04: 2.1.0-0~201701041302~ubuntu16.04.1
<catbus1> cory_fu: I don't have any juju controller yet.
<catbus1> I assume a juju controller will be created afterwards. conjure-up bootstraps juju.
<cory_fu> catbus1: Yes, that's fine.  It's just the bootstrap logic that needs to run.  The relevant issue for conjure-up is https://github.com/conjure-up/conjure-up/issues/641
<cory_fu> It seems that it has not been fixed yet after all
<magicalt1out> cory_fu: your support services are failing this evening! ;)
<cory_fu> magicalt1out: Indeed.  Happens when I try to support things I haven't worked on.  ;)
<magicalt1out> hehe
<magicalt1out> i blame your colleagues for going to bed....
<magicalt1out> and certainly not the fact i'm trying to stand up a demo 12 hours before my presentation....
<cory_fu> magicalt1out: Me too
<magicalt1out> thanks... that means a lot!
<magicalt1out> i also blame kwmonroe
<cory_fu> catbus1: I'm afraid I do have to head out for the evening.  I'm not sure what timezone you're in, but if my suggestion of running `juju status` followed by re-running conjure-up doesn't work, I would have to direct you to stokachu tomorrow during the day according to EST
<cory_fu> magicalt1out: That goes without saying, I'm sure.  ;)  But for reals, heading out.
<cory_fu> o/
<kwmonroe> magicalt1out: does pushing to one of your other groups get you un-stuck for the preso tomorrow?
<magicalt1out> yeah kwmonroe its not a blocker
<magicalt1out> just a bit shit :)
<catbus1> cory_fu: thanks, I will ping stokachu tomorrow
<kwmonroe> totally agreed magicalt1out
#juju 2017-02-07
<stokachu> catbus1, i should be around for a bit just ping me if you come back to it
<stokachu> balloons, around?
<pranav_> Hi. I have a question regarding Cinder charm.
<pranav_> If i locally modify the cinder.conf through the shell and then modify config through the juju-gui
<pranav_> the local changes get overridden. Any workaround this?
<junaidali> pranav_: I haven't used juju gui for deployment. Have you tried modifying the template file in /var/lib/juju/agents/unit-cinder-0/charm/templates/ and then writing changes using gui?
<pranav_> junaidali: No haven't tried that. We tried to see if any relation hooks get fired on modification but no good. Let me check the templates
<pranav_> One question, to modify the template file our application has to be running in the same unit, correct? Or is there a way to change the templates via relations?
<junaidali> imo, if you want some changes to be retained, you probably look for changing template file because whenever you change some config, all the template files will be re-written
<junaidali> if you've more than one units of charm, update template file in each unit
<junaidali> should probably*
<pranav_> I see. In which case our application always has to co-exist with the cinder charm.
<junaidali> sorry, just to correct what i said earlier, whenever we change any config, all the file are re-written **from the template file**
<junaidali> pranav_:
<junaidali> files*
<pranav_> Cool! we are gonna try out changing the templates, which i feel should work for us.
<pranav_> Thanks for the help Junaid :)
<anrah> Hi! I'm starting to write tests to my charms, however I seem to have a problem:
<anrah> 2017-02-07 10:32:51 Error getting env api endpoints, env bootstrapped?
<anrah> 2017-02-07 10:32:51 Command (juju api-endpoints -e localhost-localhost:admin/default) Output:
<anrah> http://paste.ubuntu.com/23946536/
<anrah> juju version is 2.0.2
<anrah> and amulet is 1.18.2
<anrah> somehow it looks like the amulet? is using old juju commands that are not available on 2.0 ?
<junaidali> anrah: what's the version of juju-deployer you have?
<anrah> 0.6.4
<anrah> I upgraded it but no help
<junaidali> upgraded to which version? i think juju-deployer doesn't yet support 2.0. You can get a 2.0 supported package from Tim Van's ppa https://launchpad.net/~tvansteenburgh/+archive/ubuntu/ppa
<anrah> 0.10.0 is the new version
<junaidali> oh okay, you've the newest version..
<anrah> I think the problem is not with the juju-deployer but the at the very first lines where the amulet? is trying to get information about the controller
<anrah> as it trys to run this command: Command (juju api-endpoints -e localhost-localhost:admin/default)
<anrah> and there is no juju api-endpoints command on juju 2.0
<junaidali> yes, you're right
<anrah> so.. Amulet is useless with Juju 2.0 ?
<junaidali> wait, someone will help you. It is probably late for many people here
<anrah> Thanks!
<anrah> I think I mixed the python versions.. As amulet uses python3 and juju-deployer python2 so had old version of the juju-deployer on python2 packages
<lazyPower> Zic heyo, i'm starting to hack on that issue you uncovered lastnight now.
<lazyPower> Zic - should have something fo ryou to look at before we head into the kubernetes hacking sessions later today. This might take a bit, but i'm hoping to have something for you to setup in a staging capacity shortly.
<Zic> lazyPower: hello, I just come to my office, you're so synced :)
<lazyPower> Zic :) Blame it on Belgium
<Zic> lazyPower: what jetlag does it cause to you? you came from London/Canonical?
<lazyPower> Zic - i came from KC MO, so much further than London
<Zic> lazyPower: so "jetlag" was the right word :D I was not so sure "jetlag" is applicable if you just... take the boat or the train :)
<lazyPower> indeed. i'll be leaving tomorrow so onw that i'm adjusted to the timezone, its time to leave soon
<lazyPower> @stub  hey stub, question for you re: layer-leadership if you're around
<stub> yo
<lazyPower> stub, can i just invoke it once and give it a dict? or do i need to call it everytime with key=val pairs for each data point i want the leader to push?
<lazyPower>        charms.leadership.leader_set({'service_key': '/etc/kubernetes/serviceaccount.key', 'foo': 'bar'})
<stub> that method accepts keyword arguments or a dictionary, so either leader_set({'foo': 'bar','baz':False}) or leader_set(foo='bar', baz=False)
<lazyPower> oh fantastic
<lazyPower> stub <3
<stub> although now I look at the signature, leader_set(settings='hello') will fail, so don't call your leadership setting 'setting' until I fix that :-P
<Zic> lazyPower: as you are at Europe time now, I will be available if you need any test to 19:00 :)
<lazyPower> Zic - i'm just now deploying the first attempt at fixing, currently waiting on convergence
<lazyPower> Zic - but as i'm at a conference its hard to dedicate any reasonable amount of time, so thank you for being patience
<lazyPower> *patient
<Zic> I understand, no worries :)
<Zic> my customer continue to adapt their code to k8s with minikube installed locally for now
<magicalt1out> kwmonroe: have you come up with an apachecon talk yet?
<magicalt1out> dont want to end up sumitting something similar to you guys
<xnox> let the fun begin
<xnox> $ juju deploy easyrsa
<xnox> ERROR cannot resolve URL "cs:easyrsa": charm or bundle not found
<xnox> juju deploy cs:~containers/easyrsa-6 works.
<marcoceppi> xnox: yup, it's not yet in a promoted namespace
<xnox> ok
<marcoceppi> xnox: you can expect it to complete review in time for the 1.6.0 release of kubernetes
<xnox> working of instructions from https://jujucharms.com/u/containers/easyrsa/
<xnox> I cannot do "juju deploy tls-client" and the relation name is wrong too?
<marcoceppi> tls-client is a place holder for connecting to something that consumes tls
<marcoceppi> xnox: what's your end goal?
<xnox> currently testing that this charm (by itself) works on s390x.
<xnox> assuming since i have managed to deploy easyrsa, it does.
<marcoceppi> xnox: you'll probably want something that connects
<marcoceppi> it's python so it'll probably work
<marcoceppi> I don't think it uses anything that's not interprutted
<xnox> i am getting a lot of _juju_complete_2_0: command not found
<marcoceppi> xnox: where? in your terminal?
<xnox> yes
<xnox> when i try to tab complete things
<xnox> (i'm running zesty)
<marcoceppi> xnox: are you using the snap?
<xnox> no
<xnox> whatever is in zesty as deb
<xnox> where is source code for https://jujucharms.com/u/containers/kubernetes-master/11 ?
<marcoceppi> xnox: https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/layers/kubernetes-master
<xnox> marcoceppi, how would I fund that from the charmstore?
<marcoceppi> xnox: you wouldn't unless it's in th ereadme
<xnox> marcoceppi, but that's the source code, rather than published charm revision?
<xnox> does that correspond to the v11 of the charm?
<marcoceppi> xnox: no, that's the upstream code
<xnox> marcoceppi, how can I clone the actual charm?
<marcoceppi> xnox: just download the .zip or use `charm pull ~containers/kubernetes-master`
<xnox> it's missing resources and binaries for my architecture, so i need to modify it and submit merge proposals back. But also test before I do all that.
<marcoceppi> nope
<xnox> what do you mean nope?
<marcoceppi> resources aren't delivered in the source code
<marcoceppi> you can deploy kubernetes-master from the store, and attach your kubernetes rsource during that time from a local mirror
<xnox> =)
<xnox> sure, but i want to fix it for everyone on s390x, not just me.
<marcoceppi> xnox: well, that's a slight change, but it's on our roadmap. s390x either just landed in upstream for support or will be soon
<marcoceppi> once it does we can include it in the charm officially
<xnox> landed
<marcoceppi> xnox: either way, you'll want to submit pull requests to the repo mentioned above
<xnox> ok
<marcoceppi> xnox: as the charms are built from that source, using `charm build`
<xnox> and after charm build, i can test my merge proposal locally, right?
<xnox> (last time i did charms, there was no `charm build` and no reactive anything)
<marcoceppi> xnox: modify the code; charm build, juju deploy builds/kubernetes-master --resource kubernetes=s390x.tar.gz; test
<marcoceppi> xnox: I'm a bit busy at the moment, but i'd love to help you more
<xnox> ok, thanks for your time.
<marcoceppi> Very interested in getting s390x support (and ppc64el) added to the charms
<marcoceppi> we have two routes we're chasing for that, so we should chat more
<admcleod> it appears my 'juju deploy' is using a proxy, although i dont have http_proxy or https_proxy set - any ideas?
<lazyPower> stokachu - both the snap and deb packages are illustrating some odd behavior. its no longer waiting for the deployment
<lazyPower> stokachu - i'll try to get more details about this and get a proper bug filed, but just FYI'ing you that there's one in flight incoming.
<stokachu> lazyPower, thanks im debugging right now
<lazyPower> oh has someone already reported?
<stokachu> yea arosales
<lazyPower> Zic - i've got a branch in flight, not going to be ready by EOD today.
<lazyPower> Zic - however, i will def get some additinoal testing on this and ping you in the PR so you can track its progress
<xnox> i am confused where and how a resource ends up packaged and uploaded into the charm store.
<rick_h> xnox: how so? using the charm command?
<xnox> rick_h, but i'm failing to pin point where the resource is assembled/downloaded from, e.g. a makefile or some declarative syntax.
<rick_h> xnox: https://jujucharms.com/docs/2.0/developer-resources ?
<xnox> aha! thank you
<xnox> rick_h, is there $ charm resource-get command?
<arosales> lazyPower: in case your interested the bug I filled was https://github.com/conjure-up/spells/issues/45
<lazyPower> arosales - thats consistent with whats happened in the k8s flavors of spells
<lazyPower> thanks, i'll sub to this
 * arosales thought it was the deploy_done step, but seems more prevalent if your hitting it as well. Good news is stokachu is aware and working on a fix.
<rick_h> xnox: so there's a resource-get hook for the charm itself. I don't see a charm pull-resource like there is a charm pull command for outside of a running unit :(
<xnox> rick_h, also that makes little sense...... so the resource has binaries, but they are x86-64 binaries.
<xnox> rick_h, how does one envision having arch specific resources? e.g. similar to how juju-tools are arch specific.
<xnox> rick_h, can I register s390x resource; amd64 resource; etc? with the same name?
<xnox> or shall I have everything inside the resource tarball and do it myself in the charm (and keep just one resource name)
<marcoceppi> xnox: well we're doing one of two things
<xnox> it seems like it's already an API that a tarball with toplevel binaries must be supported
<marcoceppi> xnox: the first is you can add a named resource like `kubernetes-s390x` and rename kubernetes to `kubernetes-x86`
<rick_h> xnox: no, so I think you'd need to define them as different resources and upload them at publish time and then the hooks would have to have an if block that states "if arch = xxx resource-get xxx"
<xnox> eeewwww
<marcoceppi> xnox: packing every arch in a tarbal is expensive for everyone
<Zic> lazyPower: just saw your message, ACK, thanks for your work while travelling anyway... it's tough :)
<marcoceppi> xnox: to be honest we're moving ot snaps for deliverying kubernetes
<xnox> marcoceppi, renaming a resource breaks all deployments that use custom resource.
<marcoceppi> which handles architecture specific payloads (and adds security / process confinement)
<marcoceppi> xnox: we'll we'd deprecate the kubernetes resource
<xnox> ack.
<marcoceppi> keep it, but deliver an empty blob
<marcoceppi> the charm would say if the blobs empty, look for an arch named resource key
<marcoceppi> that way we wouldn't break exising custom stuff
<marcoceppi> we can do that tastefully, but I think we're going to move away from charm resources
<xnox> about expensive, the tarball is currently 78MB, if we explode it 3 times. It's ok, if we download that; but then remove unused arches.
<xnox> ./foo ->
<xnox> ./x86_64/foo
<xnox> ./s390x/foo
<xnox> ./ppc64el/foo
<xnox> as a resource should be backwards enough compatible. E.g. look for ./arch/foo, failing that take ./foo and run with it.
<Zic> lazyPower: do you have any recommendation to do manually the work of the fix while waiting for the fix? my customer/devs works on their minikube locally while the cluster is b0rken so it's fine, but I need myself to do some testing (like connecting our k8s cluster with our Nagios)
<lazyPower> Zic - you can manually sync those files, but i'd rather have this run during a charm upgrade so its consistent if thats ok
<lazyPower> Zic - otherwise i'm encourgaing you to make a snowflake
<Zic> lazyPower: bonus question, how can I explain to my customer that this problem was not discovered in your testing environment, as for him, the step-to-reproduce is just a reboot
<Zic> I don't want to put all the fault on your shoulders :/
<lazyPower> Zic - we're in beta and HA testing hasn't been part of the release process. #honestanswer
<Zic> what can cause this in our environment and not in your?
<lazyPower> Zic - we've been more focused on single master with in-place upgrades, once that's rock solid, we were going to do HA testing.
<lazyPower> you just happened to beat us to it :)
<Zic> \o/
<lazyPower> Zic and thanks to that testing, we should get HA bits done before we're done with the upgrade testing that we're still working through. A lot of the plumbing is there
<lazyPower> but the minor release updates is different from major release updates
<lazyPower> so we're workign through *that* story this cycle, is 1.5.x => 1.6.x
<stokachu> lazyPower, are you guys seeing errors like (ServerError(...), 'json: cannot unmarshal string into Go value of type uint64')
<stokachu> arosales, ^
<arosales> stokachu: checking
<stokachu> arosales, lazyPower, can you guys also try with `sudo snap refresh conjure-up --edge`
<stokachu> i got some more debugging in there
<arosales> stokachu: not seeing that in my stack trace, where else should I look?
<stokachu> arosales, ~/.cache/conjure-up/conjure-up.log
<arosales> stokachu: not finding that string in my conjure-up.log
<stokachu> arosales, ok give that --edge version a go
 * arosales now going to try with "sudo snap refresh conjure-up --edge
<stokachu> thanks
<Zic> hmm, what exactly "juju enable-ha" do? especially as I'm on manual-cloud provisionning with no MaaS, does it pop a new juju controller machine?
<Zic> jcastro: hello, the k8s meeting we talked the last week is tomorrow right?
<Zic> I will have time to come this time normally :)
<stokachu> arosales, how's it going?
<marcoceppi> Zic: on manual nothing much, however if you `juju switch controller; juju add-machine <user>@<ip>; juju add-machine <user>@<ip>; juju enable-ha --to <machine-id1>,<machine-id2>;` you can get ha for contorller. However, there are some caveats with manual provider
<Zic> marcoceppi: thanks! was wat I'm looking for :)
<Zic> what*
<arosales> stokachu: hitting a snap issue atm
<arosales> working through that
<stokachu> arosales, ok
<Zic> marcoceppi: I think we're going to deploy a MaaS anyway if we have other infra like the one we are preparing with CDK, as our interest for Juju will also be on OpenStack in coming month
<marcoceppi> Zic: I think it'll help with a lot of the headaches you've had
<Zic> the main reason I didn't deploy a MaaS was because we have a kind of like prudct internally-developed, but with less features, and for only one infra, even if MaaS has more features, it's a bit redundant (and our internal system is so strongly tied to other tools we used here...)
<Zic> but as we're planning to deploy more CDK, and test Juju for OpenStack in coming month... I will give it a try :)
<Zic> s/prudct/product/ what happened to my keyboard! :]
<arosales> stokachu: got a stack at a different point now
<arosales> http://paste.ubuntu.com/23948408/
<stokachu> arosales, paste ~/.cache/conjure-up/conjure-up.log
<SimonKLB> when having reset:false in the bundletester yaml manifest, are charms already in the model supposed to be upgraded if the test is running a newer version of the charms or not?
<SimonKLB> i suppose this is up to amulet?
<marcoceppi> Zic: sure, understood. If that system has an api, you could probably bridge the two, by adding your thing as a cloud provider, if you're comfortable with golang
<arosales> stokachu: http://paste.ubuntu.com/23948419/
<arosales> stokachu: odd its calling out not registering a controller
<arosales> conjure should make one for me if I don't have one, but I going to bootstrap and try again just for a data point
<stokachu> arosales, yea it can't find your aws creds for some reason
<stokachu> do you have ~/.local/share/juju/credentials.yaml file?
<arosales> stokachu: http://paste.ubuntu.com/23948429/ <--- with a controller bootstrapped
<Zic> marcoceppi: Go is one of my "needed skills of 2017", as I'm only skilled in C today (and Bash/Python of course, but I do not place Go in the scripting category)
<stokachu> arosales, ok remove ~/.local/share/juju/credentials.yaml
<arosales> stokachu: and yes I have a ~/.local/share/juju/credentials.yaml file
<arosales> ?
<stokachu> arosales, look in that file is one of the accounts for aws incomplete?
<arosales> I still get a stack when I conjure-up with a controller ready
<stokachu> i wonder if we're failing on that
<arosales> I bootstrapped just fine
<stokachu> arosales, pastebin ~/.cache/conjure-up/conjure-up.log
<arosales> http://paste.ubuntu.com/23948438/
<stokachu> arosales, ah! ok that was the bug i was wrestling
<stokachu> arosales, i pushed an update `sudo snap refresh conjure-up --edge`
<stokachu> there is an issue with the constraints parameters we're doing
<arosales> snap refresh conjure-up --edge
<stokachu> yea
<arosales> previously didn't give me an update
<arosales> said I was at the latest
<arosales> ran it again . . .
<stokachu> what about now?
<arosales> and looks to be downloading
<stokachu> arosales, should be rev56
<arosales>  snap refresh conjure-up --edge
<arosales> conjure-up (edge) 2.1.0 from 'canonical' refreshed
<arosales> any way to tell which rev?
<stokachu> whats snap list show?
<arosales> conjure-up  2.1.0    56   canonical  classic
<stokachu> yea
<arosales> rev 56
<stokachu> try that
<arosales> ok
<Zic> marcoceppi: in the first stage of Go, I preferred Rust as it's more like C (no garbage collector or runtime), but Go is everywhere today, so I'm beginning to train at it :)
<arosales> stokachu: good that it is now waiting for applications to deploy
<arosales> still getting an odd message about the size of my terminal though
<stokachu> arosales, ok good, yea need to debug the constraints
<arosales> but if the spell works . .  . .
<stokachu> arosales, yea you gotta be 134x42
<stokachu> arosales, you using gnome-terminal
<arosales> what ever ships with xenial
<arosales> gnome 3.18.3
<stokachu> arosales, so if you go to the menu item 'Terminal' and select 132x43
<stokachu> that's what we test the UI on
<stokachu> that size
<arosales> I def have a terminal > 132x43
<stokachu> hmm ok i just tested it and it works as expected
<stokachu> arosales, those are rows and columns
<stokachu> nothing to do with the resolution
<arosales> but I did go ahead and try to select Terminal --> 132x43 and then `conjure-up bigdata` and I still get the warning
<arosales> stokachu: no stack and waiting for the deploy though . .  .
<stokachu> arosales, ok cool
<arosales> stokachu: got to reclocate
<arosales> but looks to be coming up
<stokachu> arosales, ill be here
<stokachu> arosales, cool thanks
<arosales> not sure how conjure will handle a suspend
<arosales> we'll see
<arosales> getting kicked out of this room
<stokachu> are you  mid deploy?
<arosales> thanks for the speedy work on the bug
<stokachu> np
<arosales> yes deploying to aws atm. . . .
<stokachu> ok yea that'd be interesting to see
<Madarafv> Like teh video plssss!!! https://youtu.be/wFhaJaY4pqU
<Madarafv> PLSSS
<Madarafv> shur up and like, no DISLIKES
<cholcombe> gnuoy, i'm having trouble finding the ceph nerpe scripts.  Do you know where they are?
<lutostag> cory_fu: kwmonroe: any chance I can get write access/collab to https://github.com/juju/juju-crashdump when you all get a chance?
<cory_fu> lutostag: You should already have admin access.  Let me get you the invite link again
<cory_fu> lutostag: https://github.com/juju/juju-crashdump/invitations
<lutostag> cory_fu: indeed, thanks!
<catbus1> stokachu: conjure-down command not found, how do I destroy the deployment?
<mmcc> catbus1: all conjure-down does is 'juju destroy-model -y' under the hood. If you can tell which model it created, you can do it and nothing else needs to happen
<catbus1> mmcc: got it, thanks.
<hml> help please: juju ssh nova-compute/0 is failing with an ssh key failureâ¦ however then ssh-keygen to remove the line canât find the ssh_known_hosts file listed.
<hml> where would it reside?
<stokachu> catbus1, you install via snap?
<catbus1> stokachu: no, via apt, added ppa:conjure-up/next first. 16.04
<catbus1> stokachu: the snap install with the --classic flag doesn't work, it says --classic flag is unknown
<stokachu> catbus1, ok if you remove that package and do `sudo snap install conjure-up --classic --beta`
<stokachu> catbus1, you need to be using snap 2.21
<stokachu> which is in the xenial-updates
<catbus1> hm, snap is not installed on the node.
<catbus1> ok, I will remove conjure-up and start from snap.
<stokachu> catbus1, thanks
<catbus1> stokachu: to confirm, by snap 2.21, you mean 'snap' package, or 'snapd'? I do have snapd and snap-confine 2.21 installed.
<stokachu> catbus1, yea snapd version 2.21
<catbus1> weird, snap install conjure-up with --classic flag works now.
<stokachu> catbus1, :)
<catbus1> stokachu: conjure-up is installed fine. Will redeploy openstack soon.
<stokachu> catbus1, \o/
<stokachu> catbus1, ill be around lemme know how it goes
<catbus1> stokachu: Thank you!
<catbus1> stokachu: Running 'conjure-up' says -bash: /usr/bin/conjure-up: No such file or directory
<catbus1> conjure-up 2.1.0 56 canonical classic
<catbus1> it works on another machine. reinstalling
<stokachu> catbus1, you probably need to logout and back in
<stokachu> if you apt removed previously deb package
<catbus1> got it
<stormmore> anyone played with running Nexus3 in a container?
#juju 2017-02-08
<Spaulding> hello folks! is there any explanation how to do ssl termination on haproxy juju charm?
<stokachu_> arosales, can you do some deploys of spark-processing from the edge channel of conjure-up?
<xilet> Possibly stupid question, but how do I deploy multiple copies of a charm to the same juju (physical) system, I keep getting ' application already exists' when trying to deploy a second copy of a local charm
<jrwren> xilet: did you give it an alt name? Most charms aren't written to support this, but if it is your charm and it supports this, it should be possible?
<stokachu> xilet, juju add-unit
<stokachu> xilet, you can see juju help add-unit
<stokachu> if you want to deploy to same system under multiple containers
<xilet> thanks
<xilet> Was exactly what I was missing
<cory_fu> kwmonroe: Crap.  http://pastebin.ubuntu.com/23955241/
<cory_fu> kwmonroe: 2.1-beta5's autoload-credentials will create a cred for LXD but it's missing a field and can't actually be used
<kwmonroe> wait cory_fu, didn't this work yesterday?
<cory_fu> kwmonroe: I didn't actually check that the credential it created would bootstrap because it looked the same as what you manually created.  I didn't notice the missing field
<kwmonroe> ha!
<kwmonroe> i sense "cat" in your future.
<cory_fu> :)
<kwmonroe> cory_fuuuuudge:  https://travis-ci.org/juju-solutions/layer-cwr/builds/199679703
<icey> is it possible to export a bundle from the cli rather than the GUI?
<kwmonroe> icey: i've always had to fire up the gui to do it.  if you find a way, lmk.  that would be super useful to me.
<icey> kwmonroe: that's what I was thinking :-/
<icey> wonder if I can hack up something to grab it from the gui with a cli command :-P
<kwmonroe> icey: munging "juju status --format=yaml" to get the right fields might be worth looking at too
<icey> kwmonroe: in essence, what I want to do is get the current non-controller model, create a new model with a matching deploy, and destroy the old model :)
<icey> yaml output may be perfect but we'll see
<kwmonroe> icey: i feel like you're on a complicated path to eseentially "rename" a model, but by golly, go for it because i need a cli export too ;)
<icey> well, I want to re-deploy local charms into the new model ;-)
<icey> kwmonroe: not just rename it
<kwmonroe> heh... suuuuure..
<icey> kwmonroe: 3/4 of my current model is local: charms :)
<catbus1> stokachu: where is conjure0 interface defined?
<catbus1> brctl shows conjureup0 isn't attached to any interface.
<catbus1> that's the conjureup0 created in openstack with novakvm on maas cloud
<catbus1> the conjureup0 in openstack with novalxd on localhost works.
<catbus1> stokachu: i found where conjureup0 is created. nm.
<kwmonroe> cory_fu: travis is busted, but https://github.com/juju-solutions/layer-cwr/pull/59.  just merge it.  do it.
<cory_fu> kwmonroe: Gotta wait for travis to pass.  ;)
<kwmonroe> one sec, just need to remove .travis.yml right quick
<cory_fu> :)
<cory_fu> I wonder what's going on wit Travis, tho.  It's also messed up for charms.reactive
<cory_fu> kwmonroe: Merged
<kwmonroe> methinks something went south with a charm-tools dep.  like maybe python-libcharmstore used to be available, but now it's not, and that's breaking the env setup.
<kwmonroe> thx for the merge
<stokachu> catbus1, its in our spells lxd profile
<catbus1> stokachu: I don't find it. I see conjureup0 gets created in the conjure-up init bridge.start, but I don't find which physical interface is attached to it.
<catbus1> I can't find  it.
<stokachu> catbus1, it's attached to same interface lxdbr0 is
<catbus1> stokachu: is it still the same if using maas as the cloud?
<stokachu> yea should be
<stokachu> it'll just nat just like lxdbr0
<catbus1> stokachu: I don't see lxdbr0 on the maas/conjure-up node.
<stokachu> catbus1, oh right, sorry
<stokachu> catbus1, maas different ballgame
<stokachu> conjureup0 is only useful with novalxd and localhost
<stokachu> maas is all up to you to setup
<stokachu> conjureup0 just gets added automatically b/c we can't determine early enough what type of provider you'll be deploying too
<stokachu> so it's a kind of prepare for every scenario
<catbus1> so with maas as a cloud, should I manually attach the physical interface to the conjureup0?
<catbus1> so that maas/conjure-up node can ssh to the openstack instance on a different physical server.
<stokachu> catbus1, yea that's up to you to configure
<catbus1> ok
<arosales> stokachu: just landed from Gent, but will get some deploys from edge on spark processing when I get back into the home office
<stokachu> arosales, cool
<skay> just started seeing this exception when I try to deploy postgresql today https://paste.ubuntu.com/23956963/
#juju 2017-02-09
<mskalka> Anyone have advice for passing json or json like objects into charm actions as params?
<pranav_> Hi Folks. How do I install charms specific to Openstack Ocata release?
<pranav_> The current charms are for mitaka release
<viswesn> I created a new dummy-subordinate charm for dummy-sink charm
<viswesn> and I am seeing the message status as " Waiting for token" for dummy-sink on running "juju add-relation dummy-sink dummy-subordinate"
<viswesn> Is there anything that I need to do to make sure that dummy-sink is "Started"
<kjackal> Good morning Juju world
<kjackal> Hi viswesn I guess you are seing the msg from here: https://api.jujucharms.com/charmstore/v5/~juju-qa/xenial/dummy-sink-0/archive/hooks/source-relation-changed
<viswesn> @kjackal - It is resolved now :)
<kjackal> ah great!
<viswesn> Thanks kjackal
<zeestrat> pranav_: I'm pretty sure Ocata charms are still in their "next" channel in https://jujucharms.com/u/openstack-charmers-next/. See also this proposal for a new bundle for Ocata here: https://github.com/openstack-charmers/openstack-bundles/pull/17.
<zeestrat> pranav_: But please check with the guys in #openstack-charms to make sure.
<Zic> hi Juju World
<kklimonda> hi guys, are charms compatible with both juju 1.25 and 2.0?
<admcleod_> kklimonda: they should be
<narindergupta>  morning
<marcoceppi> stokachu: sos, conjure-up won't let me configure clouds with latest classic snap from beta channel
<marcoceppi> it only ever gives me localhost and not my existing maas
<marcoceppi> stokachu: it's also stacktracing if I try localhost
<fs> ÙØ³ØªÛØ
<ir> Ø¢Ø±Ù
<fs> Ø§ÛÙ ÙÛØ³ØªÛ Ú©Ù Ø§ÛÙ ÛØºÙ ÙØ³Øª ÙÙÙ Ø¢Ø¯ÙÙØ
<mmcc> marcoceppi - were you trying this with the openstack-novalxd spell? that is restricted to only running on localhost intentionally. I can see how that'd be confusing, since there isn't good feedback on that in the UI currently. I've filed https://github.com/conjure-up/conjure-up/issues/666 to track improving that.
<mmcc> marcoceppi - were you trying this with the openstack-novalxd spell? that is restricted to only running on localhost intentionally. I can see how that'd be confusing, since there isn't good feedback on that in the UI currently. I've filed https://github.com/conjure-up/conjure-up/issues/666 to track improving that.
<mmcc> sorry if I just posted that 3 times, having irc bouncer issues
<vila> mmcc: and a devilish issue number, don't search further ;-)
<mmcc> vila :)
<marcoceppi> mmcc: it also failed on localhost
<marcoceppi> mmcc: but why limit it to localhost? It should work fine on maas?
<mmcc> marcoceppi: it's targeted at deploying into LXD containers. if you deployed that bundle on maas, you'd use ~13 full machines
<mmcc> the intent is that if you want to deploy openstack onto maas you should use the other openstack spell
<mmcc> which crams those services into ~4 machines IIRC
<marcoceppi> mmcc: there is no nova-lxd spell though
<marcoceppi> other than localhost
<marcoceppi> mmcc: seems the spell should choose a different bundle based on cloud selected
<marcoceppi> I want OpenStack NovaLXD, I don't care about the nuainces between maas or lxd
<stormmore> is it possible to have different models on a controller to be different clouds? e.g. local and maas?
<marcoceppi> I also don't see why four lxd machines with more lxd machines inside that is a bad thing, lxd supports fully nested machines
<mmcc> marcoceppi: it's not nested. there are no placement directives in the bundle
<marcoceppi> stormmore: technically, yes, however those models would both need to have networking between them
<marcoceppi> mmcc: I'm saying you could do nested still, instead of an exploded 13 machine lxd bundle
<marcoceppi> stormmore: we see people do this a lot with regional models, I don't think we support cross cloud models atm
<stormmore> marcoceppi that is the plan :) I need to build a minimal offline cluster
<stormmore> marcoceppi thinking about making one machine the master / client running all the "master" services including MaaS rack/region and then just have worker nodes boot to it
<stormmore> potentially make it a top of rack design / data center bootstrap system too
<mmcc> marcoceppi: I agree that the current spell organization for openstack isn't ideal. We'll have a discussion about how we can make it clearer and easier to deploy openstack using novalxd onto maas
<marcoceppi> mmcc: seems like the bundle keyword in the spell could be either a string or dictionary of cloud: bundle-url for arcitectures which diverge based on cloud backend
<mmcc> fwiw, I think the way you'd do it with current spells is to pick the openstack-base spell and change the virt-type option in nova-compute to lxd
<mmcc> not sure off the top of my head if that's all though
<marcoceppi> mmcc: you need the LXD charm as well
<mmcc> ah ok
<marcoceppi> mmcc: https://jujucharms.com/u/openstack-charmers-next/openstack-lxd/
<marcoceppi> though, that bundle doesn't deploy cleanly yet, if you change two (outdated) config options it will
<stormmore> The only other way I was thinking which would be better in some ways it figuring out how to register the maas region/rack controller with maas and add juju controller to it too - this would be the ideal method
<mmcc> marcoceppi: having a cloud: bundle mapping inside a spell isn't a bad idea. it complicates some of the other parts of spells, so there's a tradeoff. the simplest thing would be to just have additional spells and keep the 1:1 spell:bundle relationship. I'll file an issue to track discussion
<stormmore> OK now I have a crazy idea forming in my head that begs to be tested
<mmcc> marcoceppi: here's that issue https://github.com/conjure-up/spells/issues/46
<mmcc> thanks for the feedback!
<beisner> hey marcoceppi - yeah that dev bundle isn't quite in sync with the dev charms atm.  but if you have to adjust on the non-next/dev bundle, please raise that as a bug.
<marcoceppi> beisner: I will, it was just two config options that were no longer there, easy enough
<beisner> thx marcoceppi, but if against the -next bundle, don't sweat it, we've got updates in flight for those.
<marcoceppi> beisner: cheers
<skayskay> stub: hey, are you around? I started seeing this failure yesterday with the postgresql charm. https://paste.ubuntu.com/23963015/
<skayskay> I'm in a bootstrapped juju1 environment, and can reproduce it by running: juju deploy postgresql
<skayskay> basically I think squashfuse is not in a trusty repo
<infinityplusb> ahoy. If I am writing a charm, is there any way to pull a file from my host filesystem, rather than having to host it, while I am testing
<infinityplusb> I am deploying using lxd
<stokachu> infinityplusb, other than juju scp there isn't a way within the charm
<stokachu> infinityplusb, you can use resources if you want
#juju 2017-02-10
<sfeole> hello juju world, quick question.  When writing layered charms can I write multiple functions for 1 decorator?
<sfeole> @when(foo)
<sfeole>     def runme():
<sfeole>   def runmetoo():
<sfeole> if anyone knows ?
<stokachu> sfeole, im guessing you'd put @when(foo) before both of those functions
<sfeole> stokachu, yea, but the 2nd function did not appear to run
<stokachu> interesting maybe reactive is just one state per function
<stokachu> why not just write several functions and include them under a parent function that runs when that state is emitted?
<sfeole> stokachu, yea, i can do that
<sfeole> stokachu, thanks for that advice
<stokachu> sfeole, sorry i know it's not what you were asking
<sfeole> i'll try it
<stokachu> but i can't think of another way
<sfeole> stokachu, no, but it should work now that I think about it
<stokachu> ok cool
<sfeole> stokachu, :)
<sfeole> stokachu, all the examples online always show 1 Decorator for 1 Function
<surf> Hi all, I want to deploy services using juju on the cloud (openstack). Is juju deploys services on linux containers on the top of openstack instance (or) it will directly deploy services on openstack instance.
<Ankammarao> Hi juju world!!!
<Ankammarao> when i try to push the charm to the charm store i am getting error"ERROR cannot post archive: unauthorized: access denied for user"
<Ankammarao> and also charm whoami only showing the user name
<stub> skayskay: oh, so what is the environment? Its coming from an update to the snap-layer, which ensures squashfuse is installed so snaps work under lxd (it is in process of becoming a required dependency of snapd, but I needed the work around yesterday)
<stub> skayskay: hmm... so trusty. I guess I'll need to detect the release and only install under xenial
<stub> at least until the snapd backports are all sorted
<kjackal> Good morning Juju world!
<stub> skayskay: Not that that should discourage you from updating to Xenial :-P
<Ankammarao> #ubuntu
<deanman> kwmonroe, hey, are you around ?
<Ankammarao> Hi , is there any command to revoke or hide the old verions of th charm in the charm store
<icey> apparently is-leader cannot be called from within the collect-metrics hook? https://bugs.launchpad.net/charms/+source/ceph-mon/+bug/1663584
<mup> Bug #1663584: metrics collection hook fails <ceph-mon (Juju Charms Collection):New> <https://launchpad.net/bugs/1663584>
<anita_> Hi, is there any method to delete any particular version of a charm from charm store? or the full charm itself?
<magicaltrout> i don't believe you can remove them, but you can grant them unavailable to users
<magicaltrout> you couldn't delete them a while ago, but i've not looked recently
<anita_> magicaltrout_: I tried to revoke a particular version
<anita_> but i can still read that charm versoin
<anita_> magicaltrout_: could you please let me know the command?
<magicaltrout> thats it
<magicaltrout> but you will be able to see it, did you check by logging out of the charmstore?
<anita_> let me try, i remember I tried that way, but still able to read
<anita_> let me recheck
<anita_> Yeah, with sign out not able to see the charm
<anita_> but with sign-in able to read that charm :(
<magicaltrout> yeah you can
<magicaltrout> but no one else can
<anita_> oh is it?
<magicaltrout> so thats as close to it being deleted as you can get
<anita_> ok
<anita_> Thanks a lot
<magicaltrout> no probs
<gaurangt> hi, how do we specify resources in the bundle file?
<anrah> gaurangt: From my knowledge that is not possible
<anrah> https://bugs.launchpad.net/juju/+bug/1623217 is filed for that issue
<mup> Bug #1623217: juju bundles should be able to reference local resources <juju:Triaged> <https://launchpad.net/bugs/1623217>
<gaurangt> anrah, yeah, this looks to be the same requirement.
<gaurangt> thanks for pointing out
<lazyPower> Zic o/
<gaurangt> anrah, one more thing , if I have already deployed the charm and I need to add a relation to that charm in my bundle (which will be subsequently deployed), is that possible?
<magicaltrout> no gaurangt
<magicaltrout> but you could just take that bundle and add your charm to it and post a new bundle to the charm store
<gaurangt> magicaltrout, oh ok.
<Zic> lazyPower: \o
<lazyPower> Zic - awesome. glad you're about. I'm about to push the proposed changes for your multi-master scenario
<gaurangt> I've a specific requirement where I need to deploy one charm manually first and then do some manual stuff on the machines and then deploy the next bundle.
<lazyPower> Zic - however, there's a bit of complexity for me to get it from my hands to yours. a) the kubedns addon template was updated, and its breaking deployments if i rebuild the charms from teh current source tree.
<Zic> lazyPower: cool! I have some hours in front of me to test
<lazyPower> b) its non-retroactive, so it would require a fresh deploy... or we would need to riff out how to approach this in a sensible manner for your existing deployment.
<Zic> I can reinstall it, sure
<lazyPower> Zic ok, sorry about the inconvenience there. I think before this goes GA, we might want to talk about if this should have some auto-magic behind it.
<lazyPower> i still have to sort A before i can get it in your hands though. CDK will fail to complete the setup while that KubeDNS addon template has the optional config map bits added, i might just try to fetch the 1.5.2 release addon template and munge it in there after a manual build
<lazyPower> Zic - however, this tested well in my initial tests. So i'm kind of excited to see if this resolves the multi-master crypto issues for you
<lazyPower> magicaltrout o/
<magicaltrout> now then squire
<lazyPower> magicaltrout  glad to see you made it somewhere safely :)  I'm looking forward to the next summit/conference. Those gents @ the pub were ww1 actors, and were doing re-enactments. I got a nickle tour of Gent + free phillofal for the trouble.
<lazyPower> \o/
<magicaltrout> lol
<magicaltrout> that was very weird
<lazyPower> i also suddenly realize i have no idea how to spell fallafel
<Zic> falafel :p
<lazyPower> ^
<lazyPower> that
<jrwren> well, now I know what I want for lunch.
<lazyPower> Yeah, they were some cool dudes. I thought for sure they were luring me away from the hotel to do nasty things... but nope. they fed me and gave me a history lesson and sent me back on my way
<admcleod> phillofaldelphia
<Mmike> Hi, lads. I'm trying to run some amulet tests on trusty, but I can't install amulet because it depends on python3-amulet which depends on python3-libcharmstore, which is no more in trusty
<Zic> lazyPower: hmm, some bad news sorry: my customer is actively working right now on the cluster to prepare their apps to be "k8s-ified", so I can't reinstall it today as they will work to the end of the day and this night (deadlines approach...) monday I'm out of office and I will be back only on tuesday :/
<lazyPower> Mmike - Sorry you've hit that. Have you filed a bug? It would be good to capture that feedback so I can shop it with the maintainers
<lazyPower> Zic - ah, that is a bit troubling but not an ultimate blocker. this jsut releives some of the pressure I put on myself to get this in your hands -today-
<Mmike> lazyPower: nope, was hoping I did something wrong - will file one shortly
<lazyPower> Zic - by then we might even have a sensible approach to updating the existing deploy so its just juju upgrade-charm
<Mmike> lazyPower: I'm filing that against amulet, right?
<lazyPower> Mmike correct - https://github.com/juju/amulet
<Mmike> ha!
<Zic> lazyPower: sorry :( I expected that I can reinstall the cluster this afternoon (it's 15:23 here o/) and let the cluster operational for this night and the week-end, but the customer is actively working this afternoon :(
<lazyPower> Zic  no problem, no problem at all
<Mmike> lazyPower: so, just to make clear - no bug in launchpad, but create issue in github?
<lazyPower> i was just trying to haul tail to get you un-blocked on this
<lazyPower> Mmike - yeah, i'm fairly certain they dont look at launchpad for amulet bugs (they might, but i'm erring on what i know)
<Zic> lazyPower: I poweroff-ed my two extra-master for now, as it's not in prod and only one master is ok to let them k8s-ified their apps
<lazyPower> Zic - good plan
<Mmike> lazyPower: ack, thnx
<Zic> so they are not hurt by the bug for now
<lazyPower> yeah that crypto bug was fairly simple to squash i think in how i approached it
<Zic> I can power-on them if you want to test your patch on an already deployed cluster
<lazyPower> Zic - just FYI, there's a notion of leadership in charms. I used the leader to generate those files and push them to the followers.  So teh leader is only the one that generates, and the followers just vaccume that in from the leader-data, and blindly write the contents to the correct filepaths.
<lazyPower> its a sort of nieve approach, but i think it's elegant enough that we can fix your deployed units with a simple state toggle
<lazyPower> however, if you have a beefy machine, it might be good to test this in a LXD environment before we go mucking with your deployed units
<lazyPower> s/environment/model/
<Zic> I can pop some VMs on the same ESX which host the current control plane of the k8s cluster, yes
<lazyPower> fantastic
<lazyPower> Zic - ok, lets plan on doing that, and we'll do some testing there before we touch your deployed cluster. I'd like to white glove that deployment as much as possible as it would be your n'th re-deploy at this time.
<lazyPower> i dont enjoy making extra work for my users
<lazyPower> ^ you heard it here first folks
<Zic> :D
<Zic> I'm preparing the new VM, just one is needed?
<lazyPower> Zic - yeah, make it beefy. You'll want bare minimum 4 cores 8gb of ram and ~ 50gb of disk space if you're going to deploy CDK in LXD
<magicaltrout> don't believe it for a second
<Zic> oki
<Zic> lazyPower: it's fun to do things reversely -> I directly began to test CDK on VMs and baremetal, it will be the first time I test it in LXD :)
<Zic> (will be the first time I use LXD anyway)
<lazyPower> Zic - its great :) you'll have some shuffling to do
<Zic> I read about LXD and what differences it exposes to docker or rkt
<lazyPower> i'll give you instructions when its ready, you'll have to use conjure-up to deploy initially then intercept and update teh charms
<lazyPower> Zic - apples and pineapples my friend. machine containers vs app containers
<Zic> it seems to be the common choice for who only works with VMs the last years
<lazyPower> you get a full init system and the containers look/act just like a "real" linux
<Zic> the migration seems to be easier for VM -> microservice with LXD
<lazyPower> so its more than just a process with an ip address
<lazyPower> YES
<lazyPower> exactly
<lazyPower> lift and shift is the primary value proposition
<Zic> I read right \o/
<lazyPower> there's more but we'll leave it at that :)
<magicaltrout> why can't C++ code just resolve its dependencies properly in any IDE :sob:
<Zic> magicaltrout: to make you Go? (I'm a C/C++ guy, but it will be the answer of my pro-Go teamworker)
<magicaltrout> hehe
<magicaltrout> i've never really done anything in either, they all make me sad
<Zic> maybe I will be part of the Go-sect (oh, I mean Gopher!) this year if I can free some time after the K8S project :p
<magicaltrout> i blame kjackal_
<kjackal_> good call!
<magicaltrout> thanks
<lazyPower> Zic - here's the magic if you're interested https://github.com/chuckbutler/kubernetes/commit/3320fc04015411cdc9ad44d98210ada5137537e3
<Zic> oh this part is in Python ?
<lazyPower> Zic - yep, the entirety of the kubernetes charms are python
<Zic> interesting, so I can actually reading it and understand the entire charm :p
<Zic> thought it was Go too, or a specific YAML descriptor
<magicaltrout> na most charms are python
<magicaltrout> a few in bash
<magicaltrout> juju core is Go
<Zic> yeah, the first time I discovered Juju, it was also in Pytho IIRC
<Zic> but the first time I used it, it was recoded to Go :)
<Zic> and as all new tools of Canonical seems to be in Go this day...
<Zic> (LXD, snappy, juju, ...)
<magicaltrout> yeah but they aren't crazy enough to get the public to develop in Go ;)
<Zic> magicaltrout: hehe :p
<SimonKLB> if ~/charms/deps/layer/X is already populated and the repository is updated the new commits don't seem to be pulled when running charm build, am i doing something wrong?
<lazyPower> SimonKLB - allow me to introduce you to the best flag ever when having these issues
<lazyPower> SimonKLB - when building, pass --no-local-layers
<SimonKLB> hehe one step ahead of you :)
<lazyPower> `charm build --no-local-layers`
<SimonKLB> same thing then
<lazyPower> argh
<lazyPower> ok i'm no help then
 * lazyPower dies a little inside
<SimonKLB> haha, ive never had the issue before, so i wonder if its something introduced recently
<SimonKLB> either that or im doing something odd
<Zic> magicaltrout: few years back, I was not curious about Go at all for two reason 1) I have skills in C, Python, and it seems enough to me for "system programming language" 2) The only well-known project in Go was Docker and, as a sysadmin, not huge fan of it (even if I didn't try, I tend to prefer the LXD approach for my PoV)
<Zic> magicaltrout: but as more and more tools in Ubuntu seems to go to Go (...), I'm planning to really take a look at Go this year :)
<SimonKLB> lazyPower: this isnt something youve stumbled upon before btw?
<SimonKLB> if youve had a long-running charmbox
<magicaltrout> i'll learn it, as soon as I've got LXD into Mesos, completed my machine learning course, onboarded my new employee, got some more work in the pipeline and taken a holiday
<SimonKLB> and build a charm with a layer that has been updated
<lazyPower> SimonKLB - nah, i ran into stale stuff because i had local paths when i was building
<lazyPower> but that flag fixed me up, and also, i always map in my charm/layer repo
<SimonKLB> lazyPower: yea ive had that problem as well, thats why i knew about the --no-local-layers flag
<lazyPower> so its whatever i have on the host. so the length of the session of charmbox isn't so much a factor
<Zic> magicaltrout: my last concern is that, it seems Go is much loved when C/C++ hurts you
<Zic> for personal development, I really love C, as I'm not a dev, just a sysadmin so when I'm developing, it's mainly for myself
<SimonKLB> lazyPower: yea right, i think i actually have it mounted as a volume as well, still though, its never been any problem getting it up to date when building
<Zic> no deadline, no teamworker code unreadable :)
<magicaltrout> "i really love C as I'm not a dev...." said 1 person ever
<SimonKLB> lazyPower: i just tried deleting the docker folder from deps/layers and then it was cloned fresh
<Zic> magicaltrout: :D
<lazyPower> SimonKLB - thats weird
<Zic> magicaltrout: I'm saying that because I know that, all I'm developing can easily be in Go (or even in Python) without any downside
<magicaltrout> aye Zic I know what you mean
<magicaltrout> I do java cause its what they taught us at uni
<magicaltrout> thats pretty much the only reason
<lazyPower> all that java
<Zic> magicaltrout: I just did it in C because I like it, and I know it's not a good reason :)
<Zic> (for profesionnal PoV)
<magicaltrout> my boss chew me out a few weeks ago for mocking PHP developers
<magicaltrout> so I'm no longer allowed to mock languages
<Zic> :p
<magicaltrout> I still think PHP developers need to get out more
<lazyPower> magicaltrout - you should replace your boss with a very intricate webservice (in your language of choice) (i'm only half kidding)
<magicaltrout> he is a webservice
<magicaltrout> i got chewed out over email
<mbruzek> Nothing wrong with Java
<Zic> for what I'm doing, Go (or Python) seems to be a better choice than C in fact, but as I'm developing for myself and not profesionally, I have more fun in developing in C, as it really feels low-level speaking to the machine
 * magicaltrout will happily go as abstracted as required for it to be easy :P
<magicaltrout> but for machine learning stuff its all python these days
<magicaltrout> and charms
<lazyPower> ^
<lazyPower> That
<magicaltrout> so my python fu is slowly growing
<lazyPower> "and charms"
<lazyPower> thats what i like to hear
<Zic> yeah, it's the TL;DR : I now know that I can code Juju charm in Python or Bash :)
<Zic> so my Go's learning can wait a little more :p
<magicaltrout> well when i get this mesos stuff building I'll have the best container stack on Jujucharms.com :
<magicaltrout> :P
<lazyPower> Zic - i'm happy to provide all the distraction of learning go that you require if its to charm stuff up
<lazyPower> magicaltrout - thats a pipedream sir, CDK is clearly > mesos. We'll do the pepsi challenge if you require
<magicaltrout> hehe
<magicaltrout> we'll see
<magicaltrout> we'll see
<lazyPower> indeed
<SimonKLB> lazyPower: another wierd one, after juju upgrade-charm im setting "could not download resource: HTTP request failed: resource "X" not found" in the logs
<magicaltrout> those who like following the crowd use CDK... those who like doing science and getting stuff done, use Mesos! ;)
<SimonKLB> however, i do have the resource locally
<SimonKLB> i.e, /var/lib/juju/agents/unit-charmname-1/resources/X exist
<Zic> lazyPower: I didn't learn Go before because it was too "have a foot in each camp" : I have C for my self-pleasure to code, and I have Python/Bash for my work (as a sysadmin)
<Zic> lazyPower: but today, as Go is more mature, I see it everywhere
<lazyPower> SimonKLB - when you upgrade a charm (if local or --switch) it will drop the resource from the controller
<lazyPower> SimonKLB - which means you need to re-attach
<Zic> so... yeah, I plan to learn Go somewhere in 2017 :p
<Zic> I heard that day will be switched to 27 hours instead of 24 this year
<SimonKLB> lazyPower: ahaaa!
<Zic> :>
<lazyPower> Zic - dont torment me with a good time
<bryan_att> hi all - looking for where I should go for conjure-up support. I've deployed it but cannot access horizon (it's unclear what the URL for horizon should be, and the default or "/dashboard" on the deployed host do not work)
<lazyPower> bryan_att - you're in the correct place, if not here then #openstack-charms. but stokachu and mmcc are the primary authors of conjure-up
<rick_h> bryan_att: what substrate did you deploy to? bryan_att is the horizon exposed and have something of an address you can reach from where you're at?
<stokachu> o/
<lazyPower> and with a response time like that ^ you're in good hands
<bryan_att> rick_h: not sure what a substrate is, but it's Xenial minimal server with updates/upgrades only
<Zic> if I was a developer, I will take time to learn as many languages I found "cool"... as a sysadmin, I just sticked with "know one language for each task, C for system-programming, Python for scripting", but I revised my mind and will do an exception for Go, as I saw more and more employee with Go in their sysadmin skills
<rick_h> bryan_att: did you go to lxd, maas, or something else?
<stokachu> bryan_att, did you select localhost?
<stokachu> bryan_att, openstack with novalxd?
<bryan_att> rick_h: yes that was the only option
<bryan_att> stokachu: yes, all the instructions as stated on the quickstart page
<stokachu> bryan_att, can you paste.ubuntu.com your `juju status` output
<bryan_att> stokachu: http://paste.ubuntu.com/23967373/
<stokachu> bryan_att, looks like openstack-dashboard/0*    active    idle   14       10.0.8.149      80/tcp,443/tcp  Unit is ready
<stokachu> so http://10.0.8.149/horizon
<stokachu> but it also looks like some of the ceph stuff isn't up yet
<Zic> lazyPower: my VM is ready by the way, ping me when I can begin the test :p
<Zic> I'm here for the two next hours
<lazyPower> Zic - i'm still waiting on a good build of bins from the master branch. we're blocked on https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/213 otherwise
<lazyPower> the build routine since we're building all arch's and all components in a single job takes upwords of an hour and a half
<Zic> ok
<lazyPower> i'm 35 minutes into a 1.5 hour build
<lazyPower> so only 60 minutes to go \o/
<lazyPower> then i'll be pending the upgrade test. this is likely to wait until Monday for you
<lazyPower> oorrrr
<lazyPower> yeah, probably monday now that i think about it more
<lazyPower> and i should have the upgrade logic sorted by then as well
<Zic> s/monday/tuesday/ actually :p but even if I'm on a weekend, I will take a look because I'm too curious even when I'm away from the PC :)
<Zic> lazyPower: to a near subject, first I thought my kube-dns CLBO-ing sometime (~10th times, and then reteruning to normal state) was maybe not related to this issue, but since I poweroff-ed my two extramaster, I didn't have a single CLBO of kube-dns
<Zic> maybe this fix... will fix this too
<Zic> as the kube-dns CLBO event is tied to the readyness/liveness check, which querying the API (and maybe get the certificate error? I don't find the way to confirm this)
<Zic> we'll see
<bryan_att> stokachu: how do I access horizon at http://10.0.8.149/horizon is that is not a routable subnet on my local net? Also see the next paste which is the result on the host itself:
<bryan_att> stokachu: attempt to access horizon https://www.irccloud.com/pastebin/EhMwXriO/
<stokachu> bryan_att, you can use sshuttle to setup a connection to that 10.0.8.0 subnet
<stokachu> bryan_att, so sshuttle -r user@hostmachine 10.0.8.0/24
<bryan_att> stokachu: ok but to get this clearer, is it assumed that conjure-up is being deployed on a desktop host, or is it designed to be deployed on a server? If the latter and we need to use another tool to access it (e.g. sshuttle), that would be good to clarify in the docs.
<stokachu> bryan_att, yea that depends, if you're install openstack with novalxd on localhost it is assumed that it's running on your laptop
<stokachu> bryan_att, but we should document the sshuttle way b/c some users do ssh into another machine and test it
<bryan_att> stokachu: ok, so for my use case, I'm deploying this on a Intel NUC5i7 with 16GB and xenial-server minimal install, then accessing it via other machines on mt local net to deploy workloads / tests etc using the OSC.
<stokachu> bryan_att, https://github.com/conjure-up/conjure-up/issues/672
<stokachu> bryan_att, yea you'll want to use sshuttle to access that openstack
<stokachu> you'll also need to setup a second sshuttle session to access the actual compute nodes deployed via openstack
<stokachu> openstack on novalxd is meant mostly for development
<stokachu> we have another one that runs on MAAS and is meant for production
<bryan_att> stokachu: this is also for development, but I need an OpenStack deployment that is more "real" than devstack which cannot do what I need for tests, e.g. per the OPNFV Models project https://wiki.opnfv.org/display/models/Testing - e.g. I need to bring up 4 VMs, driven by Tacker as VNFM
<bryan_att> stokachu: I am working with narindergupta to get the OPNFV JuJu installer (JOID) running on newton but also need something lighter, so I am trying conjure-up to see what it can and can't do.
<stokachu> bryan_att, ah ok
<stokachu> narindergupta, can you walk bryan_att through using sshuttle to access his openstack environment?
<stokachu> bryan_att, im working on more openstack spells if there is something you need specifically let me know
<lazyPower> Zic - makes sense to me. seems like whichever scheduler scheduled the kubedns pod doesn't always correlate with whichever api-server was handling the request. and when thats the case, if the crypto keys were mismatched it makes sense it failed because it uses teh default service token to do that auth request
<Zic> lazyPower: just saw mbruzek comment on your fix : https://github.com/chuckbutler/kubernetes/commit/3320fc04015411cdc9ad44d98210ada5137537e3#commitcomment-20834883
<Zic> do you plan to migrate to snap instead of apt in future releases?
<lazyPower> Zic - we're not using apt now ;) we're using tarball packages
<lazyPower> Zic - but yeah, we're in the process of snapping up kubernetes
<mbruzek> Zic we are looking into snaps as the future yes.
<Zic> cool
<Zic> lazyPower: oh yeah, for k8s part, but for some other part like etcd, it fetch the package from the deb archive and you're sticked to the freezed archive version so
<lazyPower> yeah, sabdfl himself is actually working on the etcd snap
<Zic> (except security/fix upgrade)
<lazyPower> i'm a bit concerned about the snap refresh happening under the charm and getting newer versions than the charm is ready for, but we'll jump off that bridge when we come to it i guess
<magicaltrout> i like the fact your jump off bridges
<magicaltrout> not cross them....
<magicaltrout> your/you
<lazyPower> intentional magicaltrout  ;)
<lazyPower> because the day i hit that issue, i'm going to commit seppuku
<Zic> lazyPower: it's a bit offtopic here, but I don't track the news about snappy in Ubuntu -> is Ubuntu Desktop fully build on snappy and no .deb is part of the future?
<Zic> or snap is just camp to "some packages which moves a lot"
<lazyPower> Zic - we're not quite there yet, but yes, snaps are the future of ubuntu.
<magicaltrout> automated under the hood rollout of all your container tech where you can't yet peg versions... what could possibly go wrtong \o/
<lazyPower> magicaltrout precisely
<Zic> lazyPower: with a total replace of deb or just as a "sidekick" for some packages?
<Zic> (as it is actually used, in fact)
<lazyPower> Zic - hard to say, but i think its where we'd like to go is fully snapped.
<lazyPower> we've recently added classic-mode snaps to make making "unconfined" snaps much easier to build and an acceptable delivery pattern. Where teh strict confinement is like final-boss mode of snaps.
<lazyPower> there are some corner cases that dont lend itself very nicely to strict-confinement, like the CNI plugin structure of kubernetes
<lazyPower> but we're working through that and talking with the snappy developers to find a good path
<Zic> I need to refresh me about all Ubuntu technologies :p it's quite a long time I didn't read about Mir, Snappy, ...
<Zic> recently I updated my info about Unity 8 and... *suspense* Juju \o/
<Zic> I was quite impressed/worried that Ubuntu is going to JavaScript application (through Qt/QML) for desktop
<Zic> </offtopic>
<lazyPower> Zic - the best place to get info about snappy is from the snappy mailing list. There's many threads daily from developers integrating and making snap packages.
<lazyPower> you'll find some neat tricks, future-talk, and get the scoop on all things snappy
<lazyPower> i really like the new format of ubuntu-core with the USSO centric bootstrap where on first boot it prompts for your user credentials and fetches ssh keys, so yoyu dont have an insecure default username/password, which  helps eliminate vectors that contribute to things like the mirai botnet
<lazyPower> its a *lot* like the cloud-init story where it fetches ssh keys on bootstrap and doesn't ship with default credentials. but has a fancy TUI for all of it
<Mmike> Hello, again! I've deployed my juju env on amazon AWS but the 'login with sso' button in juju-gui still yields with 'authentication failed: no credentials provided'. Do I need to configure something else for this to work?
<Mmike> rick_h: ^^
<rick_h> Mmike: is this something you bootstrapped?
<Mmike> rick_h: it is
<rick_h> Mmike: then the sso button doesn't do anything. I've filed a bug on the GUI on this and we're looking at updating that
<Mmike> rick_h: I did 'add-credentials' for aws and ...
<Mmike> oh
<Mmike> rick_h: thank you
<Mmike> rick_h: do you have the bug url handy, maybe
<Mmike> ?
<rick_h> Mmike: https://github.com/juju/juju-gui/issues/2360
<Zic> lazyPower: I'm so attached to the APT/.deb architecture but ideas that snappy exposes seems so cool that yeah, I'm excited about how it will emerge in future Ubuntu releases
<lazyPower> Zic its already availble by default in xenial+
<Mmike> rick_h: thnx, much appreciated
<Zic> lazyPower: yeah, but not so much integrated for GUI apps (the only case I used it for now :/)
<lazyPower> Zic - as a test, you can sudo snap install charm
<lazyPower> that will get you the latest/greatest charm-tools in snap format
<lazyPower> Zic - and i dont know about that :) there's quite a few GUI apps in the snap store as well
<Zic> lazyPower: the confinement of this GUI apps in snap break some Desktop integration like the Unity HUD, the GTK decorator, the clipboard, etc.
<lazyPower> ah yeah
<Zic> but it's a work in progress I guess
<lazyPower> that is a challenge
<lazyPower> https://uappexplorer.com/apps?type=snappy_application
<lazyPower> is what i was about to link as counter point
<Zic> and the old XOrg is not helping on this part
<Zic> I think it will be easier with Mir
<lazyPower> but i cede to your findings
<Zic> the only technology I'm feared that Canonical push is Mir actually (instead of Wayland)
<Zic> I know that they choose Mir instead of Wayland because of Ubuntu Touch
<Zic> but I feared that, in coming future, Ubuntu will be too different than other distribution who choose Wayland
<Zic> for all other tech (juju, snappy, LXD, Unity) I'm glad of choices made
<Zic> I'm just a bit curious/worried about Mir
<magicaltrout> ooh nice
<magicaltrout> kjackal_: got mesos master + slave running docker containers locally using the universal stuff
<magicaltrout> don't need marathon after all
<magicaltrout> i'll take a stab at finding out what goes on under the hood next week.
<Zic> magicaltrout: (offtopic again, sorry) -> we never used Mesos directly at my company, only via DC/OS and... was not fan at all
<Zic> I'm saying that because the customer which went with DC/OS in his mind is now currently migrating to K8S through CDK :)
<Zic> not the same techno at all, but he drops DC/OS after seeing K8S
<magicaltrout> well whatever works :)
<magicaltrout> we use a lot of Mesos at NASA as it allows us to deploy non containerised workloads to it
<Zic> magicaltrout: in fact, I think I had a bad experience with Mesos but it's DC/OS's fault, I never use "raw"-Mesos
<magicaltrout> but I'd also like to bring juju to Mesos as a "cloud" which is why I'm plugging LXD into it, but you know, Kubernetes has a lot of fans
<Zic> used*
<magicaltrout> but I use DC/OS on my consultancy servers to deploy all my stuff
<magicaltrout> i'm more than happy with it, but i think the earlier versions were a bit funky
<magicaltrout> and TBH vanilla mesos is easy to stand up anyway
<Zic> yeah, my main concern with DC/OS was, when it block or crash, it only prompt you with a "Give us a visit at Slack" in the first version
<magicaltrout> lol
<magicaltrout> okay its not that bad :P
<lazyPower> who doesn't like joining private slack instances? *eyeballs the 10 orgs he's idling in and hasn't spoken to in 6+ days)
<magicaltrout> indeed
<Zic> also, we find that one of the GUI which was normally protected by the DC/OS oauth was actually accessible if you forge a special link that bypass the reverse-service...
<Zic> we drop it early in our PoC, don't know if it's better now :)
<magicaltrout> Zic: if you deploy on prem and don't lock down the ports there's a shit load open to the  world :)
<Zic> yep
<magicaltrout> dunno why they don't resolve that, but I'm not a Mesosphere dev, so I don't care :)
<Zic> ^^
<magicaltrout> iptables < lock-downmesos.save :)
<magicaltrout> anyway, I think the container orch landscape is big enough for a few platforms, clearly k8s is winning, but I don't think Mesos will go anywhere in the near future
<magicaltrout> or maybe it will and something else will come along, but clearly there's a lot of scope for different platforms
<magicaltrout> they'll all do similar stuff at the end of the day
<Zic> it's not the same abstraction of hardware, between k8s and Mesos, I think there is place for both of them
<lazyPower> ^
<lazyPower> that
<Zic> Mesos presents you hardware like a "bunch of ressources"
<Zic> K8S orchestrate containers
<Zic> it's not same approach for me
<magicaltrout> yup
<magicaltrout> thats true
<lazyPower> Zic - however k8s has support for resources, *and* cri will change that story
<magicaltrout> personally, I like containers, but i like raw resource as well ;)
<lazyPower> assuming lxd makes its way into CRI
<lazyPower> which i heard once, but haven't heard anything about since
<lazyPower> so we cant really commit to heresay
<Zic> FYI, I was not fan at all of container before K8S, because I saw containers as "devs wants to do silly things in my machines"
<magicaltrout> well everyone seems to think it will happen, without actually committing to it
<magicaltrout> and your commander in chief was like "we'll build the stuff, and someone else will plug it in "
<magicaltrout> who knowa
<Zic> with K8S, container in prod is a viable thing
<magicaltrout>  -a +s
<Zic> but since K8S, I just embrace the philosophy of microservices in prod
<magicaltrout> depends what you deploy though doesn't it
<Zic> before, it was just for me  a "lab for devs", and if docker image go in prod I was like "meh, it's running in the container, don't know, poke the dev"
<magicaltrout> you can't classify a 100 node hadoop cluster as a microservice :)
<lazyPower> ^
<lazyPower> that
<Zic> since K8S, we're more in the devops approach here (full-collaboration between dev & ops)
<Zic> (we don't wait K8S in fact :p but we envisage K8S to make things better to run container in prod)
<lazyPower> magicaltrout - and i get the point. Everyone wants it, and I'd love to have the time to work on that and get my hands dirty with the lxd team. but a) i'm not a go developer (yet) and b) without an official roadmap item, i cannot commit to anything happening anywhere. but i would suspect its brewing somewhere in the corners of canonical.  If not it'll be one of those "why haven't we done this yet? who's responsible" and then i'll get ot stand
<lazyPower>  on the carpet somewhere and answer to the bosses.
<magicaltrout> indeed
<magicaltrout> i don't doubt it
<Zic> lazyPower: slap if I'm indiscret, but are you directly working at Canonical?
<Zic> I thought so, but I saw in your slides that you put your @ubuntu.com mail, not the @canonical.com one :)
<lazyPower> Zic - yep. I'm co-architect of CDK with mbruzek
<Zic> so I'm asking :x
<lazyPower> Zic - i value the community contribution more than teh company contribution. I will be an ubuntu community member longer htan I will be a canonical employee (is my justification for that)
<Zic> lazyPower: like this kind of spirit :)
<Zic> (as an Ubuntu Member too :p)
<lazyPower> i have no plans on going anywhere, but we are who we are because we have awesome community members
<lazyPower> like yourself, who aren't afraid to break things and let us know how we can do better and even sometimes conetribute those better ideas
<lazyPower> *contribute
<lazyPower> so, rather than identify via my job, i'll identify via our contributions
<lazyPower> i also chose the ubuntu membership cloak instead of the canonical cloak (if you /whois me)
<lazyPower> little things like that :)
<lazyPower> i mean magicaltrout is about as much of an ubuntu member as any of us employed here :)  speaking of magicaltrout  - have you applied for membership?
<magicaltrout> dunno what you're talking about
<magicaltrout> i did get a canonical rucksack yesterday though
<magicaltrout> which was nice
<lazyPower> https://wiki.ubuntu.com/Membership
<Zic> lazyPower: my company wants to buy official support from Canonical for CDK, it's cool (as it's the way Canonical can makes money and continue to support Ubuntu), but I prefer to directly chat with the Juju team than the commercial support :)
<magicaltrout> you can do both Zic
<Zic> I will :p
<magicaltrout> that way lazyPower gets paid :P
<lazyPower> \o/
<lazyPower> and i like getting paid
<lazyPower> not gonna lie
<magicaltrout> pays for beer
<Zic> but in fact, I will reserve lazyPower for me, and let the Canonical support to my teamworker *evil laughing*
<bryan_att> stokachu: if I get it up and running, let me see what services are included and I'll get back to you. Apart from the basics, I do need Heat at least.
<Zic> (you can keep lazyPower's body, I'm just reserving his minds)
<lazyPower> this got awkward fast
<Zic> \o/
<Zic> as it sounds awkward in French, it's even worse in English
<lazyPower> https://imgflip.com/i/1jdjzm
<magicaltrout> don't worry lazyPower Zic told us he uses C for self pleasure earlier....
<Zic> lazyPower: even if I'm preferring IRC over Slack, /giphy miss in IRC :)
<Zic> lazyPower: anyway, do you think that we can obtain commercial support for a multi-master environment? as it's not marked as production-ready officially
<Zic> I don't even know if I will put multimaster in prod or just in preprod
<lazyPower> Zic  - thats one of our line items for GA, is to have HA master sorted
<Zic> (as we're planning to have a separate cluster for preprod)
<lazyPower> the only thing we dont have that i'm aware will be a request is federated clusters
<lazyPower> and i think once we finish our plumbing, get the upgrade story bulletproof, and have HA masters, we're basically at GA at that point.
<lazyPower> and our upgrades are looking pretty good so far, there's more work to be done
<lazyPower> but the 1.5.x to 1.6.x upgrade will be teh final boss test of that, and then its time to rubberstamp
<Zic> will gladly any troubles I will run of course :D
<Zic> +report
<lazyPower> :) we appreciate it
<Zic> I will let you know who is the customer when it will go prod :)
<Zic> (I think some of you may already know it)
<stormmore> howdy juju world!
<lazyPower> hey stormmore
<lazyPower> o/
<lazyPower> stormmore - also i know you were tracking this. HA master fixes incoming https://github.com/chuckbutler/kubernetes/commit/3320fc04015411cdc9ad44d98210ada5137537e3
<stormmore> lazyPower o/ good to have you back :)
<lazyPower> :D glad to be back. even if only for half a day. i'm about to bounce to get my new glasses (no more orange tape!)
<stormmore> lol I have http://www.clicmagneticglasses.com/ which freak some people out :)
<lazyPower> oh man i want some of these
<lazyPower> next year when the benefit has re-upped i might do this
<rick_h> yea, at first those were crazy but then I thought...that's a damn good idea
<stormmore> lazyPower, you will crack up at this. I am trying to architect a standalone master node!
<lazyPower> stormmore - why would i crack up at this? you can even do it as a phaux HA with lxd and a reverse proxy
<stormmore> rick_k and lazyPower I love mine :) have to order direct if you want anything more than a pair of readers
<stormmore> oh really! I was just thinking of creating a base Ubuntu install with MaaS, and KVM. Then have VMs for Juju, and k8s master then add other hardware nodes for the workers
<stormmore> lazyPower I am thinking of trying to make it useable for 1) air-gapped rooms and 2) to bootstrap additional data centers easily
<stormmore> lazyPower do you have a link for phaux HA?
<lazyPower> stormmore - nah i just cooked it up in my head. the premise is deploying to LXD on the unit, and setting up a reverse proxy for the apiserver endpoint
<lazyPower> so you could in theory, poke individual containers with upgrades and what not, and lose a container and still remain online.
<lazyPower> simulated HA via a single point of failure
<stormmore> a true DC in a box idea then :)
<lazyPower> stormmore - thats exactly what we did in Gent, ran a bunch of deployments in lxd
<lazyPower> people were kind of blown away that you can simulate network partitions and what not on a single box
<stormmore> I thought about that but I wasn't sure how to get the juju controller to handle the LXD and the ability to add hardware nodes through MaaS
<lazyPower> juju deploy --to lxd:# kubernetes-master
<lazyPower> the networkign there should work pretty well as spaces are fully supported on maas
<lazyPower> however we need to investigate extra bindings in the kube charms for that to be truly useful
<magicaltrout> if i get lxd in mesos i'm going to name it.... Fauxpenstack
<stormmore> oh I get that part but how do you configure the local juju controller ... yes I could use manual for it but then how do I get juju to add-node using maas
<lazyPower> next cycle maybe, we're pretty up to the gills in terms of features for this cycle.
<stormmore> it is basically the 1 controller - 2 cloud problem
<lazyPower> you could just juju deploy ubuntu to get a clean server install
<lazyPower> then use that machine # to start colocating the lxd services
<lazyPower> and scale out using juju add-unit ubuntu
<lazyPower> its not directly straight forward, but would work
<stormmore> at least from my understanding you would have to manually add each node to juju
<lazyPower> stormmore - lets follow up on this next week for a "for fun" session
<stormmore> lazyPower sounds "fun" ;-)
<lazyPower> i bet we can get you moving with minimal fuss modeling that as a distributed lxd service
<lazyPower> across many physical units
<stormmore> for the time being I am going to have VM and Physical nodes handled by MaaS
<bdx> lazyPower: "modeling that as a distributed lxd service" - I would love to know what you are talking about here
<bdx> :-)
<lazyPower> bdx nobody poked you ;)
<lazyPower> <3
<bdx> I heard distributed lxd service and I came running
<lazyPower> bdx yeah man, there's a lot we can do here, i'm sure we'll find an end of the sidewalk at some point but if we're as far along with networking in the MAAS substrate this should be completely doable with minimal mods to teh charms.
<lazyPower> and iirc, thats our furthest running story with regards to juju spaces networking
<stormmore> I am not sure if it would need to be a fully distributed lxd service (not that that wouldn't be cool too) but the ability to put all the management services on to the master node in lxds and add other k8s worker nodes that are hw / maas driven is basically want I am wondering about
<lazyPower> stormmore - completely doable. my manual environment is like that
<lazyPower> i have 3 workers that are just spare hardware, all the management/control-plane is either smashed on the metal or in lxd
<lazyPower> i dont recommend smashing on metal unless you like pain in the future
<stormmore> lazyPower yeah but it is manual, would be nice to use MaaS for the hw nodes ;-)
<lazyPower> same principal
<lazyPower> should be a similar path to success
<lazyPower> if you *need* to have the metal unit represented first, you can juju deploy ubuntu, that will give you a clean metal ubuntu image and you can start modeling there
 * lazyPower checks the juju help-commands to see if there's one to just reuqest a machine via the provider
<lazyPower> add-machine                Start a new, empty machine and optionally a container, or add a container to a machine.
<lazyPower> stormmore - juju add-machine --help
<lazyPower> absolutely no schenangans needed. add-machine can reuqest clean metal from the provider.
<lazyPower> well clean-metal being vm, container, metal, et-al
<stormmore> lazyPower I got juju running on localhost using juju deploy manual/localhost my-cluster but I couldn't figure out how to then point that controller to a maas cloud
<lazyPower> look at juju add-user/ juju grant
<lazyPower> you can take the output there and add it to your other juju workstation to control the controller.
<stormmore> ah you are still thinking that I would be managing this master from another system :)
<lazyPower> are you meaning a self hosted full stack juju bit?
<stormmore> the workflow I am looking at accomplishing is bootstrap juju on localhost and use that controller to hook into MaaS to add additional hosts. I believe there is only 1 controller per cloud rule
<lazyPower> oooo
<lazyPower> yeah your adds would be manual then
<lazyPower> and thats less than optimal
<lazyPower> at least if this is how i think it is
<stormmore> that is why I am thinking using MaaS and KVMs for the components other than k8s worker nodes
<stormmore> at least MaaS can handle both VMs and HW in the same controller
<stormmore> the end state (hopefully) will be the master node can act like a client as well when needed
<stormmore> or removed from the environment once the subservices have been hardened into the environment
<stormmore> the messy part is I am considering using Ansible to orchestrate the bootstrapping of this node as it doesn't need to bootstrapped itself
<lazyPower> you could probably get away with a pretty short bash script
<lazyPower> but i digress i need to jet to run some errands. keep me in the loop stormmore and i'm happy to lend a hand/input where applicable
<lazyPower> cheers o/ have a great weekend everyone
<derekcat> Anyone know where Juju keeps its known_hosts file?  It keeps telling me to delete the offending key in /tmp/ssh_known_hosts[numbers] when I try to juju ssh to a unit...  Machines originally added via: juju add-machine ssh:ubuntu@[ip address]
<derekcat> The /tmp/ssh_known_hosts file appears to be a very temporary file..  Gone by the time the ssh attempt fails.
<rahworks> hey sup everyone, I can't seem to login to jujucharms.com. can someone help me out
<rahworks> This is what i see when i try to login to juju charms.com
<rahworks> http://imgur.com/a/YZILS
<magicaltrout> yeah i think the SSO is having a fit
<magicaltrout> i can't get into the wiki either
<bdx> lazyPower: we are trying to install deis on cdk and getting some crazy errors ...
<bdx> lazyPower: have you installed deis on cdk successfully?
<bdx> lazyPower: were hitting this https://github.com/conjure-up/conjure-up/issues/520
<bdx> lazyPower: trying your workaround now
<stokachu> bdx, if you get it working can you post the steps in that bug?
<stokachu> so i can automate it
<bdx> stokachu: yes ... we are so close ...
<stokachu> thanks
<bdx> stokachu: `deis register deis.<mydomainname>.com` is whats failing us now ... I'll add to the bug
<stokachu> bdx, perfect
<derekcat> : Anyone know where Juju keeps its known_hosts file for manual/local machines?
<derekcat> It works if I run juju ssh --no-host-key-checks postgresql/14
<derekcat> but otherwise, it spits this at me:
<derekcat> Add correct host key in /tmp/ssh_known_hosts736182584 to get rid of this message.
<derekcat> Offending RSA key in /tmp/ssh_known_hosts736182584:7
<derekcat> Very similar to https://bugs.launchpad.net/juju/+bug/1646322  Except I'm using manual provider instead of openstack, hence the suggested solution is unrelated to this..
<mup> Bug #1646322: juju scp/ssh known hosts errors <landscape> <juju:New> <https://launchpad.net/bugs/1646322>
<derekcat> mup: haha nice timing.  Everything is in the same VLAN/subnet in my case..
<mup> derekcat: In-com-pre-hen-si-ble-ness.
<derekcat> mup: lol
<mup> derekcat: Roses are red, violets are blue, and I don't understand what you just said.
<derekcat> mup: my problem machine, juju-controller, and the machine I'm running commands from are all in the same network space. The other 5 machines in the model are all working fine, so I'm not sure what happened here..
<mup> derekcat: I apologize. I'm a program with a limited vocabulary.
<derekcat> mup: well that's ok, maybe the extra verboseness will help other people ^_-
<mup> derekcat: I really wish I understood what you're trying to do.
<derekcat> Also, no idea how the fingerprint could've changed as it doesn't appear to have been redeployed since I initially added the machine
<derekcat> >_<
<lazyPower> bdx looks like you didn't apply the work around. if you see port 443 - you're using the api load balancer, which doesn't support SPDY which in turn will fail the deis setup.
<lazyPower> bdx - https://kubernetes.io/docs/getting-started-guides/ubuntu/troubleshooting/#common-problems
<bdx> lazyPower: thanks ... we did apply the work around though ... it was failing the same way on 80 and 443
<lazyPower> bdx but the API endpoint should be 6443
<lazyPower> not 443
<lazyPower> 80 will always fail, as the apiserver requires strict tls key authentication
<bdx> ahhhh
<lazyPower> 443 might have worked, but the layer7 load balancer would be the blocker there and yield unhelpful error messaging
<bdx> I see that now
<lazyPower> so i suspect something didn't happen how we expected it to and that config is incorrect
<bdx> I see, that would make perfect sense
<lazyPower> https://kubernetes.io/docs/getting-started-guides/ubuntu/troubleshooting/#common-problems <- has the steps to manually fix this using some jq kung-fu and editing your kubeconfig
<lazyPower> sorry :( that should have worked, i did test it
<lazyPower> but i haven't tested it recently
<lazyPower> so its likely that something has changed and its botched on "fixing" the config file
<lazyPower> if this works i'll file a bug to investigate the config regeneration path and see if somethings funky in there or if this is unrelated and we have something else at play here, but deis has been deployed successfully via helm on CDK. Ben was a wizard at that and stokachu has been working through this as well (but i'm not certain if it was successful as I haven't followed up)
<bdx> lazyPower: I'll investigate this and get back to you
<bdx> lazyPower: thanks for following up
<lazyPower> np :)
<lazyPower> i just happened to stop in before i head out for the night. glad i caught you before we missed each other
<bdx> aha niccceeee
#juju 2017-02-11
<derekcat> No one has any idea :(?
<redir> derekat mup is a bot in case you didn't figure that out
<redir> derecat can you ssh without juju to that machine with the ubuntu user?
<redir> or can you juju ssh <machine> instead of unit?
 * redir eows
<redir> back on the 22nd
<Tyrantelf> Okay, stupid question but I'm doing a juju-quickstart.  How long should retrieving the environment status take?
<junaidali> Hi have anyone deployed rados-gw charm in HA? or is it possible?
<junaidali> nevermind, i just checked it provides HA support :)
<rick_h> Tyrantelf: hmm, quickstart is deprecated and only works with 1.25 on trusty. It depends on what cloud you're deploying on as to how long it should take.
<Tyrantelf> rick_h: yeah, i figured that out... Wish there was some documentation actually stating that clearly somewhere
#juju 2017-02-12
<thumper> delivery...
#juju 2018-02-05
<SUPERNETS> IRC.SUPERNETS.ORGÂ #SUPERBOWLÂ BESTÂ IRCÂ NETWORKÂ FUCKÂ YOURÂ NETWORK
<SUPERNETS> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
<SUPERNETS> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
<SUPERNETS> YOURÂ IRCÂ NETWORKÂ ISÂ TERRIBLEÂ NOÂ ONEÂ CHATSÂ THEREÂ COMEÂ CHATÂ HEREÂ 
<SUPERNETS> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
<SUPERNETS> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
<SUPERNETS> WEÂ TAKEÂ CHATSÂ TOÂ AÂ NEWÂ LEVEL,Â SOMETHINGÂ YOU'VEÂ NEVERÂ SEENÂ BEFORE
<SUPERNETS> wallyworld bitchecker anastasiamac thumper veebers nevermind el_tigro1 rogpeppe1 junaidali Spads jog_ skay kina__ niemeyer ryebot markthomas bladernr gaurangt mthaddon` icey seyeongkim diddledan mpontillo antdillon SaMnCo jdandrea_ mup jw4 dames tvansteenburgh drcode cmars axw Cynerva neclimdul arosales bobeo gaughen balloons mwe1 jhebden beisner joedborg smgoller- idobos CadBane eriklonroth
<SUPERNETS> john51 lathiat knobby narindergupta zerick mhall119 wolsen fnordahl ubuntulog3 zeus jhobbs obedmr gsamfira Cheeky-Celery verterok ubuntulog2 dnegreira atrius wgrant cory_f Odd_Bloke LiftedKilt heckles1000 coreycb bogdanteleaga xnox cargonza WillMoogle Lukewh tbc aisrael Makyo jose axino grumble magicaltrout med_ admcleod jcsackett ever pmatulis__ dweaver xavpaice jam plars lifeless hbogert_
<thumper> so convincing
<knobby> thumper: i am tempted. I don't know about you! :)
<blahdeblah> thumper: spam doesn't need to be convincing, all it needs is to get a few clicks
<thumper> who would be tempted I wonder?
<el_tigro1> you sure that was spam?
<thumper> of a sort... sure
<blahdeblah> thumper: There's a freenode bot you can invite into the channel to get it kicked from the network a bit quicker
 * blahdeblah rummages for the name
 * lifeless ponders directing a few Tbps to that user
<knobby> It does seem that if you are trying to get people to try something that spamming obscenities about this network isn't a good way to do that
<blahdeblah> thumper: Bot is called Sigyn
<blahdeblah> lifeless: They're probably using a victim machine/network - probably not the best idea
<thumper> yeah
<lifeless> blahdeblah: O I know. but the temptation :P
<lifeless> blahdeblah: it would at least stop the current spamm
<blahdeblah> lifeless: There's a reason it's called temptation :-)
<bobeo> kwmonroe: magicaltrout thats abosolutely amazing! I wish I could get good like that. Working on polishing up my linux mojo right now, learning how to make GUIs in bash, and how to work with EOFs, and sed & awk exercises. Hopefully learn why the kernel works some day
<bobeo> magicaltrout: kwmonroe Would you two recommend that someone put specific applications for administration into /usr/sbin , and applications for root level systems administration in /sbin ?
<bobeo> Im trying to figure out the best ways to divide my mantainence scripts and programs, so that I can lock the root account down to minimal use, while also using it to do tasks I want few, if any, other admins having access to
<bdx> bobeo: https://pdos.csail.mit.edu/6.828/2017/xv6.html
<bdx> bobeo: walk through ^ a few times
<bdx> bobeo: let me know if you have any questions
<bdx> I've worked through xv6 quite a few times .... it makes learning about the kernel more of a "bite size" experience
<bdx> which is super cool
<bobeo> bdx: oh...my...lawd....my brain...its talking about actually building a kernel, ITS LINUXFROMSCRATCH!!! OOH GAWD thE PAIN!
<bobeo> bdx: im already downloading it o.o
<bdx> bobeo: its already built
<bdx> its a very very simplified kernel and os
<bdx> so you can more easily inspect it and see whats going on
<bdx> bobeo: enjoy!
<bdx> oh yeah, my bad, the code is there, but you do have to run the make command to build it - for sure
<bobeo> bdx: wait...its a shitload of pieces? how do I run it? I feel like i just got a puppy in a box, how do I make it bark? D:
<bdx> haha
<bdx> yes
<bdx> very much so
<bobeo> the "make" command? Ive only used that once...and um...lets just say I had a full metal alchemist experience..
<bdx> aha
<bdx> it should take you 1-3 months to become familiar with the codebase of xv6 and the process of building the operating system
<bdx> its not something you are just going to "get"
<bdx> learning how the kernel and unix/linux os work is not a quick fast experience
<bobeo> bdx: wait...wait. this thing says the kernel is 1MB, seriously?
<bdx> yeah
<bobeo> bdx: dude..
<bobeo> bdx: thats amazing!
<bobeo> bdx: 8O is this how CONTAINERS WORK!?
<bdx> bobeo: aha, yea, many of the concepts in xv6, especially process confinement and system resource access will make you think of containers
<bobeo> bdx: I have found my miagi! Teach me sensei o.o
<bdx> bobeo: http://web.cecs.pdx.edu/~markem/CS333/ - this is a full xv6 class with all of the associated material (the same class and the same professor I took xv6 from)
<bdx> ^ that should be all you need
<bdx> just read and go through it like you were in the class
<bdx> everything you need is ^
<bobeo> bdx: oh to be in IRC! CHRISTMAS CAME EARLY!
<bdx> :)
<bobeo> bdx: So I have a question, if im not mistaken, someone said you made this: https://jujucharms.com/u/omnivector/owncloud/1
<bobeo> bdx: I love that you integrated postgres instead of mysql, or a backend nfs system, and I want to do the same thing with gitlab, but I also want to learn to do what you did to do this, so that i cna do this with other applications.
<bobeo> bdx: Im a big fan of postgres, and I understand it, as well as know how to cluster the databases, and loadbalance between them, so Id like to make that readily avaialble to others. Can you teach me, or show me something that can teach me that also?
<bobeo> is it possible to rename machines and/or units in juju?
<rick_h> bobeo: no, unfortunately not
<rick_h> bobeo: that'd be an interesting juju plugin, juju alias x y
<bobeo> rick_h: dang. Is it possible that when you deploy the machine or unit you can decide what its named, at creation. e.g.: juju deploy owncloud --config example.yaml --to lxd:9 --uname owncloud/0
<rick_h> bobeo: no, it's straight up auto number through the model/history.
<rick_h> bobeo: if names changed/etc it makes things like the audit log and such much harder
<bobeo> rick_h: BAH! sad panda :(. understood. cycles are best spent elsewhere for now. I will at it to my dreamlist.
<bdx> bobeo: https://jujucharms.com/u/omnivector/owncloud/6 - the latest revision 6 might give you better experience
<bobeo> bdx: oo! I shall indeed explore it, thank you! Also, is relating a web app like gitlab or owncloud as easy as juju relation postgresql:db webappname:postgresql
<bdx> bobeo: the codebase is here https://github.com/omnivector-solutions/layer-owncloud - you can ask questions about what is going on in the code on this channel if you have questions
<bobeo> is that really how the actual relationship is established, and it just auto deploys the db, and configures the app to use it?
<bdx> bobeo: yes
<bdx> `juju relate`
<bobeo> bdx: so does that mean if I do: juju relate postgresql:db gitlab:postgresql, gitlab will automatically use postgresql to store all of its files?
<bdx> bobeo: if you haven't already found rick_h's blog here  http://mitechie.com/blog/
<bdx> reading up ^ will help in learning about Juju more
<bdx> also reference https://jujucharms.com/docs/stable and try to find answers to your questions
<bobeo> bdx: Oh my lawd.... I swear youre a treasure trove.
<bdx> :)
<bobeo> bdx: Ive checked the docs on quite a few of these questions, and quite a lot of the questions were answered, but some of them im iffy on,and some im just outright confused
<bdx> cool, yeah, sometimes you just have to get some deeper insight .... another way to get feedback (and also contribute to Juju) is to create an issue on the Juju docs here https://github.com/juju/docs/issues when you can't seem to find the correct information
<bdx> bobeo: creating an issue on the juju docs will help the answer you are looking for make its way into the documentation if it isn't in there
<rick_h> always the balance of "OMG INFO OVERLOAD" vs "how can I get this going quickly and feel like I'm amazing?"
<kwmonroe> bobeo: fwiw, you *can* set the name at deployment time, but not the number.  so "juju deploy owncloud fooberrycloud" would deploy the owncloud charm, but you'd reference it as 'foobeerycloud/0'
<bobeo> rick_h: I dont want to feel like im amazing, I want to be the merge clone of kwmonroe rick_h and bdx , all in one super human cyborg form. Hellbent on collecting all of the infinity stones, the rings of power, and consuming the green latern core.
<kwmonroe> ha!
<bdx> bobeo: a broken and defeated, disfigured and demented being, damned to spend eternity in a dark hole, scratching at a keypad and burning its eyes out staring at a screen - thats just me
<bdx> not sure what you would get if you put kwmonroe + rick_h in the mix ... nothing good though, I can tell you that
<bdx> :P
<kwmonroe> lol
<kwmonroe> true dat
<rick_h> bdx :p
<ejat> hi...  in autopilot with maas , which juju charm did autopilot use for choosing compute (kvm & lxd) ? is it the same as openstack-base charm in store?
#juju 2018-02-06
<gsimondon> Hi, is there a way to NOT use ncurses based UI during Canonical K8s installation?
<magicaltrout> gsimondon: depends where you're trying to install it
<magicaltrout> if you're doing a local LXD install you'd have some fun
<magicaltrout> if you're doing a cloud based install, you can  juju bootstrap and then just juju deploy canonical-kubernetes
<magicaltrout> you don't have to use conjure up
<gsimondon> doing bare metal
<gsimondon> @magicaltrout all localhost, bare metal, multi node proof of concept installation
<gsimondon> @magicaltrout but I don't want any UIs and I want to automate the process... without hacking around
<magicaltrout> sorry gsimondon yeah in that case you can do what I do all the time
<magicaltrout> and do a juju manual cloud bootstrap
<magicaltrout> and then just place workloads on units
<magicaltrout> https://jujucharms.com/docs/2.2/clouds-manual
<magicaltrout> that one
<magicaltrout> then i usually just look at https://api.jujucharms.com/charmstore/v5/canonical-kubernetes/archive/bundle.yaml
<magicaltrout> and "juju deploy" the required services and then "juju add-relation" to join them up
<magicaltrout> so if you have 5 baremetal servers you could do
<magicaltrout> juju deploy easyrsa --to 1
<magicaltrout> juju deploy etcd --to 1
<magicaltrout> juju deploy kubernetes-master --to 2
<magicaltrout> and so on
<magicaltrout> then
<magicaltrout> juju add-relation kubernetes-master etcd
<magicaltrout> etc
<rick_h> magicaltrout: gsimondon to be fair, with the 2.3 work you can update the bundle machine numbers and use --use-existing
<rick_h> to help automate it into a single bundle deploy now
<magicaltrout> ah yeah
<magicaltrout> forgot about that
<rick_h> life-easier++
<gsimondon> rick_h: magicaltrout, thanks a lot.
<kwmonroe> magicaltrout: there's also conjure-up in headless mode.. if you specify the spell plus a cloud, c-u will do it's thing with all defaults selected.  it will try to bootstrap, but you can also specify a pre-existing controller... so if i have a bootstrapped controller called aws-e, this will do a headless deploy of k8s-core: conjure-up kubernetes-core aws/us-east-1 aws-e
<kwmonroe> i know gsimondon already left, so that's just an fyi for you magicaltrout.  you're welcome.
<kwmonroe> aaaand docs, https://docs.ubuntu.com/conjure-up/2.2.0/en/usage#running-in-headless-mode
<rick_h> kwmonroe: oooh, more learnings
<rick_h> lol
<kwmonroe> rick_h: put that in your tips & tricks doc ;)
<kwmonroe> jk, i know you don't have one.
<rick_h> kwmonroe: :P
<kwmonroe> hey cory_fu, what's a good convention for setting a new key with data_changed('foo', bar)?  i'm trying to avoid name collision.  do most people prefix the key with the layer name?  or does data_changed jam some uuid in front of the key already?
<kwmonroe> nm cory_fu, i see https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/helpers.py#L144.  i will make my own uniqueness.
<kwmonroe> though it's nice to know it's somewhat isolated with reactive.data_chagned.
<cory_fu> kwmonroe: Yeah, there's not really a way it could reliably do a uuid, so it's up to you, but it does have the built-in prefix and I'd recommend using the layer name as well
<kwmonroe> +1 cory_fu
<arosales> manual provider question on juju 2.3
<arosales> I can `ssh ubuntu@<ip>` from my client machine
<arosales> but from that same machine when I try to bootstrap the manual provider I get "Permissioned denied (publickey)"
<arosales> any tips in juju 2.3 and manual provider I should be aware of ?
<thumper> o/ arosales
<thumper> arosales: I only got the last two lines of your post... what is the issue?
<arosales> thumper: hello :-)
<arosales> thumper: https://paste.ubuntu.com/26531789/
<thumper> arosales: um... did you try to bootstrap manual from within the machine itself?
<arosales> nope, client is on my laptop where ssh keys are
<arosales> bootstrap node is on DigitalOcean
<arosales> I also sshed into the target node and imported my ssh keys just to be sure
<arosales> confusing part is I can ssh just fine from the same node I am trying to bootstrap from
<thumper> arosales: when adding the ipaddress for the cloud
<thumper> try ubuntu@...
<yosefrow> arosales, maybe its using the keys in ~/.local/share/juju/ssh
<arosales> from --debug I saw juju grabbing my key from ~/.ssh/id_rsa.pub
<arosales> but perhaps it is not actually using it . .  .
<arosales> I can try to put my key into ~/.local/share/juju/ssh
<yosefrow> @arosales, I wouldnt suggest overriding the key in ~/.local/share/juju/ssh because juju may have installed it elsewhere. Instead, you can try adding ~/.local/share/juju/ssh public key to the node you are trying to manually bootstrap
<yosefrow> in the remote nodes authorized_keys file
<arosales> to confirm my understanding though if I can `ssh ubuntu@<ip>` then juju should be able to ssh to the same node, correct?
<yosefrow> @arosales, this part isnt clear to me. But as i said if you are trying to troubleshoot. You can *try* to add the pubkey in ~/.local/share/juju/ssh to the authorized_keys file in the remote node. I honestly dont know why you cant ssh there
<yosefrow> via juju
<magicaltrout> i ended up in a weird loop back ssh thing arosales a few months ago
<magicaltrout> where the remote machine and my local machine had the same key
<magicaltrout> and it got very confused
<arosales> yosefrow: the target node will not have ~/.local/share/juju/ssh initially
<arosales> it will just be stock ubuntu with my ssh key on it
<arosales> magicaltrout: what did you do to resolve?
<thumper> arosales: it is probably trying to use your name for the SSH key source on the target machine
<yosefrow> @arosales, i meant to try to put the public key from your juju client machine folder ~/.local/share/juju/ssh into ~/.ssh/authorized_keys on the remote mahcine. but its just a shot in the dark
<thumper> you only entered the ip address of the machine (which admittingly is all it asked for)
<thumper> but I think you need to say ubuntu@59.65.74.150
<thumper> ubuntu@159.65.74.150
<arosales> thumper: ahhh, let me try that
<yosefrow> @arosales, did you manually edit your target nodes ~/.ssh/authorized_keys?
<yosefrow> nevermind i saw earlier that you did
<magicaltrout> just juggled my keys around arosales
<arosales> thumper: https://paste.ubuntu.com/26531916/
<arosales> thumper: looking for ubuntu on my laptop now . .  .
<arosales> magicaltrout: gotcha
<yosefrow> @arosales, the issue was you were trying to use a hostname instead of ip?
<arosales> I was only using IP
<yosefrow> aaah
<arosales> thumper suggested I append a user name
<yosefrow> @thumper, arosales , this line is misleading: Enter the controller's hostname or IP address: ubuntu@159.65.74.150
<yosefrow> it should probably say ssh login or user@hostname
<yosefrow> seems like a kind of bug to me
<arosales> well putting ubuntu@<IP> didn't work for me
<arosales> looks for ubuntu on my local machine, which doesn't exist
<yosefrow> @arosales, it looks like earlier you just tried ip and it failed, then you tried ubuntu@ip and then it worked. Is this correct?
<arosales> negative
<arosales> did _not_ work with ubuntu@ip
<yosefrow> @arosales, try adding the user ubuntu
<yosefrow> to the machine you are trying to add
<arosales> its there on the target controller
<arosales> I can `ssh ubuntu@<IP>`
<yosefrow> from your current user?
<yosefrow> the same user you are using to bootstrap juju?
<arosales> correct
<yosefrow> @arosales, juju bootstrap manual/192.168.1.128 mycloud
<yosefrow> https://jujucharms.com/docs/2.3/clouds-manual
<yosefrow> so in your case juju bootstrap manual/159.65.74.150 po1
<arosales> yosefrow: also tried that, and didn't work --- note you have to drop the last arg. In your command "po1"
<yosefrow> why would you drop the last arg ?
<yosefrow> wiki says to include it, doesnt it?
<arosales> yosefrow: https://paste.ubuntu.com/26531977/
<arosales> the docs do, but alas
<yosefrow> what version of juju are you using?
<arosales> 2.3.1-xenial-amd64
<yosefrow> docs for 2.3 say Usage: juju bootstrap [options] [<cloud name>[/region] [<controller name>]]
<yosefrow> ,
<arosales> looks like a 2.3.2 may be out there. I'll see if that has the same results
<yosefrow> @arosales, not $ juju bootstrap 159.65.74.150 manual/159.65.74.150 do
<yosefrow> instead do $ juju bootstrap manual/159.65.74.150 do
<arosales> yosefrow: did you see my pastbin?
<yosefrow> yes you have an extra ip
<yosefrow> in there
<arosales> ah yes, my syntax error
<arosales> same perm error
<yosefrow> patebin?
<arosales> https://paste.ubuntu.com/26532007/
<arosales> same error with 2.3.2 and manually adding ~/.local/share/juju/ssh/juju_id_rsa.pub juju-client-key to the authorized_keys file for both root and ubuntu users on the target bootstrap node
<yosefrow> hmmm
<yosefrow> i did this before
<yosefrow> and it was easy. thats why this is stumping me now
<yosefrow> i wish i had documented it
<yosefrow> let me examine the error again
<arosales> no worries, yosefrow I appreciate the help
<arosales> I can add anyone's ssh key to this server if they want to try and bootstrap
<arosales> right now its just a test machine
<arosales> in theory juju just need ssh key access to the machine, which I thought it would get from ~/.ssh/
<arosales> obviously I am missing something
<yosefrow> look in ~/.local/share/juju for a file called environments
<yosefrow> environments.yaml
<arosales> yosefrow: doesn't exist on my machine
<yosefrow> @arosales, i see an archaic usage of bootstrap-user probably not used anymore in 2.3
 * arosales nods
<yosefrow> whats your juju client user?
<yosefrow> arosales?
<arosales> I believe so, how do I confirm?
<yosefrow> `whoami`
<arosales> oh, just on the local machine -- yes "arosales"
<yosefrow> mv ~/.juju to ~/.juju.bak, remove ubuntu user from the remote machine
<yosefrow> lets start over
<yosefrow> remove ubuntu user in remote machine if not needed
<yosefrow> @arosales,
<yosefrow> let me know when you done it
<arosales> done, I'll start with a fresh DO instance as well
<yosefrow> sorry meant to say mv ~/.local/share/juju
<yosefrow> to ~/.local/share/juju.bak
<yosefrow> mv ~/.cache/juju to ~/.cache/juju.bak as well
<arosales> k, done
<yosefrow> create a new manual cloud specify just the ip of the node u want to be controller
<arosales> k, done
<yosefrow> ssh-copy-id user@host-ip
<yosefrow> to add ur key to new bootstrap node
<yosefrow> then ssh user@host-ip
<yosefrow> @arosales,
<yosefrow> which user are you using to login to the remote node?
<arosales> root is the only user on the target controller node
<yosefrow> you added the key for root user?
<arosales> no I just added my ssh key when making the instance
<arosales> that got added to the authorized_keys on the root account on the target machine
<arosales> so I can ssh root@<ip>
<yosefrow> i have an idea
<kwmonroe> ;
<yosefrow> @arosales,from root@remote-host$ adduser ubuntu; adduser ubuntu sudo; passwd ubuntu (set some passwd),. Then from juju client create a new cloud, add a new cloud, this time use ubuntu@159.65.74.150 instead of just the ip, ok then finally try to bootstrap to the second cloud
<yosefrow> when it bootstraps it will login, then ask for a passwd
<yosefrow> enter the passwd you created in the previous step
<yosefrow> ill brb to see how it goes
<arosales> I did that exact thing with https://paste.ubuntu.com/26531789/
<arosales> I then tried ubuntu@<ip> and that also failed per thumpers suggestion
<arosales> ubuntu disables login via username/password by default. It seems juju ends up looking for a Ubuntu user locally to sudo to and fails
<yosefrow> @arosales, show me the output from trying to login to the second cloud i said you should make, where the host is not just the ip but ubuntu@ip
<yosefrow> Enter the controller's hostname or IP address: ubuntu@159.65.74.150
<yosefrow> instead of Enter the controller's hostname or IP address: 159.65.74.150
<yosefrow> @arosales, last time your output was https://paste.ubuntu.com/26531916/. this time you should get the same output, except now, you should enter the password for ubuntu that you created in the previous step
<yosefrow> it appears that juju is logging in successfully via ssh and then attempting to run a command on the remote host with sudo
<arosales> yosefrow: https://paste.ubuntu.com/26531916/
<yosefrow> great
<yosefrow> enter the password you created
<yosefrow> on the remote host
<kwmonroe> arosales: when you're done messing around, use root@<do-ip> as your cloud.  https://paste.ubuntu.com/26532245/
<arosales> thanks kwmonroe that worked
<arosales> yosefrow: complained about Ubuntu not being in sudo file, but I think I could have added it and it may have worked
<arosales> root worked with out having to mess with Ubuntu
<kwmonroe> i'm sure adding the ubuntu user first and doing key mgmnt will probably get ya there, but since DO gives you root and jams your key in there, i say use it!  with metldown and spectre, logging in as root across the internet is the least of your worries ;)  now where's my $5 arosales?
<arosales> kwmonroe: put it on my tab
<kwmonroe> ha!
<yosefrow> @arosales, ubuntu complained because you probably skipped `adduser ubuntu command"
<yosefrow> @kwmonroe, has a good workaround, but personally i prefer not directly ssh as root
<kwmonroe> yeah yosefrow, i didn't mean to interrupt there, but you guys were messing up my backscroll.
<magicaltrout> i'll mess up your backscroll
<yosefrow> lol
<kwmonroe> gah!
<yosefrow> kwmonroe, i thought the point of this chat was to demonstrate how to solve juju related issues and other juju related chat
<arosales> yosefrow: thanks or sticking with it for me
<yosefrow> should i have answered him in private messages?
<arosales> yosefrow: kwmonroe  can tell you I am a tough customer
<arosales> next charmer summit I'll buy beers
<yosefrow> @arosales, I still think you should do it the way I suggested if you want to follow best practices
<arosales> were you guys at config mgmt camp?
<yosefrow> but if you want a quick solution then kwmonroe is 100% correct
<yosefrow> @arosales, wasnt there
<kwmonroe> yosefrow: i was totally messing around -- and no, you don't want to get arosales in a PM.  what you guys were walking through was all good.
<yosefrow> kwmonroe, ah ok xD
<yosefrow> @kwmonroe, i might write a blog post about this chat soon
<yosefrow> we'll see
<arosales> yosefrow: I can see the light at that tunnel, the odd thing was that I had created the ubuntu user and added "ubuntu" to the sudoers via `usermod -aG sudo ubuntu`
<arosales> but not dice
<kwmonroe> yosefrow: +1, and if you do, arosales will send you $5
<arosales> but most likely fat fingered it.
<arosales> kwmonroe: lol
<arosales> in IOUB
<yosefrow> @arosales, thats quite strange
<yosefrow> @arosales, ok well in that case nevermind. the cake goes to @kwmonroe
<yosefrow> i was certain that should work
<yosefrow> @kwmonroe, save me a slice of cake
<kwmonroe> so it looks like the manual provisioner really wants to add the ubuntu user:  https://github.com/juju/juju/blob/develop/provider/manual/provider.go#L30
<kwmonroe> that calls out to https://github.com/juju/juju/blob/develop/environs/manual/sshprovisioner/sshprovisioner.go#L31, which lists the preconditions which will skip that init
<kwmonroe> yosefrow: arosales, so i think the key takeaway might be that arosales' ubuntu user needed to have passwordless sudo access.
<kwmonroe> anyway, root4life
<yosefrow> @kwmonroe, rootkits4life :P
<kwmonroe> lol
<arosales> man kwmonroe reading Go code now ;-)
<kwmonroe> nah, i just have thumper in a side channel telling me what to type
<arosales> you must have stopped drinking early PM brews
<kwmonroe> them's fightin words
<arosales> rofl
<yosefrow> @arosales, if you want to do with ubuntu user take kwmonroe suggestion and `visudo`. then https://serverfault.com/questions/160581/how-to-setup-passwordless-sudo-on-linux
<yosefrow> i suspected as much as well
<yosefrow> i honestly forgot how i got it to work last time, but probably like that
<yosefrow> @kwmonroe, did thumper get pissed off with me banging my head against the wall trying to help @arosales ?
<arosales> that makes sense since I could sudo apt get with the ubuntu user, but failed when Juju tried
<yosefrow> @kwmonroe, arosales anyway that was interesting. Glad we found a solution. laters
<kwmonroe> yosefrow: no, thumper doesn't get pissed.  he writes go.  good time today, have a good one!
<arosales> thanks yosefrow, kwmonroe, magicaltrout, and thumper for the help
 * thumper was on calls, soryr
<yosefrow> wb thumper
<cory_fu> stub: Hey, could you update juju-wait on pypi to match the snap, please, when you get a chance?
#juju 2018-02-07
<stub> cory_fu: whoops, sorry.
<stub> uploaded
<elmaciej> Hello! Does anyone have expierience with installing mapr using juju
<rick_h> Sorry elmaciej  not done it here. What charm are you using and what are you hitting?
<SuneK> Hi, I'm trying to deploy the canonical kubernetes cluster through juju gui. I exported and modified the yaml file to add constraints for the workers, however these constraints were not met by the provisioned machines.
<SuneK> (Of course I also reimported the updated yaml file :-)
<SuneK> I know I could just add constraints to the machines, but as far as I understood adding the constraints to the applications, should ensure, that the application was deployed on machines with sufficient resources
<SuneK> msg NickServ register 0G2YOU8ipDoh sune.kjaergaard@gmail.com
<SuneK> lol
<cory_fu> stub: Thanks.  Any chance we could automate the release process somehow so that they stay in sync?  Or perhaps give me and / or tvansteenburgh access on pypi to update it if it's missed?  We depend on the pypi version in conjure-up (we use pypi to bundle it into the snap)
<stub> PPA gets built automatically, snap published to edge automatically but needs manual promotion to stable (by me, since snapstore doesn't have teams), pypi isn't automatic
<stub> I can give you and Tim access to Pypi, sure
<cory_fu> Thanks.  That'll at least take care of the case where one or two of us is unavailable
<stub> It will lose gpg signing by my key, but I don't think anyone in the real world cares about that.
<akshay__> Hi All, on my OCATA setup (openstack+my application) when I revert the snapshot to openstack only state and then try to re-deploy my application it is not allowing me to add relation and errors out as the relation being added already exists. Can someone please help me out.
<stub> cory_fu: Is done
<cory_fu> stub: Thanks!
<kwmonroe> rats, i missed SuneK.  if that person comes back with the application vs machine contraint issue, it's bug 1676986.  workaround is that you need machine constraints to affect initial bundle deployment; app constraints alone won't do it.
<mup> Bug #1676986: juju doesn't honor bundle application constraints (2.1.2) <constraints> <juju:Invalid> <https://launchpad.net/bugs/1676986>
<magicaltrout> is there an answer you don't know kwmonroe .......
<kwmonroe> magicaltrout: i don't know why you keep messing with my backscroll!
<rick_h> kwmonroe: magicaltrout bdx hml externalreality_ and folks a heads up on juju show in 105min
<hml> rick_h: :-) - whatâs todayâs topic?
<hml> agprado: ^^
<rick_h> hml: upgrading juju
<rick_h> agprado: that's what I was looking for. I was looking in the G's trying to find his nick
<rick_h> hml: IS has a cool tool for upgrading juju controllers and models I want to show off and get folks involved with
<yosefrow_> @kwmonroe, is it possible yet to deploy a bundle with a manual cloud. iirc last time I tried that, it failed because juju could not use the manually added machines to deploy for some reason.
<rick_h> yosefrow_: so the newer juju supports a flag on bundle deploy --use-existing that should work out for you
<rick_h> oh damn too slow and wrong command https://jujucharms.com/docs/2.3/charms-bundles#recycling-machines
<kwmonroe> heh
<kwmonroe> he'll be back.  they always come back.
 * rick_h adds that as a note to the juju show
<rick_h> 30min! and then party time!
<yosefrow> rick_h, wheres the party?
<rick_h> yosefrow: juju show in 26min!
<yosefrow> :o
<yosefrow> where?
<rick_h> yosefrow: and https://jujucharms.com/docs/2.3/charms-bundles#recycling-machines for ya
<rick_h> yosefrow: https://www.youtube.com/watch?v=Pkbp4VK8-vo
<rick_h> at the top of the hour
<yosefrow> @rick_h, this was in answer to my question?
<yosefrow> recycling
<rick_h> yosefrow: yep, if I understand your question correctly
<yosefrow> this looks amazing
<yosefrow> its probably exactly what i need
<yosefrow> wish i knew about that months ago
<rick_h> yosefrow: well it's a month old I think in the last release or two
<yosefrow> ah i heard about it then
<rick_h> so yea, added a note to mention it on the juju show today in case it slipped by others
<yosefrow> when i originally had the problem i complained to canonical and they said is a feature coming to the next release
<yosefrow> @rick_h, specifically useful when deploying manual cloud
<rick_h> yosefrow: definitely
<rick_h> yosefrow: what machines are you running on then?
<rick_h> yosefrow: is it something we don't support as a cloud or just machines lying around or ?
<yosefrow> my use case is 3 nodes manually provided by a client who doesnt want me to access their hypervisor. Then bootstrapping to kvm node on management node and deploying k8s to the 3 manual nodes with a bundle
<rick_h> yosefrow: oic
<yosefrow> i fell short of deployment and was forced to use rancher
<yosefrow> because juju insisted on ignoring my manually added machines
<yosefrow> glad to see this fixed
<rick_h> yosefrow: definitely
<yosefrow> ill include it in my blog post about manual deployment with juju when i get around to it
<rick_h> yosefrow: I'd love to see it when you get around to it
<yosefrow> sure
<yosefrow> you can see my previous posts and correct any glaring issues if you want
<yosefrow> havent had many ppl review it and im wondering if my posts are clear enough
<yosefrow> rick_h, do you work with maas much?
<rick_h> yosefrow: I use it, I've got my own maas cluster at the house I use for testing and such but don't work on it
<rick_h> yosefrow: but I'm a fan :)
<yosefrow> cool
<yosefrow> how deeply are you involved with juju?
<rick_h> I think it really solves a cool problem that more folks have than realize (maas that is)
<rick_h> I've worked all around it for a while. I'm pretty involved.
<rick_h> (juju that is)
<yosefrow> nice
<yosefrow> you write code for juju?
<rick_h> I've written more code around juju, the gui, the charmstore, etc. I've not written the main juju Go code. I work with those teams a lot.
<yosefrow> cool :o
<yosefrow> Im confident that Juju / MAAS have a prominent place in the present and future of cloud computing
<yosefrow> Without them my life would be a nightmare
<rick_h> yosefrow: glad to hear. hopefully the updates get your deploys going smoother
<rick_h> https://hangouts.google.com/hangouts/_/kzm7m5vmn5f5lbfm5yr4wkowk4e bdx kwmonroe hml agprado externalreality_  and such for joining the hangout
<yosefrow> rick_h, before juju was not on option for certain clients. now it is. I just need to test it
<rick_h> https://www.youtube.com/watch?v=Pkbp4VK8-vo for watching in 7 min
<rick_h> yosefrow: if you hit anything you know where to find us :)
<yosefrow> hehe yep :)
<zeestrat> rick_h: A tip on how to build older juju clients would be handy too for us stragglers who need to test things in staging
<zeestrat> rick_h: Would love to crib some notes.
<rick_h> zeestrat: gotcha, will put together a pastebin for you
<zeestrat> Thanks
<yosefrow> @rick_h, well that was fun. I originally meant to join as a spectator, but I guess it all worked out. How often do you do this show?
<rick_h> yosefrow: every two weeks, same bat time, same bat channel
<yosefrow> juju operates on bat time?
<rick_h> yosefrow: http://youtube.com/jujucharms check out the playlist for the juju show
<rick_h> yosefrow: is there any other? :P
<yosefrow> hehe\
<rick_h> zeestrat: https://pastebin.canonical.com/209481/ is the gist of what I did
<rick_h> zeestrat: that creates a bin directory with a juju in it juju-core_2.2.9/bin/juju
<rick_h> I *think* those are the steps needed. I had to monkey around a bit to get it to work but think these are the required ones
<yosefrow> rick_h, while you are here, do you know off the top of your head if theres a way to customize the location of the juju gui download automatically downloaded when you bootstrap, or a way to skip the gui being installed so that the installation does not timeout?
<yosefrow> this becomes in an issue in ari-gapped environments
<zeestrat> rick_h: Getting "You do not currently have access to the pastebin." Internal only?
<yosefrow> air-gapped*
<rick_h> yosefrow: yes, there's a --no-gui option to bootstrap and then you can always download any gui release tarball and use that as an upgrade-gui command
<rick_h> zeestrat: oh doh my bad
<rick_h> yosefrow: https://github.com/juju/juju-gui/releases
<rick_h> zeestrat: try https://paste.ubuntu.com/26537367/
<zeestrat> ty
<yosefrow> rick_h, is this the recommended way of performing air gapped installs?, or is a kind of --gui-url option being planned ?
<rick_h> yosefrow: no, nothing in the plans. Worth a bug perhaps but unfortunately not a priority there since there's the work around
<yosefrow> understood. noting the workaround. Thanks
<yosefrow> I wish I joined this channel earlier instead of futzing around on my own for so long. You guys are totally cool
<yosefrow> Thanks for all the help
<rick_h> yosefrow: no problem, thanks for hacking with stuff and definitely we want people to use our stuff :)
<yosefrow> rick_h, This is cutting edge stuff. So I'm glad to be part of the juju movement, even if just as a user/bug reporter.
<yosefrow> Ill definitely report bugs and clarify any roadblocks i run into here
<rick_h> <3
<ryebot> I'm having a hard time getting the cloudinit-userdata model config to work: https://gist.github.com/wwwtyro/77d79e971f8c79590ea47e87b4875d8a
<ryebot> I've tried numerous permutations, but I never see anything set in /var/lib/cloud/instance/user-data.txt.i or any of its siblings
<ryebot> Any suggestions/examples?
<thumper> ryebot: which version of juju are you using?
<thumper> hml: ^^
<ryebot> @thumper: 2.3.2
<ryebot> thumper: I just discovered this: https://github.com/juju/juju/blob/2.3/cloudconfig/userdatacfg_unix.go#L357
<ryebot> which invalidates that experiment
<ryebot> but I'm trying to get ca-certs to work
<ryebot> I'm going to try with final_message next and see if I can even get it to show up
<hml> ryebot: packages should be allowed - they are handled separately
<hml> ryebot: they are merged into the juju packages list
<hml> ryebot: any chance you can check the cloudinit log files on the machine?
<ryebot> hml: yeah no problem
<ryebot> hml: anything in particular you'd like me to look for?
<hml> ryebot: see what references to ack-grep there are.  did it find it in the cloud init files and were there problems installing it
<hml> ryebot: you can also see if it make it into /var/lib/cloud/instance/user-data.txt.i
<ryebot> hml: no references to ack-grep in /var/log/cloud-init.log or /var/log/cloud-init-output.log
<ryebot> hml: it's not in /var/lib/cloud/instance/user-data.txt.i either
<hml> ryebot: hrmâ¦
<hml> ryebot: trying something in my setup
<ryebot> hml sweet thanks
<ryebot> hml: fwiw, I wasn't able to get final_message or ca-certs to work either
<hml> ryebot: youâre config file worked locally for me
<ryebot> well, poop
<hml> ryebot: what series are you using?
<ryebot> hml xenial
 * hml scratching head
<ryebot> hml: are you on 2.3.2? or dev branch or?
<hml> ryebot: iâm on dev right now - but it works on 2.3.2, went in for 2.3.1, but iâll double check 2.3.2 in a minute to be paranoid
<ryebot> hml: also did you try with a fresh model? I've been reusing the same model and just launching a new machine after each model-config change
<hml> ryebot: i had to bootstrap - so itâs all fresh
<hml> ryebot: did you bootstrap 2.3.2 or upgrade?
<ryebot> gah, my controller is 2.3.1
<ryebot> dangit
<ryebot> lemme bootstrap a new one
<rick_h> ryebot: upgrade! /me did the juju-upgrader tool in the juju show today
<rick_h> vs bootstrap, oh except I see there's some question of issues with an upgraded setup
<ryebot> rick_h: hmm well I probably should have to add another datapoint, but too late now
<ryebot> rick_h: I'll remember next time :)
<SuneK> Hi I need some help understanding constraints
<SuneK> I was under the impression that when i specify a constraint for an application in a bundle, juju would provision machines that met those constraints?
<knobby> that would be my assumption as well. What specific constraint are you using and in what environment?
<SuneK> I'm trying to setup the canonical kubernetes distribution
<knobby> on bare metal, aws, gce?
<SuneK> on vsphere
<SuneK> So i loaded the bundle in the juju gui, exported it, and added constraints for the worker nodes, and reimported it to my model
<SuneK> But the machines created are way to small
<SuneK> I know i could set constraints for the machines themselves, but that's not how it's suppose to be (in my mind at least)
<kwmonroe> SuneK!!
<knobby> I'm not sure about vsphere and constraints. I thought I saw something about that in an issue recently but I can't find it now. Maybe one of the juju guys can help.
<SuneK> kwmonroe: ?
<kwmonroe> SuneK: sorry, i forgot to paste the thing i was exlaiming you for...
<kwmonroe> so, earlier you asked about this constraint thing, but i wasn't fast enough with the reply before you dropped..
<kwmonroe> here's the deal:  bug 1676986
<mup> Bug #1676986: juju doesn't honor bundle application constraints (2.1.2) <constraints> <juju:Invalid> <https://launchpad.net/bugs/1676986>
<SuneK> Yeah sorry about that; I had to pickup kids :-)
<kwmonroe> SuneK: on initial deploy, machine contraints will take prescedent.  application constraints will take effect for stuff like "add-unit"
<SuneK> But thanks, I'll look into that
<SuneK> Ok, well now there's an explanation, I can work around that
<SuneK> Thanks again!
<kwmonroe> np
#juju 2018-02-08
<jhebden> erm, am I right in my assumption that 1.25 doesn't have network-get, and that charmhelpers' network_get function is broken on it?
<jhebden> it seems that I am
<icey> is it possible to get stdout from `juju run` in a streaming fashion? It seems that stdout from the `juju run` is only passed back to the caller after command completion, unless I'm missing something?
<icey> beisner: unless it would be OK to _not_ have 0-downtime, I'm looking at rolling style, but I could just tell it to do the release upgrade on all units in the model
<icey> :-/ sorry, wrong channel
<stub> icey: If you don't need to run under a hook context, 'juju ssh' might be what you need.
<icey> stub: I suppose I don't need the hook context, I'm doing a `do-release-upgrade` ;-)
 * stub wonders if he should add that as an action to the apt layer
<icey> could be nice, but I don't have layers ;-)
<SuneK> I'm trying to add Kibana to a machine in my model, but I get this error: "Error placing unit: unable to place a trusty unit on the xenial machine new8"
<SuneK> I'm unsure of the cause though
<zeestrat> SuneK: Sounds like it's trying to deploy the trusty version of the kibana charm to a xenial machine. Try adding --series xenial to your juju deploy command
<SuneK> Makes sense, thanks
<zeestrat> SuneK: np. Normally I'd expect juju to figure that out. Are you doing juju deploy kibana or deploying a bundle? Also what kind of cloud, lxd, manual?
<rick_h> zeestrat: SuneK yea, the issue there is that rather than assume it fails something it knows isn't valid
<kwmonroe> SuneK: if you're deploying a bundle, please let me know which one.  i've made lots of changes around the elk stack in the last 2 weeks to polish things up for xenial, but i may have missed a bundle or two.
<SuneK> @kwmonroe I'm deploying the canonica-kubernetes-elastic bundle https://jujucharms.com/canonical-kubernetes-elastic/
<kwmonroe> SuneK: roger that.. make sure you use the latest edge version to pick up xenial kibana:  https://jujucharms.com/canonical-kubernetes-elastic/104.  if you're doing this from cli, that's: juju deploy canonical-kubernetes-elastic --channel edge
<SuneK> kwmonroe: ok, I will do that, normally though I prefer stable versions for production use :-)
<zeestrat> rick_h: So I built 2.1.2 with snapcraft which was really easy, but now I'm stumbling at no matching tools. I haven't messed much with uploading or customized agents so there's probably something obvious I'm missing. Am doing something dumb? https://paste.ubuntu.com/26541861/
<SuneK> Got to go now though, i'll report back tomorrow
<rick_h> zeestrat: hmm, not sure tbh. I thought it would know this and auto upload from your own built version.
<rick_h> zeestrat: have to ask around, cory_fu any ideas? ^
<cory_fu> rick_h, zeestrat: Maybe 2.1.2 doesn't support bionic?  You might try --bootstrap-series=xenial
<zeestrat> cory_fu, rick_h That did the trick, thanks. Not sure why it tried to bootstrap bionic.
<zeestrat> Is that default expected behavior?
<cory_fu> zeestrat: I think it defaults to whatever your host system is.  I assume you're running bionic?
<zeestrat> Nope, xenial
<cory_fu> Oh, strange
<cory_fu> Maybe bionic is the default in simplestreams?
<zeestrat> That something related to https://bugs.launchpad.net/juju/+bug/1727355 ?
<mup> Bug #1727355: Juju attempts to bootstrap bionic by default <cdo-qa> <cdo-qa-blocker> <cdo-release-blocker> <foundations-engine> <sts> <uosci> <verification-done> <verification-done-xenial> <verification-done-zesty> <juju:Fix Released by nskaggs> <juju-core:New> <distro-info-data (Ubuntu):Won't Fix>
<mup> <juju-core (Ubuntu):Invalid> <distro-info-data (Ubuntu Trusty):Won't Fix> <juju-core (Ubuntu Trusty):Invalid> <distro-info-data (Ubuntu Xenial):Fix Released by vorlon> <juju-core (Ubuntu Xenial):Fix Released> <distro-info-data (Ubuntu Zesty):Fix Released> <juju-core (Ubuntu Zesty):Fix Released>
<mup> <distro-info-data (Ubuntu Artful):Won't Fix> <juju-core (Ubuntu Artful):Invalid> <https://launchpad.net/bugs/1727355>
<cory_fu> Yeah, that seems like it
<zeestrat> cory_fu: Thanks for the snapcraft tip yesterday btw, that worked like charm (pun intended).
<cory_fu> heh.  Glad it worked out
<rick_h> zeestrat: cory_fu oh, didn't think of bionic issues
<ejat> hi
<ejat> anyone can help me with this : https://paste.ubuntu.com/26543884/
<ejat> is it related to this : https://bugs.launchpad.net/charm-ceph-osd/+bug/1731639
<mup> Bug #1731639: get_partition_list fails <OpenStack ceph-osd charm:Triaged> <charms.ceph:Fix Released by james-page> <https://launchpad.net/bugs/1731639>
#juju 2018-02-09
<SuneK_> kwmonroe: So I looked into the edge version. I wonder what the reason for going from 2 to one elastic search units is (https://github.com/juju-solutions/bundle-canonical-kubernetes/commit/5a2f725e6da4cba1ff258fafc70be16d241cc24a#diff-efca159023ec4c86cc8b346b8e8094a2)
<kwmonroe> SuneK: just to be more conservative about resource requirements.  a single ES node is the minimum you'll need to get elastic functionality, and then we leave it up to users to add-unit to meet their specific needs.
<bobeo> asdf
#juju 2018-02-10
<ejat> hi .. how could i juju deploy application into new lxd in specific machine ?
<zeestrat> ejat: juju deploy <application> --to lxd:<machine-number>, so for example juju deploy keystone --to lxd:1. See also https://jujucharms.com/docs/stable/charms-deploying#deploying-to-specific-machines-and-containers
<ejat> zeestrat: thanks .... if i want to deploy into new lxd?
<ejat> i can do it using juju gui but doesn't know specific cli cmd
<ejat> manual placement in juju gui
<zeestrat> ejat: I'm not sure if I understand. The command I listed above is for deploying to a new lxd container on a specific machine.
<ejat> but need to define the machine number too right ?
<ejat> or no need ?
<ejat> btw, how to check the neutron-gateway error : Status: error - hook failed: "config-changed"
<ejat> deployed with maas
<ejat> and this bugs
<ejat> https://bugs.launchpad.net/mongodb-charm/+bug/1676730
<mup> Bug #1676730: mongodb charm status unknown (needs application workload status and version) <sts> <uosci> <MongoDB Charm:In Progress by mariosplivalo> <https://launchpad.net/bugs/1676730>
<zeestrat> ejat: yes, you'll need the specific machine number. Don't know about the other bug.
#juju 2020-02-03
<wallyworld> babbageclunk: it seems like that maas test is running but just takes a long time, comparing the output of a successful run to the failed one. maybe just increase the timeout, and take a look a finfolk to see if stuff needs cleaning up etc
<babbageclunk> wallyworld: yeah, will do
<timClicks> is this the current release template? https://discourse.jujucharms.com/t/juju-release-template/1506
<timClicks> I would like to add a check that if a config (app/model) is added, that the docs are updated to suit
<wallyworld> timClicks: release template is now a google doc
<wallyworld> on the shared drive
<timClicks> that's what I thought, which is why I asked
<wallyworld> thumper: there's a race in the model cache, got a minute to talk about it?
<thumper> wallyworld: yep
<wallyworld> let's go to 1:1
<thumper> ack
<thumper> wallyworld: https://github.com/juju/juju/pull/11171
<thumper> wallyworld: what does the names package use from utils?
<wallyworld> i'd need to check again, one sec
<wallyworld> thumper: IsValidUUIDString() for one
<thumper> ugh
<thumper> I've been quietly trying to kill the utils package for some time
<wallyworld> also, MustNewUUID()
<thumper> make smaller targeted packages that fit
<wallyworld> i think heather is doing some work in that area
<thumper> perhaps we should make a juju/uuid package for those
<wallyworld> +1
<wallyworld> heather has a PR up to take another step
<thumper> wallyworld, babbageclunk: https://github.com/juju/juju/pull/11171
<thumper> or anyone really...
<babbageclunk> thumper: looking
<hpidcock> wallyworld: did you say you did some snap work already for go1.13?
<wallyworld> hpidcock: there's a PR with my juju snapcraft changes
<wallyworld> https://github.com/juju/juju/pull/11138
<hpidcock> wallyworld: thx
<wallyworld> tlm: do you think we'll get the watcher stuff landed today?
<tlm> wallyworld, hpidcock HO for some rubber ducking ?
<wallyworld> tlm: just finishing a meeting, can be there soon
<tlm> k
<tlm> wallyworld: nvm hpidcock help me sort it out.
<tlm> I think I am on the last failing test now so should be soonish
<wallyworld> tlm: gr8 ok, sorry still in meeting
<tlm> np
<wallyworld> tlm: still all good?
<tlm> wallyworld: yep, giving it a full run
<tlm> sent DM
<wallyworld> all good, i can review when ready
<hpidcock> wallyworld: can you remember if you ever did a remote-build using your changes?
<hpidcock> it's taking an eternity to upload to lp for me. Not sure if you had a similar experience?
<tlm> are you sure it's still working? I had similar issues but it had failed and gone into an endless loop
<tlm> not saying this is the case now hpidcock, just an FYI
<hpidcock> could just be slow upload
<hpidcock> i dunno the git repo has nothing in it
<tlm> restart your computer 3 times ?
<hpidcock> Three shall be the number thou shalt count, and the number of the counting shall be three.
<tlm> the number of pringles in a stack
<wallyworld> hpidcock: i did do a remote build to test it
<wallyworld> it took a little while but to too long
<hpidcock> must be my Australian internet
<wallyworld> maybe try running on a jenkins slave?
<hpidcock> alright for some reason, it is uploading 10gb
<hpidcock> that might be my problem
<wallyworld> wow, i  don't recall that much but didn't check too closely
<wallyworld> i would hope it's not doing the entire git repo
<hpidcock> I think it has pulled in my .git folder
<wallyworld> it just would need the source files
<wallyworld> if it's pulled in .git i'd raise a bug and see what sergio says
<wallyworld> we can avoid that in the build scripts
<tlm> wallyworld, hpidcock PR pushed, no doubt it may have some problems
<wallyworld> looking
<wallyworld> tlm: you'll need to address the existing comments
<tlm> already on it :)
<wallyworld> tlm: there's still a bunch of import grouping issues
<tlm> yeah I put a comment on one of them
<tlm> not sure what you where chasing v what is there ?
<wallyworld> there's 3 blocks we use: std lib, 3rd party libs, juju/juju
<wallyworld> so see operator.go - it has juju/juju stuff mixed in with k8s.io stuff and juju /errors etc
<wallyworld> same with namespaces.go
<tlm> so we consider juju/errors external for this purpose ?
<wallyworld> yup
<tlm> ah no worries makes sense now
<wallyworld> anything not from juju/juju is 3rd party
<wallyworld> confusing for sure
<wallyworld> tlm: to allow parallel, work, i submitted a couple of comments - main thing is we already have a mock notify watcher that can be used
<wallyworld> so no need to create a new one for k8s testing
<wallyworld> i inlcuded a reference to the code in the comment
<tlm> ta looking now
<wallyworld> tlm: i'm trying tp get my head around the new k8sWatcherFn on the test suite. do we need it instead of what was there before? also, there's maybe one snafu in there?
<wallyworld> if s.k8sWatcherFn != nil {
<wallyworld>     w, err = s.k8sWatcherFn(informer, name, clock)
<wallyworld> }
<wallyworld> w, err = provider.NewKubernetesNotifyWatcher(informer, name, clock)
<wallyworld> ...
<wallyworld> i think we can land this tomorrow and do the stringswatcher also
<tlm> I don't mind, almost got it swapped out for the notify one
<wallyworld> ok
<tlm> want me to HO to explain the above ?
<wallyworld> sure
<nammn_de> manadart: if you have some time later, beside it being ci day, want to go over 2 of your comments on this pr? https://github.com/juju/juju/pull/11143 As I want to make sure to understand what is meant
<manadart> nammn_de: OK, if not today, then tomorrow.
<nammn_de> manadart: sure, just give me a ping if you can
<nammn_de> stickupkid: https://github.com/juju/juju/pull/11173 regards running focal with force
<stickupkid> nammn_de, i think this needs to target 2.7
<nammn_de> stickupkid: oh yes
<nammn_de> stickupkid: https://github.com/juju/juju/pull/11174
<stickupkid> nammn_de, lovely
<nammn_de> stickupkid: ta!
<nammn_de> wow it feels like we didnt forward port 2.7 to develop for ages. I am currently processing all those merge conflicts..
<skay> I have a newbie postgresql charm question. by default postgres charm stores backups in /var/lib/postgresql/backups. when using storage, pgdata is /var/lib/postgresql/10/main. is it safe to store the backups folder there instead so that it is saved in the attached storage?
<skay> when I've looked at how someone else is configuring this, they just used the defaults
<nammn_de> manadart: https://github.com/juju/juju/pull/11177 the one I closed and already resolved mostly. Maybe of help to you.
<stub> skay: Better to put your backups dir in /srv/pgdata. /srv/pgdata is the Juju storage mount. /var/lib/postgresql/10/main should be a symlink to /srv/pgdata/10/main IIRC
<manadart> nammn_de: Superseding patch: https://github.com/juju/juju/pull/11178
<nammn_de> manadart: approved!
<manadart> nammn_de: Thanks.
<skay> stub: ack
<skay> stub: if I understand the source, when storage is detached everything is destroyed. at that point the unit is probably being destroyed so it doesn't matter. do I understand that correctly?
<skay> I'm just really paranoid about backups and want to be certain
<skay> (by doesn't matter, I mean, I know the destruction is going on and I have backups saved elsewhere)
<nammn_de> stickupkid: https://github.com/juju/juju/pull/11179
<nammn_de> stickupkid: tested it all, now bootstraps fine for me locally.
<stickupkid> nammn_de, wicked
<stickupkid> approved
<nammn_de> stickupkid: ta!
<hml> rick_h:  any issues with canonical irc?
<hml> stickupkid: iâm thinking microk8s wonât work in a lxc container.  i get weird results like the enable storage works, but it never reaches a running status
<hml> stickupkid: i can also start a pod that never completes
<nammn_de> stickupkid and are having issues with irc as well
<nammn_de> *s/are/I
<stickupkid> nammn_de, i reconnected and it's fine now
<stickupkid> nammn_de, it failed
<stickupkid> nammn_de, we need to work out why that failed
<nammn_de> stickupkid: meh, I am so sad. Maybe I did the lxd configuration wrong?
<stickupkid> rick_h, first attempt bootstrapping focal on our CI, it works locally, but fails in CI
<stickupkid> rick_h, checking out why now
<nammn_de> but I just followed the instruction.. I need to leave now. Gonna look at this later or next week.
<nammn_de> stickupkid: if you have some updates I am more than happy to read them =D
<stickupkid> nammn_de, sure
<stickupkid> ah, so it can't ssh in
<stickupkid> rick_h, you got a sec?
<rick_h> stickupkid:  sure thing if you're free
<stickupkid> daily
<rick_h> omw
<thumper> morning team
<hml> morning thumper
<rick_h> morning thumper
#juju 2020-02-04
<wallyworld> kelvinliu: we already have a really old version of a python juju client in the stable juju packages archive https://launchpad.net/~juju/+archive/ubuntu/stable/+packages
<wallyworld> we should be able to publish a newer "python-libjuju" ppa
<wallyworld> to that juju stable archive
<kelvinliu> they were pushed 5yrs ago
<wallyworld> yeah, realy old
<wallyworld> so we just need to push our new "python-libjuju" ppa
<kelvinliu> yeah
<wallyworld> to that juju stable archive
<wallyworld> can do that and update the release process doc for libjuju
<kelvinliu> that one was manually pushed
<wallyworld> yeah, so updating process doc after doing it manually is all we need for now
<kelvinliu> yep
<kelvinliu> wallyworld: got a question about the quoteStrings in config process, free to have a quick HO?
<wallyworld> sure
<thumper> wow it is raining hard here today
<thumper> makes me pleased that the stadium has a roof
<wallyworld> elton had to abandon a concert here in OZ due to gale for rain, wrecked all the sound gear etc
<tlm> now we have gail force wind
<hpidcock> Best day of February so far, nice and cool
<kelvinliu> wallyworld: should I just continue to change to the spec in the doc?
<wallyworld> what was the final outcome of the discussion? i didn't hear it due to sound issues
<wallyworld> i disagree with splitting it as it sucks for the user
<kelvinliu> wallyworld: stdup?
<wallyworld> ok
<nammn_de> manadart: around to talk about rename-space? 2 review comments I am not sure
<nammn_de> https://github.com/juju/juju/pull/11143#discussion_r373477221 (missing information) and https://github.com/juju/juju/pull/11143#discussion_r373573802 (I tried to solve, not sure if thats what you meant)
<manadart> nammn_de: I am in Daily.
<nammn_de> manadart: 2 min, cannot find phone for 2fa
<achilleasa> jam: manadart regarding our chat on side-effects yesterday, if my open/close ports operation uses the same Ports model and I stack an [open, close] operation, the ports slice of the model will end up in an inconsistent state (open appends an entry, close replaces the port list with a filtered version)
<achilleasa> I could tweak the done logic for close to make it work but not sure if it's worth the effort given that the Ports model will be thrown away
<achilleasa> (e.g. have close track the entries to be removed instead of the remaining entries and filter the port list in Done)
<manadart> achilleasa: Seems reasonable. We discussed how the object curation for consistency with state post-DML execution is kind of a waste when we they are so short-lived.
<manadart> manadart: And probably less relevant than ever if the particular entities live in the model cache.
 * manadart tags himself like an idiot.
<achilleasa> manadart: actually, now that I look at it again, it's a bit more complicated. open ports issues an updatePortsDocOps whereas close ports issues a setPortsDocOps
<achilleasa> my guess is that the first txn.Op block will succeed but the later will not due to the revnos and cause the txn to fail
<achilleasa> manadart: quick ho?
<manadart> achilleasa: Yeah, give me a mo'
<achilleasa> perhaps I need an "opencloseports operation"
<stickupkid> manadart, got a sec?
<stickupkid> i'm either being stupid or stupid
<manadart> stickupkid: In Daily with achilleasa.
<stickupkid> i'll gate crash
<stickupkid> https://jenkins.juju.canonical.com/job/nw-deploy-focal-amd64-lxd/24/console
<nammn_de> manadart: incorporated your feedback + updated qa and should now be ready . https://github.com/juju/juju/pull/11143
<manadart> nammn_de: Will look soon.
<jam> achilleasa: sounds like we want to have a $pullAll instead of a $set
<achilleasa> jam: turns out you cannot compose the two individual ops together without jumping through hoops. As a workaround, I made them into a single op that calculates the final port range list and either does insert or $set. Original tests pass and I am adding some extra ones for composed open/close
<nammn_de> manadart rick_h: do we allow the deletion of provider provided spaces?  (Maas)
<manadart> nammn_de: No.
<rick_h> +1, nope the world is the world we have to live in it
<achilleasa> can anyone explain to me why this test works? https://github.com/juju/juju/blob/develop/state/unit_test.go#L1594 I don't see any unit-is-alive (there is one for model-is-alive though) assertions in the open/close txn code https://github.com/juju/juju/blob/develop/state/ports.go#L199
<stickupkid> rick_h, fyi: https://github.com/lxc/lxd/issues/6833
<rick_h> stickupkid:  <3
<manadart> Small mechanical change: https://github.com/juju/juju/pull/11181
<stickupkid> manadart, me look
<stickupkid> manadart, I looked, also saw you may have fixed a runtime panic?
<manadart> stickupkid: We've never hit it AFAIK.
<stickupkid> good piece of code then
<stickupkid> kill it?
<manadart> stickupkid: Volume attachment plans are used by the OCI (Oracle) provider for attaching volumes to instances where the local machine needs to take some actions, I believe.
<stickupkid> manadart, but we know that would never have worked, so isn't exercised
<stickupkid> manadart, whilst we're at CR sharing https://github.com/juju/juju/pull/11182
<manadart> stickupkid: Yep. Can you look at the commit I just pushed to mine?
<rick_h> jam:  got it updated and pushed together a bundle with the bits in it https://discourse.jujucharms.com/t/monitoring-juju-controllers/430
<stickupkid> manadart, I think we should add a comment and it's done :)
<manadart> stickupkid: OK.
<stickupkid> something of the lines, "we have no idea what we're doing, but this should fix it"
<stickupkid> haha
<manadart> nammn_de: I am going over your patch again. I was thinking that given the number of files touched for these, we should break future ones up.
<manadart> We can add the API server, client and cmd parts in separate patches.
<nammn_de> manadart: agree, should makes everything easier to review
<nammn_de> manadart: while running through it. Should we be able to rename-space `alpha`? I did not catch the case if someone wants to rename. i just did, because I thought that we hold by the spaceID and not spaceName
<hml> manadart:  it looks like there may have been work done on the duplicate subnets already, but some of it is a work around.  background in https://bugs.launchpad.net/juju/+bug/1733266
<mup> Bug #1733266: Autodetection of subnets prevents bootstrap when there are duplicate subnet ranges <cpe-onsite> <network> <openstack-provider> <juju:Fix Released by jameinel> <juju 2.3:Fix Released by jameinel> <https://launchpad.net/bugs/1733266>
<manadart> nammn_de: We should prevent it. There are some conditions interrogating the name. It can be done in the cmd.
<nammn_de> manadart: oh, I need to add this then.
<nammn_de> manadart: I will let you finish review first and add the alpha case in the cmd
<manadart> hml: Thanks, I'll take a look. I still need to work out why I am not seeing subnets from another network in the same tenant.
<achilleasa> manadart: does it work with dev branch?
<manadart> nammn_de: Actually, we need to check at the API server, in case someone is using say, pylibjuju.
<manadart> nammn_de: QA is looking OK here. Go ahead and add that change.
<nammn_de> manadart: will do.
<manadart> achilleasa: The network thing? I am using develop HEAD.
<nammn_de> manadart: I promise my next pr is gonna be puny :D
<manadart> Well, HEAD-ish.
<nammn_de> manadart: added
<achilleasa> manadart: I am thinking of modifying SettingsGroup in state/settings.go to implement ModelOperation instead of having a Write() method (func equiv to buildTxn+apply). I added this type when I introduced the UpdateNetworkInfo call in uniter. IIRC you recently added a settings op type.
<achilleasa> I can probably switch the code to use that and remove SettingsGroup. Thoughts?
<achilleasa> nammn_de: I think you used the ^^ type in one of your recent PRs
<stickupkid> I wonder why we never used middleware for auth of facades
<stickupkid> used composition rather than logic checks
 * stickupkid thought of the day
<nammn_de> achilleasa:  So I used ModelOperation for the PRs
<nammn_de> so no real throughts on the settingsgroup refactor. Their write would comply with applyoperation.  Modeloperation I think
<nammn_de> but it does make sense. As they comply both
<achilleasa> nammn_de: can you point me to that PR?
<nammn_de> achilleasa: https://github.com/juju/juju/pull/11143/files#diff-c2f3a22eae3088d2abd0727df01272e4R2
<nammn_de> opfactory.go and rename.go
<achilleasa> thanks!
<nammn_de> stickupkid: yeah, would be really cool.
<achilleasa> manadart: nammn_de actually the SettingsGroup is still required because my use-case requires persisting multiple *Settings in a single txn. I will make it into an operation for consistency
<roadmr> rick_h: hey there :)
 * roadmr about to pester Rick again heh
<rick_h> roadmr:  howdy
<rick_h> pester away
<roadmr> rick_h: so the list of urls that juju hits, that you obtained from logs
<roadmr> rick_h: it has method, url, query string basically. right?
<rick_h> roadmr:  right
<roadmr> rick_h: would it be possible to get user-agent as well?
<roadmr> rick_h: with that we can first weed out non-juju clients and have a better idea of what juju itself needs
<rick_h> roadmr:  all those are a generic "go client" user agent
<roadmr> rick_h: also lets us see how the api access patterns differ between our targeted juju versions (1.25 and 2.x IIRC)
<rick_h> roadmr:  and juju and the charm command are the only ones I am aware of
<roadmr> rick_h: ahh that's super unfortunate :( whaat
<roadmr> rick_h: ah but the charm command is python, right? most likely not a go client string
<roadmr> rick_h: I'd settle for being able to weed out non-jujus
<rick_h> roadmr:  so the charm command is a mix of go and python.
<roadmr> argh :)
<rick_h> roadmr:  trying to recall, I thought I weeded out obvious charm commands
<roadmr> rick_h: ah yes, you said "exact requests we're getting form go clients (juju)"
<rick_h> roadmr:  as far as different Juju's, my first instinct is forget juju 1.2X as the only folks we care about that are internal and they use offline charms with mojo ime
<roadmr> rick_h: ok, that sounds good
<rick_h> roadmr:  not to say I did it perfect but do recall trying to really focus it in and did a lot of cleaning of that data
<roadmr> rick_h: got it... doh I'm dumb, mind if we move this to #snapstore so facu can also be in the loop?
<rick_h> roadmr:  yea, or I'd suggest the canonical #juju channel so other folks on the team can see as well
<thumper> rick_h: do you know who to chase for https://github.com/juju/charmstore/issues/895#issuecomment-576562396
<rick_h> thumper:  mhilton was working with rt's to folks around these when they happened. I thought this one got corrected
<rick_h> maybe the bug didn't get closed?
 * rick_h checks rt email history
<thumper> maybe
<rick_h> thumper:  yea, marked as resolved
<wallyworld> rick_h: thumper: test passed this time no problem
<wallyworld> we have seen issues if the slaves are busy
<wallyworld> thumper: btw, https://github.com/juju/juju/pull/11172 is ready for looking at
#juju 2020-02-05
<tlm> hpidcock: if you checkout bootstrap_test.go #668, open to ideas for fixing this hacky function
<wallyworld> thumper: will you have a chance to look at the modelcache race PR?
<wallyworld> tlm: to avoid a bit of churn, can you move the NewK8sWatcherFunc (and strings version also) type definition back to the original location in the code?
<hpidcock> tlm: it's a test, not too concerned. But essentially you *can* use go mock to mock that.... but it's probably not worth the effort tbh.
<tlm> I might throw a panic in their if we step outside of bounds. Might make it a bit more clear if it gets added to hpidcock
<tlm> taking a look wallyworld
<wallyworld> tlm: can't we look at the params passed to the func to see what watcher to return?
<thumper> wallyworld: looking now
<tlm> not in this case. When we spoke I thought that was the case
<tlm> I thought about just putting all the watchers in a slic inc and index, If index > panic
<hpidcock> tlm: see Call and RecordCallWithMethodType in go mock... you can mock calls like this.. but I'm totally happy with the way you have it
<tlm> i'll have a read
<wallyworld> also, don't panic - return an error
<wallyworld> and let the test fail
<tlm> wallyworld: happy to move those functions back but they make no sense where they where (defined miles away from where they are used).
<wallyworld> tlm: i don't mind a lot - they were used near where they ariginally were also, approx line 125
<wallyworld> and all the func types were together
<hpidcock> wallyworld: do we have schema's for mongo documents anywhere, or is it just the state code that deals with the structure of docs?
<wallyworld> hpidcock: all the monfo docs should be confined to state. depends on the age of the code, but we typically expose a struct which wraps the mongo doc
<wallyworld> tlm: there's still a bunch of import issues
<wallyworld> plus stuff what was previously private and now unnecessarily exported
<wallyworld> very close though
<hpidcock> I guess we now use monfodb
<hpidcock> :)
<wallyworld> ha de ha ha
<tlm> fixing them now :)
<tlm> made them public as I couldn't see much reason to keep them private for a non const var, will update
<kelvinliu> wallyworld: https://github.com/juju/juju/pull/11145 changed the config format, could u take a look again? ty
<wallyworld> tlm: public functions etc by rights need comments so easier to keep struff private etc
<tlm> okey doke
<wallyworld> kelvinliu: will do, just let me get yet another doubles espresso first
<tlm> go tripple
<kelvinliu> going to grab some food n double shot espresso, come back later
<hpidcock> I'm going to do the same... food, octo-shot of coffee
<wallyworld> kelvinliu: let me know if my comments are unclear
<kelvinliu> wallyworld: HO?
<wallyworld> ok
<nammn_de> manadart: as we discussed before.  A smaller patch in the series of patches for remove-spaces https://github.com/juju/juju/pull/11183
<nammn_de> manadart: while at it, did you have time to look at the email I sent you yesterday evening?
<ec0> curious behaviour in 2.7.1, running kubernetes-e2e 'test' action: juju run-action kubernetes-e2e/0 test -> ERROR "action-6" is not a valid action tag
<ec0> has anyone seen this before?
<manadart> ec0: Are the client, model and controller all 2.7.1?
<nammn_de> manadart achilleasa stickupkid: this seem to cause some racy condition: https://github.com/juju/juju/blob/ff32067866004a0a04d5dba8e281dea7857f33ea/cmd/juju/status/status_internal_test.go#L6096 . It may update the model later the the call right after that to run the status output. How would you guys solve that?
<ec0> manadart: yep all 2.7.1
<ec0> interesting, let me double check client
<ec0> ahah, that'll be in manadart
<ec0> 2.6.10 client
<manadart> ec0: Yes, I think it will be unable to parse the new tag form.
<achilleasa> so, regarding my yest question about that odd test, I found what made it work: https://github.com/juju/juju/blob/develop/state/ports.go#L455. Looks like this was only enforced when appending a port range and not when creating the doc or when a port range gets closed
<achilleasa> guess I will move it into the Build for the txn
<ec0> that was it manadart, snap refresh juju --channel=stable got me 2.7.1, and the same action worked properly
<ec0> thanks!
<manadart> ec0: Good to hear; no problem.
<nammn_de> manadart:  I will remove the state removespaceOps for now as this will be eventually patched again. I started with the cmd, as this was mostly done and wanted to start with the easier and smaller part
<nammn_de> manadart: pushed the changes
<nammn_de> Do we have somewhere some functions to indiciate that the ID corresponds to a unit/application ect. This seems to be scattered everywhere but not on one common place to me
<nammn_de> manadart: ah just realized, do you have 2 min to talk about the email?
<manadart> nammn_de: I am back in the HO.
<achilleasa> jam: so I finally tracked down the issue with the broken test. The txn was indeed failing as expected. The new Build impl iterates the list of ports from the original port model (I removed the redundant copy bits). Turns out that attempt #1 caused my build code to return ErrNoOperations... why? because of *this* https://github.com/juju/juju/blob/develop/state/ports.go#L417
<achilleasa> so the code behaved as if you tried to open an already opened range twice and obviously that's a noop
<achilleasa> removing that line makes all tests happy again
<hml> achilleasa:  iâm going to work on moving the spike-v2 from process-hook to dispatch.  tease out anything from the spec comments.
<achilleasa> hml: IIRC there was a mismatch with an envvar name but I think it got dropped from the new spec
<hml> achilleasa:  ack
<stickupkid> manadart, I can't replicate bug 1860865
<mup> Bug #1860865: [2.7.1] Incorrect container architecture (i386, not amd64) used after a host upgrade to Focal - jujud fails to start <juju:Triaged> <juju 2.7:Triaged> <https://launchpad.net/bugs/1860865>
<stickupkid> installed:       2.7.1                                (10357) 71MB classic
<stickupkid> installed:        3.19                   (13162) 67MB -
<stickupkid> juju and lxd versions
<stickupkid> this is in a multipass vm
<manadart> stickupkid: And you had a controller up before the upgrade?
<stickupkid> yeah
<manadart> stickupkid: Let me know when you are done with rick_h and free to HO.
<stickupkid> manadart, ping
<manadart> stickupkid: Does the schema generation not handle embedding properly?
<manadart> stickupkid: Any chance to jump back on HO quickly?
<achilleasa> rick_h: I have converted 5/8 uniter calls into model operations which I can now compose together. I think it would be best to get these into an initial PR and then do a second PR for the rest which is more complex (AddUnitStorage for example). wdyt?
<hml> achilleasa:  dispatch spike: https://pastebin.ubuntu.com/p/rTxVJt9sTP/
<achilleasa> hml: awesome!
<rick_h> achilleasa:  sounds like a plan
#juju 2020-02-06
<wallyworld> hpidcock: i'll have a new PR ready soonish but need to land that other one first, just sayin' :-)
<hpidcock> wallyworld: sorry I'll have a look. Didn't you want tlm to also have a look at it?
<wallyworld> yeah, for educational purposes
<wallyworld> so see how lots of different key patterns are implemented
<wallyworld> i have a meeting and won't be quite ready for maybe 45 minutes or something so no great rush
<hpidcock> wallyworld: all good. I'm gonna grab some lunch anyway brb
<hpidcock> wallyworld: getting close
<hpidcock> almost done, got a bunch of comments
<wallyworld> ok, ta
<hpidcock> wallyworld: added my comments
<hpidcock> some are probs not valid
<hpidcock> but it looks good otherwise
<wallyworld> ty, looking
<wallyworld> hpidcock: my eyes hate looking at "ID" for some reason. i'll have to squint as i make the change
<hpidcock> wallyworld: hah nice, we can discuss this all day
<hpidcock> but we probs both don't have time
<wallyworld> we use docId all over but i ain't touching that
<hpidcock> I meant because it's new
<wallyworld> yeah i know
<hpidcock> also from my understanding id is a Latin word we use in English (id est or i.e.), so I think that's why ID is generally the accepted abbreviation (also to keep consistency across projects)
<hpidcock> I mostly don't care, just all the linters crying at me
<wallyworld> me either, just a personal visual thing
<hpidcock> but I think I care more than you haha
<wallyworld> hpidcock: fixes pushed
<wallyworld> thanks for review
<wallyworld> i answered a couple of comments
<hpidcock> approved
<wallyworld> awesome
<wallyworld> ty
<tlm> +1
<wallyworld> tlm: anything unclear?
<tlm> no just missing a little context for the whole package
<wallyworld> yeah, there's a lot of contex in working on juju
<tlm> i'll get my hands dirty in there next time something comes up
<wallyworld> hopefully what you saw will trigger some meories
<wallyworld> when you go to do it for reals
<tlm> PTSD
<wallyworld> yup
<wallyworld> one this one lands i'll push up another
<wallyworld> to handle the CLI changes that use the new stuff
<wallyworld> for the run action bits, still got to do list-tasks, list-operations rework
<wallyworld> hpidcock: we have a problem with juju-run - it can stop working for reasons yet to be determined
<wallyworld>  mkubectl -n test exec -ti mariadb-k8s-0 bash
<wallyworld> root@mariadb-k8s-0:/# /usr/bin/juju-run ls
<wallyworld> ERROR r.runner.RunCommands: no runner is registered for unit mariadb-k8s/0
<wallyworld> and unit shows as failed in status
<wallyworld> happens after running a status-set
<wallyworld> using juju-run
<hpidcock> interesting
<stickupkid> manadart, ping
<manadart> stickupkid: Pong.
<stickupkid> quick jump in daily
<nammn_de> manadart: regarding the race condition I mentioned yesterday in daily. Did you have a suggestion in mind yesterday? I don't have any great idea in mind for this.  https://github.com/juju/juju/blob/ff32067866004a0a04d5dba8e281dea7857f33ea/cmd/juju/status/status_internal_test.go#L6096
<manadart> nammn_de: I haven't delved into that one yet.
<stickupkid> nammn_de, manadart would be happy to have a look at that later
<nammn_de> stickupkid: cool thanks! Nothing simple as useful came into my mind
<nammn_de> manadart: how can I understand the life concept of spaces? Do I need to take them into consideration for removing?
<manadart> nammn_de: It is currently not used. The pattern for responding to space changes (were it required) would be as for machines - a worker that watched for space changes and acted based on topology/life/etc changes. But we don't require such a thing at this point.
<manadart> So ignore it for now. We can think about it and discuss if required later.
<nammn_de> manadart: ta
<stickupkid> manadart, can you see if I'm way off base with the last commit (need to rebase once my other PR lands) https://github.com/juju/juju/pull/11188
<achilleasa> while applying the Open/Close port changes from the Ports model to the Unit, it turns out that we can effectively replace the Open/ClosePort(s) methods on Unit with a single OpenClosePortsOnSubnet method. In the future we can update this method to work with endpoints instead of subnet IDs. Any objections to refactoring this all the way to the uniter facade?
<achilleasa> (there are a few TODOs in the uniter model for fixing the Open/Close port variants)
<manadart> stickupkid: Looks the goods. Looks like you need to populate the network ID on the opts: https://github.com/go-goose/goose/blob/v2/nova/nova.go#L318
<stickupkid> manadart, wicked, thanks
<stickupkid> I'm just messing around thinking how to test this atm
<stickupkid> manadart, I'm sure we could extract this piece of logic, it's almost identical to ec2
 * manadart nods.
<stickupkid> let me think (brain gears start whirring)
<rick_h> morning party folks
<nammn_de> manadart: first patch for apiserver is ready for cr https://github.com/juju/juju/pull/11186/files some things I werent sure and thus added them as comments in the PR
<manadart> nammn_de: OK, will look in a bit.
<stickupkid> manadart, if we can't find a networkId, then what? skip em?
<stickupkid> manadart, it's not like I can magically make one up i guess
<manadart> stickupkid: hml previously mentioned O7k deployments where the network(s) is not exposed. For these I don't think we can do anything, so yeah, skip for now.
<stickupkid> sick, integration tests at the unit level
<hml> rick_h:  if you approved the JUJU_HOOK_NAME pr, we can get the conflicts resolved and land it.  :-). youâve requested changes currently
<manadart> stickupkid: https://github.com/juju/juju/pull/11185
<rick_h> hml:  oh sorry, which one?
<hml> rick_h: https://github.com/juju/juju/pull/10969
<rick_h> ty
<rick_h> hml:  done
<stickupkid> manadart, https://github.com/juju/juju/pull/11188
<manadart> stickupkid: Yep. Factored your feedback in too.
<stickupkid> nice
<manadart> stickupkid: Reviewed yours. I think we need a bit more. Going AFK to sort out kids. Will check back later this eve; no hurry if you're done for the day.
<stickupkid> manadart, I would suspect so, let's meetup...
<babbageclunk> hpidcock: quick q about go.mod?
<hpidcock> fire
<babbageclunk> I'm trying to use gopkg.in/mgo.v2 but replace it with github.com/juju/mgo, but I'm getting the following error:
<babbageclunk> go: finding github.com/juju/mgo v0.0.0
<babbageclunk> go: github.com/juju/mgo@v0.0.0: unknown revision v0.0.0
<tlm> does that git repo have a v0.0.0 tag ?
<babbageclunk> It's true that there's no v0.0.0 tag on juju/mgo, but there aren't any on other juju repos I'm using
<babbageclunk> eg juju/errors
<babbageclunk> but this is the only one I'm using replace on
<tlm> you would have to use a git sha instead if that tag is missing
<babbageclunk> Do I need to add a v0.0.0 tag to juju/mgo? Or is there something I can do locally
<tlm> sorry stole from hpidcock
<babbageclunk> ooh, ok - I'll try that, thanks tlm
<babbageclunk> (thanks for nothing hpidcock! ;)
<tlm> I could be very wrong also babbageclunk
<hpidcock> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
<babbageclunk> if you are I'll take the thanks back
<babbageclunk> hpidcock: oh - because I'm replacing a .v2 package?
<babbageclunk> tlm: seemed happy with that (well, it built anyway)
<babbageclunk> consider those thanks banked
 * tlm counts he's interest
<hpidcock> I'm guessing you went go mod init and it imported godep dependencies?
<hpidcock> I think the import tried to use v0.0.0 as the version. The Gopkg.toml file specifies mgo from github.com/juju/mgo and uses the master branch. So I think it is trying to use v0/v1 semantics. We should create a v2 branch or create a v2.0.0 tag off master. Then change the url to be github.com/juju/mgo/v2
<hpidcock> But the sha way is fine for now
<hpidcock> Things are just going to get weird when we add go.mod to subpackages and all we depend on is sha. Go.mod will be unable to resolve shas then.
<hpidcock> But with the semantic versioning, if a dependency needs a higher version, go mod can bump the projects dep to that minor version.
#juju 2020-02-07
<thumper> babbageclunk: do you have a few minutes for a python question?
<thumper> or anyone else really who has done testing recently in pylibjuju
<tlm> I did a little bit thumper but hardly an expert
<thumper> I'm just having issues with the python path
<thumper> it is grabbing a version in .local/lib
<thumper> when I set a python path
<thumper> it fails on an import for toposort
<thumper> and I'm not sure why
<tlm> this is what I do
<tlm> python3 -m venv .venv; source .venv/bin/activate; python setup.py egg_info && pip install -r juju.egg-info/requires.txt; pip install asynctest ipdb mock pytest pytest-asyncio pytest-xdist Twine git+https://github.com/johnsca/websockets@bug/client-redirects#egg=websockets && pip install urllib3==1.25.7 && pip install pylxd
<tlm> harry gave me that when I worked on it. That covers all dependencies from memory
<wallyworld> babbageclunk: if you had time before eod, a look at https://github.com/juju/juju/pull/11189 would be gr8
<babbageclunk> wallyworld:  looking
<tlm> what version of go mock are we suppoed to use wallyworld? See a lot of changes when I generate due to version bump
<wallyworld> yeah, that can happen. it's hard because builds use go 1.10, CI uses 1.12 I think. i normally just ignore gomock changes when doing a review
<tlm> wallyworld, hpidcock: i did a tidy up for basic structure. Have a look at https://github.com/juju/juju/pull/11190
<wallyworld> ok
<hpidcock> tlm: might be good if the rbac mapper follows the worker interface
<tlm> it's going to be used inside of worker thats why I opted out and stuck to kube convention
<tlm> but easy change
<tlm> can do
<wallyworld> why getRBACLabels2 ?
<hpidcock> I dunno, maybe wallyworld has stronger opinions on it
<tlm> I need to break out that function off of the struct but haven't got around to it. Just to illustrate
<tlm> not staying
<wallyworld> ah no worries, ta
<wallyworld> yeah, so typically we do prefer workers in juju to encapulate the management of go routines
<tlm> np, it's an easy fix. Functionally will still remain the same
<wallyworld> all juju go routines/workers are typically started via the dependency engine or as a child worker of another worker, managed by the runner abstraction
<wallyworld> yup
<wallyworld> tlm: so we could use a watcher abstraction over the informer event stream (like we did in the other pr) and use a standard worker loop to process those watch events
<tlm> not really, our current watcher implementations are not adequate for this type of problem
<babbageclunk> wallyworld: why have Enqueue and EnqueueV2 on the same API? Shouldn't everything just use EnqueueV2 (if that's what's on the best API)?
<wallyworld> babbageclunk: older clients still need enqueue
<babbageclunk> Right, but wouldn't they talk to the old facade?
<babbageclunk> (that's why we have them)
<wallyworld> usually but there's still legacy actions CLI not behind the feature flag that uses enqueue
<wallyworld> it's only the CLI behind the feature flag that uses v2
<wallyworld> when 2.8 beta1 will have both CLIs
<wallyworld> so we need to support both until juju v3
<babbageclunk> Oh, so those commands that use the old method will still be available on the next-released juju CLI?
<wallyworld> yeah :-(
<wallyworld> as we can't change CLI until v3
<wallyworld> and new stuff is opt in till then
<babbageclunk> still seems like a weird way to do it - we can change the API internally while keeping the cli the same
<wallyworld> how? they return different structs
<wallyworld> and the new struct has less info
<wallyworld> we also have AddMachineV2 (rom memory) for similar reasons
<wallyworld> maybe it's gone now
<wallyworld> babbageclunk: or maybe i'm on crack and am missing something?
<wallyworld> tlm: what calls enqueueServiceAccount ?
<babbageclunk> wallyworld: I think really I just don't like that the new method is called EnqueueV2 - it's the one that we're going to be stuck with when the legacy method is removed once the feature flag goes away.
<wallyworld> we can rename it then
<tlm> the event handlers, I have just fixed that up
<tlm> my cleanup had the old code in it
<babbageclunk> Might make more sense to rename the old one to LegacyEnqueue and have this one as Enqueue in the most recent facade version.
<wallyworld> babbageclunk: i could call it EnqueueOperation
<babbageclunk> yup, that would work too
<babbageclunk> I'll put that in a comment
<wallyworld> ok
<wallyworld> tlm: modulo seeing the revised code, i still think we can wrap the informer event handler as a notify watcher, and use a std juju worker to update the uuid->app mapping, but i could be wrong also
<tlm> perhaps, I can explain it over HO when you are free if you would like
<wallyworld> tlm: coffee time, give me a few minutes
<tlm> no rush
<wallyworld> tlm: free now?
<tlm> roger
<wallyworld> thumper: can you remind me - the isResponsible flag - does that ensure we only have one of those workers it wraps per controller?
<wallyworld> or babbageclunk?
<babbageclunk> wallyworld: ask again?
<wallyworld> babbageclunk: ty for review btw :-)
<wallyworld> just checking
<babbageclunk> hang on, reminding myself...
<wallyworld> i think if we pass controller agent tag (or machine tag of controller) as the claimant we just get one of that worker that is wrapped
<wallyworld> tjust want to confirm
<babbageclunk> yeah, that's right - it tries to claim the lease for that entity and if it fails the flag is false, so any downstream workers won't run
<wallyworld> babbageclunk: awsome ty
<wallyworld> we want one k8s client cache per controller
<wallyworld> the worker maintains it and different model workers use it
<wallyworld> the isresponsible worker
<babbageclunk> yeah, sounds like the isResponsible decorator is what you want
<tlm> thanks, will try that for wiring this up
<babbageclunk> wallyworld: oh, hang on - isResponsible is for 1 worker per model across n controllers, the machine-agent-level flag is the ifPrimaryController one
<wallyworld> we want one per controller
<babbageclunk> but the model level workers might be running in a controller that isn't the primary controller agent, not sure whether that's a problem
<wallyworld> i think we can set the claimant flag to the controller agent though right?
<wallyworld> i think isresponsible is what we want, can always test to be sure
<babbageclunk> jump in a hangout? I think we might be talking at cross-purposes
<wallyworld> ok
<wallyworld> stickupkid: hey, 2 things, i'd love a review on a totally mechanical PR to move some unused/deprecated code out of the way https://github.com/juju/juju/pull/11191
<wallyworld> also, https://bugs.launchpad.net/juju/+bug/1856832
<mup> Bug #1856832: neutron-openvswitch charm lxc profile not getting set with correct configuration <juju:Triaged> <https://launchpad.net/bugs/1856832>
<wallyworld> i ran a test of a single unit and it worked bu then the reported said it happens when deploying a bundle
<wallyworld> so seems like it could be some sort of race
<wallyworld> but win o'clock here so ran out of time to dig further
<wallyworld> *wine
<stickupkid> haha
<stickupkid> win sounds better
<wallyworld> no, wine :-)
<stickupkid> i hate wine
<stickupkid> i'll have a look once I'm up and running, taking dogs for a walk first
<wallyworld> no worries, i got a dinner guest here so got to go afk
<stickupkid> manadart, I'm picking up a bug today, I'll catch up on the openstack cidr issue after that
<manadart> stickupkid: Ack. I am working on the consuming side of my last patch. I might look at yours with a mind to testing if I get through it today.
<stickupkid> manadart, yeah, go for it
<flxfoo> Hi all
<stickupkid> flxfoo, hi
<flxfoo> I have a little issue with `mysql-shared` on a percona-cluster (x3)... a webserver charm is not doing what it is suppose to do
<flxfoo> the status on mysql-shared is joining
<flxfoo> the webserver is connectiong to percona charm and send data, but then wait for an answer
<flxfoo> not sure where to look at
<flxfoo> ideas are welcome
<stickupkid> flxfoo, this might help https://discourse.jujucharms.com/t/debugging-charm-hooks/1116
<stickupkid> flxfoo, failing that, I would log on to the charm machine/container and ensure it can access the outside
<stickupkid> flxfoo, or check if the relation is up correctly
<flxfoo> stickupkid: thanks will give it a read thanks
<flxfoo> stickupkid: thing is we use the exact same charm on dev platform, which is working fine
<flxfoo> on production difference is cluster members is more than 1 :)
<flxfoo> and communicate through private network without issue
<flxfoo> everybody is happy except the charm relation :)
<flxfoo> find that in debug log: host is not in access-network xxxx ignoring
<flxfoo> ips are on different subnet
<flxfoo> stickupkid: do you know how I would change the interface they would communicate for that relation? (if ever you know)
<stickupkid> flxfoo, I don't unfortunately
<stickupkid> flxfoo, if you want better exposure maybe drop an new topic on https://discourse.jujucharms.com/
<flxfoo> stickupkid: ok thanks
<flxfoo> little quick one: how can I see which relations are available in a charm
<flxfoo> stickupkid: I think my issue is that the two leaders are not communicating on the same subnet...
<stickupkid> flxfoo, juju status --relations
<achilleasa> is it possible to access a unit name from its tag?
<achilleasa> .Id() seems to apply a transformation
<stickupkid> i thought Id didn't do that
<achilleasa> stickupkid: for units it replaces last '-' with '/'
<achilleasa> no prob; just have to pass the name as an extra arg
<nammn_de> manadart: rick_h opened a bug where one should be able to use the spaceID in `show-space` . While at it I wasn't sure whats the best way to solve this from API param sense.
<nammn_de> On the cmd part I could decide between sending an int or a tag. On the Apiserver part I could use that information to either search by id or by name. Wdyt?
<nammn_de> Or we can just stick with the entity Tag. And in case it does not work out on the apiserver tag, try to search by id
<achilleasa> stickupkid: turns out that for the api call I am interested in 'Unit' means 'Tag' :D
<stickupkid> why doesn't this create three containers in lxd, it only does one? juju deploy cs:~juju-qa/bionic/lxd-profile-without-devices-5 --to lxd -n 3
<stickupkid> this does the same thing... juju add-unit lxd-profile -n 3 --to lxd
<stickupkid> annoying
<nammn_de> manadart: I thought something along this line https://github.com/juju/juju/pull/11195/files
<manadart> nammn_de: A space ID is actually a valid space name, so you can drop the extra DTOs and keep it as `params.Entities`.
<nammn_de> manadart: ah, yes. But I would need to parse it on the apiserver to check whether I call byName or byID
<manadart> nammn_de: This also means that testing for an integer is not enough. We'll just have to query both ID and name. Unique=return, Multiple=error with instructions to disambiguate, Nothing=not found.
<nammn_de> manadart: rgr
<achilleasa> looking for someone to pair with me in deciphering the way that errors are handled when flushing the hook ctx
<stickupkid> wallyworld, I'm struggling to get a reproducer for 1856832
<manadart> stickupkid: https://github.com/juju/juju/pull/11194
<rick_h> morning
<manadart> Morning rick_h.
<stickupkid> manadart, i'll look into this
<rick_h> stickupkid:  what about if you did --to lxd,lxd,lxd ?
<rick_h> stickupkid:  I think the thing is that it reads the list of --to thinking it'll be like --to 0,1,2
<rick_h> so it treats each target as one at a time
<stickupkid> rick_h, it may well be, but it's very strange
<rick_h> stickupkid:  I understand it is in that case, but -n3 --to=0 you don't want three of them on the same machine as well
<stickupkid> rick_h, it not intuitive
<rick_h> yea, for the lxd case it's not agree
<stickupkid> hml, this is interesting esp. because it's on the openvswitch 3, which is causing the problemshttps://paste.ubuntu.com/p/qhbzKTNNzz/
<nammn_de> rick_h: in for a cr on column ordering? https://github.com/juju/juju/pull/11193
<rick_h> nammn_de:  rgr, will do
<nammn_de> manadart: cr on ID/Name search for show-space? https://github.com/juju/juju/pull/11195
<nammn_de> stickupkid: opened the LP bug https://bugs.launchpad.net/juju/+bug/1862376
<mup> Bug #1862376: tests: status output branches output -> race condition <juju:New> <https://launchpad.net/bugs/1862376>
<stickupkid> nammn_de, nice
<hml> stickupkid: looking at the pastebin now.
<nammn_de> manadart: I can remember why i didn't export ConstraintsBySpaceName and used tag conversion instead.
<nammn_de> Reason was that the  doc `constraintsWithID` is not exported. Should I just export that type instead?
<hml> stickupkid: ln 28 looks like a side effect of the neutron-openvswitch unit not coming up correctly with the profile changes
<manadart> nammn_de: Let me take a look.
<manadart> nammn_de: BTW, can you get a fix up for this? https://pastebin.canonical.com/p/qxsDM3hwZ9/
<stickupkid> hml, exactly
<stickupkid> i'll report back
<hml> stickupkid: there are other errors too in there, not just the 1 unit
<hml> stickupkid: is this a MAAS setup?
<stickupkid> hml, quick ho?
<hml> stickupkid: sure
<nammn_de> manadart: will do!
<nammn_de> manadart: fixed the test by ensure ordering with sorting. I think that was the problem
<nammn_de> Did you take a look regarding constraints thing? Should have applied the rest. Not 100% sure about your last comment though, added a comment.
<stickupkid> manadart, what's wrong with #11194 it's not building with github correctly
<mup> Bug #11194: auto-fsck after 30 boots can be problematic on a laptop <laptop-mode (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/11194>
<stickupkid> bot fail!
<manadart> Not sure. Will look Monday.
<stickupkid> just close it and reopen the PR
