Evgeniy, > 3. Change tokens in template language
I'm not sure what do you mean here. Could you please clarify? Perhaps I missed something. Thanks, Igor On Mon, Jul 27, 2015 at 11:53 AM, Evgeniy L <e...@mirantis.com> wrote: > So, to summarise, +1 from me, we accept the changes which are required > for the feature as feature freeze exceptions: > > 1. Fuel client changes [1] > 2. Validation [2] > 3. Change tokens in template language > > Sebastian, Igor, correct? > > [1] https://review.openstack.org/#/c/204321/ > [2] https://bugs.launchpad.net/fuel/+bug/1476779 > > On Sat, Jul 25, 2015 at 1:25 AM, Andrew Woodward <xar...@gmail.com> wrote: >> >> Igor, >> >> https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the FFE >> if you think it's a feature. Networking is the most complicated and >> frustrating thing the user can work with. If we cant provide usable feedback >> from bad data in the template then the feature is useless. I could argue >> that its a critical UX defect. >> >> >> On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L <e...@mirantis.com> wrote: >>> >>> Aleksey, >>> >>> Yes, my point is those parts should be also included in the scope of FFE. >>> Regarding to template format, it's easy to fix and after release you will >>> not >>> be able to change it, or you can change it, but you will have to support >>> both >>> format, not to brake backward compatibility. So I would prefer to see it >>> fixed >>> in 7.0. >>> >>> Thanks, >>> >>> On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin >>> <akasat...@mirantis.com> wrote: >>>> >>>> I agree, guys, we need at least some basic validation for template when >>>> it is being loaded. >>>> Ivan Kliuk started to work on this task. >>>> And we agreed to test other types of delimiters (it is regarding ERB >>>> style template) but we have some more important issues. >>>> Evgeniy, is your meaning to include those to FFE ? >>>> >>>> >>>> Aleksey Kasatkin >>>> >>>> >>>> On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski >>>> <skalinow...@mirantis.com> wrote: >>>>> >>>>> I agree here with Evgeniy. Even if it's not a trivial change, we cannot >>>>> leave a new API in such shape. >>>>> >>>>> 2015-07-24 11:41 GMT+02:00 Evgeniy L <e...@mirantis.com>: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> I don't agree with you, some basic validation is essential part of >>>>>> any handler and our API, currently it's easy to get meaningless 500 >>>>>> error >>>>>> (which is unhandled exception) from the backend or get the error that >>>>>> there >>>>>> is something wrong with the template only after you press deploy >>>>>> button. >>>>>> It's a bad UX and contradicts to our attempts to develop good api. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky >>>>>> <ikalnit...@mirantis.com> wrote: >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> The issue [1] looks like a feature to me. I'd move it to next >>>>>>> release. >>>>>>> Let's focus on what's important right now - stability. >>>>>>> >>>>>>> Thanks, >>>>>>> Igor >>>>>>> >>>>>>> [1]: https://bugs.launchpad.net/fuel/+bug/1476779 >>>>>>> >>>>>>> On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L <e...@mirantis.com> wrote: >>>>>>> > Hi, >>>>>>> > >>>>>>> > Since the feature is essential, and changes are small, we can >>>>>>> > accept it as >>>>>>> > a, >>>>>>> > feature freeze exceptions. >>>>>>> > >>>>>>> > But as far as I know there is a very important ticket [1] which was >>>>>>> > created >>>>>>> > in >>>>>>> > order to get patches merged faster, also I still have concerns >>>>>>> > regarding to >>>>>>> > ERB style template "<% if3 %>" which is in fact Jinja. So it's not >>>>>>> > only >>>>>>> > about >>>>>>> > fixes in the client. >>>>>>> > >>>>>>> > [1] https://bugs.launchpad.net/fuel/+bug/1476779 >>>>>>> > >>>>>>> > On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov >>>>>>> > <mscherba...@mirantis.com> >>>>>>> > wrote: >>>>>>> >> >>>>>>> >> Looks like the only CLI part left: >>>>>>> >> https://review.openstack.org/#/c/204321/, and you guys did a great >>>>>>> >> job >>>>>>> >> finishing the other two. >>>>>>> >> >>>>>>> >> Looks like we'd need to give FF exception, as this is essential >>>>>>> >> feature. >>>>>>> >> It's glad that we merged all other thousands lines of code. This >>>>>>> >> is the most >>>>>>> >> complex feature, and seems like the only small thing is left. >>>>>>> >> >>>>>>> >> I'd like to hear feedback from Nailgun cores & fuel client SMEs. >>>>>>> >> For me, >>>>>>> >> it seems it is lower risk, and patch is relatively small. How long >>>>>>> >> would it >>>>>>> >> take to complete it? If it takes a couple of days, then it is >>>>>>> >> fine. If it is >>>>>>> >> going to take week or two, then we will have to have it as a risk >>>>>>> >> for HCF >>>>>>> >> deadline. Spending resources on features now, not on bugs, means >>>>>>> >> less >>>>>>> >> quality or slip of the release. >>>>>>> >> >>>>>>> >> On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin >>>>>>> >> <akasat...@mirantis.com> >>>>>>> >> wrote: >>>>>>> >>> >>>>>>> >>> Team, >>>>>>> >>> >>>>>>> >>> I would like to request an exception from the Feature Freeze for >>>>>>> >>> "Templates for Networking" feature [1]. >>>>>>> >>> >>>>>>> >>> Exception is required for two CRs to python-fuelclient: [2],[3] >>>>>>> >>> and one >>>>>>> >>> CR to fuel-web (Nailgun): [4]. >>>>>>> >>> These CRs are for adding ability to create/remove networks via >>>>>>> >>> API [4] >>>>>>> >>> and for supporting new API functionality via CLI. >>>>>>> >>> These patchsets are for adding new templates-related >>>>>>> >>> functionality and >>>>>>> >>> they do not change existing functionality. >>>>>>> >>> Patchsets [3],[4] are in deep review and they will hopefully be >>>>>>> >>> merged on >>>>>>> >>> Thursday. >>>>>>> >>> >>>>>>> >>> Please, respond if you have any questions or concerns related to >>>>>>> >>> this >>>>>>> >>> request. >>>>>>> >>> >>>>>>> >>> Thanks in advance. >>>>>>> >>> >>>>>>> >>> [1] >>>>>>> >>> https://blueprints.launchpad.net/fuel/+spec/templates-for-networking >>>>>>> >>> [2] https://review.openstack.org/#/c/204321/ >>>>>>> >>> [3] https://review.openstack.org/#/c/203602/ >>>>>>> >>> [4] https://review.openstack.org/#/c/201217/ >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> Best regards, >>>>>>> >>> Aleksey Kasatkin >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> __________________________________________________________________________ >>>>>>> >>> 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 >>>>>>> > >>>>>>> >>>>>>> >>>>>>> __________________________________________________________________________ >>>>>>> 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 >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> >> __________________________________________________________________________ >> 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
