Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-12
16:59:39 pabelanger yes, building the collection isn't difficult
16:59:55 mordred sshnaidm: I'm not sure it helps or hurts - it's just that to actually release semver versioned artifacts on every commit would involve inventing a bunch of new automation and I don't know that effort on that is worth it
17:00:08 sshnaidm ok, so anybody objects to manual releases and want CD only?
17:00:30 sshnaidm #agreed on having manual releases as much as we need
17:00:30 gtema not me
17:00:40 dtantsur sounds good
17:00:41 sshnaidm well, we're out of time
17:00:46 dtantsur yay, thanks all!
17:00:49 mordred woot!
17:00:51 pabelanger mordred: I can share what we are doing in network, atleast as a discussion point. But is also a step towards buildset-galaxy too, not sure if there is interest in that right now
17:01:08 sshnaidm #endmeeting
17:01:10 openstack Meeting ended Thu Dec 12 17:01:07 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:01:11 openstack Minutes: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.html
17:01:12 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.txt
17:01:12 mordred pabelanger: I want buildset-galaxy the instant we can have it
17:01:13 openstack Log: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.log.html
17:01:24 mordred :)
17:01:42 gtema dtantsur, can I sleep now?
17:02:21 dtantsur gtema: I shall permit that
17:02:29 sshnaidm mordred, I think I'll get my CI job patch on top of yours with modules
17:02:32 gtema thks
17:02:55 sshnaidm mordred, to have it ready for running basic tests for them
17:03:23 pabelanger sshnaidm: how do you plan to run unit tests?
17:03:39 sshnaidm pabelanger, we don't have these afaik
17:03:44 sshnaidm pabelanger, with tox?
17:03:53 pabelanger sshnaidm: this is unit tests?
17:04:12 sshnaidm pabelanger, we have a job that runs functional tests and was running on ansible patches before
17:04:29 sshnaidm pabelanger, I convert it to run on sig repo now
17:04:30 pabelanger yah, that is devstack right?
17:04:34 sshnaidm pabelanger, yep
17:05:03 sshnaidm pabelanger, I didn't see unittests, lemme check in ansible repo..
17:05:13 pabelanger k, so should be able to just build collection and install, and ansible dev find it
17:05:21 pabelanger using ansible-galaxy
17:05:32 Shrews there were no unit tests, only functional tests
17:05:48 Shrews i wouldn't even know how to unit test an ansible module
17:06:08 pabelanger yah, it is a little messy IMO
17:07:05 sshnaidm yeah, no unit tests
17:07:21 sshnaidm there is a guide in ansible docs
17:07:23 Shrews and the current functional tests are woefully inadequate and hopefully will be improved uon
17:07:25 Shrews upon
17:07:39 sshnaidm https://docs.ansible.com/ansible/latest/dev_guide/testing_units_modules.html
17:07:52 sshnaidm didn't try it yet
17:08:01 Shrews yeah, i know it's possible, i've never had interest to learn how though
17:08:17 gtema mordred: what can you say about https://review.opendev.org/#/c/650374/15/openstackclient/image/v2/image.py@127
17:08:23 pabelanger no, I wouldn't use ansible-test for unit tests. I would much rather do something like stestr for it
17:08:37 pabelanger ansible-test is very opionioned in that case
17:09:03 sshnaidm pabelanger, is it usable for something?
17:09:08 sshnaidm ansible-test I mean
17:09:19 sshnaidm it has a lot of sanity checks I saw
17:09:23 pabelanger we use it for integration testing, in network
17:09:28 pabelanger it works, but is also slow in some cases
17:09:42 sshnaidm pabelanger, can you drop a link please?
17:09:47 pabelanger but not for unit tests for sanity
17:10:04 sshnaidm I'm curios if we can use molecule for tests
17:10:45 mordred Shrews, sshnaidm, pabelanger: perhaps once we're structured a bit more like this: https://review.opendev.org/#/c/698044/ it'll be easier to write "normal" unit tests?
17:10:50 pabelanger molecule uses pytest
17:11:20 mordred or maybe it won't be - who know
17:11:23 mordred knows
17:11:48 pabelanger sshnaidm: https://dashboard.zuul.ansible.com/t/ansible/build/6060fe2d015a4b718f1ab81f59a97a4f is a integration test for network and collections
17:11:57 pabelanger https://github.com/ansible-network/ansible_collections.arista.eos/pull/50
17:12:27 pabelanger basically, we have a parent job for build-ansible-collection, which creates the artifacts and passed is back into swift (soon galaxy)
17:12:41 pabelanger then ansible-test jobs, fetch collections and ansible-galaxy collection install it
17:12:45 pabelanger to then run ansible-test
17:12:47 sshnaidm mordred, yeah, need to try..
17:13:23 mordred https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/test-upload-logs-swift/library/test_zuul_swift_upload.py
17:13:27 pabelanger I'm not sure I'd try to use molecule... personally, I haven't see much work on ansible side to update it for collections
17:13:30 mordred that's how we unittest modules in zuul-jobs
17:14:02 mordred pabelanger: yah - also molecule seems a bit focused on being able to make test envs for you and stuff- I don't know that it's a great fit here
17:14:09 pabelanger mordred: yah, it would be great to some how loop that into a test runner, for both zuul and local
17:14:22 mordred pabelanger: I think we can do that pretty easily
17:14:31 pabelanger +1
17:14:39 mordred if you run stestr in zuul-jobs it'll run those unit tests
17:14:51 pabelanger oh, today?
17:14:53 pabelanger nice
17:14:57 pabelanger that is what I want to do for network
17:15:04 mordred yeah
17:15:17 mordred it'll need to be slightly adapter - but it should be mostly cargo-cultable
17:15:23 pabelanger then, even add support for ansible-playbook and inventory file, like we did with zuul functional testing
17:15:29 mordred tests/test_discovery.py is what drives finding the tests to run
17:15:33 mordred ++
17:16:49 pabelanger ack
#openstack-sdks - 2019-12-13
08:31:58 openstackgerrit Vishakha Agarwal proposed openstack/python-openstackclient master: Adding options to user cli https://review.opendev.org/697444
11:15:56 openstackgerrit Artem Goncharov proposed openstack/osc-lib master: Add get_osc_show_columns_for_sdk_resource function https://review.opendev.org/698874
14:32:57 openstackgerrit Merged openstack/openstacksdk master: Remove duplicate job definition https://review.opendev.org/698057
16:11:19 mriedem efried: mordred: see the question in the ML - i'm not sure how a volume-backed server in the sdk is represented for the Server.image attribute because the sdk defines that as an Image type but for a volume-backed server the actual server.image response body param is an empty string
16:12:11 efried ack, I'll have to get back to that later.
16:12:13 mordred mriedem: I'll have to go dig around (and look at that) - I know for server creation we have a large pile of logic
16:14:21 mordred in the resource layer there - we have image = resource.Body('image', type=image.Image
16:14:53 mordred so that's going to mean the sdk is going to pass the empty string value to the Image constructor - meaning that code looking for not image is not going to work
16:15:20 mordred however - that should be a ludicrously empty Image with an id of ''
16:15:36 gtema I'm not really sure, image_id will be empty
16:15:39 mordred so maybe an easy fix would be if not server.image.id
16:15:45 mordred or test for image_id
16:15:54 mordred (is imageRef also an empty string in the response?)
16:15:55 gtema in my cloud even for servers booted from image I still see image in the response
16:16:07 mriedem yeah i at least picked up that the Image field isn't going to be Falsey
16:16:12 mordred yeah
16:16:32 mriedem gtema: that would be expected...
16:16:34 mordred now - maybe we should add some logic to look for an empty string image and set Image to None if so
16:16:57 mriedem the servers body response will always have 'image'; if it's volume-backed the value is '', else it's a dict

Earlier   Later