=== psivaa_ is now known as psivaa === thumper-dogwalk is now known as thumper === JoseeAntonioR is now known as jose === scuttle|afk is now known as scuttlemonkey [05:13] morning [05:13] marcoceppi: Marco are you there? [05:15] I have a problem with creating a mysql database, its not providing the password file to login as root in order to create the user/database when I add a relationship with an webapp i created [05:16] I think i have my metadata.yaml wrong or something on the relationship with mysql === med_ is now known as Guest93664 [10:35] Hello there. I get the following error, does some know where to look? "Service placement to machine not supported" [10:54] what you doing BlackDex ? [11:07] magicaltrout: Deploing ;) [11:07] But i fond the problem [11:07] i pointed to a wrong machine [11:08] cool [11:08] that was going to be my suggestion :P [11:49] hehe thx ! [12:02] jamespage: https://github.com/juju-solutions/layer-basic/pull/45 however, you can patch this in the charms in the future by having the following in your layer.yaml http://paste.ubuntu.com/15340870/ [12:03] those will be evaluated before any pip calls are made (so if you need like buildessentials or libX-dev installed for a pip module, you can have that defined in the packages option) [12:11] marcoceppi, oh nice - thanks! [12:11] jamespage: either way, it'll land when cory_fu or someone else takes a look and +1's it [12:12] marcoceppi, thanks for doing the fix - I was about to poke around and see if I could fix that up [12:12] marcoceppi, btw [12:12] http://paste.ubuntu.com/15340899/ works lovey [13:57] marcoceppi: Hello Marco, I have a quick question. [13:57] if you are there that is [13:57] o/ nvalerkos [13:57] so, I am trying to generate a new database connection with a non root user through metadata.yaml [13:58] but I am not getting it right [13:58] nvalerkos: sounds good, which charm are you connecting to? [13:58] postgresql? mysql? [13:58] I am making my own charm, I am using the mysql [13:59] nvalerkos: sounds good - do you have your charm uploaded somewhere so I can follow along and take a look? [14:00] marcoceppi: sent on prv message [14:01] nvalerkos: okay, so your charm "requires" a MySQL interface, it's not a peer [14:02] marcoceppo: I used it that, however it was connecting without the root password when using the db-relation-joined and getting a couldn't connect in log of python charm (mysql side) [14:05] nvalerkos: the MySQL relations will provide database, user, password, port, hostname, you will need to check to make sure you have those values before contining since tihs is an async system [14:05] oh [14:06] ok got it, so the relation with requires is correct I just need to wait for complete relation credentials. [14:06] Async. [14:08] marcoceppi: thanks. [14:08] nvalerkos: here's an example of a charm that does tomcat + MySQL and it's hook: https://api.jujucharms.com/charmstore/v5/~spagobi-charmers/trusty/spagobi-4/archive/hooks/metadatadb-relation-changed and https://jujucharms.com/u/spagobi-charmers/spagobi/ [14:08] metadatadb is the name of the MySQL relation for this charm [14:09] nvalerkos: the system is async, but don't block the hook waiting. If you don't have the data just exit 0 from the hook and wait for the hook to be called again [14:10] marcoceppi: ok got it. I am using python [14:10] nvalerkos: ah, same concept, but without all the base ;) [14:10] bash [14:10] ah [14:10] ok [14:10] will do. thanks again. [14:11] I saw that when you first gave me that charm link yesterday and did not gave any attention to it. [14:11] thedac, coreycb, beisner: got time for a quick one? [14:11] https://review.openstack.org/#/c/291146/ [14:12] jamespage, sure. 2-for-1? :-) https://review.openstack.org/#/c/290943/ https://review.openstack.org/#/c/288483/ [14:13] beisner, sure - looking [14:13] jamespage, ps, we've got the charm-single config file repo live now. https://github.com/openstack-charmers/bot-control/tree/master/config/charm-single [14:13] so ceph single is good, and the odl ones get the right vars, but odl seems to be trusty-only [14:13] beisner, I just put up a fix for odl - it was missing systemd support for wily [14:14] jamespage, sweet, thanks [14:14] I had that in an old bzr branch that I had some other stuff in [14:14] picked it out - hopefully should work OK now [14:14] jamespage, did you see the c-h fork that one of the odl charms is using? [14:14] beisner, yes [14:15] beisner, openvswitch-odl is a bit of a mess tbh - we need to move it to layers properly [14:15] beisner, it now passes amulet smoke at least [14:15] https://review.openstack.org/#/c/287153/ [14:16] beisner, just kicked off a full run of that [14:18] beisner, another fairly trivial one - https://review.openstack.org/#/c/289249/ [14:19] jamespage, oooo. idea. we should have more magic words to kick of relevant mojo specs. in this case, it'd be the ssl-everywhere specs. it would take rejigging the specs a bit to use the change branch, but doable and probably what we want. [14:19] sounds awesome [14:25] tinwood, not sure whether you spotted but https://review.openstack.org/#/c/288733/ needs a rebase [14:27] jamespage, Thanks for spotting this. I was waiting on gnuoy's keystone_v3 to get merged before I did the rebase. I'm guessing that's gone through, so I'll rebase after I push this fix to charm-helpers. [14:27] tinwood, it has [14:28] thanks, will do. [14:31] thedac, narindergupta: hey - I'm due to push the nuage charms live today - but I think they are all in a private team I can't see [14:32] https://bugs.launchpad.net/charms/+bug/1510672 [14:32] Bug #1510672: Nuage Canonical Charm: vrsg [14:33] jamespage: let me give you access for same. [14:33] narindergupta, ta [14:34] jamespage: you are part of team now and will subscraibe you that bug [14:35] jamespage: done [14:37] jamespage: please let me know once live so that we can comnunicate the same to nuage team as well [14:40] marcoceppi, ok I'm going to put these nuage charms into the charm store using charm upload/publish etc... [14:40] jamespage: gl [14:40] marcoceppi, if I place them under 'charmers' does that make them the official charm? [14:41] jamespage: no, that's not really how it works [14:41] marcoceppi, ok I'm missing a step then [14:41] jamespage: you upload then publish them /somewhere/ [14:41] I could see how to go from development to published [14:41] ie ~nuage/trusty/nuage-charm [14:42] or whever [14:42] ok [14:42] then, you just "charm promulgate" [14:42] oh - ok [14:42] lemme try that [14:42] and that makes that revision the actual official one then... [14:44] jamespage: pretty much [14:47] marcoceppi, bleh - charm-store does not know I'm a member of nuage-charmers... [14:47] I suspect regular injestion from lp? [14:47] jamespage: what's the error you're getting? have you `charm login` yet? [14:48] "unauthorized: access denied for user "james-page" [14:48] " [14:48] marcoceppi, I've been publishing aodh all morning so I know I'm normally ok [14:48] https://jujucharms.com/u/james-page/aodh/9 [14:49] I guess I can put them under charmers for now and move them later [14:49] jamespage: huh, looks like you're a member as of 2 mins ago ;) https://launchpad.net/~nuage-charmers [14:49] marcoceppi, yeah - I just created that team :-) [14:49] jamespage: I wouldn't moving later sounds painful [14:49] jamespage: try logging in again? [14:50] jrwren: help ^? [14:50] err, frankban ^? [14:51] jamespage: will have to log out/in to catch the new team? [14:51] rick_h__, how do I logout? [14:51] being a dumbass [14:51] jamespage: oh, from cli? [14:51] jamespage: rm -rf .go-cookies [14:51] rm ~/.go-cookies, IIRC [14:51] jamespage: think it's still there [14:52] ta that did the trick [14:52] \o/ [14:53] * marcoceppi pines for the new charm command [14:55] working nicely [14:55] narindergupta, https://jujucharms.com/u/nuage-charmers/ [14:56] rick_h__, marcoceppi: the series in metadata support is great bt [14:56] jamespage: thanks [14:56] w [14:56] jamespage: <3 [14:56] jamespage: yeah, I can't take credit for that, but it makes charming so much easier [14:56] jamespage: vrsg is not listed yet. Are we releasing vrsg as well? [14:57] narindergupta, I have slow upstream internet :-) [14:57] jamespage: what a concept, you're the bottleneck to the store and not some ingestion process ;) [14:57] marcoceppi, lol [14:58] jamespage: thanks [14:58] marcoceppi, I was local deving this morning and deploying on serverstack - boucing via the charm-store was neat [14:58] narindergupta, all done [14:58] jamespage: thanks I can see it now [14:58] :D jamespage with the new channel stuff, it'll be even more awesome to rev around in the store [14:58] narindergupta, a bundle would be a nice next step :-) [14:59] jamespage: yeah thay have bundle and i will ask team to work on with latest upstream charm and submit for review [14:59] narindergupta, sure [15:02] thedac, all promulgated - did it new style [15:02] thedac, I'll explain later [15:04] jamespage: looks great https://jujucharms.com/nuage-vrs/ [15:04] marcoceppi, indeed [15:05] something is odd with interface-rabbitmq - always takes forever to clone [15:11] marcoceppi - just one thing, and i'm guilty of this too. but the card says "by: undefined" [15:11] we're missing a data point on the charms to populate that field in the card [15:12] lazyPower: that's something for the charmstore [15:13] also it would be cool (if you can't already) to embed a paragraph of the readme into the card [15:15] jamespage, shall we land openvswitch-odl? full passes too. https://review.openstack.org/#/c/287153/ [15:15] beisner, go for it [15:16] could one of the charms tell me if hold up on https://bugs.launchpad.net/charms/+bug/1538573 is expected? AFAICT it just needs to be merged [15:16] Bug #1538573: New collectd subordinate charm [15:23] thedac, gnuoy, beisner: retro'ed my upload script into designate* charms [15:23] https://jujucharms.com/u/openstack-charmers-next/designate [15:23] https://jujucharms.com/u/openstack-charmers-next/designate-bind [15:23] jacekn: for some reason that request is blankly ignored :) I even asked yesterday for you and got no response either...... [15:24] marcoceppi, is the 'charm' binary a go binary? [15:24] you must have done something mean in a past life [15:24] jamespage, cool. we should probably add both to openstack-charmers @ github for dev, then propose upstream projects from there. [15:24] aodh and designate that is [15:24] beisner, we can actually just slurp them direct from lp [15:24] jamespage, oh cool. [15:24] beisner, yah - them being git repos and all [15:25] beisner, we should probably sort out some tests first tho [15:25] right [15:25] they are a bit cowboy right now but only due to the very early lifecycle they are in [15:25] I'd prefer to push under openstack once we have them in better shape... [15:25] ack [15:26] beisner, series in metadata is a must for all of our charms... [15:26] its a single charm upload command and the charm-store does the rest! [15:26] jamespage, yes. so, what happens if we define series now, and try to use the charms with 1.25.x ? [15:26] beisner, it all works [15:27] well then we should add that metadata now :-) [15:27] beisner, charm store interprets the cs:xxx request and figures out the right thing todo [15:27] beisner, agreed [15:27] beisner, I feel we could move to a post-commit charm upload quite quickly now [15:28] beisner, http://paste.ubuntu.com/15341662/ [15:28] its that simple [15:29] magicaltrout: maybe people are afraid of collectd :) [15:30] jacekn: indeed [15:30] spam the mailing list as well until you get a response :) [15:30] post a commend on the LP tracker as well [15:30] someone will be watching somewhere [15:31] I'm also afraid that there is a bigger problem with the review process here [15:32] jacekn: i believe the process is being overhauled so its a lot more visible, but you need to ask marcoceppi and/or tvansteenburgh about that stuff [15:32] there should be no need to chase your contributions, it's charmers who should be chasing and encouraging people to do this work [15:32] jamespage, beisner: are you seeing anything odd with ceilometer testing? [15:32] it shouldn't take 3 or 4 days of asking to get an answer :) [15:32] absolutely jacekn [15:32] tinwood, yes - what do you see? [15:32] kick marcoceppi [15:32] TypeError: can't pickle thread.lock objects. [15:33] tinwood, nope never seen that one [15:33] jamespage, it's in ceilometerclient/v2/client.py [15:33] Might be a version thing. [15:33] * tinwood hmmm [15:33] maybe... [15:34] jamespage: it is, it's being switched to that in xenial [15:34] jacekn: my charm went into the review process, got reviewed once then stopped, but I didn't know if I had to do something or not to get it re-reviewed, so its just waiting until I get enough time to stand it back up again [15:34] so I know what you mean [15:34] jamespage: narindergupta: \o/ Thanks for getting nuage charms promulgated. That was a long time coming. [15:34] jacekn: there's a huge problem with the review process, it's being overhauled with a public beta of the new process coming out in a few weeks [15:35] narindergupta, what's your lp id? [15:35] thedac: thanks for your patience as well i know it was long dur [15:35] no problem [15:35] jamespage: narindegupta [15:35] marcoceppi: cool! Maybe in the mean time nominate one person a day and put them in the topic here so that people know who to chase? [15:36] jacekn: what do you mean? [15:36] narindergupta, thedac: I created https://launchpad.net/~nuage-charmers [15:36] that's the team under which the charms are uploaded and published on the charm store [15:36] great [15:36] marcoceppi: so instead of me asking every day and getting silence I could hilight somebody directly and get a response, even if that response is "your review is in the queue" [15:36] jamespage: thanks [15:36] so adding people to that will allow future charm upload's [15:37] jamespage: gotch you [15:37] thedac, narindergupta: they are one of the first partners I've promugated this way ... [15:37] its neat [15:37] Sounds like a much better process [15:37] jamespage: yeah looks cool [15:37] narindergupta, if they want to move they charm development out of launchpad that's ok - the requirement for bzr branches for charm injestion is going away [15:37] jamespage: is it possible to move other partners also on same process specially plumgrid? [15:38] narindergupta, yes [15:39] jamespage: please look into it whenever gets time. Also it seems nuage and plumgrid wants to stick to launchpad for now. May be in future they might move to github [15:39] narindergupta, they can do git on launchpad if they prefer - and this is only vcs [15:39] not bug tracking etc... [15:40] jamespage: gotch you and will inform them. [15:41] narindergupta, I made you an admin of nuage-charmers so you can add the nuage guys [15:41] jamespage: sure will ask the team who else to be involved and add them. [15:41] jamespage, is ceilometer charm written against the v2 client? [15:42] tinwood, tbh you're outside of my knowledge now [15:42] it might be - the tests? [15:42] oh it's definitely tests. Whose our ceilometer specialist? :) [15:42] jacekn: well, the queue is open, http://review.juju.solutions [15:43] tinwood, sounds like you might be now :-) [15:43] * tinwood lol [15:43] jamespage, I will dig into it. [15:43] tinwood, tbh its always been a peripheral charm - not that many users user it [15:43] we don't on serverstack [15:44] ah, I see. I don't think it'll be a big change, just need to work out what's going on and whether it needs to be backwards compatible. [15:44] lazyPower, you gonna use charm upload for nexenta as well? [15:44] Yep! [15:45] Now that all the pipeline bits are there, there's almost no reason not to :) [15:45] indeed [15:46] tinwood, ceilometer charm tests seem ok. lmk if you see troubles therein. [15:51] thanks beisner - it's probably a difference in versions on the test box vs my bastion. [15:52] beisner, I have on the bastion: python-ceilometerclient 2.3.0-0ubuntu1 [15:57] Is it always the case that the first leader-elected hook will run before install? === JoseeAntonioR is now known as jose [16:08] Is there a way to download manually the cloud-trusty lxc image before issuing a deploy --to lxc:x ? [16:13] deanman: there is [16:13] kind of [16:13] well, in general, it's in http://cloud-images.ubuntu.com, but the process for preseeding on a deployed node I'm not 100% on [16:16] marcoceppi: when issuing a deploy it's not very informative on what goes on the background and whether is downloading the lxc or something. So i was thinking that maybe if i could download it manually i could present some more feedback to the user... [16:24] tvansteenburgh: my stab at updating charmworldlib turned out pretty decently using theblues instead, finishing up tests now [16:24] marcoceppi: excellent [16:24] it's not a perfect match charmworldlib -> libcharmstore, but it's easy enough to patch [16:34] It looks like the base charm layer is installing/upgrading pip outside of what's packaged in trusty, creating a /usr/local/bin/pip that calls python3 instead of python2. Does that sound right? [16:35] I'm running into issues because something I'm installing has a syntax error with python3. I expect pip vs. pip3 similar to the packaged versions. [16:43] wallyworld: new bootstrap for maas built-in is nice [16:43] wallyworld: especially now you can just define your credentials for maas and not a local name [16:46] with ec2 provider, how do i specify the instance type for the controller? tried '--config instance-type=t2.micro' but it didn't work, and did not complain [16:52] aisrael: if you need to, use the venv flag in the basic layer to work around this [16:53] marcoceppi: ack. I'm trying the wheelhouse approach, but I'll look at that next if this doesn't work. [16:54] marcoceppi: in general, though, I'm worried this behavior could be problematic (pip actually being pip3) [16:55] aisrael: yes, this is why I always recommend we use virtualenv for all packaging and managing of pip [16:55] deb and pip are competing packaing formats, and many people don't care [16:57] tvansteenburgh, hey - can we get the juju-deployer release into https://launchpad.net/~juju/+archive/ubuntu/stable ? [16:57] then I can transition our core bundles over to use git directly rather than lagging on bzr mirrors... [16:57] marcoceppi: That totally sounds like a blog post waiting to be written. ;) [16:58] aisrael: I will, getting tired of finding problems because people pip install willy nilly [16:58] * marcoceppi rage posts [16:59] jamespage: yeah. have you used the latest release? === bcsaller_ is now known as bcsaller [17:00] tvansteenburgh, yes I put it in xenial last week and have been using it since... [17:00] jamespage: great, thanks. i'll get it in stable then [17:03] tvansteenburgh: lmk if you need help backporting to the ppa [17:03] * marcoceppi has a script [17:04] tvansteenburgh, ta [17:04] marcoceppi: i always just ask frankban to do it. i need to fix a build problem first though [17:05] tvansteenburgh: I think we decided to just copy the daily built deployer package when you are ready for a new release and you have QAed the deb [17:06] frankban: yes that's correct! [17:06] frankban: where's that built? [17:06] how do you specify the amazon machine image when deploying ? [17:06] https://launchpad.net/~ahasenack/+archive/ubuntu/juju-deployer-daily [17:07] marcoceppi: ^ [17:07] marcoceppi: there [17:07] cholcombe: the instance type? [17:07] cool [17:07] rick_h__, yeah i want to deploy on xenial to test [17:07] cholcombe: oh series? [17:07] cholcombe: --series= [17:07] ah cool [17:07] cholcombe: on 2.0? [17:07] cholcombe: or 1.25? [17:07] no i'm 1.25 [17:08] cholcombe: so there you need to local charm it and do the series directory/etc [17:08] looks like maybe juju set-env "default-series=xenial" ? [17:22] so how do i bootstrap with juju 2.0 and define a different default model? [17:23] I was thinking something like: juju bootstrap maas-production:prod1 maas/192.168.10.114 --debug --upload-tools [17:23] stokachu: 'default model'? [17:23] so when you define the controller it creates a model with the same name [17:23] stokachu: oh, that's coming in the future code [17:23] stokachu: I thought it was in beta2 to go out today but I'm told it didn't make it [17:23] ah ok [17:23] i would like to have like maas-production:development,staging,production models [17:24] stokachu: soon, (beta3?) the default model will always be called admin, and that's the main controller model. Juju will also create a model called 'default' which you are auto put into [17:24] stokachu: and to change that you can pass an arg that's something like '--default-name' [17:24] stokachu: so you'd have models "admin" and your custom name passed on the flag [17:24] so there will always be a default model for admin? [17:24] stokachu: there will always be an "admin" model as that's technically the 'controller' [17:25] stokachu: but folks shouldn't mess with it much, but we expect folks to do things common to all models there [17:25] yea i think that's a bit confusing, having a 'controller' but a model that is also the 'controller' [17:25] stokachu: yea, it's an implementation detail that's leaked that we'll work on over time [17:25] ok cool [17:26] stokachu: but yea, you can't remove-model admin [17:26] stokachu: because that's your controller [17:26] ah right, yea i think once the definition of the admin model is more clearer that'll help the confusion [17:26] stokachu: yep [17:26] that's the hope [17:27] is the --default-name something that was part of the changes in beta2 that didnt make it? [17:27] im running from master as well [17:35] ahasenack: ping [17:37] tvansteenburgh: hi [17:39] ahasenack: hey, i'm trying to figure out why juju-deployer daily build started failing. i can see the test failure in the build log, but the confusing bit is when i look in older (successful) build logs, there's no indication that `make test` was ever run [17:39] tvansteenburgh: I think, if I remember correctly, that tests might be skipped if it detects it's in a launchpad buildd [17:39] tvansteenburgh: maybe that check failed, and it thought it should run the tests [17:40] I have to check [17:54] Hey guys. Any way I can get the CIDR of the maas network in a charm? [18:00] ahasenack: okay thanks for your time. i just pushed a test fix so we'll see if that fixes the build [18:03] jamespage: whenever this build succeeds we can get the package moved to stable ^ [18:11] ahasenack: okay the build is fixed, but the version is behind (should be 0.6.4, not 0.6.1). how does that get updated? [18:19] tvansteenburgh: it's in the packaging branch [18:19] tvansteenburgh: let me update that [18:20] tvansteenburgh: juju-deployer - 0.6.1~bzr168~48~ubuntu16.04.1 <-- that's your build? [18:20] ahasenack: yep [18:21] tvansteenburgh: updated, r49 [18:22] marcoceppi: ping [18:22] o/ [18:22] marcoceppi: do you have a sec to take a look at an ubucon branch? [18:23] jose: link me up [18:23] https://code.launchpad.net/~ubucon-site-developers/ubucon-site/update-source-action [18:23] ahasenack: ta. for future reference, do i need to contact you for version bumps? [18:23] tvansteenburgh: I think so, the pkging branch the recipe uses is mine, https://code.launchpad.net/+branch/~ahasenack/juju-deployer/juju-deployer-packaging [18:24] marcoceppi: so, I think that update-source action is pretty straightforward, but are there any services that need restarting apart from that? [18:24] marcoceppi: action is here http://bazaar.launchpad.net/~ubucon-site-developers/ubucon-site/update-source-action/view/head:/actions/update-source [18:24] jose: that won't work [18:24] jose: you have to run an entire migration, etc in addition [18:24] ahasenack: ok thanks! [18:24] marcoceppi: the site isn't live-running from the directory? [18:24] tvansteenburgh: if you want you could copy the recipe to a team-owned account perhaps [18:25] jose: it is, but you have to run db migrations and such in addition to just updating the files [18:25] hmmk I'll dig a bit more into it [18:26] jose: you need the event to show up in the reactive framework and to reset the djang.ready or intalled or whatever event [18:27] ok, thanks [18:27] ahasenack: can you force a new build so i get the new version? [18:27] tvansteenburgh: yep [18:27] ahasenack: ta [18:27] done: https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily [18:28] tvansteenburgh: can you kick that as well? Just curious [18:28] ahasenack: i don't see a way to do so [18:29] ok [18:29] "Request build(s)" green link just above "Recipe contents"? [18:29] ahasenack: heh, there it is [18:29] cool [18:30] good to know, thanks [18:34] ahasenack: just noticed that frankban is offline now. can you copy that build to juju/stable, or tell me who can? jamespage has been using it for a week now and is ready to get it in stable [18:35] wow, that built fast [18:35] tvansteenburgh: hm, there might be a problem with the version number [18:36] tvansteenburgh: xenial has 0.6.4-0ubuntu1 [18:36] that's the same? [18:36] I mean, it's higher than my PPA, and on purpose [18:36] it's the same [18:37] tvansteenburgh: that being said, no, I cannot copy. I don't see the juju stable ppa in the target list [18:37] ahasenack: ok, will wait til tomorrow, thanks [18:37] jamespage: ^ [18:38] tvansteenburgh: have you tried sinzui? [18:38] or any of the juju a folk I bet [18:38] ahasenack: good idea, will try sinzui [18:38] s/a/qa/ I meant [18:55] for systemd with charmhelpers host.service_stop i need to pass an id parameter. It looks like I need to add that to the function [18:56] wait.. i think i can pass the service name with the id. I'm going to try it [19:51] stokachu: yeah, the built in maas was a last minute idea which seemed worthwhile. we'll get the credentials stuff sroted and it will be even better [19:51] jamespage: new deployer is in juju/stable [20:06] wallyworld: yea man sounds awesome [20:30] wallyworld: is there a way via list-models to determine which one is the admin model? [20:30] i want to be able to fitler out the admin model when presenting deployment models to an end user [20:31] stokachu: for now, it's the one called "admin". we'd have to look at tagging or something to do it better [20:31] stokachu: wait [20:32] that will be the case in the next beta [20:32] ah ok [20:32] for this beta it's the one named after the controller [20:32] juju bootstrap mycontroller lxd [20:32] right i figured as much, rick_h__ mentioned --default-name will that be exposed for the admin model? [20:32] the admin model will be mycontroller [20:33] --default-model will be to name the initial hosted model [20:33] the admin model will be "admin" [20:33] not the admin model correct? [20:33] ok [20:33] the default hosted nodel will be "default" [20:33] cool so i can just filter out based on the name [20:33] yeah [20:33] ok perfect [20:33] we may do it better with an attribute or something [20:33] can i change the name of default with --default-model? [20:33] but for now that will work [20:33] yes [20:34] in the next beta [20:34]