Re: [openstack-dev] [Neutron] Team meeting this Tuesday at 1400 UTC

[Armando M.]

On 1 February 2016 at 16:59, Carl Baldwin  wrote:

> I almost missed this because [Neutron] was missing from the subject.
> I'm replying now to add it in case someone else missed it.
>
>
Ah...so there are people who indeed read these emails!

Thanks for spotting this, I totally miss it, the jet lag must have caught
up with me.

Cheers,
Armando


> On Sat, Jan 30, 2016 at 2:27 PM, Armando M.  wrote:
> > Hi neutrinos,
> >
> > According to [1], this is a kind reminder for next week's meeting:
> please do
> > not get caught by the confusion.
> >
> > The Tuesday meetings will be hosted by Ihar, and I will be working with
> him
> > to discuss these meeting agendas [2] ahead of time. For this reason, stay
> > tuned for reminder updates coming from him too.
> >
> > I do not plan on attending, but I may occasionally join the irc meetings
> > when I travel to more friendly time zones. If you have something to
> discuss
> > with me (whilst I am in the PTL capacity), please do not rely on the
> Tuesday
> > meetings to reach out.
> >
> > In the meantime, let's thank Ihar for volunteering!
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/272494/
> > [2] https://wiki.openstack.org/wiki/Network/Meetings
> >
> >
> __
> > 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

Re: [openstack-dev] [oslo][all] Announcing our new Olso Project

[Davanum Srinivas]

yay Ronald :)

On Mon, Feb 1, 2016 at 11:50 AM, Ronald Bradford  
wrote:
> The Olso team is proud to announce the release of Oslo Bingo.  In Oslo
> we like to spice up our release notes using meaningful random
> adjectives [1].
>
> Each month the Oslo team will select an adjective to be the Oslo Bingo
> word of the month.
>
> For February 2016 we have selected "jazzed" (from rlrossit).
>
> To play, simply pick the first Oslo project that will have release
> notes using our Bingo word of the month (i.e. jazzed). Check out
> recent release notes that selected "overjoyed" [2] and "jubilant" [3]
> to see what we mean.
>
> Entry is free for all at http://j.mp/Oslo-bingo [4]
>
> The winner each month will get a limited edition Oslo t-shirt,
> sponsored by HPE (quantity and sizes limited):
> http://j.mp/Oslo-bingo-prize
>
> More details at [5]
>
>
> [1] 
> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py#n33
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085000.html
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083797.html
> [4] http://j.mp/Oslo-bingo
> [5] https://etherpad.openstack.org/p/Oslo_Bingo
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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-dev] [Fuel][QA] added fuel-devops branch 'release/2.9'

[Dennis Dmitriev]

Hi all,

New branch 'release/2.9' was added to the repository 'fuel-devops' last
week. This branch was created to keep supporting 2.9.x code while
fuel-devops 3.0.0 will be merged to the 'master' branch.

Please create all fixes for fuel-devops v2.9.x directly into
'release/2.9' branch instead of 'master' because of a big difference in
code between 2.9.x and 3.0.0

Also please join to review of fuel-devops 3.0.0 patches that implement
the flexible object scheme for store and manipulate with data from
fuel-devops YAML templates [1]:

https://review.openstack.org/274749 New Libvirt Driver Model
https://review.openstack.org/274750 New Network Models
https://review.openstack.org/274751 Volume model changes
https://review.openstack.org/274752 Node model changes
https://review.openstack.org/274753 New LibvirtXMLBuilder
https://review.openstack.org/274754 Group and Environment changes
https://review.openstack.org/274755 shell.py changes
https://review.openstack.org/274756 Migration for new model schema.
https://review.openstack.org/274757 Update unit tests Update verion to 3.0.0

These patches will be merged all at once after all of them pass review,
implementing the new functionality for 'master' branch.
Backward compatibility with fuel-devops 2.9.x should be preserved for
fuel-qa tests (for Fuel 6.1, 7.0, 8.0), but it is not tested yet.

[1]
https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst

-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: dis.x...@gmail.com


__
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] [Fuel UI] Node role list grouping

[Vitaly Kramskikh]

Folks,

That's true, Nailgun is still using Role entity - in DB, API, plugins can
provide new roles, etc., and it's not going away, at least in 9.0.

I'm fine with proposed set of role groups, except the "controller" group.
We don't have anything else but "controller" role in this group in the base
installation, but there are plugins that can detach some services from the
controller, like detach-database, detach-rabbitmq, etc. So these roles with
detached services should also be in the "controller" group, but it looks a
little illogical to me. So I'd prefer to go with something like "base" or
"core" group.

2016-01-29 16:53 GMT+03:00 Bogdan Dobrelya :

> On 29.01.2016 13:35, Vladimir Kuklin wrote:
> >> We removed role as abstraction from library. It's very very artificial
> >> abstraction. Instead we use tasks, grouping them to different
> >> combinations. That allows plugin developers to adjust reference
> >> architecture to their needs.
>
> I only replied to that. We did not remove role as abstraction
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> 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
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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] [puppet] Midcycle Sprint Summary

[Cody Herriges]

Emilien Macchi wrote:
> Last week, we had our midcycle sprint.
> Our group did a great job and here is a summary of what we worked on:
> 

