Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Vladimir, Sorry for delayed response. Let's continue inline. On Thu, Oct 22, 2015 at 2:16 PM, Vladimir Kuklin wrote: > > >> >> Each task can use some code to transform this output to the >> representation that is actually needed for this particular task. Whenever a >>

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

> > Each task can use some code to transform this output to the > representation that is actually needed for this particular task. Whenever a > task transforms this data it can access API and do version negotiation, for > example. Each time this transformation is performed this task can return >

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hello, We discussed this proposal in our team and came up with the following vision of a configuration provisioning system: - Installer is a system of multiple components: hardware inventory, user interfaces, provisioning modules, deployment modules, checker modules, volume manager, network

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Oleg Thank you for your feedback. IMO, the schema you are providing is very complex and would surely benefit from some examples. If I understand correctly your proposal, you are trying to do the things that we actually want to get rid of - tight coupling and schema control of data that is being

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hi Oleg, I want to mention that we are using similar approach for deployment engine, the difference is that we are working not with components, but with deployment objects (it could be resources or tasks). Right now all the data should be provided by user, but we are going to add concept of

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hi Vladimir, Thanks for prompt reply. Please, see my comments inline. On Thu, Oct 22, 2015 at 12:44 PM, Vladimir Kuklin wrote: > Oleg > > Thank you for your feedback. IMO, the schema you are providing is very > complex and would surely benefit from some examples. > I'm

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hi, I have a comment regarding to when/where run translators. I think data processing (fetching + validation + translation) should be done as a separate stage, this way when we start deployment, we are sure that we have everything we need to perform deployment, but I understand that there might

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Folks Can we please stop using etherpad and move to some more usable thing as Google Docs? Etherpad seems too unusable for such discussion especially with this coloured formatting. Mike I currently see no need in following marketing trend for noSQL here - we need to store a set of structured

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Thanks Vladimir. This is very important work, I'd say. I'd split it into two parts: 1. Have some store where you'd dump data from serializers. Hiera should be able to read easily directly from this store. 2. Refactor serializers so to get rid of single python method which creates data

[openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hey, Fuelers TL;DR This email is about how to make * Intro I want to bring up one of the important topics on how to make Fuel more flexible. Some of you know that we have been discussing means of doing this internally and now it is time to share these thoughts with all of you. As you could know