Cisco switch support

This pull request adds support for Cisco 9300 in the switch module.  Some preliminary work has been done to re-use common code for both the Allied and Cisco implementations.  It was not the intention of this pull request to fully create a common template and code base for both implementations and should be treated only as adding Cisco 9300 support while maintaining current Allied functionality.

Thanks for putting this together -- something that really does need to be done. I had a quick look and mostly it's good -- I'll provide a more detailed review in just a bit.
Meanwhile, @pisuke or @InBrewJ, are you in a position to try this out with an AT switch?  Given that there's no faux-test for this, I'd like to do a bit more manual regression testing on it before approving.

Yup, we'll give it a spin today and tomorrow, thank you @jhughes!

Understood -- just go ahead and make the breaking change.  Also then update
docs/changelog.md (create a new section at the top) with a one-line note
about the breaking change.
On Tue, Dec 3, 2019 at 1:50 PM jhughesbiot<EMAIL_ADDRESS>wrote:

@jhughesbiot commented on this pull request.
In daq/host.py
https://github.com/grafnu/daq/pull/267#discussion_r353441154:

@@ -459,6 +459,12 @@ def _docker_test(self, test_name):
params['local_ip'] = ext_loip % self.test_port
params['switch_ip'] = self.config['ext_addr']
params['switch_port'] = str(self.target_port)

   if 'switch_model' in self.config:

       params['switch_model'] = self.config['switch_model']

   else:

       params['switch_model'] = "ALLIED_TELESIS_X230"

I left this fallback value for the initial commit to maintain legacy
installations using AT switches so existing working system.conf files could
remain unchanged. I will remove the default value if we want to force this
new required value. Probably should document the breaking change somewhere
to indicate this.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPDZ5XKLCKPDOZXSIER3QW3ICXA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCN2ZHUI#discussion_r353441154,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD2SJ766W4M4QNKVLD3QW3ICXANCNFSM4JUPAQRQ
.

@grafnu @jhughesbiot after getting OpenFlow fully up and running on my 9300 today (thanks @jhughesbiot!) I can run through a proper functional test of this tomorrow. I'll report back tomorrow evening GMT.

Does anybody have an AT setup handy and still working?  I'm actually more
"concerned" about AT (I'm assuming Jonathan has been testing against Cisco
just fine).
On Tue, Dec 3, 2019 at 3:15 PM Jason Brewer<EMAIL_ADDRESS>wrote:

@grafnu https://github.com/grafnu @jhughesbiot
https://github.com/jhughesbiot after getting OpenFlow fully up and
running on my 9300 today (thanks @jhughesbiot
https://github.com/jhughesbiot!) I can run through a proper functional
test of this tomorrow. I'll report back tomorrow evening GMT.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD6N27C3I4IEE5KCF7LQW3SBRA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF3EVUI#issuecomment-561400529,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD26PR257LEQMS476ITQW3SBRANCNFSM4JUPAQRQ
.

I have the AT and the Cisco sitting next to eachother - swapping things over is a matter of renaming my system.AT.conf back to system.conf, cleaning docker things to be safe and plugging in two different ethernet cables. I'll focus on that first

Try it without cleaning the docker things -- it should be transparent to
that.  Really, it should just be as simple as editing the one config
parameter (one line)
On Tue, Dec 3, 2019 at 3:28 PM Jason Brewer<EMAIL_ADDRESS>wrote:

I have the AT and the Cisco sitting next to eachother - swapping things
over is a matter of renaming my system.AT.conf back to system.conf,
cleaning docker things to be safe and plugging in two different ethernet
cables. I'll focus on that first
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD2AJYELE6XOQKSFVUTQW3TSFA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF3FSUI#issuecomment-561404241,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD5CNPCW4UPBF7Z5VT3QW3TSFANCNFSM4JUPAQRQ
.

@grafnu @jhughesbiot
I've just tested this a few times with an AT x230-18GP - I'm afraid the switch test is currently crashing. This means that the switch results are never written to the report. Attached is the activate.log from my run.
activate.log
I'll have a look into what's causing this post-haste!

@InBrewJ I just pushed an update that should correct the Allied Switch test.  Found an issue for the data arrays not being created in the same way as before this update.

Hi @jhughesbiot, there's still a problem somewhere, the activate log from my most recent run is attached:
activate.log
I'm trying to find out why the log is just cutting off and not doing anything afterwards

There are sometimes buffering issues where part of the system will exit
(e.g. docker container) before something has been completely flushed. Not
an easy problem to fix (otherwise I would have!).
Sometimes to debug something like this you have to resort to trickery --
add a "tail -f /dev/null" somewhere in the switch test file so that it
never exists, and then go into the running container and see what's
happening.
On Thu, Dec 5, 2019 at 6:59 AM Jason Brewer<EMAIL_ADDRESS>wrote:

Hi @jhughesbiot https://github.com/jhughesbiot, there's still a problem
somewhere, the activate log from my most recent run is attached:
activate.log https://github.com/grafnu/daq/files/3927504/activate.log
I'm trying to find out why the log is just cutting off and not doing
anything afterwards
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD66BLA5EFV4HQGH2QLQXEJL7A5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGA7Q7Q#issuecomment-562165886,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD7APE4VESBYDEMNPT3QXEJL7ANCNFSM4JUPAQRQ
.

Ah ha. The races are having races with each other. I'll give the tail/docker exec plan a go, thanks!

I think I've gotten to the bottom (of the start) of it. It seems like, in my runs, the requestFlag variable always has a value of -2. Confusingly, there is a method called getRequestFlag() that does this. Request flag is initialized to 0 here. There's something fishy going on.

The buffer issue was failing on the expected key "input packet" but for whatever reason didn't get the full expected response, just the beginning (inp), so it appeared to get stuck waiting forever for the completed packet that wasn't going to come.
Did you add some additional debug to find the request flag -2 issue?  Based on inspecting the code and the active.log, it would have had to get to at least a value of 1 which happens after user enabled to send the show interfaces command. The request flag has a value written in only two places, once after enable to make it 1 and then incremented after successful commands.  It never decrements so there should be no way for it to ever become negative 2.
Have you done a sanity check against the current release to make sure the switch is successful in it's current state without these updates?  Might be a good thing to try to rule out any code changes at this point if nothing else shows  up as a possible culprit.

Yep, I've sanity checked the switch test with the latest commit on grafnu/master. Everything is fine there.
I also added some additional debug to get the requestFlag issue and tidied up some existing debug messages, yes. Sorry - I should have mentioned. I'll keep on digging.
One extra observation, the final debug output shows the key/value pairs that the code is using to validate results, in this case from the interfaceExpected array of strings. The keys and values that are being injected into the hashmap don't sync up though, as far as I can see. For example, port1 gets a value of null. The value of administrative state is is 100.
100 is the value of current speed in this run. Still fishy, still weird.

I was just about to update my previous statement but i'll just add this after for clarity.
It actually does appear to be possible to get to negative 2 due to the fact that the getRequestFlag() method decrements the actual request flag by 1 and the call from the TelnetSocket additionally decrements by 1.  This is the same behavior as the original code so I do not believe this is the issue.  Can you provide the new output with the bad mapping?

I think I see what's happened. If we compare the [https://github.com/grafnu/daq/blob/master/subset/switches/src/main/java/switchtest/SwitchInterrogator.java](AT code) on grafnu/master, we see variables like:

interface_expected
show_interface_expected

In your update/refactoring here we see methods like:

interfaceExpected()
showInterfaceExpected()

These return strings which you rightly assign to the old variable names in this style.
I'm no expert on this code but I'm presuming that the variables prepended with show in the old code (i.e. show_interface_expected) are command sets and those without show aren't. In your refactored code, interfaceExpected and showInterfaceExpected are equal. I would presume these are both command sets.
See the same variables in grafnu/master in the previous style:

interface_expected
show_interface_expected

So in this PR, showInterfaceExpected is too long because it includes new lines chars and comma chars and all sorts. The array full of replies for the switch is shorter, so we essentially get a segfault at this point and the JVM says goodnight.
If that makes sense?

Update part 2:
I made the change I was suggesting: AlliedTelesisX230.txt. I can't send a link to a Java file so just rename it to AlliedTelesisTelesisX230.java if you want to have a look.
The switch test now runs fine on the AT switch. See the report from the run here
I haven't set up the module_config.json properly but you can see the switch test passing - the DUT under test one of these guys from Delta.
Once the change is made I'll be happy to approve!

One other thing I'd mentioned from a QA perspective is that if you have an AT switch plugged in but enable the Cisco 93k module with switch_model="CISCO_9300" in local/system.conf then the switch test hangs forever. This is for another PR though, I suspect

I found my local copy confirmed the interfaceExpected method as correct and not the code in the PR.  Not sure why that didn't get included but I just pushed an update that should correct that.

One other thing I'd mentioned from a QA perspective is that if you have an AT switch plugged in but enable the Cisco 93k module with switch_model="CISCO_9300" in local/system.conf then the switch test hangs forever. This is for another PR though, I suspect

I can look into this as well if it's an issue that should be addressed.  Can you provide the log for this state so I can try to determine cause?

@grafnu @pisuke what are your thoughts on Jon's comment above?

I don't have enough information to have much of an opinion -- surely it's
not good (hangs forever), but in the grand scheme of things I don't know
what impact it might have.
On Mon, Dec 9, 2019 at 8:17 AM Jason Brewer<EMAIL_ADDRESS>wrote:

@grafnu https://github.com/grafnu @pisuke https://github.com/pisuke
what are your thoughts on Jon's comment above?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD6ARLKJRNDAVJG34W3QXZVR3A5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGJX2KA#issuecomment-563313960,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD4N5LZJZALVK6KB2L3QXZVR3ANCNFSM4JUPAQRQ
.

I'd assume that if you ran the current switch test without an AT switch plugged in (but with the right settings in /local/system.conf) that would also hang forever. I haven't tested that, however.
I guess we can say that since this class of problem:
"the switch test hangs and doesn't time out if the topology is incorrect"
isn't isolated to the code in this PR then we could leave it for another time?

That is true -- there are in fact a number of situations where a bad config
or system state just sits there and doesn't do anything useful or obvious.
You just "have to know" what the problem might be.
On Mon, Dec 9, 2019 at 8:36 AM Jason Brewer<EMAIL_ADDRESS>wrote:

I'd assume that if you ran the current switch test without an AT switch
plugged in (but with the right settings in /local/system.conf) that would
also hang forever. I haven't tested that, however.
I guess we can say that since this class of problem:
"the switch test hangs and doesn't time out if the topology is incorrect"
isn't isolated to the code in this PR then we could leave it for another
time?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPDZ6IYROX2EAM2MSFKLQXZX2DA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGJZ7VI#issuecomment-563322837,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPDYDBCKVKIAOQGNA26TQXZX2DANCNFSM4JUPAQRQ
.

Note that there are some failing tests that need to be cleaned up before submitting. One looks like real, but the other I think is just from a flaky test, so I restarted it.  My guess is that the integration tests does a basic "ping" against something to test part of the switch capability, but then it fails because the switch_model isn't defined to anything. You probably need an entry in misc/system_ext.conf -- you can just put something like "testing" and then make that work elsewhere if necessary (e.g., make it an allowed switch model).

You probably need an entry in misc/system_ext.conf -- you can just put something like "testing" and then make that work elsewhere if necessary (e.g., make it an allowed switch model).

Can you elaborate on that?  Adding a switch_model default entry to system_ext.conf is easy enough but not sure what the "make that work elsewhere" is referring to. Does this need an entry in the java code to handle a "testing" option in the enum?  Not sure what that would mean beyond that as i'm not clear as the failure point is or what these test interactions are expecting.

I just mean try it, and if something breaks then fix it. I'm not sure what
assumptions are made anywhere so hard to tell. I'm not talking about adding
anything new, just fixing what breaks.
On Tue, Dec 10, 2019, 11:14 AM jhughesbiot<EMAIL_ADDRESS>wrote:

You probably need an entry in misc/system_ext.conf -- you can just put
something like "testing" and then make that work elsewhere if necessary
(e.g., make it an allowed switch model).
Can you elaborate on that? Adding a switch_model default entry to
system_ext.conf is easy enough but not sure what the "make that work
elsewhere" is referring to. Does this need an entry in the java code to
handle a "testing" option in the enum? Not sure what that would mean beyond
that as i'm not clear as the failure point is or what these test
interactions are expecting.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD42ABVUFA2SFVXW65TQX7TCVA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQN2XA#issuecomment-564190556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD6AYG6YBUGDQKDSHYDQX7TCVANCNFSM4JUPAQRQ
.

I guess i'm unclear on what exactly the failure being reported is here so i'm not sure how to proceed in implementing and verifying any fix for it.

Not sure if you're looking at the integration tests or not -- here's the
run for the pull request
https://travis-ci.org/grafnu/daq/jobs/621244056#L6143 (may take a bit to
load). There's a link to it from the bottom of the pull request comment
section -- where is says "All checks have failed." This is the page where
you can see all the pull requests that are automatically tested
https://travis-ci.org/grafnu/daq/pull_requests.  So, complaining about that
missing value -- so set the value to something, and then see if the test
passes or not!
On Tue, Dec 10, 2019 at 12:40 PM jhughesbiot<EMAIL_ADDRESS>wrote:

