Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 14 2016 13:06
    andreaturli unlabeled #311
  • Jul 14 2016 13:06

    rosogon on master

    Updating deployer and brooklyn-… Merge pull request #311 from ki… (compare)

  • Jul 14 2016 13:06
    rosogon closed #311
  • Jul 14 2016 13:06
    rosogon commented #311
  • Jul 14 2016 10:15
    kiuby88 commented #311
  • Jul 14 2016 08:50
    codecov-io commented #311
  • Jul 14 2016 08:42
    codecov-io commented #311
  • Jul 14 2016 08:42
    kiuby88 synchronize #311
  • Jul 13 2016 16:22

    rosogon on 1.1.0-beta

    (compare)

  • Jul 13 2016 11:24
    rosogon commented #311
  • Jul 13 2016 11:19
    kiuby88 synchronize #311
  • Jul 13 2016 10:15
    codecov-io commented #311
  • Jul 13 2016 10:08
    kiuby88 commented #311
  • Jul 13 2016 10:08
    andreaturli labeled #311
  • Jul 13 2016 10:08
    kiuby88 opened #311
  • Jul 11 2016 16:41
    IvanFebles commented #310
  • Jul 10 2016 18:09
    fradandria labeled #310
  • Jul 10 2016 18:09
    fradandria assigned #310
  • Jul 10 2016 18:09
    fradandria opened #310
  • Jun 29 2016 15:22
    andreaturli unlabeled #309