My attention at the office was stolen quite a few times by finishing up
work for our production cloud deployment but I worked on the
pupept-cinder Mitaka deprecations when I could.  First round was done
which was the removal of old code previously deprecated and I have
started on a second pass which is new deprecations that are being
introduced in Mitaka by upstream cinder.

This is the fist time I've sat down to actually just hunt and implement
deprecations and the number one thing I learned is that it is really
time consuming.  We'll need several people working on this if we want
them complete for every module by release time.


-- 
Cody



signature.asc
Description: OpenPGP digital signature
__
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] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

This is basically why I proposed to allow users to set per cluster priority for 
every enabled plugin. That would allow users to select results they need. 
Putting too many logic into checks whether two plugins are incompatible is 
error-prone and won’t stop anyone from shooting their feet.


> 29 січ. 2016 р. о 16:10 Igor Kalnitsky  написав(ла):
> 
> Roman P. wrote:
>> Putting extra checks will create a more fool-proof but less configurable
>> software. I’d vote for letting users shoot their feet using their plugins
>> but making Fuel more flexible.
> 
> I won't agree here. You see, what if two plugins wants to override the
> core network role? Consider that plugin A wants to extend VIPs:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip:
>- name: "management"
>  namespace: "haproxy"
># new VIP we want to add
>- name: "myvip"
>  namespace: "haproxy"
> 
> while plugin B wants to remove them:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip: []
> 
> How do you suppose to resolve this action? We don't know in which
> order they will be resolved, and I'm strongly against unpredictable
> situation (especiall it may be different time-to-time and depends on
> which order plugins will be selected).
> 
> Moreover, it makes a little sense to try to resolve this situation. If
> two plugins change something in core, they are probably incompatible.
> Manual actions are required.
> 
> So that's, basically, why I think we should warn user about
> incompatible changes to core stuff. Just like we do for deployment
> tasks.
> 
> - igor
> 
> On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko  wrote:
>> I would not check that. We are not talking about installing browser plugins
>> when users may not know what they want. Putting extra checks will create a
>> more fool-proof but less configurable software. I’d vote for letting users
>> shoot their feet using their plugins but making Fuel more flexible.
>> 
>> 
>> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
>> написав(ла):
>> 
>>> jsonpatch
>> 
>> There were +1's regarding overriding VIPs above. I'd stick with that. It is
>> done for tasks now. But we will need to check conflicts between plugins
>> there (as for tasks).
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:
>>> 
>>> Frankly, I have not though about how to deal with multiple plugins yet.
>>> However, what I think is that we must not restrict this too much and let
>>> users configure it more flexibly even if it allows to shoot one’s foot.
>>> Perhaps we can add a per-cluster priority for enabled plugins which users
>>> can configure via UI, CLI or API. My other thought is that we should not
>>> invent our own mechanics for changing a configuration and use an existing
>>> one, say, jsonpatch. What do you guys think?
>>> 
>>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>>> please check it out. If it does not break anything, lets merge it ASAP.
>>> 
>>> - romcheg
>>> 
>>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
>>> написав(ла):
>>> 
>>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>>> what VIPs you are removing.
>>> Another option - remove "built-in" VIPs using some specific expression.
>>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>>> you cannot remove them this way.
>>> 
>>> And the order of plugins processing is not defined so there is no warranty
>>> you will remove all VIPs on those network roles.
>>> Seems, checking for such conflict between plugins is needed.
>>> 
>>> The original goal, actually, was to remove VIPs for controllers (or for
>>> some particular node role, maybe),
>>> so we should maybe find a way to do exactly this.
>>> 
>>> 
>>> 
>>> Aleksey Kasatkin
>>> 
>>> 
>>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
>>> wrote:
 
> How are we handling this now for multiple plugins?
 
 OK, so right now we can only add VIPs to array, we can't remove them. So
 overriding would disable such possibility of adding VIPs from different
 plugins. But with [0] patch it will be still possible to add and to remove
 by providing empty array. But we'll have the problem with multiple plugins
 in such case.
 I've changed my mind :) I vote for leaving as in [0] since it's less
 destructive comparing to what we have now.
 
 Regards,
 Alex
 
 [0] https://review.openstack.org/#/c/273169/1
 
 On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko
  wrote:
> 
> Well, with merging instead of overriding, I believe, this problem with
> multiple plugins still exists, right? How are we handling this now for
> multiple plugins?
> Since VIPs is 

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

[Thierry Carrez]

Fausto Marzi wrote:

[...]
That said, what we are trying to do, with Sam (that is showing an open
attitude and constructive approach), is to understand if the solution
make sense itself, if we can work together as a Team and if it make
sense to include it in Freezer. If not, it is crystal clear, that no one
in the world, can stop a very committed and capable person to do what
he/she wants to do. Even less in the Open Source and here. We probably
need to avoid fragmentation and at the same time no limiting new ideas,
but potentiate them.


It's also worth noting that Freezer is currently an official OpenStack 
project while Ekko is not, so there is no real overlap (yet).


If Ekko wants one day to become an official project, it would be great 
to clarify its positioning relative to Freezer before it applies, as I 
expect that will be the first question from the Technical Committee.


--
Thierry Carrez (ttx)

__
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