Update on Podman V2 A few weeks ago, we made an announcement about the development of Podman V2. In the announcement, we mentioned that the state of upstream code would be jumbled for a while and that we would be temporarily disabling many of our CI/CD tests. The upstream development team has been hard at work, and we are starting to see that work pay off. Today, we are very excited to announce: The local Podman v2 client is complete. It is passing all of its rootfull and rootless system and integration tests. The CI/CID tests have been reenabled upstream and are run with each pull request submission. We are now hard at work finishing up some of the core podman-remote functions. Once those functions are complete, we can then begin to run our podman-remote system and integration tests to catch any regressions. We have re-enabled the autobuilds for Podman v2 in Fedora rawhide. As mentioned earlier, the Podman remote client is not complete, so that binary is temporarily being removed from the RPM. It will be re-added when the remote client is complete. As a corollary, the Windows and OS/X clients are also not being compiled or tested. This will occur once the remote client for Linux is complete. We encourage you to pull the latest upstream Podman code and exercise it with your use cases to help us protect against regressions from Podman v1. We hope to make a full Podman v2.0 release in several weeks, once we are confident it is stable. We look forward to hearing what you think, and please do not hesitate to raise issues and comments on this in our [GitHub repository]( https://github.com/containers/libpod/issues), our Freenode IRC channel `#podman`, or to the Podman mailing list. We’re very excited to bring Podman v2.0 to you as it offers a lot more flexibility through it’s new REST API interface and adds several enhancements to the existing commands. If your project builds on top of Podman, we would especially love to have you test this new version out so we can ensure complete compatibility with Podman v1.0 and address any issues found ASAP. Note: This announcement was first released to the Podman mailing list. If you are not yet a member of that community, please join us by sending an email to [podman-join@lists.podman.io](mailto: podman-join@lists.podman.io?subject=subscribe) with the word “subscribe” as the title.
Do you have some kind of "migration guide", how to move from varlink to HTTP ? Currently we connect over ssh, and then run this command: sudo varlink -A "podman varlink $VARLINK_ADDRESS" bridge The complete command goes into the PODMAN_VARLINK_BRIDGE, with ssh etc. What environment variable should be exported now, and how should it be set up ? Do we just export the same variables as before, or are there some new ones to use: export PODMAN_USER="root" export PODMAN_HOST="127.0.0.1" export PODMAN_PORT="36230" export PODMAN_IDENTITY_FILE="/home/anders/.local/machine/machines/box/id_rsa" export PODMAN_IGNORE_HOSTS="true" Can we still use "sudo", or do we have to enable ssh logins for the root user now ? Currently root login is disabled (default), since we found the sudo varlink workaround. Tried to use the varlink resolver and the varlink socket, and it worked - for a while. $ sudo varlink resolve io.podman unix:/run/podman/io.podman;mode=0600 But we never got interactive (-it) sessions working, so not using those anymore... This would be for existing "podman-machine env" and "minikube podman-env." Both of those are currently using the varlink bridge, and podman version 1.8.2 /Anders Den tors 14 maj 2020 kl 02:14 skrev Brent Baude <bbaude@redhat.com>:
Update on Podman V2
A few weeks ago, we made an announcement about the development of Podman V2. In the announcement, we mentioned that the state of upstream code would be jumbled for a while and that we would be temporarily disabling many of our CI/CD tests. The upstream development team has been hard at work, and we are starting to see that work pay off.
Today, we are very excited to announce:
The local Podman v2 client is complete. It is passing all of its rootfull and rootless system and integration tests.
The CI/CID tests have been reenabled upstream and are run with each pull request submission. We are now hard at work finishing up some of the core podman-remote functions. Once those functions are complete, we can then begin to run our podman-remote system and integration tests to catch any regressions.
We have re-enabled the autobuilds for Podman v2 in Fedora rawhide. As mentioned earlier, the Podman remote client is not complete, so that binary is temporarily being removed from the RPM. It will be re-added when the remote client is complete. As a corollary, the Windows and OS/X clients are also not being compiled or tested. This will occur once the remote client for Linux is complete.
We encourage you to pull the latest upstream Podman code and exercise it with your use cases to help us protect against regressions from Podman v1. We hope to make a full Podman v2.0 release in several weeks, once we are confident it is stable. We look forward to hearing what you think, and please do not hesitate to raise issues and comments on this in our [GitHub repository]( https://github.com/containers/libpod/issues), our Freenode IRC channel `#podman`, or to the Podman mailing list.
We’re very excited to bring Podman v2.0 to you as it offers a lot more flexibility through it’s new REST API interface and adds several enhancements to the existing commands. If your project builds on top of Podman, we would especially love to have you test this new version out so we can ensure complete compatibility with Podman v1.0 and address any issues found ASAP.
On 5/16/20 08:03, Anders F Björklund wrote:
Do you have some kind of "migration guide", how to move from varlink to HTTP ?
Currently we connect over ssh, and then run this command:
sudo varlink -A "podman varlink $VARLINK_ADDRESS" bridge
The complete command goes into the PODMAN_VARLINK_BRIDGE, with ssh etc.
What environment variable should be exported now, and how should it be set up ?
Do we just export the same variables as before, or are there some new ones to use:
export PODMAN_USER="root" export PODMAN_HOST="127.0.0.1" export PODMAN_PORT="36230" export PODMAN_IDENTITY_FILE="/home/anders/.local/machine/machines/box/id_rsa" export PODMAN_IGNORE_HOSTS="true"
Can we still use "sudo", or do we have to enable ssh logins for the root user now ?
Currently root login is disabled (default), since we found the sudo varlink workaround.
Tried to use the varlink resolver and the varlink socket, and it worked - for a while.
$ sudo varlink resolve io.podman unix:/run/podman/io.podman;mode=0600
But we never got interactive (-it) sessions working, so not using those anymore...
This would be for existing "podman-machine env" and "minikube podman-env."
Both of those are currently using the varlink bridge, and podman version 1.8.2
/Anders
Den tors 14 maj 2020 kl 02:14 skrev Brent Baude <bbaude@redhat.com <mailto:bbaude@redhat.com>>:
Update on Podman V2
A few weeks ago, we made an announcement about the development of Podman V2. In the announcement, we mentioned that the state of upstream code would be jumbled for a while and that we would be temporarily disabling many of our CI/CD tests. The upstream development team has been hard at work, and we are starting to see that work pay off.
Today, we are very excited to announce:
The local Podman v2 client is complete. It is passing all of its rootfull and rootless system and integration tests.
The CI/CID tests have been reenabled upstream and are run with each pull request submission. We are now hard at work finishing up some of the core podman-remote functions. Once those functions are complete, we can then begin to run our podman-remote system and integration tests to catch any regressions.
We have re-enabled the autobuilds for Podman v2 in Fedora rawhide. As mentioned earlier, the Podman remote client is not complete, so that binary is temporarily being removed from the RPM. It will be re-added when the remote client is complete. As a corollary, the Windows and OS/X clients are also not being compiled or tested. This will occur once the remote client for Linux is complete.
We encourage you to pull the latest upstream Podman code and exercise it with your use cases to help us protect against regressions from Podman v1. We hope to make a full Podman v2.0 release in several weeks, once we are confident it is stable. We look forward to hearing what you think, and please do not hesitate to raise issues and comments on this in our [GitHub repository]( https://github.com/containers/libpod/issues), our Freenode IRC channel `#podman`, or to the Podman mailing list.
We’re very excited to bring Podman v2.0 to you as it offers a lot more flexibility through it’s new REST API interface and adds several enhancements to the existing commands. If your project builds on top of Podman, we would especially love to have you test this new version out so we can ensure complete compatibility with Podman v1.0 and address any issues found ASAP.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Den 2020-05-18 kl. 19:32, skrev Daniel Walsh:
On 5/16/20 08:03, Anders F Björklund wrote:
Do you have some kind of "migration guide", how to move from varlink to HTTP ?
Currently we connect over ssh, and then run this command:
sudo varlink -A "podman varlink $VARLINK_ADDRESS" bridge
The complete command goes into the PODMAN_VARLINK_BRIDGE, with ssh etc.
What environment variable should be exported now, and how should it be set up ? ... Den tors 14 maj 2020 kl 02:14 skrev Brent Baude <bbaude@redhat.com <mailto:bbaude@redhat.com>>:
We’re very excited to bring Podman v2.0 to you as it offers a lot more flexibility through it’s new REST API interface and adds several enhancements to the existing commands. If your project builds on top of Podman, we would especially love to have you test this new version out so we can ensure complete compatibility with Podman v1.0 and address any issues found ASAP.
I take it that this (2.0) is still being worked on, and with the current problems when building using podman-remote 1.9.x, we will go with 1.8.2 We still have ssh as a workaround, so if varlink stops working further we can send the "build context" (tarball) as stdin to the build command. The regular "podman-env" setup is mostly used for users that cannot run Linux podman locally, and want to avoid running _two_ virtual machines. i.e. one for kubernetes running cri-o (with podman for image loading) and one for podman containers primarily (with k3s and crio as add-ons) I guess there will be more Podman 2 documentation closer to the launch ? And maybe at least some Fedora tutorial, on how to run podman remotely. https://github.com/containers/libpod/blob/master/docs/tutorials/mac_client.m... https://github.com/containers/libpod/blob/master/docs/tutorials/remote_clien... And it would be great if the stable releases of podman (1.6.x and 1.8.x) could be kept available, both the Ubuntu packages and the podman-remote /Anders
Daniel Walsh wrote:
On 5/16/20 08:03, Anders F Björklund wrote:
Do you have some kind of "migration guide", how to move from varlink to HTTP ?
Currently we connect over ssh, and then run this command:
sudo varlink -A "podman varlink $VARLINK_ADDRESS" bridge
The complete command goes into the PODMAN_VARLINK_BRIDGE, with ssh etc.
What environment variable should be exported now, and how should it be set up ?
Do we just export the same variables as before, or are there some new ones to use:
export PODMAN_USER="root" export PODMAN_HOST="127.0.0.1" export PODMAN_PORT="36230" export PODMAN_IDENTITY_FILE="/home/anders/.local/machine/machines/box/id_rsa" export PODMAN_IGNORE_HOSTS="true"
Eventually found out (in the source), that the new variable is called $CONTAINER_HOST and that it follows the same syntax as $DOCKER_HOST : CONTAINER_HOST=ssh://root@127.0.0.1:36230 CONTAINER_SSHKEY="/home/anders/.local/machine/machines/box/id_rsa"
Can we still use "sudo", or do we have to enable ssh logins for the root user now ?
Currently root login is disabled (default), since we found the sudo varlink workaround.
Tried to use the varlink resolver and the varlink socket, and it worked - for a while.
$ sudo varlink resolve io.podman unix:/run/podman/io.podman;mode=0600
But we never got interactive (-it) sessions working, so not using those anymore...
It seems like the user will either be root, or have the equivalent access to the podman socket (through the user or group or something) Running "sudo" doesn't really work anymore, since it is now just a path (/run/podman/podman.sock) and not a command (varlink).
This would be for existing "podman-machine env" and "minikube podman-env."
Both of those are currently using the varlink bridge, and podman version 1.8.2
It seems like most of the bugs with version 1.9.2 have now been fixed... So should be able to use 2.0 (RC), while support clients 1.6 and up. Probably will stick with 1.9.3 and varlink for the upcoming releases, since those are only a couple of weeks away (and already implemented). /Anders
On 6/9/20 14:28, Anders F Björklund wrote:
Daniel Walsh wrote:
On 5/16/20 08:03, Anders F Björklund wrote:
Do you have some kind of "migration guide", how to move from varlink to HTTP ?
Currently we connect over ssh, and then run this command:
sudo varlink -A "podman varlink $VARLINK_ADDRESS" bridge
The complete command goes into the PODMAN_VARLINK_BRIDGE, with ssh etc.
What environment variable should be exported now, and how should it be set up ?
Do we just export the same variables as before, or are there some new ones to use:
export PODMAN_USER="root" export PODMAN_HOST="127.0.0.1" export PODMAN_PORT="36230" export PODMAN_IDENTITY_FILE="/home/anders/.local/machine/machines/box/id_rsa" export PODMAN_IGNORE_HOSTS="true" Eventually found out (in the source), that the new variable is called $CONTAINER_HOST and that it follows the same syntax as $DOCKER_HOST :
CONTAINER_HOST=ssh://root@127.0.0.1:36230 CONTAINER_SSHKEY="/home/anders/.local/machine/machines/box/id_rsa"
Can we still use "sudo", or do we have to enable ssh logins for the root user now ?
Currently root login is disabled (default), since we found the sudo varlink workaround.
Tried to use the varlink resolver and the varlink socket, and it worked - for a while.
$ sudo varlink resolve io.podman unix:/run/podman/io.podman;mode=0600
But we never got interactive (-it) sessions working, so not using those anymore... It seems like the user will either be root, or have the equivalent access to the podman socket (through the user or group or something)
Running "sudo" doesn't really work anymore, since it is now just a path (/run/podman/podman.sock) and not a command (varlink).
This would be for existing "podman-machine env" and "minikube podman-env."
Both of those are currently using the varlink bridge, and podman version 1.8.2 It seems like most of the bugs with version 1.9.2 have now been fixed... So should be able to use 2.0 (RC), while support clients 1.6 and up.
Probably will stick with 1.9.3 and varlink for the upcoming releases, since those are only a couple of weeks away (and already implemented).
/Anders _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Sounds good to me. Podman 2.0 is not released anywhere yet. Just in Beta.
participants (3)
-
Anders F Björklund -
Brent Baude -
Daniel Walsh