Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-02
20:14:39 mriedem ok it looks like this quota limit is per project/user
20:15:32 mriedem so by default you can have 5 files, at 10mb each
20:15:45 mriedem wait, no
20:15:46 mriedem kb
20:17:10 sean-k-mooney mriedem: yes it is. userdata however is handeled seperatly from that limit today
20:18:17 mriedem right, there is no quota limit on user_data
20:18:20 mriedem it's just the limit in the db per instance
20:18:25 mriedem which is as you said 16MB
20:18:30 sean-k-mooney yes
20:19:04 sean-k-mooney we could change that in the future or mysql could be we dont have a contract in place with the end user on this today
20:20:32 sean-k-mooney having a qouta on this in the future would not nessicalily be a bad thing it is sotre on you db node after all so it could cause issues if allowed to grow too large
20:35:05 dansmith mriedem: are you aware of any cells-based short circuiting around InstanceMapping?
20:35:17 dansmith in the api_samples_tests
20:35:46 dansmith in looking at some of them, they create a server, which exists in the cell db, but we never set the InstanceMapping.cell_mapping for those
20:35:59 dansmith ISTR these were problematic with cells for some reason, but I can't really remember why
20:37:34 mriedem not really
20:38:13 dansmith ah, maybe it's SingleCellSimple that's getting me
20:38:25 mriedem i was going to say, i thought there was a fixture we used, but don't see where it's set
20:38:28 dansmith yasss
20:39:38 dansmith yeah, the wrinkle is that the api sample tests use singlecellsimple unlike the other functional ones
20:39:53 mriedem oh i'm looking at newton still, derp
20:40:27 mriedem If1138331f3a46f5aed87e898ce19879a787d435f
20:40:51 dansmith I added a new CellMappingList method and so I have to put that in the fixture or we always get back an empty list
20:47:48 mriedem we said at the ptg that if we deprecated personality files from the api, and you can specify personality files during rebuild, that we'd allow passing new user_data during rebuild, but i'm not sure if we should
20:47:56 mriedem i think we just allow passing personality files during rebuild b/c we don't persist them
20:48:05 mriedem so that was a hack workaround for the lack of persistence,
20:48:15 mriedem so i'm not sure we should allow passing user_data to rebuild just b/c personality is gone
20:48:24 mriedem sdague: remember that discussion? ^
20:48:54 mriedem cfriesen: ^ you might care since you seem to love rebuild
20:49:39 sdague mriedem: you are right
20:50:52 openstackgerrit Dan Smith proposed openstack/nova master: Add CellMapping.get_by_project_id() query method https://review.openstack.org/509002
20:50:52 openstackgerrit Dan Smith proposed openstack/nova master: Make get_instance_objects_sorted() be smart about cells https://review.openstack.org/509003
20:51:29 sdague mriedem: though, I think people were using that as an end run
20:51:37 sdague we can't update user_data on instances, right?
20:51:48 dansmith mriedem: ^ that's the last cellsv2 perf optimization I had in my head to consider it legit usable for queens
20:52:04 mriedem sdague: no you can't specify user_data during update
20:52:20 mriedem i don't really know if people are using personality files on rebuild as a workaround for missing user_data
20:52:26 mriedem i don't know how people use our apis really
20:52:36 sean-k-mooney jaypipes: after nested resouce providers lands would you have any objection to seperating https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py into a placement-lib repo so it could be imported by neutron/os-vif for the ovo neutron port binding work and bandwith based scheduling?
20:53:02 efried os-placement ftw
20:53:18 mriedem dansmith: are you going to run https://review.openstack.org/#/c/509003/ through your performance tests, compared to before/after that change?
20:53:28 mriedem but on top of https://review.openstack.org/#/c/505418/
20:53:38 dansmith mriedem: I'd have to have lots of cells to make any difference
20:53:52 dansmith so I wasn't really planning to, unless you just want to make sure it's not super painful or something
20:53:58 jaypipes sean-k-mooney: yes, I would. those objects are not intended for use by anything outside placement. That said, I think the /nova/scheduler/client/report.py code can be moved into a placement lib
20:53:59 mriedem dansmith: couldn't you measure the relative difference by just having 1000 instances in cell1, all ACTIVE?
20:54:06 mriedem that would exclude cell0 at least
20:54:46 dansmith mriedem: you're trading one one-row api db result for one empty cell0 result
20:54:47 dansmith so I doubt you'd be able to measure it
20:55:17 dansmith if you really want, I could just synthesize a bunch of cells with two tenants or something
20:55:21 sean-k-mooney jaypipes: ok the usecase was to be able to define a placement request and a placement allocation object that could be used between nova and neutron
20:55:58 jaypipes sean-k-mooney: yeah, that's report.py, not resource_provider.py :)
20:56:06 sean-k-mooney jaypipes: i originally taught of having them defined in os-vif but taught that felt a litle weired as they could be used in cinder
20:56:32 jaypipes sean-k-mooney: note that objects in nova/objects/resource_provider.py do NOT get sent over the wire, ever.
20:56:42 jaypipes sean-k-mooney: and we intend to keep it that way :)
20:57:42 sean-k-mooney but they do map to the structure recived from the rest api?
20:58:11 sean-k-mooney currently neutron is manipulating raw json responces which is a little annoying
20:59:58 sean-k-mooney actully that code look kind of like what neutron is doing but i was hoping we could have a singel place for it that both nova and neutron used so they dont get out of sync
21:01:54 sean-k-mooney jaypipes: https://github.com/openstack/neutron/blob/b1dd13abfb121ca2a3e1cebc6bc2cef4a056f401/neutron/services/segments/placement_client.py is basically a stripped down version
21:05:23 jaypipes sean-k-mooney: right, and I'm agreeing with you that it would be good to have a placement-lib repo that would store common code for callers of the placement API :)
21:05:44 jaypipes sean-k-mooney: I'm just saying that that common code is the scheduler/client/report.py code and not the nova/objects/resource_provider.py code :)
21:07:21 sean-k-mooney i am glad we are in violent agreement :) ya that make senese this is the same comment code that would be imported in osc
21:08:49 sean-k-mooney does it make sense to look at createing placement-lib after nested resouce providers or are there other api level changes to plaement in queens that we should also wait for
21:10:13 sean-k-mooney perhaps limit? that should be non invasive to add to the client code however so im less worried about that.
21:11:20 sean-k-mooney jaypipes: i just dont want the creation of placement-lib or os-placement to impact your other work, we can temporaily create the functions we need on the neutron side for now
21:12:06 jaypipes sean-k-mooney: sorry, what do you mean by limit?
21:13:05 sean-k-mooney cdent's spec for limits on the allocation candidates
21:14:58 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L325 would need a minor update to be able to pass the limit to the api.
21:21:05 jaypipes sean-k-mooney: oh, I see. well that would be a microversion that would be passed by the calling client.
21:21:32 jaypipes sean-k-mooney: so yeah, a minor change to the report.py client module and the similar code in mlavalle's code
21:22:50 melwitt mriedem: I think most of the quota limits (except fixed_ips, networks, floating_ips) can be set per project or per project and user. so quota_injected_file_path_length would be global to a deployment if it hadn't been set via the quota-sets update API
21:23:32 melwitt and AbsoluteResource just means that the resource usage isn't counted based on values stored in the database
21:24:30 melwitt the injected_file_path_length is evaluated on-the-fly when a request is made to verify that the requested injected file length is less than or equal to the quota limit
21:29:44 mriedem melwitt: so it's not global to the deployment right? just per-request
21:29:47 mriedem so api rate limiting
21:30:42 melwitt mriedem: oh, yeah it's per request. I misunderstood what you meant by global
21:31:41 sean-k-mooney melwitt: so max injected files is not per project/user its per instance?
21:33:35 melwitt sean-k-mooney: there are a few injected files quota limits. the one that limits the file path length and file content length are checked per request
21:34:09 melwitt *the ones (injected_file_path_length and injected_file_content_bytes)
21:35:36 melwitt and injected_files (number of injected files allowed) is how many per request too
21:36:08 melwitt you can set those limits to be different per project or per project and user
21:36:49 sean-k-mooney melwitt: so there is no global limit today for how much data a single project/user can store across all there instances today
21:37:06 mriedem well, personality files are not stored in the db
21:37:25 mriedem i think the point is that they default to a global value, checked per request,
21:37:33 mriedem but you can override those defaults per project or per project/user
21:37:37 mriedem using the os-quota-sets API
21:39:09 melwitt sean-k-mooney: right. injected file data isn't counted across projects or anything. it's only evaluated at the time of instance create, that the values you've requested don't exceed the limits. by default you can't boot an instance with more than 5 injected_files, each file has to be <= a certain length, each path has to be <= a certain length
21:39:36 sean-k-mooney mriedem: ah thats the delta to user-data then which is stored in the db.
21:40:01 mriedem yeah
21:40:13 mriedem spec will be incoming shortly
21:41:30 sean-k-mooney so are injected files kept in ram until the compute node actully creates the instance. if so that was proably part of the reason for limiting there overall lenght per request
21:46:20 melwitt yeah, could be. I don't know the history about it
21:52:55 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Return Alternate Hosts https://review.openstack.org/504275
21:53:23 sean-k-mooney johnthetubaguy: just getting ready to reupload https://review.openstack.org/#/c/375580/2/specs/ocata/approved/neutron-new-port-binding-api.rst is the createive common license correct for specs?
21:57:47 openstackgerrit sean mooney proposed openstack/nova-specs master: WIP: Use neutron's new port binding API https://review.openstack.org/375580
21:57:59 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Deprecate file injection https://review.openstack.org/509013
21:58:17 mriedem sean-k-mooney: it's part of the spec template
21:59:04 sean-k-mooney mriedem: cool i just assumed it would be apache 2 is all but i guess its really a doc and not code so makes sense
23:02:14 openstackgerrit Matt Riedemann proposed openstack/python-novaclient stable/newton: Fix aggregate_update name and availability_zone clash https://review.openstack.org/507816
#openstack-nova - 2017-10-03
00:06:36 openstackgerrit Jay Pipes proposed openstack/nova master: rp: de-ORM ResourceProvider.get_by_uuid() https://review.openstack.org/509025

Earlier   Later