| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 16:05:41 | sshnaidm | any other opinions about that? ^ | |
| 16:05:45 | odyssey4me | hmm, is that an OK thing for openstack repositories? | |
| 16:05:50 | mordred | ohai! | |
| 16:06:05 | gtema | well, reading inside I would say there are no answers (mordred doesn't count) | |
| 16:06:10 | sshnaidm | odyssey4me, well, it's not really openstack repository | |
| 16:06:38 | sshnaidm | gtema, yeah, responses were from people of this meeting actually :) | |
| 16:07:10 | dtantsur | it seems that we can host GPL code, just not make it official openstack delivarables | |
| 16:07:10 | mordred | yeah - although while I don't count - the takeaway I've gotten from past encounters is that as along as it's not part of "the software" called openstack, it's ok | |
| 16:07:18 | mordred | yah | |
| 16:07:26 | odyssey4me | is that a problem? | |
| 16:07:39 | sshnaidm | I'd like to know what it blocks for us | |
| 16:07:42 | mordred | nope. should be fine. this is an effort of a sig | |
| 16:08:00 | dtantsur | nothing blocking. just a bit unfortunate that we cannot proudly call these modules official | |
| 16:08:00 | mordred | I don't thnk it's blocks anything. ansible is already GPL | |
| 16:08:03 | sshnaidm | what is consequences of not having this as deliverable? | |
| 16:08:13 | odyssey4me | we have imports both ways, right - the module imports ansible (GPL) stuff, and also imports openstack (Apache) stuff | |
| 16:08:15 | mordred | so anything that would use these modules must by definition be ok consuming gpl software | |
| 16:08:22 | dtantsur | sshnaidm: no promotion on openstack.org? | |
| 16:08:38 | mordred | I don't think it's a matter of not being able to call these modules official | |
| 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 | dtantsur | sshnaidm: any logic code is anyway tied to openstack, not to ansible | |
| 16:10:43 | mordred | so that direction is fine | |
| 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 | dtantsur | what else can we have? | |
| 16:16:21 | gtema | let's talk about collection name | |
| 16:16:22 | odyssey4me | mordred: ok, sounds sensible - we should probbaly document that somewhere | |
| 16:16:22 | mordred | I think this sig can have additional collections published to galaxy that contain roles and stuff | |
| 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 | mordred | Shrews: 2 potential naming things ... yeah | |
| 16:17:00 | dtantsur | actually, drop os_? | |
| 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 | |