Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
20:55:59 dansmith belmoreira: tssurya_ was going to put up a straw man for us to discuss with api people
20:56:02 mriedem it's a discussion item for the ptg
20:56:13 jackie-truong mriedem: The cert validation patch series has been +2'd :-) Can I move it to the "Needs final +2 to complete blueprint" section in the nova-queens-blueprint-status etherpad?
20:56:16 dansmith which I don't think has been posted, or at least that I saw
20:56:25 mriedem jackie-truong: go for it
20:56:40 jackie-truong mriedem: *\o/*
20:57:19 tssurya_ dansmith : we have been working on it and have some ideas/questions on how to proceed
20:57:19 belmoreira tssurya_ and I started to check for some alternatives. The PTG for us may be to late
20:57:28 mriedem jackie-truong: i don't understand why this isn't in the series before the API change? https://review.openstack.org/#/c/479949/
20:57:34 dansmith tssurya_: okay cool
20:58:20 belmoreira I would like to move to Pike in few weeks after Ocata. Meaning that we will need to cook something even it's only internal
20:59:18 jackie-truong mriedem: That patch implements the the certificate_utils module, but doesn't make any changes to the API. So it basically adds the functionality with no way to use it.
20:59:46 jackie-truong mriedem: The API change adds the usability part
20:59:58 mriedem jackie-truong: so technically here,
21:00:03 mriedem we could merge the API,
21:00:17 mriedem w/o the utils merged to do the things the api says you can do, right?
21:00:36 mriedem adding functionality that is eventually exposed out of the rest api is kind of how all new things work
21:01:26 jackie-truong The API change works with the trusted_certs object added in https://review.openstack.org/#/c/489408/
21:01:33 jackie-truong So, techincally
21:01:59 jackie-truong We could merge the API change (which would require the trusted_certs object change to be merged)
21:02:17 jackie-truong which would result in you being able to create and pass around a TrustedCerts object
21:02:20 mriedem what does the cert utils module do then?
21:02:20 jackie-truong Without making use of it
21:02:46 mriedem if i can't make use of the thing, what's the point of having the api before said thing works?
21:02:56 jackie-truong the cert utils module takes in the TrustedCerts object (which gets turned into a list of strings)
21:03:33 jackie-truong I realize that it technically makes sense to have the dependencies work: TrustedCerts object -> API -> cert_utils module
21:03:45 jackie-truong But technically, that isn't necessary
21:04:09 jackie-truong Since the API can be updated to pass around a useless object
21:04:10 mriedem no i was saying object > util (make things do something) > API (expose the things that do something)
21:05:01 jackie-truong Yeah, that timeline makes sense too. Basically, both util and API changes depend on the object change
21:05:20 jackie-truong but util and API don't have any dependency on each other
21:06:00 jackie-truong So we used the depends-on tag to indicate what dependencies needed to build
21:06:41 mriedem jackie-truong: i think you're asserting like code deps, and i'm asserting functionality deps
21:06:43 melwitt mriedem: replied
21:06:45 jroll mriedem: our jobs are no longer segfaulting n-cond as of this morning, so nfi what was causing it :/
21:06:55 mriedem jroll: huh
21:06:57 mriedem success!
21:07:09 jroll ikr
21:07:20 jroll proves "have a beer and try again tomorrow" is always a good plan
21:07:41 jackie-truong mriedem: Correct. Should the depends-on tag be used for functionality deps, too?
21:09:28 sean-k-mooney jroll: hum well it works. kind of hoped you would get to the bottom of that one
21:10:00 jroll sean-k-mooney: yeah, me too, but is nice to have it off my back
21:10:49 mriedem jackie-truong: you don't need a depends-on when it's in the same repo, just stack the changes in a series
21:10:53 mriedem object > utils > API
21:11:05 mriedem the API changes should always be the last thing to go
21:11:47 sean-k-mooney mriedem: logic being dont expose the feature at the api until its fully done right
21:12:30 mriedem sean-k-mooney: yes that's generally how things should work
21:12:48 mriedem because we support CD,
21:12:53 mriedem so that API can be in the wild once it's merged
21:12:56 mriedem and we have to support it
21:14:11 jackie-truong mriedem: Got it. bpoulos will fix shortly
21:14:19 bpoulos mriedem: I'll update the API order. I think we chose the way we did because that was the order it was listed in in the spec (at http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nova-validate-certificates.html )
21:28:28 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
21:28:28 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
21:28:29 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
21:49:04 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
21:53:43 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
21:54:43 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
21:59:41 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
22:00:30 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
22:00:45 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
22:01:16 mriedem tssurya_: dansmith: melwitt: L74 https://etherpad.openstack.org/p/nova-ptg-rocky
22:01:22 mriedem updated to summarize some of the meeting notes
22:01:32 dansmith awesome
22:01:38 melwitt thanks for doing that
22:04:06 tssurya_ mriedem : thanks for putting it all in one place,
22:07:04 jackie-truong mriedem: dependency orders are now fixed. sorry about that
22:19:38 mriedem lyarwood: is the native luks swap volume thing b/c of blockRebase? and if so, is that then also an issue for guest-assisted snapshot of encrypted volumes for volumes like NFS/gluster?
22:20:10 mriedem i don't know if we even have a tempest test for creating a snapshot of an instance with an encrypted volume attached, probably not
22:20:28 mriedem and if we did, it would only be run in the NFS CI
22:26:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Move remaining uses of parted to privsep. https://review.openstack.org/519483
22:31:35 mriedem gmann: do you plan on doing anything with these WIP changes? https://review.openstack.org/#/q/topic:bp/api-extensions-merge-queens+status:open
22:31:47 mriedem gmann: otherwise once the 2 patches from alex_xu are merged i'm going to complete the blueprint for queens
22:32:46 mriedem or i can just defer to rocky
22:33:56 mriedem efried: i assume we'll just defer this to rocky https://review.openstack.org/#/c/508345/
22:34:29 efried mriedem Yeah. I deemed nrp more important and didn't spend the cycles to investigate why that one's... "special".
22:34:40 mriedem that's fine
22:36:15 bpoulos mriedem lyarwood: the latest encrypted volume tempest tests are at https://github.com/openstack/barbican-tempest-plugin/blob/master/barbican_tempest_plugin/tests/scenario/test_volume_encryption.py and don't involve any snapshots
22:39:20 mriedem #success osc-placement 1.0.0 released; you can now do things with resource providers/classes via OSC CLI now
22:39:22 openstackstatus mriedem: Added success to Success page
22:39:28 mriedem mnaser: ^
22:39:38 mriedem you don't have to hack the db directly as much!
22:41:23 melwitt "as much" \o/
22:42:18 openstackgerrit OpenStack Release Bot proposed openstack/osc-placement master: Update reno for stable/queens https://review.openstack.org/537698
23:40:51 efried jaypipes Hi, didn't see you come in.
23:46:43 openstackgerrit Mike Perez proposed openstack/nova master: Replace support matrix ext with common library https://review.openstack.org/481304
23:52:42 jaypipes efried: sorry been out of network access for a while
23:53:47 efried jaypipes You missed a rather hearty debate on the extent to which the internals of generation management should be a part of the placement API spec.
23:54:26 efried jaypipes TL;DR: does the client get to know that the generation is a monotonically increasing integer starting at zero; or should the generation be completely opaque to the client?
#openstack-nova - 2018-01-25
00:04:08 openstackgerrit Eric Fried proposed openstack/nova master: New-style _set_inventory_for_provider https://review.openstack.org/537648
00:04:08 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821
00:04:09 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
00:04:09 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
00:04:10 openstackgerrit Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517
00:11:17 jaypipes efried: the client should just know it's an *atomically* increasing integer that, if it changed from the client's previous view of the generation, should trigger a re-read of the expected state.
00:11:26 jaypipes (and now I have to leave, I'm sorry :(
00:11:40 efried jaypipes Have a good one.
00:11:43 Spazmotic see ya jay
00:11:55 Spazmotic Just waking up and drinking my coffee and getting ready for hte gym.. whew
00:32:15 openstackgerrit Takashi NATSUME proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081

Earlier   Later