I guess i'm unclear on what exactly the failure being reported is here so
i'm not sure how to proceed in implementing and verifying any fix for it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD5TBFT2OCGSWLDKDE3QX75DTA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQ35UA#issuecomment-564248272,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD7OCV4JZJGGYVQVMPTQX75DTANCNFSM4JUPAQRQ
.

I've attempted to review the travis ci output to determine what the failure is but all I see is the failure notice with no indication of the actual failure.  There is a really long job log to review but again, nothing that I can see indicating the exact failure.

Huh - that link only sometimes seems to work (take you to the right line)
-- other times not.  Either a bug in their website or chrome. The link
itself has the line number encoded in it:
https://travis-ci.org/grafnu/daq/jobs/621244056#L6143 --> 6143, which shows:
ERROR:host:Target port 2 start error: 'switch_model'
6143ERROR:runner:Target port 2 active True exception: Traceback (most
recent call last):
6144  File "/home/travis/build/grafnu/daq/daq/host.py", line 417, in
_run_next_test
6145    self._docker_test(self.remaining_tests.pop(0))
6146  File "/home/travis/build/grafnu/daq/daq/host.py", line 462, in
_docker_test
6147    params['switch_model'] = self.config['switch_model']
6148KeyError: 'switch_model'
6149
6150
At the very end of the log there's an overall failure, which is just useful
to know if it's passed or not:
Comparing testing/test_base.out against inst/test_base.out
8594107c107
8595< 02: []
8596---
8597> 02: ["02:monitor:'switch_model'"]
8598110,113c110
8599< Switch test with port 2
8600< RESULT pass base.switch.ping target %% <IP_ADDRESS>:2
8601< Switch test with port 2
8602< switch ping 2
8603---
8604> switch ping 0
On Tue, Dec 10, 2019 at 3:16 PM jhughesbiot<EMAIL_ADDRESS>wrote:

