Re: [openstack-dev] [Fuel][Plugins] add health check for plugins
it makes sense. We have two intersting use cases here: -to extend sanity test to validate plugins (see example in my previous email) -to extend OSTF test to add pre-deployment check. verify network tests are not enough to ensure that a deployment will be successfull or not. there are lot of other external parameters which can impact the deployment. VMWare credentials as mentionned by sheena is a good example but there is also check DNS, NTP, Netapp credentials , Netapp or NFS server ip is reachable, external Elasticsearch or Influxdb server is reachable (in case of using external servers for LMA) and so one. It would be very interesting to be able to add those tests for core components and plugins. it would help us to ensure user that if your tests are ok so no external elements would interfere with you deployment. it can be a verify settings test as the verify network one 2015-09-28 11:06 GMT+02:00 Sheena Gregson <sgreg...@mirantis.com>: > I just realized I missed this thread when Andrey responded to it – > apologies! > > > > I was thinking of things like – confirming VMware username and password > are accurate, confirming that SSL certificate chain is valid, etc. – some > of these are not plugin based, but I think there is value in enabling both > core components and plugins to specify tests that can be run prior to > deployment that will help ensure the deployment will not fail. > > > > Does that make sense? In this case, it is not confirming the deployment > was successful (post-deployment), it is checking known parameters for > validity prior to attempting to deploy (pre-deployment). > > > > *From:* Samuel Bartel [mailto:samuel.bartel@gmail.com] > *Sent:* Monday, September 28, 2015 11:13 AM > > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for > plugins > > > > Hi, > > Totally agree with you Andrey, > > other use cases could be : > > -for Ironic plugin, add test to validate that Ironic is properly deploy > > -for LMA plugin check that metric and log are properly collect, that elk, > nagios or grafana dashboard are accessible > > -for cinder netapp multi backend, check that different type of backend can > be crreated > > and so on > > So it would be very intersting to have enxtensibility ofr OSTF test > > > > > > Samuel > > > > 2015-09-08 0:05 GMT+02:00 Andrey Danin <ada...@mirantis.com>: > > Hi. > > Sorry for bringing this thread back from the grave but it look quite > interesting to me. > > Sheena, could you please explain how pre-deployment sanity checks should > look like? I don't get what it is. > > From the Health Check point of view plugins may be divided to two groups: > > > 1) A plugin that doesn't change an already covered functionality thus > doesn't require extra tests implemented. Such plugins may be Contrail and > almost all SDN plugins, Glance or Cinder backend plugins, and others which > don't bring any changes in OSt API or any extra OSt components. > > > 2) A plugin that adds new elements into OSt or changes API or a standard > behavior. Such plugins may be Contrail (because it actually adds Contrail > Controller which may be covered by Health Check too), Cisco ASR plugin > (because it always creates HA routers), some Swift plugins (we don't have > Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because > they require special network preparation and extra drivers to be presented > in an image), when a combination of different ML2 plugins or hypervisors > deployed (because you need to test all network underlayers or HVs). > > So, all that means we need to make OSTF extendible by Fuel plugin's tests > eventually. > > > > On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <sgreg...@mirantis.com> > wrote: > > I like that idea a lot – I also think there would be value in adding > pre-deployment sanity checks that could be called from the Health Check > screen prior to deployment. Thoughts? > > > > *From:* Simon Pasquier [mailto:spasqu...@mirantis.com] > *Sent:* Monday, August 10, 2015 9:00 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for > plugins > > > > Hello Samuel, > > This looks like an interesting idea. Do you have any concrete example to > illustrate your point (with one of your plugins maybe)? > > BR, > > Simon > > > > On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel < > samuel.bartel@gmail.com> wrote: > >
Re: [openstack-dev] [Fuel][Plugins] add health check for plugins
Hi, Totally agree with you Andrey, other use cases could be : -for Ironic plugin, add test to validate that Ironic is properly deploy -for LMA plugin check that metric and log are properly collect, that elk, nagios or grafana dashboard are accessible -for cinder netapp multi backend, check that different type of backend can be crreated and so on So it would be very intersting to have enxtensibility ofr OSTF test Samuel 2015-09-08 0:05 GMT+02:00 Andrey Danin <ada...@mirantis.com>: > Hi. > > Sorry for bringing this thread back from the grave but it look quite > interesting to me. > > Sheena, could you please explain how pre-deployment sanity checks should > look like? I don't get what it is. > > From the Health Check point of view plugins may be divided to two groups: > > 1) A plugin that doesn't change an already covered functionality thus > doesn't require extra tests implemented. Such plugins may be Contrail and > almost all SDN plugins, Glance or Cinder backend plugins, and others which > don't bring any changes in OSt API or any extra OSt components. > > 2) A plugin that adds new elements into OSt or changes API or a standard > behavior. Such plugins may be Contrail (because it actually adds Contrail > Controller which may be covered by Health Check too), Cisco ASR plugin > (because it always creates HA routers), some Swift plugins (we don't have > Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because > they require special network preparation and extra drivers to be presented > in an image), when a combination of different ML2 plugins or hypervisors > deployed (because you need to test all network underlayers or HVs). > > So, all that means we need to make OSTF extendible by Fuel plugin's tests > eventually. > > > On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <sgreg...@mirantis.com> > wrote: > >> I like that idea a lot – I also think there would be value in adding >> pre-deployment sanity checks that could be called from the Health Check >> screen prior to deployment. Thoughts? >> >> >> >> *From:* Simon Pasquier [mailto:spasqu...@mirantis.com] >> *Sent:* Monday, August 10, 2015 9:00 AM >> *To:* OpenStack Development Mailing List (not for usage questions) < >> openstack-dev@lists.openstack.org> >> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for >> plugins >> >> >> >> Hello Samuel, >> >> This looks like an interesting idea. Do you have any concrete example to >> illustrate your point (with one of your plugins maybe)? >> >> BR, >> >> Simon >> >> >> >> On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel < >> samuel.bartel@gmail.com> wrote: >> >> Hi all, >> >> >> >> actually with fuel plugins there are test for the plugins used by the >> CICD, but after a deployment it is not possible for the user to easily test >> if a plugin is crrectly deploy or not. >> >> I am wondering if it could be interesting to improve the fuel plugin >> framework in order to be able to define test for each plugin which would ba >> dded to the health Check. the user would be able to test the plugin when >> testing the deployment test. >> >> >> >> What do you think about that? >> >> >> >> >> >> Kind regards >> >> >> >> Samuel >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Andrey Danin > ada...@mirantis.com > skype: gcon.monolake > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugins] add health check for plugins
Hi all, actually with fuel plugins there are test for the plugins used by the CICD, but after a deployment it is not possible for the user to easily test if a plugin is crrectly deploy or not. I am wondering if it could be interesting to improve the fuel plugin framework in order to be able to define test for each plugin which would ba dded to the health Check. the user would be able to test the plugin when testing the deployment test. What do you think about that? Kind regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugins] additionnal categories for plugins
Hi all, I think we are missing a category for plugins. I was thinking to following plugins -TLS plugin related to security. For example everything related to tls access to the dashboard/vnc and apis -Plugin to deploy freezer with fuel in order to achieve abckup and restore (on going) -plugin to setup availaiblity zones (on going) The actual categories are : montiroing storage storage-cinder storage-glance network hypervisor these plugins are not matching to any of those categories. Shoul we let the category field empty as requested in fuel plugin documentation or can we consider to add additionnal categories? Regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available
Hi, First, thank you all for your contributions on that topic (I don't know what it has been split in two thread but let reply on this one) Igor : the problem I try to solve is the following, I would like to be able to : 1/decide on which compute node I want to deploy a plugin. for the example of nova-nfs, I would like to be able to keep lvm for ephemeral volume in some compute nodes and use the nova-nfs in others 2/be able to group compute nodes in order to apply a plugin with a different configuration for each group. My first use case here would be to be able to define and setup availability zone I totaly agree that filtrering on node name is not a good solution (possible typo or other human errors) What I understand/keep for the different contribution is that we have two very interesting specs: - https://review.openstack.org/#/c/185267/ for new role definition - https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst for label definition with these specs (maybe shipped in 7.0) this is how I think these use cases could be implemented 1/ with the new role definition, the plugin can define a new role nova-nfs and in task.yaml filtre on this new role. Then to apply a plugin in a given compute node user would have to check the nova-nfs checkbox in setttings tab and assign nova-nfs to the corresponding compute nodes 2/ with the label defitinion : the plugin can define new labels (corresponding to several availaibility zone. then user would have to activate the plugin by checking the box in the setttings tab and assign label. then the plugin with setup availability zone and assign compute nodes ccording to labels The problem is that these feature are not expected at least before 7.0. That's why I am looking for a solution usuable right now with 6.0 and 6.1. For the availability zone use case, we can, as suggested by Igor, introduce several fields for each availability zone and list uid of the node in each fields. Other solution would be to use the nodegroup feature to define 1 node group by desire availability zone For the nova-nfs, i can't figure out perfect solution. one can be to use a magic word, as mentioned by Andrey, in the name but we already seen it would lead to lot of potential errors. the other one derived from Igor idea for az would be tlo have a fiel with the list of uid of the nodes on which we want to apply the nova-nfs configuration regards Samuel 2015-06-26 7:12 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Samuel, Here's my 2 cents on this topic. First of all, I'd like to ask you - what problem do you try to solve? Please, answer on that first because it'll help me to come back with solution. Currently it looks like an error-prone approach to apply nova-nfs tasks only on roles with some label. Why? Because what if user forgot to attach them? Or he just made a typo here? It'd be better to introduce a special mixin-role (nova-nfs) where user explicitly assign it to those compute nodes he wants to use it. Regarding second issue, perhaps it would be useful affect deployment through labels.. but I'm not sure it'll be done in 7.0. What about plugin settings? You can introduce two fields: az1, az2, each is a list of node ids. You will be able to use this information during deployment, because afaik we serialize cluster attributes. Thanks, Igor On Wed, Jun 24, 2015 at 11:03 PM, Andriy Popovych apopov...@mirantis.com wrote: Samuel, As I know one node can have many roles. For 1/ You can specify custom nova-nfs role and assign it on compute nodes. Regards, Andriy On Wed, Jun 24, 2015 at 10:21 PM, Samuel Bartel samuel.bartel@gmail.com wrote: Andriy, May be 'role' was not the correct word here. For me role are compute, controller, base-os, cinder, mongo. I know that we can specify that a task A should be executed on some role (controller and compute for example) and a task B on some other roles (Cinder for example). To come back to my previous examples with the label feature presented by Irina : 1/ not apply nova-nfs plugin in all compute nodes we would assign a label on the nodes on which we want to setup the nfs backend storage for ephemeral volume. Then in the deploymodule we would be able to put a condition to setup it or not. Here the cleaner solution would be in th task.yaml to define a condition to execute the task for a given role AND a given label (here role would be equal to compute and label could be equal to nfs) 2/ a plugin to define availability zone: if I have 3 compute nodes, I would be able to assign az1 label to compute node 1 and 2 and label az2 to compute node 3. Then in the plugin deployment moduel I would be able to setup a az called az1 with compute nodes 1 and 2 and a az called az2 with compute node 3. It is not custom role as these nodes are compute. regards Samuel 2015-06-24 20:20 GMT+02:00 Andriy Popovych apopov
[openstack-dev] [Fuel][Plugins] differenciate node with the same role
Hi folks I am wondering if it is possible to differenciate nodes within a same role. Is it possible for example to apply aplugin to a compute node A but not a compute node B? It will be more clear with examples : 1) for the nfs plugin I want to use nfs storage backend for compute node A but LVM for compute node B 2) I was thinking of a plugin to define Availability zone and setup compute node A and B in AZ1 and compute node C in AZ2 I think it would possible to check according to specific value in the name of the node. But it doesn't seems to me to be very clean. And if we hav many plugins built in that way, name of the node would become very complicated soon and it is not very flexible. I was more looking a way to put a tag in the node (without needed to manually edit deployement yaml files) Anyone has already done something like this or has a tips on that topic? regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available
Irina, Thanks for the link. Unfortunatly it does not cover my use cases. What we would like to do is not define a new role. We would like to be able to apply plugin to some compute node for example and not in the others compute nodes or to be able to execute plugin with a given config on some compute nodes and with an other config on other compute nodes It is related to a capcity to tag/flag nodes and not adding new role regards Samuel 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya ipovolotsk...@mirantis.com: Samuel, Currently, there is a spec on introducing a new role through a plugin [1] - the feature is targeted at 7.0. Feel free to comment on it and ask questions right in the commit. [1] https://review.openstack.org/#/c/185267/ -- Best regards, Irina Partner Management Business Analyst skype: ira_live __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available
Julia, It is exactly what i was thinking. With such a mechanism we would be able to define custom labels to apply different type of task on compute nodes according to their labels. I add a comment on the review. As for now I don't see how we would be able to create custom label from plugin. In such a case we would have to make evolution on plugin engine part so we will have to identify exact impact on the plugin feature regards Samuel 2015-06-24 13:54 GMT+02:00 Julia Aranovich jkirnos...@mirantis.com: Samuel, I would like you to consider this proposal: https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst This is about support of custom node labels. I think plugins should be able to assign its own labels to nodes via Nailgun API. Is it possible? Will it suit your case? Thanks, Julia On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel samuel.bartel@gmail.com wrote: Irina, Thanks for the link. Unfortunatly it does not cover my use cases. What we would like to do is not define a new role. We would like to be able to apply plugin to some compute node for example and not in the others compute nodes or to be able to execute plugin with a given config on some compute nodes and with an other config on other compute nodes It is related to a capcity to tag/flag nodes and not adding new role regards Samuel 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya ipovolotsk...@mirantis.com : Samuel, Currently, there is a spec on introducing a new role through a plugin [1] - the feature is targeted at 7.0. Feel free to comment on it and ask questions right in the commit. [1] https://review.openstack.org/#/c/185267/ -- Best regards, Irina Partner Management Business Analyst skype: ira_live __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available
Andriy, May be 'role' was not the correct word here. For me role are compute, controller, base-os, cinder, mongo. I know that we can specify that a task A should be executed on some role (controller and compute for example) and a task B on some other roles (Cinder for example). To come back to my previous examples with the label feature presented by Irina : 1/ not apply nova-nfs plugin in all compute nodes we would assign a label on the nodes on which we want to setup the nfs backend storage for ephemeral volume. Then in the deploymodule we would be able to put a condition to setup it or not. Here the cleaner solution would be in th task.yaml to define a condition to execute the task for a given role AND a given label (here role would be equal to compute and label could be equal to nfs) 2/ a plugin to define availability zone: if I have 3 compute nodes, I would be able to assign az1 label to compute node 1 and 2 and label az2 to compute node 3. Then in the plugin deployment moduel I would be able to setup a az called az1 with compute nodes 1 and 2 and a az called az2 with compute node 3. It is not custom role as these nodes are compute. regards Samuel 2015-06-24 20:20 GMT+02:00 Andriy Popovych apopov...@mirantis.com: Samuel, AFAIK labels will not be related to tasks, it's just marks for filtering nodes. What roles means for you? we have tasks (A, B, C, D) and on some nodes tasks A B D should be executed, on some B C etc. So plugin can provide specials marks or tags or sets (we call it roles) and link tasks with it. In example before we can describe roles 'a' and 'b' to group 2 different sets of tasks ABD and BC. So A links with 'a', B with 'a' and 'b', C with 'b' and D with 'a'). Both roles 'a' and 'b' can be implemented in context of ONE plugin. Actually I can't understand why you want another mark(or tag) for tasks if we already have it and it's called role. Thanks, Andriy On Wed, Jun 24, 2015 at 6:45 PM, Samuel Bartel samuel.bartel@gmail.com wrote: Julia, It is exactly what i was thinking. With such a mechanism we would be able to define custom labels to apply different type of task on compute nodes according to their labels. I add a comment on the review. As for now I don't see how we would be able to create custom label from plugin. In such a case we would have to make evolution on plugin engine part so we will have to identify exact impact on the plugin feature regards Samuel 2015-06-24 13:54 GMT+02:00 Julia Aranovich jkirnos...@mirantis.com: Samuel, I would like you to consider this proposal: https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst This is about support of custom node labels. I think plugins should be able to assign its own labels to nodes via Nailgun API. Is it possible? Will it suit your case? Thanks, Julia On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel samuel.bartel@gmail.com wrote: Irina, Thanks for the link. Unfortunatly it does not cover my use cases. What we would like to do is not define a new role. We would like to be able to apply plugin to some compute node for example and not in the others compute nodes or to be able to execute plugin with a given config on some compute nodes and with an other config on other compute nodes It is related to a capcity to tag/flag nodes and not adding new role regards Samuel 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya ipovolotsk...@mirantis.com: Samuel, Currently, there is a spec on introducing a new role through a plugin [1] - the feature is targeted at 7.0. Feel free to comment on it and ask questions right in the commit. [1] https://review.openstack.org/#/c/185267/ -- Best regards, Irina Partner Management Business Analyst skype: ira_live __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] vxlan support
Hi Sean, I understand and share you point of view. The best and cleaner solution would be to have the vxlan support out of the box. Unfortunatly it is not the case for 6.0 and I doubt this feature can be available before HCF for 6.1 (planned in the next upcoming days). That's why in my initial message I asked if help is needed to ship this feature in 7.0 Having a vxlan plugin is a workaround, an ugly one, but the only workaround which make the job in 6.0 and 6.1. My actual vxlan plugin modify ml2 neutron plugin configuration in order to switch segmentation type to vxlan and restart neutron services or neurton crm ressources. The only issue, I have for the moment is to recreate net04 network and corresponding subnet as you can't redefine an already defined resource in puppet. About the fact to choose GRE and having vxlan. it will be the same with contrail, nuage cinder netapp, nfs nova nfs glance plugins for example. In the create env form you choose a configuration. But you can choose in settings tab by activating a particular plugin to override initial network or storage configuration. In every case, It will be done on purpose. -- Regards, Samuel Bartel, IRC #samuelbartel 2015-05-28 21:42 GMT+02:00 Sean M. Collins s...@coreitpro.com: On May 28, 2015 2:51:56 PM EDT, Andrey Danin ada...@mirantis.com wrote: Hi, Sean, A plugin cannot modify Fuel UI but it actually can change a segmentation type after deployment. On UI it's still GRE but in fact it will be VxLAN. I know, it's ugly, but should work. On Thu, May 28, 2015 at 7:47 PM, Sean M. Collins s...@coreitpro.com wrote: VxLAN support cannot be made as a plugin because plugins cannot modify the initial networking wizard (based on conversations I've had in #fuel-dev) where the choices between Neutron VLAN, Neutron GRE, and nova-network are shown to the user. I am currently working on this blueprint and have a WIP patch for fuel-web. Please contact me if you want to help contribute to the work. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I don't think that's a good way to go about it, we'd be giving someone a surprise if they actually wanted to deploy GRE only to discover it deployed VXLAN. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] [Plugins] type available
Hi folks, is there anyway in the environment_config.yaml file of the plugin to define some attrobutes as title (something similar to the the metadata in the openstack.yaml of fuel-web). I would like to add somes titles in the plugin config in order to define section into the ui for the plugin and make it easier to read. something like section1 param1: value description param2: value descritpion section3 param3: value description param4: value descritpion I have tried different types and iI ahve got alway errors by fpb when trying to build the plugin in the meantime, I haven't been able to find out the information into validator used by the fpb any tips? Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] [Plugins] modification disk configuration
Hi folks In some plugin such as the nfs for glance or nova and the netapp for cinder, we have replaced the lvm by nfs mount point. However we still have partition setup for glance, cinder, nova which are not used anymore. we can still int the disk configure allocate the minimum space to these partitions. but is it possible in the plugin to chache the disk configuration in order to reallocate thiese partition to a different used? regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] vxlan support
Hi folks, I have a question about implementation of vxlan for neutron. there is a blueprint on that topic in launchpad from 2014/03/21: https://blueprints.launchpad.net/fuel/+spec/neutron-vxlan-support several fixes have been pushed but all of them have been abandonned or refused. Is there any technical reason to not having vxlan support on fuel or is it just not a priority for product manager? In fuel 5.0 and 5.1 we customize fuel in order to have this segmentation type. starting from fuel 6.0, I have made a plugin for vxlan but not totally satisfied by that way to process. It will be cleaner to having vlxan directly ship into fuel core. So if there is no technical issue and if it not already shiped into the advanced network topic, I can work on a fix to add this feature in fuel 7.0 regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI
Vitaly, Simon, thanks for your answers. In fact for the cinder multi backend use case, it is more complicated and closer from simon's case. For each filer, we have several parameters (hostname/ip, username, password, volume, storage protocoleand so on). So I thing that we are going to use Simon's approach a little bit modified : having a pick list corresponding to the number of filers to declare and then display the corresponding number of group of fields and hide the others. But for sure JS part for plugin would be a great improvement for developping complex plugins. 2015-05-07 18:41 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com: Samuel, There are plans to solve this: 1) Add a flag/field to control declaration so it can have multiple values: ntp_list: *multiple_values: true* value: - 1.1.1.1 - 2.2.2.2 label: NTP server list description: List of upstream NTP servers type: text Now we use one input with comma-separated values to enter DNS and NTP servers which is hacky. This proposal with also solve your issue, but won't help for Simon's case (as there are groups of 2 fields). 2) For complex controls we plan to implement support for JS parts of plugins https://blueprints.launchpad.net/fuel/+spec/ui-plugins, so you can implement configuration UI of any complexity by providing custom JS. repo_setup control in 6.1 is a great example of a complex control. For 6.1 I suggest you to use current DNS/NTP approach (comma separated values) or Simon's approach (though I'd use action: hide instead of action: disable) 2015-05-07 17:36 GMT+03:00 Simon Pasquier spasqu...@mirantis.com: Hello Samuel, As far as I know, this isn't possible unfortunately. For our own needs, we ended up adding a fixed-size list with all items but the first one disabled. When you enter something in the first input box, it enabled the second box and so on (see [1]). In any case, this would be a good addition... BR, Simon [1] https://github.com/stackforge/fuel-plugin-elasticsearch-kibana/blob/master/environment_config.yaml#L21 On Thu, May 7, 2015 at 3:37 PM, Samuel Bartel samuel.bartel@gmail.com wrote: Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp (to add multibackend feature) In this two plugins I face the same problem. Is it possible in the environment yaml config describing the fields to display for the plugin in the UI to have some dynamic element. I explain my need. I would like to be able to add additional element by clicking on a “+” button as the IP range for network tab in order to be able to: -add new log file to manage for the logrorate instead of having a static list -add extra netapp filer/volume instead ofbeing able to setup only one for the cinder netapp in a multibackend scope. For the cinder netapp for example, I would be able to access to the netapp server hostname with: $::fuel_settings[‘cinder_netapp’][0][‘netapp_server_hostname’] #for the first one $::fuel_settings[‘cinder_netapp’][1][‘netapp_server_hostname’] #for the second one And so on. Can we do that with the actual plugin feature. If not is it planned to add such a feature? Regards, Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI
Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp (to add multibackend feature) In this two plugins I face the same problem. Is it possible in the environment yaml config describing the fields to display for the plugin in the UI to have some dynamic element. I explain my need. I would like to be able to add additional element by clicking on a “+” button as the IP range for network tab in order to be able to: -add new log file to manage for the logrorate instead of having a static list -add extra netapp filer/volume instead ofbeing able to setup only one for the cinder netapp in a multibackend scope. For the cinder netapp for example, I would be able to access to the netapp server hostname with: $::fuel_settings[‘cinder_netapp’][0][‘netapp_server_hostname’] #for the first one $::fuel_settings[‘cinder_netapp’][1][‘netapp_server_hostname’] #for the second one And so on. Can we do that with the actual plugin feature. If not is it planned to add such a feature? Regards, Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
