Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-12
16:08:49 dtantsur one things that I think is important re licensing:
16:08:50 sshnaidm mordred, this won't change anyway, we don't relicense them
16:08:51 mordred it's that they can't be part of an OpenStack release
16:09:01 mordred which they wouldn't be anyway, since that makes no sense
16:09:05 dtantsur if we write something that looks like logic independent of ansible, we should better put it somewhere else
16:09:16 dtantsur otherwise we won't be able to easily reuse it in other parts of openstack
16:09:17 mordred dtantsur: right. and that's stuff we tend to put in sdk
16:09:22 dtantsur e.g. it will be troublesome to put it to sdk
16:09:23 dtantsur exactly
16:09:31 pabelanger right, this should be the ansible community openstack collection
16:09:34 dtantsur last time I proposed that any logic goes to sdk
16:09:35 mordred (which is one of the reasons we have sdk and are so adamant about butting things in there)
16:09:40 mordred ++
16:09:54 odyssey4me yep, the thinner the module is as a layer - the better
16:09:55 mordred the modules should be thin glue code between the ansible module structure and logic entities in sdk
16:09:59 odyssey4me *modules
16:10:02 mordred this will be easier to accomplish with the modules in gerrit now
16:10:12 dtantsur #agreed Try to put most of the logic into openstacksdk, keep the ansible modules as thin glue
16:10:19 dtantsur right?
16:10:20 sshnaidm having lite modules with sdk logic is totally fine for me too, but here comes question of compatibility between versions
16:10:23 mordred yah
16:10:37 mordred the sdk supports all versions of openstack
16:10:43 mordred so that direction is fine
16:10:43 dtantsur sshnaidm: any logic code is anyway tied to openstack, not to ansible
16:11:10 sshnaidm dtantsur, right, agree
16:11:17 Shrews yes, there is no reason to not continue that abstraction/separation. also, hi!
16:11:20 mordred the version support matrix is then for different versions of ansible - maybe something changes in newer versions of ansible and we need to update the module interface for that
16:11:34 dtantsur wow, I wild Shrews appears :)
16:11:39 dtantsur * a wild
16:11:41 dtantsur (sigh)
16:11:45 Shrews i'm tame now
16:11:58 gtema atm collection does not define dependency to Ansible (requires version)
16:12:16 gtema so assume this should not happen in near future
16:12:29 dtantsur gundalow: ^^^?
16:12:32 mordred yah. so hopefully we can have our modules support all extant versions of ansible too
16:12:40 sshnaidm I hope won't happen at all
16:12:45 mordred (even if the modules have to have some if logic in them to do so)
16:12:55 mordred but the module interface has been *VERY* stable for the past several years
16:13:06 odyssey4me I guess we're going to have to limit the collection version support for Ansible. Ansible does tend to make pretty heavy changes from time to time.
16:13:07 gtema don't kill me: should we introduce support for microversions in Ansible?
16:13:10 mordred the only main systemic changes have been around things like docstsring formats
16:13:11 dtantsur #agreed Try to support as many versions of ansible as possible with the same code
16:13:22 mordred gtema: no
16:13:34 mordred all microversion support should be in the sdk
16:13:41 gtema it was a joke, but with small sense of truth
16:13:45 mordred heh
16:13:48 sshnaidm so, back to hosting modules - do we completely freeze existing and start new ones? Remember that people will use them from 2.10 from our repo
16:14:00 mordred I *strongly* oppose starting new modules
16:14:07 gtema i mean if someone would like to get info about smth, what is reported only with microversion set
16:14:08 dtantsur mmm?
16:14:15 Shrews why would we *want* new ones?
16:14:17 dtantsur mordred: would you rather prefer a breaking change?
16:14:23 sshnaidm mordred, we'll need to rename them at least
16:14:26 dtantsur Shrews: we need 1) rename some modules, 2) fix auth in some
16:14:37 sshnaidm and people use them in their playbooks
16:14:38 pabelanger one thought I had with collection version, since it is semver. Is have 1.0.0,<2.0.0 support ansible 2.10.0 (stable-2.10), then 2.0.0,<3.0.0 support ansible 2.11.0 (stable-2.11)
16:14:45 pabelanger etc
16:15:02 mordred I think that's potentially unnecessary and hard
16:15:12 mordred many of these modules have been unchanged from ansible 2.0
16:15:15 dtantsur it depends on how different 2.11 will be from 2.10
16:15:23 mordred ansible itself does _not_ change that much as it relates to the module interface
16:15:24 sshnaidm mordred, I think current names and code should be re-thought at least
16:15:38 odyssey4me hmm, ok - is the scope of the collection *just* modules/libraries?
16:15:44 dtantsur I recall auth being mess in ironic modules (maybe all really)
16:15:46 openstackgerrit Andrew Karpow proposed openstack/python-openstackclient master: Use network service for Server AddFixedIP https://review.opendev.org/698749
16:16:03 mordred odyssey4me: the scope of _this_ collection, yes
16:16:21 gtema let's talk about collection name
16:16:21 dtantsur what else can we have?
16:16:22 mordred I think this sig can have additional collections published to galaxy that contain roles and stuff
16:16:22 odyssey4me mordred: ok, sounds sensible - we should probbaly document that somewhere
16:16:35 Shrews what is the proposed new module naming structure? and why doesn't the current one work?
16:16:41 mordred but this, for now, is about moving the os_ modules from ansible/ansible and into a collection
16:16:55 dtantsur Shrews: at least s/os_ironic/baremetal/
16:16:56 gtema Shrews: os_ prefix is unnecessary
16:17:00 dtantsur actually, drop os_?
16:17:00 mordred Shrews: 2 potential naming things ... yeah
16:17:02 pabelanger is there no plugins that need to move?
16:17:07 pabelanger dtantsur: plese no
16:17:12 pabelanger that will break playbooks
16:17:16 mordred os_ prefix - and the service-type in the module names for "admin" modules
16:17:17 sshnaidm I'd leave existing with deprecation notice and start from copying and reworking them
16:17:21 dtantsur pabelanger: that's why we're talking about new modules
16:17:29 mordred but - pabelanger makes a good point WRT naming
16:17:32 dtantsur leave os_ironic whatever it is, develop baremetal properly
16:17:39 mordred this is a thing I'd like to really get a real answer on though
16:17:41 sshnaidm pabelanger, yeah, I wouldn't touch them at all
16:18:13 sshnaidm mordred, working on old modules doesn't give us any freedom and will most likely break existing playbooks
16:18:16 mordred gundalow mentioned a magical thing that would allow someone to install ansible + a set of collections to get symlinks for the old modules for compat
16:18:20 gtema wrt playbook change, I was still not able to get answer in Ansible
16:18:33 mordred if that exists, and doesn't have support for module-level symlinks, then I think renaming is very mean
16:18:35 pabelanger I would recommend everybody look at https://github.com/ansible-community/collection_migration, that is the tooling being written today to migrate content out of ansible/ansible to collections. So far, that has some large assumptions
16:18:43 gtema so for the moment it is not known, whether it is possible at all
16:18:43 mordred if it doesn't exist - we should rename because everyone is going to be broken anyway
16:19:04 mordred if it does exist AND we can provide a mapping of fully qualified names to old names, then we should rename
16:19:14 pabelanger gtema: which answer?
16:19:26 mordred I think we need an answer on what the omnibus installer looks like before we commit one way or the other to renaming anything
16:19:29 sshnaidm #link https://github.com/ansible-community/collection_migration
16:19:30 gtema exaclty, whether it is possible to leave playbooks unaffected
16:19:37 gtema without introducing FQCN
16:19:39 mordred yah

Earlier   Later