14:00:00 #startmeeting Glance 14:00:00 Meeting started Thu Apr 2 14:00:00 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:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:04 The meeting name has been set to 'glance' 14:00:16 o/ 14:00:31 o/ 14:00:59 Agenda for today: 14:01:00 o/ 14:01:04 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:16 o/ 14:01:26 o/ 14:01:26 Looks like we've decent turnout.. 14:01:50 Let's get started 14:01:53 #topic Kilo RC1 14:02:02 Quick updates 14:02:07 Specs: 14:02:54 1. We got CIS (Catalog Index Service) merged on server side. Due to client HardDepFreeze we ar not letting any more changes so that is carried over to early(ish) L (as applicable) 14:03:12 o/ 14:03:31 o/ 14:03:49 There are few related changes to CIS that should go in, like the functional tests. Those were considered not a mandate on feature and can be merged outside of the freeze (in the RC window) 14:03:54 Those* 14:04:24 o/ 14:04:29 o/ 14:04:35 o/ 14:04:37 seems like we've only one pending for review: 14:04:38 https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:bp/catalog-index-service,n,z 14:05:04 Welcome guys, we're just chatting on RC1 14:05:05 that's an interesting statement ... we demand 20 lines of tests for single line bug fix and then we are willing to merge whole functionalities into release without tests? 14:05:46 Welcome to OpenStack 14:06:19 all test are written and passed there 14:06:25 *tests 14:06:37 https://review.openstack.org/#/c/157209/ 14:07:24 the main CIS patch which got merged also had tests 14:08:07 The review priority and the community expectations were declared quite in advance. Lack of reviews adds pressure on the stability. We need to find a balance on this and reviewers need to focus on the program priorities. We cannot afford to work on refactors and minor fixus and smaller reviews when the whole features are waiting. We can discuss more about this in the coming weeks.. 14:08:37 Artifacts: 14:08:39 https://blueprints.launchpad.net/glance/+spec/artifact-repository 14:09:33 A few merged and a few did not. It's a big change and lots of code. So, we will take what we can get. 14:10:10 There is a bug fix on cis as well. I'm on mobile. So can't type quick enough. Trying to find. 14:10:22 great thanks to all the reviewers who made that possible 14:10:23 ok, do we have funtional artifacts now in the release? (not perhaps doing all that was wanted, but something that can be used?) 14:10:27 There was some conversation between the rel-mgr and project/feature repr that allowed some reviews merge in Kilo early this week 14:11:04 Can we have funtional tests for artifacts without API merged? 14:11:22 jokke_: no, unfortunately not: the REST API commit didn't get enough reviews and was postponed 14:12:01 Although not backport candidate, we can still work on helping move those forward on L-1 14:12:06 ativelkov: ^ 14:12:24 That should give enough time to complete the client work and stabilize the feature 14:12:29 TravT: This one? https://review.openstack.org/#/c/166501 14:12:45 artifacts has got the DB layer, declarative framework (flaper87 - I remember, we have agreed to refactor it a lot, Ina is already working on it), the plugin loader and some other helper stuff. No domain and REST API commit (the last one binds them all together) 14:12:46 As I stated in the reviews, the API is more delicate than the database code since it's user facing. 14:13:11 ativelkov: I started looking at Ina's work, thanks a lot for putting efforts there 14:13:22 I really appreciate the openness you guys have demostrated 14:13:36 flaper87: it's also experimental and to be clearly communicated as subject to change backward incompatible. I hope ativelkov will take care of that 14:14:12 nikhil_k: yeah, agreed on that! 14:14:39 nikhil_k: sure. The documentation (which haven't been merged as well) says that explicitly. But having a client at the moment of API release is a good thing, so we'll try doing that in L1 14:15:07 Sounds like a plan 14:15:38 BTW, guys, do you prefer artifacts client to be part of the main python-glanceclient CLI, or should we have a separate command endpoint? 14:15:39 I've also asked ativelkov and his team to create a new spec for L 14:16:04 ativelkov: I think we can discuss that on the spec 14:16:08 I just know who will be responsible for the client 14:16:18 nikhil_k: got it 14:16:20 better to get wider audience and hopefully this time earlier in the cycle 14:16:41 ++ 14:16:45 ++ 14:16:45 mfedosin: for its development? I guess that will be us 14:17:08 so, re the client library, it'd be inconsistent to have the API in glance and the client library elsewhere. 14:17:15 (if I understood your question correctly) 14:17:30 flaper87: no, the library is definetly the same 14:17:34 ativelkov, yeah, sure :D 14:17:43 I mostly speak about CLI endpoint 14:17:44 There is the place where most (if not all) the comments/bugs on the reviews related to Artifacts are: 14:17:47 #link https://etherpad.openstack.org/p/Artifacts_Reviews 14:18:10 ativelkov: ah sorry, mmh, I guess the endpoint could be different, OTOH 14:18:35 ativelkov, mfedosin: please please please, try to not put all what you want to extend on those patches what you have out pending again ... lets try to get what you have ready into the state we can merge sooner the better before extending a lot ... I'd rather see experimental api in L1 than stable api day before FF 14:18:38 i.e. should that be "$ glance artifacts-list" or something else, like "glance-artifacts artifacts-list" 14:18:50 flaper87: yeah, I think he means something along the lines of the novaclient (like the module based wrapper) 14:19:03 Though, maintainability wise that sounds trixy 14:19:30 I'd personaly vote for `glance artifacts-list` for the sake of consistency 14:19:35 jokke_: I surely agree. I'd prefer to land the remaining two patches in L1 and then proceed with imporvements/new features/refactoring 14:20:10 and, well, less code lines per patch. The lesson is learned :) 14:20:30 thanks guys for all your patience in reading that tons of code 14:20:43 ativelkov: yes and preferably softer dependencies too 14:21:12 (fewer unneeded rebases ie) 14:21:16 yup 14:21:20 Thanks! 14:21:37 So, we are out of the FFE period 14:21:39 well, once most of the base logic is in, we won't have so much dependencies 14:22:04 sure 14:22:19 At this point, we are looking at only bugs that fit the RC criterion 14:22:57 #topic RC1 blockers 14:23:06 nikhil_k: do you have link to those criteria for refresher to everyone 14:24:22 hmm, can't seem to find the link (if there is one) 14:24:58 yeah hard criteria would be nice 14:24:59 Basically, we are frozen on all the changes related to features, docs, dependencies and such 14:25:02 https://wiki.openstack.org/wiki/Kilo_Release_Schedule 14:25:06 also we're still in string freeze, right? 14:25:11 nikhil_k: ok, mind to type few line summary what we're looking that can qualify on top of any critical/security bugs? 14:25:13 That has list of the freeze(s) 14:25:23 Yeah, trying 14:25:52 * flaper87 reads carefully 14:26:32 RC1 would allow more general bugs than other RCs 14:26:55 The patch wokuma mentioned above is really important. Metadefs don't load correctly right now. Fresh devstack will yield 0 usable defintions out of box. 14:27:04 So, anything that's breaking can be merged and if needed we are easier to get an exception (for docs, deps) 14:27:39 RC2 would be the period when we test out tarball rigorously and find stuff to fix 14:27:51 RC3 is limited fixes only 14:27:54 sure ... and iiuc we can put easy fixes that might not be so critical as soon as something surfaces that mandates next RC anyways 14:28:26 nikhil_k: so rc1 will be out at 9th? 14:28:40 can you please elaborate on "that mandates next RC anyways" ? 14:29:10 jokke_: it's usually on Tuesdays (iirc) 14:29:35 nikhil_k: so when there comes critical bug that will push us to next RC anyways we can and should get other fixes in as well what we manage to fix while doing that one that will demand the next rc 14:29:38 So, that if there has to be an execption and wait on gate it can be resolve in couple of days and we're packed by Friday 14:30:21 folks, what about fixes in python-glanceclient? Are they postponed now, as we are on dep-freeze and so new releases are not likely now? 14:30:25 jokke_: yes please 14:30:32 but we should not tag RC4 for fixing typos in docstrings :P 14:30:56 I don't think we get RC4 (at least not yet) 14:31:07 at that time we are looking at backports 14:31:23 and have more restrictions 14:31:51 ativelkov: we can fix bugs in client and make patch releases, but no new functionality until we can lock the stable client and start developing for Liberty 14:32:06 what jokke_ said 14:32:27 got it 14:32:39 Thanks to sigmavirus24 : 14:32:50 huh? what'd I do? 14:32:51 #info We've created more official tags at https://bugs.launchpad.net/glance 14:32:54 I am asking because of https://review.openstack.org/#/c/168364/ as it fixes some cinder-related bug 14:32:56 hah 14:33:13 There are tags for artifacts, cis, cache etc now 14:33:15 ativelkov: I thought I had workflow'd that 14:34:12 I wanted to quickly go through the RC1 bugs so that people are aware (online now and otherwise) 14:34:21 https://bugs.launchpad.net/bugs/1417304 14:34:21 Launchpad bug 1417304 in Glance "Upload/Import image continues consuming glance host cpu/memory/network/disk resources even after the image is deleted" [Undecided,Incomplete] 14:34:25 sigmavirus24: nope, there was just a +1 from you at one of the first PS. +2A will be appreciated ) 14:34:27 So following ativelkov's review, quickly, it's introducing new behaviour, but the fact that it didn't exist before is a pretty bad bug 14:34:53 ah 14:34:56 sigmavirus24 & nikhil_k: if there is some "more official" new tags, please update https://wiki.openstack.org/wiki/Bug_Tags#Glance accordingly 14:35:14 jokke_: cool, thanks for the pointer! 14:35:34 jokke_: will do 14:35:45 sigmavirus24: can we pleae come to it in the bugs topic? 14:36:26 We're out of time for RC1 and had a security bug people might want to chime in on.. 14:37:00 * sigmavirus24 is quiet ; 14:37:17 Sorry about that, a bit caught up.. 14:37:26 bug/1417304 14:37:40 We need a verdict on that whether we need it in kilo or not 14:37:45 nikhil_k: that one, I'll get back to it as promised last night 14:37:48 well, night for me 14:37:51 flaper87: and I had agreed yday that it can wait 14:38:09 I think we should change the milestone, I can do that after commenting 14:38:10 Everyone please leave you opinion if necessary 14:38:13 nikhil_k: easy fix, we do not allow deleting image which is on saving status ... if one want's to delete image one should cancel the upload first ;) 14:38:37 jokke_: Please do provide your insight there :) 14:38:46 will do :P 14:38:50 https://bugs.launchpad.net/bugs/1276694 14:38:51 Launchpad bug 1276694 in neutron "Openstack services should support SIGHUP signal" [Wishlist,In progress] - Assigned to Elena Ezhova (eezhova) 14:38:54 That looks merged 14:39:07 and I think we can mark it Committed 14:39:26 mclaren: do you have still something pending for that? 14:39:43 The other three in open status are needed and blocking RC1 so please review them before others 14:39:49 just the glance-control bit 14:40:00 jokke_: what happens if it is in SAVING due to a copy-from external source? Is there a way to cancel that? 14:40:15 https://review.openstack.org/#/c/130222/ 14:40:23 mclaren: Not sure if you got a chance to look at my email - I think we can do that bit in the kilo-potention as a different bug 14:40:50 Other bugs that have potential to go in Kilo are: 14:40:51 https://bugs.launchpad.net/glance/+bugs?field.tag=kilo-rc-potential 14:41:23 ativelkov: I don't think we have abort for that currently, which is not that great loss as the copy-from is v1 functionality and tasks does support abort iiuc 14:41:36 ativelkov: sigmavirus24 : Can we mark this with milestone https://bugs.launchpad.net/cinder/+bug/1323660 14:41:37 Launchpad bug 1323660 in Glance "Glance image properties not copied to cinder volume with glance V2 API" [Undecided,In progress] - Assigned to Alexander Tivelkov (ativelkov) 14:41:39 ? 14:41:49 Hopefully it should merge smoohtly now that it has a +W 14:42:18 sigmavirus24: and if you wanted to go ahead on that bug please do :) 14:42:28 mclaren: btw thanks for finding the gate broker! All: could we please finally stop issuing requests to random domain brokers from our tests! 14:42:59 oh! What was the issue? I missed the solution, but the problem was really nasty 14:43:38 ativelkov: hopefully this https://review.openstack.org/#/c/169889/ 14:43:43 mclaren: ++ 14:43:45 (I never actually reproduced a failure) 14:44:04 mclaren: me nor flaper87 either 14:44:34 oh my... 14:44:43 FWIW, I think the problem is weirder than that since the `get_size` catches the BadStoreUri error but still, it's being propagated 14:44:45 :/ 14:44:55 That's what had me stuck for a bit 14:45:17 anyway, mclaren's fix should be enough for our CI 14:45:41 Ok, guys. Sorry about this, we are running out of time 14:46:12 If there are no more bugs to be discussed forkilo-potential can we please run for the next part? 14:46:36 Ok, in the interest of time crunch.. 14:46:44 (crunch..) 14:46:49 #topic Summit planning 14:47:00 #info Slots: Fishbowl: 4, Work: 8, Sprint: 1 Halfday 14:47:16 * sigmavirus24 won't make it to the sprints 14:47:18 There was some discussion in the CPL meeting yday about this 14:47:32 what's the fishbowl? 14:47:44 and we'd added the discussion etherpads for the topics to 14:47:45 ativelkov: the normal room we've been using 14:47:48 #link https://wiki.openstack.org/wiki/Design_Summit/Planning 14:47:55 ativelkov: I mean, the sessions as we know them 14:48:06 #link https://etherpad.openstack.org/p/liberty-glance-summit-topics <- That the Glance specific one 14:48:20 ativelkov, A fishbowl conversation is a form of dialog that can be used when discussing topics within large groups. 14:48:51 More info on the summit format (changes): 14:48:53 #link https://openstack.nimeyo.com/521/openstack-dev-vancouver-design-summit-format-changes?show=417 14:48:56 ativelkov: ^ 14:49:13 Ok, moving on to the next 14:49:16 #topic Stable branches 14:49:20 git it, thanks 14:49:34 flaper87: sigmavirus24 and I had a chat yday about glance_store stable branch 14:49:42 seems like we don;t have one currently 14:50:12 So, the plan was to point on the absolute necessary changes/commits to have after 0.3.0 for a stable branch for juno and kilo 14:50:25 We are trying to track that inofficially on 14:50:27 https://trello.com/b/GFXMXxsP/openstack-glance 14:50:40 (Currently, there is nothing and soon to be added) 14:50:55 FWIW, there's a -1 on my patch already 14:51:11 #link https://review.openstack.org/#/c/169661/ 14:51:14 awesome 14:51:17 I'll get back to that soon 14:51:34 Client stable branch 14:51:40 We did not discuss one yet 14:52:01 however, my opinion is (based on a quick browse) that we need the same approch here 14:52:14 yup 14:52:28 That was it from my side. 14:52:39 I will open up for pending / other discussions 14:52:39 re the stable branch 14:52:46 open up the topic 14:52:48 We were mostly waiting for the cross-project patch to land 14:52:48 :) 14:52:53 now that it's been merged 14:52:54 #topic Open Discussion 14:52:59 folks, please, say your thoughts/opinions about db documentation https://review.openstack.org/#/c/164432/ Because we are ready for the next commit :) 14:53:00 I think we can move forward to creating such branch 14:54:14 if we have a suggestion for a summit topic, should we discuss it here or go ahead and put it on the etherpad? 14:54:24 bpoulos: yes please go ahead 14:54:28 I'd propose both glance_store and python_glanceclient "stable" branches to be named by the version we dedicate for stable backports for stable glance releases 14:54:32 we're working on a feature for image signing and encryption supported by glance 14:54:42 this would allow users to verify that their images had not been modified by verifying a signature before booting the image 14:54:50 we were wondering if it would be possible to discuss the feature at the summit 14:55:10 jokke_: as in stable/juno ? or stable/0.3.0 ? 14:55:11 bpoulos: interesting 14:55:25 flaper87: stable/0.3 14:55:29 flaper87: the spec prescribes stable/juno kind of stuff iirc 14:55:42 bpoulos: I'd love to hear more! FWIW, flwang once looked into this, you might want to ping him and see where he was at 14:55:45 flaper87: and for example 0.3.1 would be just tag on that branch 14:55:51 jokke_: what sigmavirus24 said 14:56:00 flaper87: ok, thanks 14:56:06 bpoulos: that's sounds interesting. We have planned similar for artifacts, so it definetely worths discussing more 14:56:34 bpoulos: feel free to propose into https://etherpad.openstack.org/p/liberty-glance-summit-topics 14:57:03 jokke: alright, i'll add it there 14:58:19 sigmavirus24: i think the biggest problem with using the release names in the libs is that because we do not follow same schedule it can become really messy and confusing quickly, thus I'd prefer using the stable version on the branch name 14:58:48 +1 on jokke_ 's idea 14:58:54 jokke_: that probably would have been better raised during the discussion of the cross-project spec. I personally agree 14:58:54 as the requirements refers to the version number as well 14:58:57 bpoulos: +1 on your proposal 14:59:04 (personally agree with you jokke_ ) 14:59:19 we should try to make sure everyone does it the same way if possible 14:59:29 but in the stable branch we would still have the version in the setup.cfg 14:59:31 right ? 14:59:40 nikhil_k: thanks 14:59:43 * flaper87 agrees with jokke_ 15:00:05 I think we should bring that up to a broader audience 15:00:14 since consistency throughout projects might be important here 15:00:18 ok time's up and I have next meeting to jump into 15:00:20 thanks all 15:00:28 Thanks all! 15:00:30 thanks guys, have a good day 15:00:30 #endmeeting