17:00:12 #startmeeting nova_cells 17:00:13 Meeting started Wed Oct 7 17:00:12 2015 UTC and is due to finish in 60 minutes. The chair is melwitt. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:16 The meeting name has been set to 'nova_cells' 17:00:25 anyone around for cells today? 17:00:31 o/ 17:01:12 ping bauzas 17:01:30 #topic open discussion 17:01:58 o/ 17:02:00 I have some questions 17:02:02 we'll just do open discussion today 17:02:07 :) 17:02:32 when can we resubmit the spec again for the flavors? 17:03:03 I think you can do that now, but I thought I saw one already re-approved 17:03:18 * bauzas waves lately 17:03:33 oh great, maybe lalitd? 17:03:38 I'm looking for it 17:03:58 this one? https://review.openstack.org/#/c/231858/ 17:03:59 yes its regarding https://review.openstack.org/#/c/213041/ 17:04:31 great... miss communication between us. sorry 17:04:56 cool, just wanted to make sure there wasn't another flavors one you were talking about 17:04:58 mmm, the spec is approved for mitaka ? 17:05:06 I see it merged 17:05:13 melwitt: the patch is passing all unit and functional tests but still problem in grenade and tempest tests 17:05:52 bauzas: is there something that you would like to change? 17:06:01 belmoreira: nope just asking 17:06:29 lalitd: ping me around 6.30pm UTC, I'll look at the grenade job 17:07:48 bauzas: thanks but it will be 12:00 AM in india :) 17:08:01 lalitd: then tomorrow afternoon your time 17:09:26 okay, moving on ? 17:09:53 sure. anyone have any other topics? 17:09:56 so, now that we have mitaka open, we should discuss on the features we want to implement 17:10:13 I'm just looking at the specs 17:10:39 john just approved that.. 17:11:22 I know that alaski_out was thinking about rewriting https://review.openstack.org/#/c/214792/ 17:12:42 so we have the persisting spec 17:12:43 bauzas: can we meet tomorrow at same time 1030 IST ... 17:13:03 tomorrow afternoon some of my office meeting is there 17:13:32 lalitd: too early for me (CEST) 17:13:42 lalitd: but I'll look at your change tonight 17:14:26 anyway, so my point is about the mitaka design summit and see whether we need to discuss on something not already accepted 17:14:31 melwitt: thoughts on that? 17:15:46 well, one thing I was wondering recently is, are we going to be migrating everything to the api db and do we need specs for every piece of that? 17:16:15 melwitt: if we use the objects, I don't think so 17:16:25 since it could be a live migration 17:16:36 bauzas: thanks , ok then I will ping you at 6:30pm UTC 17:16:39 I mean an online migration 17:17:05 lalitd: nevermind 17:17:13 bauzas: I was thinking of the schema migrations, creating the tables in the api db 17:17:46 melwitt: then a spec is needed I guess 17:17:58 melwitt: but we could ask johnthetubaguy 17:18:11 I setup devstack the other day and so far we have cell_mappings host_mappings instance_mappings in the api db 17:19:02 melwitt: right, that still leaves the global tables like aggregates to move on 17:19:03 melwitt: then what will happen to old migration scripts which are part of patches 17:19:11 just for info 17:20:49 lalitd: what do you mean by the old migration scripts? 17:20:50 melwitt: anyway, I guess we should still consider what to move, and that's why some specs could be needed 17:21:34 melwitt: I'm also concerned by the online data migration and the contract action 17:21:52 melwitt: so, I think you made a very valid point 17:22:50 bauzas: yeah, me too. I'm not clear on what we need to do here. I thought we're going to have to add the global tables to the api db and not sure how to start that, other than the flavors patches we already have going on 17:24:08 melwitt: in patch https://review.openstack.org/#/c/201606/14 it includes migration script like https://review.openstack.org/#/c/201606/14/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/004_flavors.py , is it same ? 17:24:10 melwitt: so we need to prepare ourselves to follow the story 17:24:11 and also when the global tables need to be added. that is, is the goal to get a simple nova boot working with a single cell before we get all the global api tables done? 17:24:32 melwitt: that's my thoughts, one single cellsv2 with a single boot 17:24:57 bauzas: right, but is getting all the api db tables done a prerequisite? I'm not clear on that 17:25:35 I was starting to think of all the build steps, "save X in the api db", "pick a cell to schedule", "save Y in the cell db" and those interactions 17:26:12 melwitt: well, for one cell, sure you don't need that 17:26:29 melwitt: but you should still have that done at one moment 17:26:45 bauzas: okay, I think that was my misunderstanding 17:26:49 melwitt: the scheduling bits are the ones that are a bit worrying me for Mitaka 17:27:31 bauzas: any updates on scheduling? 17:27:36 melwitt: given our upgrade process, I'd be far in favor of doing the migrations earlier than later 17:27:38 is alaski handling those? 17:28:02 lalitd: yeah, I was trying to say we'll need more of them, one for each of the other global tables 17:28:13 melwitt: while the scheduling bits are just an API contraxt 17:28:15 contract 17:28:29 vineetmenon: it's not tracked for the moment 17:28:39 melwitt: okk 17:29:28 vineetmenon: tbc, http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/cells-scheduling-interaction.html is the only one we merged 17:29:32 bauzas: yeah, true 17:29:54 bauzas: so still a long way to go.. 17:30:26 vineetmenon: and only a few resources yeah you got it 17:31:26 so, I'd say for mitaka 17:31:36 - db migrations 17:31:45 (incl. flavors) 17:32:02 - scheduling bits given in http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/cells-scheduling-interaction.html 17:32:08 +1 17:32:12 ... and that's basically it 17:32:24 keep it simple 17:32:48 that sounds good to me 17:32:49 because 17:33:02 for db migrations, we need to do as a best effort wayt 17:33:26 for scheduling bits, we need to land the spec object usage + persist it + doing the above spec 17:33:39 just by saying the above, that's already pretty pedantic 17:35:03 in other words, I don't more work than the current planned ones 17:35:08 I don't see* 17:35:31 we just need to make sure that all the existing specs are mitaka-approved 17:35:57 and we should consider some new specs for the global tables we consider needing to be moved to the api db 17:36:11 agreed 17:36:29 +1 17:36:41 okay 17:36:48 I'll need to jump off for a bit 17:36:55 any other topics today? 17:36:58 but I'll be back in a few 17:37:06 wonders if he can answer a question? 17:37:12 melwitt: something about a spec? 17:37:37 johnthetubaguy: it was about some db migrations we need to land 17:37:56 since that's db migrations, that requires a spec AFAIU 17:38:02 johnthetubaguy: oh, we were just talking about the cells api db global tables. if we'll need a spec per global table migration, I assumed so 17:38:14 we usually require a spec for those, mostly just so operators have a chance to tell us we are crazy 17:38:16 like we did for the flavor bits 17:38:22 we were thinking about what are the specs we still need t owrite 17:38:31 cool 17:38:41 that's why I feel a spec by table isn't overkill 17:38:48 so feel free to group them, if thats more efficient 17:38:52 becuase we could argue per table 17:39:02 but we could ask for specific fast-approval 17:39:39 again, my main worries are not about the expand bits 17:39:46 so its easier for me if there is one big one that gets done quickly-ish, but I am open to ideas 17:39:52 rather the online data migration and the contract bits 17:40:09 I feel we can discuss that somewhat later with ala 17:40:11 alaski_out: 17:40:13 heh 17:40:26 yeah. at least so far, with flavors we have the expand and the online migrations in the same spec series 17:40:27 I would focus on the regular migrations, and make sure they are purely addative 17:40:30 that's not super urgent 17:40:43 oh, wait, online data migrations right? 17:40:47 the contract, I don't think we're covering at all at this point 17:41:01 johnthetubaguy: sure, but that would still leave an open question about the existing data 17:41:23 johnthetubaguy: eg. if we move the aggregates table 17:41:31 any online migration needs a nova-manage command to do the migration, with a throttling param 17:41:40 yeah that 17:42:02 I need to drop off now 17:42:03 ttyl 17:42:13 seeya bauzas 17:42:26 johnthetubaguy: that's a good reminder 17:42:35 by bauzas 17:42:38 yeah, its is an interesting one, so we have a servers table in the API cell now I guess? 17:43:42 we are assuming folks add the API database I guess, I wonder if we should add the child cell database, that could well be stupid 17:44:11 johnthetubaguy: no, instances will be in the cell db. and in the api db will contain mappings 17:44:51 johnthetubaguy: the current state of the api db has only tables: cell_mappings, host_mappings, instance_mappings 17:45:09 so I have a feeling alaski was having another idea for the initial create 17:45:27 having a full instance record, then doing a move to the cell, and deleting it from the API at that point 17:45:52 so a swap for a full record to a mapping, so its still only ever in one place at once 17:45:59 the request spec is supposed to act that way 17:46:23 yeah, he may have changed his mind about changing his mind 17:46:34 sorry, just thinking out loud really 17:47:01 I might be wrong :) I need to consult with alaski again 17:47:19 ha 17:47:32 me too 17:47:33 johnthetubaguy: in https://review.openstack.org/#/c/213041/ patch for flavor migration a new option is added in file https://review.openstack.org/#/c/213041/18/nova/cmd/manage.py 17:48:17 lalitd: yeah, that looks good 17:48:34 anyways, didn't mean to extend the meeting, honest! 17:48:45 cool 17:49:08 johnthetubaguy: it's cool, glad you joined :) 17:49:21 back to the other bit, feel free to submit the specs in whatever way is easiest, let me know what works for you all 17:49:54 johnthetubaguy: will do, thanks 17:49:54 cool.. thanks for joining johnthetubaguy 17:50:00 it sounds like a spec that just has a list of tables that will be copied into the APi database would do the trick :) 17:50:15 no problems 17:50:24 cool 17:50:47 anything else today? 17:50:47 so I should really go an cook my dinner, before I have to head off to my tuba/brass band rehearsal! 17:51:06 thanks for keeping cells stuff moving forward all, great stuff! 17:51:16 johnthetubaguy: nice, have fun 17:51:47 okay, guess that's it. thanks all! 17:51:55 #endmeeting