Re: Charm release fails with "cannot update base entity for..."

[Merlijn Sebrechts]

Ok, thanks!


This might be a bug in `charm build`. It merges the "series" array of
multiple layers' metadata.yaml.

2017-01-04 18:18 GMT+01:00 roger peppe :

> OK, I've found the issue. Your metadata.yaml specifies "trusty" twice
> in the "series" attribute.
> Specifying it only once should allow you to release.
>
> We should produce a better error message for this case (or just
> de-duplicate series).
>
>   cheers,
> rog.
>
> On 3 January 2017 at 12:17, Merlijn Sebrechts
>  wrote:
> > Hi all
> >
> >
> > When releasing my charm I get the following error:
> >
> > charm release cs:~tengu-team/jupiter-notebook-spark-0
> > ERROR cannot release charm or bundle: cannot publish charm or bundle:
> cannot
> > update base entity for "cs:~tengu-team/jupiter-notebook-spark-0": Field
> name
> > duplication not allowed with modifiers
> >
> > A quick google shows that this is a MongoDB error. Is something wrong
> with
> > the cs backend?
> >
> >
> >
> > Kind regards
> > Merlijn
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm release fails with "cannot update base entity for..."

[roger peppe]

OK, I've found the issue. Your metadata.yaml specifies "trusty" twice
in the "series" attribute.
Specifying it only once should allow you to release.

We should produce a better error message for this case (or just
de-duplicate series).

  cheers,
rog.

On 3 January 2017 at 12:17, Merlijn Sebrechts
 wrote:
> Hi all
>
>
> When releasing my charm I get the following error:
>
> charm release cs:~tengu-team/jupiter-notebook-spark-0
> ERROR cannot release charm or bundle: cannot publish charm or bundle: cannot
> update base entity for "cs:~tengu-team/jupiter-notebook-spark-0": Field name
> duplication not allowed with modifiers
>
> A quick google shows that this is a MongoDB error. Is something wrong with
> the cs backend?
>
>
>
> Kind regards
> Merlijn
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using a bundle with manually added machines (redux)

[roger peppe]

On 4 January 2017 at 15:34, roger peppe  wrote:
> a dep option

I meant to say "a deploy option" here.

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm release fails with "cannot update base entity for..."

[roger peppe]

Ah, sorry, I misread above - I thought that "jupyter" was the
incorrect spelling.
Will look again.

On 4 January 2017 at 10:49, Merlijn Sebrechts
 wrote:
> Correct. In the staging charm store I only used the (correct) name
> jupyter-notebook-spark. It's in the normal charm store that I used the
> incorrect  jupiter-notebook-spark.
>
> 2017-01-04 11:04 GMT+01:00 roger peppe :
>>
>> On 3 January 2017 at 13:05, Merlijn Sebrechts
>>  wrote:
>> > I have the same issue in the staging charm store.
>> >
>> >
>> > charm release  cs:~tengu-team/jupyter-notebook-spark-0
>> > ERROR cannot release charm or bundle: cannot publish charm or bundle:
>> > cannot
>> > update base entity for "cs:~tengu-team/jupyter-notebook-spark-0": Field
>> > name
>> > duplication not allowed with modifiers
>> >
>> >
>> > Maybe this has something to do with it; the first time I pushed this
>> > charm I
>> > pushed to a wrong name (jupIter instead of jupYter):
>> >
>> > charm push jupyter-notebook-spark/ ~tengu-team/jupiter-notebook-spark
>> >
>> > Although I did it right the first time in the staging charm store, and
>> > it
>> > still doesn't work.
>> >
>> > Also, I'm user `merlijn-sebrechts` and I'm pushing to `tengu-team`. This
>> > has
>> > worked before.
>>
>> I don't see any record of any operations on jupiter-notebook-spark on the
>> staging charmstore (I can see the accesses to jupyter-notebook-spark).
>>
>> Are you sure you exported your JUJU_CHARMSTORE environment
>> variable correctly?
>>
>>   cheers,
>> rog.
>
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: master/CiaB: Wait for juju services to have open ports - Timeout when waiting for services