I've attempted to review the travis ci output to determine what the
failure is but all I see is the failure notice with no indication of the
actual failure. There is a really long job log to review but again, nothing
that I can see indicating the exact failure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPD4L2KKHR42R2JTZIADQYAPMVA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGRJL2Y#issuecomment-564303339,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD2YIQ3Y544MKWFAEG3QYAPMVANCNFSM4JUPAQRQ
.

That link never seemed to work for me (in its intended use at least) so I was not really able to find what error was happening.  Makes sense now so I'll go ahead and try some things to fix it and if I have to manually find the error line...at least I know what i'm looking for to do that now.

I attempted an update to try to correct and/or expose the next issue down the line and I see the switch_model reference went away but there is still another one present I cannot determine.
Nothing in the CI seems to tell you what actually failed, just that it failed.  Was that something you had to do by inspected the job log manually and then created the link to the line?  If so, is there specific terms that can be searched for to find the true cause of the failures?

There is no way to always know what actually failed... it's an integration
test suite that tests the integration across multiple components, so
each one has its individual proclivities, and all the tests really do at
the end is test "was the result correct"... the rest more or less requires
differential debugging with a known-good test run.
In this particular case, I think the failure you're seeing is because of a
flaky test. Hard to know up-front unless you're familiar with the system.
I'm trying to run it a couple more times and we'll see how that fairs. So
just give me a bit and we'll see how it plays out.
On Wed, Dec 11, 2019 at 8:05 AM jhughesbiot<EMAIL_ADDRESS>wrote:

