Variable "topic" in valence.conf

[david9ml]

Does variable "topic" in valence.conf indicate the controller we choose in valence-controller service ?

[conductor]
#topic=rsc-conductor

So, if someone choose another controller let's say ibm, we should only change variable "topic" , right ? Like bellow :

[conductor]
#topic=ibm-conductor

[snivas]

Hi yanchao,
Currently, 'topic' in .conf file is not used and we implicitly consider that there is one topic.
The 'topic' represents rabbitmq topic exchange key..if there is another controller that could handle messages on that 'topic', yes we can use it.

[david9ml]

Hi @snivas ,
So, our next question is that can we contribute another controller like "topic=lenovo-conductor" in our current Valence framework ?

[snivas]

hi yanchao,
that may end up in duplication of work. I also need to discuss that with Ananth(@ananthnarayan).. we are in holiday now..Shall we discuss this by wednesday?

[david9ml]

hi, @snivas :
Ok， We're not sure, how Valence supports different kind of controllers(like intel, ibm, lenovo controllers) ?

[chesterkuo]

Should be one controller for all (that's why we define Valence as generic one) , put controller on top of PODM. as PODM is only one spec from intel/Redfish

[david9ml]

hi, @chesterkuo :
I think so too. But how do you support other kind of PODMs (like ibm, Dell, Lenovo) ?

[ananthnarayan]

@yanchao727,
To support a different controller, we'd have to add code within the 'controllers' module to handle OEM specific extensions.

[ramineni]

@ananthnarayan , Thanks.
Could you please update the architecture diagram mentioned in the wiki , where vendor specific drivers fit in, so that everyone gets a clear picture. Appreciate the help.

[david9ml]

Hi, @ananthnarayan :
So, there are two kinds of plugin outside of Valence：

1. openstack component plugin to Valence (like ironic-valence plugin, nova-valence plugin etc.)
2. Valence controller plugin (like ibm-valence-controller, dell-valence-controller etc.)
   Right ?

[ananthnarayan]

@ramineni Sure. I will do that. Please give me a couple of days.

[chesterkuo]

@yanchao727, the PODM need to passed with intel publich tool to make sure they are fully compliance , also in order to make sure interoperability , PODM NB will be generic and based on RF API, unless there is a feature not define in RF , nor PODM API , if so , this need to submit to RF/DMTF.
Add more OEM feature into API will put this under condition like BMC/IPMI OEM cmd, hard to maintain.