Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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] [FFE] FF Exception request for Custom node attributes feature
Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
I apologize for my hasty email earlier. Thank you all who tried to help me but I have to revoke my additions to this feature. I completely missed the fact that labels may be changed after the deployment is done. It creates inconsistency between label values and actual values in astute.yaml on the nodes. It's bad UX and it may break a cluster in some circumstances. Merging my code we just add a new tech dept into Fuel and it's not we want to do. So, thank you again, and I'll come up later with a better proposal for 8.0. On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
+1 to merging the CLI part, if all our comments there are filed as High priority bugs and then fixed ASAP - romcheg 24 лип. 2015 о 07:58 Mike Scherbakov mscherba...@mirantis.com написав(ла): Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com mailto:ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com mailto:jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/ https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com mailto:mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com mailto:ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com mailto:jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
The fuelclient request was merged with all needed +1s. Known issues are filed to Launchpad: https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli So, we'll have a support of custom node labels both in Fuel UI and CLI in 7.0. Thank you guys all who contributed to the feature and helped with review and with everything else. Thanks Mike for granting the feature with an additional day to merge the latest patch. Will focus on the filed bugs for now. Regards, Julia On Fri, Jul 24, 2015 at 1:16 PM Andrey Danin ada...@mirantis.com wrote: I apologize for my hasty email earlier. Thank you all who tried to help me but I have to revoke my additions to this feature. I completely missed the fact that labels may be changed after the deployment is done. It creates inconsistency between label values and actual values in astute.yaml on the nodes. It's bad UX and it may break a cluster in some circumstances. Merging my code we just add a new tech dept into Fuel and it's not we want to do. So, thank you again, and I'll come up later with a better proposal for 8.0. On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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
[openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] *https://review.openstack.org/#/c/204524/ https://review.openstack.org/#/c/204524/* [2] https://review.openstack.org/#/c/201472/ __ 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] [FFE] FF Exception request for Custom node attributes feature
Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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 -- Mike Scherbakov #mihgen __ 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] [FFE] FF Exception request for Custom node attributes feature
-1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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 -- Mike Scherbakov #mihgen __ 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] [FFE] FF Exception request for Custom node attributes feature
Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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] [FFE] FF Exception request for Custom node attributes feature
+1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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
