Open Stack

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 <eli at 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 <xarses at 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 <eli at 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
>>> <akasatkin at 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
>>>> <skalinowski at 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 <eli at 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
>>>>>> <ikalnitsky at 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 <eli at 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
>>>>>>> > <mscherbakov at 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
>>>>>>> >> <akasatkin at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>