srl-labs
Add cJunosEvolved
- adding cJunosEvolved to containerlab
- adding the cJunosEvolved lab example and it's doc
- adding the cJunosEvolved description manual
thanks @kmo7
@vista- could you give this a try when you have time given you are my Juniper buddy 👯
cJunosEvolved will be released at the end of this month and at that time, the link mentioned in the doc will be available.
We wanted to put this up for review early, so it can be merged in to containerlab when it is released.
If it helps, I can post the results of my testing, showing cJunosEvolved coming up and pinging Srlinux fine, etc on this review (or would you like it committed to the repo in the lab-examples document at the end?
I am the developer for cJunosEvolved, but we cannot provide an image till the official release goes out. We can however meet and answer questions if you like?
Thanks.
Juniper Business Use Only From: Roman Dodin @.> Sent: Thursday, June 12, 2025 1:25 AM To: srl-labs/containerlab @.> Cc: Kaveh Moezzi @.>; Mention @.> Subject: Re: [srl-labs/containerlab] Add cJunosEvolved (PR #2617)
[External Email. Be cautious of content]
@hellt commented on this pull request.
In docs/manual/kinds/cjunosevolved.mdhttps://urldefense.com/v3/__https:/github.com/srl-labs/containerlab/pull/2617*discussion_r2142044318__;Iw!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0lcXUm7RA$:
+## How to obtain the image
+The container image can be freely downloaded from the Juniper support portal without a Juniper account. Type cJunosEvolved in the Find a Product search box.
It seems the support portal does not list cjunos evolved as a product available for download
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/srl-labs/containerlab/pull/2617*pullrequestreview-2920052451__;Iw!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0l0wDmffg$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AVFQEDKY2IC6AC2BC75YPOT3DE2N3AVCNFSM6AAAAAB7DYGFKCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDSMRQGA2TENBVGE__;!!NEt6yMaO-gk!FC9U6NzJd_mfwpBP4SMUHvfjVfH5XjuO6E0LEnrG_a6q7fMkQaVqE1-AdXMGPtGj5xcCDEKtrchhVTOzD0lD_Xchfg$. You are receiving this because you were mentioned.Message ID: @.***>
Thanks @kmo7 for the comments. It is great seeing contributions for new systems coming ahead of the release time, love it.
Given our reliance on you doing the testing, I'd say the path forward is to address existing comments and then re-checking that the same MVP reproduction with srl-cjunos works
@kmo7 I rebased your branch onto latest main to add a recent commit that fixes the CI/CD pipeline, just as a heads-up
@kmo7 I rebased your branch onto latest
mainto add a recent commit that fixes the CI/CD pipeline, just as a heads-up
Thanks Vista, i don't see this commit reflected in containerlab.dev yet, e.g. on the front page where vendor notes are listed. https://containerlab.dev/ or in the nodes directory: https://github.com/srl-labs/containerlab/tree/main/nodes
Are you waiting on the image from us or the rebase operation to be done>
Hi all,
Might be too early, but would it be possible to add a pre-config hook to the cJunosEvolved router kind in Containerlab to execute a couple of operational commands that generate TLS certificates directly on the container?
The commands are:
request security pki generate-key-pair certificate-id myname
request security pki local-certificate generate-self-signed certificate-id myname subject CN=abc domain-name clab.com ip-address 1.2.3.4 email [email protected]
This would enable the configuration of TLS-based services like RESTCONF in the startup-config:
services {
rest {
https {
port 3000;
server-certificate myname;
}
}
}
Let me know if that’s feasible or if there’s a preferred approach.
Thanks! Nicolas
Hi @kmo7,
Congrats on launching cJunosEvo! Thank you again for your hard work with preparing this PR.
I just tried out the cJunosEvo image, just a few observations:
The way the startup configuration to the node is provided does not really match the way most other Containerlab kinds do it: they just append the generated config required for management connectivity to the provided config.
cJunosEvolved, on the other hand, expects the provided startup config to contain the mgmt config to template into.
This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node).
Rather than your current approach for generating an initial startup configuration, perhaps it would be better to put this logic (rendering a default config template and merging it with the user-provided startup config) into Containerlab? Check out how it's done with cRPD, it's fairly easy to template in runtime variables: https://github.com/srl-labs/containerlab/blob/main/nodes/crpd/crpd.go#L155
Some further notes:
- The default config loaded on the node is a bit lackluster. I would suggest adding the following:
- Hostname should be included for easy identification of nodes in the topology
- NETCONF and gNMI should be pre-enabled in the default config
-
system { management-instance; }helps avoid issues down the line where you might kill your own management connectivity
- I would add "Node can take 5+ minutes to boot" to the Kind documentation, since some users won't look in the container logs to find out if it's actually booting or not.
- Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?
Hi @kmo7,
Congrats on launching cJunosEvo! Thank you again for your hard work with preparing this PR.
I just tried out the cJunosEvo image, just a few observations:
The way the startup configuration to the node is provided does not really match the way most other Containerlab kinds do it: they just append the generated config required for management connectivity to the provided config.
cJunosEvolved, on the other hand, expects the provided startup config to contain the mgmt config to template into.
This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node).
Rather than your current approach for generating an initial startup configuration, perhaps it would be better to put this logic (rendering a default config template and merging it with the user-provided startup config) into Containerlab? Check out how it's done with cRPD, it's fairly easy to template in runtime variables: https://github.com/srl-labs/containerlab/blob/main/nodes/crpd/crpd.go#L155
Some further notes:
* The default config loaded on the node is a bit lackluster. I would suggest adding the following: * Hostname should be included for easy identification of nodes in the topology * NETCONF and gNMI should be pre-enabled in the default config * `system { management-instance; }` helps avoid issues down the line where you might kill your own management connectivity * I would add "Node can take 5+ minutes to boot" to the Kind documentation, since some users won't look in the container logs to find out if it's actually booting or not. * Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?
Reponse: Hi Vista, thanks for the review. Have incorporated some of the comments and we will look at the rest for the next commit. Since cJunosEvolved has now been also verified by you to be working, can you please merge the pull request into containerlab so the many others that are expressing interest to use it, can do so, and will get back to you on the rest? Please see below responses to the comments.
- With respect to the longer comment up front, this is the key point "This essentially means a user would have to manually edit the configuration saved from the node in order for it to be usable in the next deploy (which might not assign the same management IP address to the node)." 3 points on this: 1- The current FXP0ADDR token scheme our code uses, does correctly configure the management IP according to what containerlab passes in to the container, even when the cevo instance is restarted and a new management port IP is assigned by the containerlab. 2- As you know, the save command has not been working in general for many containers in containerlab and you are fixing that but it is not yet committed: https://github.com/srl-labs/containerlab/pull/2659 Once that is committed, for vr-net lab based containers, could you also fix it for cjunosevo? 3- With the combination of the above 2 points, even though cjunosevolved does this differently than some other containers in clab, it will still function correctly.
wrt to these comments: o Hostname should be included for easy identification of nodes in the topology. Yes, agreed. We will address this in a subsequent commit. This feature works in our docker compose deployements, but has one line missing to make it work in containerlab. Either by adding that line or by pushing the hostname from the go code, we will fix this, but do not want to delay the initial commit, so people can bringup cjunosevo and use it initially. o NETCONF and gNMI should be pre-enabled in the default config
- netconf already is enabled in the following config file: lab-examples/srlcjunosevo/cjunosevo.cfg. Users can do same for their deployments (will show the test log for this at the end).
- GNMI was not enabled for our vJunosEvolved, vJunos-switch and vJunos-router also. This needs a bit more work and we will enable it in a subsequent commit. o system { management-instance; Added this to the above config file to separate the mgmt port into its own routing instance. "• I would add "Node can take 5+ minutes to boot" to the Kind documentation,". This was already documented in this kind doc file: docs/manual/kinds/cjunosevolved.md, line 28. If you think it is needed elsewhere too, can you please add it?
"Perhaps define a health check command to give feedback to the user/containerlab when the node has finished booting?" I have added this info the kind documentation file. Besides the docker log command, the " # docker exec -ti clab-srlcjunosevo-cevo cli" indicates bootup progress periodically, so the user is not blind to that.
Thanks for the careful review Vista. I hope above answers the immediate comments so you can commit the code into clab and I will follow up w/ the rest.
Here is a sample netconf log:
ssh admin@clab-srlcjunosevo-cevo -p 830 -s netconf
Warning: Permanently added '[clab-srlcjunosevo-cevo]:830' (ED25519) to the list of known hosts. (admin@clab-srlcjunosevo-cevo) Password:
Codecov Report
Attention: Patch coverage is 17.64706% with 42 lines in your changes missing coverage. Please review.
Project coverage is 54.83%. Comparing base (
02513f6) to head (69291f6). Report is 25 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| nodes/cjunosevolved/cjunosevolved.go | 16.00% | 41 Missing and 1 partial :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #2617 +/- ##
==========================================
- Coverage 54.90% 54.83% -0.07%
==========================================
Files 184 185 +1
Lines 20151 20202 +51
==========================================
+ Hits 11063 11078 +15
- Misses 7948 7985 +37
+ Partials 1140 1139 -1
| Files with missing lines | Coverage Δ | |
|---|---|---|
| clab/register.go | 100.00% <100.00%> (ø) |
|
| nodes/cjunosevolved/cjunosevolved.go | 16.00% <16.00%> (ø) |
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}