Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-17
16:37:07 cburgess mriedem I don't get to code anything. :(
16:37:26 sdague cburgess: we can totally find you some easy bugs to fix :)
16:37:42 cburgess I last landed code on 2/8/2016
16:37:52 cburgess sdague I just found one. It involves a new config option, you will hate me.
16:37:52 sdague cburgess: nova api-ref is in tree now, I'm sure you can tell us a ton of things we lie about with the API :)
16:38:03 cburgess sdague LOL
16:38:12 mriedem dtp: btw, now that you're around, we should talk about your alternative for https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api
16:38:26 dtp sure, you want to do that here or privately?
16:38:31 mriedem dtp: here
16:38:42 mriedem unless it involves profanity
16:38:46 mriedem but then still here
16:39:00 superdan since when does that matter?
16:39:05 mriedem superdan: it doesn't
16:39:16 dtp hehe
16:39:19 dtp my main concern is [Then when a request to delete a service is made, if the uuid is provided we can simply iterate cells until we find the service, or error with a 404.]
16:39:42 dtp i would expect to not have to iterate when given an id
16:39:48 dtp or guid
16:39:52 superdan dtp: no, we do
16:40:01 superdan dtp: unless we index services in the api db, which wouldn't be worth the trouble, IMHO
16:40:04 superdan plus the syncing problem
16:40:49 dtp if i understand correctly, the problem w/ id is we don't know which cell to point to, right?
16:41:00 mriedem yes
16:41:02 superdan dtp: the problem with id is that it can be duplicated in multiple cells
16:41:08 superdan not that we don't know what cell it's in
16:41:11 mriedem dtp: we'd need a ServiceMapping in the api db
16:41:16 superdan -2 on that
16:41:16 mriedem like we have for HostMapping and InstanceMapping
16:41:19 superdan please no
16:41:24 mriedem i agree, no to that
16:41:39 dtp so i was thinking we could embed the cell id w/ the object id
16:41:52 mriedem the int?
16:42:20 superdan you mean change id to "%(cell_uuid)s-%(service_uuid)s" ?
16:42:23 dtp yes
16:42:31 dtp something like that
16:42:38 mriedem id is an int primary key right now,
16:42:43 mriedem and expressed that way in the api
16:42:47 mriedem so we can't change that
16:43:00 superdan mriedem: he means in the api after a microversion
16:43:01 superdan which we could do
16:43:02 superdan however,
16:43:02 mriedem unless you're talking about rather than return service uuid in the microversion, just put the cell id in that
16:43:03 mriedem ok
16:43:05 superdan I'd rather not expose cell details out of the api, even subversively
16:43:26 superdan and I don't think this is anywhere near a big enough problem to warrant that
16:43:27 mriedem that is something that exists with cellsv1 right?
16:43:30 mriedem the cell namespace?
16:43:49 superdan mriedem: yeah, and it has problems, and we vowed not to expose cell details out of the api with v2
16:44:05 mriedem ok, yes, it does feel too special snowflake for a problem that doesn't warrant it
16:44:23 superdan yeah
16:44:54 mriedem because if we did that for services/computes/pci_devices, we'd have to start thinking about doing it for other things too, for consistency, which we don't want to do
16:45:04 mriedem you could restrict an id like that to admin-only type resources, but still
16:45:18 superdan there's just no need for it, IMHO
16:45:55 mriedem dtp: just curious, how many cellsv1 cells are you guys running in production?
16:46:03 superdan we can parallelize the queries anyway, to lower the latency at some point
16:46:08 superdan mriedem: cern has 50
16:46:14 mriedem because initial deployments that weren't ever cellsv1 to begin with will just be a single cell
16:46:25 dtp we don't have 50
16:46:26 superdan mriedem: service delete has to be an infrequent thing
16:46:26 mriedem so there is no looping
16:46:32 mriedem superdan: i know
16:46:52 dtp but hypervisor lookup?
16:47:03 mriedem i was just thinking years down the road when having hundreds of cells could cause performance pain in the API
16:47:20 superdan mriedem: if we end up with actual pain, then we add a cache or mapping
16:47:24 mriedem dtp: we have the HostMapping for that
16:47:34 mriedem superdan: yeah
16:48:10 dtp ok, got it. thanks guys
16:48:32 mriedem np. and thanks for thinking up alternatives
16:48:39 mriedem i can work that into the alternatives section of the spec
16:48:39 dtp yw
16:48:47 mriedem "dtp sez..."
16:48:56 dtp lol
16:49:22 superdan dtp: you should /nick deeteepee
16:49:28 superdan because: friday
16:49:41 mriedem superdan: +2 on the novaclient change
16:49:58 superdan thanks
16:50:16 superdan much better
17:01:11 openstackgerrit Michael Henkel proposed openstack/nova master: contrail: add vrouter VIF plugin type support https://review.openstack.org/441183
17:23:44 jroll heh
17:23:53 jroll deeteepee-afk: you were looking for me last night, what's up?
17:33:22 openstackgerrit Christopher Brown proposed openstack/nova master: Add lan9118 as valid nic for hw_vif_model property for qemu https://review.openstack.org/393489
17:34:55 cburgess cfriesen Did you already have a bug open about the pre live timeouts on glance?
17:41:19 deeteepee-afk hey jroll! do you mind if i add your comments from yesterday regarding https://blueprints.launchpad.net/nova/+spec/conf-network-metadata-always-static-ip ? or if you have any other comments, i would appreciate them
17:41:42 jroll leakypipes: having a conversation about ironic capabilities^Wtraits, reading the spec, it sounds like standard traits go through os-traits, custom go through the api. does queens sound like a reasonable timeframe for us to move ironic capabilities into that so people can stop using the ComputeCapabilitiesFilter thing?
17:42:11 jroll leakypipes: (which also makes me wonder, should we go ahead and cover a flavor extra spec for custom traits when we do the custom resource class extra spec?)
17:42:42 jroll deeteepee-afk: yeah, go for it :)
17:42:56 deeteepee-afk thanks
17:42:59 leakypipes jroll: yes and yes
17:44:33 jroll leakypipes: cool - also question from yesterday, I put custom RC allocations as a dependency for the flavor changes, do you want to do that work, and do you want to write a separate spec or put it in this one? https://review.openstack.org/#/c/446570/2/specs/pike/approved/custom-resource-classes-in-flavors.rst
17:50:33 openstackgerrit John Garbutt proposed openstack/nova master: Add and use ProcessedNetworkRequest object https://review.openstack.org/418025
17:50:39 openstackgerrit John Garbutt proposed openstack/nova master: Pass objects into _validate_requested_network_ids https://review.openstack.org/418027
17:50:55 openstackgerrit John Garbutt proposed openstack/nova master: Pass objects into _create_ports_for_instance https://review.openstack.org/418512
17:51:12 openstackgerrit John Garbutt proposed openstack/nova master: Stop passing network when you only need dns_domain https://review.openstack.org/419577
17:51:22 openstackgerrit John Garbutt proposed openstack/nova master: Pass objects into _update_ports_for_instance https://review.openstack.org/418513
17:51:44 openstackgerrit John Garbutt proposed openstack/nova master: Extract preallocate_for_instance https://review.openstack.org/418876
18:16:24 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: rename qemu_enable_gluster_storage_driver https://review.openstack.org/447091
18:23:09 openstackgerrit John Garbutt proposed openstack/nova-specs master: Spec to add per instance timeout for LM https://review.openstack.org/442809
18:23:51 johnthetubaguy cfriesen: cburgess: thats that live-migrate API spec that raj_singh is working on ^
18:24:19 johnthetubaguy there is also the dependent spec thats interesting
18:25:06 cburgess johnthetubaguy Thanks
18:32:14 openstackgerrit Sujitha proposed openstack/nova master: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185

Earlier   Later