Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-05
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
16:13:12 jistr but i wonder about code sharing
16:13:36 ekultails Would there be a way to have a meta collection that installs all relevant collections?
16:13:43 pabelanger I would recommend openstack.openstack as the collection then you call openstack.openstack.os_nova, or maybe even community.openstack.os_nova
16:13:44 jistr will openstack.<service> pattern complicate *writing* those collections in case we want to share code?
16:13:51 dtantsur we could avoid the problem with code sharing by putting EVERYTHING in openstacksdk
16:13:56 sshnaidm jistr, as we were talking previously there should be definitely common part, like auth for example
16:14:23 pabelanger opentack.openstacksdk.os_nova would work too
16:14:47 dtantsur are we keeping the os_ prefix?
16:14:50 sshnaidm openstack.compute, openstack.network, openstack.tripleo - can it work?
16:14:51 pabelanger but, i think you still want os_nova / os_neutron, otherwie, you will break a ton of playbooks
16:14:53 gundalow FYI you can use https://github.com/ansible-community/collection_migration with a scenario file to pull the contents out of ansible/ansible into the correct structure
16:14:54 dtantsur I guess it was only useful before namespacing?
16:15:09 sshnaidm I dont' think need os_ now, it's a dup
16:15:11 gtema while "openstacksdk" forever, what should it stand for?
16:15:17 pabelanger for ansible/ansible migration, they should all be migrated to single repo
16:15:18 pabelanger and namespace
16:15:23 gtema os_ should be definitely dropped
16:15:34 gundalow If you change the module names, you may break backwards compatibility between 2.9 and 2.10 unless you put in aliasing (symlink)
16:15:38 pabelanger gtema: that is a huge breaking change
16:15:39 dtantsur pabelanger: we're considering some breaking changes anyway, like unifying authentication
16:16:04 pabelanger if you do, openstack.sdk.os_nova, you could still reference os_nova in your playbook
16:16:04 dtantsur gundalow: would plain os_nova (without openstack.<something>) work after the migration?
16:16:13 pabelanger yes
16:16:15 dtantsur mmm, I see
16:16:19 gtema he? is the migration from ansible to collection not a breaking change by itself?
16:16:30 dtantsur it sounds like it's not THAT breaking
16:16:36 gtema you anyway need to change your playbooks
16:16:38 dtantsur or rather: it doesn't break the playbooks
16:16:43 pabelanger I'd say no, you can keep same playbooks for most part
16:16:43 gtema it does
16:16:57 gundalow gtema: There is the idea of a "Community version of Ansible" that will ship with all the collections that make up what's in Ansible 2.9
16:17:04 gtema you need to refer to modules from collection or import collection
16:17:23 dtantsur I'd seriously regret if we couldn't unify the auth though
16:17:35 dtantsur (and s/os_ironic/os_baremetal/ )
16:17:38 gtema gundalow, but you anyway need to modify playbook

Earlier   Later