[Mac Lin]

This is the content of juju-bad.log, result of "juju status" on my server.
Or please let me know what command should I gave.

It's difficult for me to try them out in ansible playbook. *sigh*

environment: manual
machines:
  "0":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: juju.cord.lab
instance-id: 'manual:'
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
state-server-member-status: has-vote
  "1":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: keystone.cord.lab
instance-id: manual:keystone.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "2":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: percona-cluster.cord.lab
instance-id: manual:percona-cluster.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "3":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: nagios.cord.lab
instance-id: manual:nagios.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "4":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: neutron-api.cord.lab
instance-id: manual:neutron-api.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "5":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: nova-cloud-controller.cord.lab
instance-id: manual:nova-cloud-controller.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "6":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: openstack-dashboard.cord.lab
instance-id: manual:openstack-dashboard.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "7":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: rabbitmq-server.cord.lab
instance-id: manual:rabbitmq-server.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "8":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: mongodb.cord.lab
instance-id: manual:mongodb.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "9":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: ceilometer.cord.lab
instance-id: manual:ceilometer.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
  "10":
agent-state: started
agent-state-info: (started)
agent-version: 1.25.9
dns-name: glance.cord.lab
instance-id: manual:glance.cord.lab
series: trusty
hardware: arch=amd64 cpu-cores=8 mem=24112M
services:
  ceilometer:
charm: cs:trusty/ceilometer-17
exposed: false
service-status:
  current: blocked
  message: 'Missing relations: messaging, identity, database'
  since: 03 Jan 2017 19:39:55Z
relations:
  amqp:
  - rabbitmq-server
  ceilometer-service:
  - ceilometer-agent
  cluster:
  - ceilometer
  identity-service:
  - keystone
  juju-info:
  - nagios
  nrpe-external-master:
  - nrpe
  shared-db:
  - mongodb
units:
  ceilometer/0:
workload-status:
  current: blocked
  message: 'Missing relations: messaging, identity, database'
  since: 03 Jan 2017 19:39:55Z
agent-status:
  current: executing
  message: running install hook
  since: 03 Jan 2017 14:53:31Z
  version: 1.25.9
agent-state: started
agent-version: 1.25.9
machine: "9"
open-ports:
- 8777/tcp
public-address: ceilometer.cord.lab
  ceilometer-agent:
charm: cs:trusty/ceilometer-agent-13
exposed: false
service-status: {}
relations:
  ceilometer-service:
  - ceilometer
  glance:
charm: cs:trusty/glance-28
exposed: false
service-status:
  current: blocked
  message: 'Missing relations: identity, database'
  since: 03 Jan 2017 19:39:50Z
relations:
  cluster:
  - glance
  identity-service:
  - keystone
  image-service:
  - nova-cloud-controller
  nrpe-external-master:
  - nrpe
  shared-db:
  - percona-cluster
units:
  glance/0:
workload-status:
  current: blocked
  message: 'Missing relations: identity, database'
  since: 03 Jan 2017 19:39:50Z
agent-status:
  current: executing
  message: running install hook
  since: 03 Jan 2017 14:54:12Z
  version: 1.25.9
agent-state: started
agent-version: 1.25.9
machine: "10"
public-address: glance.cord.lab
  keystone:
charm: cs:trusty/keystone-33
exposed: false
service-status:
  

Re: master/CiaB: Wait for juju services to have open ports - Timeout when waiting for services

[Rick Harding]

Can you paste the relations part of the juju status output that shows those
relations in place? Perhaps there's an issue with the charm logic and
breaking and re-adding the relations might kick it into gear?



On Wed, Jan 4, 2017 at 2:48 AM Mac Lin  wrote:

> Really appreciate for the help. Have been stuck here for weeks.
>
> AFAIK, no. I attached two result of "juju status" on CloudLab(good) and my
> server (bad). It's supposed to work without expose the ports. And I just
> noticed that on my server, most of the services are in blocked status. But
> it seems the missing parts are fulfilled. For example, the ceilometer is
> complaining missing messaging, identity, and database relations, but the
> relation does exist.
>
> Please let me know if any info needed.
>
>   ceilometer:
> charm: cs:trusty/ceilometer-17
> exposed: false
> service-status:
>   current: blocked
>   message: 'Missing relations: messaging, identity, database'
>   since: 03 Jan 2017 19:39:55Z
> relations:
>   amqp:
>   - rabbitmq-server
>   ceilometer-service:
>   - ceilometer-agent
>   cluster:
>   - ceilometer
>   identity-service:
>   - keystone
>   juju-info:
>   - nagios
>   nrpe-external-master:
>   - nrpe
>   shared-db:
>   - mongodb
> units:
>   ceilometer/0:
> workload-status:
>   current: blocked
>   message: 'Missing relations: messaging, identity, database'
>   since: 03 Jan 2017 19:39:55Z
> agent-status:
>   current: executing
>   message: running install hook
>   since: 03 Jan 2017 14:53:31Z
>   version: 1.25.9
> agent-state: started
> agent-version: 1.25.9
> machine: "9"
> open-ports:
> - 8777/tcp
> public-address: ceilometer.cord.lab
>
>
>
> On Tue, Jan 3, 2017 at 8:23 PM, Rick Harding 
> wrote:
>
> Has juju expose been run on the applications? The charm can declare that
> these ports are the ones that are opened if exposed, it's not actually set
> until the operator runs the juju expose command on the application.
>
> On Sun, Jan 1, 2017 at 2:58 AM Mac Lin  wrote:
>
>
> Hi,
>
> I'm running CORD master/cord-in-a-box.sh on an x86_64 server. The same
> script on CloudLab has no problem.
>
> If I log into each failed service(lxc), I could found the port is not
> listened because service is not up, which is due to not configured
> properly. The configuration files are mostly at its initial state.
>
> How could I let juju to generate the configuration for the services
> manually?
>
> TASK [juju-finish : Wait for juju services to have open ports]
> *
> Saturday 31 December 2016  12:04:22 + (0:00:04.738)   0:09:13.981
> *
> failed: [10.100.198.201] (item={u'service': u'ceilometer',
> u'ipv4_last_octet': 20, u'name': u'ceilometer-1', u'forwarded_ports':
> [{u'int': 8777, u'ext': 8777}], u'aliase
> s': [u'ceilometer']}) => {"elapsed": 1800, "failed": true, "item":
> {"aliases": ["ceilometer"], "forwarded_ports": [{"ext": 8777, "int":
> 8777}], "ipv4_last_octet": 20, "n
> ame": "ceilometer-1", "service": "ceilometer"}, "msg": "Timeout when
> waiting for ceilometer-1:8777"}
> failed: [10.100.198.201] (item={u'service': u'glance', u'ipv4_last_octet':
> 30, u'name': u'glance-1', u'forwarded_ports': [{u'int': 9292, u'ext':
> 9292}], u'aliases': [u'g
> lance']}) => {"elapsed": 1800, "failed": true, "item": {"aliases":
> ["glance"], "forwarded_ports": [{"ext": 9292, "int": 9292}],
> "ipv4_last_octet": 30, "name": "glance-1"
> , "service": "glance"}, "msg": "Timeout when waiting for glance-1:9292"}
> failed: [10.100.198.201] (item={u'service': u'keystone',
> u'ipv4_last_octet': 40, u'name': u'keystone-1', u'forwarded_ports':
> [{u'int': 35357, u'ext': 35357}, {u'int': 49
> 90, u'ext': 4990}, {u'int': 5000, u'ext': 5000}], u'aliases':
> [u'keystone']}) => {"elapsed": 1800, "failed": true, "item": {"aliases":
> ["keystone"], "forwarded_ports": [
> {"ext": 35357, "int": 35357}, {"ext": 4990, "int": 4990}, {"ext": 5000,
> "int": 5000}], "ipv4_last_octet": 40, "name": "keystone-1", "service":
> "keystone"}, "msg": "Timeo
> ut when waiting for keystone-1:35357"}
> ok: [10.100.198.201] => (item={u'service': u'nagios', u'ipv4_last_octet':
> 60, u'name': u'nagios-1', u'forwarded_ports': [{u'int': 80, u'ext': 3128}],
> u'aliases': [u'nagi
> os']})
> failed: [10.100.198.201] (item={u'service': u'neutron-api',
> u'ipv4_last_octet': 70, u'name': u'neutron-api-1', u'forwarded_ports':
> [{u'int': 9696, u'ext': 9696}], u'alia
> ses': [u'neutron-api']}) => {"elapsed": 1800, "failed": true, "item":
> {"aliases": ["neutron-api"], "forwarded_ports": [{"ext": 9696, "int":
> 9696}], "ipv4_last_octet": 70
> , "name": "neutron-api-1", "service": "neutron-api"}, "msg": "Timeout
> when waiting for neutron-api-1:9696"}
> failed: [10.100.198.201] (item={u'service': 

Re: Charm release fails with "cannot update base entity for..."

[roger peppe]

On 3 January 2017 at 13:05, Merlijn Sebrechts
 wrote:
> I have the same issue in the staging charm store.
>
>
> charm release  cs:~tengu-team/jupyter-notebook-spark-0
> ERROR cannot release charm or bundle: cannot publish charm or bundle: cannot
> update base entity for "cs:~tengu-team/jupyter-notebook-spark-0": Field name
> duplication not allowed with modifiers
>
>
> Maybe this has something to do with it; the first time I pushed this charm I
> pushed to a wrong name (jupIter instead of jupYter):
>
> charm push jupyter-notebook-spark/ ~tengu-team/jupiter-notebook-spark
>
> Although I did it right the first time in the staging charm store, and it
> still doesn't work.
>
> Also, I'm user `merlijn-sebrechts` and I'm pushing to `tengu-team`. This has
> worked before.

I don't see any record of any operations on jupiter-notebook-spark on the
staging charmstore (I can see the accesses to jupyter-notebook-spark).

Are you sure you exported your JUJU_CHARMSTORE environment
variable correctly?

  cheers,
rog.

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using a bundle with manually added machines (redux)

[Mark Shuttleworth]

On 04/01/17 10:55, Stuart Bishop wrote:
>
>
> On 3 January 2017 at 19:07, Rick Harding  > wrote:
>
> I'm looking into this. The bundle deploy feature in Juju 2.0 does
> not allow referring to existing machines because it breaks the
> reusability of the bundle. 
>
>
> It would be great if Juju started supporting non-reusable bundles too.
> Its a waste having to support two similarly named tools that do almost
> the same thing. I'm not sure who is using 'juju deploy', but Amulet
> and Mojo both depend on 'juju deployer' for this reason. Which slows
> feature adoption, as juju-deployer doesn't seem to be owned by anyone
> and adding support for new features happens on an ad-hoc basis (my
> team is just now adding storage and resource support to it, needed for
> Mojo, so we can start using these features with actual deployments).

Amen :)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using a bundle with manually added machines (redux)

[Stuart Bishop]

On 3 January 2017 at 19:07, Rick Harding  wrote:

> I'm looking into this. The bundle deploy feature in Juju 2.0 does not
> allow referring to existing machines because it breaks the reusability of
> the bundle.
>

It would be great if Juju started supporting non-reusable bundles too. Its
a waste having to support two similarly named tools that do almost the same
thing. I'm not sure who is using 'juju deploy', but Amulet and Mojo both
depend on 'juju deployer' for this reason. Which slows feature adoption, as
juju-deployer doesn't seem to be owned by anyone and adding support for new
features happens on an ad-hoc basis (my team is just now adding storage and
resource support to it, needed for Mojo, so we can start using these
features with actual deployments).

-- 
Stuart Bishop 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju