fix: Settings and State assigned instead of annotated.

This PR was orginally intended to simply fix https://github.com/ezmsg-org/ezmsg/issues/134, but I believe this is a good time to refactor the specification of SETTINGS and STATE in a Component to be more pythonic. Thus, this PR enables and encourages the declaration of SETTINGS and STATE via assignment rather than by annotation. The annotation approach will not be deprecated immediately, but will emit a logging warning to notify the end-user of this design change.
This fixes static type-check errors introduced by annotating.
You may run the following command to fix downstream codebases using the find and sed tools:
find . -type f -name "*.py" -exec sed -i 's/SETTINGS:/SETTINGS =/g' {} +
find . -type f -name "*.py" -exec sed -i 's/STATE:/STATE =/g' {} +

I'm a bit confused by this. Am I correct in my understanding that self.SETTINGS is an object but cls.SETTINGS is a type?

Yes, you are correct. I am open to alternative approaches to specifying SETTINGS and STATE as well, but I think this change is still a step in the right direction.
The crux of the issue is that with the annotation approach, I get the following diagnostic from my IDE when specifying SETTINGS and STATE for every Unit.
1. "SETTINGS" overrides symbol of same name in class "Component"
     Variable is mutable so its type is invariant
       Override type "CountSettings" is not the same as base type "Settings" [reportIncompatibleVariableOverride]

@cboulay Preston and I have chatted about this quite a bit, and beyond the linter issues, I keep coming back to how weird it is that the user instantiates sub-units, which get deep-copied per class instance, but the settings and state are simply type-hinted; and the code reads the annotations to create bespoke settings and state objects.  I think the reason LabGraph worked this way was related to their messaging backend (cthulhu) but I think consistency is more important here.  There's no shortage of 'magic' in ezmsg, but using typehints to drive functionality of the code is one of the biggest bits of magic that is arguably a big no-no; as annotations/typehints are pretty exclusively supposed to only provide typing data to linters and make code more readable.
Preston went through this changeset with me and although I'll have to patch a bunch of code, provided this is all functional and tests pass - I think it's a good change

I agree it's a step in the right direction. This is something that tripped me up once for 30 minutes -- I accidentally used assignment instead of annotation, or was it vice versa?
I'm not suggesting we do the following, but I'm curious ... would it be better or worse to have something like cls.SETTINGS_TYPE or cls.TSettings and then use magic to init obj.settings (lower case)? Definitely a lot more editing required, many places, but it would eliminate this particular ambiguity.

I'm ready for this to be merged in if you are. Please go ahead.

I agree it's a step in the right direction. This is something that tripped me up once for 30 minutes -- I accidentally used assignment instead of annotation, or was it vice versa?
I'm not suggesting we do the following, but I'm curious ... would it be better or worse to have something like cls.SETTINGS_TYPE or cls.TSettings and then use magic to init obj.settings (lower case)? Definitely a lot more editing required, many places, but it would eliminate this particular ambiguity.

The biggest issue with this approach is that we would no longer get any type hinting for self.SETTINGS or self.STATE. I'll move forward with what I had originally proposed for now.


Display list attributes in seperate columns

If an attribute is an array, each item in array must be a separate column

if teh list is a nested list, we only need columns for teh top level
so if the value is a = [1, [2,3]] then tehre should be two columns
First column a[0] = 1
Second columns a[1] = [2,3]
The value in the second column should include the square brackets, otherwise the user will not understand that it is a list

fixed in Dev


Does remoteapp work on wfreerdp？

Does the new version of wfreerdp make the remoteapp work？
As i use the version of stable1.1，i find the code did not realize the remoteapp function。

https://github.com/FreeRDP/FreeRDP/wiki/BugReporting


Fix type instabilities for sesolve

This is the first of a long series of Pull Requests for fixing all the type instabilities of the functions.
Here, I have downgraded the maximum version of DiffEqCallbacks.jl to v3.1.0, since after that version it generates type instabilities. Moreover, I made some small changes to the code.

It seems that it is using an old version of DiffEqCallbacs. Very strange.

I make the type instabilities test only vor versions equal or larger than 1.10. I don't know why it fails for smaller versions


Permissive license - ASL 2.0, MIT, BSD

Can you consider moving to a permissive license?

There's already some discussion about potentially changing or modifying the license to be more permissive in issue #26

Thanks for the feedback, it was helpful. We've switched to Apache, and your request was part of this decision. Happy coding!
https://github.com/PerfectlySoft/Perfect/issues/131


should now only read in boxy data file

So this is the start of us addressing the comments in the other PR: https://github.com/mne-tools/mne-testing-data/pull/67
To make things more simple, this PR changes read_raw_boxy so that it now only reads in the raw boxy file, and doesn't require .elp, .mtg, or .evt files. It's also designed to read in either a single boxy file (saved by default as a .txt I believe) or it can read in multiple files (similar to what we had before where it will read the data files for various blocks and montages). Added a new argument to help with this (multi_file=False).
I'll run some tests on this to makes sure style and everything is okay. Feel free to take a look and let me know if anything needs to be changed.
Also, do you think we should add a test file for this to compare the imported data to p_pod? Thought adding that test to this PR would make sense, rather than making a separate PR. Then we could add tests for each new function we add (such as reading .elp, .mtg, or .evt files).

tutorial crashed, so I commented everything after the loading, and it seems to work,
I am a bit confused about your question about the test, I think the answer is yes, we want to start with a simple PR with just this and a test of it against Ppod, and then make new PR's to add in all the other features we (you) have made,

so maybe we want to brach off importBOXY, save all the stuff you did, and then merge this with importBOXY for this PR

also I may have screwed up the commit history above trying to rebase with their master, help please

Yeah sorry for the confusing question. I meant to ask should this PR only be concerned with loading the raw boxy data, and should a test for that (compare loading to p_pod) also be included. Then should the other functions be their own PR (load .elp, load .evt, etc) and also include tests for those functions. Even though I didn't ask it properly, you answered what I meant to ask.
Yeah I didn't try it with the tutorial beyond the loading. I'm not surprised it crashes since the raw data object is now very bare bones (only containing the data basically). We probably don't want to include the plot_80 tutorial at this point anyway, until we have all the other functions implemented as well.
I'm working on designing a test for the imported data, and working on a tutorial for it as well (similar to plot_30). I'll upload those files later today. I'll also remove the plot_80 tutorial for now.
Okay, I'll try and figure out the rebasing issue. Seems that rebasing can cause lots of problems...

Sorry I didn't rebase I was just trying to merge master
On Fri., Jul. 24, 2020, 9:41 a.m. kuziekj<EMAIL_ADDRESS>wrote:

Yeah sorry for the confusing question. I meant to ask should this PR only
be concerned with loading the raw boxy data, and should a test for that
(compare loading to p_pod) also be included. Then should the other
functions be their own PR (load .elp, load .evt, etc) and also include
tests for those functions. Even though I didn't ask it properly, you
answered what I meant to ask.
Yeah I didn't try it with the tutorial beyond the loading. I'm not
surprised it crashes since the raw data object is now very bare bones (only
containing the data basically). We probably don't want to include the
plot_80 tutorial at this point anyway, until we have all the other
functions implemented as well.
I'm working on designing a test for the imported data, and working on a
tutorial for it as well (similar to plot_30). I'll upload those files later
today. I'll also remove the plot_80 tutorial for now.
Okay, I'll try and figure out the rebasing issue. Seems that rebasing can
cause lots of problems...
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/kylemath/mne-python/pull/26#issuecomment-663601258,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA36GFJVRKHV6QUXNWRY6H3R5GTR7ANCNFSM4PFAY6QA
.

Ah okay. Maybe when we decide to merge, we do a 'squash and merge'?

Yeah
On Fri., Jul. 24, 2020, 10:02 a.m. kuziekj<EMAIL_ADDRESS>wrote:

Ah okay. Maybe when we decide to merge, we do a 'squash and merge'?
[image: image]
https://user-images.githubusercontent.com/20359571/88411181-b55f5880-cd94-11ea-802a-7a28c207eeab.png
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/kylemath/mne-python/pull/26#issuecomment-663610823,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA36GFKIV64LPEZUTEY3TRDR5GWBLANCNFSM4PFAY6QA
.

Alright so I updated this. Added a tutorial about loading boxy data (similar to plot_30). I added an explanation about how to load and name the montage and block files, if used, but maybe this is a bit too much. Let me know.
I also added a test file to compare loading boxy data to p_pod.
I removed the plot_80 tutorial for now, and some references to it, since we can't really use it until we have all the other functions implemented. Maybe we also want to change the tutorial since we know more about the ANC dataset.

Alright, updated this so it will only load the default file (.txt) saved by boxy and the tutorial only refers to this file type.


Crashes on device

Every time I try to run on the device I get the following crash:
thread #2: tid = 0x153bbd, 0x00000001020dac90 libswiftCore.dylib`swift_unknownRelease + 24, stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
    frame #0: 0x00000001020dac90 libswiftCore.dylib`swift_unknownRelease + 24
    frame #1: 0x0000000102fbd578 libswiftObjectiveC.dylib`function signature specialization <Arg[0] = Owned To Guaranteed and Exploded, Arg[1] = Dead> of ObjectiveC.Selector.init (ObjectiveC.Selector.Type)(stringLiteral : Swift.String) -> ObjectiveC.Selector + 240
    frame #2: 0x0000000102fbcb48 libswiftObjectiveC.dylib`ObjectiveC.Selector.init (ObjectiveC.Selector.Type)(stringLiteral : Swift.String) -> ObjectiveC.Selector + 20
    frame #3: 0x0000000101671e74 EasyAnimation`static ext.EasyAnimation.__ObjC.CALayer.(self=CALayer) (__ObjC.CALayer.Type)() -> () + 140 at EasyAnimation.swift:446
    frame #4: 0x0000000101671dcc EasyAnimation`static ext.EasyAnimation.__ObjC.CALayer.initialize (self=CALayer)() -> () + 132 at EasyAnimation.swift:438
    frame #5: 0x0000000101671f54 EasyAnimation`@objc static ext.EasyAnimation.__ObjC.CALayer.initialize (__ObjC.CALayer.Type)() -> () + 24 at EasyAnimation.swift:0
    frame #6: 0x00000001998fcfc8 libobjc.A.dylib`_class_initialize + 800
    frame #7: 0x00000001999038f8 libobjc.A.dylib`lookUpImpOrForward + 184
    frame #8: 0x000000019990ddb8 libobjc.A.dylib`_objc_msgSend_uncached_impcache + 56
    frame #9: 0x00000001031b6338 GPUToolsCore`DYCALayerInterposeInit() + 108
    frame #10: 0x00000001011891f0 libglInterpose.dylib`DYGLInitPlatform + 56
    frame #11: 0x00000001031a421c GPUToolsCore`GPUTools::Interpose::DYInterposeCommonInit(bool (*)(DYTransport*)) + 464
    frame #12: 0x00000001031b292c GPUToolsCore`GPUTools::Interpose::DYInterposeThreadEntry(void*) + 16
    frame #13: 0x000000019a323b28 libsystem_pthread.dylib`_pthread_body + 156
    frame #14: 0x000000019a323a8c libsystem_pthread.dylib`_pthread_start + 156

It crashes here:
private static func replaceAnimationMethods() {
    //replace actionForKey
    method_exchangeImplementations(
->      class_getInstanceMethod(self, "actionForKey:"),
        class_getInstanceMethod(self, "EA_actionForKey:"))
}

It works perfectly on the simulator.

I also saw the same crash.
It seems to occur when you are using the GLKView.

Can either of you guys send me a super simple demo project for this?

Here you go: https://dl.dropboxusercontent.com/u/3547246/EasyAnimationGLViewCrash.zip
The only thing you have to do for getting the crash is link with OpenGLES.framework.

Oh - now I see... Very strange indeed

@icanzilb do you expect to release a fix soon?

I don't have a fixed release schedule, I work on this any time I have some free time ...

ah .. too bad .. I'll have to switch back to the old way of handling CA animations :(

I accept PRs :)

Good news, the latest merged PR fixes that issue :+1:

