18:00:23 <SlickNik> #startmeeting trove
18:00:24 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:27 <openstack> The meeting name has been set to 'trove'
18:00:34 <robertmyers> o/
18:00:35 <amrith> ./
18:00:36 <iccha> o/
18:00:38 <grapex> o/
18:00:38 <annashen_> o/
18:00:44 <SlickNik> Agenda at:
18:00:46 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:00:55 <cp16net> |o|
18:01:01 <esp> o/
18:01:09 <kevinconway> o/
18:01:11 <schang> o/
18:01:16 <dougshelley66> o/
18:01:17 <SlickNik> previous meeting summary at:
18:01:20 <SlickNik> #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-06-25-18.00.html
18:01:31 <SlickNik> #topic Agenda Items
18:01:44 <vipul> o/
18:01:51 <SlickNik> One agenda item from the last meeting
18:02:13 <SlickNik> Action Item*
18:02:19 <SlickNik> SlickNik to update the dev-docs with build / test process updates.
18:03:26 <SlickNik> I've started doing this, but still am in the process of trying to iron out devstack / redstack integration.
18:03:54 <SlickNik> Will propose a patch to the docs this week once that's a bit more final.
18:04:08 <SlickNik> So I'm going to re-action this item again.
18:04:16 <SlickNik> #action SlickNik to update the dev-docs with build / test process updates.
18:04:37 <mattgriffin> o/
18:04:43 <rueben> o/
18:04:53 <SlickNik> #topic Per datastore volume support
18:04:57 <boden> o/
18:05:00 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/per-datastore-volume-support
18:05:24 <iccha> 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 <iccha> One believing it belonged to capabilites and other it belonged to the datastore config groups.
18:05:36 <iccha> 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 <iccha> 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 <iccha> 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 <kevinconway> iccha: how you type so fast?
18:06:07 <grapex> Hey these meetings are supposed to be improv only
18:06:08 <iccha> kevinconway: i have super powers
18:06:08 <amrith> cut and paste
18:06:37 <peterstac> o/
18:06:51 <vipul> one question i have is.. what's the status of capabilities?
18:06:57 <robertmyers> seems to me that volume support is not a capability
18:07:03 <robertmyers> it is a choose
18:07:06 <robertmyers> choice
18:07:22 <iccha> vipul: the api and migration is merged, the management calls to add capabilites are in review
18:07:24 <grapex> 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 <grapex> Then if capabilities is ready adding it to check capabilities should be no problem
18:07:38 <SnowDust> amrith how u knew its cut and paste :)
18:07:42 <dougshelley66> vipul: we are working on some of the front end apis for ti
18:07:52 <denis_makogon> o/
18:08:04 <kevinconway> i agree with robertmyers. this is not a capability of a datastore.
18:08:07 <cp16net> 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 <SlickNik> 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 <kevinconway> SlickNik: false
18:08:33 <denis_makogon> SlickNik, ++
18:08:42 <dougshelley66> if volume support isn't a capability then i would say we completely missed the boat on capabilities
18:08:43 <denis_makogon> same for me, seems like capabilities task
18:08:58 <grapex> 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 <kevinconway> 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 <abramley> SlickNik +1 - having this as a capability is needed for Horizon support
18:09:10 <vipul> yea it's completly fair to tie volume_support and other flags like this to a datastore..
18:09:15 <grapex> abramley: How so?
18:09:56 <grapex> Is it just so you can query to see if volumes are or are not supported on a given datastore?
18:10:01 <robertmyers> so then volumes needs to be a hard coded config setting
18:10:10 <robertmyers> it if is needed for horizon
18:10:18 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/capabilities
18:10:21 <abramley> grapex - since that is a common way for horizon to obtain this information - rather than some other mechanism
18:10:27 <robertmyers> otherwise you have to enter it in the db every time
18:10:37 <grapex> abramley: People deploying horizon will know if it is supported or not
18:10:40 <vipul> 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 <abramley> If we want to enable / disable UI functionality per datastore - then capabilities should do that
18:10:58 <grapex> 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 <denis_makogon> abramley, ++
18:11:23 <grapex> vipul: can't the hp deployment of Horizon just disable that?
18:11:33 <robertmyers> abramley: but cant it be driven by a config option?
18:11:38 <grapex> Trove allows you to, so Horizon should do the same
18:11:55 <kevinconway> right now capabilities is a db object not unlike metadata, yes?
18:11:57 <vipul> 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 <abramley> robertmyers - how does that config option get to horizon? we duplicate it in various configuration files ?
18:12:15 <iccha> and horizon doesnt need to know about trove configs
18:12:15 <denis_makogon> kevinconway, yes
18:12:25 <robertmyers> abramley: provide an api to read it
18:12:44 <robertmyers> I just don't think it need to be in the DB
18:12:44 <kevinconway> so let's say my datastore doesn't support users or databases, how do i use capabilities to disable those features?
18:12:46 <abramley> robertmyers - we have an api to read it already if it is a capability
18:13:20 <robertmyers> but it *has* to be in everyones setup
18:13:23 <grapex> abramley: So will Horizon make this call for each datastore to know if it does or does not support volumes everytime?
18:13:28 <iccha> kevinconway: i think how do we use capabilities or rather introduce capabilities into code base is the next question
18:13:29 <robertmyers> otherwise the check fails
18:13:37 <denis_makogon> kevinconway, with admin rights you would disable users API for given datastore, format of disabling/enabling hadn't been discussed yet
18:13:59 <robertmyers> what if you typo adding the capability into your db
18:14:09 <iccha> denis_makogon: i think kevinconway is refering to first step of adding a given cpaability to the table
18:14:14 <kevinconway> 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 <SnowDust> robertmyers +1
18:14:35 <grapex> Sounds like what is needed here is an API to see what are acceptable arguments to the create call
18:14:39 <denis_makogon> kevinconway, ++
18:14:51 <iccha> 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 <grapex> Even if we have capabilities all that is going to be is a bag of random settings for each datastore
18:14:55 <denis_makogon> grapex, that's capabilities for
18:15:07 <kevinconway> iccha: we originally planned to augment the CONFIG object
18:15:11 <amrith> 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 <grapex> 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 <SlickNik> iccha: IIRC we discussed this at the mid-cycle, and we planned to extend the CONF object.
18:15:44 <grapex> 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 <esmute> 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 <grapex> amrith: And trying to see if she has to use the brand new capability feature or can use the conf file
18:16:17 <iccha> 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 <robertmyers> config file +1
18:16:28 <denis_makogon> +1 to capabilites instead of conf
18:16:35 <kevinconway> robertmyers: +1
18:16:47 <iccha> SlickNik: kevinconway and this config object would be loaded from the database?
18:16:49 <grapex> What does using the capabilities instead of the conf buy us other than new fun ways to screw up a deployment?
18:16:59 <vipul> If you read the capabilities BP.. it's littered with volume_support as the prime example
18:17:01 <amrith> grapex, iccha thanks. I thought we discussed this in Atlanta (or maybe Austin) and decided we would use capabilities
18:17:03 <robertmyers> if we add it to capabilities, we need a set of hard coded values
18:17:08 <kevinconway> iccha: it would have a special object attached to it that did db lookups. like CFG.capabilities.some_stuff
18:17:17 <denis_makogon> vipul, +!
18:17:26 <robertmyers> it can't all be driven by db entries
18:17:26 <amrith> so I'm wondering whether there is a forcing function driving the reconsideration.
18:17:29 <iccha> kevinconway:  SlickNik was it discussed how it would be added to db in first place to ensure consistency?
18:17:57 <denis_makogon> robertmyers, why?
18:18:11 <SlickNik> iccha: There was some talk of seeding it from the values in the config files.
18:18:13 <robertmyers> denis_makogon: so you know which values are accepable
18:18:24 <kevinconway> 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 <rueben> denis_makogon: robertmyers: typos in the capability name
18:18:40 <grapex> SlickNik: So the capabilities for say volume support, if it wasn't in the db, would come from the config file?
18:18:41 <robertmyers> how would yo know to set volumes vs volume_support
18:18:54 <kevinconway> ex: myDataStoreX doesn't support replication. that is a capability
18:19:05 <denis_makogon> kevinconway, capabilities are not only about what datastore can or not
18:19:14 <kevinconway> denis_makogon: that is the definition of capability
18:19:19 <denis_makogon> kevinconway, it's all about resource utilization
18:19:26 <SlickNik> grapex: It would depend on the implementation, but a fallback approach like that sounds reasonable.
18:19:58 <grapex> 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 <amcrn> 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 <esmute> i think we should have the BP on capabilities being updated
18:20:19 <iccha> SlickNik: if the db is loaded from config values, whats the point then
18:20:23 <rueben> 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 <denis_makogon> kevinconway, when caps. came they were only about datastores but for now, it's more that datastores specific things
18:20:25 <esmute> right now i dont know what a capability is.
18:20:26 <grapex> 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 <SlickNik> kevinconway: iccha, IIRC one of the points mentioned was that you could turn on / off capabilities programmatically
18:21:14 <grapex> 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 <vipul> 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 <amcrn> 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 <glucas> 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 <grapex> 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 <kevinconway> SlickNik: yes. example: i deploy datastoreX at my company. I want to enable users but disable backups.
18:22:00 <vipul> 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 <grapex> 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 <vipul> grapex: yep, exactly -- and that was the idea behind capabilities.. at least that's how i understood it
18:23:31 <denis_makogon> vipul, grapex +
18:23:40 <grapex> vipul: Maybe we should refocus capabilities on just that then
18:23:52 <grapex> Also, Freudian slip, Reach==Horizon ;)
18:23:52 <SlickNik> kevinconway: in its original incarnation this was about the capabilities of a "trove deployment", not necessarily of a particular "datastore".
18:23:52 <iccha> 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 <grapex> iccha: Or reinvision capabilities
18:24:22 <grapex> as something that just answers the question "what can I do for this particular datastore"
18:24:22 <robertmyers> or both
18:24:30 <esmute> 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 <vipul> iccha: Yea i don't care where it's stored i suppose
18:24:34 <robertmyers> check db then config
18:24:39 <denis_makogon> i'd suggest to reinvision capabilities first, then move on with other things
18:24:55 <amcrn> wouldn't it be odd that we introduce a mgmt api to set a conf file?
18:25:07 <amcrn> hence the drive to have capabilities store the matrix in a table
18:25:09 <grapex> 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 <denis_makogon> esmute, as for me, caps. are not only things about what datastore can or not
18:25:20 <robertmyers> amcrn: you'd tuse it to set the db
18:25:46 <vipul> 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 <amcrn> if we're using the db, then i'm not understand why capabilities makes understanding volume-support more difficult
18:26:06 <kevinconway> denis_makogon: should we call it marshmellow instead? that way the word doesn't confuse us?
18:26:07 <robertmyers> amcrn: can you need to know to set that exact string
18:26:20 <robertmyers> s/can/because/
18:26:31 <esmute> 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 <esmute> #link https://blueprints.launchpad.net/trove/+spec/cinder-volume-type
18:26:57 <grapex> 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 <amcrn> 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 <vipul> esmute: I would agree -- that's a backend concern that doesn't need to be exposed
18:27:30 <cp16net> i agree with grapex
18:27:44 <cp16net> seems like we are chasing our long lost ghost
18:27:54 <grapex> 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 <grapex> It isn't perfect
18:27:59 <grapex> but it's pretty simple
18:28:05 <grapex> I saw that code and wanted to start crying
18:28:32 <grapex> 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 <robertmyers> that is how it should be
18:28:59 <robertmyers> and it *could* be driven by a db under the hood
18:28:59 <grapex> 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 <cp16net> can we vote it?
18:29:03 <robertmyers> it if must
18:29:09 <iccha> 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 <amcrn> makes it easier from an operations perspective as well; because you likely already have auditing on conf drift
18:29:13 <grapex> That way the volume work is not dependent on also fixing capabilities for its first use case
18:29:34 <vipul> 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 <kevinconway> did we even have datastore configs when we talked about capabilities?
18:29:43 <amcrn> vipul: good point
18:29:48 <iccha> to enable support for a feature its highly likely a deployment is needed when config can be changed amcrn
18:30:04 <grapex> 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 <amcrn> grapex: so would capabilities morph into a read-only view call, with the values being set via confs?
18:30:38 <esmute> An API that returns a matrix?
18:30:42 <iccha> vipul: yes thats right. and it could be added to the response irrespective of where it is stored
18:30:53 <SlickNik> So it seems to me that we have different types of "capabilitles" we're talking about here:
18:30:53 <SlickNik> 1. Don't care about reading through the API : This should be a backend concern, not capability
18:30:53 <SlickNik> 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 <SlickNik> 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 <grapex> amcrn: I'd be ok with that
18:31:21 <vipul> thanks SlickNik i think thta's a good summary
18:31:29 <grapex> vipul SlickNik: Agreed
18:31:43 <cp16net> SlickNik: thanks
18:32:03 <iccha> well summarized
18:32:03 <grapex> I'm goof with #2
18:32:05 <grapex> *good
18:32:10 <grapex> Should we vote?
18:32:15 <amcrn> 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 <amcrn> otherwise you'd return a bunch of junk, unless they're under a special subheader
18:32:35 <vipul> amcrn: yea some way to change visibility of conf options
18:32:41 <grapex> 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 <vipul> i think the DB would help solve that.. with a conf file.. might get wierd
18:33:05 <SnowDust> #2 makes sense
18:33:12 <robertmyers> 2 +2
18:33:19 <rueben> #2 ++
18:33:27 <esmute> Isnt #2 solved with docs?
18:33:34 <grapex> 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 <kevinconway> grapex: we had several use cases. API features being disabled if not supported
18:33:56 <iccha> yeah we agree upon #2, but that doesnt define how we want to implement it
18:33:57 <esmute> i dont understand the need of an API to tell you what features you can or cant use
18:34:02 <robertmyers> #3 is good too
18:34:03 <grapex> 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 <robertmyers> so I'm on 2 to 3
18:34:15 <grapex> The problem then esmute is in cases like Horizon they have to duplicate the settings
18:34:51 <iccha> 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 <amcrn> +1 to grapex, and it will only get worse once flavors-per-datastore gets implemented, etc.
18:34:57 <dougshelley66> 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 <vipul> 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 <esmute> ahh ok.. so this is more to help integrate better with other other openstack projects
18:36:26 <iccha> SlickNik: if we did have a standardized way to add capabilities to the table, would that help merge #2 and #3?
18:36:30 <vipul> so if we go with #2, anyone have ideas on how something would be made visible ?
18:36:31 <SlickNik> dougshelley66: Yes, that's what I originally meant it as. Not as separate options, but as a whole.
18:36:58 <SnowDust> even #3 makes sense for admin priviledge(role)
18:37:02 <kevinconway> i'm confused by numbers...
18:37:26 <SlickNik> dougshelley66: Although, I'm good with approaching this incrementally if that would make things easier.
18:37:32 <SlickNik> Okay time check.
18:37:35 <iccha> vipul: might have to be explicitly added to datstore show call
18:38:17 <grapex> rueben: Is there a public way to view capabilities now (i.e. not the mgmt api?)
18:38:30 <rueben> no
18:38:38 <iccha> 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 <dougshelley66> yes we are working on capabilities list now
18:39:05 <grapex> rueben: In that case we should be open to the idea of making a new REST call
18:39:17 <dougshelley66> iccha i assume there is some reason we need this volume support so quickly?
18:39:20 <amcrn> this is likely divisive, but if the immediate concern is "hey, we have datastore <x> 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 <grapex> Why not just make this a call to the datastore version view?
18:39:32 <amcrn> i'm with dougshelley66, i don't see why this is so urgent
18:39:37 <grapex> amcrn: +100000000000
18:39:47 <grapex> That's what I'd like to get buy in for
18:40:23 <iccha> 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 <robertmyers> or, we just make capibilties optionally read the config file for the value
18:40:24 <grapex> 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 <SlickNik> iccha: I like that idea (I believe robertmyers alluded to it earlier as well).
18:41:05 <amcrn> 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 <amcrn> 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 <iccha> amcrn: i meant [mysql] [redis] config group in the conf file
18:41:47 <iccha> amcrn: not the configuration groups defined by trove
18:41:51 <amcrn> ah, my bad ;)
18:42:09 <robertmyers> iccha: +1
18:42:15 <amcrn> i'm ok with iccha's proposal
18:42:25 <amrith> what's the proposal?
18:42:32 <amrith> add it to config_groups?
18:42:54 <iccha> yes amrith, thats the first step while we made a decision on capabilities
18:43:20 <vipul> 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 <amrith> may I suggest we set this topic gingerly aside and ask the question about the "decision on capabilities"
18:43:46 <amrith> is there some "decision" that needs to be made?
18:43:47 <SlickNik> 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 <amrith> SlickNik, that strikes me as saying that we've embraced the fact that this is a capability
18:44:26 <vipul> amrith: +1
18:44:27 <dougshelley66> vipul given this discussion I think we need to update the spec to hopefully get everyone on the same page
18:44:32 <amrith> 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 <iccha> 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 <robertmyers> amrith: +1
18:44:59 <esmute> Can someone update the BP to reflect that has been decided today?
18:45:01 <esmute> #link https://blueprints.launchpad.net/trove/+spec/capabilities
18:45:17 <esmute> ahh dougshelley66 you beat me to it :P
18:45:20 <kevinconway> esmute: was anything decided today?
18:45:23 <SlickNik> esmute: We haven't decided anything yet.
18:45:33 <amrith> OK, I have a proposal
18:45:47 <SnowDust> SlickNik, why not update to DB but config file at runtime ?
18:45:50 <amrith> SlickNik, maybe we should table iccha's request till the capabilities BP is updated
18:46:00 <amrith> and then discuss the implementation of iccha's proposal.
18:46:03 <grapex> SlickNik: Can we have a vote to not hold the volumes work hostage until we finish capabilities?
18:46:08 <esmute> kevinconway: Im as confused as you are... I was hoping the BP will shed some clarity into capabilities :P
18:46:22 <amrith> unless someone feels there is an URGENT desire to get volume support implemented right away, post haste, stat ...
18:46:36 <grapex> amrith: I do.
18:46:43 <robertmyers> amrith: me too
18:46:48 <grapex> Also I think we should drive capabilities based on the feature it will support
18:46:53 <SnowDust> in past i was asked to "fork" when in haste :)
18:47:07 <vipul> 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 <iccha> 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 <grapex> vipul: I disagree
18:47:21 <kevinconway> i disagree this is a hack
18:47:24 <grapex> there is not even an mgmt API for capabilities
18:47:33 <grapex> Also I wouldn't call this code a hack: https://github.com/openstack/trove/blob/master/trove/instance/models.py#L593
18:47:36 <vipul> sounds like dougshelley66 is working on it and it's only a matter of time
18:47:49 <dougshelley66> vipul also rueben, i believe
18:47:54 <cp16net> ok
18:48:02 <amrith> 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 <grapex> amrith: Some datastores don't need volumes?
18:48:50 <amrith> so what is getting held up grapex?
18:48:54 <rueben> dougshelley66: https://review.openstack.org/#/c/104011/
18:48:56 <grapex> vipul: So you're saying: let's wait and not add these features until capabilities is 100% finished
18:49:03 <rueben> dougshelley66: that's the current patch
18:49:05 <grapex> because at the midcycle capabilities was discussed as something that was nearly done
18:49:19 <SlickNik> 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 <dougshelley66> rueben, correct. which is a mgmt api for capabilities, right?
18:49:24 <robertmyers> amrith: we want to offer two db's one with volumes and one without in the same trove instance
18:49:32 <grapex> 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 <iccha> vipul: amrith why cant we do iterative development in the open
18:49:47 <iccha> grapex: +!
18:49:47 <vipul> 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 <rueben> dougshelley66: trove management commands for adding/removing capabilities and their overrides
18:50:05 <denis_makogon> vipul, +1
18:50:10 <grapex> vipul: I think that will be easier once we have the use cases
18:50:14 <rueben> dougshelley66: cli commands
18:50:17 <kevinconway> vipul: if we're talking about how to implement capabilities, are we also defining what a capability is?
18:50:28 <grapex> if the concern here is that if we implement volume togglability right now, changing it later will be impossible, I disagree
18:50:37 <vipul> kevinconway: i think we went a long way towards doing that today
18:50:56 <grapex> vipul: at the expense that we have people who have other work they need to get done who are now blocked
18:51:08 <rueben> dougshelley66: does also include the underlying logic to do the add/removes
18:51:17 <iccha> 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 <grapex> 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 <kevinconway> iccha: users!
18:52:04 <vipul> 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 <grapex> 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 <iccha> 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 <vipul> 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 <SlickNik> Okay, guys. Let's move on to open items, let's circle back to this after the meeting.
18:52:29 <vipul> the fix will fit right in, once capabilities land
18:52:32 <SlickNik> #topic Open Discussion
18:52:35 <grapex> vipul: Ok, +1
18:52:35 <cp16net> sounds good
18:52:37 <grapex> I think we agree
18:52:46 <denis_makogon> i have one
18:52:49 <cp16net> i have 2 things
18:52:52 <cp16net> go denis_makogon
18:52:54 <denis_makogon> thanks
18:53:23 <denis_makogon> not so long ago oslo.db and oslo.i18n were released, and some of the OS services are already using them
18:53:46 <denis_makogon> at last oslo meeting was a talk about Trove and those libs
18:54:08 <SnowDust> denis_makogon, Yogesh : lets have a talk on vertica datastore patchsets
18:54:09 <denis_makogon> do we have certain plans to move to oslo.i18n and oslo.db in Juno-2/3
18:54:20 <denis_makogon> SnowDust, after meeting
18:54:52 <amrith> denis_makogon, is there some feature/aspect that we need?
18:54:57 <vipul> denis_makogon: sounds like a large port..
18:54:58 <SlickNik> denis_makogon: Is there a reason for the move?
18:55:28 <denis_makogon> amrith, no features, it's a migration from oslo-incubator code to specific released libs
18:55:37 <amrith> 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 <denis_makogon> SlickNik, code is being deprecated and deleted from oslo
18:56:19 <amrith> denis_makogon, are you saying something will stop working?
18:56:19 <SlickNik> denis_makogon: akaik, the only code being deprecated and removed this cycle is the rpc code.
18:56:29 <SlickNik> And we are planning to move to oslo.messaging.
18:56:31 <vipul> SlickNik: +1
18:56:40 <denis_makogon> other reason is to up to date, but seems that Trove already uses some legacy/dropped code from oslo
18:56:49 <SlickNik> Also oslo has a policy of 1 cycle heads up before deprecating / removal.
18:57:10 <SlickNik> So if they deprecated something this cycle, they won't remove it until the next one.
18:57:26 <amrith> 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 <denis_makogon> ok
18:57:30 <cp16net> #action SlickNik update jenkins: please remove JENKINS_HOME/scm-sync-configuration.*.log files
18:57:33 <cp16net> :)
18:57:41 <SlickNik> cp16net: will do, thanks! :)
18:58:07 <SlickNik> cp16net: go for it. 2 mins
18:58:19 <cp16net> and FYI i created a job that should test multiple patches for a blueprint
18:58:30 <cp16net> i have not seen it pass yet but it looks like it should work
18:58:45 <cp16net> #info https://rdjenkins.dyndns.org/job/multi-patch-test
18:58:54 <cp16net> ok thats it
18:59:01 <SlickNik> cp16net: nice work!
18:59:14 <SlickNik> cp16net: will take a look at it.
18:59:19 <denis_makogon> but still rdjenkins =)
18:59:33 <SlickNik> anything else?
18:59:53 <SlickNik> #endmeeting trove