18:00:23 #startmeeting trove 18:00:24 Meeting started Wed Jul 2 18:00:23 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:27 The meeting name has been set to 'trove' 18:00:34 o/ 18:00:35 ./ 18:00:36 o/ 18:00:38 o/ 18:00:38 o/ 18:00:44 Agenda at: 18:00:46 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:00:55 |o| 18:01:01 o/ 18:01:09 o/ 18:01:11 o/ 18:01:16 o/ 18:01:17 previous meeting summary at: 18:01:20 #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-06-25-18.00.html 18:01:31 #topic Agenda Items 18:01:44 o/ 18:01:51 One agenda item from the last meeting 18:02:13 Action Item* 18:02:19 SlickNik to update the dev-docs with build / test process updates. 18:03:26 I've started doing this, but still am in the process of trying to iron out devstack / redstack integration. 18:03:54 Will propose a patch to the docs this week once that's a bit more final. 18:04:08 So I'm going to re-action this item again. 18:04:16 #action SlickNik to update the dev-docs with build / test process updates. 18:04:37 o/ 18:04:43 o/ 18:04:53 #topic Per datastore volume support 18:04:57 o/ 18:05:00 #link https://blueprints.launchpad.net/trove/+spec/per-datastore-volume-support 18:05:24 This agenda item has a two fold purpose. As Rueben and me started putting together the proposal for volume support for datastores, there were two schools of thought which we came across. 18:05:36 One believing it belonged to capabilites and other it belonged to the datastore config groups. 18:05:36 I think it would be good precedent, for future features which are considered for capabilities, to discuss in the community whether this feature belongs to configs or to capabilities. 18:05:36 And if it does belong to the later, we might want to discuss how to introduce new capabilities in the trove code base. 18:05:38 The blueprint proposed here is adding volume support on a datastore basis. Currently trove_volume_support config value enables/disables support for volumes for all datastores in trove. 18:05:47 iccha: how you type so fast? 18:06:07 Hey these meetings are supposed to be improv only 18:06:08 kevinconway: i have super powers 18:06:08 cut and paste 18:06:37 o/ 18:06:51 one question i have is.. what's the status of capabilities? 18:06:57 seems to me that volume support is not a capability 18:07:03 it is a choose 18:07:06 choice 18:07:22 vipul: the api and migration is merged, the management calls to add capabilites are in review 18:07:24 I vote it gets added to the datastore config groups first, via a tiny helper method in the base Instance class called "supports_volumes" 18:07:37 Then if capabilities is ready adding it to check capabilities should be no problem 18:07:38 amrith how u knew its cut and paste :) 18:07:42 vipul: we are working on some of the front end apis for ti 18:07:52 o/ 18:08:04 i agree with robertmyers. this is not a capability of a datastore. 18:08:07 yeah i could see it as a choice for the user because maybe they dont want that setup and they want to use ephemeral disk instead of the volume 18:08:11 robertmyers: I think that just might be a nomenclature issues. volume-support was the initial reason that drove capabilities IIRC. Horizon needed some way of knowing if the choice was enabled / disabled. 18:08:27 SlickNik: false 18:08:33 SlickNik, ++ 18:08:42 if volume support isn't a capability then i would say we completely missed the boat on capabilities 18:08:43 same for me, seems like capabilities task 18:08:58 SlickNik: There's a big issue I'm observing here, which is that while volume-support drove capabilities, now I have people working on adding the ability to toggle volume support whod on't understand how it will take advantage of capabilities 18:09:00 capabilities were first suggested as a way to disable the users call in datastore without users… not to bring up users again 18:09:06 SlickNik +1 - having this as a capability is needed for Horizon support 18:09:10 yea it's completly fair to tie volume_support and other flags like this to a datastore.. 18:09:15 abramley: How so? 18:09:56 Is it just so you can query to see if volumes are or are not supported on a given datastore? 18:10:01 so then volumes needs to be a hard coded config setting 18:10:10 it if is needed for horizon 18:10:18 #link https://blueprints.launchpad.net/trove/+spec/capabilities 18:10:21 grapex - since that is a common way for horizon to obtain this information - rather than some other mechanism 18:10:27 otherwise you have to enter it in the db every time 18:10:37 abramley: People deploying horizon will know if it is supported or not 18:10:40 hp doesn't run with volume_support, yet Horizon doesn't know better and will show a drop-down for volume_size 18:10:46 If we want to enable / disable UI functionality per datastore - then capabilities should do that 18:10:58 If this is about the general use case for open stack trove then I say everything should be supported for all of the things 18:10:59 abramley, ++ 18:11:23 vipul: can't the hp deployment of Horizon just disable that? 18:11:33 abramley: but cant it be driven by a config option? 18:11:38 Trove allows you to, so Horizon should do the same 18:11:55 right now capabilities is a db object not unlike metadata, yes? 18:11:57 sure, but I think we're getting to a point where there actually might be some datastores that we'd like to back with volumes, whereas others we wouldn't 18:12:07 robertmyers - how does that config option get to horizon? we duplicate it in various configuration files ? 18:12:15 and horizon doesnt need to know about trove configs 18:12:15 kevinconway, yes 18:12:25 abramley: provide an api to read it 18:12:44 I just don't think it need to be in the DB 18:12:44 so let's say my datastore doesn't support users or databases, how do i use capabilities to disable those features? 18:12:46 robertmyers - we have an api to read it already if it is a capability 18:13:20 but it *has* to be in everyones setup 18:13:23 abramley: So will Horizon make this call for each datastore to know if it does or does not support volumes everytime? 18:13:28 kevinconway: i think how do we use capabilities or rather introduce capabilities into code base is the next question 18:13:29 otherwise the check fails 18:13:37 kevinconway, with admin rights you would disable users API for given datastore, format of disabling/enabling hadn't been discussed yet 18:13:59 what if you typo adding the capability into your db 18:14:09 denis_makogon: i think kevinconway is refering to first step of adding a given cpaability to the table 18:14:14 ok so if nothing is decided on how to use capabilities is it even possible to discuss it as a choice for this BP? 18:14:15 robertmyers +1 18:14:35 Sounds like what is needed here is an API to see what are acceptable arguments to the create call 18:14:39 kevinconway, ++ 18:14:51 so folks who were there when capabilities was first discussed did we have a plan of action for how new capabilities would be introduced into code base/database? 18:14:55 Even if we have capabilities all that is going to be is a bag of random settings for each datastore 18:14:55 grapex, that's capabilities for 18:15:07 iccha: we originally planned to augment the CONFIG object 18:15:11 I'm confused. Would someone please state the question we're debating? I think there are at least three and the conversation is confusing ;) 18:15:14 Horizon will have to have in-depth knowledge of Trove to know which value to look for in the bag to drive its behavior 18:15:41 iccha: IIRC we discussed this at the mid-cycle, and we planned to extend the CONF object. 18:15:44 amrith: iccha is trying to fix the code so it can support volumes or not support them on a per-datastore basis 18:15:55 i thought capabilities were for optional configs such as volume support etc... or are we going to use it to enable/disable features/api such as users, db? 18:16:05 amrith: And trying to see if she has to use the brand new capability feature or can use the conf file 18:16:17 amrith: thats a good point. (1) what is a capability? is volume support per datastore a capability (2) how are new capabilities introduced in trove 18:16:18 config file +1 18:16:28 +1 to capabilites instead of conf 18:16:35 robertmyers: +1 18:16:47 SlickNik: kevinconway and this config object would be loaded from the database? 18:16:49 What does using the capabilities instead of the conf buy us other than new fun ways to screw up a deployment? 18:16:59 If you read the capabilities BP.. it's littered with volume_support as the prime example 18:17:01 grapex, iccha thanks. I thought we discussed this in Atlanta (or maybe Austin) and decided we would use capabilities 18:17:03 if we add it to capabilities, we need a set of hard coded values 18:17:08 iccha: it would have a special object attached to it that did db lookups. like CFG.capabilities.some_stuff 18:17:17 vipul, +! 18:17:26 it can't all be driven by db entries 18:17:26 so I'm wondering whether there is a forcing function driving the reconsideration. 18:17:29 kevinconway: SlickNik was it discussed how it would be added to db in first place to ensure consistency? 18:17:57 robertmyers, why? 18:18:11 iccha: There was some talk of seeding it from the values in the config files. 18:18:13 denis_makogon: so you know which values are accepable 18:18:24 capabilities are meant to describe a feature that a _datastore_ can or cannot support. volumes are a part of the nova instance that gets provisioned 18:18:26 denis_makogon: robertmyers: typos in the capability name 18:18:40 SlickNik: So the capabilities for say volume support, if it wasn't in the db, would come from the config file? 18:18:41 how would yo know to set volumes vs volume_support 18:18:54 ex: myDataStoreX doesn't support replication. that is a capability 18:19:05 kevinconway, capabilities are not only about what datastore can or not 18:19:14 denis_makogon: that is the definition of capability 18:19:19 kevinconway, it's all about resource utilization 18:19:26 grapex: It would depend on the implementation, but a fallback approach like that sounds reasonable. 18:19:58 I know somebody talked about using capabilities for volume support ages ago, but here is the problem I want to bring up: it isn't clear how it will be used or if using it will make the feature of disabling volumes on a per-datastore basis any better. So far it seems as though using capabilities will make this more confusing. 18:20:07 fwiw, since caching is included in the charter of trove, it does make sense to some degree that volume-support is considered a capability for datastores that have no persistence to speak of 18:20:15 i think we should have the BP on capabilities being updated 18:20:19 SlickNik: if the db is loaded from config values, whats the point then 18:20:23 SlickNik: grapex: we could no longer introduce new capabilities via api call correct? Or is there an ask for create via API call? 18:20:23 kevinconway, when caps. came they were only about datastores but for now, it's more that datastores specific things 18:20:25 right now i dont know what a capability is. 18:20:26 For example, there is already code to turn on or off setting a root password on a per-datastore basis which uses the config file that is really simple 18:21:13 kevinconway: iccha, IIRC one of the points mentioned was that you could turn on / off capabilities programmatically 18:21:14 rueben: We could add capabilities via an API call IIRC but the issue is we'd be adding capabilities with random strings for names, but in the code we'd be using non-dynamic string literals. 18:21:20 In my opinion, if there is a requirement to expose wehther something is enable/disabled via an API, it should be a capability -- if not -- then a conf value would suffice 18:21:27 as far as i understood when it was pitched, capabilities was meant to support the ability to toggle on and off features for a datastore, whether that be because (1) the datastore intrinsically can't support it, or (2) the cloud administrator chooses not to support it 18:21:36 denis_makogon: kevinconway: "Configuration options, such as whether volume support is enabled..." It's the first line of the BP from 09/2013, doesn't seem like a recent idea. 18:21:51 vipul: Maybe what we need is an API that just shows a JSON object with a list of things that is and is not supported for a datastore 18:21:58 SlickNik: yes. example: i deploy datastoreX at my company. I want to enable users but disable backups. 18:22:00 for config options that are datastore specific like .. mount_point for example.. wouldn't be a capability.. it's a backend concern 18:22:31 vipul: I think what you and Reach though want is an API that is read only and returns what a user (or control panel) can do 18:23:17 grapex: yep, exactly -- and that was the idea behind capabilities.. at least that's how i understood it 18:23:31 vipul, grapex + 18:23:40 vipul: Maybe we should refocus capabilities on just that then 18:23:52 Also, Freudian slip, Reach==Horizon ;) 18:23:52 kevinconway: in its original incarnation this was about the capabilities of a "trove deployment", not necessarily of a particular "datastore". 18:23:52 so i think grapex s question is why cant we return response to the api call based on config values vs db vipul 18:24:10 iccha: Or reinvision capabilities 18:24:22 as something that just answers the question "what can I do for this particular datastore" 18:24:22 or both 18:24:30 vipul: THere is still a difference between datastore-specific features such as backup, users, DB and trove-specific like volume_support... are they all capabilities? 18:24:33 iccha: Yea i don't care where it's stored i suppose 18:24:34 check db then config 18:24:39 i'd suggest to reinvision capabilities first, then move on with other things 18:24:55 wouldn't it be odd that we introduce a mgmt api to set a conf file? 18:25:07 hence the drive to have capabilities store the matrix in a table 18:25:09 denis_makogon: Yes. And since using capabilities does not seem to be making the volume work any easier I say for now we go forward and use the config file 18:25:13 esmute, as for me, caps. are not only things about what datastore can or not 18:25:20 amcrn: you'd tuse it to set the db 18:25:46 esmute: I would think so.. APIs that are supported / not supported would also need to be things that need to be exposed via an API 18:25:48 if we're using the db, then i'm not understand why capabilities makes understanding volume-support more difficult 18:26:06 denis_makogon: should we call it marshmellow instead? that way the word doesn't confuse us? 18:26:07 amcrn: can you need to know to set that exact string 18:26:20 s/can/because/ 18:26:31 i know we have beaten this horse more than we would like to.. But from what i am getting from this conversation, the following is not a capability 18:26:33 #link https://blueprints.launchpad.net/trove/+spec/cinder-volume-type 18:26:57 amcrn: Yeah. I am not hearing great reasons why we need to set this stuff in the database except that we had a blueprint to maybe do that months ago 18:27:04 the capabilities spec supports a capability default, then a datastore-by-datastore-version ability to override the default, i'm missing how this doesn't solve the problem? 18:27:06 esmute: I would agree -- that's a backend concern that doesn't need to be exposed 18:27:30 i agree with grapex 18:27:44 seems like we are chasing our long lost ghost 18:27:54 Check out this code to figure out if we should return a root password on create: https://github.com/openstack/trove/blob/master/trove/instance/models.py#L593 18:27:56 It isn't perfect 18:27:59 but it's pretty simple 18:28:05 I saw that code and wanted to start crying 18:28:32 We need the same thing for volumes, and I feel like the talk of capabilities is getting in the way of finishing it 18:28:39 that is how it should be 18:28:59 and it *could* be driven by a db under the hood 18:28:59 So what if iccha did something similar to get_root_on_create, and then if capabilities becomes something we all love we can easily change that one method? 18:29:00 can we vote it? 18:29:03 it if must 18:29:09 yeah thats why i said, just because we thought so is not good enough. any feature which is considered for a capability should be analyzed to see if it is sufficient to be config value 18:29:11 makes it easier from an operations perspective as well; because you likely already have auditing on conf drift 18:29:13 That way the volume work is not dependent on also fixing capabilities for its first use case 18:29:34 it doesn't solve the problem of someone wanting to know whether it's a supported operation prior to actually invoking the operation 18:29:40 did we even have datastore configs when we talked about capabilities? 18:29:43 vipul: good point 18:29:48 to enable support for a feature its highly likely a deployment is needed when config can be changed amcrn 18:30:04 vipul: You're right. In my opinion we should make a new API call for that or return that info in the datastore version view call 18:30:31 grapex: so would capabilities morph into a read-only view call, with the values being set via confs? 18:30:38 An API that returns a matrix? 18:30:42 vipul: yes thats right. and it could be added to the response irrespective of where it is stored 18:30:53 So it seems to me that we have different types of "capabilitles" we're talking about here: 18:30:53 1. Don't care about reading through the API : This should be a backend concern, not capability 18:30:53 2. Want to read/discover through the API, but likely read-only: Capability that can be backed by a config entry (eg. volume-support) 18:30:53 3. We want to read/write through the API: Capability backed by entry in db (reasonable to fall back to a conf entry if not defined). 18:31:03 amcrn: I'd be ok with that 18:31:21 thanks SlickNik i think thta's a good summary 18:31:29 vipul SlickNik: Agreed 18:31:43 SlickNik: thanks 18:32:03 well summarized 18:32:03 I'm goof with #2 18:32:05 *good 18:32:10 Should we vote? 18:32:15 grapex: you'd need a list of conf parameters that are "eligible" to be returned in the view call, but other than that, it should work. 18:32:27 otherwise you'd return a bunch of junk, unless they're under a special subheader 18:32:35 amcrn: yea some way to change visibility of conf options 18:32:41 I do want to point out though that I think whatever happens, I would like to see the ability to flip volumes on and off go on independent of #2 18:32:55 i think the DB would help solve that.. with a conf file.. might get wierd 18:33:05 #2 makes sense 18:33:12 2 +2 18:33:19 #2 ++ 18:33:27 Isnt #2 solved with docs? 18:33:34 I think in the future if we need new things, and also have an idea for over-arching features to give us those things, we should probably wait until we have one use case implemented first and then make that the first thing we refactor as we implement the new helper feature 18:33:52 grapex: we had several use cases. API features being disabled if not supported 18:33:56 yeah we agree upon #2, but that doesnt define how we want to implement it 18:33:57 i dont understand the need of an API to tell you what features you can or cant use 18:34:02 #3 is good too 18:34:03 esmute: It could be, but I think making a read only API call is easy enough I'll side with vipul on it. 18:34:12 so I'm on 2 to 3 18:34:15 The problem then esmute is in cases like Horizon they have to duplicate the settings 18:34:51 what if we did have a standardized way to add to the capabilities table the capability name entry would that address some of the concerns? 18:34:53 +1 to grapex, and it will only get worse once flavors-per-datastore gets implemented, etc. 18:34:57 i assumed that we were talking about supporting all of 1,2 & 3 - and we should adjust the capabilities feature to accomodate 18:35:00 esmute: the reason it needs to be an API is so things like Horizon can render the screen appropriately based on whether something is enabled 18:35:04 ahh ok.. so this is more to help integrate better with other other openstack projects 18:36:26 SlickNik: if we did have a standardized way to add capabilities to the table, would that help merge #2 and #3? 18:36:30 so if we go with #2, anyone have ideas on how something would be made visible ? 18:36:31 dougshelley66: Yes, that's what I originally meant it as. Not as separate options, but as a whole. 18:36:58 even #3 makes sense for admin priviledge(role) 18:37:02 i'm confused by numbers... 18:37:26 dougshelley66: Although, I'm good with approaching this incrementally if that would make things easier. 18:37:32 Okay time check. 18:37:35 vipul: might have to be explicitly added to datstore show call 18:38:17 rueben: Is there a public way to view capabilities now (i.e. not the mgmt api?) 18:38:30 no 18:38:38 SlickNik: how about if we did had a short term solution of doing it only via config, and work on defining how it needs to be added to the table and displayed etc 18:38:54 yes we are working on capabilities list now 18:39:05 rueben: In that case we should be open to the idea of making a new REST call 18:39:17 iccha i assume there is some reason we need this volume support so quickly? 18:39:20 this is likely divisive, but if the immediate concern is "hey, we have datastore and we really need to change the default on/off behavior of volume-support", why can't we just permit a quick hack via CONF.volume_support_exclusions, unblock some folks, and deprecate that once capabilities lands. 18:39:24 Why not just make this a call to the datastore version view? 18:39:32 i'm with dougshelley66, i don't see why this is so urgent 18:39:37 amcrn: +100000000000 18:39:47 That's what I'd like to get buy in for 18:40:23 amcrn: what if we added it to config groups, (similar to volume_support_Exclusions) so it can be in future default for #3 18:40:24 or, we just make capibilties optionally read the config file for the value 18:40:24 I feel like we are blocking real things we have 100% known and understood use cases for so we can make use of this thing that no one here seems to fully understand that isn't 100% finished from an API perspective 18:40:52 iccha: I like that idea (I believe robertmyers alluded to it earlier as well). 18:41:05 iccha: because there's an agreement that configuration-groups should only continue to mirror true configuration-file parameters, not higher level constructs 18:41:32 otherwise it morphs into "conf file parameters, and other configuration-like options that aren't really set in a file, but cause other side-effects" 18:41:39 amcrn: i meant [mysql] [redis] config group in the conf file 18:41:47 amcrn: not the configuration groups defined by trove 18:41:51 ah, my bad ;) 18:42:09 iccha: +1 18:42:15 i'm ok with iccha's proposal 18:42:25 what's the proposal? 18:42:32 add it to config_groups? 18:42:54 yes amrith, thats the first step while we made a decision on capabilities 18:43:20 is dougshelley66 also changing the implementation so it reads from the config group? (so we actually ahve a way of exposing the capability)? 18:43:24 may I suggest we set this topic gingerly aside and ask the question about the "decision on capabilities" 18:43:46 is there some "decision" that needs to be made? 18:43:47 amrith: the proposal is to add it to the config file in the appropriate section. If a value for the capability is not defined, we'll fallback to looking in the config file. 18:44:17 SlickNik, that strikes me as saying that we've embraced the fact that this is a capability 18:44:26 amrith: +1 18:44:27 vipul given this discussion I think we need to update the spec to hopefully get everyone on the same page 18:44:32 and the way capabilities should work is that if something isn't a capability, IT should go look in a config file 18:44:43 SlickNik: amrith also i think its a separate cnversation to decide how we introduce a capability so it has contant name across deployers because the code is going to be looking for it 18:44:44 amrith: +1 18:44:59 Can someone update the BP to reflect that has been decided today? 18:45:01 #link https://blueprints.launchpad.net/trove/+spec/capabilities 18:45:17 ahh dougshelley66 you beat me to it :P 18:45:20 esmute: was anything decided today? 18:45:23 esmute: We haven't decided anything yet. 18:45:33 OK, I have a proposal 18:45:47 SlickNik, why not update to DB but config file at runtime ? 18:45:50 SlickNik, maybe we should table iccha's request till the capabilities BP is updated 18:46:00 and then discuss the implementation of iccha's proposal. 18:46:03 SlickNik: Can we have a vote to not hold the volumes work hostage until we finish capabilities? 18:46:08 kevinconway: Im as confused as you are... I was hoping the BP will shed some clarity into capabilities :P 18:46:22 unless someone feels there is an URGENT desire to get volume support implemented right away, post haste, stat ... 18:46:36 amrith: I do. 18:46:43 amrith: me too 18:46:48 Also I think we should drive capabilities based on the feature it will support 18:46:53 in past i was asked to "fork" when in haste :) 18:47:07 grapex: the only qualm i have with this is we know the right approach is capabilities.. but we're ok with implementing this as a hack 18:47:09 amrith: we do not want to be holding up features unless really necessary which i do not feel is needed in this case 18:47:15 vipul: I disagree 18:47:21 i disagree this is a hack 18:47:24 there is not even an mgmt API for capabilities 18:47:33 Also I wouldn't call this code a hack: https://github.com/openstack/trove/blob/master/trove/instance/models.py#L593 18:47:36 sounds like dougshelley66 is working on it and it's only a matter of time 18:47:49 vipul also rueben, i believe 18:47:54 ok 18:48:02 so folks, I get it that some want to move forward with this. I'm wondering what the driving factor is. maybe if you share we can all get behind it? 18:48:25 amrith: Some datastores don't need volumes? 18:48:50 so what is getting held up grapex? 18:48:54 dougshelley66: https://review.openstack.org/#/c/104011/ 18:48:56 vipul: So you're saying: let's wait and not add these features until capabilities is 100% finished 18:49:03 dougshelley66: that's the current patch 18:49:05 because at the midcycle capabilities was discussed as something that was nearly done 18:49:19 Okay, two more minutes. I want to allow some time for open discussion, and then this conversation can continue in the trove channel. 18:49:22 rueben, correct. which is a mgmt api for capabilities, right? 18:49:24 amrith: we want to offer two db's one with volumes and one without in the same trove instance 18:49:32 but now it's July and we still are seeing rough spots. I don't get why iccha can't just add a first pass of the work to make volumes togglable 18:49:44 vipul: amrith why cant we do iterative development in the open 18:49:47 grapex: +! 18:49:47 grapex: No, i'm just saying let's get agreement on how capabilities will be implemented.. and once we have that.. you can move forward with adding it ot the conf (if we agree that capabilites will loko at conf).. your change should fit right in 18:49:51 dougshelley66: trove management commands for adding/removing capabilities and their overrides 18:50:05 vipul, +1 18:50:10 vipul: I think that will be easier once we have the use cases 18:50:14 dougshelley66: cli commands 18:50:17 vipul: if we're talking about how to implement capabilities, are we also defining what a capability is? 18:50:28 if the concern here is that if we implement volume togglability right now, changing it later will be impossible, I disagree 18:50:37 kevinconway: i think we went a long way towards doing that today 18:50:56 vipul: at the expense that we have people who have other work they need to get done who are now blocked 18:51:08 dougshelley66: does also include the underlying logic to do the add/removes 18:51:17 i could not find any documentation on how we envisioned capabilities to be used, i wish it had been a part of the capabilties bp 18:51:21 We shouldn't force independent tasks to be blocked to encourage debate on a feature that I honestly don't see the need for yet. 18:51:40 iccha: users! 18:52:04 grapex: Yea I get that.. so let's figure out how we plan to implement capabilities.. since this is an option that we want to expose 18:52:05 If we do that we're only getting discussion because we're causing people frustration. Maybe the end result is in some small way better, but I think we'd be happier as a community and a project if we were more flexible 18:52:05 kevinconway: i did not find any place which explained how it would be used for users, how would a capability be added etc 18:52:19 grapex: if we agree that looking at a conf file is a good fallback.. then just add it to the conf file.. done 18:52:19 Okay, guys. Let's move on to open items, let's circle back to this after the meeting. 18:52:29 the fix will fit right in, once capabilities land 18:52:32 #topic Open Discussion 18:52:35 vipul: Ok, +1 18:52:35 sounds good 18:52:37 I think we agree 18:52:46 i have one 18:52:49 i have 2 things 18:52:52 go denis_makogon 18:52:54 thanks 18:53:23 not so long ago oslo.db and oslo.i18n were released, and some of the OS services are already using them 18:53:46 at last oslo meeting was a talk about Trove and those libs 18:54:08 denis_makogon, Yogesh : lets have a talk on vertica datastore patchsets 18:54:09 do we have certain plans to move to oslo.i18n and oslo.db in Juno-2/3 18:54:20 SnowDust, after meeting 18:54:52 denis_makogon, is there some feature/aspect that we need? 18:54:57 denis_makogon: sounds like a large port.. 18:54:58 denis_makogon: Is there a reason for the move? 18:55:28 amrith, no features, it's a migration from oslo-incubator code to specific released libs 18:55:37 it was my understanding that the oslo guidelines were that we should not just sync their stuff unless there was a specific benefit provided. 18:55:48 SlickNik, code is being deprecated and deleted from oslo 18:56:19 denis_makogon, are you saying something will stop working? 18:56:19 denis_makogon: akaik, the only code being deprecated and removed this cycle is the rpc code. 18:56:29 And we are planning to move to oslo.messaging. 18:56:31 SlickNik: +1 18:56:40 other reason is to up to date, but seems that Trove already uses some legacy/dropped code from oslo 18:56:49 Also oslo has a policy of 1 cycle heads up before deprecating / removal. 18:57:10 So if they deprecated something this cycle, they won't remove it until the next one. 18:57:26 cp16net, had two things. I'd say we don't do this unless there is a strong driver for the change. it is a large port. 18:57:27 ok 18:57:30 #action SlickNik update jenkins: please remove JENKINS_HOME/scm-sync-configuration.*.log files 18:57:33 :) 18:57:41 cp16net: will do, thanks! :) 18:58:07 cp16net: go for it. 2 mins 18:58:19 and FYI i created a job that should test multiple patches for a blueprint 18:58:30 i have not seen it pass yet but it looks like it should work 18:58:45 #info https://rdjenkins.dyndns.org/job/multi-patch-test 18:58:54 ok thats it 18:59:01 cp16net: nice work! 18:59:14 cp16net: will take a look at it. 18:59:19 but still rdjenkins =) 18:59:33 anything else? 18:59:53 #endmeeting trove