Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-12
19:51:01 kmalloc go go keystoneclient sucking
19:51:05 kmalloc it was KSC's default
#openstack-sdks - 2019-04-13
03:15:49 openstackgerrit Merged openstack/python-openstackclient master: Before writing object data to stdout, re-open it in binary mode https://review.openstack.org/573465
#openstack-sdks - 2019-04-15
08:59:05 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: WIP Skip attaching FloatingIP if it is already attached https://review.openstack.org/652594
09:50:10 cdent dtantsur: I kicked that thing
09:50:25 dtantsur thx!
09:59:56 openstackgerrit Merged openstack/api-sig master: Repair building guidelines https://review.openstack.org/651260
11:23:18 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Skip attaching FloatingIP if it is already attached https://review.openstack.org/652594
12:34:28 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Skip attaching FloatingIP if it is already attached https://review.openstack.org/652594
12:36:53 gtema mordred, dtantsur: would appreciate a look at https://review.openstack.org/#/c/651534/. Not a small change, but important one
12:40:13 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Try to fix the masakari CI job https://review.openstack.org/652638
12:40:19 dtantsur gtema: looking
13:19:00 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
13:35:53 brtknr Any idea when 0.28.0 will be shipped?
13:36:22 brtknr I'm still waiting for the heat tag update patch to be available in the SDK :)
13:41:30 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
14:09:34 dtantsur brtknr: now that we have Stein out, I guess mordred can request a release
14:10:05 mordred yes. I'll get that going today
14:10:27 brtknr mordred: dtantsur: excellent, thank you
14:10:55 gtema and I wanted to have https://review.openstack.org/#/c/651534 to come in first ;-(
14:17:02 mordred gtema: I took one look, but will take another in a couple of hours after the morning meetings
14:21:48 dtantsur mordred, https://review.openstack.org/#/c/652638/
14:22:47 mordred dtantsur: ah neat!
14:22:56 mordred dtantsur: sadly the bifrost job had a sad :)
14:23:47 mordred dtantsur: I hit a recheck - looks great to me though
14:57:07 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
14:57:51 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
15:28:49 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
17:06:49 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
17:09:25 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
18:19:41 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
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

Earlier   Later