I attempted an update to try to correct and/or expose the next issue down
the line and I see the switch_model reference went away but there is still
another one present I cannot determine.
Nothing in the CI seems to tell you what actually failed, just that it
failed. Was that something you had to do by inspected the job log manually
and then created the link to the line? If so, is there specific terms that
can be searched for to find the true cause of the failures?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPDZMTM3QE3AO6F4R2XDQYEFTXA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTVA5Q#issuecomment-564613238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD2WI4CAMC6G5XLM4ZDQYEFTXANCNFSM4JUPAQRQ
.

So -- not entirely sure what's going on, but something is wonky with the CI
setup for that test. It works when I pull it in to my repo as a regular
branch. I'll have to sort that out some other time... But for now, this one
is good-to-go so I'm gonna merge it in.
Thanks for your work putting this together and patience!
On Wed, Dec 11, 2019 at 9:46 AM Trevor Pering<EMAIL_ADDRESS>wrote:

There is no way to always know what actually failed... it's an integration
test suite that tests the integration across multiple components, so
each one has its individual proclivities, and all the tests really do at
the end is test "was the result correct"... the rest more or less requires
differential debugging with a known-good test run.
In this particular case, I think the failure you're seeing is because of a
flaky test. Hard to know up-front unless you're familiar with the system.
I'm trying to run it a couple more times and we'll see how that fairs. So
just give me a bit and we'll see how it plays out.
On Wed, Dec 11, 2019 at 8:05 AM jhughesbiot<EMAIL_ADDRESS>wrote:

I attempted an update to try to correct and/or expose the next issue down
the line and I see the switch_model reference went away but there is still
another one present I cannot determine.
Nothing in the CI seems to tell you what actually failed, just that it
failed. Was that something you had to do by inspected the job log manually
and then created the link to the line? If so, is there specific terms that
can be searched for to find the true cause of the failures?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grafnu/daq/pull/267?email_source=notifications&email_token=AAIEPDZMTM3QE3AO6F4R2XDQYEFTXA5CNFSM4JUPAQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTVA5Q#issuecomment-564613238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIEPD2WI4CAMC6G5XLM4ZDQYEFTXANCNFSM4JUPAQRQ
.


GraphToRules: Converting "." in property name to "_"

Is your feature request related to a problem? Please describe.
GraphToRules generates property names such as "Fragment.id", which is not allowed in CDF.
Describe the solution you'd like
the property name should be converted to a CDF valid name, such as "Fragment_id", together with a warning about the changes.

Possibly should be done similarly to ArbitraryJsonYamlToRules step , where the conversion (set of conversion rules ) is controlled by setting fdm_compatibility_mode configuration parameter


Keyword blocklist | Generated C code contains key words

A variable that's called unsigned in Rust, will get translated into a C variable, called unsigned, which is a keyword.
Eurydice should change variable names that are keywords in C.

Thanks. The blocklist is in krml's lib/GlobalNames.ml and unsigned is already in there so I need to investigate.


Custom marker in SymbolLayer with data

