Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-11
22:25:17 mriedem sure
22:25:33 mriedem my understanding of this thing is it's for the REST API to pull these audit logs which ceilometer consumes
22:25:57 zzzeek mriedem: right, but the DB size is never mitigated
22:25:59 mriedem http://developer.openstack.org/api-ref/compute/#server-usage-audit-log-os-instance-usage-audit-log
22:26:02 mriedem zzzeek: nope
22:26:21 mriedem neither is...anything except for nova.tags and anything in the nova_api db
22:26:34 zzzeek mriedem: and...not anytime soon, but people might someday like that DB tables like these don't grow to be billions of rows? or that's how they want it
22:26:36 mriedem all of the old tables in the nova db use the soft delete mixin
22:27:09 zzzeek mriedem: right but task_log seems to be, accumulate rows just for doing things, so it's a fast grower
22:27:11 mriedem zzzeek: i think most operators have their own purge scripts, i know there are some in the osops tooling repos
22:27:16 zzzeek mriedem: OK
22:27:32 mriedem there was a bp at one point to add a purge cli to nova
22:27:44 mriedem for not archiving, no shadow tables, but delete things over a certain age
22:28:02 mriedem last i remember someone from red hat was looking into implementing that
22:28:07 mriedem i'll try to find it
22:28:36 mriedem zzzeek: v
22:28:37 mriedem https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/purge-deleted-instances-cmd.html
22:29:23 mriedem ^ only addresses instances though, so that'd have to be tweaked to handle task_log
22:29:33 mriedem or to add something to nova to self-clean that table
22:29:44 mriedem like only keep audit logs under a certain age
22:30:55 openstackgerrit Jay Pipes proposed openstack/nova: placement: create aggregate map in report client https://review.openstack.org/407309
22:32:59 mriedem zzzeek: what's even funnier/sadder about that thing,
22:33:22 mriedem zzzeek: is the periodic task emits a notification, which someone (ceilometer) is consuming and probably throwing that data into a time series db
22:33:36 mriedem so nova storing it is probably much less relevant, except for nova's own REST API
22:34:52 zzzeek mriedem: im on a search to figure out how big people's databases might be reasonably getting
22:35:23 openstackgerrit Dan Smith proposed openstack/nova: Make metadata server know about cell mappings https://review.openstack.org/417962
22:35:24 openstackgerrit Dan Smith proposed openstack/nova: Multicell support for instance listing https://review.openstack.org/396775
22:36:24 mriedem zzzeek: at one point not too long ago dansmith had a fairly large db for testing the archive command
22:36:38 mriedem dansmith: did that have task_log stuff in it?
22:36:53 dansmith mriedem: probably
22:36:56 dansmith it's in a bug somewhere
22:37:03 mriedem mikal might be able to get his hands on some large db with task_log in it since that feature was all added by rax people
22:37:06 dansmith the dump I mean
22:37:39 mriedem zzzeek: or jhesketh
22:38:18 mriedem if i had 1% more energy right now i might email the operators list asking if anyone uses the nova REST API for this feature
22:39:19 zzzeek mriedem: yeah i can manufacture fake large DBs with a script here am more wondering, if i went into the nova DB of some huge customer, how big would these tables be. because migrating from mariadb5.5 -> 10.1 requires a dump+ restore
22:39:35 zzzeek and for tens of millions of rows it's a hit
22:40:00 mriedem zzzeek: so i'd ask jhesketh b/c he has some large dbs for just that kind of question
22:40:12 mriedem zzzeek: otherwise we'd have to ask some godaddy or cern people probably
22:40:20 zzzeek mriedem: thanks
22:46:51 mriedem dansmith: so i guess on https://review.openstack.org/#/c/416585/ we have some kind of weird catch-22 because the cellsv1 job fails on that patch, but passes on your nova one that uses that
22:47:07 mriedem http://logs.openstack.org/85/416585/8/experimental/gate-tempest-dsvm-cells-ubuntu-xenial/e9f1fe9/console.html#_2017-01-11_19_25_38_191005
22:47:42 dansmith mriedem: we might be able to merge the nova patch before the devstack one, if you want to try
22:47:49 dansmith or we just queue the nova one up and let the devstack one gate it, which I think is probably fine given the stability of things right now
22:47:50 dansmith your call
22:48:00 dansmith I needed the depends-on to test them together
22:48:13 mriedem so we don't need the depends-on to make the nova one pass?
22:48:21 dansmith I don't know
22:48:25 dansmith we might not
22:48:27 dansmith probably don't
22:49:09 mriedem ok, well the cells v1 job is gating of nova and other repos (not devstack though sadly) so if we land the devstack change first, it's going to break things until the nova one lands
22:49:18 mriedem s/of/on/
22:49:21 openstackgerrit Sarafraj Singh proposed openstack/nova: Add service_token for nova-glance interaction https://review.openstack.org/412634
22:49:50 dansmith yeah, but we can get them both in the gate together
22:49:58 dansmith but I'll remove it and let is run to see
22:50:22 mriedem ok
22:51:12 openstackgerrit Dan Smith proposed openstack/nova: Multicell support for instance listing https://review.openstack.org/396775
22:51:12 openstackgerrit Dan Smith proposed openstack/nova: Make metadata server know about cell mappings https://review.openstack.org/417962
22:51:13 openstackgerrit Dan Smith proposed openstack/nova: Don't bypass cellsv1 replication if cellsv2 maps are in place https://review.openstack.org/418141
22:56:24 openstackgerrit Sujitha proposed openstack/nova: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185
22:58:54 openstackgerrit Sujitha proposed openstack/nova: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185
23:00:52 openstackgerrit Claudiu Belu proposed openstack/nova: Hyper-V: Adds vNUMA implementation https://review.openstack.org/282407
23:07:14 openstackgerrit Claudiu Belu proposed openstack/nova: Hyper-V: Adds vNUMA implementation https://review.openstack.org/282407
23:07:49 claudiub|2 well, i'm out. thanks for the reviews!
23:09:52 mriedem zzzeek: http://lists.openstack.org/pipermail/openstack-operators/2017-January/012425.html
23:10:56 zzzeek mriedem: wow thanks!
23:20:45 openstackgerrit Sujitha proposed openstack/nova: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185
23:29:33 openstackgerrit Jay Pipes proposed openstack/nova: Expose a REST API for a specific list of RPs https://review.openstack.org/392569
23:30:44 jaypipes edleafe: good pickup on the location of the except block in https://review.openstack.org/#/c/392569/. Pushed a fix for that. Please re-review at your earliest.
23:31:01 jaypipes mriedem: ^ is mostly written by me so I don't want to +2 it.
23:31:13 jaypipes if you and dansmith could tackle, that would be great.
23:32:27 mriedem jaypipes: yeah it's on my list, would also like alex_xu and sdague to look
23:33:43 jaypipes mriedem: thx
23:33:58 jaypipes mriedem: going through the feature freeze review list now, trying to get reviews done.
23:36:29 mriedem cool we've made some solid progress today, 1 merged and have 3 in the queue
#openstack-nova - 2017-01-12
00:02:56 dansmith mriedem: passed the cells job but failed something else, probably unrelatedly
00:39:05 mriedem so apparently my foundation membership has lapsed b/c i haven't been voting in board of directors elections,
00:39:20 mriedem is there an easy way to get my membership back or i just need to do the initial sign up stuff all over again?
00:41:11 mriedem can i be ptl if i'm not a foundation member? i'm pretty sure i'm breaking some laws right now.
00:48:58 mriedem ooo i'm back in
00:49:08 mriedem EmilienM: https://review.openstack.org/419217
01:36:20 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova: Deny invalid flavor extraspec for cpu_policy https://review.openstack.org/406377
01:55:10 openstackgerrit Matt Riedemann proposed openstack/nova: Hyper-V: Adds vNUMA implementation https://review.openstack.org/282407
01:59:10 tovin07 johnthetubaguy, mriedem, could you review this one https://review.openstack.org/#/c/254703/ ? patch in novaclient is OK now. Thank you!
02:03:12 EmilienM mriedem: thanks!
02:13:49 mriedem tovin07: probably not tonight
02:13:56 mriedem but it's on the list
02:14:20 mriedem dansmith: looks like my series of backports for the scheduler report client in newton are going to be needed after all for ironic https://review.openstack.org/#/c/416734/
02:14:26 tovin07 mriedem, thanks!
02:14:26 mriedem ^ was failing before the depends-on
02:14:40 mriedem which pulls in this whole series https://review.openstack.org/#/c/416762/
03:14:35 alex_xu diana_clarke: yea, agree with you , we need better error message. At least the "query parameter 0" confuse user. I guess "0" due to the input are array type.
03:25:49 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: Better black list for py35 tests https://review.openstack.org/419250
03:32:36 mriedem dansmith: we should talk to vladikr about this tomorrow https://review.openstack.org/#/c/405948/
03:32:41 mriedem i don't want to forget about that one
03:35:23 vladikr mriedem, I'm here - I'm try to re-implement it all with storing the vlan in info_cache - having some issues with that though.. that's why I didn't update yet
03:35:48 mriedem vladikr: ok yeah i assumed you'd need to see how that change makes the rest of the series behave
04:01:49 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add a decorator to reject know bad filters. https://review.openstack.org/419256
04:39:41 openstackgerrit zhangyujun proposed openstack/nova: Use JSON-Schema to validate bdm https://review.openstack.org/418654
04:43:10 openstackgerrit zhangyujun proposed openstack/nova: Use JSON-Schema to validate bdm https://review.openstack.org/418654

Earlier   Later