[00:02] <wallyworld> redir: thanks for doc, i may have missed it, was there a test to check that "source" of config value is updated dynamically? ie if it shows "controller" and I update the region value to match that of the controller, the source should now say "region"
[00:02] <redir> erm, lemme look
[00:05] <wallyworld> redir: also, i assigned you a nice card to pick up next :-)
[00:07] <redir> wallyworld: how do you update the region value to match that of the controller?
[00:07] <redir> 067118
[00:07] <wallyworld> redir: you should be able to do all the development either with lxd or aws without teardown of server so dev cycle should be fast
[00:08] <redir> wallyworld: would you care to HO for a minute on the QA/CI stuff? prolly faster
[00:08] <wallyworld> sure
[00:08] <wallyworld> standup
[00:23] <menn0> anastasiamac: I've added a request for more information, with instructions, on that ticket
[00:24] <anastasiamac> menn0: u r brilliant! tahnk you :D
[00:24] <anastasiamac> thank you even
[00:30] <anastasiamac> thumper: i've missed 3 days. did u have a chance to import/export workloads for model migration?
[00:31] <anastasiamac> wallyworld: model confi defaults: are cloud region default done? and command re-work?
[00:31] <anastasiamac> commands*
[00:32] <wallyworld> no
[00:32] <wallyworld> there's cards for it on the board
[00:32] <anastasiamac> q1 or q2 or both?
[00:32] <wallyworld> region defaults done partly
[00:32] <anastasiamac> k
[01:05] <axw> anastasiamac: I'm back
[01:05] <anastasiamac> veebers: r u available? m happy to chat without u if u r busy and pull u in if we can;t live without :D
[01:07] <veebers> anastasiamac: I'm available
[01:08] <anastasiamac> veebers: pm-ed u
[01:24] <thumper> anastasiamac: payloads?
[01:24] <thumper> yes
[01:24] <thumper> resources, no
[01:24] <anastasiamac> k:D
[01:43] <katco> axw: ping
[01:43] <axw> katco: [ong
[01:43] <axw> pong even
[01:43] <katco> axw: hey, long time. o/
[01:43] <axw> katco: indeed, how's it going ?
[01:43] <katco> axw: kind of chaotic here. kiddo is probably coming down with something :(
[01:44] <katco> axw: how is your family doing?
[01:44] <axw> that's never fun
[01:44] <katco> yeah, it's no fun
[01:44] <axw> katco: not bad, nothing eventful as that :p
[01:44] <katco> lol, well that is good to hear ;)
[01:45] <katco> axw: i pushed up further refactor of the deploy command. i couldn't get the tests passing tonight, but wanted to get someone's eyes on it since i'll be out for the next 2 weeks
[01:46] <katco> axw: it's http://reviews.vapour.ws/r/5582/ if you (or anyone else) get a chance today. i'm afraid it's quite long, but i think a lot of the diff is tests
[01:46] <axw> katco: ok. pretty busy today, but I'll see what I can do
[01:47] <katco> axw: no worries. i understand if you can't get to it
[01:47] <katco> so is it getting warmer over there?
[01:50] <axw> katco: not really that warm here yet
[01:50] <axw> katco: not as cold as it was a few weeks ago, but still fairly chilly
[01:50] <katco> lucky
[01:50] <katco> we had a nice fallish day today
[01:54] <natefinch> Someday fall will come here.  It's been unseasonably hot all summer.
[01:55] <katco> well we're technically still in summer i suppose
[01:56] <natefinch> I think we've had like one below average temperature day all summer.  New England... where all the days are above average
[01:56] <katco> wondering how much of that is climate change too =/
[01:57] <natefinch> well yeah. When the last like 15 months or something have all been record highs, globally, and 14 of the 15 hottest years have been since 2000 (or some numbers pretty close to those)
[01:58] <mwhudson> perrito666, etc: juju-mongodb3.2 3.2.9 builds fine on trusty it seems https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages
[02:17] <natefinch> so weird.... the X button (window close) in the upper left of my windows is disabled when windows are maximized
[02:18] <natefinch> no, sorry, all those buttons (minimize and maximize too) are disabled
[02:38] <thumper> menn0, veebers: who is ready for a call now?
[02:38] <menn0> menn0: i'm around
[02:39] <veebers> thumper: I'm available
[02:39] <thumper> I'll go with menn0 first because I think it'll be shorter
[02:39] <thumper> menn0: 1:1?
[02:39] <menn0> thumper: ok
[02:53] <thumper> veebers: now?
[02:59] <wallyworld> mwhudson: that's awesome. maybe we can get juju-mongodb on trusty updated at some points?
[02:59] <mwhudson> wallyworld: yeah, should be possible
[02:59] <wallyworld> \o/
[03:02] <veebers> thumper: in 5?
[03:03] <thumper> veebers: sure
[03:03] <veebers> thumper: actually I wanted to ask wallyworld something but he's just disconnected. Now is fine :-)
[03:03] <thumper> ok
[03:03] <thumper> veebers: https://hangouts.google.com/hangouts/_/canonical.com/manual-ci?authuser=0
[03:03] <anastasiamac> thumper: menn0: axw: is it possible to use `juju scp` to copy between units directly?
[03:04] <thumper> kinda
[03:04] <thumper> goes via the host
[03:04] <menn0> anastasiamac: yes
[03:04] <thumper> but yes, I think
[03:04] <menn0> juju scp -- -3 from:path/to/file to:
[03:04] <menn0> something like that
[03:05] <anastasiamac> \o/ thank you :D then we have a bug... but i'll target it ;D
[03:05] <menn0> the -3 is important
[03:05] <menn0> you can't copy directly between machines because they don't have SSH keys for each other
[03:05] <menn0> anastasiamac: I even made sure there was an example of this in the help
[03:05] <menn0> (last one)
[03:06] <anastasiamac> menn0: and that's why u r brilliant \o/ tyvm
[03:08] <anastasiamac> menn0: -3 is importnt because it's...?
[03:09] <menn0> $ man scp | grep -- -3
[03:09] <menn0>      -3      Copies between two remote hosts are transferred through the local host.  Without this option the data is copied directly between the two remote hosts.  Note that this option disables the progress meter.
[03:09] <menn0> anastasiamac: ^
[03:09] <anastasiamac> menn0: \o/
[03:10] <menn0> anastasiamac: the client can connect to the 2 Juju managed hosts, but the hosts can't connect to each other, so -3 works around that
[03:10] <anastasiamac> menn0: awesome! i'll add it to the comment in the bug... i hope it's a user error and we don't need to do anything! thank you
[03:30] <veebers> wallyworld: you recently landed changes re: controller UUID handling right?
[03:31] <veebers> wallyworld: would this change what appears in a log forwarded syslog? (I think maybe the CI test for log-forward needs updated as it might be looking for the wrong uuid in the syslog file)
[03:31] <wallyworld> yes - controller uuid is now different to controller model uuid
[03:32] <veebers> wallyworld: which uuid will get forwarded for log-forwarding (and also, how would one get that uuid used)
[03:32] <wallyworld> i'll look. if the test assumed controller UUID = controller model UUID then it needs fixing
[03:32] <wallyworld> those values happened to be the same before but it is wrong to assume that
[03:33] <wallyworld> you know the uuid of the controller as it is the one you are connecting to
[03:33] <wallyworld> let me look at the test output
[03:34] <veebers> wallyworld: we were using the uuid from 'show-controller' json/yaml output under controllername -> details -> uuid
[03:36] <wallyworld> that is the correct thing to do
[03:37] <veebers> wallyworld: hmm, that would suggest that the ci test is doing the right thing but it fails. I'll dig deeper to see what's happenig
[03:38] <wallyworld> i'm just looking at the code
[03:54] <wallyworld> veebers: it depends on what you are looking for - the rfc5424 appname contains the model uuid not the controller uuid
[03:55] <wallyworld> it would have worked by coincidence before if you are searching using controller uuid
[03:55] <wallyworld> we do record the controller uuid in syslog structured data
[04:00] <veebers> wallyworld: For this test I use the UUID found as outlined before to check the logs of the rsync-sink to ensure expected output is landing there.
[04:00] <wallyworld> veebers: you misunderstand - i am saying you are probably checking the wrong content
[04:00] <veebers> wallyworld: oh
[04:00] <wallyworld> we record the model uuid, you are checking for controller uuid
[04:01] <wallyworld> we record the model uuid in the appname field
[04:01] <veebers> wallyworld: right, so I'm using the wrong uuid
[04:01] <wallyworld> only if the script is looking in appname
[04:01] <veebers> wallyworld: how does one get the controller model uuid?
[04:01] <wallyworld> if the script if looking in structured data then it is correct
[04:01] <veebers> wallyworld: its checking content of syslog on the rsyslog syslog file
[04:02] <wallyworld> right, but the syslog content contans lots of diffrent fields :-)
[04:02] <wallyworld> which field is the script looking for
[04:02] <wallyworld> appname of the structured data
[04:02] <wallyworld> *or
[04:03] <veebers> wallyworld: the check is doing a regex grep on syslog similar to: ^[A-Z][a-z]{,2}\ +[0-9]+\ +[0-9]{1,2}:[0-9]{1,2}:[0-9]{1,2}\ machine-0.0518053c\-31cd\-4d49\-8316\-a504c6d78389\ jujud-machine-agent-0518053c\-31cd\-4d49\-8316\-a504\ .*$
[04:03] <veebers> (this is a specific example from a test)
[04:03] <wallyworld> right, so i guess it is grepping assuming it is parsing the appname field
[04:04] <wallyworld> use use show-model controller to see the controller model uuid
[04:06] <veebers> wallyworld: ok, I'll give that a spin now
[04:06] <wallyworld> fingers crossed, should be a simple fix hopefully :-)
[04:06] <veebers> hopefully :-)
[04:06] <wallyworld> "juju show-model controller" prodiceds yaml similar to show-controller
[04:07] <wallyworld> and you just get that uuid instead
[04:07] <veebers> cool, makes sense
[04:07] <wallyworld> we just needed to see what was being searched for in the syslog output
[04:07] <wallyworld> appname field or structured data
[04:07] <wallyworld> and now the tests will be even better because a faulty assumption will be fixed :-)
[04:08] <veebers> wallyworld: can you have structured data in the syslog log file (or am I misunderstanding again?)
[04:09] <wallyworld> yes, it is text, and can be parsed into simple fields and structured data. i think the structured data is written out inside [] but i'd need to check that syntax
[04:09] <wallyworld> it's all in the rfc standard
[04:09] <wallyworld> we write the flat fields and structured data fields
[04:10] <wallyworld> aooname is a standard scalar field
[04:10] <wallyworld> appname
[04:10] <wallyworld> we put "juju-"modeluuid in there i think
[04:11] <wallyworld> and then things like controller uuid, model uuid as separate fields in structured data
[04:11] <wallyworld> which is then flattened out into a line of text in the syslog file
[04:11] <wallyworld> i'd have to read the rfc to get the exact syntax etc
[04:15] <veebers> wallyworld: ah cool, thanks for clarifying
[04:16] <wallyworld> np
[04:17] <thumper> wallyworld: http://reviews.vapour.ws/r/5584/
[04:17] <thumper> wallyworld: just running test suite now
[04:17] <thumper> wallyworld: much rationalisation on aliases
[04:17] <wallyworld> ok
[04:18] <wallyworld> thumper: you sure about add-units? we can add more than one at a time
[04:18] <wallyworld> juju add-units -n 10
[04:18] <thumper> wallyworld: that's what the doc says
[04:18] <thumper> there is no alias for add-unit
[04:18] <wallyworld> hmmpf
[04:19] <thumper> the thing is, if you add plural for one, you should do for all
[04:19] <thumper> then it just looks messy
[04:19] <thumper> like you haven't decided
[04:19] <thumper> be opinionated
[04:19] <thumper> I went on changes based on the 2.0 command table
[04:20] <thumper> just wondering whether we should have status or show-status be the alias
[04:20] <thumper> doc says "status" is the alias
[04:20] <thumper> but it also says "list-foo" should be the primary
[04:21] <thumper> so it appears to be slightly out of date
[04:21] <wallyworld> thumper: in that case, we are inconsistent. the PR changes to juju list-sshkeys. but we still have juju machines as the list machines example
[04:22] <thumper> wallyworld: refresh
[04:22] <thumper> I fixed that
[04:22] <thumper> I tried to be consistent on all the aliases
[04:23] <thumper> wallyworld: http://paste.ubuntu.com/23122921/
[04:23] <thumper> that is all the aliases now
[04:24] <wallyworld> thumper: lgtm with a trivial
[04:26] <thumper> wallyworld: taking the dog for a quick walk while it is light
[04:26] <thumper> bbl
[04:26] <wallyworld> sure, ttyl
[04:26] <thumper> pushed trivial fix and lined up for merging
[05:17] <veebers> wallyworld: fyi that was the fix for the CI job, seems I had conflated the controller uuid and the contrller model uuid. All sorted now
[05:17] <wallyworld> veebers: yay, thank you. not just you who confused it. juju did also for about 18 months or more :-)
[05:18] <veebers> heh :-) I've set the log-forward job to be non-voting for now until this fix can land in the test
[06:16] <frobware> dimitern: you about?
[06:22] <dimitern> frobware: yeah
[06:22] <dimitern> frobware: aren't you out today?
[06:23] <frobware> dimitern: for the "unconfigured vlan" bug I think I'm just going to deal with bridging unconfigured interfaces and leave the MAAS 2.1 issues for another commit
[06:23] <frobware> dimitern: I am - need to leave in a bit
[06:23] <dimitern> frobware: ok, sgtm
[06:24] <frobware> dimitern: the script needs to change so that we can look at forward interfaces that we may (or may not) need to bridge. That's a departure from what we do today.
[06:24] <dimitern> frobware: btw re the other bug with hostnames - I still think we should have that as an optional "native mode", even if later we do nss by default everywhere
[06:24] <frobware> dimitern: I think the nss module is orthogonal to that bug.
[06:25] <frobware> dimitern: if we probe/scan for open ssh ports on an undefined order that should still help without nss
[06:25] <dimitern> frobware: that way we can work consistently across the board, but still satisfy specific deployments that need to use maas hostnames and have properly configured dns settings
[06:26] <frobware> dimitern: from a juju client perspective (CLI, UI) we would always be dealing with ip addrs
[06:26] <dimitern> frobware: so I'm proposing to add a maas-specific config flag that enables "put hostname on top of addresses list", otherwise it doesn't and just returns IPs
[06:27] <dimitern> off by default
[06:27] <frobware> dimitern: propose via email and let's discuss with jam, et al
[06:27] <dimitern> and ivoks
[06:27] <dimitern> ok
[06:27] <frobware> dimitern: I think we should try and land "unconfigured vlans" soon - if we can.
[06:28] <dimitern> frobware: agreed - I'm on it
[06:45] <mup> Bug #1441319 changed: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop <canonical-bootstack> <cisco> <cpec> <deployer> <landscape> <lxc> <oil> <systemd> <upstart> <juju-core:Invalid> <https://launchpad.net/bugs/1441319>
[06:51] <mup> Bug #1475509 changed: upgrade-charm --force behavior causes races <race-condition> <upgrade-charm> <juju:Triaged> <https://launchpad.net/bugs/1475509>
[06:51] <mup> Bug #1531589 changed: debug-log does not work with local provider on xenial + 1.25.0 <debug-log> <local-provider> <xenial> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1531589>
[07:12] <mup> Bug #1475509 opened: upgrade-charm --force behavior causes races <race-condition> <upgrade-charm> <juju:Triaged> <https://launchpad.net/bugs/1475509>
[07:12] <mup> Bug #1531589 opened: debug-log does not work with local provider on xenial + 1.25.0 <debug-log> <local-provider> <xenial> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1531589>
[07:15] <mup> Bug # changed: 1394223, 1475509, 1514456, 1531589, 1554088, 1613804, 1615106, 1615112, 1615118
[07:18] <mup> Bug # opened: 1394223, 1514456, 1554088, 1613804, 1615106, 1615112, 1615118
[07:21] <mup> Bug # changed: 1301367, 1394223, 1444576, 1446885, 1448308, 1514456, 1554088, 1613804, 1615106, 1615112, 1615118
[08:31] <wallyworld> axw: here's a PR to handle the list controllers things http://reviews.vapour.ws/r/5585/  no rush to land, can do it next week
[08:39] <axw> wallyworld: ok, will probably review on monday. still butting heads with auth
[08:40] <wallyworld> axw: yeah, no worries, figures as much :-) just letting you know
[10:10] <babbageclunk> wallyworld: At the moment I'm not exposing much of the tags functionality in gomaasapi - just enough to do what we need in the provider. Is that ok?
[10:10] <babbageclunk> wallyworld: We can always flesh out the other parts later as needed.
[10:11] <babbageclunk> wallyworld: (is my thinking)
[10:12] <voidspace> babbageclunk: in
[10:12] <voidspace> oops
[10:13] <voidspace> babbageclunk: in general, only exposing what we need is the way we've gone
[10:13] <voidspace> babbageclunk: so that sounds good
[10:13] <voidspace> babbageclunk: gomaasapi itself is open source - so if anyone needs more they can add it themselves
[10:14] <babbageclunk> voidspace: cool, thanks - might get you to look at the interface I'm thinking about for tags before I start implementing it if that's ok?
[10:15] <voidspace> babbageclunk: sure
[10:27] <voidspace> down to only seven test packages that fail or won't build
[10:27] <voidspace> progress
[10:42] <wallyworld> babbageclunk: sounds ok - just enough to satisfy our use case, but if there's a tateful way to do it so that we can accommodate future requirements, that would be good. the main thing for juju is to be able to get and set arbitary tags on machines and storage/volumes
[10:44] <babbageclunk> wallyworld: ok - sounds good.
[11:02] <babbageclunk> wallyworld: Just rereading your email - do we expose tagging to users somewhere? Or is it just something we use to find instances by custom tags internally.
[11:02] <babbageclunk> ?
[11:03] <wallyworld> babbageclunk: the primary use case is to allow the Environ ControllerInstances() method to correctly identity which machines are controllers - that eliminates the provider-state file requirement. But we also support the resource-tags attribute in config to allow users to specify their own tags as well. There are typically seen via cloud specific tools, like the aws console for example
[11:04] <wallyworld> but juju could be asked to query and present them
[11:07] <babbageclunk> wallyworld: Ah, ok - reading about resource-tags now.
[11:08] <wallyworld> babbageclunk: what happens when juju provisions a resource is that it applies standard tag values (eg controller uuid, model uuid etc) and then adds to those any user specified values
[11:08] <wallyworld> babbageclunk: so for example, model admins amay set different tags which are then used for accounting or other purposes
[11:09] <babbageclunk> wallyworld: Ok, and then the point of those custom tags is that users can find them in the provider's UI (the maas one in this case)?
[11:09] <wallyworld> babbageclunk: see usages of the environs.tags.ResourceTags() method
[11:10] <wallyworld> yes
[11:10] <wallyworld> maybe juju can display those in stats, i can;t recall now exactly what the yaml contains
[11:10] <wallyworld> *status
[11:13] <babbageclunk> wallyworld: Ok.
[11:13] <babbageclunk> wallyworld: When you talk about storage volumes, that would correspond to block devices in maas-land? They don't seem to be able to be tagged in the same way.
[11:16] <wallyworld> babbageclunk: yeah, i'm not sure what maas supports there. in aws for example, we can tag ebs block volumes. but if maas doesn't support a similar concept that's fine. the main thing is to tag machines. but we may also query tags when killing the controller so that we clean up all resources. but that's only really relevant to clouds like aws where the storage is separate and is attached dynamically to a machine
[11:16] <wallyworld> s/is/may be
[11:17] <wallyworld> babbageclunk: you'll find StartInstance() in particilar for provider/ec2 or provider/openstack will have code to collect all the required tags and then apply them to the newly started instance
[11:17] <wallyworld> maas provider would do something similar
[11:17] <wallyworld> and then ControllerInstances() for maas would be changed to not use provider-state, and instead query machines where controller-uuid tag is the relevant one
[11:18] <wallyworld> and we'd move the Environ.Storage implementation off the maas 2.0 provider and retain it for use in 1.9, and the mass 2.0 work could be nice and clean
[11:19] <wallyworld> because Environ.Storage is i think only used to access the provider-state file
[11:19] <dimitern> babbageclunk, wallyworld, voidspace: hey guys, can you have a look at http://reviews.vapour.ws/r/5586/ ? it should be straightforward
[11:19] <wallyworld> which we won't need on maas 2.0 now
[11:21] <babbageclunk> wallyworld: ok, makes sense - thanks!
[11:21] <babbageclunk> dimitern: Looking
[11:22] <wallyworld> dimitern: is SysClassNetPath const necessary as an arg? will it ever be anything different?
[11:22] <dimitern> babbageclunk: ta!
[11:22] <dimitern> wallyworld: well, I wrote it initially to take just a name, but then I found it awkward to test without introducing global vars unecessarily
[11:23] <dimitern> wallyworld: it will only be called in a couple of places anyway
[11:25] <wallyworld> dimitern: yeah, understood. i also wonder if at least the error from say reading the file should be checked. fair enough if it's a notexists. but what happens if you get an eof? maybe worth at least loggin something before returning UnknownInterface. i'm a little wary of swallowing all errors
[11:25] <dimitern> wallyworld: yeah, ok - I'll add Debug logging on error
[11:26] <wallyworld> dimitern: you'll appreciate the log entry when something goes wrong and you're asked to diagnose and  fix :-)
[11:26] <dimitern> wallyworld: sure - I'm usually the one to add insane level of trace logging all over the place :)
[11:27] <wallyworld> warranted in this case IMHO :-)
[11:27] <dimitern> +1
[11:30] <babbageclunk> wallyworld, voidspace - here's how I'm planning to add tags to the gomaasapi interface: https://github.com/juju/gomaasapi/compare/master...babbageclunk:tags?expand=1
[11:33] <wallyworld> babbageclunk: i don't know the gomaasapi very well, but i generlly prefer not to define interfaces domain entities like Tags and then add verbs to them, like Delete() or Machines() or UpdateNodes(). those verbs I tend to add to a service type of interface
[11:34] <wallyworld> the above really belong on Controller interface IMO
[11:34] <wallyworld> DeleteTag(machine, tag)
[11:34] <wallyworld> etc
[11:36] <babbageclunk> wallyworld: I was trying to keep consistency with the other types - like Device.Delete or File.Delete.
[11:37] <babbageclunk> wallyworld: (And to a lesser extent with the underlying API.)
[11:39] <babbageclunk> dimitern: LGTM
[11:39] <babbageclunk> dimitern: (Other than the logging that wallyworld mentioned)
[11:40] <dimitern> babbageclunk: thanks! I've added logging and will push an update shortly
[11:40] <babbageclunk> dimitern: cool
[11:41] <wallyworld> babbageclunk: Device and Machine interfaces for example in gomaaspi - these tend to only expose methods relevant to the domain entity which they prepresent
[11:42] <wallyworld> so given a Machine instance, you can query aspects of that machine. but you can't do things *with* that machine
[11:42] <wallyworld> it seems the Controller interface performs that role
[11:43] <wallyworld> eg AllocateMachine, ReleaseMachine etc
[11:43] <wallyworld> there could be tag related methods on  a machine I guess
[11:43] <babbageclunk> wallyworld: No, for example Machine has Start and CreateDevice.
[11:44] <wallyworld> right, but Device (which is analogoues to tag) doesn't have methods that can be used to manipulate machines. a Device is tied to a machine, hence I can see why CreateDevice is there
[11:45] <wallyworld> so a Machine interface could gain a Tagger interface, providing AddTag() DeleteTag() GetTag() on the Machine interface
[11:45] <babbageclunk> wallyworld: Yeah, that makes sense.
[11:46] <wallyworld> babbageclunk: and Controller already has a Machine() method - the MachineArgs would gain tags to filter on
[11:47] <wallyworld> Machines()
[11:47] <babbageclunk> wallyworld: That would make gomaasapi quite differently structured from the underlying API - do we think that's a problem?
[11:48] <wallyworld> babbageclunk: and hopefully/maybe the StartInstance args used to start an instance in maas would have a tags attribute so you can start an instance and apply tags in one call without having to follow up with AddTag()
[11:48] <wallyworld> doesn't the underlying api have a query machines method?
[11:48] <wallyworld> where you pass filter attributes to query on for example?
[11:48] <wallyworld> which is implemented by Controller.Machines()
[11:49] <babbageclunk> wallyworld: It does, but it doesn't support tags.
[11:49] <wallyworld> oh, damn
[11:50] <babbageclunk> wallyworld: The tag querying is done from a separate place in the api - you couldn't search by tag AND mac addresses, for example.
[11:50] <wallyworld> babbageclunk: so, we should construct the api to be the best it can be for juju and so it is consistent with our design goals; we can adapt that to the underlying maas api and then work with them to improve theor api if it is not "tasteful"
[11:50] <babbageclunk> (Well, without doing that filtering in the gomaasapi ourselves.)
[11:50] <wallyworld> if the underlying api is not perfect, we should not build on that an expose it
[11:51] <wallyworld> we should adapt to it so that if/wehn it improves, out api stays nice and clean
[11:51] <wallyworld> that's IMHO
[11:52] <babbageclunk> wallyworld: yeah, I see what you mean.
[11:52] <wallyworld> there's nothoing wrong with writing an abstraction layer that hides some dirty laundry :-)
[11:54] <babbageclunk> ok - I'm going to think about that while I go for a run. Thanks!
[11:54] <wallyworld> babbageclunk: so yeah, think of a Tag like a Device; a machine instance has a Devices() method; it would also have a Tags() method. and just as there's CreateDevice(), also there will be a CreateTag() etc
[11:54] <wallyworld> have fun
[11:54] <wallyworld> or AddTag()
[12:00] <rock_> Hi. I want to deploy openstack using [MAAS+openstack-base-bundle]. Can anyone please give me the detailed hardware requirements. and refrence links for doing that.
[13:05] <babbageclunk> wallyworld: still around?
[13:08] <babbageclunk> wallyworld: Actually, I'm seeing a yoda-like apparition of you telling me how to handle the thing that occured to me on the run, so that's fine.
[13:26] <voidspace> down to two failing packages
[13:35] <dimitern> voidspace: \o/
[13:35] <dimitern> out of how many?
[13:41] <natefinch> anyone familiar with configuring squid?
[13:45] <natefinch> dimitern, voidspace, frankban, dooferlad: ^^
[13:46] <natefinch> all I want is the simplest "just forward everything from everyone" ... which google seems to think I am unique in wanting
[13:49] <dimitern> natefinch: I've been there :) let me check my maas proxy setup
[13:49] <natefinch> dimitern: exactly what I need it for :)
[13:50] <mup> Bug #1619682 opened: [azure] can't bootstrap in Central US : no OS images found for location <juju-core:New> <https://launchpad.net/bugs/1619682>
[13:52] <dimitern> natefinch: here's my /var/lib/maas/maas-proxy.conf: http://paste.ubuntu.com/23124122/
[13:53] <dimitern> natefinch: it's not exactly allow everything from everyone, but every segment defined in localnet
[13:56] <natefinch> the problem with that is that then I have to edit it when things change... and if it breaks, I have to figure out what I messed up...  whereas if there were something like "mode transparent" that just did the right thing, I wouldn't have to wonder if juju is broken or my proxy is broken.
[13:56] <natefinch> dimitern: I'll try to make yours work for me.  Thanks
[13:57] <dimitern> natefinch: I hope it helps; fwiw I found transparent mode to be quite difficult to get working right
[13:57] <natefinch> dimitern: not so transparent, eh?
[13:58] <dimitern> natefinch: I found that using explicit http_proxy like http://10.20.20.2:8000 works best
[13:58] <dimitern> with transparent mode you'll have tons of issues around TLS
[13:58] <natefinch> dimitern: ahh yeah, that makes sense
[14:00] <dimitern> natefinch: last time I tried to get transparent mode working with e.g. https://cloud-images.ubuntu.com/ took me a few hours and at the end it was still not usable
[14:00] <natefinch> dimitern: well that makes testing this bug a lot harder
[14:01] <dimitern> natefinch: you could do other things, like iptables + DNAT to the non-transparent proxy host:port
[14:04] <natefinch> dimitern: that sounds much easier :/
[14:06] <dimitern> natefinch: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
[14:07] <rock_> dimitern: Hi. I pused my charm to charm store. I am trying to set BUG URL. Here I am facing issue. pasted issue info : http://paste.openstack.org/show/566078/
[14:14] <dimitern> rock_: hey, I'm not sure why you're getting this error - where's your charm's source ?
[14:20] <macgreagoir> natefinch: I don't have a maas2 setup. Maybe first step is me installing something and seeing what it needs for you?
[14:20] <rock_> dimitern: my charm source https://jujucharms.com/u/siva9296/kaminario-openstack
[14:21] <dimitern> rock_: I mean is it on launchpad or github, etc. ?
[14:22] <natefinch> macgreagoir: we could just screen share on my machine, would seem more efficient
[14:23] <macgreagoir> natefinch: Aye, true enough. I mostly want to see what it has now as a proxy service, compared to 1.x.
[14:27] <rock_> dimitern: my source is not on Github. And please tell me what it means [is it on launchpad]
[14:28] <dimitern> rock_: e.g. the cinder charm (https://jujucharms.com/cinder/) has bugs-url=https://bugs.launchpad.net/charms/+source/cinder/+filebug but that's because its source is at https://code.launchpad.net/charms/+source/cinder
[14:32] <rock_> dimitern: So How can I put my source on launchpad?
[14:32] <dimitern> rock_: it doesn't have to be on launchpad - use whichever code hosting / bug tracker you're familiar with
[14:33] <dimitern> rock_: have a look if this might help: https://jujucharms.com/docs/stable/charm-review-process
[14:35] <dimitern> rock_: maybe someone from the charmers team might be able to help you better (or in #juju), like marcoceppi, jcastro, lazyPower
[14:37] <rock_> dimitern: we don't have any bug tracker as of now. for pushing charm we used https://jujucharms.com/docs/2.0/authors-charm-store. And Used https://github.com/openstack-charmers/release-tools/blob/master/push-and-publish#L138 to set bug URL.
[14:37] <rock_> dimitern: OK. Tahank you. I will ask.
[14:39] <dimitern> sure, np
[14:42] <dimitern> katco: ping
[14:42] <katco> dimitern: pong
[14:42] <katco> dimitern: err i mean "route to katco not found because of some obscure networking setup affecting juju"
[14:42] <dimitern> katco: so it was decided to go less verbose and no way to bump it back up even you want all the details?
[14:42] <dimitern> hehe
[14:43] <katco> dimitern: yeah, that was what was suggested in the bug rick opened
[14:44] <katco> dimitern: i wanted to log the messages to debug instead, but was getting late and couldn't find a hook to a logger with debug on it. i can certainly figure that out though
[14:44] <dimitern> katco: ok
[14:45] <mgz> natefinch: double checking, this issue is wht dbus thing you fixed in 1.25.6? http://paste.ubuntu.com/23124253
[14:51] <mup> Bug #1619682 changed: [azure] can't bootstrap in Central US : no OS images found for location <cloud-images:New> <juju-core:Invalid> <https://launchpad.net/bugs/1619682>
[14:52] <dimitern> katco: you've got a review - though not terribly useful I'm afraid
[14:52] <katco> dimitern: not a problem, tyvm for looking at it in the 1st place
[15:01] <mgz> macgreagoir: so, I have an answer on how we've done charmstore testing
[15:01] <macgreagoir> mgz: I'm interested! :-)
[15:01] <mgz> we had a test that monkeyed with iptables after bootstrap on the state server
[15:02] <mgz> so when deploy happened after it would go off and talk to the staging store
[15:02] <mgz> but... we appear to have lost the test
[15:04] <mgz> macgreagoir: aha, assess_cs_staging.py in juju-ci-tools
[15:04] <mgz> macgreagoir: also, there seems to be a JUJU_CHARMSTORE envvar that should do something
[15:04] <mgz> but I'm not sure where or what
[15:05] <macgreagoir> mgz: Let me see if I can find that. Rings a bell from a code comment.
[15:05] <katco> mgz: oh god please don't check something like that into juju's src tree =|
[15:07] <natefinch> mgz: yes, exactly
[15:48] <babbageclunk> voidspace: still around? What timezone are you in at the moment?
[15:54] <redir> morning
[16:17] <voidspace> babbageclunk: UK
[16:17] <voidspace> babbageclunk: so yes
[16:17] <voidspace> babbageclunk: although grabbing coffee - back in 5!
[16:17] <babbageclunk> voidspace: okcool
[16:18] <voidspace> babbageclunk: finethen
[16:20] <babbageclunk> voidspace: pingmewhenyou'reback
[16:29] <voidspace> babbageclunk: back
[16:29] <babbageclunk> voidspace: Cool - can we hang out?
[16:29] <voidspace> babbageclunk: ok
[16:30] <voidspace> babbageclunk: standup one
[16:30] <babbageclunk> voidspace: core, right?
[16:30] <voidspace> babbageclunk: yep
[16:36] <natefinch> gah, my eyes.... evidently debug log uses color now
[16:41] <perrito666> lol
[16:42] <perrito666> I am starting to think that someone actually adds weak points on purpose on mongo tooling
[17:05] <rock_> dimitern : As we discussed before. This issue was not solved. Series miss match issue between mycharm and cinder while adding relation from JUJU GUI. pasted info  http://paste.openstack.org/show/566123/
[17:09] <katco> hatch: ^^^
[17:09]  * hatch pops in
[17:10] <katco> hatch: looks like maybe the gui is choosing the wrong series to deploy for a charm
[17:10] <hatch> yes I believe we've got an open PR atm for this fix
[17:10] <hatch> one moment while I confirm
[17:10] <hatch> ^ rock_
[17:14] <voidspace> babbageclunk: ping
[17:15] <babbageclunk> voidspace: pong
[17:15] <hatch> rock_: this is indeed a GUI bug and I believe it will be resolved with the next GUI release next week cc/ katco
[17:15] <katco> hatch: thanks for checking in!
[17:15] <katco> rock_: i believe if this is critical for you to resolve, it's possible to deploy a beta version of the gui. is that right, hatch?
[17:16] <voidspace> babbageclunk: PM sent
[17:16] <hatch> katco: unfortunately the PR hasn't yet made it through the review & qa process
[17:16] <hatch> I'm working my way through them now
[17:17] <rock_> katco: Yes. It was critical. Because I have to test my charm in both ways[CLI and GUI]. I have critical deadline for my charm to deliver to the client.
[17:18] <hatch> rock_: when is the deadline?
[17:19] <hatch> assuming the PR is good, I will be able to get you a beta build of the GUI to test in a few hours
[17:19] <rock_> hatch/rock: I have to test it and then deliver by next week[8/9/2016].
[17:20] <hatch> ohh ok that's perfect then, we should have a new release of the GUI out by then as well
[17:21] <rock_> hatch: Thank you. now please provide beta build of the GUI. i will test on it.
[17:21] <hatch> regardless though I'll ping you when I have confirmed this bug fixed (or not) with a beta build of the GUI
[17:22] <rock_> hatch: OK. Thank you for your support.
[17:25] <hatch> anytime, glad to help
[18:30] <rock_> Hi. I have a question.  For suppose acc. to openstack-base bundle requirements I have taken machines. Which node I have to take as main node to deploy bundle? Once I deploy bundle how that bundle distribute service charms to hardware machines that we have taken?
[18:31] <rock_> please provide me the network architeture of {MAAS+openstack base bundle]  based openstack setup.
[18:33] <katco> rock_: that's really a better question for #juju. you could try pinging elmo there, but i think it's past his EOD
[18:34] <rock_> katco; OK. Thank you.
[19:04]  * redir lunches
[19:18] <lazyPower> omg we have color in tabular status output on key fields?
[19:18] <lazyPower> \o/
[19:18] <natefinch> there was a lot of work lately put into colorizing things
[20:02] <hatch> rock_: sorry, the fix for the issue you mentioned is not yet complete and will need some additional time to fix before it can be merged in
[20:03] <hatch> rock_: a possible workaround is to go into the subordinates "Configuration" pane in the inspector and change it to match the series you've related to
[20:03] <hatch> and then click deploy
[20:03] <hatch> This may or may not work.
[20:04] <hatch> However, if your charm works as expected when deployed via the CLI you can be confident that it will also work via the GUI (assuming the GUI is free of bugs ;) )
[20:29] <natefinch> I can't tell if juju is screwed up or maas is screwed up, or if I've screwed up.
[21:32] <hatch> Can anyone confirm for me that the Juju controller does not support local charms for the AddCharm api call?
[21:45] <katco> hatch: pretty sure this is true. you need to call AddLocalCharm
[21:46] <mbruzek> hi katco: I have a problem
[21:46] <mbruzek> katco: I was hoping you could help me
[21:46] <mbruzek> ERROR creating API connection: invalid entity name or password (unauthorized access)
[21:46] <katco> mbruzek: ok, what's up?
[21:46] <cmars> hatch, that is correct. apiserver/client.AddCharm calls AddCharmWithAuthorization which rejects any charm URL that isn't a cs: URL
[21:46] <mbruzek> I did `juju log out`  and now I can not log back in
[21:46] <katco> mbruzek: i think that's an open bug...
[21:47] <mbruzek> katco: and I can not kill my controller
[21:47] <mbruzek> katco: is there a work around?
[21:48] <katco> mbruzek: https://bugs.launchpad.net/juju/+bug/1617190
[21:48] <mup> Bug #1617190: Logout required after failed login <juju:Incomplete by natefinch> <https://launchpad.net/bugs/1617190>
[21:48] <katco> mbruzek: i guess you need to log out again?
[21:51] <mbruzek> katco: I can not get that to work, it never logs me out of the controller.
[21:52] <mbruzek> $ juju logout
[21:52] <mbruzek> Logged out. You are still logged into 1 controller.
[21:52] <mbruzek> mbruzek@warhorse:~$ juju status
[21:52] <mbruzek> ERROR no credentials provided
[21:55] <katco> mbruzek: i'm trying to figure out where that error occurs
[21:56] <katco> mbruzek: what version are you on?
[21:56] <mbruzek> 2.0-beta16-xenial-amd64
[21:59] <katco> mbruzek: can you run that command with --debug?
[22:00] <mbruzek> katco: http://pastebin.ubuntu.com/23125739/
[22:04] <katco> perrito666: are you still on?
[22:04] <perrito666> katco: sort of
[22:04] <katco> perrito666: can you help mbruzek? i don't know where this error comes from
[22:04]  * perrito666 reads backlog
[22:05] <mbruzek> perrito666: I seem to be in a weird state
[22:06] <perrito666> mbruzek: can you ssh into the machine and check the log there? it will tell you which api endpoint rejected you. My best guess is that we have some wrong permission around some basic call
[22:07] <mbruzek> ssh using ubuntu to the controller did not work.
[22:08] <mbruzek> ssh ubuntu@54.67.11.148 -> Permission denied (publickey).
[22:08] <katco> bradm: juju switch controller && juju ssh 0
[22:08] <katco> bradm: oops sorry for the ping
[22:08] <katco> mbruzek: ^^
[22:08] <mbruzek> katco: juju switch controller -> ERROR getting account details for qualifying model name: account details for controller containers not found
[22:09] <mbruzek> because I am not logged in?
[22:09] <katco> i have no idea... i have done 0 with the new ACL stuff perrito666 helped put in
[22:13] <mbruzek> katco: I was able to list-controllers
[22:13] <perrito666> mbruzek: mm, you shoud try ssh -i ~/.local/share/juju/ssh/id_rsa ubuntu@yourip
[22:14] <mbruzek> perrito666: I was able to juju switch controller amazon  and destroy the controller
[22:14] <perrito666> or that :)
[22:15] <mbruzek> perrito666: do you still want me to ssh ?
[22:15] <perrito666> mbruzek: well you have nothing to ssh into now :p
[22:15] <perrito666> no worries, if this is a bug it will happen again soon
[22:15] <perrito666> ok, I am well past EOD/W and going to theatre, cuall
[22:16] <mbruzek> bye and thanks perrito666
[22:16] <katco> perrito666: ta
[22:18] <mbruzek> katco: Thanks for walking me through it. I don't have a console for this aws account and there was no other way for me to kill that instance
[22:18] <katco> mbruzek: no worries, sorry for the trouble/bug. speaking of, can you file a bug for that?
[22:19] <mbruzek> Do you want me to update the bug you found?
[22:19] <katco> mbruzek: no i'm not sure it's related
[22:19] <katco> mbruzek: if it is we can always dupe it later
[22:44] <hatch> katco: ohhh AddLocalCharm thanks
[22:44] <katco> hatch: np
[22:44] <katco> hatch: i am landing some tests which actually do a decent job of documenting the API calls necessary for deploying charms
[22:45] <hatch> oh great - we just have a bug which throws an error for local charms but deploys fine - I hnarrowed it down to not needing the AddCharm call
[22:45] <hatch> but we should likely instead swap AddLocalCharm
[22:45] <hatch> although it doesn't appear necessary
[22:47] <hatch> katco: so we're doing an POST to upload the actual charm then just a deploy and it works...is this just a fluke and we should instead call https://github.com/juju/juju/blob/master/api/client.go#L269
[22:50] <katco> hatch: wait, i'm sorry. AddLocalCharm is a client-side call which just reads the charm from disk... uploading and then deploying is just fine
[23:07] <hatch> ohh ok perfect thanks for confirming katco
[23:07] <hatch> have a good weekend