I am trying to make pins with clustered points. I can make it work but i need single markers like in the second picture. I can't use a custom View property in the SymbolLayer. I am able to put one png like in the first picture. But what i need it something like in the second picture. When i put  in the SymbolLayer it is not working.
This is what i did.

This is what i want to do.

<MapboxGL.MapView
        styleURL={"mapbox://styles/sammyoguzhan/cl6ovork9003215qhd0xtzmx4"}
        showUserLocation={true}
        compassEnabled={false}
        pitchEnabled={true}
        panEnabled={true}
        style={{ height: height, width: width }}
        ref={(ref) => (_map = ref)}
      >
        <MapboxGL.Camera
          ref={_camera}
          centerCoordinate={[-73.97953068202536, 40.76374230439849]}
          zoomLevel={14}
          pitch={60}
        />
        {!isLoading ? (
          <ShapeSource
            id="symbolLocationSource"
            shape={shape}
            cluster={true}
            clusterRadius={80}
            clusterMaxZoom={14}
            onPress={async (pressedShape) => {
              onSourceLayerPress(pressedShape);
            }}
            ref={_sourceRef}
          >
            <MapboxGL.SymbolLayer
              id="pointCount"
              minZoomLevel={6}
              style={{ textField: "{point_count}", textColor: "#fff" }}
            />
            <MapboxGL.CircleLayer
              id="clusteredPoints"
              minZoomLevel={6}
              belowLayerID="pointCount"
              filter={[">", "point_count", 1]}
              style={{
                circleColor: "#ff0d0d",
                circleRadius: 18,
              }}
            />
            <MapboxGL.SymbolLayer
              id="singlePoint"
              filter={["!", ["has", "point_count"]]}
              style={{
                iconImage: history_png,
                iconSize: 0.1,
              }}
            />
          </ShapeSource>
        ) : (
          <View />
        )}
      </MapboxGL.MapView>

I thinks it's the same as #2426. Look into the Images component if you want to use multiple images.

any solution?


Doesn't work with concierge service

When using a concierge service (i.e doing a bicep module through learn.microsoft) the user doesn't have permission to use this command:
$ echo "Enter your email address that is used to sign in to Azure:" && read upn && az ad user show --id $upn --query "objectId" && echo "Press [ENTER] to continue ..."

In this situation, if you want to get the objectid of the current user you are logged in with you can use this instead:
az ad signed-in-user show --query "objectId"

This will run successfully in more scenarios.
Not sure if you want to include this or not, but thought it might be helpful for me to document through this issue at least.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 1c66dbe4-1959-fe57-d445-b8658e8f1b7e
Version Independent ID: f5809176-8c97-a4a3-644a-01b7a5e556d5
Content: Azure Quickstart - Create an Azure key vault and a secret using Bicep
Content Source: articles/key-vault/secrets/quick-create-bicep.md
Service: key-vault
Sub-service: secrets
GitHub Login: @rkarlin
Microsoft Alias: rkarlin

@dazinator
Thanks for your feedback! We will investigate and update as appropriate.

@dazinator
Thanks for your contribution. Please add your ideas in below link, so our production team can review it and update the same.
Ideas · Community (azure.com)


Search resources everywhere, not only in active flavor

Please add option to search resources everywhere in project.
For example in inactive flavors (*.java, *.xml files)
It will killer-feature if will show usages inside all files. Because most large projects uses 2 or more flavors. So IDEA's find usages is useless here.
I think it could be implemented by using Text Index search instead of Find Usages search.
For example to search any usage inside Java file it could use next pattern to search text:
R.<type>.<resource_name>
While for XML it could be:
@<type>/<resource_name>
This also automatically solves problem similar to that:
https://github.com/niorgai/Android-Resource-Usage-Count/issues/23

Well..I think it's not a feature but a bug of Android Studio(IntelliJ idea).
Resource should be searched everywhere even if they are in different flavors.
Since Android Studio(IntelliJ idea) has too much version, it's too difficult to test the search method's compatible, and that's the reason why i use the official Find Usage search.
So i think we should wait for Android Studio(IntelliJ idea) fix it.