[openstack-dev] [Solar] Weekly update

fixes Also, last Saturday I had a short presentation about Solar in Katowice. -- Warm regards Jedrzej Nowak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

[openstack-dev] [Solar] Weekly update

: - rework staging procedure to support both implicit and explicit stages - vbox/qemu packer build added - improvements for BAT transport - fix testing examples using fuel-devops - further packaging improvements -- Warm regards, Jedrzej Nowak

[openstack-dev] [Solar] Weekly update

and swarm tests - activities on packaging Solar itself: - various UX improvements - various bugs fixed - packaging improvements -- Warm regards, Jedrzej Nowak __ OpenStack Development Mailing List (not for usage questions

[openstack-dev] [Fuel][Solar] Integration in 9.0

As you may now we should integrate solar with fuel in 9.0. Integration in 9.0 will be very experimental and it will not affect fuel except: spec [](https:// review.openstack.org/283600)[https://review.openstack.org/283600](https://revi ew.openstack.org/283600) and

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

I definitely agree with what Evgeniy said. @Oleg could you make a step-by-step how do you imagine this integration (with separate ConfigDB) ? To me this adds at least one component / integration point. > The point is that for Solar integration, we still need integration points, > and the less

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

+1 for Lukasz concerns. But if we really need operate with "solar resources database" as a kv store, then we could implement service on top of it, It could be then separate project, which would work as separate service. Would it fulfill the requirements ? (we could implement it using some already

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

On Wed, Dec 16, 2015 at 12:40 PM, Bogdan Dobrelya wrote: > Data resources shall fill the configdb by results of the fetched data > shaped by data processors aka serializers. The shaping process assumes > applying of all versioning and schema transformations knowledge