Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-15
18:22:21 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
21:56:42 openstackgerrit Merged openstack/python-openstackclient master: Tweak network segment range fiunction tests https://review.openstack.org/652129
#openstack-sdks - 2019-04-16
07:30:30 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
09:21:52 openstackgerrit LIU Yulong proposed openstack/python-openstackclient master: Add floating IP Port Forwarding commands https://review.openstack.org/650062
10:31:39 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
10:59:00 openstackgerrit Merged openstack/openstacksdk master: Try to fix the masakari CI job https://review.openstack.org/652638
11:42:43 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add image.stage methods https://review.openstack.org/652981
13:38:29 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Return None from get_server_by_id on 404 https://review.openstack.org/652995
13:41:03 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Return None from get_server_by_id on 404 https://review.openstack.org/652995
13:45:10 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
13:45:35 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
14:49:06 mordred gtema: left a review on the image patches - I think they're close
14:49:59 gtema yes, thanks. Few issues:
14:50:35 gtema auto_disk_config - I think it would be better to drop this attr from image resource and rely on the "properties" interpretation of it
14:51:03 gtema drop compute for list - ok, will do
14:52:02 gtema switch to wait_for_task - it's this fallback for _IMAGE_ERROR_396 which makes it not easy
14:52:39 mordred gtema: auto_disk_config - yeah
14:52:51 mordred gtema: or else we should add ALL of the driver-specific properties
14:53:19 gtema which we do not want to
14:53:53 mordred gtema: yeah. and unfortunately _IMAGE_ERROR_396 is a wonderful thing that rackspace does throw. like - that chunk of logic exists because of issues production nodepool sees without it
14:54:09 mordred gtema: totally. there's too many of them - it would make the image objects absurd
14:54:43 gtema morderd: so should I then drop all hw*, vmware*?
14:56:27 mordred gtema: ugh. we do have a lot of these already don't we
14:56:33 gtema yupp
14:56:46 mordred gtema: maybe it's better that we just add the rest of them? I wish they were documented somewhere that isn't a wiki page
14:56:50 mordred like, you know - in the API docs
14:57:00 mordred lemme ask rosmaita
14:57:04 gtema ok
15:02:21 mordred gtema: https://docs.openstack.org/glance/latest/admin/useful-image-properties.html
15:02:51 gtema morder: ack, will go through
15:03:22 mordred wow. trait:trait_name is fantastic
15:03:51 gtema however, if on Rackspace auto_disk_config returns you "disabled" - we have a problem and need to treat all those as strings only
15:04:03 gtema since it should be true or false
15:09:00 mordred gtema: mriedem tells me that auto_disk_config is string in the nova schema, so even the true and false values are actually "true" and "false"
15:09:39 gtema ok, that is the problem, that in Image it was casted to bool and therefore I had problem
15:10:32 mordred aha!
15:10:36 mordred https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L233
15:10:48 mordred gtema: this is apparently where we can look to find out actual thing
15:11:00 gtema yeah, looks interesting
15:11:27 gtema but is also interesting "architecture" vs "hw_architecture"
15:11:41 gtema hw_auto_disk_config
15:11:47 mordred there's a legacy property map at the bottom
15:11:58 gtema oh, thks
15:12:25 mordred I wonder how hard it would be to write a gate job (or maybe a functional test that works only on devstack installs)
15:12:33 gtema it's huge. Do we really want all of that?
15:12:40 mordred that would import that nova file and do a cross-check to make sure the property lists match
15:12:46 mordred gtema: I don't know
15:12:53 mordred it's an excellent questions
15:13:21 gtema we will anyway put everything what we get under properties and even allow to set anything
15:14:39 gtema and those traits - we can't define such things as of now
15:15:34 mordred yeah ... so - in #openstack-nova I just said :
15:16:39 mordred oh - screw it - copy/paste not worth it... basically - since the various base properties can have varied data types, we might really want to do the whole list so we can make sure everything in properties is just a string type and is a user-defined property
15:16:42 mordred BUT
15:16:50 mordred maybe we can wait a bit and do that later
15:17:01 mordred I think what's there now is fine for now until someone gets upset
15:17:24 gtema so simply let it stay how it is now?
15:17:41 gtema auto_disk_config - will remove type=bool
15:18:58 mordred OH GOD. THERE ARE ENUMS
15:19:21 mordred gtema: yeah. let's do that for now - I think dealing with the whole thing is ... large ... and requires some real thought
15:19:38 mordred like - if we wanted to actually tackle it - I'd want to figure out how to keep thigns liek enum lists in sync
15:20:15 mordred gtema: you know - there's also the schema field you added support for
15:20:33 gtema yes, I know
15:20:47 mordred gtema: I wonder if it would be easier/better to just write something that grabs the schema and figures out which properties are base and which are user based on that schema
15:20:50 gtema you want us to make use of it?
15:20:59 mordred maybe? I don't know how useful it is
15:21:23 gtema well, I am not sure it is usefull as of now. Maybe later
15:22:07 gtema this would not be very efficient by default, since nearly always we would need to invoke it and/or cache schema data
15:22:14 mordred ++
15:22:26 mordred yeah - we'd definitely have to cache schema data I think
15:22:38 mordred but for single-use processes like osc it woudl still be inefficient
15:22:48 gtema definitely
15:22:59 mordred so it's PROBABLY better to think about a test job that validates against the nova source code
15:23:13 mordred but HOLY CRAP that'll be a lot of work too due to the use of custom enum classes
15:23:28 gtema agree
15:29:33 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
15:43:32 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Add image.stage methods https://review.openstack.org/652981
18:23:48 efried mordred: This openstacksdk business is ready for primetime, yah? So like, new projects like cyborg that don't yet have a legacy commitment to python-*client and/or oslo.config for ksa can and should bootstrap their talking-to-other-services business with a clouds.yaml and production Connection constructor-ness?
18:30:13 mordred efried: yes
18:30:39 mordred efried: it would be very welcome for them to add support for their service into sdk directly
18:30:56 efried mordred: I was talking about cyborg wanting to communicate *at* other services, like placement and glance.
18:31:02 mordred ah. yes. that too
18:31:20 Shrews mordred: very very small nit on https://review.openstack.org/652995 but happy to merge as is too if you'd rather say "meh"
18:31:23 efried Sundar: ^ Given that you've just succeeded in connecting using a ksa adapter, it should be fairly trivial to translate your oslo.config-based values into a clouds.yaml.
18:31:25 mordred so - both things are true
18:32:02 mordred efried: yah. although if they _want_ to use the oslo.config stuff, we've got that helper method we put in for nova
18:32:12 efried mordred: Well, yeah, it's still in flight.
18:32:28 efried mordred: And I'm not sure there's a reason to use oslo.config stuff, is there?
18:32:33 mordred efried: god, have we not landed that yet? I should really finish writing tests
18:32:47 efried mordred: I did leave a poke there a week or two ago :)
18:32:48 mordred efried: not really - other than consistency with other services for operators
18:33:04 efried I mean, how much gerrit mail could you possibly get?
18:33:14 efried :P
18:33:14 mordred efried: you think I get email from gerrit? :)
18:33:41 efried I've got a guy coming up to speed and working on the ironicclient swapout for nova
18:33:55 efried We're getting close-ish to a point where we'll want that dep merged & released.
18:34:10 efried dustinc: ^
18:34:46 mordred efried: cool. we'll get it merged for you then
18:35:01 efried mordred: Let me know if you need anything from me on that.
18:35:29 mordred don't think so - I think the nova depends-on patches provide good integration testing that it works - we just need to add some sdk-side testing and it should be good to go
18:35:54 mordred Shrews: oh piddle. can you tell I copy-pastad that?

Earlier   Later