It maybe an intermittent error on the store side and couldn’t download it correctly (hence the EOF). I checked to ensure that it does install for focal with the following commands:
This also might be a proxy issue, correct? Juju is attempting to get metadata or a file blob, and if it gets proxy landing page html instead, it can become confused.
Are there things that we can do internally to help make the error messages less ambiguous in this case? Passing the raw error when reading from the socket isn’t super classy – we can at least wrap it in “Error contacting the charm store” or something else that gives users who don’t know Juju internals a better shot at diagnosing things.
Other than ensuring you have egress to the charm store, you can do it manually by either downloading the charm on another computer and scp/rsync’ing the charm across to your MAAS machine or from mysql router | Juju
Thank u.
I download all charms.zip by other provider’s network and unzip them.
they are "openstack-base-70,ceph-mon-49,ceph-osd-304,ceph-radosgw-290,cinder-304,cinder-ceph-257,mysql-router-3,glance-298,keystone-317,cs:mysql-innodb-cluster-1,cs:neutron-api-287,neutron-api-plugin-ovn-1,nova-cloud-controller-346,nova-compute-319,ntp-41,openstack-dashboard-305,ovn-central-1,ovn-chassis-3,placement-12,rabbitmq-server-104,vault-40
And filezilla them to maas server’s /root/openstack-base/
Then I modified bundle.yaml:
from" charm: cs:"
into “charm: /root/openstack-base”
then I “juju deploy ./root/openstack-base/openstack-base/bundle.yaml”