Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-24
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
00:54:41 mnaser mriedem: awesome stuff about osc-placement :D
01:46:33 oomichi takashin: hi, still isn't https://review.openstack.org/#/c/533134/ favorite?
01:47:38 takashin oomichi: Hi. There are redirects. So the modification is not necessary.
01:48:33 oomichi takashin: do you see my comment?
01:49:59 takashin oomichi: Yes. but my patch was not just replacing http with https.
01:50:11 Yikun gmann, https://review.openstack.org/#/c/534721/, hi, I saw your inline comments, so, should we add 2 config like project_network_cidr[1 & 2] to keep this? or some other idea?
01:50:43 oomichi takashin: then, why did you change it even if there was a redirecting?
01:54:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix bug case by none token context https://review.openstack.org/522112
01:54:15 mriedem efried: can you tell me if the release note i threw in here sounds ok? ^
01:54:39 efried ...
01:55:19 takashin oomichi: My patch was changing 'pike' to 'queens'. Replaceing http with https was done at the same time, but it is not worth doing it separately.
01:56:49 efried mriedem LGTM, +1
01:58:02 oomichi takashin: I am not sure why it is not worth doing it *separately*
01:58:16 efried mriedem Course, you coulda addressed my nit, but meh.
01:58:53 efried takashin Glad to catch you online. I've been wanting to tell you how much I appreciate your super-thorough code reviews.
01:59:37 efried takashin ありがとうございました ;)
02:00:17 jose-phi_ hi any idea
02:00:28 takashin efied: You are welcome.
02:00:36 jose-phi_ of why when i set data-port=br-ext:eno1 this interface got dead "eno1"
02:00:49 jose-phi_ and this is my data network so i lost all connectivity to the compute node
02:01:13 takashin oomichi: it is not worth doing it alone.
02:02:08 takashin efried: You are welcome.
02:02:52 openstackgerrit Eric Fried proposed openstack/nova master: set_{aggregates|traits}_for_provider: tolerate set https://review.openstack.org/536625
02:02:52 openstackgerrit Eric Fried proposed openstack/nova master: New-style _set_inventory_for_provider https://review.openstack.org/537648
02:02:53 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821

Earlier   Later