13:59:34 #startmeeting Glance 13:59:35 Meeting started Thu Apr 23 13:59:34 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:38 The meeting name has been set to 'glance' 13:59:40 o/ 13:59:43 o/ 13:59:43 o/ 13:59:46 o/ 13:59:47 o/ 13:59:48 o/ 13:59:50 o/ 13:59:51 o/ 13:59:52 o/ 14:00:16 welcome all :) 14:00:28 Short agenda #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:37 o/ 14:00:50 Let's get started 14:00:53 #topic RC2 14:01:28 Seems like we are all set for now. Blockers were/are listed at #link https://trello.com/c/CoZ9g13d/45-kilo-rc2 14:01:52 Reviews were given and RC2 is about to be cut 14:02:11 Any last minute red flags? 14:02:25 o/ 14:02:46 https://review.openstack.org/#/c/169813/ and https://review.openstack.org/171022 are still failing on gate. recheck going on... 14:02:54 thanks 14:03:13 We would basically use the older reviews and ninja approve if needed 14:03:39 trying to avoid any delays. Some of them need to be backported 14:05:29 yosamite just crashed 14:06:05 Backports would be done by rel-mgrs so no need to worry about them for now 14:06:25 Sometimes if there are bunch of conflicts then it is recommended for the authors to do them 14:06:43 backport for what? 14:07:03 Those reviews that are target for RC2 14:07:12 and currently proposed against master 14:07:33 ah you mean the picks for stable/kilo branch, thanks got it 14:07:48 yeah 14:07:50 This one was brought to my attn a couple days back #link https://review.openstack.org/#/c/176411/ 14:08:03 It seems unlikely to make it 14:08:20 So, let's roll that over to Liberty if there are no objections 14:09:02 Moving on.. 14:09:25 #topic Gate failure blocking reviews 14:09:38 #link https://bugs.launchpad.net/glance/+bug/1447463 14:09:38 Launchpad bug 1447463 in Glance "glance.tests.functional.v2.test_images.TestImages.test_download_random_access failed" [Critical,New] 14:09:55 so we have small problem there, everything will keep failing 14:10:16 I'm working with krykowski but we haven't found where the problem is yet 14:10:50 pkoniszewski: Just kind reminder ... if you bump bug criticality, please make sure that you set it at least confirmed as well then 14:11:11 Cool, let's keep syncing on #openstack-glance to speden up unblocking 14:11:18 jokke_: i just wanted to bring more attention, everything with +2 is blocked and RC2 is near 14:11:24 I'm happy to take a look aswell 14:11:31 thanks for any help! 14:11:48 (although stuck in a few meetings this afternoon :-/) 14:11:51 pkoniszewski: that's fine, personally I just think we do not have critical bug if no-one can verify that the fault exists 14:12:17 so the person marking the priority should at least verify that the bug is valid and indeed causing the issue 14:12:18 I'm going to look there too 14:12:40 pkoniszewski: not for you only, that's for everyone 14:12:52 yeah, it would be okay to mark it confirmed by the reporter if the verification is done on the automation system like jenkins. So, please paste a link to the review and the console logs where you see the failure and mark it confirmed 14:13:36 Ok, moving on.. 14:14:00 #optic py-client 0.17.1 14:14:17 #topic py-client 0.17.1 14:15:16 #link https://pypi.python.org/pypi/python-glanceclient/0.17.1 14:15:36 thanks Nikhil. 14:15:51 That was released yday to get it included in RC2. We are hoping that it does not break any other package and then include it 14:15:58 Is going to be in global requirements? 14:16:04 ^ 14:16:06 Should I mark my stable global-requirements patch not-WIP now? 14:16:12 mfedosin: nope 14:16:24 Doug -2'd it already 14:16:36 mclaren: I think that would be good to do it from your side (if not already) 14:16:45 jokke_, oh... why? 14:16:56 The same reason as above 14:17:05 We are hoping that it does not break any other package and then include it 14:17:20 There have been some issues with libraries breaking packages recently 14:17:43 mfedosin: apparently the risk breaking something by touching the requirements at the moment is too high to wait that the projects gets it rolled in before cutting RC23 14:17:57 -21 ;) 14:18:07 and folks have worked hard to get things to a stable state. Once everything looks good Thiery is going to decide. 14:18:35 Any other questions? 14:18:36 So should I wait until Doug removes the -2 before doing anything? 14:19:07 mclaren: I think you can lift your wip so you won't be blocking it when the time comes to merge it 14:19:13 == jokke_ 14:19:17 Ok, I'll do that. 14:19:35 Thanks. 14:19:35 Can you clarify when it's likely to merge? ie before kilo? 14:19:40 yes 14:19:42 or after? 14:19:47 before, ok 14:19:49 thanks 14:19:54 if things go all good, we will have it in RC2 14:20:06 We are working on probabilities though 14:20:20 and it looks ~1 atm 14:21:10 #topic Swift driver: 401 issue in ChunkReader 14:21:31 Hi again, folks, I want to discuss with you a known issue with uploading big files (>5 Gb) to Swift. 14:21:49 As you know glance_store driver has its own implementation of big files chunking. 14:22:01 https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/swift/store.py#L503 14:22:27 The problem is Keystone token may expire during the uploading and when we want to put another chunk to Swift we get 401 response. 14:22:41 And it's a serious headache for our customers who can't store big images there. 14:23:10 I'm not so familiar with Swift. So, may I ask you, what was the point of having our own implementation of Swift Large Objects and why we just can't use SLO directly? 14:23:38 Can I answer a question with a question? 14:23:58 Is there a reason SLO will help here? 14:24:43 I think yes, as far as I understand SLO 14:24:49 mclaren: well, in this case you will have a single call to swift 14:25:06 ah, I see 14:25:22 the problem, as far as I can see, is the token expiring at some n-th iteration of the chunk reader 14:25:36 and chunking will perform via Swift tools, not Glance's 14:25:45 So we use static large objects currently 14:26:07 oops, we use dymanic large objects currently 14:26:11 at least by documentation it's multiple calls to swoft 14:26:15 swift even 14:26:31 we may either fix it by re-connecting to swift on every chunk (which is a bit ugly), or make a single call and let the swift do the cunking for us 14:26:33 is your proposal to switch to static large objects? 14:27:01 Actually, let me talk to some Swift folks so I can comment more intelligently on this :-) 14:27:07 Half-serious question: "Why not both?" (and allow operators to configure it as they need) 14:27:15 mclaren: can you loop me into thos? 14:27:18 *those discussions? 14:27:41 I also think some deployers might have disagreement on the swiftclient SLO functionality and it's bandwidth utilization: 14:27:44 This would split the large_file into 1G segments and begin uploading those segments in parallel. Once all the segments have been uploaded, swift will then create the manifest file so the segments can be downloaded as one. 14:27:47 sigmavirus24_awa: I can give you a summary (I'll be talking to the guy beside me :-)) 14:27:58 ^^ that is from swift docs 14:28:12 mclaren: hah 14:28:44 I know the token expiration issue has been around for a while, so removing it would be more excellent 14:28:50 more/most 14:29:02 ++ 14:29:16 The token expiration will still remain an issue at v1 14:29:17 ativelkov: mfedosin this is with the multi-tenant store? 14:29:24 followed by intelligent use of user token to save image in the DB ;) 14:29:52 nikhil_k: yes, that's what I mean by v1: we still need the token to do the call to registry to change the state 14:29:53 it doesn't matter, single and multi use the same 'add' 14:30:06 mclaren: afaik that is single in our cases 14:30:19 but multi-tenant will have the same issue 14:30:33 but the single-tenant store can just request a new token? (I'm missing something -- sorry) 14:30:54 he wants to avoid that retry 14:30:57 mclaren, yes, in single case it's easy to fix 14:30:59 at specified intervals 14:30:59 mclaren: yes, it can, but it does not do it, as it establishes a single connection for all the chunks and then reuses it 14:31:22 ok, thanks 14:31:30 https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/swift/store.py#L490 14:31:57 that should be fairly easy to fix for single tenant then? 14:32:03 here, it makes a connection and then uses it for all the chunks at line 526 14:32:12 536* 14:32:18 yes, it should be 14:33:27 for multi-tenant the problem is harder to fix, but we may try to refresh the token on every iteration 14:33:42 But why we just can't send big object there and remove code in 'else' part? https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/swift/store.py#L503 14:34:19 ativelkov: mfedosin propose a spec? 14:35:02 mfedosin: so we ignore the swift object size limit and let swift reject them? 14:35:32 swift won't reject them 14:35:45 jokke_: why will it reject them if SLO is enabled? 14:36:02 we uploaded files via swift client with 150G size and everything was fine 14:36:18 http://docs.openstack.org/developer/swift/overview_large_objects.html 14:36:44 it seems to be the client doing the splitting 14:36:44 ativelkov: 'we may try to refresh the token on every iteration' - interesting - how? 14:37:24 need some logic in glance for that 14:37:31 server 14:37:55 mclaren, keystone supports this feature 14:37:57 are trusts helpful here in any way? https://wiki.openstack.org/wiki/Keystone/Trusts 14:38:20 mclaren: keystone's authenticate API call may use existing (non-expired) token to issue a new one 14:38:31 no, trust won't help, but refreshing the token is a good solution 14:38:49 http://developer.openstack.org/api-ref-identity-v2.html#authenticate-v2.0 14:38:50 ativelkov: I didn't know that! Do both tokens continue to be valid? 14:39:26 mclaren: that's the question. May be, may be not 14:39:46 Ok, now I need to talk to some keystone folks too :-) 14:41:19 my keystone guys says it should bot expire 14:41:29 should not 14:41:47 ok, that sounds very promising 14:41:55 hmm-m ... did I get this right ... we can request a new token that is valid over the current tokens validity with the curren token? 14:41:58 mfedosin: trusts may help as well, but that's a bit an overkill 14:42:13 there's some overlap 14:42:21 I think one hour 14:42:30 jokke_: i don't think that we can do that - i think you can only rescope a token within the same expires 14:42:56 Ok, we need to get moving here.. 14:43:09 hmm, ok, I'll try to get a second opinion from keystone 14:43:27 Let's create a spec/etherpad/session proposal or soemthing and let's discuss there. 14:43:42 mclaren, thanks, it'll be good 14:43:42 dstanek: I would expect so ... if not the expiry is pretty much pointless ... but yeah I think the trust approach would be the correct one as it's designed for these use cases 14:44:23 #topic Open Discussion 14:44:50 Any thing that needs urgent attendion? (and was not on the agenda) 14:45:24 Again shout for people to put summit topics in! 14:45:47 If not, please take a look at the current proposals.. 14:45:52 #link https://etherpad.openstack.org/p/liberty-glance-summit-topics 14:46:07 not urgent but couple of stable branch reviews https://review.openstack.org/#/q/project:openstack/glance+branch:stable/kilo+status:open,n,z 14:47:19 thanks mclaren , those seem important 14:47:51 About the topics, I would encourage everyone to consider something they want discussed as the topic and that way we can prioritize the cycle better 14:48:31 I don't think this bug was in RC https://bugs.launchpad.net/glance/+bug/1445827 14:48:31 Launchpad bug 1445827 in Glance "unit test failures: Glance insist on ordereddict" [High,In progress] - Assigned to Stuart McLaren (stuart-mclaren) 14:48:31 I think v2 nova support is probably important, but does it warrant a session? 14:49:16 It should not be the case that only a spec is proposed and there are ton of other things lined up, even for an important discussion. 14:49:37 mclaren: I hadn't expected it would need a session 14:49:42 mclaren: Nova usually have one session that deals with images modules 14:50:09 we can discuss it there if needed but I think we covered the base (pretty much) in the mid-cycle 14:50:17 sure 14:50:34 thanks jokke_ 14:51:22 We shall plan to have a priority impromptu meeting sometime the week after next 14:51:45 and in the week prior to the summit, we should plan to have a video call 14:51:50 Details to be sent out soon 14:52:06 Once rc2 is cleared and things look stable) 14:53:36 So, again request for session proposals. Please add an entry for something that you need to be discussed and should be on the roadmap for Liberty 14:53:50 #info Please add an entry for something that you need to be discussed and should be on the roadmap for Liberty. 14:54:00 If nothing else ... 14:54:56 Thanks all! 14:55:00 #endmeeting