Earlier  
Posted Nick Remark
#openstack-sdks - 2019-12-04
21:22:24 cmurphy seeking feedback from the osc team on ^
21:24:56 openstackgerrit Merged openstack/openstacksdk master: Fix reno index list indent https://review.opendev.org/697356
#openstack-sdks - 2019-12-05
11:24:55 openstackgerrit Vishakha Agarwal proposed openstack/python-openstackclient master: WIP Adding options to user cli https://review.opendev.org/697444
13:59:21 mordred rm_work: ossum
13:59:54 rm_work :)
15:31:23 openstackgerrit Merged openstack/shade master: Add source and contributing link in readme https://review.opendev.org/686871
15:55:53 elmiko dtantsur: is the ironic thing happening today?
15:56:37 dtantsur elmiko: ironic things happen every day
15:57:02 dtantsur it's not ironic-specific, more of adopting all openstack ansible modules (and re-shaping their API for consistency - hence API SIG involvement)
15:57:59 elmiko ahh, gotcha
15:58:06 cloudnull o/
15:58:12 elmiko is ironic things happening everyday also ironic?
15:58:43 dtantsur ironic things are ironically also ironic
15:58:49 elmiko nice
15:59:10 cloudnull isn't it ironic, don't you think?
15:59:25 dtantsur ++
15:59:47 ekultails o/
15:59:57 sshnaidm dtantsur, can you run the mtg bot here?
16:00:09 dtantsur we haven't done it for a while, I guess I can
16:00:10 elmiko API SIG office hour now open
16:00:15 dtantsur w00t
16:00:26 elmiko i'll let you do your bot thingie
16:00:31 dtantsur #startmeeting API-SIG
16:00:32 openstack Meeting started Thu Dec 5 16:00:31 2019 UTC and is due to finish in 60 minutes. The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 openstack The meeting name has been set to 'api_sig'
16:00:41 dtantsur heya!
16:00:49 sshnaidm dtantsur, cool, if you can chair me too please :)
16:01:00 dtantsur today we're a bit hijacked by Ansible SIG and the ongoing effort of bringing OpenStack ansible modules under our wing
16:01:03 dtantsur #chair sshnaidm elmiko
16:01:04 openstack Current chairs: dtantsur elmiko sshnaidm
16:01:28 sshnaidm ok, so thanks to SDK folks for the channel time :)
16:01:32 dtantsur a big part of it will be re-designing the modules for consistency, hence our (API SIG) involvement
16:01:54 dtantsur sshnaidm: take it from here :)
16:02:03 sshnaidm dtantsur, right
16:02:05 sshnaidm please use the etherpad: https://etherpad.openstack.org/p/openstack-ansible-modules
16:02:18 dtantsur #link https://etherpad.openstack.org/p/openstack-ansible-modules
16:02:18 sshnaidm we have update from gundalow from Ansible team
16:02:32 sshnaidm it's written in the bottom of etherpad
16:02:43 sshnaidm and I think we have a few decisions to make
16:03:00 sshnaidm 1. what is namespace name of openstack collections
16:03:11 sshnaidm gundalow, great
16:03:17 elmiko i just want to state for the record, that it is currently not within the goals of the api-sig to define guidance for these type of apis. /but/ with that said, it is within our goals to facilitate and promote these types of discussions.
16:03:58 sshnaidm elmiko, thanks
16:04:09 dtantsur well, our *actual* goals is to spend some time joking on each other
16:04:19 dtantsur soooo... :D
16:04:19 elmiko haha, too true
16:05:10 sshnaidm so, can we use "openstack." namespace?
16:05:15 gundalow So goal wise, all (will nearly all) modules/plugins will be removed from ansible/ansible before Ansible 2.10 ships. Getting a head of the curve and thinking about this now is good think
16:05:46 gtema is it official target of Ansible to remove modules from core?
16:05:49 dtantsur sshnaidm: my only concern is the fact that the collection won't be strictly "official"
16:05:50 sshnaidm gundalow, so no more community modules in 2.10?
16:06:23 ekultails What about modules that won't be able to find a new home?
16:06:26 sshnaidm dtantsur, yeah, these licenses differences, that's why raised this
16:06:27 gundalow ansible/ansible:stable-2.10 will only contain https://github.com/ansible-community/collection_migration/tree/master/scenarios/minimal
16:07:04 gundalow ekultails: for "homeless modules" that are currently in ansible/ansible they may go in the "catch-all" (aka dumping ground) repo & Collection
16:07:22 dtantsur ansible's stackforge :)
16:07:53 sshnaidm cool
16:07:57 sshnaidm so we're on time..
16:08:04 jistr sshnaidm: +1 for using openstack. namespace for the collection, since it's supposed to be "the official thing"
16:08:09 ekultails gundalow: Okay, good to know, thanks.
16:08:19 gtema and what about collection name?
16:08:30 jistr openstack.openstack? :)
16:08:36 gtema too weird
16:08:37 gundalow https://github.com/theforeman/foreman-ansible-modules/pull/591 might have some useful background
16:08:40 dtantsur openstack.<service type>?
16:08:45 dtantsur otherwise why do we need both?
16:08:50 sshnaidm gundalow, well, I think nobody should take "openstack" namespace except Openstack..
16:08:50 ekultails Not openstack.ansible, that could get confusing with OpenStack-Ansible. :-P
16:09:00 jistr having both is a requirement by Ansible galaxy IIUC
16:09:01 dtantsur #link https://github.com/theforeman/foreman-ansible-modules/pull/591 some helpful background
16:09:06 gtema for my org I ended up with "namespace.core" - for the core modules
16:09:11 gundalow What else could go under `openstack.`?
16:09:21 dtantsur gundalow: we can have a collection per service
16:09:26 gundalow (forgive me, I'm not familiar with all the parts of OpenStack)
16:09:29 dtantsur although it will probably complicate everything
16:09:44 jistr yea i also thing that would complicate it...
16:09:50 dtantsur gtema: we no longer have an official concept of core modules
16:09:58 gtema I don not think collection per service make sense, more a one collection with "core" modules, and perhaps additional ones for some "extra-weird" stuff
16:10:00 dtantsur we could have openstack.openstack and openstack.unofficial
16:10:18 sshnaidm what is "core" modules?
16:10:25 dtantsur let's avoid the term "core", it's a different thing for everyone
16:10:26 jistr gtema, dtantsur: +1 i think that scenario might come up perhaps
16:10:27 gtema well, everything what we have now
16:10:51 gtema and i.e. for some weird provisioning of triple-o infra - there might be openstack.tripleo
16:10:56 sshnaidm everything we have is kinda casual..
16:11:06 sshnaidm it's just what people could made quickly
16:11:40 jistr gtema: +1. So for the ones that are getting imported from Ansible, i'd go openstack.openstack or openstack.core or something like that
16:11:40 sshnaidm and I think it will look very different in the end
16:11:57 gtema yeah, but I think openstack.core.server looks better than openstack.openstack.server or openstack.compute.server
16:12:09 sshnaidm I'd vote for openstack.[service/project] names
16:12:11 pabelanger o/
16:12:18 dtantsur I think for many people 'core' may be nova+cinder+neutron+glance+keystone
16:12:23 dtantsur not things like ironic
16:12:30 sshnaidm gtema, openstack.compute.servers is actually as in SDK
16:12:42 sshnaidm and we may align with SDK here
16:12:46 jistr sshnaidm: hmm that does look good indeed
16:12:51 gtema I do not want to end up needing to do "ansible-galaxy collection install nova"
16:12:58 gtema and neutron and ...
16:13:07 jistr we'd force people to fetch multiple collections though... maybe not much of a problem

Earlier   Later