Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-01-11
10:10:32 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Lay a foundation for the project cleanup https://review.opendev.org/700219
17:59:48 openstackgerrit Merged openstack/openstackclient master: Constrain openstackclient-check-plugins run on master https://review.opendev.org/701293
18:04:25 openstackgerrit Merged openstack/openstackclient master: Use python3 for openstackclient-check-plugins job https://review.opendev.org/701378
#openstack-sdks - 2020-01-12
13:13:43 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
13:40:29 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
14:26:14 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
16:18:39 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
16:19:34 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
16:58:03 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: WIP: New nodejs jobs https://review.opendev.org/702132
#openstack-sdks - 2020-01-13
08:22:15 openstackgerrit Vishakha Agarwal proposed openstack/python-openstackclient master: Adding options to user cli https://review.opendev.org/697444
09:56:08 openstackgerrit Bence Romsics proposed openstack/python-openstackclient master: Add command: router add/remove route --route https://review.opendev.org/674325
10:52:19 gundalow sshnaidm: Hi, I'm back now :)
11:05:06 sshnaidm gundalow, welcome back!
11:10:46 sshnaidm gundalow, will you be available this week for helping with ansible bits of moving OS modules?
11:11:34 gundalow Sure, is there a doc where we are listing the steps?
11:14:10 sshnaidm gundalow, I think we can use our etherpad for that: https://etherpad.openstack.org/p/openstack-ansible-modules
11:21:13 gundalow sshnaidm: perfect, thank you. Could you remind me if we decided on 1) namespace 2) Collection name 3) Host repo
11:28:39 sshnaidm gundalow, updated in etherpad
11:38:06 sshnaidm bbl
12:43:51 sshnaidm gundalow, I'd like to send a mail to Ansible devs/cores to ask them not to merge patches to OS modules w/o exceptional ack from specific OS cores. Where can I send it to?
12:44:10 sshnaidm gundalow, because we want to freeze them in current state now
14:53:05 gundalow hum, Ansibulbot will also automerge. I wonder if we can somehow make the PRs fail CI
15:51:11 sshnaidm gundalow, I think we can, need just to configure openstack job to fail always, but also I'd like to make people aware about it
15:51:24 sshnaidm gundalow, do you have kind of "ansible-dev" list..?
16:05:50 KeithMnemonic am i reading this failure correctly, that it also due to the thread on openstack-discuss about setuptools and python2? https://zuul.opendev.org/t/openstack/build/372bc8c66d794210aeb571491ed6e893
16:25:27 dtantsur KeithMnemonic: everything is broken, yes. the infra team is about to work it around though.
16:28:55 KeithMnemonic thanks!
16:34:11 mordred should be fixed now
16:45:27 KeithMnemonic thanks mordred. Does anyone have any objections for me starting the cherry-pick to stein on this change while I am waiting for a WF+1? ? https://review.opendev.org/701299. That way i can start seeing if there are other issues on stable/stein.
16:45:47 KeithMnemonic or would you prefer i wait until it merges
16:48:45 mordred KeithMnemonic: go for it! stein has been a little shaky recently, so might as well go ahead and make sure things work
16:49:41 KeithMnemonic thanks morded
16:50:09 KeithMnemonic argh mordred: :-)
16:54:53 mordred :)
16:55:08 dtantsur note that if you press the cherry-pick button now, the patch will be missing the required "cherry picked from" line
16:55:52 KeithMnemonic got it thanks, there is a merge conflict so i need to do it by hand anyway
17:24:57 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Add unit tests and release note for dns_publish_fixed_ip https://review.opendev.org/702266
18:24:18 openstackgerrit Merged openstack/python-openstackclient master: Raise hacking to more recent 2.0.0 https://review.opendev.org/702019
18:24:20 openstackgerrit Merged openstack/python-openstackclient master: Raise flake8-import-order version to latest https://review.opendev.org/702036
19:03:26 efried johnsom: Before I go digging, can you remind me where we are on the osc-lib business that was holding up https://review.opendev.org/#/c/692931/ ?
19:04:28 efried looks like https://review.opendev.org/#/c/693267/ is still open.
19:04:33 johnsom efried This is stuck: https://review.opendev.org/#/c/662864/
19:04:41 johnsom On this: https://review.opendev.org/#/c/693267
19:05:16 efried johnsom: is it just that we need the latter approved before the former can pick it up properly?
19:05:25 efried approved/released/constrainted/etc?
19:05:52 johnsom I think so, but it has been a long time, so the details are fuzzy
19:10:57 efried johnsom: Can we swap back in? Cause off the top I'm not sure I understand how https://review.opendev.org/#/c/662864/ needing https://review.opendev.org/#/c/693267 should hold up https://review.opendev.org/#/c/692931/
19:14:12 johnsom efried Yeah, the whole issue was the addition of "enhanced_help" you did. It broke other pending patches and is a bit of an oddity. So, the discussion was if we revert the "enhanced_help" change or if we move forward with it and add it to osc-lib.
19:14:32 efried johnsom: but how does that relate to autogenerating docs for identity?
19:14:34 johnsom efried if we reverted, this https://review.opendev.org/#/c/692931/ should not merge either
19:16:01 johnsom efried that patch drops the versioning callout on the --tag options
19:16:28 efried tbc, ...31 doesn't do anything with enhance_help. If we revert that, we would have to revert down that (already merged) series as well.
19:16:40 johnsom Yep
19:16:41 efried if my delta makes the versioning of --tags wrong, that's its own issue.
19:16:48 johnsom It was a pretty nasty mess as I remember
19:19:32 efried johnsom: I'm rechecking to get a new docs build to be sure, but looking at the code, it should be the case that we're only adding the docs for --tags to the v3 doc.
19:19:35 johnsom It looks like Dean was ok with moving forward with the "enhanced_help" path, but it looks like the cores never confirmed that
19:19:37 efried which is what we want to do.
19:19:46 efried johnsom: "the cores" would be... Dean.
19:19:57 johnsom lol, well
19:20:40 efried I think dtroyer was waiting for you to confirm that that solution would work for you.
19:20:47 efried before +2ing
19:20:53 johnsom There are five folks on the list, but yeah, I understand this area is lacking at the moment
19:21:04 efried I actually can't tell who's core in osc-lib
19:21:10 efried is it python-openstackclient-core?
19:21:16 johnsom yes
19:21:20 efried in which case we really only have three: mordred, dtroyer, amotoki
19:21:40 efried Matt is gone, and Doug hasn't been active there for a while.
19:22:35 johnsom So maybe Dean is around and we can just get that osc-lib change rolling
19:23:31 efried johnsom: so let me propose this: If the docs build confirms that --tags only show up in the v3 docs and not in the v2 docs, will you unblock the identity patch? Then we can decide whether to revert the enhance_help business -- in which case we'll need to do *something* else to fix that whole stack -- or approve the osc-lib patch, whereupon https://review.opendev.org/#/c/662864/ can be vetted to make sure it subsumes identity etc.
19:24:42 johnsom I would really like to see a path forward on the centralized tags code before we merge another patch that changes the way we document / handle tags.
19:25:01 efried I get that, but my point is that that ship has already sailed
19:25:09 johnsom That change was pretty big breakage on an already half merged migration
19:25:50 efried For that I apologize; I didn't know that change was in flight, and I was on a (totally unrelated) mission.
19:26:19 efried that said, this kind of conflict is pretty standard fare for this kind of development
19:26:20 johnsom Yeah, I get it.
19:27:52 openstackgerrit Merged openstack/python-openstackclient master: Add dns_publish_fixed_ip attribute to subnets https://review.opendev.org/679834
19:27:53 openstackgerrit Merged openstack/python-openstackclient master: Remove redundant OpenStackShell.prepare_to_run_command https://review.opendev.org/691865
19:31:11 johnsom This is the tie-in with the identity stuff BTW: https://review.opendev.org/#/c/691767/4/openstackclient/identity/common.py
19:32:25 efried got it
19:35:15 efried mordred: you willing to be the second core on this?
19:36:28 efried where "this" is: enhancing osc-lib's handling of --tag options to accept a callable so it can be decorated as pertaining to only a specific version of the API?
19:39:33 efried johnsom: actually, wouldn't it only matter if add_project_domain_option_to_parser had *also* been added to osc-lib? (afaict it wasn't)
19:41:51 efried And that guy is using enhance_help to decorate the help as pertaining only to neutron (as opposed to a particular version)
19:42:56 johnsom Wasn't this all because you didn't want to fix the code structure to deal with the mixed neutron/nova commands?
19:43:13 efried that's where it started, yes.
19:43:43 johnsom The new docs system can't handle the current method and some projects were using static pages.
19:43:45 johnsom Right.
19:44:38 efried where "fix the code structure" would have entailed splitting neutron and nova-network classes into 100% separate packages, like what we see for identity
19:46:16 efried doing all of this -- enhance_help in python-openstackclient and osc-lib and reworking your change -- is still an order of magnitude less effort than that would be.
19:46:35 efried Arguably "the right thing", but... 80/20 rule.
19:47:05 johnsom Yeah, and I agreed that I can live with that, we just need to commit to it or revert IMO
19:49:17 efried that's fine, but I still don't agree that that should hold up https://review.opendev.org/#/c/692931/ (and its successor) which have nothing to do with enhance_help
19:50:14 efried But that's your prerogative. So let's just push on dtroyer mordred amotoki to merge https://review.opendev.org/#/c/693267/ so we can move forward.
19:50:23 johnsom Well, once the docs re-render maybe we can look at the changes and issues that related them. I think that if we revert, we will want to stick with the static pages until a new path forward is found
19:52:43 efried The identity patch wouldn't be affected by that, though.
19:52:44 efried the fact that there's an enhance_help in an identity lib is coincidental; it's only used by networking.
19:52:44 efried that method is called in a hundred other places, but the enhance_help kwarg is only used from networking
19:52:44 efried so whichever approach we choose, the identity docs split/autogen patch wouldn't be different.
20:04:36 efried dtroyer: tl;dr:

Earlier   Later