| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-05 | |||
| 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 | |
| 16:17:38 | sshnaidm | maybe we can keep migrated ones and develop their replacement aside with new names..? | |
| 16:17:46 | pabelanger | IMO, this goal for migration out of ansible/ansible, would be to use migration tool from ansible-core, then keep naming schema of modules the same | |
| 16:17:56 | gtema | or "community version" will do some extra magic? | |
| 16:18:01 | pabelanger | then do deprecation process on os_nova, os_neutron | |
| 16:18:07 | gundalow | We may add some magic during Ansible 2.10 development that means if you are using the Ansible Community Distribution that you wouldn't need to change your playbooks - Though the exact details of this haven't been worked out uet | |
| 16:18:09 | gundalow | yet* | |
| 16:18:13 | pabelanger | sshnaidm: yah, that would be fine | |
| 16:18:31 | dtantsur | realistically, we should probably do what sshnaidm proposes | |
| 16:18:37 | jistr | +1 | |
| 16:18:46 | dtantsur | I'm not sure we're going to have enough cycles to simultaneously refactor things | |
| 16:19:00 | dtantsur | so maybe keep os_ prefix to designate old modules | |
| 16:19:02 | sshnaidm | we'll just advertise new names for a few versions and then will remove old ones I think | |
| 16:19:03 | dtantsur | and drop it for new ones | |
| 16:19:14 | sshnaidm | dtantsur, ya | |
| 16:19:15 | dtantsur | os_ironic_node is old, baremetal_node is new | |
| 16:19:18 | pabelanger | +1 | |
| 16:19:22 | gtema | perhaps better name them properly now and make alias | |
| 16:19:30 | gundalow | FYI Ansible's deprecation cycle has been 4 major versions, so two years | |
| 16:19:41 | dtantsur | gtema: not everything will be a mere rename | |
| 16:19:57 | dtantsur | gundalow: is it the same for collections? | |
| 16:19:58 | jistr | gtema: separating will allow developing new ones in a common way without worrying about breaking existing use | |
| 16:20:15 | gtema | I know we are talking about more than simple rename | |
| 16:20:15 | dtantsur | gundalow: to generalize my question: is there an expected release cadence? | |
| 16:20:18 | gundalow | dtantsur: unsure | |
| 16:20:22 | gtema | but if we do rename and alias | |
| 16:20:36 | gtema | we can develop some standard, follow it | |
| 16:20:38 | gundalow | dtantsur: at least twice a year (so new Ansible Engine releases can pick up the new contents) | |
| 16:20:49 | gundalow | I'd hope that over time we can get quicker at doing releases | |
| 16:20:51 | gtema | and be consistent in the new modules for those 4 cycles | |
| 16:20:57 | dtantsur | okay, so synchronized with ansible releases? | |
| 16:20:59 | pabelanger | I would go as far, until code is deleted in ansible/ansible (which date is up in the air), we continusoly run migration sync nightly, and make new collection repo read-only, then once ansible/ansible code is deleted, we unfreeze openstack collection | |
| 16:21:06 | gtema | otherwise we have a mix of different patterns | |
| 16:21:08 | pabelanger | this is our plan for ansible network team | |
| 16:21:32 | dtantsur | pabelanger: I'd prefer to freeze only the existing modules, but allow new development | |
| 16:21:37 | gundalow | So, for a moment ignoring refactoring. I don't think you want to break Playbooks that work in Ansible 2.9 | |
| 16:21:46 | sshnaidm | pabelanger, +1 to dtantsur | |
| 16:22:11 | sshnaidm | pabelanger, we'll have old ones for usage, but the main goal is new ones.. | |
| 16:22:22 | pabelanger | sshnaidm: dtantsur: that is fine, but keep in mind, if a nightly sync happens, like proposed bot, we want to avoid conflicts | |
| 16:22:36 | dtantsur | right, so make sure not to modify the same files | |
| 16:22:39 | pabelanger | for me, we need to keep old ones for 2 years | |
| 16:22:43 | pabelanger | even in a collection | |
| 16:22:52 | dtantsur | like, set up gerrit to outright reject changes to os_*.py until we unfreeze | |
| 16:22:57 | dtantsur | s/gerrit/zuul jobs/ | |
| 16:23:01 | gundalow | Once the collection is up and running we can `git rm` the files from ansible/ansible | |
| 16:23:08 | sshnaidm | pabelanger, I think we're good with that | |
| 16:23:30 | pabelanger | yah, once migration happens, if everything is sync'd we can push on git rm on ansible/ansible | |
| 16:23:33 | pabelanger | then freeze is over | |
| 16:23:42 | pabelanger | but, that sync should be a zuul jobs | |
| 16:23:57 | dtantsur | #agreed Import the existing modules as they are and freeze them. Keep syncing until ansible removes them from tree. | |
| 16:23:59 | dtantsur | right? | |
| 16:24:01 | pabelanger | I'm happy to share job for that, as we do it | |
| 16:24:09 | pabelanger | (ansible-network) | |
| 16:24:31 | sshnaidm | #action to collaborate with pabelanger to create sync zuul jobs | |
| 16:24:40 | gtema | for how long do we expect to have this freeze? | |
| 16:24:42 | sshnaidm | pabelanger, thanks, it'd be great | |
| 16:24:55 | sshnaidm | gtema, to keep old modules you mean? | |
| 16:24:58 | dtantsur | sshnaidm: #actions requires <who> | |
| 16:25:07 | sshnaidm | #action sshnaidm to collaborate with pabelanger to create sync zuul jobs | |
| 16:25:20 | pabelanger | gtema: freeze should be as long as we all agree, final sync looks good and we can rm -rf ansible/ansible | |
| 16:25:32 | pabelanger | we should be able to drive delete date | |
| 16:25:36 | dtantsur | gtema: until they are removed from ansible/ansible. then it's bugfix-only mode. | |
| 16:25:52 | pabelanger | that means, getting content uploaded into galaxy and some sort of pre-release versioning | |
| 16:26:00 | gtema | ok then. I just wanted to avoid freeze, which will keep us ourselves with tied hands | |
| 16:26:33 | gundalow | FYI for bug fixes for ansible/ansible:stable-2.9, once you've gitrm'd from devel you can create a PR directly against that branch, rather than `git cherry-pick -x` from devel into stable-2.9 | |
| 16:26:43 | sshnaidm | and these bugfixes should be done in openstack repos since moving, right? | |
| 16:26:46 | gundalow | Which may mean one fewer things to keep moving | |
| 16:27:36 | gundalow | Once the collection is done, I'd expect bug fixes do be done in the collection first. Then optionally made to ansible/ansible:stable-2.9. Realistically I expect fewer backports to ansible/ansible once Collections are up and running | |
| 16:27:56 | sshnaidm | gundalow, lemme understand, 2.9 backports via ansible github, all new - via our repos, right? | |
| 16:28:00 | dtantsur | hmm, that's the opposite direction | |
| 16:28:25 | pabelanger | backwards? | |
| 16:28:40 | gtema | "main dev on our side" | |
| 16:28:54 | gtema | and "port" fixes back to ansible-2.9 | |
| 16:29:06 | pabelanger | that seem correct to me | |
| 16:29:23 | sshnaidm | gtema, I think we shouldn't port there, maybe only some critical fixes | |
| 16:29:43 | gtema | that's exactly about critical things, but I do not expect those honestly | |
| 16:29:56 | pabelanger | it raises the question of maybe stable backports team? | |
| 16:30:15 | pabelanger | which can handle sync to github | |
| 16:30:30 | gtema | I don't think that just for 2.9 it make sense to have this overhead | |
| 16:30:35 | gundalow | Current backport docs: https://docs.ansible.com/ansible/latest/community/development_process.html#backporting-merged-prs | |
| 16:30:35 | gundalow | Before Collections: 1) PR to `devel`, 2) wait for that to be merged. 3) For bug fixes only Create backport PR to `stable-2.x` | |
| 16:30:37 | sshnaidm | I don't think we should backport anything to 2.9 at all, it looks working as is, and no much activity was there | |
| 16:30:46 | dasp | Can I get some reviews on https://github.com/ansible/ansible/pull/65339 and https://github.com/ansible/ansible/pull/65292 ? (new qos_policy modules for Ansible) | |
| 16:31:07 | pabelanger | sshnaidm: we can't say that however, as ansible/ansible still maintans that | |
| 16:31:18 | gundalow | Unless I see a critical bug, I'm not going to be backporting anything to stable-2.9 after we've gitrm'd from devel | |
| 16:31:21 | gtema | dasp - wrong channel. We are deciding to drop that at all ;-) | |
| 16:31:29 | sshnaidm | pabelanger, I think we agree it should be something exceptional | |
| 16:31:36 | pabelanger | +1 | |
| 16:31:46 | dtantsur | okay, so do we even need a constant sync then? | |
| 16:31:52 | sshnaidm | gtema, :D | |
| 16:32:01 | gundalow | and "critical bug" is subjective, maybe you'd use that to your advantage :P | |
| 16:32:04 | dtantsur | or just copy everything once and apply some policies by humans? | |
| 16:32:20 | sshnaidm | dtantsur, I'd go for that for simplifying things | |
| 16:32:26 | gundalow | Maybe I could give an example of what I'm doing with Grafana | |