| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 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 | |
| 16:19:41 | pabelanger | gtema: yes, that is possible | |
| 16:19:47 | gtema | how? | |
| 16:20:06 | pabelanger | collection loader supports relative imports | |
| 16:20:20 | mordred | can you say more words about that? | |
| 16:20:35 | pabelanger | so both cisco.ios.ios_config and ios_config are valid tasks in playbooks using collections | |
| 16:20:46 | sshnaidm | I think gundalow told about this previous time, it works like imports in python | |
| 16:20:48 | mordred | pabelanger: I thought you had to add an import statement to your playbook for that to work | |
| 16:20:48 | gundalow | mordred: there will be a "Ansible Community Distribution" (bikeshed) which will install Ansible + the collections that hold the content that was in Ansible 2.9. | |
| 16:20:49 | pabelanger | if collection is cisco.ios | |
| 16:20:57 | gundalow | sshnaidm: correct | |
| 16:20:57 | gtema | not really, in the 2nd case you introduce import at the beginning of playbook | |
| 16:21:01 | mordred | pabelanger: right - but you have to add a collection reference into the playbook | |
| 16:21:05 | sshnaidm | mordred, when using symlink you shouldn't | |
| 16:21:10 | mordred | hang on | |
| 16:21:10 | pabelanger | mordred: no, not any more | |
| 16:21:13 | mordred | two different things | |
| 16:21:15 | mordred | ok. | |
| 16:21:25 | pabelanger | from playbooks, what I said is fine | |
| 16:21:32 | gundalow | If you are using ACD you may not need to explicitly import anything that ships in ACD, it's done automagically for you | |
| 16:21:39 | pabelanger | for module_utils, you should use fqcn (fully qualify collection name) | |
| 16:21:46 | mordred | gundalow: what's ACD? | |
| 16:22:02 | gundalow | sorry, Ansible Community Distribution | |
| 16:22:12 | mordred | is that what I get when I do "pip install ansible" ? | |
| 16:22:14 | dtantsur | do we expect a lot of people to use it? | |
| 16:22:22 | dtantsur | yeah, same question (dnf install ansible, etc) | |
| 16:22:33 | pabelanger | mordred: magic installer doesn't exist today | |
| 16:22:39 | mordred | ok. I won't be using that | |
| 16:22:40 | gtema | brew install ansible? | |
| 16:22:42 | pabelanger | so, pip install ansible / ansible-galaxy collection install foo | |
| 16:22:50 | gundalow | In an ideal word, yes, `$package_mgr install ansible` will give you ACD | |
| 16:23:09 | dtantsur | and in ours? :) | |
| 16:23:13 | mordred | gundalow: does $package_mgr include pip? (sorry to be pedantic here- just trying to make sure I understand everything) | |
| 16:23:16 | gundalow | dtantsur++ | |
| 16:23:27 | gundalow | mordred: yup including pip | |
| 16:23:30 | mordred | cool | |
| 16:23:48 | mordred | gundalow: so - the magic there is done via symlinks from the botmeta file we discussed the other day right? | |
| 16:23:51 | gtema | I still do not really believe in a perfect world | |
| 16:24:12 | gundalow | Given one of the high level requirements is "don't break people" I'd really hope we can get `pip install ansible` to give you ansible + all the modules | |
| 16:24:17 | mordred | gundalow: do we know if we'll be able to specifiy in that botmeta file mappings on a per-module basis? | |
| 16:24:34 | gtema | when we release first collection we need to insure our func tests from SDK are using really collection | |
| 16:24:45 | gundalow | mordred: yes, BOTMETA supports per file, there are examples, it's just that generally we logically group by directory | |
| 16:24:48 | mordred | gtema: we should probably test both ways | |
| 16:24:56 | mordred | gundalow: cool. | |
| 16:25:04 | mordred | so - let's assume a perfect world for a sec ... | |
| 16:25:11 | pabelanger | gtema: mordred: yes, testing both is safest, that is what ansible network does now | |
| 16:25:32 | mordred | if the botmeta thing works per file and if it exists and does the symlinks and works for pip nad dnf and friends ... | |
| 16:25:36 | dtantsur | gtema: just half past 5, c'mon! | |
| 16:25:42 | mordred | then it should be safe to rename the modules in the collection | |
| 16:25:48 | sshnaidm | ok, so back to the original question, should we keep old modules fully functional as before for not breaking current users? | |
| 16:25:50 | mordred | because we can do a name mapping in botmeta | |
| 16:25:51 | gtema | sure we need to test both, but exactly here we need to "rely" on assumption it works both ways without modifying playbook | |
| 16:25:58 | mordred | people getting the modules through symlinks will not be affected | |
| 16:26:03 | dtantsur | mordred: assuming our auth changes won't end up breaking? | |
| 16:26:08 | mordred | and people using collection explicitly will use colledction paths | |
| 16:26:15 | dtantsur | (and assuming we won't need other per-module breaking changes) | |
| 16:26:27 | mordred | dtantsur: well - it's sounding like there's less implicit breaking than we thought before | |
| 16:26:33 | gtema | let's do all breaking as new modules | |
| 16:26:43 | gtema | with a fresh design | |
| 16:26:44 | mordred | so maybe we should figure out what we want to do with auth and see if we can figure out a way to do it non-breaking | |
| 16:26:47 | dtantsur | gtema: the question was whether we need new modules | |
| 16:26:59 | gtema | sure we need | |
| 16:27:02 | mordred | gtema: I don't want two different designs - we don't have enough people working on this to support that :) | |
| 16:27:11 | pabelanger | +1 | |
| 16:27:12 | mordred | we *barely* have enough people to keep the ones we have going | |
| 16:27:20 | gtema | we currently do not have possibility to manage tags, and I do not really want to modify each module with tagging mess | |
| 16:27:27 | dtantsur | at the very least we need to think how to support all session AND adapter options | |
| 16:27:32 | dtantsur | I think we don't do it now | |
| 16:27:32 | mordred | yes | |
| 16:27:41 | mordred | well - we assume for complex options you'll use clouds.yaml | |
| 16:28:01 | mordred | dtantsur: and you can pass a full clouds.yaml yaml snippet to the cloud parameter of the module too | |
| 16:28:02 | sshnaidm | there are some modules like ironic_node that should be redesigned at all | |
| 16:28:18 | dtantsur | I'm talking simple: {auth_type: none, endpoint_override: https://bare.metal} | |
| 16:28:23 | mordred | that said- if we NEED to redesign a module and deprecate the old one - we should totally do that | |
| 16:28:31 | mordred | dtantsur: that should work by passing to cloud: | |
| 16:28:46 | dtantsur | mordred: in cloud.yaml - yes (well.. maybe) | |
| 16:28:51 | mordred | no - in the module | |
| 16:29:04 | mordred | you can pass _anything_ to cloud: that you can put in a clouds.yaml cloud entry | |
| 16:29:27 | sshnaidm | mordred, I'm afraid changes in openstack.py may require redesign in most of modules.. | |
| 16:29:28 | dtantsur | I remember I had some problem. I need to check. | |
| 16:29:41 | mordred | sshnaidm: they might - and we might need to do some things | |
| 16:30:00 | mordred | I think what I'm saying is that it sounds like ansible/ansible is providing mechanisms to make this not an inhernet breaking change | |
| 16:30:08 | mordred | so our ground cover for making additional breaking changes is lower | |
| 16:30:17 | mordred | so we should at least TRY to not immediately make breaking changes | |
| 16:30:29 | sshnaidm | mordred, deprecating old modules gives you more freedom to break things, then trying to keep backward compatibility | |
| 16:30:29 | mordred | we might find something that needs to be changed and we can't figure out non-breaking | |