14:00:09 #startmeeting Glance 14:00:10 Meeting started Thu Mar 26 14:00:09 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:11 o/ 14:00:13 The meeting name has been set to 'glance' 14:00:32 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:41 o/ 14:00:58 Welcome all! 14:01:10 Looks like we've a good turnout :) 14:01:10 o/ 14:01:36 This shouldn't be a long one, hopefully 14:01:42 full house for proper moshpit :D 14:01:43 Let's get started 14:01:43 nikhil_k: that's what they all say 14:01:53 #topic RC1 14:02:00 #link https://launchpad.net/glance/+milestone/kilo-rc1 14:02:18 2 specs need some reviews: 14:02:19 https://blueprints.launchpad.net/glance/+spec/artifact-repository 14:02:20 and 14:02:25 https://blueprints.launchpad.net/glance/+spec/catalog-index-service 14:02:44 Please add some of your thougts on the CIS (Catalog Service glance-spec) if you feel so 14:02:57 #link https://review.openstack.org/#/c/138051/ 14:03:49 #info We've until Monday evening (Tuesday morning in some places) to merge both of these or at least have 2 +2s (waiting on gate) for all the reviews on each of the specs 14:04:24 So, reviews are welcome from everyone 14:04:36 Reviews are definitely appreciated! 14:04:52 nikhil_k: do you mean reviews on the specs, or on the code patches? 14:04:57 They are in FFE period for those who might be unaware 14:05:08 rosmaita: on everything 14:05:19 that's a lot of LOCs to dump in over weekend :( 14:05:37 Here are some helpful links if you're in the mood of reviews: 14:05:39 https://review.openstack.org/#/q/topic:bp/artifact-repository,n,z 14:05:46 https://blueprints.launchpad.net/glance/+spec/catalog-index-service 14:07:00 ativelkov: and mfedosin are point of contacts for Artifacts reviews 14:07:11 points of contact* 14:07:22 and TravT is for CIS 14:07:32 lakshmiS krykowski as well on CIS 14:07:52 That's about the specs from my side. If anyone has some more input please go ahead. 14:08:32 If not, moving on. 14:08:53 jokke_: was it you who added the glance_store and python-glanceclient stable branches point? 14:09:37 maybe it was TravT ? 14:09:38 If so (or one who added to etherpad is online), let me create a new topic for this for easier navigation. 14:09:59 nikhil_k: yes 14:10:06 #topic glance_store and python-glanceclient stable branches 14:10:19 * nikhil_k hands over the mic to jokke_ 14:11:06 jokke_: anything? 14:11:22 So as per the cross project spec (I do not have the link in hands now, will dig it out) all OS libs are expected to move to stable branching from this release 14:11:43 so we should start putting those branches in 14:12:01 this -> 14:12:01 https://review.openstack.org/#/c/155072/ 14:12:08 yes that 14:12:19 #link https://review.openstack.org/#/c/155072/ 14:12:22 (for the minutes) 14:12:31 I think this is a good timing since we recently released the library 14:12:32 ++ thanks 14:13:25 sounds like a good idea. Let's make sure that interested people are aware of the effects like TravT maybe? 14:14:08 I'm happy to help with moving this forward 14:14:21 Ok, so jokke_ can we assign you to send an email to ML about we planning to implement this? or flaper87 14:14:40 so I would suggest we keep our stable maint team handling those two libs as well instead of making dedicated maintainers groups for those, objections? 14:14:40 I think this sounds great from a supportability/stability point of view. Really happy to see it happening 14:14:50 mclaren: I agree 14:14:55 jokke_: ++ 14:15:25 nikhil_k: I can send it out, I think we can figure out with flaper87 the actual work that needs to happen in repos 14:15:42 #action flaper87 and jokke_ to co-ordinate on stable branches for the client and libs incl. email to the ML 14:15:45 thanks jokke_ ! 14:15:47 does this apply to clients aswell does anyone know? 14:15:55 mclaren: yes 14:15:56 When does it take affect? 14:15:59 mclaren: it should yes 14:16:00 nikhil_k: thanks 14:16:10 flaper87: jokke_ if you'd like help with that, I'll have more cycles after the summit probably 14:16:24 TravT: Kilo will be using the new stable and Liberty start following master 14:16:26 TravT: it should take effect after approval. I forget if it's retroactive or not 14:16:27 sigmavirus24: thanks, I'd like to get this done before the summit 14:16:38 it shouldn't take long, it's a matter of submitting a couple of patches to -infra 14:16:40 flaper87: I'll have fewer cycles before that, but I'll try 14:17:10 But please ensure that we've critical bugs covered for both client and lib before marking it stable or at least have them with info for why we could not include them. 14:17:25 (as applicable) 14:17:27 nikhil_k: even if we miss some, we can backport them 14:17:51 yes same backport rules apply and we can keep releasing stables when needed 14:18:29 I have a critical client bug that needs some attention - it's been sitting since K1 - https://review.openstack.org/#/c/138612/ 14:18:35 sounds like a good idea. I don't believe we've security bugs in either at this point so, we can move forward with that plan 14:18:58 nice, thanks wko 14:19:23 jokke_: can you please co-ordinate trello for that too so that we can review them easier/faster? 14:19:27 welcome 14:19:41 nikhil_k: sure 14:19:47 thanks jokke_ 14:20:01 can we move on to next topic? 14:20:05 #action jokke_ sets up trello cards for stable libs 14:20:32 (perfet) 14:20:36 nikhil_k: I think that was all for now 14:20:43 cool. thanks/ 14:20:48 #topic RC potential 14:21:01 #link https://launchpad.net/glance/+milestone/kilo-rc1 14:21:55 I think this one needs to be on there: https://review.openstack.org/#/c/166501/ 14:22:00 I think we've a lot of bugs put in RC1. It has been tasked to keep only the critical ones as blockers and mark the rest of them with 'kilo-rc-potential' tag 14:22:31 nikhil_k: I'd like to see as many bugfixes landing as possible, but lets not wait them 14:23:09 more we get them in now the less probably we will have rc4 or rc5 in our hands because something blew up after all or got forgotten ;) 14:23:17 jokke_: yeah, that sounds like a good idea. May be in next meeting we can share an etherpad with the one we feel should go in asap and spend some time discussing them. 14:25:04 #info by Monday the RC1 bugs list would have fewer items and the rest of them marked with 'kilo-rc-potential' tag. If you need something in RC1 please bring it to team's attention and get it moved to Critical level. 14:25:07 perhaps bug day on week after next to check up what has came out of rc1? 14:25:19 sure 14:25:26 jokke_: ++ 14:25:26 bug day sounds like a good idea 14:25:37 * sigmavirus24 wishes we had those more frequently =P 14:26:13 Cool 14:26:19 Moving on.. 14:26:41 #topic Adoptingno-downward-sql-migration 14:26:54 sigmavirus24: please take over 14:27:11 So this is another cross-project spec 14:27:15 #link http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html 14:27:22 #link http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html 14:27:25 hah thanks nikhil_k 14:27:49 Essentially downwards migrations are considered a harmful practice at this point 14:27:56 The spec suggests deprecating tooling that allows for them 14:28:00 == sigmavirus24 14:28:01 And not adding down migrations to new migrations 14:28:25 So I'm proposing glance follows suit and deprecates using down migrations in its tooling in L 14:28:37 And we should figure out when a good removal date should be in M or after 14:28:48 so I deprecated downgrades in the latest commit 14:28:51 mfedosin: has already started by not adding down migrations in 040 ;) 14:29:04 Sounds like a fair plan. 14:29:05 * sigmavirus24 thanks mfedosin 14:29:30 that's all I have 14:29:40 * sigmavirus24 waits for objections or agreement 14:29:57 * mfedosin agree 14:29:58 Adds weight to our stability focus so, the team can hopefully move up it's priority for L. 14:30:07 * flaper87 agrees 14:30:13 * flaper87 +1'd that spec 14:30:15 :P 14:30:20 sigmavirus24: what are the actual things we're deprecating? 14:30:37 its* 14:30:38 sigmavirus24: cleaning the down parts from the migration scripts? 14:30:58 jokke_: no 14:31:12 Just deprecating any tooling that performs downward migrations 14:31:26 And not adding new migrations with down pieces 14:31:37 it's in test_migrations function walk_versions 14:31:45 sure, do you have list of such tooling? 14:32:05 it has flag enable_downgrades or something 14:32:16 And adding recommendations for proper DB upgrades and suggestion for how to use earlier versions :) 14:32:19 so now it is False 14:32:48 Yeah, I think a glance specific spec will be useful for this work 14:32:55 * sigmavirus24 thinks that is what jokke_ is getting at 14:32:57 ++ 14:32:59 sigmavirus24: +1 14:33:37 at least something to track what we're actually doing regarding this unless sigmavirus24 wants to take sole responsibility :P 14:33:56 lol I don't 14:34:13 Someone who knows how to disappear can 14:34:19 * sigmavirus24 currently has a weird upstream/work balance at the moment 14:35:20 OK, can we move on for now ? 14:35:52 #topic NoSql backend support ( ajayaa ) 14:35:59 Hi guys. 14:36:04 hey 14:36:11 hi 14:36:19 o/ 14:36:25 I was wondering whether glance team would be willing to have a NoSql backend. 14:36:47 we've had this conversations before and I think there was some agreement on doing it 14:36:55 flwang worked on a mongodb impl, IIRC 14:37:06 flaper87, I wasn't a part of it. 14:37:06 however, at this point, I think we'd need to discuss it over 14:37:18 ajayaa: yup, just giving you a summary :D 14:37:20 It would be wonderful to read that conversation. 14:37:26 :) 14:37:37 that sounds cool. 14:37:38 ajayaa: will you be at the summit? 14:37:41 no irrational hatred of the idea on my part 14:37:51 sigmavirus24, not sure. :( 14:37:54 mclaren: can't tell if sarcasm or not 14:37:55 I'm ok with the idea, FWIW 14:37:59 is this something that other projects are considering? 14:38:01 * sigmavirus24 is neutral 14:38:22 mclaren, Yes. I have already proposed a spec to Keystone. 14:38:28 They are happy with it. 14:38:36 I'd like to know what technology and how it's going to be implemented. A spec would be wonderful 14:38:47 https://review.openstack.org/#/c/148521/ 14:38:52 ajayaa: ah, I thought they could already use mongo? (Probably confusing with 'other' implementation) 14:39:01 The above link is for Keystone btw. 14:39:10 I think it makes sense if there is wider pull for it across OS ... it kind of would not make sense having only in Glance 14:39:19 flaper87: agree -- it would need to be done like the sql stuff is, ie fairly consistently between projects 14:39:33 rushiagr, ping 14:39:48 #link fwiw, https://blueprints.launchpad.net/glance/+spec/enable-mongo-db 14:39:53 jokke_: agreed. I'd ideally see this as Glance mainly consuming some kind of oslo effort 14:40:02 I'm a colleague of ajayaa, from Reliance, and I'll be at the summit 14:40:49 == mclaren, jokke_ 14:40:57 * sigmavirus24 hopes no one notices the tuple unpacking exception 14:41:10 ajayaa: rushiagr the main motivation here is? to speed up image listing? 14:41:37 mclaren, To have a scalable and fault torerant Openstack backend. 14:41:40 * nikhil_k raises exception.sigmavirus24() 14:41:54 nikhil_k:++ 14:42:06 ajayaa: and the specific benefit to users? 14:42:09 rushiagr: /me likes that motivation 14:42:25 - rush 14:42:47 (just trying to get a bit of understanding of where you're coming from, eg are there any existing bottlenecks you specifically want to address...) 14:42:48 mclaren: data resiliency 14:43:26 ajayaa, rushiagr: so is mongo something you're planning to go with or do you have some other specific solution in mind for some specific reason? 14:43:43 rushiagr: Do you mean resiliency as in being able to handle custom metadata well and use flexible schema for such? 14:43:55 jokke_, Right now we are evaluating Cassandra and MagnetoDB as the backend. 14:44:03 I don't think we need a strong motivation or benefits table to allow for this innovation to happen. A bit of experimentation in this area would be good. IMHO. However, I'm very curious to know what tecnologies are being evaluated and why 14:44:05 rushiagr: how will it be more resilient than eg mysql? (sorry I'm not a db expert) 14:44:20 especially because, if it happens, I'd like the nosql backend to be already part of openstack 14:44:26 for example, mongodb 14:44:30 FYI, MagnetoDB is an Openstack project which provides dynamodb api. 14:44:31 mclaren: mysql is a centralized solution, whereas we'll like a solution which works properly in case of failures 14:45:10 So we need a spec and this seems like a good thing to discuss at the summit or on an email thread 14:45:13 There are solutions in sql for that too though, no? 14:45:26 rushiagr: what about SQL databases deployed in HA? 14:45:28 e.g. Galera 14:45:34 == pkoniszewski 14:46:21 I guess the motivation can be clarified in a spec/whatever. 14:46:24 pkoniszewski: Although, the ML discussion on Galera wasn't a pleasing one 14:46:56 that's true 14:46:59 ajayaa, rushiagr: I think spec and even more cross project or oslo spec would be great ... as mclaren said, would be great if we did not need to reinvent the wheel but consume something common across OS 14:47:00 nikhil_k: I now have another thing to search for 14:47:10 == jokke_ 14:47:23 and ++ for summit meetup around that 14:47:26 not oslo, pls! 14:47:28 :) 14:47:34 Either glance or cross-project spec 14:47:59 ajayaa: rushiagr: So, the takeaway from here can be - motivation for support of no-sql needs to be a bit more than HA and something that helps with the intricate design of Glance else we should pursure this as OpenStack wide subject discussion. 14:48:19 pursue* 14:48:32 == flaper87 14:48:38 well said nikhil_k 14:48:45 ajayaa: rushiagr is the keystone work very keystone specific? 14:49:13 ajayaa: doesn't mongo have some ugly licensing associated with it 14:49:29 TravT: it's LGPL 14:49:30 ouch, he timed out 14:49:39 lets not get in that mongodb license fight again 14:49:51 :) 14:49:52 As long as we don't force mongo into ppl's deployments, I think it's fine 14:49:57 heh 14:50:00 yeah 14:50:01 TravT: LGPL is acceptable in OpenStack 14:50:03 and the proposed driver is just optional 14:50:18 AGPL, GPL etc aren't 14:50:18 sorry, our wifi router chose the worst time to stop working 14:50:34 or was it AGPL ? 14:50:35 ok, in my last hp internal project we couldn't use mongo for some reason. 14:50:38 Hey guys. 14:50:40 rushiagr: if it's sentient, I would kill it with fire to prevent it from taking over the world 14:50:56 so, conclusion, spec :) 14:51:01 flaper87: agreed. 14:51:03 Next topic? 14:51:03 AGPL 14:51:08 sigmavirus24: :) 14:51:09 10mins left 14:51:31 #topic Open Discussion 14:51:46 * rushiagr reads logs for missed outcome of nosql discussion 14:52:06 flaper87: (thanks for pointing out the license side of that) 14:52:29 mclaren: it was actually TravT, I'm just defending mongodb :P 14:53:02 TravT: (thanks for pointing out the license side of that, I know HP fears the AGPL) 14:53:15 yeah, i've been hit by it before. 14:53:38 but again, it'd be an optional db so, nothing to fear 14:53:42 I'd like to drop a bomb at this point so we can just all agree it on last minute. There has been lots of work done on glance_store to separate it from glance. I think it would be time to start moving it to become oslo_store during Liberty :P 14:54:05 jokke_: nope 14:54:14 We had that discussion when we split it 14:54:22 hm 14:54:24 and we decided that it should stay under glance 14:54:36 flaper87: as said we just could agree on it and start the work rather than argue about it :P 14:54:40 So glance is the main consumer. Do other things want to use it? 14:54:49 because it's still related to how glance works, and it'll be used from cinder and nova in the future (ideally) 14:54:55 sigmavirus24: that was the reason why it was separated 14:54:57 gosh, there's been a lot of churn there, I'd like things to settle for a while before another change... 14:55:08 == mclaren 14:55:13 mclaren: yes 14:55:17 also, it's a core piece 14:55:27 if we move it to oslo, we need to split reviewers there too 14:55:29 L needs to be pow(lot, 1M) cooler than K 14:55:36 it's not like we can just say: "Hey oslo, it's now your problem" 14:55:54 * flaper87 is part of the oslo core team and hell there's enough work there :P 14:56:12 flaper87: so there is no difference under which project you break it? :P 14:56:13 Lets first get it adopted by other projects 14:56:19 and then we can discuss that point again 14:56:23 jokke_: LOL 14:56:26 flaper87: I agree with you. It's not being used by anyone else, so moving to oslo doesn't make sense. Once nova starts using it, may be we can revisit this topic. 14:56:50 (exactly what flaper87 said) 14:57:16 yep 14:57:27 ok, can we then stop pretending it's not tied to glance and make sure it works for us first? 14:58:13 So, about the breakage. We really need better release management for that lib. It's not going to work if there is single point of failure. 14:58:28 I'm still not sure the degree to which glance_store has been 'codified', ie which bits we expect people are relying on and which bits we can change if we need to 14:58:55 mclaren: the refactor is still happening 14:59:02 My perpective on reviews has been a bit worrysome. We focus too hard to sync with oslo and not review stuff that can cause other breakage. 14:59:08 I mean, the spec is there, it hasn't been approved yet and Cindy is working on the refactor 14:59:19 as soon as a patch is up there, we can start re-reviewing the spec 14:59:30 We need dedicated effort on this flaper87 as far as I can tell. 14:59:31 flaper87: ok, thanks 14:59:40 cpallares: if I can help, let me know 14:59:45 or frequent updates 14:59:48 == sigmavirus24 14:59:58 I've tried to reach out to her for the same a few times. 15:00:07 nikhil_k: yes, fwiw, I've been following up but I agree more updates are needed 15:00:16 * sigmavirus24 understands the problems with work/glance/real-life balance 15:00:17 anyways, we need to discuss this offline. 15:00:20 Thanks all! 15:00:20 yep 15:00:21 thanks sigmavirus24, I will :P 15:00:23 thanks 15:00:27 #endmeeting