Thanks for letting me know .. I had to move away from using the framework :( will try to reconsider in the future.


Reset terminationGracePeriodSeconds for SM Engine and RouteAgent Pods

In one of the earlier PRs, we modified the terminationGracePeriodSeconds
to 10 secs. However, its seen that this is causing more CI failures
during e2e redundancy tests. Ideally, once the Pods are terminated,
it should cleanup itself ASAP but it is seen that SM Pods are sometimes
taking time to exit and during this Period since there is no active SM
Pod running, this is triggering some failures.
Until we figure out the exact reason why the Pods are taking time for
cleanup, this PR resets the terminationGracePeriodSeconds back to 0 secs.
Related to: https://github.com/submariner-io/submariner-operator/issues/444
Related to: https://github.com/submariner-io/submariner-operator/pull/445
Signed-Off-by: Sridhar Gaddam<EMAIL_ADDRESS>

I think it's better to look for the root cause, if we hide it we will have less reasons to look for it

Agree to some extent, but the side-effect of this problem is seen on Globalnet Jobs.
Initially while debugging Globalnet failures, I realized that Globalnet Pod was not cleaning up the rules properly so pushed the PR to tune the terminationGracePeriodSeconds on Globalnet Pods alone. But based on the review comments, I had to modify the values of other Pods as you know.
https://github.com/submariner-io/submariner-operator/pull/445#issuecomment-640433487
So IMO the change we did for Engine/RouteAgent Pods has to be properly tested and then modified. Until then, my idea was to revert it so that we can stabilize the Globalnet jobs which are failing randomly.
I reported the following issue to track it further - https://github.com/submariner-io/submariner/issues/694

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

yeah setting to 0 may trigger different failures wrt to Gateway deletion on shutdown.
Where specifically are the redundancy tests intermittently failing? Perhaps there's a timeout we can bump in those tests to offset the extra 10 sec?

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

yeah setting to 0 may trigger different failures wrt to Gateway deletion on shutdown.
Where specifically are the redundancy tests intermittently failing? Perhaps there's a timeout we can bump in those tests to offset the extra 10 sec?

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

Right but, either way, eventually the pods get killed so I'm wondering why the extra 10 sec causes failures.

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

Right but, either way, eventually the pods get killed so I'm wondering why the extra 10 sec causes failures.

Basically, it's like this. Most of the failures seen in Globalnet jobs are either in redundancy restarting of the GatewayPod or subsequent test. When e2e redundancy test terminates the GatewayPod, its taking time to exit. As part of this restart scenario, the local endpoint is first deleted and once the GatewayPod is restarted a new endpoint is published (with the node being the same).
GlobalnetPod has a listener to Endpoints and as soon as it sees Endpoint delete notification, it flushes various iptable chains and which are only re-created once the new Endpoint is created. So any delay in these will be affecting the e2e tests as our e2e tests are bit time sensitive and not designed for Globalnet use-cases (i.e., we do not wait for the globalIP annotation on the Pod before we start validating the connectivity).

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

yeah setting to 0 may trigger different failures wrt to Gateway deletion on shutdown.
Where specifically are the redundancy tests intermittently failing? Perhaps there's a timeout we can bump in those tests to offset the extra 10 sec?

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

Agree, can we do it as part of the new issue that is reported - https://github.com/submariner-io/submariner/issues/694
and if you really want, I can keep 1 sec (although I would prefer to revert the time back to 0 secs until the issue is resolved).
Please let me know, thanks.

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

yeah setting to 0 may trigger different failures wrt to Gateway deletion on shutdown.
Where specifically are the redundancy tests intermittently failing? Perhaps there's a timeout we can bump in those tests to offset the extra 10 sec?

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

Agree, can we do it as part of the new issue that is reported - submariner-io/submariner#694
and if you really want, I can keep 1 sec (although I would prefer to revert the time back to 0 secs until the issue is resolved).
Please let me know, thanks.

I'm good with 1 sec for now If we don't lose sight of the submariner-io/submariner#694
This will make our E2E and user experience better overall.

May be we can give it 1 second grace period at least?, and keep the issue open.
The gateway agent does cleanup at exit. Ideally we should make sure they are able to do part of that job.

yeah setting to 0 may trigger different failures wrt to Gateway deletion on shutdown.
Where specifically are the redundancy tests intermittently failing? Perhaps there's a timeout we can bump in those tests to offset the extra 10 sec?

There's a low-level issue in the gateway and routeagent pods, they don't terminate on sigterm... and keep hanging. I think we actually need to figure that out and fix it instead.

Agree, can we do it as part of the new issue that is reported - submariner-io/submariner#694
and if you really want, I can keep 1 sec (although I would prefer to revert the time back to 0 secs until the issue is resolved).
Please let me know, thanks.

I'm good with 1 sec for now If we don't lose sight of the submariner-io/submariner#694
This will make our E2E and user experience better overall.

Thanks @mangelajo


Security Disclosure: Potential XSS Issue on Job Result Page

This issue was created in response to a report to our security mailer.
In the belief of strong transparency, we record this here to publicly acknowledge our receipt of this disclosure, our investigation, our summary, and ultimate outcome.
The Report
Environment

Python version: N/A
Nautobot version: 1.2.5

Steps to Reproduce

Create Job
Log a message containing HTML code, example self.log_debug(message=f"Running for {interval} seconds. Can we reproduce this? __b Tag!__")
View Job Result Detail Page

Expected Behavior
Raw HTML does not get outputted to the result page

Observed Behavior
Stylized message appearing to honor HTML tags results in the output, potentially causing XSS if containing


Error when loading: "The ipylivebash module is not an IPython extension."

After installing the extension in Google Colab, I attempt to load it using the %load_ext magic command, but the cell output says "The ipylivebash module is not an IPython extension." The code that I ran to install the extension and attempt to load it are listed below. Clicking "Cell Output" should reveal the output of the code immediately above it.

Code of Each Cell and its Corresponding Output
!pip install ipylivebash

    Cell Output

  Looking in indexes: https://pypi.org/simple, https://us-python.pkg.dev/colab-wheels/public/simple/
Collecting ipylivebash
  Downloading ipylivebash-0.1.2-py2.py3-none-any.whl (99 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 99.4/99.4 KB 2.3 MB/s eta 0:00:00
Requirement already satisfied: ipywidgets>=7.0.0 in /usr/local/lib/python3.9/dist-packages (from ipylivebash) (7.7.1)
Requirement already satisfied: jupyterlab-widgets>=1.0.0 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (3.0.5)
Requirement already satisfied: traitlets>=4.3.1 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (5.7.1)
Requirement already satisfied: ipykernel>=4.5.1 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (5.3.4)
Requirement already satisfied: ipython>=4.0.0 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (7.9.0)
Requirement already satisfied: ipython-genutils~=0.2.0 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (0.2.0)
Requirement already satisfied: widgetsnbextension~=3.6.0 in /usr/local/lib/python3.9/dist-packages (from ipywidgets>=7.0.0->ipylivebash) (3.6.2)
Requirement already satisfied: tornado>=4.2 in /usr/local/lib/python3.9/dist-packages (from ipykernel>=4.5.1->ipywidgets>=7.0.0->ipylivebash) (6.2)
Requirement already satisfied: jupyter-client in /usr/local/lib/python3.9/dist-packages (from ipykernel>=4.5.1->ipywidgets>=7.0.0->ipylivebash) (6.1.12)
Collecting jedi>=0.10
  Downloading jedi-0.18.2-py2.py3-none-any.whl (1.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.6/1.6 MB 21.3 MB/s eta 0:00:00
Requirement already satisfied: setuptools>=18.5 in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (63.4.3)
Requirement already satisfied: decorator in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (4.4.2)
Requirement already satisfied: backcall in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (0.2.0)
Requirement already satisfied: pickleshare in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (0.7.5)
Requirement already satisfied: prompt-toolkit<2.1.0,>=2.0.0 in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (2.0.10)
Requirement already satisfied: pygments in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (2.6.1)
Requirement already satisfied: pexpect in /usr/local/lib/python3.9/dist-packages (from ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (4.8.0)
Requirement already satisfied: notebook>=4.4.1 in /usr/local/lib/python3.9/dist-packages (from widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (6.3.0)
Requirement already satisfied: parso<0.9.0,>=0.8.0 in /usr/local/lib/python3.9/dist-packages (from jedi>=0.10->ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (0.8.3)
Requirement already satisfied: pyzmq>=17 in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (23.2.1)
Requirement already satisfied: nbconvert in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (6.5.4)
Requirement already satisfied: nbformat in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (5.7.3)
Requirement already satisfied: argon2-cffi in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (21.3.0)
Requirement already satisfied: prometheus-client in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.16.0)
Requirement already satisfied: terminado>=0.8.3 in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.17.1)
Requirement already satisfied: jinja2 in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (3.1.2)
Requirement already satisfied: Send2Trash>=1.5.0 in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (1.8.0)
Requirement already satisfied: jupyter-core>=4.6.1 in /usr/local/lib/python3.9/dist-packages (from notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (5.2.0)
Requirement already satisfied: python-dateutil>=2.1 in /usr/local/lib/python3.9/dist-packages (from jupyter-client->ipykernel>=4.5.1->ipywidgets>=7.0.0->ipylivebash) (2.8.2)
Requirement already satisfied: six>=1.9.0 in /usr/local/lib/python3.9/dist-packages (from prompt-toolkit<2.1.0,>=2.0.0->ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (1.15.0)
Requirement already satisfied: wcwidth in /usr/local/lib/python3.9/dist-packages (from prompt-toolkit<2.1.0,>=2.0.0->ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (0.2.6)
Requirement already satisfied: ptyprocess>=0.5 in /usr/local/lib/python3.9/dist-packages (from pexpect->ipython>=4.0.0->ipywidgets>=7.0.0->ipylivebash) (0.7.0)
Requirement already satisfied: platformdirs>=2.5 in /usr/local/lib/python3.9/dist-packages (from jupyter-core>=4.6.1->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (3.1.1)
Requirement already satisfied: argon2-cffi-bindings in /usr/local/lib/python3.9/dist-packages (from argon2-cffi->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (21.2.0)
Requirement already satisfied: MarkupSafe>=2.0 in /usr/local/lib/python3.9/dist-packages (from jinja2->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (2.1.2)
Requirement already satisfied: jupyterlab-pygments in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.2.2)
Requirement already satisfied: defusedxml in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.7.1)
Requirement already satisfied: lxml in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (4.9.2)
Requirement already satisfied: packaging in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (23.0)
Requirement already satisfied: tinycss2 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (1.2.1)
Requirement already satisfied: nbclient>=0.5.0 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.7.2)
Requirement already satisfied: pandocfilters>=1.4.1 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (1.5.0)
Requirement already satisfied: mistune<2,>=0.8.1 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.8.4)
Requirement already satisfied: bleach in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (6.0.0)
Requirement already satisfied: entrypoints>=0.2.2 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.4)
Requirement already satisfied: beautifulsoup4 in /usr/local/lib/python3.9/dist-packages (from nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (4.11.2)
Requirement already satisfied: fastjsonschema in /usr/local/lib/python3.9/dist-packages (from nbformat->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (2.16.3)
Requirement already satisfied: jsonschema>=2.6 in /usr/local/lib/python3.9/dist-packages (from nbformat->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (4.3.3)
Requirement already satisfied: pyrsistent!=0.17.0,!=0.17.1,!=0.17.2,>=0.14.0 in /usr/local/lib/python3.9/dist-packages (from jsonschema>=2.6->nbformat->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.19.3)
Requirement already satisfied: attrs>=17.4.0 in /usr/local/lib/python3.9/dist-packages (from jsonschema>=2.6->nbformat->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (22.2.0)
Requirement already satisfied: cffi>=1.0.1 in /usr/local/lib/python3.9/dist-packages (from argon2-cffi-bindings->argon2-cffi->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (1.15.1)
Requirement already satisfied: soupsieve>1.2 in /usr/local/lib/python3.9/dist-packages (from beautifulsoup4->nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (2.4)
Requirement already satisfied: webencodings in /usr/local/lib/python3.9/dist-packages (from bleach->nbconvert->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (0.5.1)
Requirement already satisfied: pycparser in /usr/local/lib/python3.9/dist-packages (from cffi>=1.0.1->argon2-cffi-bindings->argon2-cffi->notebook>=4.4.1->widgetsnbextension~=3.6.0->ipywidgets>=7.0.0->ipylivebash) (2.21)
Installing collected packages: jedi, ipylivebash
Successfully installed ipylivebash-0.1.2 jedi-0.18.2

%load_ext ipylivebash

    Cell Output

  The ipylivebash module is not an IPython extension.

!jupyter nbextension enable --py --system ipylivebash

    Cell Output

  Enabling notebook extension ipylivebash/extension...
Paths used for configuration of notebook:
    	/usr/local/etc/jupyter/nbconfig/notebook.d/ipylivebash.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/jupyterlab-plotly.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/widgetsnbextension.json
    	/usr/local/etc/jupyter/nbconfig/notebook.json
Paths used for configuration of notebook:
    	/usr/local/etc/jupyter/nbconfig/notebook.d/ipylivebash.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/jupyterlab-plotly.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/widgetsnbextension.json
      - Validating: OK
Paths used for configuration of notebook:
    	/usr/local/etc/jupyter/nbconfig/notebook.d/ipylivebash.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/jupyterlab-plotly.json
    	/usr/local/etc/jupyter/nbconfig/notebook.d/widgetsnbextension.json
    	/usr/local/etc/jupyter/nbconfig/notebook.json

%load_ext ipylivebash

    Cell Output

  The ipylivebash module is not an IPython extension.

I spent a long time trying to troubleshoot this issue. I still don't understand the error or how to fix it, but I found some code that I believe might be relevant.

Here is the print statement in the ipython code that prints the error.
Here is the load_extension function in the ipython code that returned the value "no load function", which means that "the module doesn't have a load_ipython_extension function" according to a comment in the load_extension function.
Here is the return statement in the _load_extension function in the ipython code that returned the value "no load function".
Here is the only file in the ipylivebash repository that I could find that mentioned "load_ipython_extension". The file is named extension.js.

Is there a problem with the extension.js file?

Hi @pine1needle
The magic command livebash should be loaded after running the !jupyter nbextension enable --py --system ipylivebash command. Then, %%livebash can be executed in a cell. Unfortunately, no output is returned, although the script is executed.
%%livebash

touch 123

No output
%%bash
ls

Output:
123
sample_data

I have tested ipylivebash with Jupyter Notebook and Jupyter Labs only. And seem that it need to handle Google Colab in a special way.
I am sorry that I could not fix it in a short time.

Thank you for the reply. It is helpful to know that %%livebash runs the script even though it does not display the output.
Also, running the !jupyter nbextension enable --py --system ipylivebash command in Google Colab might not be necessary. The %%livebash command seems to behave the same way no matter whether the !jupyter nbextension enable --py --system ipylivebash command has been run or not.


Workbooks,download fails for Tableau Server v.2023.1.7

Describe the bug
Workbooks.download fails with an error in regard to 'filename'.
Versions: Tableau Server 2023.1.7 (API 3.19), tableauserverclient-0.14.1, python 3.7.9
(tested also: Tableau Server 2023.1.7 (API 3.19), tableauserverclient-0.28, python 3.9.13)
To Reproduce
server_int = TSC.Server("https://yousite",use_server_version = True)
tableau_auth_int = TSC.TableauAuth("username", "password", site_id='sitename')
with server_int.auth.sign_in(tableau_auth_int):
workbook= server_int.workbooks.get_by_id('fca33a9a-0139-41b9-b1e7-841a92bf5f92')
wkbk=workbook.name
print(workbook.name)
print(workbook.id)
file_path = server_int.workbooks.download('fca33a9a-0139-41b9-b1e7-841a92bf5f92')
print("\nDownloaded the file to {0}.".format(file_path))

Results
WorkbookName
fca33a9a-0139-41b9-b1e7-841a92bf5f92
KeyError                                  Traceback (most recent call last)
~\AppData\Local\Temp\1\ipykernel_7340\2448852531.py in
5     print(workbook.name)
6     print(workbook.id)
----> 7     file_path = server_int.workbooks.download('fca33a9a-0139-41b9-b1e7-841a92bf5f92')
8     print("\nDownloaded the file to {0}.".format(file_path))
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py in wrapper(self, *args, **kwargs)
290         def wrapper(self, *args, **kwargs):
291             self.parent_srv.assert_at_least_version(version, self.class.name)
--> 292             return func(self, *args, **kwargs)
293
294         return wrapper
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py in wrapper(self, *args, **kwargs)
332                     error = "{!r} not available in {}, it will be ignored. Added in {}".format(p, server_ver, min_ver)
333                     warnings.warn(error)
--> 334             return func(self, *args, **kwargs)
335
336         return wrapper
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py in wrapper(self, *args, **kwargs)
332                     error = "{!r} not available in {}, it will be ignored. Added in {}".format(p, server_ver, min_ver)
333                     warnings.warn(error)
--> 334             return func(self, *args, **kwargs)
335
336         return wrapper
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\workbooks_endpoint.py in download(self, workbook_id, filepath, include_extract, no_extract)
182         no_extract: Optional[bool] = None,
183     ) -> str:
--> 184         return self.download_revision(workbook_id, None, filepath, include_extract, no_extract)
185
186     # Get all views of workbook
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py in wrapper(self, *args, **kwargs)
290         def wrapper(self, *args, **kwargs):
291             self.parent_srv.assert_at_least_version(version, self.class.name)
--> 292             return func(self, *args, **kwargs)
293
294         return wrapper
E:\Anaconda3\envs\Tableau_analytics\lib\site-packages\tableauserverclient\server\endpoint\workbooks_endpoint.py in download_revision(self, workbook_id, revision_number, filepath, include_extract, no_extract)
488                 return_path = filepath
489             else:
--> 490                 filename = to_filename(os.path.basename(params["filename"]))
491                 download_path = make_download_path(filepath, filename)
492                 with open(download_path, "wb") as f:
KeyError: 'filename'
NOTE: Be careful not to post user names, passwords, auth tokens or any other private or sensitive information.

It looks like the filename header in the following was changed to filename*, throwing the error: https://github.com/tableau/server-client-python/blob/72eb3c8500193e4f20defa20c8a6f8bbf34b2f43/tableauserverclient/server/endpoint/workbooks_endpoint.py#L483-L495

@hersh-gupta @ElenasemDA we have run into this issue as well. Any rough idea of how long things like this usually take to get resolved?

Same issue here, after upgrading from 2023.1.5 to 2023.1.7
Looks like a change in Rest API version 3.19?
There is no "filename" return in the 'params' set on line 484
File "C:\Program Files\Python38\lib\site-packages\tableauserverclient\server\endpoint\workbooks_endpoint.py", line 490, in download_revision
filename = to_filename(os.path.basename(params["filename"]))
KeyError: 'filename'

Hello. We faced the same problem. We are looking forward to the fix.

Update From our side, we did a test and upgraded our dev server to 2023.3.0 and it looks like the issue has been resolved. However, we've learnt from past experiences to never upgrade our production server to an 20XX.X.0 version as there are usually very buggy and cause more damage than they fix. We're going to wait till 2023.3.1 comes out.

Any update on this issue? we are facing the same.

Also getting this error. Awaiting a fix.

I'm also encountering this error. Looking forward to a resolution.

facing this same issue after our server upgrade. Please push a fix to the python client.

We use the snippet below instead of calling the server.workbooks.download (v.2023.1.7). Check if you can incorporate it to your processes.
with closing(server_int.workbooks.get_request(url, parameters={"stream": True})) as server_response: _, params = cgi.parse_header(server_response.headers["Content-Disposition"]) if isinstance(ind_path, io_types_w): for chunk in server_response.iter_content(1024): # 1KB ind_path.write(chunk) return_path = ind_path else: filename = to_filename(os.path.basename(params["filename*"])) filename = filename.replace("UTF-8","").replace("+"," ") filename = filename.replace("28","(").replace("29",")") download_path = make_download_path(ind_path, filename) with open(download_path, "wb") as f: for chunk in server_response.iter_content(1024): # 1KB f.write(chunk) return_path = os.path.abspath(download_path)

This is my workaround snippet. maybe you'll find it useful as well until the fix:
def _decode_filename(self, params):
if 'filename*' in params:
encoded_filename = params['filename*']
if encoded_filename.startswith("UTF-8''"):
encoded_filename = encoded_filename[
7:]  # strip off the "UTF-8''" prefix
filename = urllib.parse.unquote_plus(
encoded_filename)  # decode percent-encoded octets
elif 'filename' in params:
filename = params['filename']
else:
filename = None
    return filename

# Download 1 workbook revision by revision number
@api(version="2.3")
def download_revision(
    self,
    workbook_id: str,
    revision_number: str,
    filepath: Optional[PathOrFileW] = None,
    include_extract: bool = True,
    no_extract: Optional[bool] = None,
) -> PathOrFileW:
    if not workbook_id:
        error = "Workbook ID undefined."
        raise ValueError(error)
    if revision_number is None:
        url = "{0}/{1}/content".format(self.baseurl, workbook_id)
    else:
        url = "{0}/{1}/revisions/{2}/content".format(self.baseurl, workbook_id, revision_number)

    if no_extract is False or no_extract is True:
        import warnings

        warnings.warn(
            "no_extract is deprecated, use include_extract instead.",
            DeprecationWarning,
        )
        include_extract = not no_extract

    if not include_extract:
        url += "?includeExtract=False"

    with closing(self.get_request(url, parameters={"stream": True})) as server_response:
        _, params = cgi.parse_header(server_response.headers["Content-Disposition"])
        if isinstance(filepath, io_types_w):
            for chunk in server_response.iter_content(1024):  # 1KB
                filepath.write(chunk)
            return_path = filepath
        else:
            filename = self._decode_filename(params)
            filename = to_filename(os.path.basename(filename))
            download_path = make_download_path(filepath, filename)
            with open(download_path, "wb") as f:
                for chunk in server_response.iter_content(1024):  # 1KB
                    f.write(chunk)
            return_path = os.path.abspath(download_path)

    logger.info(
        "Downloaded workbook revision {0} to {1} (ID: {2})".format(revision_number, return_path, workbook_id)
    )
    return return_path

Same issue for us since upgrading to 2023.1.7 - looking forward to a fix.

Faced the same issue. You can fix it by opening  /{path/to/your/python-libraries}/site-packages/tableauserverclient/server/endpoint/workbooks_endpoint.py and on line 490 update "...(params["filename"]))" to "...(params["filename*"]))"
Workbooks should now download but they have "UTF-8" appended to beginning of their name so you can write some code to take care of that until they patch this issue.

We also are affected by this issue.

For anyone facing this issue, please try downloaded the new v0.29 release. It includes #1330 which should fix this.

unfortunately, i get an issue with 0.29 to uploading datasources : 400011: Bad Request
There was a problem publishing the file '17851:753240939c9444f4a364f54c39c26e3e-1:0'

@SebMontreal06 That is different than the problem being discussed in this issue. Please open a new issue.

I create a support case for that
On Mon, Jan 22, 2024 at 2:41 PM jorwoods @.***> wrote:

@SebMontreal06 https://github.com/SebMontreal06 That is different than
the problem being discussed in this issue. Please open a new issue.
—
Reply to this email directly, view it on GitHub
https://github.com/tableau/server-client-python/issues/1312#issuecomment-1904770500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AENNTRR5XDQT2QVIVOWBXF3YP3FGLAVCNFSM6AAAAAA63RQWBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBUG43TANJQGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Regards
Sebastien Henry
Tel :<PHONE_NUMBER>
Mail : @.***

I'm going to resolve this one as closed/fixed now. If anyone is encountering problems like this after upgrading to v.030, please open a new issue with details.


Added better support for groups in the layer list

The layer list now accepts a class for rendering groups
as well as layers.

Coverage increased (+0.008%) to 98.522% when pulling a3d234c0ba4bdf69f48ae2d97eca1d4c31cdea3f on theduckylittle:feature/layer-group into d45fe69348bd3cf93294a84fbceca53921b9cde7 on boundlessgeo:master.

Coverage increased (+0.008%) to 98.522% when pulling 5012e96e85e82c09df24af5a77cbb30e1e202fb1 on theduckylittle:feature/layer-group into d45fe69348bd3cf93294a84fbceca53921b9cde7 on boundlessgeo:master.


remove unused six

Description

This fixes CI.
@drowoseque PTAL
Motivation and Context

Have you tested this? If so, how?

@honnix
thanks
I'm sorry you had to do it after my prs

No worries at all. You have been doing great job!


Remote Jupyter server and kernel picker UX

Define idealized UX for connecting to remote Jupyter servers
Open questions
1. If we were to improve current UX/UI...
What does the user expect to see in the kernel drop down list when...

They're on VS Code desktop / vscode.dev / Codespaces?
They have N Python environments?
a. Python not installed
b. Only global Python envs (is "Global Env" descriptive enough?)
c. Multiple Python environment manager types
Opening a notebook for the N-th time (i.e. kernel suggestion)?
The user is connected to a local Jupyter kernel, but have connected to a remote Jupyter server via the Specify Jupyter Server for Connections command? Current:

How well are these remote server connection entry-points served?

Specifying an currently running Jupyter URI with password authentication does not work
Running a cell without selecting a kernel ❔
Using SSH to start & connect to a Jupyter server (e.g. access remote notebook via port forwarding) ❔
a. Command line SSH
b. Remote-SSH extension
Going backwards, clicking on 'Jupyter Server: <Local/Remote>' button doesn't give option to disconnect / "connect" back to local server

What does the user expect to see in the remote connection server drop down list when...

There are multiple connection tokens for the same URI? E.g. how do we represent the notion of multiple tokens for the same server, and how would we save tokens?
There are multiple older connections for the same URI? Current:
There are one or more local Jupyter servers running (i.e. http://localhost:8888/?token=<...>)?
Some existing connections are active / reachable and some are inactive / unreachable?

2. If we were to "reimagine" the UX/UI...
What does the user expect to see in the VS Code window when connected to a kernel / Jupyter server?

File system in the context of the kernel / server?
Integrated terminal in the context of the kernel / server?
Should connecting to a remote Jupyter server be treated as a Remote Window? i.e. a part of this (the >< indicator on bottom left):

a. How about when user types jupyter notebook in the integrated terminal? Should this open a Remote Window instance on VS Code?

Here are my thoughts on this UX:

If we were to improve current UX/UI...

When I click to select a kernel, I see a very long list (this isn't all, I need to scroll down) that I think includes every Python binary in every virtual environment for every project I've ever worked on, on this machine. It's hard and I'm conflicted about this--I do like how it shows them alphabetically by name, shows the file location of the Python binary, and sub-groups them by environment manager. But it's a little confusing to me how it mixes the concept of a virtual environment with the concept of a Jupyter kernel, and it's not clear to me how to clean up the list to remove the ones I don't use anymore. It's also unclear to me why one of them is sometimes marked "Suggested" and I feel like the suggestion is usually not the one I want.

I'm not sure why I need to click this separate button, far away in the bottom tray, to connect to a remote Jupyter server. For a long time, I didn't even notice it was there:

When I'm connected to a remote server I can see an option to "Connect to Local Kernels" but when I'm connected to a local kernel there's no corresponding "Connect to Remote Kernels" option.

If we were to "reimagine" the UX/UI...

I don't think treating a remote Jupyter server as a Remote Window (like WSL / SSH / Dev Container) makes sense to me because my mental model is that only the notebook itself is talking to the remote Jupyter server, not all of VS Code is talking to it. And I don't know if it's the case that remote Jupyter servers always provide shell and filesystem access.
Thinking about what I would want: I would like to have a pane on the left sidebar for the extension where I can manage a list of local and remote Jupyter kernels (maybe similar to how I would manage a list of database connections in a query editor tool), and then I could select one from that list when I run a notebook. I feel like this would give me much more control and enable me to keep my snake pit more organized. I think the discovery of existing Pythons on my machine is super useful, but it also leads to clutter and I want for a better way to manage that clutter.

Adding some additional comments from our users on specific pain points to address--
Need better indication of remote connection, including updating the folder view in the context of remote

"It is very unclear to me if a remote connection is established. Would love to have it like in the browser, ie you can paste the jupyter link somewhere and then it directly opens the folder view everyone knows from the browser. At least with my setup, nothing happens when pasting the link in Jupyter: Specify Jupyter Server for Connections, therefore I manually have to do Create: New Jupyter Notebook which is very unintuitive. At first, I thought I am doing something wrong and the connection to the remote host doesn't work."
"Can not remap remote files to local when working with remote kernel."

Remote connection needs to be persisted

"Running remotely (macOS client, Windows desktop WSL2 host w/ RTX3090) can be frustrating as whenever my Mac goes to sleep the VS Code connection to the host is lost and must be reestablished (by clicking the button to reload the window, it takes like 30 seconds before the SSH connection is seemingly established)."
"cannot run notebooks in SSH remote "over night""
"It would be nice to keep command history across window reloads. This happens often for remote SSH session and can cause loss of complex experimental commands."
"[I would like to be] Staying connected to kernels on remotes ."

Want my kernel / notebook states to be persisted between remote sessions

"When running on a remote , i want the notebook to continue running if I am disconnected then update my ui on reconnection."
"need to reload previous cells incase of remote notebooks"
"Once the connection is back (this may or may not apply anymore, just going off memory) the notebook state is reset so I have to run all my cells again."
"I use notebooks together with vscode remote SSH. When I disconnect from the session and then reconnect to it, the notebook kernel must be restarted because it has lost all the previous state."
"When disconnect and reconnect to remote containers, I want to keep running kernels alive and keep outputs. For codes that requires long execution time."
"Remote notebooks require to be saved manually. This is frustrating and error prone. The work could be lost."

Connecting to remote servers with varying auth methods should be supported

"Cannot connect to development servers with self-signed certificates"

Experience for switching between remote servers needs to be improved

"[I would like to see] Setup up and choose a remote coding environment and choose it as easily as choosing a new Conda environment."
"[I would like to see] Smoother switching between jupyter servers (without need to reload window etc.), and especially between remote servers. "

UX/UI needs to be improved (general need for improvements, including buggy-ness)
Using notebooks with remote SSH is buggy
Note: it seems like this is the primary way VS Code users connect to remote servers

"I'm working with remote ssh mostly so every few minutes it has to reconnect and the process of finding the right kernel venv starts again.."
"it regularily crashes when remote developing using ssh due to oom."
"There are some issues using jupyter notebooks on a remote pc with ssh connection. The kernel installation was faulty recently, the workflow changed apparently. Accessing another pc via ssh requires a bit of configuration with certain network user-name-conventions It'd be cool, if there was an option to switch the user for a known host while connecting."
"[I would like to see] Better integration with Remote SSH connections and shared remote programming."

Using notebooks with remote Jupyter server connection is buggy

"It always takes a bit of effort to connect to a kernel. Especially if I'm connecting to a remote kernel, I always seem to run into some sort of issue. The latest thing I've found is that if I forget to start the Jupyter server before I open VSCode, I get into a state where I can't get it to connect until I restart VSCode with the server already running. But it just always seems like something causes a headache trying to get it to connect."
"For remote connections, (I think) disconnection can result in a failure mode where commands stop working but have no real error indicator."
"Setting/reconnecting to remote servers seems to be buggy at times. However, that is probably one of the most challenging subjects."
"Also I find it a bit slow and when working remotely it become unusable if the internet connection is poor."

Learning curve for using remote servers in VS Code is high

"Learning curve to using extensions, sshing into remote servers was confusing itially"
"I need to use Cloud computing resources like Google Colab Pro or MS Azure. But, even with the extensions remote development is still to usable. It is very easy to pick/switch environments. Why isn't it that easy to set up a remote environment and switch to that while coding from VS Code?"
"Connecting to and using notebooks on remote servers is very hard, and the UI is not very nice"
"[I would like to see] connect to remote server, attach/detach to a running notebook."

Taking a step back. We show potentially a lot of information to users and it feels to me that we need to help users in understanding what they see and how to decide. Here's my mental model on what decisions a user has to take:
graph TD
   A{Do I have a running Jupyter Server?}
   B(Select Server)
   B1(Select Kernel)
   C(Select environment from the system my window runs on)
   D{Do I have environments with installed kernels?}
   E(Select environment)
   E1(Select kernel)
   F{Resuse environment?}
   G(Select environment)
   H(Create environment)

   A --> |yes| B
   B --> B1
   A --> |no | C
   C --> D
   D --> |yes| E
   E --> E1
   D --> |no| F
   F --> |yes| G
   F --> |no| H

From my point of view it would make sense to translate that decision making progress into a UI that makes sure that the user understands what decisions they make.
There are a few questions that go along with that:

How common is it that notebooks in the same workspace connect to different kernel?
Has the user made the decisions for this workspace before?
Does that decision making flow make sense for non-python users? I.e. when I'm a Julia user do I know what Python environment to pick that has my Julia kernel?
When you select an environment, is the kind of Python environment such a major decision factor that selecting the kind of Python environment should be an explicit step?
When I start VS Code within an activated environment does that change the decision making process?

On a smaller point, I'm 100% with you that different connection tokens should be mapped to the same URL so that the user does not have the confusion of seeing multiple.

Thanks for structuring the conversation with the flow diagram for user's decision-making process!
Quick follow up q: what does it mean by "reusing" an environment in the diagram? That the user wants to use the same environment / kernel across different files in the workspace?

How common is it that notebooks in the same workspace connect to different kernel?

From my understanding, this is not abnormal for data scientists working in teams. For example, a data scientist would open a repo in a workspace that contains multiple data analysis projects nested in different folders. They then would have kernels for each project or sometimes even for each notebook.

Has the user made the decisions for this workspace before?
When I start VS Code within an activated environment does that change the decision making process?

I like where this is going! This decision-making process makes sense, but I've been thinking on a similar note: how much of this can / should be streamline for different user / notebook / workspace states? A few other ones (in addition to the two you mention above) include:

Has the user made the decisions for this notebook before? (i.e. would this decision-making process be notebook-based or workspace-based?)
How much of this decision-making process should we bypass if a user doesn't care (e.g. new users who just want to run their code cell for the first time)?
Does the user want new notebooks / interactive windows to connect to the kernel that is already connected to an existing notebook in the same workspace (e.g. to share variables)?

When you select an environment, is the kind of Python environment such a major decision factor that selecting the kind of Python environment should be an explicit step?

My intuition here is that this doesn't need to be an explicit step--though folks do value seeing their environments bucketed / organized by different Python environment types.

Does that decision making flow make sense for non-python users? I.e. when I'm a Julia user do I know what Python environment to pick that has my Julia kernel?

I don't have much experience with Julia, but the current way we display this is the same with how Jupyter classic does (ish), which means that a user who knows to select a Julia kernel in their Jupyter kernel will be able to do so by clicking on it (either #1 or #2 🤔):

https://www.figma.com/file/TfzHDYTRoLROZU0ddRH1ow/Kernel-Picker?node-id=2%3A261
per @misolori

Ref to prototyping env/kernel creation: https://github.com/microsoft/vscode-jupyter/issues/9640

Will be posting various scenario demos that I've mocked up.
Scenario 1: Running a notebook for the first time with no environment/extensions installed
This mirrors what we do right now out of the box and then leverages the "auto-create environment" concept that @IanMatthewHuff is currently working on.
https://user-images.githubusercontent.com/35271042/185251947-188d7ea9-9647-4006-af27-0b285cf03dea.mp4

I really like it. I suppose my main question is how much we can get away with installing on users computers without a prompt / message? I love the basically zero notification flow, but I'm a tiny bit unsure if it's ok to drop 80mb in the workspace without a confirmation. I think so? But we might have to be careful about making sure that it gets added to .gitignore and things like that.

I actually had a very similar comment! 😅 When we talked to users about this, they really like the ability to "confirm" what VS Code was going to do on their machine. They appreciated a message like this below, and they (to my surprise) wanted to click on "learn more" where they expected it to show them exactly what we'd install on their system so that they were confident about the changes VS Code was making to their system / repo.

With that, if we were to provide this true zero-notification flow, maybe it warrants an "undo" option of sorts?

I think we can include this dialog when installing the environment, and maybe with a "don't ask again" checkbox?

Scenario 2: Running a notebook and using local environments
This is aimed for the users that already have the Python/Jupyter extensions installed and has local environments. We should do our best to only show the most likely environments they would use and if we have low certainty then we show the full kernel list. I'm also proposing showing only the environments they have used in the past and allow them to remove them and access them through a "Show more kernels" menu item.
https://user-images.githubusercontent.com/35271042/185471983-f8c25425-1493-4b36-917c-e876965001fe.mp4

Scenario 3: Running a notebook and using many local environments
This is for when we don't have great certainty that we'll pick the right kernel and directly jump to the "Select local kernel" quick pick. Once the users selected a kernel, it'll get added to the main kernel quick pick and will also be stored for the workspace when switching to a different notebook. There are other edge cases where if a user selects a different kernel in another notebook that we can discuss.
https://user-images.githubusercontent.com/35271042/185498213-c756fba3-99b9-4cf4-85ca-158c08698720.mp4

In Scenarios 2 & 3, I wonder if we should be more opinionated and default to auto-creating environments as opposed to asking the user. On one hand, reducing the number of actions the user needs to do would be preferred but you also don't want to auto-create environments they didn't expect.

Scenario 4: Running a notebook on a remote jupyter server
This is to make sure we account for the remote server connections and how we show that in this new list. There will always be a "Connect to jupyter server" command from the kernel picker and then once you are connected to that remote, the kernels will be listed in the "Show more kernels" list. Showing multiple remote kernels is TBD.
https://user-images.githubusercontent.com/35271042/185504325-53462c08-4fc0-48c3-88ff-e106bb5e80c7.mp4

Thank you for making the clean shot videos for these scenarios! I have a few comments / questions.
Scenario 2

Is the main kernel quick pick based on the context of the workspace or is this a shared "suggested" list for VS Code in general? IOW, would the list of kernels in the main kernel quick pick change based on which workspace I'm in?
If the user was previously connected to a kernel from the workspace, should we just skip all clicks and directly connect them to that kernel (even after a VS Code reload)?
I see that the global Python environments are not listed in the "show more" list. Is this intentional?
I also see that the Python environment types are not categorized in the "show more" list. Is this intentional?
During the sync, we talked about caching the kernel list (for perf sake) and then adding a way to "refresh" the list. I wonder if the "show more" button can double as that "refresh" button?

Scenario 3

Thinking out loud here. It seems like this is what most users will see when they first try to run notebooks in VS Code. Then, they will subsequently see the main kernel quick pick with the shortened list based on what VS Code knows about the workspace. I wonder if that will cause any confusion? It seems like a "minor" confusion if at all, but still wanted to leave this comment as a food for thought.
The initial list makes it hard for user to find the "connect to a Jupyter server" option, because they'd have to know to click on the "back" arrow. I wonder if we should add that option to the bottom of this list? Or if there is a better way to surface that?
We've worked to reduce clicks in the "getting started" effort last iteration, where we'd automate some parts of the user flow where they'd have to install missing extensions. Would that experience flow into this experience where for example: a user would click "Run all" --> they click "Install necessary extensions (Python + Jupyter)" --> we'd immediately show them this list (without requiring the user to click the "Run all" or "Select kernel" button again)?
A few other entry points to consider for selecting kernels:

Attempting to activate an environment via integrated terminal with a notebook open (e.g. conda activate <env>)
Attempting to open a notebook from the integrated terminal (e.g. cd-ing into a folder and running jupyter notebook)

Scenario 4

One of the user confusion points was seeing remote & local kernels in the same list. Since the main kernel quick pick is now more of our somewhat strong suggestion / guesstimate, and going off of the assumption that the main kernel quick pick is workspace based (not like an MRU list for VS Code), I wonder if we should only include the remote kernel in the main kernel quick pick?
A few other entry points to consider for connecting to a remote server are:

Jupyter Server connection indication on the bottom right
Attempting to connect to a remote Jupyter server via integrated terminal (e.g. ssh -L <port on remote server>:localhost:<port to map to> <remote_user>@<remote_host>)

Other food for thought...

What would this look like for users who doesn't have Python and/or Python env manager not installed?

@minsa110 I think that #11159 is going to address many of the questions that you asked regarding Scenario 2. I don't think the UX walkthroughs will have the full info on what kernels make the "short-list" cut line, that will be up to us to figure out.
Scenario 3 I go have to admit I didn't quite grok the same way that Scenario 2 made sense to me. I think the only main reason might be that the back button also wasn't clear to me at that point the same way that Soojin wasn't sure on that. Adding the connect button to the bottom might help there.
I would say that based on how we figure out the cut-line for scenario two we could make scenario 3 way less common. If we have nothing above the cut line then it might be good to just "raise up" something like the highest version global python or the "create environment" command to be above the cut line and just do scenario #2.
I'm interested in what scenario 4 might look like with multiple remote connections. At some point we are pushing against the bounds of what we can do with the Quick Pick UI, but wondering about something like this:

Local Kernel A
Local Kernel B
Connect Remote Server

Then connect a remote server

Remote Kernel A (server 1)
Remote Kernel B (server 1)
Show Local Kernels
Connect Remote Server

Then connect a second remote server

Remote Kernel C (server 2)
Remote Kernel D (server 2)
Show Server 1 Kernels
Show Local Kernels
Connect Remote Server

Like the quick pick is always only ever showing one set of kernels, but it's easy to swap between multiple connected servers and local kernel views.

Closing in favor of the changes we made, grouping the kernel types by categories


Separate adding X-Forwarded-Port header

Similar to #1656
Add X-Forwarded-Port header in Zuul PreDecorationFilter even with X-Forwarded-Host header being absent.
In my case I deployed my Zuul Proxy gateway behind a Amazon ALBv2.
In my zuul proxy, I receive the following request :
GET /swagger/scim/v2/api-docs
X-Forwarded-For: <IP_ADDRESS>.
X-Forwarded-Proto: https.
X-Forwarded-Port: 443.
Host: front-host.com.
X-Amzn-Trace-Id: Root=blabla
cache-control: max-age=0.
upgrade-insecure-requests: 1.
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36.
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8.
accept-encoding: gzip, deflate, sdch, br.
accept-language: en-US,en;q=0.8,fr;q=0.6,es;q=0.4,it;q=0.2.

As you can see, there's no X-Forwarded-Host.
In the current code, X-Forwarded-Port is added only if there's a X-Forwarded-Host present.
https://github.com/spring-cloud/spring-cloud-netflix/blob/675e4c1031b275af877938c02d5950c91f7fe660/spring-cloud-netflix-core/src/main/java/org/springframework/cloud/netflix/zuul/filters/pre/PreDecorationFilter.java#L199
In my case, my Zuul proxy forwards a request containing :
x-forwarded-port: 80

While I would expect it to send a
x-forwarded-port: 443,80

I have the same problem and was about to open an issue, when I found the bug already reported here.
I also have my service behind an Amazon ELB, which I believe be a very standard use case.
When we do a request to our ELB:
GET https://myelb.domain.com/test
The following headers are sent from the ELB to the Gateway running Zuul:
X-Forwarded-For: (the IP address of the ELB)
X-Forwarded-Proto: https
X-Forwarded-Port: 443

Then Zuul forwards the request with:
X-Forwarded-Proto: http
X-Forwarded-Host: myelb.domain.com
X-Forwarded-Port: 80

And it should have being:
X-Forwarded-Proto: https
X-Forwarded-Host: myelb.domain.com
X-Forwarded-Port: 443

We added a Apache HTTPD server before Zuul to set X-Forwarded-Host, and that fixes it, as already reported that if X-Forwarded-Host is present, then X-Forwarded-Proto and X-Forwarded-Port are correctly used. However, they should be consider when X-Forwarded-Host is not present as well!
I see there is already an issue open and closed to fix X-Forwarded-Proto and this one is to fix X-Forwarded-Port.
As both are wrong, I would consider this a critical issue.
Looking forward to see this fixed on a service release for Camden, maybe Camden.SR7?
Thanks!

@gonzalad @michelzanini if either of you want to submit a PR for this, that would be welcome, if not we will get to it when we can

@ryanjbaxter a PR is available for this issue : #1808

Thanks @gonzalad. Hopefully this will make into next SR release =]


Move UWPVoiceAssistantSample from ADO

Purpose

Add UWP Voice Assistant Sample to clients/csharp-uwp

Does this introduce a breaking change?
[ ] Yes
[x] No
Pull Request Type
What kind of change does this Pull Request introduce?
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[x] Other: Move from ADO to GitHub

.editorcofig file should be removed

There are two README.md. There should only be one at the root of this sample.
Remove LICENSE.md

remove .editorconfig
remove CONTRIBUTING.md


Prefix path setup

PLIP (Plone Improvement Proposal)

Responsible Persons
Proposer:  Nilesh Gulia @nileshgulia1
Seconder:
Abstract
Allows a Volto project to be published under relative-path. For eg: www.mysite.com/foo,
Motivation
We came across projects that manifest the need to have multiple sites published under one domain. For eg: https://water.europa.eu/ is the static webpage that links to two "subsites". The page is static with two sites hosted inside their own folders. For eg: /Plone/marine and /freshwater.
There is a need to replace the build path every time, eg for freshwater, we are using PUBLIC_PATH https://github.com/eea/freshwater-frontend/blob/master/entrypoint-prod.sh#L16
We might want a more robust solution that can handle the prefixing of build files at runtime under one env var. So something like RAZZLE_PREFIX_PATH="/foo" will ensure that plone site root is at /foo.
Assumptions
Proposal & Implementation
This has been nicely already put on top of the table by red turtle folks @giuliaghisini @cekk @pnicolli in the form of https://github.com/plone/volto/pull/3592/.
Based on basename react-router prop which adds an initial entry to browser "history" stack and allows all links to be prefixed with basename by react-router. The static assets like images need to be explicitly prefixed. @nileshgulia1  amended an express-middleware which re-directs to app base path on initial load.
There is another approach in https://github.com/plone/volto/pull/3190 PR, which uses a store enhancer middleware to prefix all the router paths(amending history accordingly) and modified flattenToAppUrl method.
Deliverables

[ ] ./foo as plone site root
[ ] serve build assets from RAZZLE_PREFIX_PATH
[ ] prefix all Images with RAZZLE_PREFIX_PATH
[ ] Url links to be prefixed as well.
[ ] Need to take care of flattenToAppUrl. Shouldn't add multiple prefixes.
[ ] Since /foo is at root, strip out the path from API requests?
[ ] Nginx config for deployments
[ ] Documentation
[ ] Cypress tests (https://github.com/plone/volto/pull/3719)

Risks

Since the site root is at /foo, what are the considerations when prefixing internal links?

Participants
These are the people involved:
Original PR by @giuliaghisini

@cekk
@pnicolli
@tiberiuichim Another react-router middleware based approach(https://github.com/plone/volto/pull/3190)
@sneridagh Created the cypress architecture in CI (https://github.com/plone/volto/pull/3719)
@nileshgulia1

I would be happy to coordinate the efforts, any help on the deployment section would be greatly appreciated.

Any temporary solutions in the meantime?


Update Ace Command

Update some links and fix import

Hey, thx for the PR... I totally forgot about it. It's merged in 3.59.0


String was not recognized as a valid DateTime

Hi,
Just started using HAWK to pull out all of the audit information on my 365 tenant but im coming across streams of errors relating to the date/time - i am running this within the UK, im not sure if this has any impact on your powershell code?
It then gets stuck in an infinite loop when searching a date range and carrying out various other tasks. It fails to pull anything from the audit files because of these errors.

Any ideas?
Thanks.

Same as issue #27


Missing tag for version 2.1.1

Could you please create a tag for the new version 2.1.1 so we can get it with bower.
And also update the version number in bower.json

Done. Thanks and sorry about that :)


⚠ Bofrost.lu has degraded performance

In f65b5c3, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1371 ms

Resolved: Bofrost.lu performance has improved in 87ee0bf after 41 minutes.


Remove microbenchmarks

These benchmarks are all testing things related to what Prometheus does, so perhaps have some historical interest, but we should not retain them in the main repo. Prometheus benchmarks should run actual Prometheus code.
(Two exceptions: BenchmarkLabelSetAccess is doing the same as BenchmarkLabels_Get in the labels package, and BenchmarkLabelsClone was moved into the labels package.)
As an alternative, we could retain the code but call b.SkipNow() at the top of each, so they don't take up any time when running all benchmarks.

Rebase might be needed 🙈


Crashlytics

Hi @pedroSG94,
I just want to share with you the crashes from crashlytics.
Thank you!

I can't do anything this week.
I will check it next week.

All this errors should be solved now:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/commit/71f372e773606d06d568d0a8c41f33a5fc297925
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/commit/fcb68b83f7e052cd101448615f2ebc06ac6fbdd2


generated output for ibm-ocp-vpc does not autowire the kms

When generating either 130 or 150 the kms key is not autowired
In the BOM, it looks like this:
    - name: ibm-ocp-vpc
      alias: cluster
      variables:
        - name: disable_public_endpoint
          value: true
        - name: kms_enabled
          value: true
        - name: worker_count
          alias: workload_worker_count
        - name: ocp_version
          value: 4.8
      dependencies:
        - name: subnets
          ref: worker-subnets
        - name: kms_key
          ref: kms_key

Which should autowire the kms key based on the contents of it's module.yaml.
Howere, the generated output looks like this:
module "cluster" {
  source = "cloud-native-toolkit/ocp-vpc/ibm"
  version = "1.13.2"

  cos_id = module.cos.id
  disable_public_endpoint = var.cluster_disable_public_endpoint
  exists = var.cluster_exists
  flavor = var.cluster_flavor
  force_delete_storage = var.cluster_force_delete_storage
  ibmcloud_api_key = var.ibmcloud_api_key
  kms_enabled = var.cluster_kms_enabled
  kms_id = var.cluster_kms_id
  kms_key_id = var.cluster_kms_key_id
  kms_private_endpoint = var.cluster_kms_private_endpoint
  login = var.cluster_login
  name = var.cluster_name
  name_prefix = var.mgmt_name_prefix
  ocp_entitlement = var.cluster_ocp_entitlement
  ocp_version = var.ocp_version
  region = var.region
  resource_group_name = module.resource_group.name
  sync = module.resource_group.sync
  tags = var.cluster_tags == null ? null : jsondecode(var.cluster_tags)
  vpc_name = module.worker-subnets.vpc_name
  vpc_subnet_count = module.worker-subnets.count
  vpc_subnets = module.worker-subnets.subnets
  worker_count = var.mgmt_worker_count
}

Notice all of the kms values are individual variables:
  kms_enabled = var.cluster_kms_enabled
  kms_id = var.cluster_kms_id
  kms_key_id = var.cluster_kms_key_id
  kms_private_endpoint = var.cluster_kms_private_endpoint

If you try to execute the template, you get these errors:

│ Error: Invalid value for module argument
│
│   on main.tf line 141, in module "ibm-transit-gateway":
│  141:   connections = module.ibm-vpc.crn
│
│ The given value is not suitable for child module variable "connections" defined at
│ .terraform/modules/ibm-transit-gateway/variables.tf:24,1-23: list of string required.
╵
-----
╷
│ Error: Missing required argument
│
│   with module.cluster.ibm_container_vpc_cluster.cluster[0],
│   on .terraform/modules/cluster/main.tf line 197, in resource "ibm_container_vpc_cluster" "cluster":
│  197: resource ibm_container_vpc_cluster cluster {
│
│ The argument "kms_config.0.instance_id" is required, but no definition was found.
╵
╷
│ Error: Missing required argument
│
│   with module.cluster.ibm_container_vpc_cluster.cluster[0],
│   on .terraform/modules/cluster/main.tf line 197, in resource "ibm_container_vpc_cluster" "cluster":
│  197: resource ibm_container_vpc_cluster cluster {
│
│ The argument "kms_config.0.crk_id" is required, but no definition was found.
╵

In the old generated FS Cloud template, it gets autowired like so:
  kms_id = module.kms-key.kms_id
  kms_key_id = module.kms-key.id

It looks like the module.yaml for the kms-key module hasn't been updated since early november, so something else has changed.

I can't reproduce this with iascable 2.11.3
With this input (current latest for fs-cloud in automation-solutions@main)
apiVersion: cloud.ibm.com/v1alpha1
kind: BillOfMaterial
metadata:
  name: 130-ibm-fs-management-vpc-openshift
  labels:
    type: infrastructure
    platform: ibm
    code: 130
  annotations:
    displayName: Management VPC OpenShift
    description: Management VPC and Red Hat OpenShift servers
spec:
  modules:
    - name: ibm-resource-group
      alias: kms_resource_group
    - name: ibm-resource-group
      alias: at_resource_group
    - name: ibm-kms
      alias: kms
      variables:
        - name: provision
          value: false
        - name: region
          alias: kms_region
        - name: name_prefix
          alias: kms_name_prefix
          scope: global
          value: ""
      dependencies:
        - name: resource_group
          ref: kms_resource_group
    - name: ibm-resource-group
      variables:
        - name: resource_group_name
          alias: mgmt_resource_group_name
          scope: global
    - name: ibm-iam-service-authorization
      alias: flow-log-auth
      variables:
        - name: source_service_name
          value: is
        - name: source_resource_type
          value: flow-log-collector
        - name: roles
          value:
            - Writer
      dependencies:
        - name: target_resource_group
          ref:  ibm-resource-group
        - name: target_resource
          ref: cos
    - name: ibm-access-group
    - name: ibm-vpc
      variables:
        - name: address_prefix_count
          value: 3
        - name: address_prefixes
          value:
            - <IP_ADDRESS>/18
            - <IP_ADDRESS>/18
            - <IP_ADDRESS>/18
    - name: ibm-flow-logs
      dependencies:
        - name: target
          ref: ibm-vpc
        - name: cos_bucket
          ref: flow_log_bucket
    - name: ibm-vpc-gateways
    - name: ibm-vpc-subnets
      alias: worker-subnets
      variables:
        - name: _count
          alias: mgmt_worker_subnet_count
          scope: global
          value: 3
        - name: label
          value: worker
        - name: ipv4_cidr_blocks
          value:
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
        - name: acl_rules
          value:
            - {"name":"allow-vpn-ingress","action":"allow","direction":"inbound","source":"<IP_ADDRESS>/0", "destination":"<IP_ADDRESS>/8"}
            - {"name":"allow-vpn-egress","action":"allow","direction":"outbound","source":"<IP_ADDRESS>/8", "destination":"<IP_ADDRESS>/0"}
      dependencies:
        - name: gateways
          ref: ibm-vpc-gateways
    - name: ibm-ocp-vpc
      alias: cluster
      variables:
        - name: disable_public_endpoint
          value: true
        - name: kms_enabled
          value: true
        - name: worker_count
          alias: mgmt_worker_count
        - name: ocp_version
          value: 4.8
      dependencies:
        - name: subnets
          ref: worker-subnets
        - name: kms_key
          ref: kms-key
    - name: ibm-vpc-subnets
      alias: vpe-subnets
      variables:
        - name: _count
          value: 3
        - name: label
          value: vpe
        - name: ipv4_cidr_blocks
          value:
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
    - name: ibm-vpc-subnets
      alias: ingress-subnets
      variables:
        - name: _count
          value: 3
        - name: label
          value: ingress
        - name: ipv4_cidr_blocks
          value:
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
            - <IP_ADDRESS>/24
    - name: ibm-vpc-vpn-gateway
      dependencies:
        - name: subnets
          ref: vpn-subnets
    - name: ibm-resource-group
      alias: cs_resource_group
    - name: ibm-object-storage
      alias: cos
      variables:
        - name: provision
          value: false
        - name: name_prefix
          alias: cs_name_prefix
          scope: global
      dependencies:
        - name: resource_group
          ref: cs_resource_group
    - name: ibm-kms-key
      variables:
        - name: provision
          value: true
      dependencies:
        - name: kms
          ref: kms
    - name: ibm-activity-tracker
      dependencies:
        - name: resource_group
          ref: at_resource_group
    - name: ibm-object-storage-bucket
      alias: flow_log_bucket
      variables:
        - name: label
          value: flow-logs
        - name: allowed_ip
          value:
            - <IP_ADDRESS>/0
    - name: ibm-vpe-gateway
      alias: vpe-cos
      dependencies:
        - name: resource
          ref: cos
        - name: subnets
          ref: vpe-subnets
        - name: sync
          ref: cluster
    - name: ibm-transit-gateway
      variables:
        - name: provision
          value: false
        - name: name_prefix
          alias: cs_name_prefix
          scope: global
      dependencies:
        - name: resource-group
          ref: cs_resource_group
    - name: ibm-log-analysis
      variables:
        - name: provision
          value: false
        - name: name_prefix
          alias: cs_name_prefix
          scope: global
      dependencies:
        - name: resource_group
          ref: cs_resource_group
    - name: ibm-cloud-monitoring
      variables:
        - name: provision
          value: false
        - name: name_prefix
          alias: cs_name_prefix
          scope: global
      dependencies:
        - name: resource_group
          ref: cs_resource_group
    - name: ibm-log-analysis-bind
    - name: ibm-cloud-monitoring-bind
  variables:
    - name: mgmt_resource_group_name
    - name: region
    - name: ibmcloud_api_key
    - name: name_prefix
      alias: mgmt_name_prefix
      required: true
    - name: cs_resource_group_name
    - name: cs_name_prefix
    - name: worker_count
    - name: kms_service

I get this in the generated main.tf
module "cluster" {
  source = "cloud-native-toolkit/ocp-vpc/ibm"
  version = "1.13.3"

  cos_id = module.cos.id
  disable_public_endpoint = var.cluster_disable_public_endpoint
  exists = var.cluster_exists
  flavor = var.cluster_flavor
  force_delete_storage = var.cluster_force_delete_storage
  ibmcloud_api_key = var.ibmcloud_api_key
  kms_enabled = var.cluster_kms_enabled
  kms_id = module.kms-key.kms_id
  kms_key_id = module.kms-key.id
  kms_private_endpoint = var.cluster_kms_private_endpoint
  login = var.cluster_login
  name = var.cluster_name
  name_prefix = var.mgmt_name_prefix
  ocp_entitlement = var.cluster_ocp_entitlement
  ocp_version = var.ocp_version
  region = var.region
  resource_group_name = module.resource_group.name
  sync = module.resource_group.sync
  tags = var.cluster_tags == null ? null : jsondecode(var.cluster_tags)
  vpc_name = module.worker-subnets.vpc_name
  vpc_subnet_count = module.worker-subnets.count
  vpc_subnets = module.worker-subnets.subnets
  worker_count = var.mgmt_worker_count
}

OK dug up the history… This is already fixed.  It is the case where the module used a default alias that didn’t match what was expected by the bom.  The alias kms_key was being used in the bom, but in the repo’s module.yaml it was kms-key.   This is one of those cases that slipped by in the old version of iascable, but was actually an error in the bom.  The bom has since been fixed.