Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-06-12
14:56:02 mriedem service version 11 was newton https://review.openstack.org/#/c/287997/
14:56:12 rmk Someone pasted code with a comment from me in it. What did I break this time? :(
14:56:21 mriedem anyway, that's not how i read the commit message
14:56:23 dansmith mriedem: it was during newton, notfinal newton
14:56:35 mriedem dansmith: that change is in stable/newton
14:56:37 dansmith mriedem: but yes, I think it needs to be "newton checking for mitaka api"
14:56:47 dansmith mriedem: yes, I know
14:56:52 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081
14:57:32 dansmith mriedem: the title is "check for mitaka" so I think I got that right and then just wrote the rest of the commit message later and was off by one
14:57:48 sean-k-mooney jaypipes: is the intenet to model traits request as an extention fo the flavor extra spec or will a new mechanisume be introduced to model this
14:58:00 openstackgerrit Dan Smith proposed openstack/nova master: Remove old service version check for mitaka https://review.openstack.org/472395
14:58:28 mriedem dansmith: ok maybe it's the "removes a service version check from mitaka" - the "from mitaka" makes me think the check was added in mitaka, which it wasn't, it was added in newton
14:58:43 jaypipes sean-k-mooney: new mech, eventually to replace extra specs would be my intent. not sure if folks agree with that though :)
14:58:43 sean-k-mooney jaypipes: e.g. can i request a traint say ssd on the nova boot command or would that be part of the flavor extra specs/image meta-data
14:58:57 sean-k-mooney jaypipes: that would be my preference
14:59:03 dansmith mriedem: it's "for mitaka" not "from mitaka"
14:59:23 jaypipes sean-k-mooney: I'd like to see a nova boot --required HW_CPU_X86_SSE42,STORAGE_DISK_SSD type of interface.
14:59:23 sean-k-mooney jaypipes: it means we can specify this per instance but the adming migh wat to impose constriant via flavors
14:59:40 jaypipes sean-k-mooney: but until that happens, we will need to tack everything on to a flavor.
14:59:52 mriedem dansmith: i know, hence my confusion :)
15:00:11 dansmith ...okay
15:00:52 sean-k-mooney jaypipes: --required HW_CPU_X86_SSE42,STORAGE_DISK_SSD is something i think in the long run would be nice to have. i dont know if we need to have a white list of traints that can be request per flavor though for billing reasons
15:02:02 sean-k-mooney e.g. cheap flavor cannont request STORAGE_DISK_SSD but performance flavor can. that list of trait could be modeled at the flvor level as allowed traits
15:02:18 mriedem dansmith: oh you're talking about the title, i was talking about the wording in the body in the old patch set
15:02:32 dansmith mriedem: correct
15:02:55 mriedem last thing is https://review.openstack.org/#/c/472395/4//COMMIT_MSG
15:03:56 mriedem if this is going to cause a head to explode we can just stop talking about it
15:05:35 sean-k-mooney jaypipes: if i rember correctly you were also proposing haveing a --prefer or somthing similar for soft reqruiment or nice to have fetaure (traits) also. is that still what you envision
15:05:58 jaypipes sean-k-mooney: yes, but long way out.
15:06:43 sean-k-mooney jaypipes: cool just checking, that would allow me to expres somting like --required HW_CPU_X86_SSE42 --prefer HW_CPU_X86_AVX cleanly
15:07:13 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-server-groups endpoint instead of stevedore https://review.openstack.org/462169
15:07:14 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-consoles, os-console-auth-tokens endpoint instead of stevedore https://review.openstack.org/462175
15:07:14 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for user_data instead of stevedore https://review.openstack.org/462183
15:07:15 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for block_device_mapping instead of stevedore https://review.openstack.org/462180
15:07:42 sean-k-mooney that is useful for tings like dpdk that require sse3+ to function but perform best with avx.
15:08:44 sfinucan Kevin_Zheng: Rebased above patches to put them in series ^^^
15:08:58 sfinucan If we don't do that, we get endless merge conflicts :(
15:09:36 jaypipes sean-k-mooney: right.
15:09:58 alex_xu sean-k-mooney: not sure how people bill that, people pay a price of avx, but may not get avx. or people pay a price for sse3, but maybe they get some luck
15:11:03 sean-k-mooney alex_xu: i would guest the get billed by the minium gurantee but it would be up to the operator
15:12:01 sean-k-mooney alex_xu: even without the perfer if you got allocated to a sse3 node it may have avx
15:12:30 sean-k-mooney i would see the --require as an input to the filters and --prefer as an input to the weighers
15:13:00 alex_xu sean-k-mooney: emm...why not just required the avx
15:13:35 sean-k-mooney alex_xu: you could but i may not need that level of performance so might want to use a cheaper flavor
15:15:37 alex_xu sean-k-mooney: so, just two flavors one cheap and another one expensive should works. btw you may interesting this spec https://review.openstack.org/468797
15:16:24 alex_xu sean-k-mooney: we explore the prefer_traits in the spec, but removed, as I'm not very sure the use-case. but welcome the review and comments
15:16:46 sean-k-mooney alex_xu: yep it would but if we want to move away form usign the flavor to ecode the request in the futer you may want to be more dynamic
15:18:10 sean-k-mooney alex_xu: well for me the real usecase for for prefer vs require come fi you have a mano system or some level of intelagent that understands that expected kpi/level of performance that this instance will need to achive and can tailor the request accordingly
15:19:23 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add memoize function using oslo.cache https://review.openstack.org/472773
15:19:30 sean-k-mooney alex_xu: it could simply chose between 2 fixed flavors or dynamicl change if the trait is expressed in prefered or require depentind on if it knows it is requrieed to meet the sla or not
15:20:26 alex_xu sean-k-mooney: oh, you want to set the minmum performance for a flavor
15:20:57 sean-k-mooney alex_xu: ill be glad to take a look that the spec though. yes require set minium performece
15:21:46 alex_xu sean-k-mooney: thanks, I will keep that in mind also
15:22:59 Kevin_Zheng sfinucan: will do thanks
15:23:11 sfinucan Kevin_Zheng: No - I have it done already :)
15:23:26 sfinucan so please don't undo it, heh
15:23:33 Kevin_Zheng sure
15:28:26 openstackgerrit Baodong (Robert) Li proposed openstack/nova-specs master: Expose vlan trunking in metadata/configdrive https://review.openstack.org/471815
15:33:17 openstackgerrit Baodong (Robert) Li proposed openstack/nova-specs master: Expose vlan trunking in metadata/configdrive https://review.openstack.org/471815
15:36:37 openstackgerrit Matt Wisch proposed openstack/nova master: conf: Corrected compute_monitors help text https://review.openstack.org/468538
15:47:06 openstackgerrit Matt Wisch proposed openstack/nova master: Clarify conf/compute.py help text for ListOpts https://review.openstack.org/468538
15:53:11 efried sfinucan I'm a little confused by https://review.openstack.org/#/c/412634/15/nova/conf/glance.py@101 followed by +2+W. Did you mean to put up another patch set?
15:53:34 sfinucan efried: Nope - I just wanted to explain why it was done that way
15:53:43 sfinucan My phrasing wasn't great, admittedly
15:54:06 efried "Dodgy test removed." <== what is this referring to?
15:54:26 efried Cause the dodgy test you point out in PS15 doesn't appear to have been removed.
15:54:37 sfinucan efried: mriedem's comments on Jan 27 03:42
15:55:09 sfinucan efried: The 'test_glanceclient_session_cached' test is removed, right?
15:55:30 sfinucan that's the test I referred to (it's attempted mocking of a global is apparently not do'able)
15:57:34 efried sfinucan [Still digging]
15:59:59 efried sfinucan Phew, that took me longer than it should. Okay, I'm happy. I got confused because those two comments looked like they were related to each other.
16:00:06 efried sfinucan Thanks!
16:00:50 sfinucan efried: Cool cool. Sorry for the poor phrasing https://imgur.com/Lffqx89
16:16:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload https://review.openstack.org/448779
16:16:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add key_name field to InstancePayload https://review.openstack.org/463002
16:16:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add keypairs field to InstanceCreatePayload https://review.openstack.org/419730
16:16:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add separate instance.create payload type https://review.openstack.org/463001
16:19:18 mriedem oomichi: sdague: checking my understanding on something, which i think is a bug - the forced_down field in the PUT /os-services/force-down API uses the boolean parameter type in the schema https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/services.py#L42
16:19:38 mriedem which can be something like 'yes' https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L190
16:20:02 sdague mriedem: ok
16:20:04 mriedem which isn't converted to an actual boolean https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/services.py#L136
16:20:28 mriedem which methinks will explode https://github.com/openstack/nova/blob/master/nova/objects/service.py#L151
16:20:32 sdague mriedem: yeh, that should be turned into a real boolean
16:20:45 sdague mriedem: agreed
16:20:55 mriedem alright, writing up a bug
16:24:35 openstackgerrit Maciej Kucia proposed openstack/nova master: [doc] Updated sqlalchemy URL in migrate readme https://review.openstack.org/472549
16:24:39 openstackgerrit Maciej Kucia proposed openstack/nova master: [doc] Updated sqlalchemy URL in migrate readme https://review.openstack.org/472549
16:25:28 mriedem https://bugs.launchpad.net/nova/+bug/1697497
16:25:28 openstack Launchpad bug 1697497 in OpenStack Compute (nova) "PUT /os-services/force-down won't work with non-boolean forced_down field" [Medium,Triaged]
16:26:46 openstackgerrit Gábor Antal proposed openstack/nova master: Transform aggregate.update_metadata notification https://review.openstack.org/460625
16:38:27 openstackgerrit Merged openstack/nova master: [placement] Add api-ref for aggregates https://review.openstack.org/470932
16:50:49 openstackgerrit Dan Smith proposed openstack/nova master: Remove old service version check for mitaka https://review.openstack.org/472395
17:03:08 mriedem dtp: fyi that i've got the PUT /os-services/{service_id} change for this https://review.openstack.org/#/c/464280/ done locally, just working on tests and docs changes for it
17:05:22 openstackgerrit Gábor Antal proposed openstack/nova master: Add json style checking for sample notifications https://review.openstack.org/443677
17:11:11 dansmith cdent: fwiw, I also think those need not be OVOs
17:11:14 dansmith and maybe not even Os
17:11:53 cdent I guess people like the O aspect because of enforcement?
17:13:56 dansmith the field type enforcement?
17:14:27 stvnoyes mriedem: johnthetubaguy: The live migrate rv is ready. I was able to successfully live migrate (with an attached volume) back and forth using the new cinder v3 api. Please take a look when you get a chance. thanks. https://review.openstack.org/#/c/463987/
17:14:32 dansmith perhaps, but we're pulling stuff out of a pretty rigid DB schema and will filter it through jsonschema validation on the sending side at least, so I'm not sure I really see the point

Earlier   Later