18:02:34 <SlickNik> #startmeeting trove
18:02:34 <imsplitbit> go go go
18:02:34 <openstack> Meeting started Wed Apr 30 18:02:34 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:38 <openstack> The meeting name has been set to 'trove'
18:02:42 <robertmyers> o/
18:02:46 <imsplitbit> ok we need to beat 16 minutes
18:02:46 <grapex> o/
18:02:46 <amrith> o/
18:02:48 <mat-lowery> o/
18:02:49 <iccha> o/
18:02:52 <konetzed> woot woot
18:02:52 <kevinconway> o/
18:02:53 <pdmars> o/
18:02:54 <SlickNik> Agenda:
18:02:55 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:03:00 <amytron> o/
18:03:01 <abramley> o/
18:03:05 <cweid> o/
18:03:07 <annashen> o/
18:03:12 <cp16net> |o|
18:03:15 <cweid> Hello everyone.
18:03:15 <konetzed> \o
18:03:16 <esp> o/
18:03:19 <cp16net> gooooool
18:03:26 <glucas> |-o-|
18:03:28 <hub_cap> good day all, im here and happy to be here
18:03:36 <esp> cp16net: lol
18:03:37 <hub_cap> i refuse to make ascii art of myself
18:03:38 <robertmyers> cp16net: wheres the a?
18:03:44 <hub_cap> but i am, in fact, a part of this meeting
18:03:59 <esmute> 0/
18:04:02 <hub_cap> you can tell by the text im submitting to this channel
18:04:03 <SlickNik> Alright, let's get started.
18:04:05 <SlickNik> #topic Establish policy for disk image builder elements for datastores
18:04:09 <juice> o/
18:04:15 <mat-lowery> My colleages have submitted a couple of Gerrit changes (https://review.openstack.org/77461 and https://review.openstack.org/79413) that have been -1ed because they lack Fedora diskimage-builder (DIB) elements.
18:04:16 <amcrn> o/
18:04:21 <mat-lowery> Goal: Establish a policy regarding Gerrit changes that add a DIB element.
18:04:22 <glucas> has anyone seen hub_cap? Is he here? :-)
18:04:27 <hub_cap> ;)
18:05:01 <vgnbkr> o/
18:05:15 <mat-lowery> Other items to consider are here: https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_Apr._30
18:05:30 <peterstac> \o
18:05:54 <mat-lowery> I'm all for Fedora and Ubuntu parity. But parity can come piecemeal (as it does for the datastore managers).
18:06:00 <mat-lowery> The dangers in requiring parity up-front include: higher potential of Abandonment, potential reduced quality of the "other" DIB element, lack of testing on Fedora at all...
18:06:26 <mat-lowery> Obviously I'm biased but the point is to just establish a policy whatever that may be.
18:06:33 <vgnbkr> I think I started the fedora issues.  I think testing fedora might be onerous, but I think that fedora elements should always be added, and if they're not tested should just throw an error.
18:06:39 <amcrn> given that we don’t enforce supporting a new feature across all datastores at once, it makes sense that we don’t enforce support of a datastore across all distros at first-go.
18:06:57 <robertmyers> amcrn: +1
18:07:03 <vgnbkr> (with a suitable message)
18:07:28 <grapex> amcrn: +1
18:07:29 <kevinconway> is the conversation about supporting datastores on multiple distros or simply being able to kick-start them in a test/development environment
18:07:38 <amcrn> kevinconway: former
18:07:55 <robertmyers> plus if they are not available or don't work wouldn't you use the distro that did?
18:08:00 <SlickNik> So, as a user here, in that case how do I know what's the state of support for a particular datastore for a particular distro?
18:08:22 <amrith> at the risk of dragging up the "support matrix", does it now mean that we need to make one that includes both datastore and guest OS?
18:08:24 <amcrn> SlickNik: as the datastore-version story matures, the feature matrix can indicate such things
18:08:29 <kevinconway> SlickNik: does trove have official support for all or any distros other than ubuntu 12?
18:08:29 <vgnbkr> For me, the issue is that when someone goes to test something on fedora, the state should be obvious.  They shouldn't have to go tracking down why something that works on ubuntu doesn't work on fedora.
18:09:35 <juice> I haven't used Fedora but can someone give me an example of something that works on ubuntu but not fedora
18:09:40 <robertmyers> but isn't this just for the DIB?
18:09:56 <robertmyers> if you want to deploy you should build your own images
18:09:58 <SlickNik> kevinconway: I think as an OpenStack project we need to support both Fedora as well as Ubuntu.
18:10:03 <vgnbkr> Right now, I don't know if anything works on fedora, at least not F20.
18:10:13 <mat-lowery> In case you didn't check out the meeting agenda: Cassandra and Couchbase are merged and do not have Fedora DIB elements.
18:10:17 <vgnbkr> It never gets testes AFAIK.
18:10:25 <esmute> what does this mean when it comes to gating? will we run the tests on both distro?
18:10:48 <SlickNik> So let's constrain the scope of this discussion to just the DiB elements for now.
18:11:14 <juice> maybe we can address each step of the process separately to keep this from turning into a tornado
18:11:23 <kevinconway> so the only difference between the DIB for ubuntu and fedora is apt vs yum right? is there more to this?
18:11:35 <SlickNik> I'm going to take an action item upon myself to check what other OpenStack projects do when it comes to testing on multiple distros (ubuntu / fedora in particular)
18:11:41 <vgnbkr> Yes, there are some small system differences.
18:12:02 <SlickNik> kevinconway: also upstart vs systemd, there might be more...
18:12:09 <juice> so what is the success critteria of building a disk image?
18:12:19 <amcrn> +1 juice and SlickNik. the very targeted question at the moment is: right *now*, does the introduction of a new datastore-version (and/or datastore) require adding dib-elements for both ubuntu and fedora in one-shot
18:12:54 <juice> amcrn: I would say adding a new datastore only requires it to work with ubuntu
18:13:04 <juice> or ubuntu only
18:13:11 <vgnbkr> Then why have fedora at all?
18:13:13 <cp16net> i think it makes sense to piecemeal the dibs but make sure it works for ubuntu
18:13:20 <SnowDust> amcrn: :-) that depends on the datastore's binary packages and its distro-support
18:13:30 <cp16net> because ubuntu is the test bed
18:13:42 <juice> vgnbkr: I would see fedora as "optional" at this point
18:13:59 <vgnbkr> then why don't we just take fedora support out until we're ready to deal with it properly?
18:14:24 <juice> vgnbkr: because we may have support for SOME data stores on fedora
18:14:26 <SnowDust> juice : optional means .. not officially supported indirectly ?
18:14:33 <juice> so the matrix is datastore/distro
18:14:50 <amcrn> vgnbkr: that's akin to saying: let's take out backups because they're not supported for all datastores. it's up to the stakeholders that care about a particular feature and/or distro to further their own interests.
18:14:57 <juice> every datastore should have a check in the ubunto distro column
18:15:23 <kevinconway> we keep saying support fedora vs support ubuntu. isn't this only about kick-starting in a dev environment?
18:15:28 <amcrn> kevinconway: no
18:15:35 <iccha> i think this is an openstack policy question, and maybe should be discussed at project meeting
18:15:37 <kevinconway> this isn't to say that missing DIBs from trove-integration prevent a deploy of a datastore
18:15:43 <vgnbkr> amcrn: that's different - it is expected that the stake holder will fix it.  In this case, who is the stakeholder for fedora?
18:15:43 <peterstac> I think we should at least be consistent across datastores: if datastore_a/v1 supports both then datastore_a/v2 should too
18:16:08 <amcrn> kevinconway: the problem right now is we're getting reviews -1'd because dibs don't exist for fedora, and are only being introduced for ubuntu
18:16:24 <juice> amcrn: that is a problem
18:16:28 <amcrn> vgnbkr: whoever wants to deploy on fedora
18:16:32 <kevinconway> amcrn: right, but that's not supporting a distro. that's setting up a dev environment
18:16:33 <grapex> amcrn: Yeah- we need to stop that
18:17:07 <juice> kevinconway: is your question, what does "support" mean...officially?
18:17:08 <amcrn> we have quorum then, yes? no -1'ing a ubuntu-only dib-element introduction.
18:17:25 <juice> what guarantees do we offer on this software? it passed the gate?
18:17:36 <juice> amcrn: we can vote on that
18:17:49 <SlickNik> Okay, let me propose a plan of action.
18:17:54 <vgnbkr> amcrn: So all I'm suggesting is that when a change is made to ubuntu, if the corresponding fedora elements aren't updated/created, there be a placeholder to indicate that that element is not supported.
18:18:01 <hub_cap> i think we should consult the mordred 's of the world too
18:18:15 <hub_cap> im not sure what our "requirements" here are
18:18:19 <SlickNik> I'll check with the other OpenStack folks about this.
18:18:39 <grapex> SlickNik: Is the plan to test / gate all datastore managers and versions against both Ubuntu and Fedora?
18:18:49 <SlickNik> I'm not 100% sure what the official openstack position is regarding asymmetric support across distros.
18:19:08 <grapex> I can't see a surefire way we can know if the corresponding fedora elements are updated or created if we don't
18:19:10 <kevinconway> SlickNik: you are now responsible for all decisions made in openstack up to the point you became PTL
18:19:30 <SlickNik> kevinconway: That's so comforting to know. :)
18:19:31 <amcrn> SlickNik: i'm not sure why the answer to that question should prohibit inflight reviews, considering if the answer is "it should be asymmetric" we're already wayyyyyy out of compliance
18:19:52 <grapex> amcrn: Agreed.
18:20:30 <SlickNik> amcrn: Because it dictates whether our priority should be to drag us back into compliance vs. to add more datastores getting us further away.
18:21:30 <grapex> Trove already is going to have a ton of datastores, which means a ton of testing. Regardless of OpenStack's take, my guess is we will not be able to gate on testing for every single datastore and version for every distro.
18:22:31 <juice> grapex: the number of permutations would be quite high at this point
18:22:32 <robertmyers> maybe we should get datastores to work in general
18:22:39 <grapex> robermyers: +1
18:22:48 <SnowDust> grapex: testing till today is for trove functionality .. not for distro support ... and you are right that way
18:22:53 <robertmyers> cause it sucks trying to use more than one
18:22:59 <mat-lowery> Stupid question: This code runs on the guest...one level up from OpenStack "proper" which is what keeps getting referenced as the standard for being symmetric. Is it a fair comparison?
18:23:06 <SlickNik> grapex: We should have the stakeholders who are interested in adding the datastores to Trove, also do the testing using some sort of 3rd party infra.
18:23:30 <amrith> time-check
18:23:54 <amcrn> SlickNik grapex: the problem is, if it's made this difficult to support other versions, the amount of inflow of public code will dry up.
18:23:59 <grapex> mat-lowery: Good point
18:24:05 <grapex> maybe just test the guest on those distros
18:24:29 <mordred> hub_cap: what did I do?
18:24:39 <hub_cap> what didnt u do :)
18:24:48 * mordred throws wet cat at hub_Cap
18:25:10 <hub_cap> mordred: we install datastores, do we have to, by default, make sure that we support fedora and ubuntu for all datastores?
18:25:14 <grapex> amcrn: Right- which is why I don't think we should gate on all the permeatations introduced by testing Fedora on every single datastore
18:25:19 <hub_cap> ^ ^ we an talk after w/ SlickNik, mordred
18:25:29 <hub_cap> and mordred, i do wash my cat, ask imsplitbit
18:25:29 <SnowDust> grapex: means there will be multiple test runs .. following instance create .. for each distro ?
18:25:39 <SlickNik> mordred: Support for a few new datastores are being added to Trove, and we're discussing whether there is a cross OpenStack requirement to support a Fedora guest as well as an ubuntu guest.
18:25:52 <amcrn> grapex: agreed.
18:26:25 <mordred> hub_cap: not really
18:26:38 <hub_cap> ^ ^ decree
18:26:56 <mordred> hub_cap: right now the policy is "dev targets latest ubuntu/fedora but may not do anything that prevents running on latest LTS or RHEL"
18:27:23 <mordred> we don't gate on fedora anywhere in the system at the moment, because fedora and ubuntu have the same python
18:27:25 <mordred> NOW
18:27:26 <hub_cap> ok but if we are all runnin ubuntu, we wait for someone to care about fedora?
18:27:31 <mordred> yup
18:27:34 <mordred> if you guys do a C-based agent
18:27:37 <grapex> mordred: I like it
18:27:42 <hub_cap> LOL
18:27:45 <grapex> mordred: This sounds theoretical....
18:27:47 <mordred> we probably want to escalate making sure it works on fedora
18:27:49 <mordred> just saying
18:27:49 <amcrn> lol
18:28:00 <grapex> mordred: But C is hard
18:28:17 <cweid> Also not enterprise webscale.
18:28:18 <grapex> IIRC you have to do bit twiddling extensively just to print a hello world.
18:28:38 <robertmyers> grapex: python3?
18:28:55 <SlickNik> Okay, time check.
18:28:59 <atomic77> looks like i am going to start doing more testing against ubuntu for my stuff :)
18:29:18 <hub_cap> heh atomic77 :P
18:29:21 <grapex> robertmyers: Good point- we at some point may want to test in Python 3 if the guest will be running on it and some canonical capacity
18:29:32 <amcrn> can we move on to the sub-item of discussing the use of PPAs?
18:29:47 <cweid> Sure
18:29:50 <mat-lowery> I'm not sure where we landed here.
18:30:06 <SlickNik> #startvote What should we do to ubuntu-only dib element patchsets. +1, -1, figure_out_requirements
18:30:07 <openstack> Unable to parse vote topic and options.
18:30:11 <SlickNik> lol
18:30:16 <SlickNik> Let's table this for now.
18:30:28 <SlickNik> mat-lowery: Let's move on to the next sub-item
18:30:54 <mat-lowery> ok. This is SlickNik's silent scope creep on my agenda item. :)
18:31:05 <mat-lowery> Do we have a policy on how the bits are laid down?
18:31:18 <mat-lowery> Package Install vs. Tarball Install vs. Source Install
18:31:35 <cweid> I think it would be what is avail for the datastore?
18:31:38 <juice> mat-lowery: is this for trove packages only?
18:31:47 <juice> or for dependencies as well
18:31:52 <SlickNik> juice: This is for the datastore.
18:32:07 <juice> trove-guest only then..
18:32:43 <mordred> cweid: wait- hang on. I want to go back to "c is not webscale"
18:32:57 <cweid> enterprise webscale.
18:32:58 <juice> ...as part of the reference guest install process
18:33:08 <mat-lowery> juice: As it was conceived, just the datastore. mysql-server deb
18:33:28 <SlickNik> I think at some point we decided that we would use official distro packages.
18:33:33 <hub_cap> mordred: dont feed the trolls :)
18:33:47 <amcrn> SlickNik: we did? ;)
18:33:48 <SlickNik> But the issue is that for some of these new datastores, no official distro packages exist.
18:33:51 <vipul> i beleive we've stuck to package install with official supported versions from vendors
18:34:12 <cweid> That's not true
18:34:23 <hub_cap> i dont think redis is a pkg
18:34:25 <hub_cap> is it?
18:34:25 <mat-lowery> There is currently a PPA-based, merged DIB: Redis on Ubuntu.
18:34:26 <cweid> I use some random PPA to install redis
18:34:27 <SlickNik> amcrn: I'm using "decided" loosely here. There was no official decision.
18:34:39 <hub_cap> so to sound like a broken record
18:34:41 <mordred> fwiw - OpenStack has no official policy on this - other than that _We_ do not make packages
18:34:45 <hub_cap> this is development, not production :)
18:34:52 <cweid> hub_cap: +1
18:34:54 <hub_cap> ymmv for installing production
18:35:04 <amrith> as an extension of earlier conversatiion, wouldn't the answer be that the one(s) concerned about that datastore will pick the packages that must be installed?
18:35:05 <hub_cap> we should find _a way_ to run the version we advert we run
18:35:55 <hub_cap> but again, if you are running some ppa in production, thats on you, if, say, it goes down or something else happens
18:36:11 <amcrn> hub_cap: the problem lies in what is actually *supported* via the managers
18:36:22 <amcrn> god knows if that random ppa diverges from the official package, etc.
18:36:26 <vipul> our goal should be that installers can use upstream DIBs to do a produciton install..
18:36:27 <atomic77> for more "experimental" data stores (cough) obviously we would not a policy that states that packages must come from the official repos
18:36:31 <hub_cap> sure amcrn and i think we need to find _a way_ to install our version we support
18:36:52 <vipul> if we need to do something special for development.. fine.. but make that param driven in the DIB
18:36:53 <hub_cap> atomic77: yea i dont think we _have_ to come from the official repos
18:37:13 <hub_cap> amcrn: i think we should do our best to pick a ppa that doesnt rewrite a datastore functionality
18:37:28 <amcrn> how is it possible to even certify that scientifically?
18:37:34 <amcrn> other than "looks like it"
18:37:40 <atomic77> but maybe it makes sense to simply warn when a data store is not using official packages
18:37:50 <hub_cap> amcrn: well, our other option is to build everything from source :)
18:37:51 <atomic77> and the user ideally knows what they are doing
18:37:58 <amcrn> i'm 100% against a ppa-based install unless the author of the ppa is the actual maintainer of the project
18:38:05 <SlickNik> Okay. I think the general consensus that that it's okay for our dib _dev_ elements to pick up a PPA, but we need to make it aptly clear what PPA's packages our manages are _actually_ tested against.
18:38:22 <atomic77> +1 amcrn that makes sense
18:38:31 <hub_cap> other options are that we (amcrn) creates a ppa for all pkgs
18:38:39 <hub_cap> or we just build from scratch in the dib element ;)
18:38:55 <SlickNik> Boy do I love those options. :)
18:39:20 <amcrn> and we're no closer to figuring out what is mergeable
18:39:40 <hub_cap> fwiw, i totally think a ppa is fine, and if we find a ppa that does what amcrn is thinking, im sure itll become a bug in our system
18:39:47 <hub_cap> and we can fix it _when_ it happens
18:39:59 <hub_cap> ;)
18:40:06 <hub_cap> https://launchpad.net/~ondrej/+archive/mysql-5.6
18:40:10 <cweid> I mean we can't just maintain packages for N number od databases
18:40:11 <cweid> https://launchpad.net/~rwky/+archive/redis
18:40:13 <vgnbkr> Or have datastore versions be tied to package source, i.e., mysql-5.5-cononical
18:40:14 <hub_cap> we could use that tomorrow heh
18:40:28 <SlickNik> Okay, time-check.
18:40:30 <hub_cap> vgnbkr: but then we have to build that, right?
18:40:51 <hub_cap> yea this sounds like a good bargument at openstack summit
18:41:05 <vgnbkr> hub_cap: no, I'm saying it's a defined source for that datastore version, so it's OK to get it from the defined source.
18:41:34 <hub_cap> ugh maybe we should do this
18:41:58 <hub_cap> 1) stop installs, and force upgrades to be a "deploy to new image"
18:42:03 <vgnbkr> So we would have mysql-5.5-canonical, mysql-5.5-oracle, mysql-5.5-percona, etc.
18:42:03 <hub_cap> sorry taht was #2
18:42:25 <hub_cap> if we say "you must provide your version in the image" then we dont have the issue of using apt/blah/blah at _all_
18:42:34 <hub_cap> and for development we can do whatevs
18:42:45 <hub_cap> but we can remove all of the install logic / apt/rpm logic from the code
18:42:53 <robertmyers> hub_cap: +1
18:43:00 <hub_cap> and migrations / upgrades are new instances / migrations
18:43:08 <hub_cap> err upgrades are new instances/migrations
18:43:26 <SlickNik> Okay, trying to reign this one in.
18:43:29 * hub_cap puts down his wrench
18:43:38 <vgnbkr> How does that solve the problem of knowing which versions of DB x work with the guestagent code?
18:43:41 <amcrn> hub_cap: i agree with you, that still doesn't answer the question of: what is merge'able as a dib-element. can it be a ppa? can it be a long-winded 500 line shell script?
18:44:12 <hub_cap> amcrn: build from source ;)
18:44:23 <hub_cap> then it wont matter tho honestly
18:44:35 <hub_cap> a ppa would be fine, and if it diverges, we will find out when we get a bug listing
18:44:43 <hub_cap> honeslty even w/o my wrench that would work
18:44:50 <juice> amcrn: I don't understand the issue - as long as it is consistently retrievable and something we have tested against why does it matter
18:45:02 <cweid> juice: +100
18:45:11 <cweid> Also
18:45:13 <grapex> juice: +1
18:45:19 <juice> I guess it would have to be universally retrievable - i.e. on the internet
18:45:19 <cweid> we might want to just treat this on a case by case basis
18:45:38 <hub_cap> otherwise we can build em ourselves
18:45:46 <cweid> hub_cap: -100
18:45:47 <hub_cap> and stick em up in lp
18:45:59 <mat-lowery> juice: The manager is tied to the bits on disk. There has to be some somewhat standard place to look for the binaries, etc.
18:46:01 <amcrn> juice: just got a phone call, sory
18:46:48 <SlickNik> Okay for mergeability:
18:46:49 <SlickNik> #startvote Allow PPAs in DIB elements? yes, yes_but_only_if_project_official, no
18:46:50 <openstack> Begin voting on: Allow PPAs in DIB elements? Valid vote options are yes, yes_but_only_if_project_official, no.
18:46:51 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:47:09 <mat-lowery> #vote no
18:47:14 <grapex> #vote yes
18:47:17 <cweid> #vote yes
18:47:23 <imsplitbit> #vote yes
18:47:24 <konetzed> #vote yes
18:47:27 <robertmyers> #vote yes
18:47:28 <rueb7363> #vote yes
18:47:29 <atomic77> #vote yes
18:47:33 <SlickNik> #vote yes_but_only_if_project_official
18:47:45 <juice> #yes_but_only_if_project_official
18:47:46 <mat-lowery> #vote yes_but_only_if_project_official
18:47:46 <imsplitbit> I don't get that?
18:47:49 <juice> shoot
18:47:51 <cweid> What makes it official?
18:47:52 <juice> #vote yes_but_only_if_project_official
18:48:04 <imsplitbit> who makes it official?
18:48:12 <SlickNik> cweid: the PPA is by a project maintainer
18:48:17 <cweid> What is there is not one?
18:48:20 <juice> cweid: I would say that we have gate test around it but that is seriously limited
18:48:21 <cweid> and no debs
18:48:27 <amrith> #vote no
18:48:28 <grapex> SlickNik: A maintainer of the datastore?
18:48:40 <SlickNik> grapex: yes
18:48:48 <SlickNik> #showvote
18:48:49 <openstack> yes (7): robertmyers, konetzed, grapex, imsplitbit, cweid, rueb7363, atomic77
18:48:50 <openstack> yes_but_only_if_project_official (3): mat-lowery, SlickNik, juice
18:48:51 <openstack> no (1): amrith
18:49:14 <juice> looks like yes_but_only_if_project_official won ;)
18:49:17 <SlickNik> #endvote
18:49:17 <openstack> Voted on "Allow PPAs in DIB elements?" Results are
18:49:18 <openstack> yes (7): robertmyers, konetzed, grapex, imsplitbit, cweid, rueb7363, atomic77
18:49:19 <openstack> yes_but_only_if_project_official (3): mat-lowery, SlickNik, juice
18:49:20 <openstack> no (1): amrith
18:49:25 <mat-lowery> Given this vote, can we at least state that PPAs should not be the first choice?
18:49:27 <hub_cap> oops i missed the vote
18:49:38 <juice> that was weird
18:49:41 <hub_cap> official repos sohuld always be first
18:49:45 * amrith different
18:49:46 <cweid> totally
18:49:49 <hub_cap> then rando dude ppa
18:49:52 <hub_cap> then build from scratch
18:49:54 <juice> what's your vote hub_cap?
18:50:03 <hub_cap> my vote is to vote against juice
18:50:07 <cweid> Too late he missed the vote.
18:50:07 <hub_cap> in general, in life
18:50:13 <juice> that leave you two options
18:50:15 <juice> yes or no
18:50:32 <SlickNik> So allow it. But let's make a best effort to follow this order: distro package, project maintainer PPA, some random PPA.
18:50:35 <cweid> We have like 50 million options
18:50:44 <cweid> If there is a package in the distro use it
18:50:50 <cweid> if not
18:50:56 <cweid> find some other place to get it?
18:51:02 <grapex> Why would someone add a PPA if an official option existed?
18:51:03 <cweid> I don't see how this is really an issue?
18:51:09 <hub_cap> so is there such a thing as "project maintainer ppa"
18:51:10 <grapex> Seems mean. :/
18:51:16 <cweid> Can we just have an order of operations?
18:51:17 <mat-lowery> Case by case basis of course but Redis PPA was chosen because it was a newer version.
18:51:25 <SlickNik> grapex: modified slightly for perf / whatever.
18:51:37 <hub_cap> mat-lowery: and im sure the same would be said wrt my5.6
18:52:10 <SlickNik> Okay, I think we've beaten this to death.
18:52:14 <SlickNik> LEt's move on.
18:52:23 <SlickNik> #topic Open Items
18:52:38 <kevinconway> SlickNik: didn't you have a topic about commit messages?
18:52:42 <vgnbkr> Was the -1 for comments issue covered?
18:52:49 <iccha> i have soemthing i wanted to mention as well
18:53:01 <SlickNik> Yes, I did.
18:53:05 <SlickNik> It's short.
18:53:11 <SlickNik> iccha: you can go first.
18:53:33 <iccha> neha wanted us to look at https://wiki.openstack.org/w/index.php?title=Trove/list-datastore-type-and-versions
18:53:42 <iccha> she made changes after bp was approved
18:53:47 <iccha> to the api response
18:54:35 <robertmyers> iccha: that looks good
18:54:45 <NehaV> thanks iccha.
18:55:00 <robertmyers> nice and backward compatible
18:55:00 <cp16net> yeah it was additive of the versions
18:55:13 <NehaV> ya basically i made the change for augmenting the existing call and changed the format of the response
18:55:34 <NehaV> now versions are nested within each db type
18:55:48 <SlickNik> iccha / NehaV: Looks good to me at a quick glance.
18:55:58 <iccha> thanks for taking a look !
18:56:17 <grapex> SlickNik: So about that -1 comment thing
18:56:33 <SlickNik> Okay, so I just wanted to chat a bit about the −1 on Commit messages.
18:56:35 <grapex> What's a good idea of the kind of commit message styles that are getting -1'd which you think shouldn't be?
18:56:55 <SlickNik> I've seen a bunch of them that say "Please provide Reasons / Changes"
18:58:00 <SlickNik> I'm not sure how the "Reasons / Changes" requirement came about, but I don't think we should mandate it. esp for a 1-2 line change.
18:58:26 <cp16net> SlickNik: oh mean in the commit message
18:58:30 <robertmyers> #link https://wiki.openstack.org/wiki/GitCommitMessages
18:58:39 <robertmyers> no reason / change
18:58:42 <cp16net> yeah i dont think that its a big deal
18:58:54 <grapex> I don't like seeing that either
18:59:01 <vgnbkr> I think it's fair that reasons/changes should be apparent to the reviewer, but it shouldn't be necessary to have explicit sections.  The reviewer should use their judgement.
18:59:05 <SlickNik> Thanks robertmyers, I was looking for that.
18:59:06 <grapex> I actually think it's a huge waste of text to have to write the Changes especially
18:59:12 <hub_cap> -1 reasons/changes
18:59:15 <cweid> gotta run out a little early see you guys next week. Have a good week!
18:59:15 <hub_cap> just put a paragraph
18:59:17 <grapex> the "Changes" are already in the git difference which itself is the commit
18:59:31 <grapex> and the "reason" should be in the commit msg anyway- there's no need to title it as such
18:59:38 <grapex> see you cweid
18:59:38 <kevinconway> are there any rules against lorem ipsum commit messages?
19:00:05 <SnowDust> hehe : i got a -1 for putting  reasons/changes :D
19:00:21 <SnowDust> thanks hub_cap <3
19:00:42 <grapex> kevinconway: I think that's pretty much what the "Reason / Changes" format is
19:00:50 <grapex> SlickNik: Can we vote?
19:01:38 <hub_cap> https://review.openstack.org/#/c/86808/
19:01:38 <hub_cap> plz view that commit msg
19:01:38 <hub_cap> and yes juice has noted i misssepellld separation
19:01:38 <esp> grapex: +1
19:01:38 <SlickNik> Another thing I want to get a quick opinion on.
19:01:38 <SlickNik> Do we require a bug for all changes?
19:01:38 <hub_cap> we used to say yes
19:01:38 <robertmyers> yes
19:01:38 <hub_cap> but im tihnking no, if its a spelling change
19:01:38 <iccha> what abt stuff like spelling mistakes?
19:01:38 <cp16net> if its small i dont think so
19:01:38 <hub_cap> or a trnsifex
19:01:39 <esp> I have had folks ask for more descriptive messages tho
19:01:39 <hub_cap> or something mordred does on tox
19:01:39 <cp16net> but if its bigger than a line or 2 i think we should
19:01:39 <robertmyers> no spelling change commits
19:01:39 <hub_cap> lol robertmyers
19:01:39 <amrith> SlickNik, I thought it was BP or BUG
19:01:41 <SlickNik> I think I agree with the general sentiment.
19:01:42 <juice> robertmyers: +1
19:01:47 <hub_cap> SnowDust: ;)
19:02:02 <iccha> whats the settlement SlickNik ?
19:02:12 <SlickNik> #startvote Require bug, or bp? yes, no
19:02:12 <cp16net> the meeting is over.
19:02:13 <openstack> Begin voting on: Require bug, or bp? Valid vote options are yes, no.
19:02:15 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
19:02:22 <kevinconway> iccha: i don't discuss settlements without my lawyer present
19:02:26 <hub_cap> #vote no
19:02:30 <robertmyers> #vote yes
19:02:30 <hub_cap> hurry!!!!!
19:02:33 <hub_cap> we are over
19:02:34 <SlickNik> I think the idea is that we don't need it for small changes.
19:02:35 <SnowDust> #vote no
19:02:35 <juice> #vote no
19:02:38 <cp16net> #vote not always
19:02:39 <grapex> #vote no
19:02:40 <openstack> cp16net: not always is not a valid option. Valid options are yes, no.
19:02:45 <hub_cap> way to go cp16net
19:02:46 <cp16net> #vote no
19:02:47 <SlickNik> #vote no
19:02:49 <juice> man cp16net!
19:02:52 <amrith> #vote yes
19:02:53 <cp16net> :-/
19:02:58 <hub_cap> #vote no , not always :)
19:02:59 <openstack> hub_cap: no , not always :) is not a valid option. Valid options are yes, no.
19:03:15 <SlickNik> any more takers?
19:03:18 <vgnbkr> #vote yes
19:03:25 <juice> vote-bot don't take no 'ish
19:03:31 <grapex> juice: lol!
19:03:34 <SlickNik> lol
19:03:40 <iccha> we should make it explicit under what conditions it is ok not to have a bug or bp
19:03:48 <robertmyers> #vote falsey
19:03:48 <openstack> robertmyers: falsey is not a valid option. Valid options are yes, no.
19:03:52 <SlickNik> #endvote
19:03:52 <konetzed> iccha: +1`
19:03:53 <openstack> Voted on "Require bug, or bp?" Results are
19:03:55 <openstack> yes (3): robertmyers, amrith, vgnbkr
19:03:57 <openstack> no (6): SlickNik, SnowDust, juice, cp16net, grapex, hub_cap
19:04:04 <esmute> #vote no
19:04:04 <amrith> the yea's have it
19:04:14 * amrith rejoices
19:04:18 <SlickNik> lol
19:04:27 <SlickNik> #endmeeting