7:12 p.m.
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(a)lists.podman.io](mailto:
podman-join(a)lists.podman.io?subject=subscribe) with the word
“subscribe” as the title.
7:03 a.m.
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(a)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.
12:32 p.m.
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(a)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(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
10:44 a.m.
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(a)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_clien...
https://github.com/containers/libpod/blob/master/docs/tutorials/remote_cl...
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
1:28 p.m.
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
2:27 p.m.
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(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
Sounds good to me. Podman 2.0 is not released anywhere yet. Just in Beta.
2006
days inactive
2033
days old
5 comments
3 participants
participants (3)
-
Anders F Björklund -
Brent Baude -
Daniel Walsh