Jose
@kiuby88
Sorry guys, I was in a long meeting this morning. I just finished and I went to the integration telco. @PaoloCifariello I think that the Discoverer has a wrong configuration. You changed the name of the CloudFoundry to cloud foundry-instance inside of Discoverer’s files but the Planner’s configuration file was not updated in the master, take a look here. The Planner README.md has to be updated too.
perezp
@perezp
@kiuby88 I'm looking at the offerings file. I suppose that it is required to change the current information
location: CloudFoundry
to
location: foundry-instance
in every cloud foundry instance?
Or that part is not required?
This is just to see if it will be possible to include all the necessary changes for this issue at once.
Jose
@kiuby88
@rosogon has just mentioned this issue
perezp
@perezp
ok
:D
Jose
@kiuby88
take a look to this line
at the one of the line CloudFoundry has to be modified to cloud foundry-instance
perezp
@perezp
I had seen that line, but changing only this line will not make anything work.
Jose
@kiuby88
Sure
perezp
@perezp
ok :)
Sorry that I had not heard it :S
perezp
@perezp
I'm opening an issue with this, to point to this during the discussion.
Jose
@kiuby88
it is a Planner issue. @andreaturli and @rosogon were talking about another Discoverer issue (empty list returned)
Román SG
@rosogon
@andreaturli: There are some fields in the planner conf.yml unset:
influxdbURL: undefined
grafanaEndpoint: 127.0.0.1   # missing port
monitorGeneratorURL: undefined
monitorGeneratorPort: undefined
@PaoloCifariello : Planner README should also be updated with these
Andrea Turli
@andreaturli
monitorGenerator is not needed, @MicheleGuerriero said that planner doesn’t use it as a service
influxdb and grafana I don’t know, the doc is not clear
Román SG
@rosogon
You are right about monitorgenerator.
Probably MonitorGeneratorURL var in the conf was reused to point to T4C manager.
I ask @PaoloCifariello and @kiuby88 to look at this.
Jose
@kiuby88
let me check it
Jose
@kiuby88
Yes, as Roman said monitorGeneratorURL and monitorGeneratorPort are T4C endpoint data. Currently MontorGenerator is required by MontoringDamGenerator interface, but probably it should be renamed probably something like monitorEndpointor t4cEndPoint. In any case, T4C endpoint information has to be added to the catalog. Because, rules and Datacollectors requires T4C endpoint. I can help on this. I can change the name of the Planner config and updating the DamGenerator configuration using the new configuration key names and I can test it
I will update #288 ASAP using artifacts from maven central
Andrea Turli
@andreaturli
@rosogon I’ve fixed the mongoimport thing
can you please try the new catalog.bom when you have time? thanks
Andrea Turli
@andreaturli
Screen Shot 2016-04-15 at 10.00.32 AM.png
@/all with the workaround for mongodb, step 3. passed, but step 4. doesn’t look good. I can see on the console.out of the planner the following
ERROR [2016-04-15 08:00:20,489] eu.seaclouds.platform.planner.core.application.ApplicationFacade: TargetType definition tosca.nodes.Computewas not foundso it will not added to DAM
INFO  [2016-04-15 08:00:20,492] eu.seaclouds.monitor.monitoringdamgenerator.MonitoringDamGenerator: Request received.
INFO  [2016-04-15 08:00:20,497] eu.seaclouds.monitor.monitoringdamgenerator.adpparsing.YAMLMonitorParser: Parsing the Abstract Deployment Model.
INFO  [2016-04-15 08:00:20,501] eu.seaclouds.monitor.monitoringdamgenerator.MonitoringDamGenerator: Generating monitoring information for host SoftLayer_Cloud_Servers_1core_2gb_AMS
INFO  [2016-04-15 08:00:20,501] eu.seaclouds.monitor.monitoringdamgenerator.rulesgenerators.InfrastructuralRulesGenerator: Generating infrastructural level monitoring rules for host: SoftLayer_Cloud_Servers_1core_2gb_AMS
ERROR [2016-04-15 08:00:20,512] io.dropwizard.jersey.errors.LoggingExceptionMapper: Error handling a request: dddf419b68b41ddd
! java.lang.NullPointerException: null
! at eu.seaclouds.monitor.monitoringdamgenerator.MonitoringDamGenerator.generateMonitoringInfo(MonitoringDamGenerator.java:91) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.application.decorators.MonitoringInformationDecorator.generateMonitoringInfo(MonitoringInformationDecorator.java:53) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.application.decorators.MonitoringInformationDecorator.apply(MonitoringInformationDecorator.java:46) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.application.ApplicationFacadeDecoratorApplicator.applyDecorators(ApplicationFacadeDecoratorApplicator.java:14) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.application.ApplicationFacade.applyDecorators(ApplicationFacade.java:140) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.application.ApplicationFacade.generateDam(ApplicationFacade.java:111) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.core.DamGenerator.generateDam(DamGenerator.java:71) ~[planner-service.jar:na]
! at eu.seaclouds.platform.planner.service.DamGenResource.damGenPost(DamGenResource.java:100) ~[planner-service.jar:na]
! at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_95]
! at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_95]
! at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_95]
! at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_95]
! at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) ~[planner-service.jar:na]
! at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309) ~[planner-service.jar:na]
! at org.glassfish.jersey.internal.Errors$1.call(Errors.jav
Jose
@kiuby88
A DamGenerator issue
I agree with @rosogon
Andrea Turli
@andreaturli
where should it be set?
Jose
@kiuby88
from the catalog, I think
Andrea Turli
@andreaturli
ok sure, which component requires that URL?
the planner?
Jose
@kiuby88
MonitorManagerUrl is called from the planner.conf as monitorGeneratorURL
yes
the planner
Andrea Turli
@andreaturli
ok what’s the URL then?
Jose
@kiuby88
give me one minute
Román SG
@rosogon
It's the url of tower4clouds manager
Andrea Turli
@andreaturli
ok thanks @rosogon I’ll update the bom
Andrea Turli
@andreaturli
give me 1 minute
Jose
@kiuby88
monitorGeneratorURL: t4c host
monitorGeneratorPort: t4c port
Andrea Turli
@andreaturli
the host should be the IP or http://IP ?
Jose
@kiuby88
I think so
give me 2 minutes