22:00:42 #startmeeting nova_cells 22:00:42 Meeting started Wed Jan 21 22:00:42 2015 UTC and is due to finish in 60 minutes. The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:46 The meeting name has been set to 'nova_cells' 22:00:51 \o 22:01:04 hi, who's around for the meeting? 22:01:06 o/ 22:01:35 hi 22:01:56 I know dansmith is out in the wilderness 22:02:27 I'm actually just going to go into open discussion this week 22:02:32 I don't have a prepared agenda 22:02:39 #topic open discussion 22:02:54 erm 22:03:15 bauzas: do you have an update on test exclusions? 22:03:29 alaski: I was about providing a change 22:03:41 alaski: I will keep the template and do a conditional for it 22:03:57 alaski: I will CC you on the patch 22:04:10 great 22:04:24 I would like to get sdagues take on it as well 22:05:09 sure, to be clear, I did some templates for another stackforge project, but that's the first time I'm diretly working for that here 22:05:18 alaski: tbp https://github.com/openstack-infra/project-config/blob/f98caac794f6d1327cb7565c446c026cc951a873/jenkins/jobs/devstack-gate.yaml#L792-L837 22:05:33 alaski: I will provide a if conditional checking the pipeline 22:05:51 alaski: and if pipeline being 'check', it will add some exceptions 22:06:14 o/ (late) 22:06:25 bauzas: okay 22:06:29 alaski: of course, I'll rename existing experimental jobs to exp-tempest-dvsm-cells 22:06:46 I'm tempted to say that we should just run one job with all of the exceptions 22:07:01 alaski: then that's easier 22:07:20 alaski: but we won't have any way to check if we fix the regressions 22:07:26 it won't entice anyone to work on fixing any tests, but that hasn't really been happening anyways 22:07:43 alaski: up to you actually 22:07:47 well... I have started running tempest with cells locally and taking down the cause for each failure in the same style as alaski had done, with the latest list of failures (I get 74 when running locally). then next I'll compare with the old failure list and also see if I can fix any of them 22:08:03 melwitt: awesome 22:08:04 melwitt: orly ? 22:08:25 melwitt: interesting in getting your local list of failures 22:08:46 I'm updating https://etherpad.openstack.org/p/nova-cells-testing as I go along with my findings 22:09:31 melwitt: cool 22:09:50 melwitt: very nice 22:10:02 alaski: ok, will then only update the current template by adding the 74 exceptions and will enable the test in non-voting check pipeline 22:10:33 if we need to have a CI reporting all the issues, we could add another conditional later 22:10:43 bauzas: I think that might be good for now, we'll just have to reduce the exclusions in two steps then 22:10:56 fix in nova, then remove from devstack regex 22:11:09 alaski: yup 22:11:25 ok, working it now 22:11:27 melwitt: The flavor 42 could not be found failures are interesting, I thought that issue was fixed 22:11:31 that's really easy 22:12:05 alaski: yeah, I don't really understand all of this yet (not a cells expert) but it's the m1.nano flavor is in the top level instance_types table but not the nova_cell instance_types table 22:12:51 bauzas: cool, thanks 22:13:17 melwitt: oh. that's a slightly different issue then 22:13:34 when flavors are added via the api they aren't replicated to the cell db 22:14:06 alaski: okay. there's another one that puzzled me, it behaves as though region!child@1 is supposed to be the key value for an attr on compute node. but I don't find that encoded name anywhere in the db, even though from the code it has to have got it from there? 22:14:27 melwitt: that issue is interesting 22:14:28 alaski: ah, okay. so if tempest is adding via api, they need to add to cell api too? 22:15:13 melwitt: right, but there isn't a mechanism for doing that today 22:15:40 we could fix the API calls so they route through cells properly, but it's not an insignificant effort 22:15:57 hm, okay 22:16:25 those might be better skipped for now, but if someone wants to fix that it would be great 22:16:37 for the other issue take a look at the code around https://review.openstack.org/#/c/145362/2/nova/compute/cells_api.py 22:17:20 melwitt: essentially the cells api layer is adding routing information to the compute_node.id. it's not actually in the db, just returned via the api 22:17:47 alaski: oh, thanks! 22:18:15 melwitt: np. I guess it actually happens a layer lower than that, but that's essentially it 22:19:00 yeah, helps a lot to know where to start looking either way 22:19:08 so from my end I've been working on having nova-manage work with two databases 22:19:13 melwitt: definitely 22:19:50 I have a lot to learn about oslo.db and sqlalchemy to figure out the right way to work with multiple databases 22:20:42 alaski: is this really difficult ? 22:21:20 bauzas: I don't think it will be difficult, there seems to be support in sqlalchemy for this. It's mainly me understanding it 22:21:35 and getting it setup properly in nova and oslo.db 22:22:16 and not having as much time as I want :) 22:22:19 alaski: it's great to know... we started looking as well and doesn't seems trivial 22:23:02 alaski: I'm saying that because there is a sql_connection opt to be done 22:23:08 one thing I don't understand yet is whether we can dynamically add new databases to talk to, or if a restart will be required 22:23:50 belmoreira: definitely not trivial, but I think it's mostly a matter of finding the right places to configure it 22:23:53 alaski: at least you need to setup DB 22:24:16 bauzas: right 22:24:34 alaski: so if you're using a CONF object, then you need to restart 22:24:41 so one question I have is what are peoples thoughts on naming of the dbs 22:24:51 because the CONF object is not live changing 22:25:09 right now everything assumes one db and is named just sql_ something or db_ something 22:25:26 I've been adding api_sql_ and api_db_ stuff 22:25:33 IIRC, you have a SQL connection string to provide 22:25:45 including the creds and the DB name 22:26:00 bauzas: we decided to put that in a db right? 22:26:10 the dynamic ones 22:26:15 alaski: right, just talking about how it can work 22:26:29 oslo.db is using a sql_connection opt IIRC 22:26:51 right, I'm still detangling some of that 22:26:58 so, that sounds possible to dynamically change this 22:27:08 alaski: yes... but in all_in_one deployments will we need at least 2 nova.conf 22:27:36 you just need to not use this opt, and provide the sql connection when instantiating the DB API implementation 22:27:40 belmoreira: I think so, like we have today 22:27:59 belmoreira: that's already manageable per service 22:28:20 bauzas: right, that's what I'd like to see. But there's a lot of strangeness in how things are configured in oslo.db right now 22:28:24 belmoreira: I mean, oslo.config is allowing you to specify a conf file per service name 22:28:57 belmoreira: so assuming the cells service won't have the same name than the child service, it should be fine 22:29:05 at one point I think a config option is being populated in the code passed on args passed in 22:29:29 bauzas: great... I'm thinking how complex it can be to have a simple all_in_one devstack running 22:30:08 alaski: that depends if it's a cli_opt 22:30:41 depends on, (of course) 22:31:42 bauzas: it's not even that, the way that the backend for migrations is looked up is done like that. It reads it from a config option that isn't actually defined as an option to be read from cli/conf file that I can see 22:32:14 it's just magically created at some point in the back and forth between nova and oslo.db 22:33:06 but I'm working my way through it all for now 22:33:53 alaski: oh I see your question 22:34:16 alaski: that's an oslo.db option 22:34:29 IIRC of course 22:34:34 AFAIK 22:35:02 (well, I was using the oslo incubator a while ago, maybe things changed since that) 22:35:25 I didn't find it in there. But I think I just need to get in touch with an expert over there and ask some questions 22:35:49 any other updates or things to discuss today? 22:36:20 continuing DB discussion 22:36:59 we will need to have two different nova.db.apis 22:37:20 one for each DB 22:37:35 right 22:38:06 we may be able to work with objects so that we don't end up with another giant db.api type file 22:38:15 alleliuah 22:38:23 but whatever we end up with will be separate from the current db.api 22:39:06 that said, using objects doesn't necessarly means we can get rid of a big giant DB API 22:39:24 it only allows us to hide the conductor methods right ? 22:39:48 I'm not sure at this point 22:40:03 I think Dan had a plan to move the db calls into the objects, or closer to them 22:40:15 I'll ask him about it next week 22:40:19 alaski: yeah I remember that disussion 22:40:26 alaski: +1, will be at midcycle too 22:40:33 great 22:41:11 alaski: IIRC the discussion was about the number of save() calls in the objects which was not efficient 22:41:12 belmoreira: was there more you wanted to discuss? 22:41:54 bauzas: yeah, that would be good to address 22:42:44 alaski: we are looking into the same things that you mentioned... it will be good to share 22:43:18 belmoreira: ok, good to know 22:43:48 definitely don't want to duplicate work if we don't need to 22:45:01 belmoreira: I'm out basically all next week for the mid-cycle and travel, but I'll get in touch when I get back 22:45:14 anything else from anyone? 22:46:31 alright, I'm going to call it then 22:46:44 thanks everyone! 22:46:51 thanks 22:46:55 #endmeeting