| rmcadams | ok bdx - back - so you think doing an 'add chassis' might be the differentiator to fix this eh? | 01:00 |
|---|---|---|
| bdx | rmcadams: possibly | 01:23 |
| rmcadams | deploying these two big nodes right now to test it out | 01:26 |
| bdx | rmcadams: a quick search turns up http://askubuntu.com/questions/663771/how-to-configure-maas-to-be-able-to-boot-virtual-machines-via-vmware-type | 01:28 |
| bdx | see the first answer | 01:28 |
| bdx | rmcadams: do you know how to use cloud init with virsh? | 01:30 |
| bdx | rmcadams: its worth looking into .... you can create a user-data file, and use that in combination with an ubuntu cloud image to create your vms on demand, instead of installing the os etc etc | 01:32 |
| rmcadams | honestly we havent done much with cloud init and virsh, I know you can boot instances with it etc... but we typically boot the virsh instances up to RedHat OSPD right now. | 01:32 |
| bdx | nice nice | 01:32 |
| rmcadams | it is nice, but it doesnt afford me the opportunity to "do more" like maas ;) | 01:33 |
| bdx | ahhh yeah , I was just thinking if you are wanting to create vms on those hosts on demand and check them into maas | 01:34 |
| bdx | http://blog.oddbit.com/2015/03/10/booting-cloud-images-with-libvirt/ | 01:35 |
| bdx | ^ is a nice read if you are interested | 01:35 |
| bdx | rmcadams: possably we are talking about different things .. my impression was that you wanted to deploy 2 hardware nodes with maas, then create a bunch of virtual machines on those hosts to check into maas | 01:37 |
| rmcadams | I do | 01:37 |
| rmcadams | so as an example, rather than spending a bunch of $ on hardware | 01:38 |
| bdx | exactly, ok | 01:38 |
| rmcadams | we build 4 infrastructure nodes | 01:38 |
| rmcadams | and build the application vms we need | 01:38 |
| rmcadams | like openstack director | 01:38 |
| rmcadams | sdn controllers etc | 01:38 |
| bdx | totally, I use to have a test lab that had a few of different setups that were just like that | 01:38 |
| bdx | you can totally do that | 01:38 |
| bdx | where I found some pain points was | 01:39 |
| bdx | getting the virsh vms all created and checked into maas | 01:40 |
| rmcadams | I wrote an ansible script for that | 01:40 |
| bdx | you need to ensure you provision the vms on a bridge that maas can provide dhcp through | 01:40 |
| bdx | ok | 01:40 |
| bdx | on top of that copying images around is messy, and creating the vms from isos is time consuming | 01:41 |
| rmcadams | you know it! | 01:42 |
| rmcadams | is that blog post above yours? | 01:42 |
| bdx | by using the cloud init userdata as a mounted iso, you can go from 0 to running instance in a fraction of the time | 01:43 |
| bdx | I didn't write it, but I remember it was the same post I found that led me to the solution I was after when I was figuring all this out | 01:43 |
| rmcadams | ya | 01:44 |
| bdx | the only gotcha about using the user-data, is you have to create a different config.iso specific to each instance, bc the meta-data contains instance-id: my-instance-id | 01:45 |
| bdx | local-hostname: my-host-name | 01:45 |
| bdx | Y | 01:45 |
| bdx | when you gen the config iso, you have to feed it the user-data and meta-data, so you end up with a config.iso for each vm | 01:47 |
| rmcadams | another thing that would be super nice, is if you could copy and paste config templates from 1 node to another node | 01:48 |
| rmcadams | since most of us deploy with repeatable hardware | 01:48 |
| bdx | yeah ... another thing you could try to make this faster | 01:49 |
| bdx | juju bootstrap your maas | 01:49 |
| bdx | deploy those two hardware nodes with juju | 01:49 |
| bdx | then just add a bunch of kvm to them with juju | 01:49 |
| rmcadams | so yah, I thought about that | 01:50 |
| rmcadams | one of my Canonical sales engineers told me that | 01:50 |
| bdx | then add the chassis in maas once it hass all the vms | 01:50 |
| bdx | idk ... | 01:51 |
| bdx | ha | 01:51 |
| stormmore | I am still trying to figure out the best way to bootstrap an einvironment so that the maas-region and maas-rack controllers become part of the platform instead of separate | 02:12 |
| pmatulis | stormmore, back up a bit. at a higher level, what are you trying to do? | 02:18 |
| stormmore | put the maas controllers on managed hosts probably in LXD containers on the admin model | 02:19 |
| stormmore | pmatulis I know the steps just wondering if there is a better way | 02:20 |
| pmatulis | stormmore, MAAS should already be set up, you then connect juju to MAAS | 02:21 |
| pmatulis | stormmore, or are you trying to install MAAS with juju? | 02:22 |
| stormmore | that is what I am thinking might be ideal... the end state would be not to have a dedicated machine for maas in the environment | 02:23 |
| pmatulis | stormmore, and how have you tried installing MAAS with juju? | 02:24 |
| stormmore | right now the plan is to bootstrap using a dedicated maas controller, then bootstrap juju, deploy maas-region and maas-rack charms, mitgrate the db and decon the machine | 02:24 |
| pmatulis | stormmore, what command will you use to install MAAS with juju? | 02:26 |
| stormmore | tbh haven't really tried too much since I am using the maas controller install direct from the ISO | 02:27 |
| pmatulis | stormmore, that's what i am getting at. i don't believe there is a maintained juju way to install MAAS | 02:28 |
| stormmore | there is a charm for maas-region, doesn't look official but it does mean to bootstrap an environment becomes a multistep process for now | 02:30 |
| pmatulis | well, i would advise to stay away from it | 02:32 |
| pmatulis | there is no obvious benefit to balance the risk and heartache | 02:33 |
| stormmore | I disagree since having the maas services spread in the cluster removes the need for dedicated hardware for something that is not necessarily used that much | 02:35 |
| stormmore | ideal I would move the maas-rack-controller components onto the switch hardware and put the maas-region-controller components on the same node as the juju-controller | 02:37 |
| rick_h | stormmore: so I think the way you can get around this a bit is to basically setup control nodes with manual lxd containers and get the components going, a juju controller, install maas, register those lxd containers into the maas, and then go from there | 02:38 |
| rick_h | stormmore: there's some thoughts longer term about being able to share a controller on the metal, the cloud put onto that metal, etc. So that you've got one control plane for several layers as long as they're on the same physical network | 02:39 |
| rick_h | stormmore: but it's not there atm | 02:39 |
| stormmore | rick_h: right now I am thinking of dedicating a bootstrap machine for maas services and as part of the overall environment bring up move all the services using juju deploy <charm> even if I have to write a charm for it ;-) then I can "reboot" the bootstrap system and add it too | 02:42 |
| stormmore | I want to get to the point that the region and rack controllers are in different spaces and thus remove a NAT rule on my router | 02:43 |
| rick_h | stormmore: do us a favor and write to the juju list on how the experiment goes. I'm always curious how folks are looking to put parts together. | 02:43 |
| stormmore | rick_h for sure :) I still like the idea of putting the rack controller on the switches but that is me just daydreaming and I know it | 02:44 |
| rick_h | well I think that's still the goal in life. A world of snap enabled switches and maas as a snap :) | 02:45 |
| rick_h | I think it'd be pretty cool to run a small home router with maas on the router myself | 02:45 |
| rick_h | need those ubuntu/snap devices to go forward | 02:45 |
| stormmore | yeah that would be kinda cool :) I am just not sure about storing the db on the switch/router | 02:46 |
| rick_h | yea, but at the same time how much data is in there really? | 02:47 |
| rick_h | $backups$ :P | 02:47 |
| stormmore | rick_h do you know if there is any thought being put into 'multi-region' maas or am I missing something | 02:47 |
| rick_h | I thought maas was multi-region already? | 02:48 |
| stormmore | it is but not in the same way aws is as far as juju is... either that or I am missing something in my configuration | 02:48 |
| stormmore | juju sees* | 02:48 |
| rick_h | https://bugs.launchpad.net/juju/+bug/1600061 is what got me thinking | 02:48 |
| mup | Bug #1600061: Expect multi-region MAAS clouds <maas-provider> <juju:Triaged> <https://launchpad.net/bugs/1600061> | 02:48 |
| rick_h | there was some work around this in the new add-clouds interactive bits in 2.1beta | 02:49 |
| stormmore | well it is on the backlog then :) | 02:49 |
| rick_h | but not sure if juju now supports fully that | 02:49 |
| stormmore | oh I can work around it for now... happy it is at least in the backlog | 02:50 |
| stormmore | oh and I agree for a home setup putting the db on the router makes sense, (still not sure i would want to run postgres on a router) but for a multi-dc environment with other postgres dbs, not so much | 02:56 |
| rmcadams | my switches are all cumulus | 03:33 |
| rmcadams | x86 | 03:33 |
| rmcadams | probably a way to put something on there, that's an interesting concept, but yah... it's interesting | 03:33 |
| rmcadams | I wanted it part of the environment too, not standalone | 03:33 |
| stormmore | I thought about cumulus, not quite ready to make that jump yet | 03:58 |
| stormmore | it just seems like even the smallest of the smallest server would still be overkill for the controllers (especially once you move postgres off) | 04:00 |
| stormmore | oh and the switch seemed logical since you could ship it basically preconfigured with pxe, tftp, etc. | 04:01 |
| stormmore | you could call me crazy but I do likely to daydream about the ideal in the modern age | 04:01 |
| rmcadams | I love cumulus quite honestly, its so simple... and with knowledge of linux and some ansible skills you never touch it | 04:09 |
| rmcadams | so bdx - I'm not sure that MAAS "Chassis" are going to fix the virsh issue | 04:12 |
| rmcadams | yah, so when I add a 'chassis' (virsh box) that has 5 compute nodes configured, none of them are added to the MAAS, in addition, if they boot and come up the virsh settings are still global :( | 04:19 |
| rmcadams | thanks for the try bdx | 04:19 |
| rmcadams | oh boy, scratch that bdx - it worked | 04:32 |
| rmcadams | wow | 04:32 |
| rmcadams | Well that does it, 6 Compute Nodes, 4 Infrastructure nodes and 4 Storage nodes through virsh with two hosts... thanks to bdx | 05:12 |
| kjackal | Good morning Juju world! | 07:46 |
| === frankban|afk is now known as frankban | ||
| === sparkieg` is now known as sparkiegeek | ||
| === jamespag` is now known as jamespage | ||
| === Prob is now known as hio | ||
| === scuttlemonkey is now known as scuttle|afk | ||
| === BlackDex_ is now known as BlackDex | ||
| arosales | kjackal: good morning | 15:39 |
| arosales | Just a reminder: There will be a Juju Show Hangout today @ 2pm USA Eastern time | 15:40 |
| lazyPower | arosales where do i buy tickets to the show? | 15:45 |
| arosales | lazyPower: here, it will only cost you code commits :-) | 15:49 |
| setuid | Any experts with numa/hugepages about, specific to customizing a charm to pin vms to node 0? | 16:25 |
| setuid | IOW, how to define in the charm, that both vms will be pinned to node 0, and not balanced across node 0 and 1 | 16:26 |
| === scuttle|afk is now known as scuttlemonkey | ||
| bdx | can I add users to my models on the juju beta hosted controller? | 18:26 |
| bdx | `$ juju users` shows "ERROR unknown object type "UserManager" (not implemented)" | 18:27 |
| bdx | is there something I'm missing here? | 18:27 |
| rick_h | bdx: I don't think you need to add the user since it's backed by SSO | 18:28 |
| rick_h | bdx: have you tried just granting an sso user email? | 18:28 |
| bdx | oooo | 18:28 |
| bdx | no | 18:28 |
| bdx | I haven't, I'll try that now | 18:28 |
| rick_h | bdx: maybe bac can confirm/deny | 18:28 |
| bdx | rick_h: you have to use the users launchpad email, not username? | 18:30 |
| rick_h | bdx: not sure on that one. 50/50 shot? | 18:31 |
| bdx | rick_h: http://paste.ubuntu.com/23823403/ | 18:33 |
| bdx | it must be email then | 18:33 |
| bdx | rick_h: users lp email worked | 18:36 |
| === dames is now known as thedac | ||
| bdx | still can't list users though ... http://paste.ubuntu.com/23823423/ | 18:36 |
| rick_h | bdx: if you show-model is that there? | 18:39 |
| bdx | rick_h: yeah ... and it says "users: {}" | 18:39 |
| rick_h | bdx: it should like users of the model in that output | 18:39 |
| rick_h | oh hmmm, well so much for that :/ | 18:39 |
| bdx | http://paste.ubuntu.com/23823432/ | 18:39 |
| bdx | even though I just successfully added a user via lp email | 18:40 |
| bdx | rick_h: ahhh, the user hasn't signed up for juju beta yet, or he just did like right now | 18:40 |
| bdx | do you think the user must be registered for juju beta in order for me to add them to my model? | 18:40 |
| rick_h | bdx: I don't think so? but I'm not sure. | 18:41 |
| rick_h | bdx: I'm reaching out to see if we can get someone deeper in that side of things to help us out here | 18:41 |
| bdx | if so, can I just give them my register command (as it seems like a generic address) so they can register now, and don't have to wait on the email response back from canonical | 18:42 |
| frankban | bdx: have you tried juju granting user@external? | 18:43 |
| frankban | bdx: like "juju grant simonbacquie@external admin prm-demo", assuming simonbacquie is the proper usso name | 18:44 |
| bdx | frankban: I ran this command, which seemed to succeed "juju grant users-launchpad-email@myemailserver.com admin common-infrastructure" | 18:44 |
| bdx | ahhh, <lp-username>@external | 18:45 |
| bdx | I'll try that | 18:45 |
| frankban | bdx: no, please try juju grant {usso-username}@external admin {model-name} | 18:45 |
| frankban | bdx: yeah | 18:45 |
| bdx | frankban: http://paste.ubuntu.com/23823475/ | 18:46 |
| bdx | here's `juju users --debug` -> http://paste.ubuntu.com/23823479/ | 18:46 |
| frankban | bdx: that's ok, possibly something we need to improve when showing models in jimm | 18:48 |
| frankban | mhilton: ^^^ | 18:48 |
| frankban | bdx: but now that user should be able to admin your model | 18:48 |
| bdx | frankban, ok, can I have that user run `juju register jimm.jujucharms.com` ? | 18:49 |
| frankban | bdx: yes | 18:49 |
| mhilton | bdx, frankban: I think that's a known limititation, but I'll make sure its on the bug list. | 18:50 |
| frankban | thanks mhilton | 18:51 |
| rick_h | jcastro: marcoceppi_ arosales tvansteenburgh mbruzek lazyPower and other folks the hangout url for the show is https://hangouts.google.com/hangouts/_/ytl/EVQjb5MECk3bIol40w_4rT0ibocCKyiqpk3QAkWjBEE=?eid=103184405956510785630&hl=en_US&authuser=0 | 18:52 |
| rick_h | and the youtube viewing link is http://youtu.be/Lsbo7f7yMxY | 18:52 |
| mbruzek | thanks rick_h | 18:52 |
| === frankban is now known as frankban|afk | ||
| arosales | rick_h: thanks | 18:57 |
| arosales | Getting ramped up for the Juju Show | 18:59 |
| mskalka | pardon my ignorance but what is the Juju Show? | 19:03 |
| rick_h | mskalka: http://youtu.be/Lsbo7f7yMxY check it out | 19:03 |
| bdx | mskalka: find out -> http://youtu.be/Lsbo7f7yMxY | 19:03 |
| mskalka | thanks! | 19:03 |
| sparkiegeek | woop woop, Juju Show time - missed the first few minutes | 19:07 |
| tvansteenburgh | https://github.com/juju/python-libjuju | 19:15 |
| tvansteenburgh | https://pythonhosted.org/juju/index.html | 19:16 |
| sparkiegeek | QUESTION: how will libjuju versioning work? Specifically will it release 1:1 with associated Juju versions? What about bugfixes? | 19:19 |
| arosales | sparkiegeek: per tvansteenburgh answer of loading the desired juju version be good to start a juju mail list thread and get folks opinion on it | 19:24 |
| sparkiegeek | arosales: sure. But the code generation that it uses can't be loaded from the API AFAIK | 19:25 |
| tvansteenburgh | correct | 19:26 |
| arosales | sparkiegeek: good to discuss that with tvansteenburgh | 19:26 |
| arosales | but perhaps on the list of pro/cons to get others input | 19:26 |
| arosales | for folks following along python-libjuju examples @ https://github.com/juju/python-libjuju/tree/master/examples | 19:29 |
| tvansteenburgh | sparkiegeek: what do you think of the idea i proposed? | 19:29 |
| tvansteenburgh | (for versioning) | 19:29 |
| sparkiegeek | tvansteenburgh: it's a nice idea - I'm just concerned about the generated code would work. You'd need N versions of the generated "blob"s for each Juju version you wanted to support | 19:30 |
| sparkiegeek | tvansteenburgh: I think a good change would be to instead split by facade - have separate generated blobs for each facade | 19:31 |
| sparkiegeek | tvansteenburgh: then negotiate with the API and do a negotiation on the facade version that libjuju supports and that it supports | 19:31 |
| sparkiegeek | tvansteenburgh: bigger font please | 19:32 |
| sparkiegeek | rick_h: LOL | 19:34 |
| bdx | tvansteenburgh: datadog/newrelic juju plugin using all watcher to report events back to your monitoring | 19:36 |
| bdx | chef/puppet already have these types of plugins .. all watcher would be perfect for for implementing the juju version of this | 19:38 |
| sparkiegeek | tvansteenburgh: arosales: FYI libjuju versioning thread started | 19:38 |
| tvansteenburgh | sparkiegeek: cool thanks | 19:39 |
| arosales | sparkiegeek: thanks | 19:43 |
| rick_h | sparkiegeek: hah, not waiting on causing trouble :P | 19:44 |
| bdx | tvansteenburgh: is there a better way for me to access the units of an application than what I'm doing here https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c#file-simple_juju_action-py-L37 | 19:45 |
| bdx | tvansteenburgh I am only finding examples where you can deploy the application, then get the units similar to https://github.com/juju/python-libjuju/blob/master/examples/action.py#L32 | 19:47 |
| tvansteenburgh | bdx: looking | 19:48 |
| sparkiegeek | app_web = model.units["app-web/2"] ? | 19:48 |
| tvansteenburgh | yes :) | 19:48 |
| tvansteenburgh | quick learner this guy | 19:48 |
| bdx | tvansteenburgh, sparkiegeek: ehhh, what if I don't know what units an application has? | 19:49 |
| sparkiegeek | and/or [unit for unit in model.applications["app-web"].units] | 19:49 |
| bdx | sparkiegeek: ahhh nice, thats what I was looking for thanks! | 19:49 |
| sparkiegeek | bdx: np! | 19:50 |
| CoderEurope | marcoceppi_: ping | 19:56 |
| marcoceppi_ | CoderEurope: o/ | 19:56 |
| CoderEurope | Cool beans - got the computer - ready to do Discourse in juju ? | 19:57 |
| CoderEurope | marcoceppi_: Can you jump on here for a second ? https://meet.schrodingersscat.com/LoyalOctopodesDiscussFinely | 19:58 |
| marcoceppi_ | CoderEurope: I'm 2 mins away from a vacation. Can we schedule an official chat time next week? | 19:58 |
| marcoceppi_ | CoderEurope: Like, this time Tuesday? | 19:59 |
| CoderEurope | Okay suppose so ... shame but I guess. | 19:59 |
| marcoceppi_ | CoderEurope: yeah, super sorry about that | 19:59 |
| CoderEurope | I shall put it into my ubuntu phone :D | 19:59 |
| marcoceppi_ | CoderEurope: sweet, I'll make sure it's in my calendar, if you grab me this time next week on Tuesday, you'll have my full undivided attention! | 20:00 |
| CoderEurope | cool beans | 20:00 |
| CoderEurope | have a good vacation :D | 20:00 |
| bdx | sparkiegeek, tvansteenburgh: much better now -> https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c | 20:03 |
| tvansteenburgh | bdx: for unit_name, unit in model.applications['app-web'].units.items(): | 20:05 |
| tvansteenburgh | that way you don't have to create the Unit object | 20:05 |
| bdx | tvansteenburgh: ooh, because the unit objects are already available via the units dict? | 20:08 |
| tvansteenburgh | yep | 20:08 |
| bdx | nice | 20:08 |
| bdx | awesome, thx | 20:08 |
| bdx | tvansteenburgh: this is what I've got now https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c | 20:13 |
| bdx | soo much cleaner ... wow .... thanks again | 20:14 |
| bdx | sparkiegeek: ^ | 20:14 |
| tvansteenburgh | bdx, one bug there | 20:14 |
| tvansteenburgh | "for unit_name, unit in" (line 47) | 20:15 |
| tvansteenburgh | otherwise looks good! | 20:15 |
| bdx | oooh, entirely, thanks | 20:15 |
| petevg | cory_fu: does the cwr-ci charm just fetch matrix from github? | 20:42 |
| cory_fu | petevg: Yes | 20:42 |
| petevg | cory_fu: cool. When you get a chance, would you look at the PR at https://github.com/juju-solutions/matrix/pull/69, so that I can confirm that it works in the charm, and push the charm side of the PR for review? | 20:43 |
| cory_fu | petevg: So, I understand the desire to avoid having to pass the output dir through BT, but on the other hand, we eventually will want to add crashdump support to BT (for picking up logs prior to doing an env reset), at which point it's going to need the output directory as well. And CWR already has the output directory passed in to it, so it seems like it wouldn't be much more of a change to add the arg pass-through to BT. | 20:50 |
| petevg | cory_fu: bundletester and matrix have a lot of conflicts in argument names, so it felt more foward facing to separate their arguments somehow. | 20:51 |
| petevg | cory_fu: another solution would be to do as tox does and have a delimiter that passes arguments after the delimiter to matrix. | 20:52 |
| cory_fu | petevg: I don't understand what you mean about conflicts in argument names? I'm not suggesting a special arg for matrix in BT. I'm saying, BT needs its own output dir option, and it should then be passed through to matrix as well. | 20:53 |
| cory_fu | And that BT output dir option would eventually be used to know where to put the crashdump output for the model that BT manages | 20:54 |
| cory_fu | *also be used | 20:54 |
| petevg | cory_fu: I understand that. I'm saying that, looking forward, we might actually want to pass multiple things through bundletester, to matrix, and maintaining a kind of manual translation table of arguments feels clunky. I'd rather have a way of talking around bundletester, through to matrix, than have to hard code translations inside of bundletester. | 20:55 |
| petevg | cory_fu: maybe it's just something we have to live with, given that we've decided to have bundletester drive matrix. | 20:57 |
| cory_fu | I can see that for things that are matrix specific, but I feel like the output dir is something that makes sense to pass through, since all three components are going to put things there, and we shouldn't have to pass it in three different ways | 20:57 |
| cory_fu | petevg: At any rate, this approach is easier and doesn't require touching BT and CWR, so we can go with it for now and consider refactoring when we have to add the output dir option to BT anyway | 21:01 |
| petevg | cory_fu: ty | 21:04 |
| bdx | frankban, rick_h: concerning credentials and the hosted controller .... | 21:05 |
| cory_fu | petevg: Merged | 21:05 |
| petevg | awesome. thx | 21:05 |
| bdx | I can add a model with a credential on my own controller and deploy ubuntu -> http://paste.ubuntu.com/23824224/ | 21:07 |
| bdx | but when I try the same thing on the hosted controller deploying anything fails | 21:07 |
| bdx | ahhh shoot ... nix that | 21:08 |
| bdx | its working | 21:08 |
| petevg | cory_fu: unfortunately, that's card isn't done done :-p (we actually do some manipulation of the output dir somewhere in either the guts of cwr or jenkins, and I'm testing a change that puts the matrix.tar.gz into a place where jenkins can actually surface it; PR coming.) | 21:13 |
| cory_fu | Ah, sorry. :p | 21:13 |
| petevg | No worries. I just noticed it myself :-/ | 21:13 |
| gQuigs | I can specify zesty as the series in a bundle, but I haven't been able to figure out how to force it to override the charms? | 21:53 |
| gQuigs | juju deploy bundlefile-reduced-zesty.yaml --series zesty --force | 21:53 |
| gQuigs | ERROR Flags provided but not supported when deploying a bundle: --force, --series. | 21:53 |
| lazyPower | gQuigs right, you can set the series in the bundle, per charm or as a whole for the bundle. | 21:54 |
| lazyPower | those --force and --series flags are intended for charm deployment, eg: juju deploy ./etcd --series=zesty --force | 21:55 |
| lazyPower | as etcd only supports xenial in its metadata.yaml, those flags would tell juju to ignore those warns, and force deploy on zesty. | 21:55 |
| gQuigs | I'm trying to override about 10 charms (openstack) to try them on zesty | 21:56 |
| gQuigs | but I want to use a bundle for them.. | 21:56 |
| lazyPower | gQuigs - i dont think theres an easy way to do that without using local charms with the series modified. rick_h might prove me wrong though, as he's kind of the bundle wizard of juju. he's clued me in to some neat features I didn't know about | 21:57 |
| mskalka | lazypower, even if you edited the bundle.yaml would juju throw errors for the charms that didn't support zesty? | 21:58 |
| mskalka | deploying from local that is | 21:58 |
| lazyPower | only if the metadata.yaml specifies series support | 21:58 |
| gQuigs | lazyPower: right, I'll fall back to editing each charm in turn | 21:58 |
| lazyPower | if its missing the series key, it should "just work" when you tell it in the bundle, as the bundle becomes the source of truth then | 21:58 |
| mskalka | so you'd have to ostensibly edit each metadata.yaml and change/remove the series and tell the bundle to deploy all local charms to completely avoid conflict? | 22:00 |
| rick_h | gQuigs: lazyPower if the charms don't devalre they support zesty it's not something the bundle can force sorry. | 22:00 |
| lazyPower | rick_h - if its alocal path charm? | 22:00 |
| lazyPower | oh you're answering the first question. right | 22:00 |
| rick_h | gQuigs: lazyPower but the cahrm says it doesn't support it in the metadata? | 22:00 |
| gQuigs | rick_h: thanks for the answer :) | 22:00 |
| rick_h | I'm surprised they don't have something in testing and the like though. | 22:01 |
| lazyPower | rick_h how does a charm say i dont support somthing? I thought if its listed it supports it, if it has no series key in metadata, you can tell it whatever. | 22:01 |
| rick_h | beisner: do you all have anything for zesty in dev? | 22:01 |
| rick_h | lazyPower: you can, but the bundle does take that I don't believe. | 22:01 |
| lazyPower | hmm | 22:01 |
| rick_h | lazyPower: as you noted you have to manually force it with the --series flag | 22:01 |
| rick_h | It's like a --force | 22:02 |
| lazyPower | ok, i was kind of goign from hazy info anyway. i've done some weird things with local charms/bundles | 22:02 |
| gQuigs | lazyPower: thanks, I forgot about local branching and juju-deployer makes that trivial... | 22:02 |
| lazyPower | gQuigs np, we aim to have you not need to do that, but corner cases and all that | 22:02 |
| beisner | hi rick_h - not much yet. we plan to enable the zesty series in the charms after the 17.02 openstack charms stable release. | 22:03 |
| rick_h | beisner: ah ok | 22:03 |
| rick_h | beisner: any trick youve thought of or used to try something on a new series before the charms are updated? | 22:03 |
| beisner | rick_h, if one uses juju-deployer, and the git branches instead of cs: values, one can deploy any charm to any series. so, a friend said ;-) | 22:04 |
| beisner | rick_h, aiui, there is a --force with juju 2 native deploy, though, right? | 22:04 |
| rick_h | Gotcha | 22:04 |
| gQuigs | beisner: the --force doesn't work with bundles | 22:05 |
| rick_h | beisner: yes but only on deploy and not.on bundles | 22:05 |
| beisner | gQuigs, rick_h - ack, that would be for individual charm deploys wouldn't it? | 22:05 |
| gQuigs | would supporting --force series to bundles be a welcome feature to add? (/me wouldn't mind giving it a shot) | 22:06 |
| beisner | gQuigs, rick_h - the reason we haven't yet enabled zesty metadata in the charms is because the openstack charms will release a stable update from master in Feb, in alignment with openstack upstream's new release cadence. but that will be ~2 months ahead of zesty's release and we don't want that series declared in stable charms while zesty is still in dev on the Ubuntu side. | 22:06 |
| beisner | gQuigs, seems like a valid --force use case ;-) | 22:07 |
| rick_h | gQuigs: the reason it didn't get added as it's very special. What charms do you want to use it on? What if one of the 10 is windows...Or you know won't work. It's just a very narrow use case feature. | 22:08 |
| rick_h | The bundle has to be perfect for it to be useful | 22:08 |
| rick_h | gQuigs: I think having the bundle respect what's entered in the series for the charm would be better. | 22:09 |
| rick_h | E.G. If the series in the application section of the bundle says zesty, use that even if the charm says it's only trusty. | 22:09 |
| gQuigs | rick_h: hmm.. will take a look at the code around that | 22:10 |
| gQuigs | thanks all! | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!