| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2021-03-11 | |||
| 08:13:49 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Object module for management Swift objects https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779718 | |
| 08:49:48 | yoctozepto | specifically I am about https://review.opendev.org/c/openstack/openstacksdk/+/777299 | |
| 09:56:30 | yoctozepto | (I got answers on #openstack-sdk) | |
| 09:58:13 | yoctozepto | (I got answers on #openstack-release) sorry :-) | |
| 09:59:05 | gtema | yoctozepto, we can release SDK "any" point in time | |
| 10:00:13 | yoctozepto | gtema: +/- as far as features are concerned | |
| 10:00:14 | yoctozepto | but yeah | |
| 10:00:16 | yoctozepto | seem so | |
| 12:44:51 | openstackgerrit | Merged openstack/python-openstackclient master: compute: Add functional tests for --block-device https://review.opendev.org/c/openstack/python-openstackclient/+/778763 | |
| 12:49:13 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Object module for management Swift objects https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779718 | |
| 12:51:52 | openstackgerrit | Merged openstack/python-openstackclient master: compute: Add support for loading BDMs from files https://review.opendev.org/c/openstack/python-openstackclient/+/778910 | |
| 15:57:33 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: compute: Remove 'file://' prefix from '--block-device' https://review.opendev.org/c/openstack/python-openstackclient/+/780025 | |
| 16:21:03 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Add pre-commit https://review.opendev.org/c/openstack/python-openstackclient/+/780030 | |
| 16:23:49 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Add pre-commit https://review.opendev.org/c/openstack/python-openstackclient/+/780030 | |
| 16:29:13 | openstackgerrit | Stephen Finucane proposed openstack/openstacksdk master: Add pre-commit https://review.opendev.org/c/openstack/openstacksdk/+/780032 | |
| 16:40:59 | stephenfin | gtema: For after the meeting, I pushed the fix to drop the 'file://' prefix from that '--block-device' opt above ^ | |
| 16:41:06 | stephenfin | Since you mentioned it on the review | |
| 16:52:05 | gtema | yupp, noticed already | |
| 18:10:05 | yoctozepto | [drop-the-legacy-client c36e647] Drop the legacy client | |
| 18:10:06 | yoctozepto | 16 files changed, 8 insertions(+), 1590 deletions(-) | |
| 18:10:11 | yoctozepto | how refreshing | |
| 18:10:30 | gtema | :) | |
| 22:41:45 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove some duplicate methods https://review.opendev.org/c/openstack/openstacksdk/+/780127 | |
| 23:22:39 | openstackgerrit | Merged openstack/python-openstackclient master: compute: Remove 'file://' prefix from '--block-device' https://review.opendev.org/c/openstack/python-openstackclient/+/780025 | |
| #openstack-sdks - 2021-03-12 | |||
| 08:17:39 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Container module for management Swift containers https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779712 | |
| 08:26:17 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Container module for management Swift containers https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779712 | |
| 11:37:37 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Container module for management Swift containers https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779712 | |
| 13:19:57 | openstackgerrit | Polina Gubina proposed openstack/ansible-collections-openstack master: Container module for management Swift containers https://review.opendev.org/c/openstack/ansible-collections-openstack/+/779712 | |
| 13:51:24 | mordred | gtema: so - I pushed up a change yesterday that was the result of me falling down a little rabbit hole looking at sdk in lgtm.com: https://lgtm.com/projects/g/openstack/openstacksdk/?mode=list | |
| 13:52:05 | gtema | wow | |
| 13:52:10 | mordred | many of the things are competely lame, and its warnings about multiple calls of constructors are not super accurate. but the duplicate code warnings seem to be reasonable | |
| 13:52:53 | mordred | (there's several other things where it's right and where I'm annoyed that pyflakes isn't flagging - like redefined variables and unused variables and stuff) | |
| 13:53:55 | gtema | well, there is always place for tools to be different | |
| 13:54:30 | mordred | yah | |
| 13:55:41 | gtema | unrelated question to https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/base/server/templates/sshd_config.j2#L84 | |
| 13:56:04 | gtema | I'm trying to reuse system-config pattern in my case and now digging the "undocumented" things | |
| 13:56:45 | gtema | is the bastion_ipv4 (what is applied to all hosts behind bridge) the ip of the bridge itself? Or how otherwise bridge connected to hosts? | |
| 13:59:03 | mordred | ip of bridge itself. | |
| 13:59:27 | gtema | okay, and is the bridge behind the some form of the bastion? | |
| 13:59:38 | mordred | nope. it is the bastion | |
| 13:59:51 | gtema | cool, thanks | |
| 14:00:04 | mordred | basically - it's where ansible is run from - so we allow it to connect to the remote hosts at root - but we only allow inbound root from bridge | |
| 14:00:12 | gtema | was digging quite a while to figure out how the secrets themselves are provisioned to bridge | |
| 14:00:50 | mordred | there's a git repo of secrets local to bridge that's managed manually there - it's the secretest part of the equation | |
| 14:01:26 | gtema | and just to double check - they are provisioned under /etc/ansible/hosts/host_vars/bastion.o.o.yaml? | |
| 14:02:02 | mordred | under /etc/ansible/hosts/host_vars/ and /etc/ansible/hosts/group_vars/ | |
| 14:02:07 | gtema | cool | |
| 14:02:25 | gtema | not the trivial usage pattern for the CD, but I clearly understand why | |
| 14:02:56 | gtema | another infra question, how search.openstack.org is working? | |
| 14:03:03 | mordred | yah - this is why our system-config jobs add bridge as an inventory host and the zuul job runs ansible on bridge in a shell task | |
| 14:03:06 | gtema | I am willing to also implement searching | |
| 14:03:31 | mordred | do you mean https://codesearch.opendev.org/ ? | |
| 14:03:48 | gtema | nope, the search.openstack.org used by docs.openstack.org | |
| 14:04:52 | mordred | I honestly don't know - I think the foundation might have set that up? fungi or clarkb might know | |
| 14:05:06 | gtema | okay, thanks a lot anyway | |
| 14:05:50 | gtema | btw, with https://review.opendev.org/c/openstack/openstacksdk/+/766783 I have figured out that we break ansible a lot | |
| 14:06:23 | gtema | already clarified with the collection, that we will update all modules to enforce doing to_dict for whatever SDK returns to ansible | |
| 14:06:30 | fungi | search.openstack.org does seem to be something related to the foundation-run openstack.org website, yes | |
| 14:06:41 | gtema | as usual - Ansible is doing some weird things, but we can't really blame it | |
| 14:07:13 | gtema | fungi - the question is basically which software is running there and how it indexes the content | |
| 14:07:55 | fungi | i can ask the webdev folks, it's almost certainly outsourced to a third party to maintain | |
| 14:08:56 | gtema | fungi - no worries. In that case it is most likely to be something more complex then I was supposing | |
| 14:09:19 | gtema | mordred: I think I will shortly start a "r1" branch where we can complete switch of the cloud layer to proxy, so that cloud returns always resources, and not munches | |
| 14:09:42 | fungi | gtema: what were you wanting to search with it? maybe they're willing to add something | |
| 14:09:57 | gtema | and once it is complete we can merge it and cut a release, which is partly breaking interface (depending on your usage pattern) | |
| 14:10:37 | gtema | fungi - no, I am "mimicing" OpenStack infra setup for our cloud and need to find a way to index html content in docs "portal" | |
| 14:10:49 | fungi | aha, got it | |
| 14:11:07 | gtema | just want to understand how it works | |
| 14:11:16 | fungi | if it were a single sphix document, then sphinx's search capability would be an option | |
| 14:11:52 | fungi | but if it's a copy of the openstack project docs, that's all different projects so the indices aren't merged | |
| 14:11:52 | gtema | yeah, but we talk about multiple subprojects pushing their own content | |
| 14:11:59 | fungi | right | |
| 14:12:46 | gtema | ok, will think deeper on possibilities | |
| 14:13:10 | gtema | thanks | |
| 14:13:40 | fungi | classical approach would be to rely on one of the numerous open source solutions which spider your site content and create trigram indices, though you'd need to adjust the sphinx theme to embed the form field calling out to whatever index interface it provides | |
| 14:14:07 | gtema | exact | |
| 19:05:52 | yoctozepto | morning gentlefolks, a little emergency in here | |
| 19:06:06 | yoctozepto | the newly released openstacksdk includes a breaking change | |
| 19:06:09 | yoctozepto | at least for masakari | |
| 19:06:17 | yoctozepto | (and it's not the one for masakari) | |
| 19:06:21 | yoctozepto | this -> https://review.opendev.org/c/openstack/openstacksdk/+/776205 | |
| 19:06:48 | yoctozepto | I don't know about other projects but all might be impacted in subtle ways | |
| 19:07:05 | mordred | gtema: discovery in #zuul - api output can be different between list servers and get server - in this particular case, list shows a server stuck in building, but get doesn't show it existing at all. nodepool does the right thing because it always uses list and client-side filter - but the behavior can be confusing from OSC | |
| 19:07:07 | mordred | yoctozepto: looking | |
| 19:07:56 | yoctozepto | this patch essentially adds new props on listings | |
| 19:08:08 | mordred | yoctozepto: I don't have enough context here, sorry. ... and poop, gtema isn't here | |
| 19:08:11 | mordred | yoctozepto: why is that breaking things? | |
| 19:08:41 | yoctozepto | because, at least masakari, has tests that compare things 1:1 | |
| 19:08:50 | mordred | oh - that's a bug in masakari | |
| 19:08:59 | yoctozepto | :D | |
| 19:09:08 | mordred | the sdk interface contract does not consider adding properties to be a breaking change | |
| 19:09:08 | yoctozepto | could be | |
| 19:09:33 | mordred | it is always fair for us to add without warning. we will not, however, take properties away - that is a breaking change | |
| 19:09:46 | mordred | so tests that test for 1:1 are bad tests | |
| 19:10:05 | mordred | (sorry, I know that doesn't put you in an awesome position at this moment) | |
| 19:10:13 | yoctozepto | ok, note taken | |
| 19:10:18 | yoctozepto | haha, I have not written them | |
| 19:10:25 | mordred | I know :P) | |
| 19:10:26 | yoctozepto | I don't like the "functional" tests that we have | |
| 19:10:56 | yoctozepto | they are like glorified unit tests that require full devstack deployment :D | |