Re: [openstack-dev] [telemetry] [vitrage] Mascot

[Ildikó Váncsa]

Thanks for the heads up. I checked briefly for logos on Google just to see 
what's around when I had the idea, but it seems I should've done a deeper/wider 
search... :) :(

Cheers,
Ildikó

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: July 25, 2016 14:30
> To: Afek, Ifat (Nokia - IL)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [telemetry] [vitrage] Mascot
> 
> On Mon, Jul 25 2016, Afek, Ifat (Nokia - IL) wrote:
> 
> > A week ago I published Vitrage mascot alternatives[1] and notified
> > Heidi Joy Tretheway. One of our options was Suricata, which is another
> > name for a Meerkat. We have yet to conduct the official vote, but from
> > what I can tell this is quite a popular option (#2 at the moment).
> >
> > Seems like we have a Meerkat problem... :-)
> 
> Haha, you're right. There's even an open source named Suricata:
>  https://suricata-ids.org/
> 
> We'll probably need to pick something else. There seems to be some kind of 
> pun possible with Vitrage did you explore that btw?
> 
> --
> Julien Danjou
> // Free Software hacker
> // https://julien.danjou.info

__
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] [cinder][nova] Cancellation of this week's Cinder-Nova meeting

[Ildikó Váncsa]

Hi,

As we had a session about the Cinder-Nova API changes in progress last week 
during the mid-cycles of these two modules we cancel the today's meeting.

You can find meeting logs on this etherpad starting from line 50: 
https://etherpad.openstack.org/p/nova-newton-midcycle

Best Regards,
/Ildikó

__
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] [telemetry] Mascot

[Ildikó Váncsa]

I had the Meerkat [1] in mind as Telemetry has a "family" of services and 
meerkat lives in bigger groups too and a few of them stand sentry and listen to 
any event or danger, etc. and "send alarms" to the others.

From the previous options I like Fennec too.

/Ildiko

[1] https://en.wikipedia.org/wiki/Meerkat 

> -Original Message-
> From: Chris Dent [mailto:cdent...@anticdent.org]
> Sent: July 21, 2016 19:47
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [telemetry] Mascot
> 
> On Thu, 21 Jul 2016, gordon chung wrote:
> > On 21/07/2016 11:36 AM, Doug Hellmann wrote:
> >> Something with big ears that are good for listening. A fennec [1]? A
> >> serval [2]?
> >>
> >> Doug
> >>
> >> [1] https://en.wikipedia.org/wiki/Fennec_fox
> >> [2] https://en.wikipedia.org/wiki/Serval
> >
> > i really like these suggestions, with a preference for the fennec. the
> > big ears idea was great.
> 
> +1 on the fennec
> 
> --
> Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
> freenode: cdent tw: @anticdent
__
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] [cinder][nova] Today's Cinder-Nova API changes meeting is cancelled

[Ildikó Váncsa]

Hi,

The today's meeting is cancelled due to the holiday in the U.S. The next 
meeting will be held next Monday (July 11th), 1700 UTC on #openstack-meeting-cp.

Thanks and Best Regards,
/Ildikó

__
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] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi Andreas,

Thanks for the clarification on this. We will consider the options.

Best Regards,
Ildikó

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: June 28, 2016 20:44
> To: Ildikó Váncsa; openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)
> 
> On 06/28/2016 08:23 PM, Ildikó Váncsa wrote:
> > Hi Andreas,
> >
> > If we would end up moving more guides to the project tree then it will be 
> > confusing having multiple top level docs folder in a
> basically code repository.
> >
> > Can that be an option to have a top level 'doc' folder and having 
> > sub-folders under like 'doc/developer', 'doc/install-guide', etc.?
> 
> We want the same infra-jobs for all these books and no special rules for
> one of them. Renaming doc/source to doc/developer for a large part of
> our 1100+ repos is a large undertaking...
> 
> Btw. nothing stops the telemetry team to have a special "telemetry-docs"
> repository that includes some of these guides,
> 
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi Rodrigo,

Thanks for sharing your view on this. I will consider what other way I have to 
organize the docs.

I tried to extract the common parts and use '.. include::' as much as possible. 
The patch was huge already. I'm afraid what you're saying would result in even 
more duplication which is not ideal. I also like having less sections the user 
has to check and put together as that makes it easier to follow the flow.

Best Regards,
/Ildikó

> -Original Message-
> From: Caballero Abraham, Rodrigo [mailto:rodrigo.caballero.abra...@intel.com]
> Sent: June 28, 2016 18:46
> To: Ildikó Váncsa; 'Spyros Trigazis'; OpenStack Development Mailing List (not 
> for usage questions); openstack-
> d...@lists.openstack.org
> Subject: RE: [OpenStack-docs] [openstack-dev] [telemetry] Ceilometer and Aodh 
> install guide(s)
> 
> snip
> >
> > Do you have a good proposal for structuring things?
> []
> I am assuming that you have distro specific instructions mixed with 
> non-specific ones.
> I can only suggest what has worked for me in the past. I created a common 
> file describing the process devoid of any instructions,
> distro specific or otherwise.
> Then I created distro specific procedures containing all the needed 
> instructions with the appropriate level of detail.
> The steps on the common file serve as the headings for all distro specific 
> procedures. That makes the common file an excellent
> introduction to all procedures while keeping the entire instructions in a 
> single place.
> 
> This system is not perfect however. There is some content repetition on the 
> instructions side of things.
> This could be avoided if we used the .. only:: directive on the instructions 
> side. You would then have a high level overview of the
> procedure, common to all distros, and a single file containing all 
> instructions for all distros differentiated by the only directive.
> 
> I guess what I am saying is that there is no magic bullet here. At the end of 
> the day, the content determines what modularity model
> you can use, IMO.
> Regards,
> Rodrigo
> >
> > Thanks,
> > /Ildikó
> snip
__
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] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi Andreas,

If we would end up moving more guides to the project tree then it will be 
confusing having multiple top level docs folder in a basically code repository.

Can that be an option to have a top level 'doc' folder and having sub-folders 
under like 'doc/developer', 'doc/install-guide', etc.?

Thanks and Best Regards,
/Ildikó

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: June 28, 2016 15:12
> To: Ildikó Váncsa; openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)
> 
> On 2016-06-28 14:55, Ildikó Váncsa wrote:
> > [...]
> > I have a third less urgent question. The install-guide has it's own folder 
> > at the same level where these two projects have their 'doc'
> folder. I would assume other projects have the same or similar folder for the 
> developer docs. Would that be reasonable/possible to
> have one main 'doc' folder for all the docs?
> 
> I understand the sentiment. The install-guide is a separate book, as
> Sean Dague called it nicely, which gets published to a different place,
> integrated into the full Install Tutorial. If you make it part of the
> developer documentation, it might integrate more nicely there but not in
> the overall cross-project Install Tutorial. Developer documentation is a
> separate book already and placing several books under doc will need even
> further changes to make it clear what goes where and how to publish.
> 
> So, I think the top-level folder is the best place for this,
> 
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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] [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi Goutham,

Thanks, I already checked your solution briefly.

I will wait until there is some decision about the global way forward. If '.. 
only::' remains an option I might change the Ceilometer setup back.

Best Regards,
/Ildikó

> -Original Message-
> From: Ravi, Goutham [mailto:goutham.r...@netapp.com]
> Sent: June 28, 2016 15:32
> To: Ildikó Váncsa; openstack-d...@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [OpenStack-docs] [telemetry] Ceilometer and Aodh install guide(s)
> 
> Hi Ildikó,
> 
> Please take a look at the tooling in https://review.openstack.org/#/c/317152/ 
> - I tried preserving the ‘only::’ tags because I had a
> similar concern about all the common parts to someone compiling the install 
> guide from time to time. We were discussing whether
> this was a good solution as opposed to using ‘include’ directives with 
> distro-specific files referencing common sections; or ignore both
> and maintain four different files (obs, debian, rdo, ubuntu) with common 
> sections included within each.
> 
> Thanks,
> Goutham
> 
> On 6/28/16, 8:55 AM, "Ildikó Váncsa" <ildiko.van...@ericsson.com> wrote:
> 
> Hi,
> 
> I'm currently working on to move the Install Guide for Ceilometer [1] and 
> Aodh [2] under the project trees. I faced with a few
> difficulties so far about which I would like to ask your opinion.
> 
> First of all these two projects are under the Telemetry umbrella, so they are 
> not completely separate. I tried to name the services in
> the documents accordingly in the files. My question here would be whether 
> these two guides will be included in the overall document
> as two totally standalone services or we can link them together somehow?
> 
> The other question I had in mind is in connection with removing ".. only::". 
> As Ceilometer is integrated with several other projects it
> needs additional configuration steps, where we have distro specific steps to 
> follow. I chose the direction of extracting the common
> parts and reused them in the distro specific files. The end result still 
> looks ugly and I have concerns about maintainability. We merged a
> first version of the structure, but I'm happy to change if we can come up 
> with a better solution. Do you have suggestions on this?
> 
> I have a third less urgent question. The install-guide has it's own folder at 
> the same level where these two projects have their 'doc'
> folder. I would assume other projects have the same or similar folder for the 
> developer docs. Would that be reasonable/possible to
> have one main 'doc' folder for all the docs?
> 
> Thanks and Best Regards,
> Ildikó
> 
> [1] https://review.openstack.org/#/c/330051/
> [2] https://review.openstack.org/#/c/330048/
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 

__
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] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi,

@Julien: +1 to the one 'doc' folder.

I think it's not yet decided whether it should be modular, using '.. only::' or 
we can/will have both.

I use the modular approach as well right now, I have many files containing the 
common things and the distro specific steps. For Ceilometer it resulted in way 
more files and folders than it should be in my opinion. And I think it will 
discourage people from contributing to it. The more files you have the harder 
to see how the guide will look like after the build, which can make it slower 
to identify and then modify the files.

Do you have a good proposal for structuring things?

Thanks,
/Ildikó

> -Original Message-
> From: Spyros Trigazis [mailto:strig...@gmail.com]
> Sent: June 28, 2016 17:18
> To: OpenStack Development Mailing List (not for usage questions); Ildikó 
> Váncsa; openstack-d...@lists.openstack.org
> Subject: Re: [openstack-dev] [telemetry] Ceilometer and Aodh install guide(s)
> 
> +1 on the modular approach by Rodrigo Caballero
> 
> I'm writing magnum's guide and I'm working on the debian guide. Debian's 
> guide will have a couple of differences and I plan to move
> them in other files or/and break the existing common config files.
> 
> IMO, one of the goals of the project specific guides was to let teams decide 
> what works for them. If the output guide is similar to
> others, I think you can choose what suits you best.
> 
> Cheers,
> Spyros
> 
> 
> On 28 June 2016 at 16:44, Julien Danjou <jul...@danjou.info> wrote:
> 
> 
>   On Tue, Jun 28 2016, Ildikó Váncsa wrote:
> 
>   > I have a third less urgent question. The install-guide has it's own 
> folder at
>   > the same level where these two projects have their 'doc' folder. I 
> would assume
>   > other projects have the same or similar folder for the developer 
> docs. Would
>   > that be reasonable/possible to have one main 'doc' folder for all the 
> docs?
> 
>   This is our long-term objective for Telemetry projects.
> 
>   Gnocchi already have only one doc/ folder with all the documentation,
>   From installation to usage.
> 
>   I don't think our projects are not big enough and have enough resources
>   to start maintaining different documentations with different scopes,
>   etc.
> 
>   --
>   Julien Danjou
>   ;; Free Software hacker
>   ;; https://julien.danjou.info
> 
>   
> __
>   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-dev] [telemetry] Ceilometer and Aodh install guide(s)

[Ildikó Váncsa]

Hi,

I'm currently working on to move the Install Guide for Ceilometer [1] and Aodh 
[2] under the project trees. I faced with a few difficulties so far about which 
I would like to ask your opinion.

First of all these two projects are under the Telemetry umbrella, so they are 
not completely separate. I tried to name the services in the documents 
accordingly in the files. My question here would be whether these two guides 
will be included in the overall document as two totally standalone services or 
we can link them together somehow?

The other question I had in mind is in connection with removing ".. only::". As 
Ceilometer is integrated with several other projects it needs additional 
configuration steps, where we have distro specific steps to follow. I chose the 
direction of extracting the common parts and reused them in the distro specific 
files. The end result still looks ugly and I have concerns about 
maintainability. We merged a first version of the structure, but I'm happy to 
change if we can come up with a better solution. Do you have suggestions on 
this?

I have a third less urgent question. The install-guide has it's own folder at 
the same level where these two projects have their 'doc' folder. I would assume 
other projects have the same or similar folder for the developer docs. Would 
that be reasonable/possible to have one main 'doc' folder for all the docs?

Thanks and Best Regards,
Ildikó

[1] https://review.openstack.org/#/c/330051/ 
[2] https://review.openstack.org/#/c/330048/ 

__
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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

Hi All,

A friendly reminder that we will have the next Cinder-Nova API changes meeting 
in a few hours at 1700UTC on #openstack-meeting-cp.

For the ongoing work items and agenda details please see the following 
etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes

Thanks and Best Regards,
/Ildikó

> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: May 31, 2016 20:57
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [cinder][nova] Multi-attach/Cinder-Nova weekly 
> IRC meetings
> 
> Hi All,
> 
> We skipped the Monday slot this week due to the holiday in the US. __Only 
> this week__ we will hold the meeting on __Thursday,
> 1700UTC__ on the __#openstack-meeting-cp__ channel.
> 
> Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes
> 
> Thanks and Best Regards,
> /Ildikó
> 
> > -Original Message-
> > From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> > Sent: May 20, 2016 18:31
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [cinder][nova] Multi-attach/Cinder-Nova weekly 
> > IRC meetings
> >
> > Hi All,
> >
> > We have now the approved slot for the Cinder-Nova interaction changes 
> > meeting series. The new slot is __Monday, 1700UTC__, it
> will
> > be on channel  __#openstack-meeting-cp__.
> >
> > Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes
> > Summary about ongoing items: 
> > http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html
> >
> > We will have one exception which is May 30 as it is a US holiday, I will 
> > announce a temporary slot for that week.
> >
> > Thanks,
> > /Ildikó
> >
> > __
> > 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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

Hi All,

We skipped the Monday slot this week due to the holiday in the US. __Only this 
week__ we will hold the meeting on __Thursday, 1700UTC__ on the 
__#openstack-meeting-cp__ channel.

Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes 

Thanks and Best Regards,
/Ildikó

> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: May 20, 2016 18:31
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [cinder][nova] Multi-attach/Cinder-Nova weekly 
> IRC meetings
> 
> Hi All,
> 
> We have now the approved slot for the Cinder-Nova interaction changes meeting 
> series. The new slot is __Monday, 1700UTC__, it will
> be on channel  __#openstack-meeting-cp__.
> 
> Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes
> Summary about ongoing items: 
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html
> 
> We will have one exception which is May 30 as it is a US holiday, I will 
> announce a temporary slot for that week.
> 
> Thanks,
> /Ildikó
> 
> __
> 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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

Hi All,

We have now the approved slot for the Cinder-Nova interaction changes meeting 
series. The new slot is __Monday, 1700UTC__, it will be on channel  
__#openstack-meeting-cp__.

Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes 
Summary about ongoing items: 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html 

We will have one exception which is May 30 as it is a US holiday, I will 
announce a temporary slot for that week.

Thanks,
/Ildikó

__
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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

> -Original Message-
> From: Mike Perez [mailto:thin...@gmail.com]
> Sent: May 17, 2016 02:23
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder][nova] Multi-attach/Cinder-Nova weekly 
> IRC meetings
> 
> On 17:59 May 16, Ildikó Váncsa wrote:
> > Hi All,
> >
> > We will have the Cinder-Nova interaction changes meetings in a new
> > slot starting from this week. The new slot is __Tuesday, 1700UTC__. We
> > will also move it to another channel, which is the 
> > __#openstack-meeting-alt__.
> >
> > Related etherpad:
> > https://etherpad.openstack.org/p/cinder-nova-api-changes
> > Summary about ongoing items:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.htm
> > l
> 
> Looks like that meeting time is taken according to the review [1]. I'm fine 
> with this being in #openstack-meeting-cp, assuming this is
> just multi-attach efforts and not some on-going cinder and nova api meeting.

Never use Outlook... :) :(

All channels are taken at that slot, but I had an old calendar loaded in 
Outlook somehow so it didn't show. I will try to find another slot that works, 
today we can fall back and have a chat on the Cinder channel I think as we have 
more Cinder items for now.

Thanks,
/Ildikó

> 
> [1] - https://review.openstack.org/#/c/317038/
> 
> --
> Mike Perez
> 
> __
> 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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

Hi All,

We will have the Cinder-Nova interaction changes meetings in a new slot 
starting from this week. The new slot is __Tuesday, 1700UTC__. We will also 
move it to another channel, which is the __#openstack-meeting-alt__.

Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes 
Summary about ongoing items: 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html 

Thanks,
/Ildikó

__
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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

> -Original Message-
> From: Mike Perez [mailto:m...@openstack.org]
> Sent: May 11, 2016 23:52
> To: Ildikó Váncsa
> Cc: 'D'Angelo, Scott <scott.dang...@hpe.com> (scott.dang...@hpe.com)'; 
> 'Walter A. Boring IV'; 'John Griffith
> <john.griffi...@gmail.com> (john.griffi...@gmail.com)'; 'Matt Riedemann'; 
> 'Sean McGinnis'; 'John Garbutt <j...@johngarbutt.com>
> (j...@johngarbutt.com)'; openstack-dev@lists.openstack.org
> Subject: Re: [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings
> 
> On 14:38 May 11, Ildikó Váncsa wrote:
> > Hi All,
> >
> > We will continue the meeting series about the Cinder-Nova interaction 
> > changes mostly from multiattach  perspective. We have a
> new meeting slot, which is __Thursday, 1700UTC__ on the #openstack-meeting-cp 
> channel.
> >
> > Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes
> > Summary about ongoing items: 
> > http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html
> 
> I don't think this meeting is registered. [1] Take a look at [2].

A quick question before I move forward with registering this temporary series. 
As it is a project to project interaction as opposed to a cross-project meeting 
according to [2] I assume I should pick another IRC channel for this. Is that 
correct? If yes, is the temporary nature of the meeting series is accepted on 
other meeting channels as well?

Thanks,
/Ildikó

> 
> [1] - http://eavesdrop.openstack.org/
> [2] - https://review.openstack.org/#/c/301822/6/doc/source/cross-project.rst
> 
> --
> Mike Perez

__
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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

[Ildikó Váncsa]

Hi All,

We will continue the meeting series about the Cinder-Nova interaction changes 
mostly from multiattach  perspective. We have a new meeting slot, which is 
__Thursday, 1700UTC__ on the #openstack-meeting-cp channel.

Related etherpad: https://etherpad.openstack.org/p/cinder-nova-api-changes
Summary about ongoing items: 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094089.html 

Thanks,
/Ildikó

__
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] [OpenStack-docs] What's Up, Doc? 6 May 2016

[Ildikó Váncsa]

> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: May 07, 2016 20:51
> To: Ildikó Váncsa; 'Matt Kassawara'
> Cc: OpenStack Development Mailing List; enstack.org
> Subject: Re: [OpenStack-docs] What's Up, Doc? 6 May 2016
> 
> On 05/07/2016 06:09 PM, Ildikó Váncsa wrote:
> > Hi Matt,
> >
> > I'm open to discuss what would be the best way forward in this topic. First 
> > of all I would like to understand the intention with
> document structures long term to see how we can have a scalable and 
> maintainable process.
> >
> > My experience is that keeping the documentation up to date separately from 
> > the code can be difficult that results in outdated
> materials, which also leads to bad user experience and impression.
> >
> > Would this topic be sufficient for one of the team meetings?
> 
> Right now we have the Install Guide as first guide where we move content to 
> the teams and still want to provide this from one place.
> 
> I suggest that we do the Install Guide first and then consider whether that 
> is a model that we should use for other documents as well,

Ok, that sounds good. Thanks Andreas for clarifying.

Best Regards,
Ildikó

> 
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

__
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] [OpenStack-docs] What's Up, Doc? 6 May 2016

[Ildikó Váncsa]

Hi Matt,

I'm open to discuss what would be the best way forward in this topic. First of 
all I would like to understand the intention with document structures long term 
to see how we can have a scalable and maintainable process.

My experience is that keeping the documentation up to date separately from the 
code can be difficult that results in outdated materials, which also leads to 
bad user experience and impression.

Would this topic be sufficient for one of the team meetings?

Thanks and Best Regards,
Ildikó

> -Original Message-
> From: Matt Kassawara [mailto:mkassaw...@gmail.com]
> Sent: May 07, 2016 00:55
> To: Ildikó Váncsa
> Cc: Lana Brindley; enstack.org; OpenStack Development Mailing List; 
> openstack-i...@lists.openstack.org
> Subject: Re: [OpenStack-docs] What's Up, Doc? 6 May 2016
> 
> One significant advantage of central documentation involves providing content 
> in a single location with consistent structure or format
> that best serves the particular audience. Moving most or all documentation 
> into project trees essentially eliminates this advantage,
> leaving our audiences with an impression that OpenStack consists of many 
> loosely associated projects rather than a coherent cloud
> computing solution. However, as a contributor to a few other OpenStack 
> projects who helps other developers contribute to central
> documentation, I can understand some of the frustrations with it. I prefer to 
> resolve these frustrations and have some ideas that I
> intend to float in separate thread, but if you don't think that's possible, 
> consider submitting a spec to change the primary purpose of
> the central documentation team to simply managing links to content in the 
> project trees.
> 
> On Fri, May 6, 2016 at 10:03 AM, Ildikó Váncsa <ildiko.van...@ericsson.com> 
> wrote:
> 
> 
>   Hi Lana,
> 
>   Thanks for the summary, it's pretty good reading to catch up what 
> happened recently.
> 
>   I have one question, I might missed a few entries, so please point me 
> to the right document in this case. We had a
> docco session with the Telemetry team and we agreed on moving back the 
> documentation snippets, like for instance the Install
> Guide, to the project trees is a really good step and we're very supportive. 
> In this sense I would like to ask about the plans regarding
> the Admin guide. We have a chapter there, which is on one hand outdated and 
> on the other hand would be better to move under the
> project trees as well. Is this plan/desire in line with your plans regarding 
> that document?
> 
>   Thanks,
>   /Ildikó
> 
> 
>   > -Original Message-
>   > From: Lana Brindley [mailto:openst...@lanabrindley.com]
>   > Sent: May 06, 2016 08:13
>   > To: enstack.org; OpenStack Development Mailing List; 
> openstack-i...@lists.openstack.org
>   > Subject: What's Up, Doc? 6 May 2016
>   >
>   > Hi everyone,
>   >
>   > I hope you all had a safe journey home from Summit, and are now fully 
> recovered from all the excitement (and
> jetlag)! I'm really
>   > pleased with the amount of progress we made this time around. We have 
> a definitive set of goals for Newton, and I'm
> confident that
>   > they're all moving us towards a much better docs suite overall. Of 
> course, the biggest and most important work we
> have to do is to get
>   > our Install Guide changes underway. I'm very excited to see the new 
> method for documenting OpenStack installation,
> and can't wait
>   > to see all our big tent projects contributing to docs in such a 
> meaningful way. Thank you to everyone (in the room and
> online) who
>   > contributed to the Install Guide discussion, and helped us move 
> forward on this important project.
>   >
>   > In other news, I've written a wrapup of the Austin design summit on 
> my blog, which you might be interested in:
>   > 
> http://lanabrindley.com/2016/05/05/openstack-newton-summit-docs-wrapup/
>   >
>   > == Progress towards Newton ==
>   >
>   > 152 days to go!
>   >
>   > Bugs closed so far: 61
>   >
>   > Because we have such a specific set of deliverables carved out for 
> Newton, I've made them their own wiki page:
>   > https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
>   > Feel free to add more detail and cross things off as they are 
> achieved throughout the release. I will also do my best to
> ensure it's kept
>   > up to date for each newsletter.
>   >
>   > One of the first tasks we've started work on af

Re: [openstack-dev] What's Up, Doc? 6 May 2016

[Ildikó Váncsa]

Hi Lana,

Thanks for the summary, it's pretty good reading to catch up what happened 
recently.

I have one question, I might missed a few entries, so please point me to the 
right document in this case. We had a docco session with the Telemetry team and 
we agreed on moving back the documentation snippets, like for instance the 
Install Guide, to the project trees is a really good step and we're very 
supportive. In this sense I would like to ask about the plans regarding the 
Admin guide. We have a chapter there, which is on one hand outdated and on the 
other hand would be better to move under the project trees as well. Is this 
plan/desire in line with your plans regarding that document?

Thanks,
/Ildikó

> -Original Message-
> From: Lana Brindley [mailto:openst...@lanabrindley.com]
> Sent: May 06, 2016 08:13
> To: enstack.org; OpenStack Development Mailing List; 
> openstack-i...@lists.openstack.org
> Subject: What's Up, Doc? 6 May 2016
> 
> Hi everyone,
> 
> I hope you all had a safe journey home from Summit, and are now fully 
> recovered from all the excitement (and jetlag)! I'm really
> pleased with the amount of progress we made this time around. We have a 
> definitive set of goals for Newton, and I'm confident that
> they're all moving us towards a much better docs suite overall. Of course, 
> the biggest and most important work we have to do is to get
> our Install Guide changes underway. I'm very excited to see the new method 
> for documenting OpenStack installation, and can't wait
> to see all our big tent projects contributing to docs in such a meaningful 
> way. Thank you to everyone (in the room and online) who
> contributed to the Install Guide discussion, and helped us move forward on 
> this important project.
> 
> In other news, I've written a wrapup of the Austin design summit on my blog, 
> which you might be interested in:
> http://lanabrindley.com/2016/05/05/openstack-newton-summit-docs-wrapup/
> 
> == Progress towards Newton ==
> 
> 152 days to go!
> 
> Bugs closed so far: 61
> 
> Because we have such a specific set of deliverables carved out for Newton, 
> I've made them their own wiki page:
> https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
> Feel free to add more detail and cross things off as they are achieved 
> throughout the release. I will also do my best to ensure it's kept
> up to date for each newsletter.
> 
> One of the first tasks we've started work on after Summit is moving the Ops 
> and HA Guides out of their own repositories and into
> openstack-manuals. As a result, those repositories are now frozen, and any 
> work you want to do on those books should be in
> openstack-manuals.
> 
> We are almost ready to publish the new RST version of the Ops Guide, there's 
> just a few cleanup edits going in now, so make sure you
> have the right book, in the right repo from now on. This was our very last 
> book remaining in DocBook XML, so the docs toolchain will
> be removing DocBook XML support. See spec https://review.openstack.org/311698 
> for details.
> 
> Another migration note is that the API reference content is moving from 
> api-site to project specific repositories and api-site is now
> frozen. For more detail, see Anne's email: 
> http://lists.openstack.org/pipermail/openstack-docs/2016-May/008536.html
> 
> == Mitaka wrapup ==
> 
> We performed a Mitaka retrospective at Summit, notes are here: 
> https://etherpad.openstack.org/p/austin-docs-mitakaretro
> 
> In particular, I'd like to call out our hard working tools team Andreas and 
> Christian, all our Speciality Team leads, and the Mitaka release
> managers Brian and Olga. Well done on a very successful release, everyone :)
> 
> Total bugs closed: 645
> 
> == Site Stats ==
> 
> Thanks to the lovely people at Foundation (thanks Allison!) I now have access 
> to more stats than I could possibly guess what to do
> with, and I'm hoping to be able to share some of these with you through the 
> newsletter. If there's something in particular you would
> like to see, then please let me know and I'll endeavour to record it here!
> 
> So far I can tell you that docs.openstack.org had 1.63M unique pageviews in 
> April, down slightly from 1.72M in March, and the average
> session duration is just over six minutes, looking at just under 4 pages per 
> session.
> 
> == Doc team meeting ==
> 
> Next meetings:
> 
> We'll be restarting the meeting series next week.
> 
> Next meetings:
> US: Wednesday 11 April, 19:00 UTC
> APAC: Wednesday 18 April, 00:30 UTC
> 
> Please go ahead and add any agenda items to the meeting page here:
> https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting
> 
> --
> 
> Keep on doc'ing!
> 
> Lana
> 
> https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#6_May_2016
> 
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com

__

Re: [openstack-dev] [nova][cinder] Austin summit nova/cinder cross-project session recap

[Ildikó Váncsa]

inder teams got together for a
> cross-project design summit session. The full etherpad is here [1].
> 
> This was all about volume multi-attach.
> 
> A subset of people from both teams were actually meeting weekly for four
> weeks leading up to the summit to hash out some details which we hoped
> to resolve at the summit. Unfortunately that didn't happen.
> 
> The first thing we wanted to settle was why do we actually want/need to
> support volume multi-attach? Because "Cinder added it to their API in
> Juno so Nova needs to support it" isn't a good reason. There are a few
> drivers for this feature:
> 
> * The need for active/active and active/hot standby scenarios which
> can't accept downtime due to attaching a new volume.
> 
> * Some database clusters, like Oracle RAC, require shared volumes. So
> Trove is a stakeholder for this feature also.
> 
> * Other legacy application use cases were brought up that essentially
> mean this is something they need to bridge a gap to adopting OpenStack.
> 
> So we agreed that while this is not really something we necessarily like
> (because of the non-cloud legacy application nature of it), it is
> necessary so we're going to continue trying to make it happen.
> 
> We then quickly went over what was completed in Mitaka and explained the
> detach issue we ran into. The problem is when you have more than one
> volume attached to the same instance on the same host, when you detach
> one of them, both of the volume connections actually get terminated on
> the host.
> 
> This problem is also complicated by the fact that some Cinder backends
> will create one attachment per export/volume, whereas others will
> multiplex all volumes onto one attachment.
> 
> Coming into the session we really had two competing solutions from the
> Cinder team, one from Walter Boring and one from John Griffith. However,
> during the session another idea was brought up from Dan Smith. The full
> details are in the etherpad, but it's really an idea to abstract the
> multiple volume attachments on the Cinder side that Nova only sees a
> single volume, so Nova wouldn't have to change any of it's API handling
> for Cinder volumes to be checking if they support multiattach or not,
> and thus have to have conditional logic spread all over Nova (API,
> compute, and virt drivers).
> 
> With Dan's idea we'd still have the disconnect/detach problem where Nova
> would need to check if it can disconnect from the host if there is only
> a single attachment left, but Nova has to do that regardless for all of
> the proposed solutions.
> 
> It sounded like John Griffith had a similar idea before when looking at
> this problem, and we spent a fair amount of time discussing it on both
> sides during the session.
> 
> At the end of the session, we (Nova) came away with the following next
> steps:
> 
> 1. John Griffith (Cinder team) would work on a proof of concept for the
> abstracted volume idea.
> 
> 2. Cinder would work on adding a volume migration test to Tempest to be
> run in the multi-node gate job (this needs to happen regardless). Scott
> D'Angelo is going to work on this.
> 
> 3. Ildikó Váncsa was going to work on the Nova volume disconnect ref
> counting logic.
> 
> 4. We'd meet on Friday during the Nova meetup session to discuss more
> details.
> 
> --
> 
> So what happened then was we met on Friday and found out that we were
> all speaking different languages on Thursday, because the Cinder team
> didn't think that they were going to be going with this new abstracted
> volume idea. After much wailing and gnashing of teeth we agreed to do a
> hangout shortly after the summit to try and get back on the same page.
> So we're doing that tomorrow (5/5) at 1600 UTC. This is going to be at
> least myself, Ildikó, Scott and Walter on the call. Walter has been
> creating diagrams of the flows through Nova and Cinder for various
> interactions like attach/detach of volumes and volume-backed live
> migration so that we can try to step back and see where the proposed
> changes fit in.
> 
> It's sounding like regardless of solution there will be changes to the
> Cinder API (at least for os-initialize_connection). There might be some
> new APIs too, for example, an API to get connection_info during live
> migration without Nova having to call os-initialize_connection to get it.
> 
> So we'll see what happens. We'll eventually figure out. After all, it's
> only code, right? :)
> 
> [1] https://etherpad.openstack.org/p/newton-nova-cinder
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Maili

Re: [openstack-dev] [cinder] [nova] Cinder-Nova API meeting

[Ildikó Váncsa]

Hi All,

We are having the last Cinder-Nova API interactions meeting before the Summit 
this Wednesday __20th April 2100UTC__, on the #openstack-meeting-cp channel.

You can find the information about the recent discussions here: 
https://etherpad.openstack.org/p/cinder-nova-api-changes

This week will mainly focus on the scenarios beyond attach/detach, we need to 
address during the design sessions mostly from multi-attach perspective.

Best Regards,
/Ildikó

__
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] [telemetry][vitrage] Joint design sesssion in Austin

[Ildikó Váncsa]

Hi Julien,

First of all big +1. :)

The 16:10-16:50 slot looks better for me.

Thanks,
/Ildikó

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: April 14, 2016 11:07
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [telemetry][vitrage] Joint design sesssion in Austin
> 
> Hi folks,
> 
> Vitrage doesn't have any track/session at the summit, and we Telemetry have a 
> bunch of spare ones, so I figured we should use one
> to meet and chat a bit about how our projects can help each others. There 
> should be some interesting evolution for Aodh going
> forward with the usage Vitrage is making of it.
> 
> We got 2 slots available on Thursday 28th April: 16:10-16:50 or 17:00:17:40. 
> Would any of those fit the schedule of every interested?
> 
> Cheers,
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info

__
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] [cinder][nova] Cinder-Nova API meeting

[Ildikó Váncsa]

Hi All,

It's a friendly reminder we're having the next Cinder-Nova API interactions 
meeting this Wednesday __13th April 2100UTC__, on the #openstack-meeting-cp 
channel.

You can follow up the recent activities here: 
https://etherpad.openstack.org/p/cinder-nova-api-changes Our current focus is 
on attach/detach scenarios focusing on better tracking of attachment info in 
Cinder to avoid detach problems listed on the etherpad.

Best Regards,
/Ildikó

__
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] [cinder][nova] Cinder-Nova API meeting

[Ildikó Váncsa]

Hi All,

As we have much to do, our next meeting about improving the Cinder-Nova API 
interaction will take place __April 6th, 2100UTC__ on the #openstack-meeting-cp 
channel.

You can follow up the recent activities on this etherpad: 
https://etherpad.openstack.org/p/cinder-nova-api-changes 

Best Regards,
/Ildikó

> -Original Message-
> From: Ildikó Váncsa
> Sent: March 24, 2016 10:01
> To: openstack-dev@lists.openstack.org
> Subject: [cinder][nova] Cinder-Nova API meeting
> 
> Hi All,
> 
> As it was discussed several times on this mailing list there is room for 
> improvements regarding the Cinder-Nova interaction. To fix
> these issues we would like to create a cross-project spec to capture the 
> problems and ways to solve them. The current activity is
> captured on this etherpad: 
> https://etherpad.openstack.org/p/cinder-nova-api-changes
> 
> Before writing up several specs we will have a meeting next Wednesday to 
> synchronize and discuss with the two teams and everyone
> who's interested in this work the way forward.
> 
> The meeting will be held on the #openstack-meeting-cp channel, on March 30, 
> 2100UTC.
> 
> Please let me know if you have any questions.
> 
> See you next week!
> Best Regards,
> /Ildikó

__
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] [telemetry] Rescheduling IRC meetings

[Ildikó Váncsa]

Hi Gordon,

> 
> ie. the new PTL should checkpoint with subteam leads regularly to review spec 
> status or identify missing resources on high-priority
> items?

I would say anything that we feel as useful information to people who read this 
mailing list. In this sense features that got implemented, items we are 
focusing on, as you mentioned resource bottlenecks on important items, etc.

> 
> as some feedback, re: news flash mails, we need a way to promote roadmap 
> backlog items better. i'm not sure anyone looks at Road
> Map page...
> maybe we need to organise it better with priority and incentive.

I had the Roadmap page in mind as well partially, we could highlight the 
plans/tasks from that page and also track progress.

Thanks,
/Ildikó

> 
> On 31/03/2016 7:14 AM, Ildikó Váncsa wrote:
> > Hi All,
> >
> > +1 on the on demand meeting schedule. Maybe we can also have some news 
> > flash mails  week to summarize the progress in our
> sub-modules when we don't have the meeting. Just to keep people up to date.
> >
> > Will we already skip the today's meeting?
> >
> > Thanks,
> > /Ildikó
> >
> >> -Original Message-
> >> From: Julien Danjou [mailto:jul...@danjou.info]
> >> Sent: March 31, 2016 11:04
> >> To: liusheng
> >> Cc: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [telemetry] Rescheduling IRC meetings
> >>
> >> On Thu, Mar 31 2016, liusheng wrote:
> >>
> >>> Another personal suggestion:
> >>>
> >>> maybe we can have a weekly routine mail thread to present the things
> >>> need to be discussed or need to be notified. The mail will also list
> >>> the topics posted in meeting agenda and ask to Telemetry folks if  a
> >>> online IRC meeting is necessary, if there are a very few topics or
> >>> low priority topics, or the topics can be suitably discussed
> >>> asynchronously, we can disuccs them in the mail thread.
> >>>
> >>> any thoughts?
> >>
> >> Yeah I think it's more or less the same idea that was proposed,
> >> schedule a meeting only if needed. I'm going to amend the meeting wiki 
> >> page with that!
> >>
> >> --
> >> Julien Danjou
> >> -- Free Software hacker
> >> -- https://julien.danjou.info
> >
> > __
> >  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
> >
> 
> --
> gord
> 
> __
> 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] [telemetry] Rescheduling IRC meetings

[Ildikó Váncsa]

Hi All,

+1 on the on demand meeting schedule. Maybe we can also have some news flash 
mails  week to summarize the progress in our sub-modules when we don't have the 
meeting. Just to keep people up to date.

Will we already skip the today's meeting?

Thanks,
/Ildikó

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: March 31, 2016 11:04
> To: liusheng
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [telemetry] Rescheduling IRC meetings
> 
> On Thu, Mar 31 2016, liusheng wrote:
> 
> > Another personal suggestion:
> >
> > maybe we can have a weekly routine mail thread to present the things
> > need to be discussed or need to be notified. The mail will also list
> > the topics posted in meeting agenda and ask to Telemetry folks if  a
> > online IRC meeting is necessary, if there are a very few topics or low
> > priority topics, or the topics can be suitably discussed
> > asynchronously, we can disuccs them in the mail thread.
> >
> > any thoughts?
> 
> Yeah I think it's more or less the same idea that was proposed, schedule a 
> meeting only if needed. I'm going to amend the meeting
> wiki page with that!
> 
> --
> Julien Danjou
> -- Free Software hacker
> -- https://julien.danjou.info

__
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] [elections][tc] TC Candidacy

[Ildikó Váncsa]

Hi All,

I would like to throw my hat in the ring to be part of the OpenStack Technical
Committee.

I'm working at Ericsson, where I'm coordinating the OpenStack related activities
across the company. I started to contribute to OpenStack more than two years ago
by adding rich query functionality to Ceilometer. Since then I got nominated as
a core reviewer in the project, where beyond other contributions, I became the
constant voice of usability aspects and backward compatibility. Among other
projects I'm contributing to Nova and OpenStack Manuals as well[1].

I would like to increase diversity in the TC group, but more importantly my
goal is to add fresh blood to the forum driving this community. In my
opinion it is very important to constantly revisit items from a different
perspective and let new voices articulate their views and ideas in order to see
the big picture. Long term this can ensure that OpenStack keeps its adaptability
to continue to be a smoothly functioning ecosystem just as being a stable and
successful software package.

In the course of my current role within Ericsson I encourage and follow the
contribution activities of my colleagues, by which I have a good oversight on
how OpenStack works as a community. Driven by my colleagues' and my own
experiences I see cross-project collaboration as an area, where notwithstanding
the already ongoing great work there is still room for further improvements. As
part of the TC I would like to participate in driving cross-project activities,
where I plan to focus on the on-boarding aspects. In my opinion it is very
important to spend time educating newcomers and helping to rapidly build up
competencies regarding processes likewise in the realm of technology and
coding abilities and guidelines. As part of this mission I would continue to
invest energy in bringing sessions on stage at the OpenStack Summits[2][3] to
share the lessons I learnt during the past two and a half years. It is key to
explain to people how the community really works beyond the well-documented
processes and tools that we are using every day. The devil is in the details, as
always.

I mentioned adaptability earlier, which I feel being a very important aspect as
it outlines the ability to constantly change when needed. In my view operating
OpenStack as Big Tent is a good approach, although I think it is important to
check the principles and review criteria to evaluate the new project
candidates to rationalize the current review process. I also got the impression
that the idea behind the tags is being devalued due to proliferation. I have
similar feelings regarding governance on project level. In my view it is very
important to give guidelines on how the teams can efficiently operate, but it is
time consuming and destroys the focus of the TC to spend much energy on giving
detailed descriptions and regulations on how these groups should work within
OpenStack. Among others I would like to revisit the aforementioned items to make
the responsibilities and activities of the TC more clear and make the group even
more efficient.

As an employee of a Telecom vendor I would like to bring in the NFV mindset to
OpenStack to be part of the daily discussions as opposed to being a mysterious
abbreviation that introduces competing priorities. During the past few years I
saw and experienced the difficulties and even pain of trying to find the common
language between the two groups and making the contributions happen. I think it
is very important to help the Telecom industry in the transformation to fit
into the cloud terminology and the open source era. By this process OpenStack
can leverage the advantages that this completely different set of priorities
and requirements could offer, such as increased stability and advanced
networking functionality.

I'm involved in OPNFV[4] and it is part of my mission to find the connection
points between the two communities[5] to build a large ecosystem which fits
OpenStack's current priorities[6] in the sense of actively supporting and being
the foundation for NFV. As a benefit for us we can use the test environment and
test frameworks to see how OpenStack operates in a fully integrated environment
on top of different hardware platforms. OPNFV brings integration and functional
testing to a different level which is an important feedback to our community and
a good checkpoint to our users. As more and more Telecom operators are looking
at OpenStack as a main building block of their systems, I would like to serve as
a representative in the technical driving force of OpenStack, who can operate as
a translator to build a common roadmap.

Thank you for reading through my thoughts. It is an honor to be part of
OpenStack, which is why I would like to take part in bringing this community
further to provide a package that can serve the whole industry and which is
backed up by a growing and smoothly functioning ecosystem.

Thank you for your consideration.

Best Regards,

[openstack-dev] [cinder][nova] Cinder-Nova API meeting

[Ildikó Váncsa]

Hi All,

As it was discussed several times on this mailing list there is room for 
improvements regarding the Cinder-Nova interaction. To fix these issues we 
would like to create a cross-project spec to capture the problems and ways to 
solve them. The current activity is captured on this etherpad: 
https://etherpad.openstack.org/p/cinder-nova-api-changes

Before writing up several specs we will have a meeting next Wednesday to 
synchronize and discuss with the two teams and everyone who's interested in 
this work the way forward.

The meeting will be held on the #openstack-meeting-cp channel, on March 30, 
2100UTC.

Please let me know if you have any questions.

See you next week!
Best Regards,
/Ildikó

__
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] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

[Ildikó Váncsa]

Hi Walt,

Thanks for describing the bigger picture.

In my opinion when we will have microversion support available in Cinder that 
will give us a bit of a freedom and also possibility to handle these 
difficulties.

Regarding terminate_connection we will have issues with live_migration as it is 
today. We need to figure out what information would be best to feed back to 
Cinder from Nova, so we should figure out what API we would need after we are 
able to introduce it in a safe way. I still see benefit in storing the 
connection_info for the attachments.

Also I think the multiattach support should be disable for the problematic 
drivers like lvm, until we don't have a solution for proper detach on the whole 
call chain.

Best Regards,
Ildikó

> -Original Message-
> From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
> Sent: February 11, 2016 18:31
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to 
> call os-brick's connector.disconnect_volume
> 
> There seems to be a few discussions going on here wrt to detaches.   One
> is what to do on the Nova side with calling os-brick's disconnect_volume, and 
> also when to or not to call Cinder's
> terminate_connection and detach.
> 
> My original post was simply to discuss a mechanism to try and figure out the 
> first problem.  When should nova call brick to remove the
> local volume, prior to calling Cinder to do something.
> 
> Nova needs to know if it's safe to call disconnect_volume or not. Cinder 
> already tracks each attachment, and it can return the
> connection_info
> for each attachment with a call to initialize_connection.   If 2 of
> those connection_info dicts are the same, it's a shared volume/target.
> Don't call disconnect_volume if there are any more of those left.
> 
> On the Cinder side of things, if terminate_connection, detach is called, the 
> volume manager can find the list of attachments for a
> volume, and compare that to the attachments on a host.  The problem is, 
> Cinder doesn't track the host along with the instance_uuid in
> the attachments table.  I plan on allowing that as an API change after 
> microversions lands, so we know how many times a volume is
> attached/used on a particular host.  The driver can decide what to do with it 
> at
> terminate_connection, detach time. This helps account for
> the differences in each of the Cinder backends, which we will never get all 
> aligned to the same model.  Each array/backend handles
> attachments different and only the driver knows if it's safe to remove the 
> target or not, depending on how many attachments/usages
> it has
> on the host itself.   This is the same thing as a reference counter,
> which we don't need, because we have the count in the attachments table, once 
> we allow setting the host and the instance_uuid at
> the same time.
> 
> Walt
> > On Tue, Feb 09, 2016 at 11:49:33AM -0800, Walter A. Boring IV wrote:
> >> Hey folks,
> >> One of the challenges we have faced with the ability to attach a
> >> single volume to multiple instances, is how to correctly detach that
> >> volume.  The issue is a bit complex, but I'll try and explain the
> >> problem, and then describe one approach to solving one part of the detach 
> >> puzzle.
> >>
> >> Problem:
> >>When a volume is attached to multiple instances on the same host.
> >> There are 2 scenarios here.
> >>
> >>1) Some Cinder drivers export a new target for every attachment on
> >> a compute host.  This means that you will get a new unique volume
> >> path on a host, which is then handed off to the VM instance.
> >>
> >>2) Other Cinder drivers export a single target for all instances
> >> on a compute host.  This means that every instance on a single host,
> >> will reuse the same host volume path.
> >
> > This problem isn't actually new. It is a problem we already have in
> > Nova even with single attachments per volume.  eg, with NFS and SMBFS
> > there is a single mount setup on the host, which can serve up multiple 
> > volumes.
> > We have to avoid unmounting that until no VM is using any volume
> > provided by that mount point. Except we pretend the problem doesn't
> > exist and just try to unmount every single time a VM stops, and rely
> > on the kernel failing umout() with EBUSY.  Except this has a race
> > condition if one VM is stopping right as another VM is starting
> >
> > There is a patch up to try to solve this for SMBFS:
> >
> > https://review.openstack.org/#/c/187619/
> >
> > but I don't really much like it, because it only solves it for one
> > driver.
> >
> > I think we need a general solution that solves the problem for all
> > cases, including multi-attach.
> >
> > AFAICT, the only real answer here is to have nova record more info
> > about volume attachments, so it can reliably decide when it is safe to
> > release a connection on the host.
> >
> >
> >> Proposed solution:
> >>Nova needs to 

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

[Ildikó Váncsa]

Hi,

As far as I can see volume attachments are handled on attachment level today as 
opposed to host level in Cinder. How the volume is exposed to a host 
technically is another question, but conceptually Cinder is the ultimate source 
of truth regarding how many attachments a volume has and what driver takes care 
of that volume.

In this sense in my understanding what you are suggesting below would need a 
redesign and refactoring so that the concept and the implementation are in line 
with each other. We talked about this at the beginning of Mitaka and this was 
the outcome of that discussion too as far as I can remember.

Tracking the connector info is not Nova's responsibility I think neither 
keeping track of what back end provides the volume to it. I think we need to 
find the solution within the current concept and architecture and then refactor 
to the aimed design. We cannot use what we have and solve our issues according 
what we would like to have. That will not match but bring additional complexity 
to these modules.

Would the new API and the connector info record in the Cinder database cause 
any problems conceptually and/or technically?

Thanks,
Ildikó

> -Original Message-
> From: Avishay Traeger [mailto:avis...@stratoscale.com]
> Sent: February 11, 2016 07:43
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to 
> call os-brick's connector.disconnect_volume
> 
> I think Sean and John are in the right direction.  Nova and Cinder need to be 
> more decoupled in the area of volume attachments.
> 
> I think some of the mess here is due to different Cinder backend behavior - 
> with some Cinder backends you actually attach volumes to
> a host (e.g., FC, iSCSI), with some you attach to a VM (e.g., Ceph), and with 
> some you attach an entire pool of volumes to a host (e.g.,
> NFS).  I think this difference should all be contained in the Nova drivers 
> that do the attachments.
> 
> On Thu, Feb 11, 2016 at 6:06 AM, John Griffith  
> wrote:
> 
> 
> 
> 
>   On Wed, Feb 10, 2016 at 5:12 PM, Fox, Kevin M  
> wrote:
> 
> 
>   But the issue is, when told to detach, some of the drivers do 
> bad things. then, is it the driver's issue to
> refcount to fix the issue, or is it nova's to refcount so that it doesn't 
> call the release before all users are done with it? I think solving it in
> the middle, in cinder's probably not the right place to track it, but if its 
> to be solved on nova's side, nova needs to know when it needs
> to do it. But cinder might have to relay some extra info from the backend.
> 
>   Either way, On the driver side, there probably needs to be a 
> mechanism on the driver to say it either can
> refcount properly so its multiattach compatible (or that nova should 
> refcount), or to default to not allowing multiattach ever, so
> existing drivers don't break.
> 
>   Thanks,
>   Kevin
>   
>   From: Sean McGinnis [sean.mcgin...@gmx.com]
>   Sent: Wednesday, February 10, 2016 3:25 PM
>   To: OpenStack Development Mailing List (not for usage questions)
>   Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, 
> determining when to call os-brick's
> connector.disconnect_volume
> 
> 
>   On Wed, Feb 10, 2016 at 11:16:28PM +, Fox, Kevin M wrote:
>   > I think part of the issue is whether to count or not is 
> cinder driver specific and only cinder knows if it
> should be done or not.
>   >
>   > But if cinder told nova that particular multiattach endpoints 
> must be refcounted, that might resolve the
> issue?
>   >
>   > Thanks,
>   > Kevin
> 
>   I this case (the point John and I were making at least) it 
> doesn't
>   matter. Nothing is driver specific, so it wouldn't matter which 
> backend
>   is being used.
> 
>   If a volume is needed, request it to be attached. When it is no 
> longer
>   needed, tell Cinder to take it away. Simple as that.
> 
> 
>   
> __
>   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
>   
> 

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

[Ildikó Váncsa]

Hi Walt,

> -Original Message-
> From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
> Sent: February 09, 2016 23:15
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to 
> call os-brick's connector.disconnect_volume
> 
> On 02/09/2016 02:04 PM, Ildikó Váncsa wrote:
> > Hi Walt,
> >
> > Thanks for starting this thread. It is a good summary of the issue and the 
> > proposal also looks feasible to me.
> >
> > I have a quick, hopefully not too wild idea based on the earlier 
> > discussions we had. We were considering earlier to store the target
> identifier together with the other items of the attachment info. The problem 
> with this idea is that when we call initialize_connection
> from Nova, Cinder does not get the relevant information, like instance_id, to 
> be able to do this. This means we cannot do that using
> the functionality we have today.
> >
> > My idea here is to extend the Cinder API so that Nova can send the missing 
> > information after a successful attach. Nova should have
> all the information including the 'target', which means that it could update 
> the attachment information through the new Cinder API.
> I think we need to do is to allow the connector to be passed at
> os-attach time.   Then cinder can save it in the attachment's table entry.
> 
> We will also need a new cinder API to allow that attachment to be updated 
> during live migration, or the connector for the attachment
> will get stale and incorrect.

When saying below that it will be good for live migration as well I meant that 
the update is part of the API.

Ildikó

> 
> Walt
> >
> > It would mean that when we request for the volume info from Cinder at 
> > detach time the 'attachments' list would contain all the
> required information for each attachments the volume has. If we don't have 
> the 'target' information because of any reason we can
> still use the approach described below as fallback. This approach could even 
> be used in case of live migration I think.
> >
> > The Cinder API extension would need to be added with a new microversion to 
> > avoid problems with older Cinder versions talking to
> new Nova.
> >
> > The advantage of this direction is that we can reduce the round trips to 
> > Cinder at detach time. The round trip after a successful
> attach should not have an impact on the normal operation as if that fails the 
> only issue we have is we need to use the fall back method
> to be able to detach properly. This would still affect only multiattached 
> volumes, where we have more than one attachments on the
> same host. By having the information stored in Cinder as well we can also 
> avoid removing a target when there are still active
> attachments connected to it.
> >
> > What do you think?
> >
> > Thanks,
> > Ildikó
> >
> >
> >> -Original Message-
> >> From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
> >> Sent: February 09, 2016 20:50
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: [openstack-dev] [Nova][Cinder] Multi-attach, determining
> >> when to call os-brick's connector.disconnect_volume
> >>
> >> Hey folks,
> >>  One of the challenges we have faced with the ability to attach a
> >> single volume to multiple instances, is how to correctly detach that
> >> volume.  The issue is a bit complex, but I'll try and explain the problem, 
> >> and then describe one approach to solving one part of the
> detach puzzle.
> >>
> >> Problem:
> >> When a volume is attached to multiple instances on the same host.
> >> There are 2 scenarios here.
> >>
> >> 1) Some Cinder drivers export a new target for every attachment
> >> on a compute host.  This means that you will get a new unique volume path 
> >> on a host, which is then handed off to the VM
> instance.
> >>
> >> 2) Other Cinder drivers export a single target for all instances
> >> on a compute host.  This means that every instance on a single host, will 
> >> reuse the same host volume path.
> >>
> >>
> >> When a user issues a request to detach a volume, the workflow boils
> >> down to first calling os-brick's connector.disconnect_volume before
> >> calling Cinder's terminate_connection and detach. disconnect_volume's job 
> >> is to remove the local volume from the host OS and
> close any sessions.
> >>
> >> There is no problem under scenario 1.  Ea

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

[Ildikó Váncsa]

Hi All,

I wonder whether we could provide an interface on the API where these kind of 
capabilities can be retrieved? I know we have a support matrix in the 
documentation that's good to have. I asked the question, because here we have a 
base functionality, which is attaching a volume that Cinder exports. The 
multiattach feature is an extension to this, which is provided by Cinder and we 
wire it into Nova to provide this functionality for the instances. It's not a 
question that the API behavior will change by this, but it's more the matter of 
the components that allows the multiple attachments. In this sense the API 
microversion does not provide too much information standalone, it can only say 
that if you have all the good drivers set up in your environment, then you can 
use it. But do we have a way to check this?

Also in order to be able to introduce multiattach in the N cycle there are two 
patches that we have to land for Mitaka [1] [2]. [1] prepares the detach 
mechanism to send all the information to Cinder in order to identify the right 
attachment. This means to pass the attachment_id to Cinder. In case of an 
upgrade when we can have old and new components in the system it is important 
that if a new component attaches a volume for the second time then the detach 
called on the old one can be executed properly. [2] is need for Cinder as some 
of the drivers need the host information for tracking the attachments of the 
same volume on the same host properly.

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: January 14, 2016 17:11
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][cinder] How will nova advertise that 
> volume multi-attach is supported?
> 
> 
> 
> On 1/14/2016 9:42 AM, Dan Smith wrote:
> >> It is however not ideal when a deployment is set up such that
> >> multiattach will always fail because a hypervisor is in use which
> >> doesn't support it.  An immediate solution would be to add a policy
> >> so a deployer could disallow it that way which would provide
> >> immediate feedback to a user that they can't do it.  A longer term
> >> solution would be to add capabilities to flavors and have flavors act
> >> as a proxy between the user and various hypervisor capabilities
> >> available in the deployment.  Or we can focus on providing better
> >> async feedback through instance-actions, and other discussed async api 
> >> changes.
> >
> > Presumably a deployer doesn't enable volumes to be set as multi-attach
> > on the cinder side if their nova doesn't support it at all, right? I
> > would expect that is the gating policy element for something global.
> 
> There is no policy in cinder to disallow creating multiattach-able volumes 
> [1]. It's just a property on the volume and somewhere in
> cinder the volume drivers support the capability or not.
> 
>  From a very quick look at the cinder code, the scheduler has a capabilities 
> filter for multiattach so if you try to create a multiattach
> volume and don't have any hosts (volume backends) that support that, you'd 
> fail to create the volume with NoValidHost.
> 
> But lvm supports it, so if you have an lvm backend you can create the 
> multiattach volume, that doesn't mean you can use it in nova. So
> it seems like you'd also need the same kind of capabilities filter in the 
> nova scheduler for this and that capability from the compute
> host would come from the virt driver, of which only libvirt is going to 
> support it at first.

Do I understand correctly that you mean that we would specify at VM creation 
time that it should go to a compute host where the hypervisor supports 
multiattach?

Thanks,
/Ildikó

[1] https://review.openstack.org/#/c/193134/ 
[2] https://review.openstack.org/#/c/256273/ 

> 
> >
> > Now, if multiple novas share a common cinder, then I guess it gets a
> > little more confusing...
> >
> > --Dan
> >
> > __
> >  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
> >
> 
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L407
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> 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] [Neutron][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi All,

We will have a chat about the feature regarding design and next steps at the 
contributors' meet-up on Friday at 10am.

https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track

Best Regards,
Ildikó
(IRC: ildikov)

> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: October 22, 2015 10:15
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Bence Romsics; Petr Savelyev
> Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN aware 
> VMs)
> 
> Hi Armando,
> 
> Great, thank you for the pointers and hints. I will contact Rossella to move 
> forward with the process and implementation.
> 
> Best Regards,
> /Ildikó
> 
> > -Original Message-
> > From: Armando M. [mailto:arma...@gmail.com]
> > Sent: October 22, 2015 01:00
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: Bence Romsics; Petr Savelyev
> > Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN
> > aware VMs)
> >
> >
> >
> > On 21 October 2015 at 15:40, Ildikó Váncsa <ildiko.van...@ericsson.com> 
> > wrote:
> >
> >
> > Hi Folks,
> >
> > During Liberty we started the implementation of the VLAN aware VMs
> > blueprint (https://review.openstack.org/#/c/94612/). We had quite a
> > good progress, although we could use some extra hands on Neutron side and 
> > some thoughts on the Nova-Neutron interaction
> aspect of the feature.
> >
> > The status of the code can be checked here:
> >
> > https://review.openstack.org/#/q/status:open+project:openstack/neutron
> > +branch:master+topic:bp/vlan-aware-
> > vms,n,z
> >
> > https://review.openstack.org/#/q/status:open+project:openstack/python-
> > neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
> > https://review.openstack.org/#/c/213120/
> > The spec proposed for Nova can be found here:
> > https://review.openstack.org/#/c/213644/
> >
> >
> > We also added a note to the corresponding cross-project session to 
> > discuss further the impacts of this feature on Nova:
> > 
> > https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
> >
> > https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-int
> > egration
> >
> > If you are interested in this feature and would like to help out
> > please let me know. If you will be in Tokyo, we can catch up during/after 
> > the cross-project session or set up a separate discussion to
> move forward and speed up the feature implementation.
> >
> >
> >
> > Hi,
> >
> > Thanks for the email. We discussed blueprint [1] during the last IRC
> > meeting [2] and based on our latest blueprint procedures [3], Rossella
> > has volunteered to help you through the process. She is going to be
> > the main point of contact for anything related to the feature. We'll watch 
> > the progress of the blueprint over the course of the cycle
> and the meeting participation is encouraged to raise/discuss blockers.
> >
> > HTH
> > Armando
> >
> > [1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> > [2]
> > http://eavesdrop.openstack.org/meetings/networking/2015/networking.201
> > 5-10-20-14.00.log.html [3]
> > http://docs.openstack.org/developer/neutron/policies/blueprints.html#n
> > eutron-request-for-feature-enhancements
> >
> >
> >
> > Thanks and Best Regards,
> > Ildikó
> > (IRC: ildikov)
> >
> > 
> > __
> > 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] [Nova][Cinder] Multi-attach volume help needed

[Ildikó Váncsa]

Hi Walt,

Yes, I am. I'm attending the Cinder-Nova session tomorrow, but we can catch up 
before/after, if your available.

Ildikó 

Sent from my iPad

> On 27 Oct 2015, at 16:03, Boring, Walter <walter.bor...@hpe.com> wrote:
> 
> Are you here at the Summit in Tokyo?
> 
> Walt
> 
> 
>> On Oct 21, 2015, at 11:31 AM, Ildikó Váncsa <ildiko.van...@ericsson.com> 
>> wrote:
>> 
>> Hi Folks,
>> 
>> The work has been ongoing for a while now to implement the feature to 
>> support attaching a single volume to multiple VM instances.
>> 
>> This work impacts both Nova and Cinder. We are in quite good shape with the 
>> implementation, but it is still far for completion and we temporarily ran 
>> out of resources and looking for hands to help out. We have the following 
>> items left:
>> 
>> * Cinder
>> * Blueprint implementation finished on server and client side too
>> * Volume detach has a bug, which makes the feature unusable at the moment. A 
>> proposed fix is up for review, but we couldn't reach a consensus yet 
>> regarding solution: https://review.openstack.org/#/c/198400/ 
>> 
>> * Nova
>> * Spec is re-proposed for Mitaka
>>   * https://review.openstack.org/#/c/212508/ 
>>   * Encryption needs to be sorted out
>> * Code for Nova side is up for review
>>   * 
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/volume-multi-attach,n,z
>>   * REST API is not finished
>>   * Needs rebase and code review
>> 
>> * Testing
>> * Tempest coverage is missing
>> * Manual/functional testing is missing
>> 
>> There will be a Nova - Cinder cross project session during the Summit, which 
>> can be a good opportunity to discuss the missing pieces and identified 
>> issues: 
>> https://mitakadesignsummit.sched.org/event/eb6adc828485d7bce0cba6654cc33156#.VifQYZeLJ4M
>>  
>> 
>> If you are interested in this feature, we could use some help in clarifying 
>> the encryption in the spec, fixing the Cinder bug, finish the Nova patches 
>> or adding Tempest coverage. If you would like to jump in and start with any 
>> tasks, please let me know. If you will be in Tokyo next week we can either 
>> meet on the session I linked above or we can set up a meeting separately to 
>> discuss how to move forward, otherwise we can discuss next steps in either 
>> mail or IRC.
>> 
>> Thanks and Best Regards,
>> Ildikó
>> (IRC: ildikov)
>> 
>> __
>> 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] [Neutron][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi Armando,

Great, thank you for the pointers and hints. I will contact Rossella to move 
forward with the process and implementation.

Best Regards,
/Ildikó

> -Original Message-
> From: Armando M. [mailto:arma...@gmail.com]
> Sent: October 22, 2015 01:00
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Bence Romsics; Petr Savelyev
> Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN aware 
> VMs)
> 
> 
> 
> On 21 October 2015 at 15:40, Ildikó Váncsa <ildiko.van...@ericsson.com> wrote:
> 
> 
>   Hi Folks,
> 
>   During Liberty we started the implementation of the VLAN aware VMs 
> blueprint
> (https://review.openstack.org/#/c/94612/). We had quite a good progress, 
> although we could use some extra hands on Neutron side
> and some thoughts on the Nova-Neutron interaction aspect of the feature.
> 
>   The status of the code can be checked here:
>   
> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-
> vms,n,z
>   https://review.openstack.org/#/q/status:open+project:openstack/python-
> neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
>   https://review.openstack.org/#/c/213120/
>   The spec proposed for Nova can be found here:
>   https://review.openstack.org/#/c/213644/
> 
> 
>   We also added a note to the corresponding cross-project session to 
> discuss further the impacts of this feature on Nova:
>   
> https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
>   
> https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration
> 
>   If you are interested in this feature and would like to help out please 
> let me know. If you will be in Tokyo, we can catch
> up during/after the cross-project session or set up a separate discussion to 
> move forward and speed up the feature implementation.
> 
> 
> 
> Hi,
> 
> Thanks for the email. We discussed blueprint [1] during the last IRC meeting 
> [2] and based on our latest blueprint procedures [3],
> Rossella has volunteered to help you through the process. She is going to be 
> the main point of contact for anything related to the
> feature. We'll watch the progress of the blueprint over the course of the 
> cycle and the meeting participation is encouraged to
> raise/discuss blockers.
> 
> HTH
> Armando
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [2] 
> http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-10-20-14.00.log.html
> [3] 
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> 
> 
> 
>   Thanks and Best Regards,
>   Ildikó
>   (IRC: ildikov)
> 
>   
> __
>   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-dev] [Nova][Cinder] Multi-attach volume help needed

[Ildikó Váncsa]

Hi Folks,

The work has been ongoing for a while now to implement the feature to support 
attaching a single volume to multiple VM instances.

This work impacts both Nova and Cinder. We are in quite good shape with the 
implementation, but it is still far for completion and we temporarily ran out 
of resources and looking for hands to help out. We have the following items 
left:

* Cinder
  * Blueprint implementation finished on server and client side too
  * Volume detach has a bug, which makes the feature unusable at the moment. A 
proposed fix is up for review, but we couldn't reach a consensus yet regarding 
solution: https://review.openstack.org/#/c/198400/ 

* Nova
  * Spec is re-proposed for Mitaka
* https://review.openstack.org/#/c/212508/ 
* Encryption needs to be sorted out
  * Code for Nova side is up for review
* 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/volume-multi-attach,n,z
* REST API is not finished
* Needs rebase and code review

* Testing
  * Tempest coverage is missing
  * Manual/functional testing is missing

There will be a Nova - Cinder cross project session during the Summit, which 
can be a good opportunity to discuss the missing pieces and identified issues: 
https://mitakadesignsummit.sched.org/event/eb6adc828485d7bce0cba6654cc33156#.VifQYZeLJ4M
 

If you are interested in this feature, we could use some help in clarifying the 
encryption in the spec, fixing the Cinder bug, finish the Nova patches or 
adding Tempest coverage. If you would like to jump in and start with any tasks, 
please let me know. If you will be in Tokyo next week we can either meet on the 
session I linked above or we can set up a meeting separately to discuss how to 
move forward, otherwise we can discuss next steps in either mail or IRC.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
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] [Neutron][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi Folks,

During Liberty we started the implementation of the VLAN aware VMs blueprint 
(https://review.openstack.org/#/c/94612/). We had quite a good progress, 
although we could use some extra hands on Neutron side and some thoughts on the 
Nova-Neutron interaction aspect of the feature.

The status of the code can be checked here:
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms,n,z
https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
https://review.openstack.org/#/c/213120/ 
The spec proposed for Nova can be found here:
https://review.openstack.org/#/c/213644/


We also added a note to the corresponding cross-project session to discuss 
further the impacts of this feature on Nova:
https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration 

If you are interested in this feature and would like to help out please let me 
know. If you will be in Tokyo, we can catch up during/after the cross-project 
session or set up a separate discussion to move forward and speed up the 
feature implementation.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
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] {Blazar]{Nova] Tokyo meetup and next steps

[Ildikó Váncsa]

Hi,

The upcoming OpenStack Summit in Tokyo is a great opportunity to discuss open 
questions, like resource management and resource reservation.

The Promise project in OPNFV is working on to identify the use cases and find a 
solution to this missing piece. For further information about this project 
please check the wiki page: https://wiki.opnfv.org/promise. You can find 
further information about our use cases and plans here: 
http://artifacts.opnfv.org/promise/PromiseResourceManagement.pdf.

We are trying to find a solution that can be integrated with OpenStack, 
therefore our primary interest is Blazar and the Nova scheduler activities.
If any of you is interested in resource reservation and/or in Blazar please let 
me know so that we can set up a meeting for next week to discuss further the 
possible solutions and tasks.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
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] [Ceilometer] Meeting cancelled for this week

[Ildikó Váncsa]

Hi All,

I would like to inform you that we cancel the Ceilometer meeting for this week 
in favor of Summit travels and preparation.

We finished to organize our sessions for next week, you can find the schedule 
here: https://mitakadesignsummit.sched.org/overview/type/ceilometer
The etherpads for the sessions are available here: 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Ceilometer

Best Regards,
Ildikó

__
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] [Blazar] Anyone interested?

[Ildikó Váncsa]

Hello,
>   It seems like an interesting project.
> 
>   On Fri, Aug 28, 2015 at 7:54 PM, Pierre 
> Riteau
> <prit...@uchicago.edu<mailto:prit...@uchicago.edu>> wrote:
>   Hello,
> 
>   The NSF-funded Chameleon project
> (https://www.chameleoncloud.org) uses Blazar to provide advance reservations 
> of resources for running cloud computing
> experiments.
> 
>   We would be interested in contributing 
> as well.
> 
>   Pierre Riteau
> 
>   On 28 Aug 2015, at 07:56, Ildikó Váncsa
> <<mailto:ildiko.van...@ericsson.com>ildiko.van...@ericsson.com<mailto:ildiko.van...@ericsson.com>>
>  wrote:
> 
>   > Hi All,
>   >
>   > The resource reservation topic pops 
> up time to time on
> different forums to cover use cases in terms of both IT and NFV. The Blazar 
> project was intended to address this need, but according
> to my knowledge due to earlier integration and other difficulties the work 
> has been stopped.
>   >
>   > My question is that who would be 
> interested in resurrecting
> the Blazar project and/or working on a reservation system in OpenStack?
>   >
>   > Thanks and Best Regards,
>   > Ildikó
>   >
>   >
> __
>   > OpenStack Development Mailing List 
> (not for usage
> questions)
>   > Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe<http://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://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<mailto: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-dev] [Blazar] Anyone interested?

[Ildikó Váncsa]

Hi All,

The resource reservation topic pops up time to time on different forums to 
cover use cases in terms of both IT and NFV. The Blazar project was intended to 
address this need, but according to my knowledge due to earlier integration and 
other difficulties the work has been stopped.

My question is that who would be interested in resurrecting the Blazar project 
and/or working on a reservation system in OpenStack?

Thanks and Best Regards,
Ildikó

__
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] [Monasca] Minutes for Monasca mid-cycle meetup

[Ildikó Váncsa]

Hi Roland,

Thanks for the meeting info.

Let me come back to you regarding the attendance of the next Monasca meeting. I 
messed up with time zones and slots a bit and I realized now that the slot is 
4pm UTC as opposed to 3pm UTC as I originally thought. I have a bi-weekly 
meeting in my calendar colliding with the upcoming slot, but for the past few 
occurrences it was cancelled, I need to check the next one with the organizer.

If I can attend, I can briefly talk about the componentization work.

Best Regards,
Ildikó

 -Original Message-
 From: Hochmuth, Roland M [mailto:roland.hochm...@hp.com]
 Sent: August 16, 2015 09:37
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup
 
 Hi Ildikó, That will be great if you can attend. If you do, would it be 
 possible for you to present an overview and current status/plans of
 the Ceilometer work around the componentization? I was at the discussion in 
 Vancouver on this, and several others from Monasca
 were there too, but I haven't stayed connected.
 
 The information for the Monasca Meetings as well as minutes is at, 
 https://wiki.openstack.org/wiki/Meetings/Monasca. If you have
 any problems connecting in, please let me know. We recently switched to 
 WebEx, which is hosted by Cisco. Everything should work,
 but if there are any problems we can switch to IRC.
 
 If Tuesday's at 4:00 PM UTC are problematic, then we would consider setting 
 up a separate time to cover this topic or move the
 Monasca meeting the following week.
 
 Regards --Roland
 
 
 
 On 8/14/15, 6:57 AM, Ildikó Váncsa ildiko.van...@ericsson.com wrote:
 
 Hi,
 
 I will try to join if I can, I have an overlapping meeting on Tuesdays.
 
 In general I think it would be really good to start a closer
 collaboration, the componentization work in Ceilometer gives a really
 good opportunity as Chris described.
 
 Best Regards,
 Ildikó
 
  -Original Message-
  From: Chris Dent [mailto:chd...@redhat.com]
  Sent: August 12, 2015 15:45
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle
 meetup
 
  On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
 
   It sounds like we should connect up soon. I could attend a
   Ceilometer meeting, or you could attend the Monasca meeting which
   is held Tuesday mornings at 9:00 MST.
 
  I'm away this coming Tuesday, but perhaps some of the other Ceilo
 people could show up? I've got it on my schedule to come the  week
 after.
 
  I suspect there's a lot we can do over the long run to avoid
 duplicating code and effort but that there will be some humps to ride
 over  to different pieces (and people!) talking to one another.
  Should be fun. Looking forward to it.
 
  --
  Chris Dent tw:@anticdent freenode:cdent
  https://tank.peermore.com/tanks/cdent
 
 
 __
 ___
 _
  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

Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup

[Ildikó Váncsa]

Hi Roland,

As I saw, the wiki says 4pm UTC too, please check it.

Thanks and Best Regards,
Ildikó

 -Original Message-
 From: Hochmuth, Roland M [mailto:roland.hochm...@hp.com]
 Sent: August 16, 2015 17:14
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup
 
 Ildikó, I think you are correct on the time. The meeting is at 3:00 PM UTC, 
 which is 9:00 AM MDT. Sorry, the time I mentioned was
 incorrect.
 Regards --Roland
 
 
 
 On 8/16/15, 7:42 AM, Ildikó Váncsa ildiko.van...@ericsson.com wrote:
 
 Hi Roland,
 
 Thanks for the meeting info.
 
 Let me come back to you regarding the attendance of the next Monasca
 meeting. I messed up with time zones and slots a bit and I realized now
 that the slot is 4pm UTC as opposed to 3pm UTC as I originally thought.
 I have a bi-weekly meeting in my calendar colliding with the upcoming
 slot, but for the past few occurrences it was cancelled, I need to
 check the next one with the organizer.
 
 If I can attend, I can briefly talk about the componentization work.
 
 Best Regards,
 Ildikó
 
  -Original Message-
  From: Hochmuth, Roland M [mailto:roland.hochm...@hp.com]
  Sent: August 16, 2015 09:37
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle
 meetup
 
  Hi Ildikó, That will be great if you can attend. If you do, would it
 be possible for you to present an overview and current status/plans of
 the Ceilometer work around the componentization? I was at the
 discussion in Vancouver on this, and several others from Monasca  were
 there too, but I haven't stayed connected.
 
  The information for the Monasca Meetings as well as minutes is at,
 https://wiki.openstack.org/wiki/Meetings/Monasca. If you have  any
 problems connecting in, please let me know. We recently switched to
 WebEx, which is hosted by Cisco. Everything should work,  but if there
 are any problems we can switch to IRC.
 
  If Tuesday's at 4:00 PM UTC are problematic, then we would consider
 setting up a separate time to cover this topic or move the  Monasca
 meeting the following week.
 
  Regards --Roland
 
 
 
  On 8/14/15, 6:57 AM, Ildikó Váncsa ildiko.van...@ericsson.com wrote:
 
  Hi,
  
  I will try to join if I can, I have an overlapping meeting on Tuesdays.
  
  In general I think it would be really good to start a closer
  collaboration, the componentization work in Ceilometer gives a
  really good opportunity as Chris described.
  
  Best Regards,
  Ildikó
  
   -Original Message-
   From: Chris Dent [mailto:chd...@redhat.com]
   Sent: August 12, 2015 15:45
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca
  mid-cycle meetup
  
   On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
  
It sounds like we should connect up soon. I could attend a
Ceilometer meeting, or you could attend the Monasca meeting
which is held Tuesday mornings at 9:00 MST.
  
   I'm away this coming Tuesday, but perhaps some of the other Ceilo
  people could show up? I've got it on my schedule to come the  week
  after.
  
   I suspect there's a lot we can do over the long run to avoid
  duplicating code and effort but that there will be some humps to
  ride over  to different pieces (and people!) talking to one another.
   Should be fun. Looking forward to it.
  
   --
   Chris Dent tw:@anticdent freenode:cdent
   https://tank.peermore.com/tanks/cdent
  
  
  ___
  ___
  ___
  _
   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

Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup

[Ildikó Váncsa]

Hi,

I will try to join if I can, I have an overlapping meeting on Tuesdays.

In general I think it would be really good to start a closer collaboration, the 
componentization work in Ceilometer gives a really good opportunity as Chris 
described.

Best Regards,
Ildikó

 -Original Message-
 From: Chris Dent [mailto:chd...@redhat.com]
 Sent: August 12, 2015 15:45
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup
 
 On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
 
  It sounds like we should connect up soon. I could attend a Ceilometer
  meeting, or you could attend the Monasca meeting which is held Tuesday
  mornings at 9:00 MST.
 
 I'm away this coming Tuesday, but perhaps some of the other Ceilo people 
 could show up? I've got it on my schedule to come the
 week after.
 
 I suspect there's a lot we can do over the long run to avoid duplicating code 
 and effort but that there will be some humps to ride over
 to different pieces (and people!) talking to one another.
 Should be fun. Looking forward to it.
 
 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent
 
 __
 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] [neutron] VLAN aware VMs: Current status?

[Ildikó Váncsa]

Hi Kyle,

First of all, sorry for the late response.

We are working on the design and implementation, the first patches are planned 
to be up by the end of this week.

We could surely use more hands as it is quite a large amount of work that this 
blueprint requires. If there are any Neutron experts who would and could help 
out we would appreciate it. We prepared a wiki page [1], which contains 
information about the plans and design, it also includes a link to tasks/work 
items. If anyone is willing to join to the implementation please ping me via 
mail or IRC (ildikov) so we can sync up regarding to the work items.

Thanks and Best Regards,
Ildikó

[1] https://wiki.openstack.org/wiki/Neutron/TrunkPort 

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: July 30, 2015 16:26
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron] VLAN aware VMs: Current status?
 
 I'm sending this email to solicit a response from the owners of the VLAN 
 aware VMs spec [1] [2]. The spec was merged on June 24,
 and I haven't seen any code posted. Given I expect this to take some 
 iterations in review, is the plan to push code for this sometime
 soon?
 
 
 Thanks!
 
 Kyle
 
 
 [1] https://review.openstack.org/#/c/94612/
 [2] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

__
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] [ceilometer] Aodh has been imported, next steps

[Ildikó Váncsa]

Hmm, as it is a change that affects the user, in my opinion it is still an API 
change.

Have we decided about the client, whether the alarming module will have a 
separate client or we will keep the current ceilometer-client? I guess more the 
latter one at least as a starting point, I just wanted to double check.

Ildikó 

Sent from my iPad

 On 30 Jun 2015, at 14:18, Julien Danjou jul...@danjou.info wrote:
 
 On Tue, Jun 30 2015, Ildikó Váncsa wrote:
 
 Will this be accessible in the same way as currently or it needs
 changes on client side?
 
 You may just need to pass more options to the client to force another
 endpoint to be used when talking to the alarming part.
 We could make this change in the client by default though.
 
 -- 
 Julien Danjou
 # Free Software hacker
 # http://julien.danjou.info

__
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] [ceilometer] Aodh has been imported, next steps

[Ildikó Váncsa]

Hi,

I think removing options from the API requires version bump. So if we plan to 
do this, that should be introduced in v3 as opposed to v2, which should remain 
the same and maintained for two cycles (assuming that we still have this policy 
in OpenStack). It this is achievable by removing the old code and relying on 
the new repo that would be the best, if not then we need to figure out how to 
freeze the old code.

Best Regards,
Ildikó

 -Original Message-
 From: Nadya Shakhat [mailto:nprival...@mirantis.com]
 Sent: June 29, 2015 21:52
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
 
 I'm afraid user experience will change because of API. Do we have a plan 
 about it?
 
 Will we interact with Aodh through ceilometer-api first? Or make user to go 
 to aodh-api service?
 
 So I agree with Gordon that code-cleanup is more preferred option because we 
 can't maintain two version simultaneously. But we
 need to think more about end users: is it appropriate just remove options 
 from ceilometer-api?
 
 
 On Mon, Jun 29, 2015 at 10:47 PM, gordon chung g...@live.ca wrote:
 
 
 
 
   On 29/06/2015 11:40 AM, Chris Dent wrote:
 
 
   On Mon, 29 Jun 2015, Julien Danjou wrote:
 
 
 
   Hi team,
 
   Aodh has been imported and is now available at:
 
https://git.openstack.org/cgit/openstack/aodh/
 
 
 
   woot!
 
 
 
   I'm pretty clear about the next steps for Aodh and what 
 we need to
   build, but something is still not clear to me. Do we go 
 ahead and bite
   the bullet and remove ceilometer-alarming from 
 ceilometer in Liberty?
 
 
 
   i think we should follow up with the packagers. if i understand 
 correctly, the location of the code is not known from a
 user pov, it's the packagers that build the appropriate packages for them to 
 use.
 
   if from packagers pov, they just need to work against Aodh, then i 
 would lean more to removing alarming from
 Ceilometer repo asap to avoid maintaining duplicate code bases and the 
 eventual diversion of the two.
 
 
 
 
   This is the big question and is one of the things listed on the
   potential agenda for the mid-cylce. When we do the splits do we
   deprecate or delete the old code. Given the high chance of us
   missing some of potential issues it seems like hasing it some 
 before
   the mid-cylce is a good idea.
 
   The two big overarching issues (that inform a lot of the 
 details)
   that I'm aware of are:
 
   * If we delete then we need to make sure we're working hand in 
 hand
 with all of: downstream packagers, tempest, grenade, devstack,
 etc.
 
   * If we deprecate will people bother to use the new stuff?
 
 
 
   i would think/hope the experience from end user doesn't actually 
 change. ie. all the same packaged services remain.
 
 
 
 
   I'm sure there are plenty of others.
 
 
 
 
   --
   gord
 
 
 
   
 __
   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] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi Kyle,

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: June 15, 2015 04:26
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
 
 On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa ildiko.van...@ericsson.com
 wrote:
 
 
   Hi,
 
 
 
   Since we reopened the review for this blueprint we’ve got a
 large number of comments. It can be clearly seen that the original proposal
 has to be changed, although it still requires some discussion to define a
 reasonable design that provides the desired feature and is aligned with the
 architecture and guidelines of Neutron. In order to speed up the process to
 fit into the Liberty timeframe, we would like to have a discussion about this.
 The goal is to discuss the alternatives we have, decide which to go on with
 and sort out the possible issues. After this discussion the blueprint will be
 updated with the desired solution.
 
 
 
   I would like to propose a time slot for _next Tuesday (06. 16.),
 17:00UTC – 18:00UTC_. I would like to have the discussion on the
 #openstack-neutron channel, that gives a chance to guys who might be
 interested, but missed this mail to attend. I tried to check the slot, but 
 please
 let me know if it collides with any Neutron related meeting.
 
 
 
 
 This looks to be fine. I would suggest that it may make more sense to have it
 in an #openstack-meeting channel, though we can certainly do a free-form
 chat in #openstack-neutron as well. I think the desired end-goal here should
 be to figure out any remaining nits that are being discussed on the spec so
 we can move forward in Liberty.
 

I wasn’t sure that it is a good idea to bring an unscheduled meeting to the 
meeting channels. Is it acceptable to hold an ad-hoc meeting there or does it 
have to be registered somewhere even if it's one occasion? As much as I saw the 
#openstack-meeting-4 channel is available although the list of meetings and the 
.ical file is not in sync, it's not taken in either. Should we try it there?

I agree with the desired outcome, so that we can start the implementation as 
soon as possible. I will try to send out an agenda before the meeting with the 
points that we should discuss.

Thanks and Best Regards,
Ildikó

 
 Thanks,
 
 Kyle
 
 
 
 
 
 
   Thanks and Best Regards,
 
   Ildikó
 
 
   ___
 ___
   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] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi Kyle,

Thanks for your support. Let's go for the meeting channel option then, so the 
final details for the tomorrow's meeting are:

Time: Tuesday (06. 16.), 17:00UTC - 18:00UTC
Location: #openstack-meeting-4

I will add a pointer to the agenda, when we have it!

Best Regards,
Ildikó

 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: June 15, 2015 15:52
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
 
 On Mon, Jun 15, 2015 at 7:40 AM, Ildikó Váncsa ildiko.van...@ericsson.com 
 wrote:
 
 
   Hi Kyle,
 
 
-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: June 15, 2015 04:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
   
On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa 
 ildiko.van...@ericsson.com
wrote:
   
   
  Hi,
   
   
   
  Since we reopened the review for this blueprint we’ve got a
large number of comments. It can be clearly seen that the original 
 proposal
has to be changed, although it still requires some discussion to 
 define a
reasonable design that provides the desired feature and is aligned 
 with the
architecture and guidelines of Neutron. In order to speed up the 
 process to
fit into the Liberty timeframe, we would like to have a discussion 
 about this.
The goal is to discuss the alternatives we have, decide which to go 
 on with
and sort out the possible issues. After this discussion the blueprint 
 will be
updated with the desired solution.
   
   
   
  I would like to propose a time slot for _next Tuesday (06. 16.),
17:00UTC – 18:00UTC_. I would like to have the discussion on the
#openstack-neutron channel, that gives a chance to guys who might be
interested, but missed this mail to attend. I tried to check the 
 slot, but please
let me know if it collides with any Neutron related meeting.
   
   
   
   
This looks to be fine. I would suggest that it may make more sense to 
 have it
in an #openstack-meeting channel, though we can certainly do a 
 free-form
chat in #openstack-neutron as well. I think the desired end-goal here 
 should
be to figure out any remaining nits that are being discussed on the 
 spec so
we can move forward in Liberty.
   
 
 
   I wasn’t sure that it is a good idea to bring an unscheduled meeting to 
 the meeting channels. Is it acceptable to hold an
 ad-hoc meeting there or does it have to be registered somewhere even if it's 
 one occasion? As much as I saw the #openstack-
 meeting-4 channel is available although the list of meetings and the .ical 
 file is not in sync, it's not taken in either. Should we try it
 there?
 
 
 
 
 I think as long as there isn't a scheduled meeting in place, we can use the 
 channel for a one-off meeting. It has the added benefit of
 being logged in the same way as other meetings, and we can focus the 
 discussion.
 
 
 
   I agree with the desired outcome, so that we can start the 
 implementation as soon as possible. I will try to send out an
 agenda before the meeting with the points that we should discuss.
 
 
 
 
 Perfect! I've added a note to the Neutron meeting for tomorrow [1] to 
 highlight this. If you get the agenda written, please add a
 pointer in the Neutron meeting agenda in the same place.
 
 [1] 
 https://wiki.openstack.org/wiki/Network/Meetings#Announcements_.2F_Reminders
 
 
 
   Thanks and Best Regards,
   Ildikó
 
   
Thanks,
   
Kyle
   
   
   
   
   
   
  Thanks and Best Regards,
   
  Ildikó
   
   
  ___
___
  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-dev] [Neutron] VLAN-aware VMs meeting

[Ildikó Váncsa]

Hi,

Since we reopened the review for this blueprint we've got a large number of 
comments. It can be clearly seen that the original proposal has to be changed, 
although it still requires some discussion to define a reasonable design that 
provides the desired feature and is aligned with the architecture and 
guidelines of Neutron. In order to speed up the process to fit into the Liberty 
timeframe, we would like to have a discussion about this. The goal is to 
discuss the alternatives we have, decide which to go on with and sort out the 
possible issues. After this discussion the blueprint will be updated with the 
desired solution.

I would like to propose a time slot for _next Tuesday (06. 16.), 17:00UTC - 
18:00UTC_. I would like to have the discussion on the #openstack-neutron 
channel, that gives a chance to guys who might be interested, but missed this 
mail to attend. I tried to check the slot, but please let me know if it 
collides with any Neutron related meeting.

Thanks and Best Regards,
Ildikó
__
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] [Zaqar][all] Zaqar will stay... Lots of work ahead

[Ildikó Váncsa]

Hi Ryan and Flavio,

Thanks for the quick response and the pointers, I will check out the reviews to 
catch up.

Best Regards,
Ildikó

 -Original Message-
 From: Ryan Brown [mailto:rybr...@redhat.com]
 Sent: June 01, 2015 16:34
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work 
 ahead
 
 On 06/01/2015 04:34 AM, Flavio Percoco wrote:
  On 31/05/15 18:12 +, Ildikó Váncsa wrote:
  Hi All,
 
  I would like to ask about the user-facing notifications part of the
  list. Do you have a roadmap for this? Is this driven by the Zaqar
  team? What are the next steps?
 
  Hey,
 
  This will require cross-project efforts and we (the Zaqar team) would
  love to get some help here. If anyone is willing to drive the spec and
  sync, the Zaqar team would be happy to help with other tasks.
 
  I think it'd be really beneficial to start doing it in one of the
  services (Heat?) as a PoC, while we discuss the cross-project spec and
  feed it with the things we'll learn from the PoC.
 
  Would you like to help with this?
 
 Indeed it will require tons of cross-project work. Heat is going to try to get
 Zaqar notifications to our users in Liberty, and I've posted specs for the
 message format side of the problem[1][2]. There is also a cross-project spec
 for user notifications[3].
 
 Heat plans on adopting this format after sufficient review, and we welcome
 other projects to look over the format and provide feedback to help it work
 for their use case as well.
 
 [1]: https://review.openstack.org/#/c/186436/
 [2]: https://review.openstack.org/#/c/186555/
 [3]: https://review.openstack.org/#/c/185822/
 
  ...[snip]...
 
 --
 Ryan Brown / Software Engineer, Openstack / Red Hat, 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

__
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] [Zaqar][all] Zaqar will stay... Lots of work ahead

[Ildikó Váncsa]

Hi All,

I would like to ask about the user-facing notifications part of the list. Do 
you have a roadmap for this? Is this driven by the Zaqar team? What are the 
next steps?

Thanks and Best Regards,
Ildikó

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com] 
Sent: May 27, 2015 18:42
To: openstack-dev
Subject: Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

Excerpts from Flavio Percoco's message of 2015-05-26 01:28:06 -0700:
 Greetings,
 
 TL;DR: Thanks everyone for your feedback. Based on the discussed plans 
 at the summit - I'll be writing more about these later - Zaqar will 
 stick around and play its role in the community.
 
 Summit Summary
 ==
 
 I'm happy to say that several use cases were discussed at the summit 
 and the difference from previous summits is that we left the room with 
 some action items to make them happen.
 
 Cross-project user-facing notifications 
 ===
 
 https://etherpad.openstack.org/p/liberty-cross-project-user-notificati
 ons
 
 Besides brainstorming a bit on what things should/should not be 
 notified and what format should be used, we also talked a bit about 
 the available technologies that could be used for this tasks. Zaqar 
 was among those and, AFAICT, at the end of the session we agreed on 
 giving this a try. It'll likely not happen as fast as we want but the 
 action item out of this session was to write a cross-project spec 
 describing the things discussed and the technology that will be 
 adopted.
 

My takeaway from that session was that there's need for something like yagi to 
filter the backend notifications into user-consumable tenant-scoped messages, 
and that Zaqar would be an interesting target for those messages along with 
Atom feeds or perhaps other pub/sub oriented things that deployers would be 
comfortable hosting for their users.

 Heat + Zaqar
 
 
 The 2 main areas where Zaqar will be used in Heat are Software Config 
 and Hooks. The minimum requirements (server side) for this are in 
 place already. There's some work to do on the client side that the 
 team will get to asap.
 

The bigger one to me is just user-notificiation which I think is covered in the 
cross project session, but it's worth noting that Heat is one of the projects 
that already does some user notification and suffers problems because of it 
(the events API is what I mean here).

 Next Steps
 ==
 
 In light of the above, and as mentioned in the TL;DR, Zaqar will stick 
 around and the team, as promised, will focus on making those 
 integrations happen. The team is small, which means we'll carefully 
 pick the tasks we'll be spending time on.
 
 As a first step, we should restore our meetings and get to work right 
 away. To favor our contributors in NZ, next week's meeting will be at
 21:00 UTC and we'll keep it at that time for 2 weeks.
 
 For the Zaqar team (and folks interested), I'll be sending out further 
 emails to sync on the work to do.
 
 Special thanks for all the folks that showed interest, participated in 
 sessions and that are committed on making this happen.
 

Thanks for setting things up for success before the summit. I think we all went 
into the discussions with an open mind because we knew where the team stood.


== Crazy idea section ==

One thing I never had a chance to discuss with any of the Zaqar devs that I 
would find interesting is an email-only backend for Zaqar. Basically make Zaqar 
an HTTP-to-email gateway. There are quite a few hyper-scale options for SMTP 
and IMAP, and they're inherently multi-tenant, so I'd find it interesting to 
see if the full Zaqar API could be mapped onto that. This would probably be 
more comfortable to scale for some deployers than Redis or MongoDB, and might 
have the nice side-effect that a deployer could expose IMAP IDLE for efficient 
end-user subscription, and it could also allow Zaqar to serve as 
email-as-a-service for senders too (to prevent getting all your vms' IPs added 
to spam lists overnight. ;)

__
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] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty?

[Ildikó Váncsa]

Hi All,

Thanks for showing interest in this feature proposal. Some additional info to 
what Erik mentioned below:

The blueprint patch will soon be updated to target the Liberty release: 
https://review.openstack.org/#/c/94612/ 

There will also be a design summit session about this topic on Wednesday 11:00 
- 11:40: VLAN Aware VMs. You can reach the corresponding etherpad here: 
https://etherpad.openstack.org/p/YVR-neutron-vlan-trunk 
We're going to discuss use cases that are not covered by the VLAN trunking 
feature 
(https://github.com/openstack/neutron-specs/blob/master/specs/kilo/nfv-vlan-trunks.rst)
 added in the Kilo release.

Best Regards,
Ildikó


-Original Message-
From: Erik Moe [mailto:erik@ericsson.com] 
Sent: May 12, 2015 21:14
To: OpenStack Development Mailing List (not for usage questions)
Cc: Petr Savelyev
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?


Hi All,

Great! In my view it looks like a lot of interest in this.

Now some other news, after more internal discussions it now looks like I will 
not work with this. Petr Savelyev will take over from Ericsson side.

I wish him the best of luck!

Thanks,
Erik


-Original Message-
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: den 12 maj 2015 20:21
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

Hi Erik,

Mellanox is also interested in it but for  ML2 plugin with and sriov-nic-switch 
mechanism driver.
I planning to do agent support for the sriov-nic-switch (when the driver will 
support it), but if you need help in other places I can also pitch in.


-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Friday, May 08, 2015 8:23 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

On 05/08/2015 09:29 AM, Erik Moe wrote:
 Hi,

 I have not been able to work with upstreaming of this for some time now.
 But now it looks like I may make another attempt. Who else is 
 interested in this, as a user or to help contributing? If we get some 
 traction we can have an IRC meeting sometime next week.

Hi Erik,

Mirantis has interest in this functionality, and depending on the amount of 
work involved, we could pitch in...

Please cc me or add me to relevant reviews and I'll make sure the right folks 
are paying attention.

All the best,
-jay

 *From:*Scott Drennan [mailto:sco...@nuagenetworks.net]
 *Sent:* den 4 maj 2015 18:42
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] [neutron]Anyone looking at support for 
 VLAN-aware VMs in Liberty?

 VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I 
 don't see any work on VLAN-aware VMs for Liberty.  There is a 
 blueprint[1] and specs[2] which was deferred from Kilo - is this 
 something anyone is looking at as a Liberty candidate?  I looked but 
 didn't find any recent work - is there somewhere else work on this is 
 happening?  No-one has listed it on the liberty summit topics[3] 
 etherpad, which could mean it's uncontroversial, but given history on 
 this, I think that's unlikely.

 cheers,

 Scott

 [1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

 [2]: https://review.openstack.org/#/c/94612

 [3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics



 __
  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

Re: [openstack-dev] [ceilometer] time based auto scaling

[Ildikó Váncsa]

Hi,

I like the base idea to trigger scaling based on other information than what we 
have from the current Ceilometer alarms.

Although I think this functionality should live somewhere else than under the 
responsibility of Ceilometer. This type of scaling is usually based on trend 
analysis and other application specific data, which is out of the scope for 
Ceilometer, even if it has the capability of triggering Heat.

Best Regards,
Ildiko

Feladó: Julien Danjou [jul...@danjou.info]
Küldve: 2015. április 29. 9:29
Címzett: ZhiQiang Fan
Másolatot kap: OpenStack Development Mailing List
Tárgy: Re: [openstack-dev] [ceilometer] time based auto scaling

On Wed, Apr 29 2015, ZhiQiang Fan wrote:

 However, current ceilometer only provide time constraint alarm, which will
 only evaluate but not guarantee it will be triggered. And heat cannot
 provide something like timer, but just can wait for the signal.

 So I propose to add a new type of alarm, which will definitely send a
 signal to action when it is evaluated (with or without repeat, it will work
 well with time constraint)

 Any suggestion?

I've proposed exactly that around 18-24 years go I think during a
summit, and nobody was really interested back then and was worried to
have yet another cron system – though OpenStack didn't have one.

I still think it's a good idea and it will be a nice addition to the
alarming system, so if you want to write a spec for that I'll be all
yours. :)

--
Julien Danjou
# Free Software hacker
# http://julien.danjou.info

__
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] [Ceilometer] Meters vs. Metrics

[Ildikó Váncsa]

Hi All,

Thanks for the heads up regarding to this inconsistency of terms in the docs. I 
will open a bug for it and target both Ceilometer and OS Manuals to get it 
corrected everywhere.

Best Regards,
Ildikó

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Wednesday, March 25, 2015 1:14 PM
To: Tim Bell
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

On Wed, Mar 25 2015, Tim Bell wrote:

 Unfortunately, this is a cause of confusion for the users. Do you have 
 a reference to the differences in the concepts ?

There's a glossary here:
  http://docs.openstack.org/developer/ceilometer/glossary.html

 The ceilometer doc does also have this confusion in some places, for 
 example, 
 http://docs.openstack.org/developer/ceilometer/measurements.html mixes 
 the terms.

Agreed, that's a bug, it should be meter.

--
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info

__
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] [Ceilometer] Adding Dina Belova to ceilometer-core

[Ildikó Váncsa]

Hi,

+1 from me too, thanks for all the hard work so far.

Best Regards,
Ildikó

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Thursday, September 11, 2014 3:25 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

Hi,

Dina has been doing a great work and has been very helpful during the Juno 
cycle and her help is very valuable. She's been doing a lot of reviews and has 
been very active in our community.

I'd like to propose that we add Dina Belova to the ceilometer-core group, as 
I'm convinced it'll help the project.

Please, dear ceilometer-core members, reply with your votes!

--
Julien Danjou
// Free Software hacker
// http://julien.danjou.info

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

[Ildikó Váncsa]

Hi,

+1 from me, and thanks for the nice work so far.

Best Regards,
Ildikó

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Wednesday, September 10, 2014 12:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

Hi,

Nejc has been doing a great work and has been very helpful during the Juno 
cycle and his help is very valuable.

I'd like to propose that we add Nejc Saje to the ceilometer-core group.

Please, dear ceilometer-core members, reply with your votes!

--
Julien Danjou
// Free Software hacker
// http://julien.danjou.info

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

[Ildikó Váncsa]

Hi,

I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh 
trusty too, everything worked fine…

Cheers,
Ildikó

From: Dina Belova [mailto:dbel...@mirantis.com]
Sent: Friday, August 22, 2014 11:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically 
because of wsme autodoc extension

Gordon, exactly. Moreover, I think percentage of failings is something close to 
the 15-20% of all the runs - sometimes it passes for the change, and next run 
on this exactly the same commit will be the failed for some reason.

Thanks
Dina

On Thu, Aug 21, 2014 at 10:46 PM, gordon chung 
g...@live.camailto:g...@live.ca wrote:
is it possible that it's not on all the nodes?

seems like it passed here: https://review.openstack.org/#/c/109207/ but another 
patch at roughly the same time failed https://review.openstack.org/#/c/113549/

cheers,
gord

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Test Ceilometer polling in tempest

[Ildikó Váncsa]

Hi Matt,

Thanks for the reply, please see my comments inline.

Best Regards,
Ildiko

-Original Message-
From: Matthew Treinish [mailto:mtrein...@kortar.org] 
Sent: Thursday, July 24, 2014 6:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [qa] Test Ceilometer polling in tempest

On Wed, Jul 16, 2014 at 07:44:38PM +0400, Dina Belova wrote:
 Ildiko, thanks for starting this discussion.
 
 Really, that is quite painful problem for Ceilometer and QA team. As 
 far as I know, currently there is some kind of tendency of making 
 integration Tempest tests quicker and less resource consuming - that's 
 quite logical IMHO. Polling as a way of information collecting from 
 different services and projects is quite consuming speaking about load 
 on Nova API, etc. - that's why I completely understand the wish of QA 
 team to get rid of it, although polling still makes lots work inside 
 Ceilometer, and that's why integration testing for this feature is 
 really important for me as Ceilometer contributor - without pollsters 
 testing we have no way to check its workability.
 
 That's why I'll be really glad if Ildiko's (or whatever other) 
 solution that will allow polling testing in the gate will be found and 
 accepted.
 
 Problem with described above solution requires some kind of change in 
 what do we call environment preparing for the integration testing - 
 and we really need QA crew help here. Afair polling deprecation was 
 suggested in some of the IRC discussions (by only notifications 
 usage), but that's not the solution that might be just used right now 
 - but we need way of Ceilometer workability verification right now to 
 continue work on its improvement.
 
 So any suggestions and comments are welcome here :)
 
 Thanks!
 Dina
 
 
 On Wed, Jul 16, 2014 at 7:06 PM, Ildikó Váncsa 
 ildiko.van...@ericsson.com
 wrote:
 
   Hi Folks,
 
 
 
  We’ve faced with some problems during running Ceilometer integration 
  tests on the gate. The main issue is that we cannot test the polling 
  mechanism, as if we use a small polling interval, like 1 min, then 
  it puts a high pressure on Nova API. If we use a longer interval, 
  like 10 mins, then we will not be able to execute any tests 
  successfully, because it would run too long.
 
 
 
  The idea, to solve this issue,  is to reconfigure Ceilometer, when 
  the polling is tested. Which would mean to change the polling 
  interval from the default 10 mins to 1 min at the beginning of the 
  test, restart the service and when the test is finished, the polling 
  interval should be changed back to 10 mins, which will require one 
  more service restart. The downside of this idea is, that it needs 
  service restart today. It is on the list of plans to support dynamic 
  re-configuration of Ceilometer, which would mean the ability to change the 
  polling interval without restarting the service.
 
 
 
  I know that this idea isn’t ideal from the PoV that the system 
  configuration is changed during running the tests, but this is an 
  expected scenario even in a production environment. We would change 
  a parameter that can be changed by a user any time in a way as users 
  do it too. Later on, when we can reconfigure the polling interval 
  without restarting the service, this approach will be even simpler.

So your saying that you expect users to be able to manually reconfigure 
Ceilometer on the fly to be able to use polling, that seems far from ideal.

ildikov: Sorry, maybe I wasn't 100% clear in my original mail. So polling will 
work out of the box after you installed Ceilometer with the default 
configuration. But it can happen that someone is not satisfied with the default 
values, like he/she needs samples from polling in every minute instead of every 
10 minutes. In this case the polling interval should be modified in one of the 
configuration files (pipeline.yaml) and then the affected services should be 
restarted. But if someone is happy with the 10 mins polling interval, then 
he/she does not have to do anything to make it work. Later on we plan to use 
some automation, so that the polling interval could be configured without 
restarting the services, which would make the user's life a bit easier.

 
 
 
  This idea would make it possible to test the polling mechanism of 
  Ceilometer without any radical change in the ordering of test cases 
  or any other things that would be strange in integration tests. We 
  couldn’t find any better way to solve the issue of the load on the APIs 
  caused by polling.
 
 
 
  What’s your opinion about this scenario? Do you think it could be a 
  viable solution to the above described problem?
 
 
 

Umm, so frankly this approach seems kind of crazy to me. Aside from the project 
level implications of saying that as a user to ensure you can't use polling 
data reliably unless you adjust the polling frequency of Ceilometer. The bigger 
issue is that you're

[openstack-dev] [qa] Test Ceilometer polling in tempest

[Ildikó Váncsa]

Hi Folks,

We've faced with some problems during running Ceilometer integration tests on 
the gate. The main issue is that we cannot test the polling mechanism, as if we 
use a small polling interval, like 1 min, then it puts a high pressure on Nova 
API. If we use a longer interval, like 10 mins, then we will not be able to 
execute any tests successfully, because it would run too long.

The idea, to solve this issue,  is to reconfigure Ceilometer, when the polling 
is tested. Which would mean to change the polling interval from the default 10 
mins to 1 min at the beginning of the test, restart the service and when the 
test is finished, the polling interval should be changed back to 10 mins, which 
will require one more service restart. The downside of this idea is, that it 
needs service restart today. It is on the list of plans to support dynamic 
re-configuration of Ceilometer, which would mean the ability to change the 
polling interval without restarting the service.

I know that this idea isn't ideal from the PoV that the system configuration is 
changed during running the tests, but this is an expected scenario even in a 
production environment. We would change a parameter that can be changed by a 
user any time in a way as users do it too. Later on, when we can reconfigure 
the polling interval without restarting the service, this approach will be even 
simpler.

This idea would make it possible to test the polling mechanism of Ceilometer 
without any radical change in the ordering of test cases or any other things 
that would be strange in integration tests. We couldn't find any better way to 
solve the issue of the load on the APIs caused by polling.

What's your opinion about this scenario? Do you think it could be a viable 
solution to the above described problem?

Thanks and Best Regards,
Ildiko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer]Collector's performance

[Ildikó Váncsa]

Hi Nadya,

You mentioned multiple DB backends in your mail. Which one did you use to 
perform these tests or did you get the same/similar performance results in case 
of both?

Best Regards,
Ildiko

From: Nadya Privalova [mailto:nprival...@mirantis.com]
Sent: Tuesday, March 11, 2014 6:05 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Ceilometer]Collector's performance

Hi team!
Last week we were working on notification problem in ceilometer during tempest 
tests creation. Tests for notification passed successfully on Postgres but 
failed on MySQL. This made us start investigations and this email contains some 
results.
As it turned out, tempest as it is is something like performance-testing for 
Ceilometer. It contains 2057 tests. Almost in all test OpenStack resources are 
being created and deleted: images, instances, volumes. E.g. during instance 
creation nova sends 9 notifications. And all the tests are running in parallel 
for about 40 minutes.
From ceilometer-collector logs we may found very useful message:

2014-03-10 
09:42:41.356http://logs.openstack.org/36/64136/20/check/check-tempest-dsvm-full/e361520/logs/screen-ceilometer-collector.txt.gz#_2014-03-10_09_42_41_356
 22845 DEBUG ceilometer.dispatcher.database 
[req-16ea95c5-6454-407a-9c64-94d5ef900c9e - - - - -] metering data 
storage.objects.outgoing.bytes for b7a490322e65422cb1129b13b49020e6 @ 
2014-03-10T09:34:31.090107:
So collector starts to process_metering_data in dispatcher only in 9:42 but 
nova sent it in 9:34. To look at whole picture please take look at picture [1]. 
It illustrates time difference based on this message in logs.
Besides, I decided to take a look on difference between the RPC-publisher sends 
the message and the collector receives the message. To create this plot I've 
parsed the lines like below from anotifications log:


2014-03-10 
09:25:49.333http://logs.openstack.org/36/64136/20/check/check-tempest-dsvm-full/e361520/logs/screen-ceilometer-anotification.txt.gz#_2014-03-10_09_25_49_333
 22833 DEBUG ceilometer.openstack.common.rpc.amqp [-] UNIQUE_ID is 
683dd3f130534b9fbb5606aef862b83d.





After that I found the corresponding id in collector log:

2014-03-10 
09:25:49.352http://logs.openstack.org/36/64136/20/check/check-tempest-dsvm-full/e361520/logs/screen-ceilometer-collector.txt.gz#_2014-03-10_09_25_49_352
 22845 DEBUG ceilometer.openstack.common.rpc.amqp [-] received 
{u'_context_domain': None, u'_context_request_id': 
u'req-0a5fafe6-e097-4f90-a68a-a91da1cff22c',




u'args': {u'data': [...,
 u'message_id': u'f7ad63fc-a835-11e3-8223-bc764e205385', u'counter_type': 
u'gauge'}]}, u'_context_read_only': False, u'_unique_id': 
u'683dd3f130534b9fbb5606aef862b83d',




u'_context_user_identity': u'- - - - -', u'_context_instance_uuid': None, 
u'_context_show_deleted': False, u'_context_tenant': None, 
u'_context_auth_token': 'SANITIZED',




} _safe_log 
/opt/stack/new/ceilometer/ceilometer/openstack/common/rpc/common.py:280
So in the example above we see time-difference only in 20 milliseconds. But it 
grows very quickly :( To see it please take a look on picture [2].
To summarize pictures:
1. Picture 1: Axis Y: amount of seconds between nova creates notification and 
the collector retrieves the message. Axis X: timestamp
2. Picture 2: Axis Y: amount of seconds between the publisher publishes the 
message and the collector retrieves the message. Axis X: timestamp
These pictures are almost the same and it makes me think that collector cannot 
manage with big amount of messages. What do you think about it? Do you agree or 
you need more evidences, e.g. amount of messages in rabbit or amth else?
Let's discuss that in [Ceilometer] topic first, I will create a new thread 
about testing strategy in tempest later. Because in this circumstances we 
forced to refuse from created notification tests and cannot reduce time for 
polling because it will make everything even worst.

[1]: http://postimg.org/image/r4501bdyb/
[2]: http://postimg.org/image/yy5a1ste1/

Thanks for your attention,
Nadya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Complex query API design

[Ildikó Váncsa]

Hi Ceilometer guys,

We are implementing a complex query functionality for Ceilometer. We got a 
comment to our implementation that using JSON in a string for representing the 
query filter expression, is probably not the best solution.

The description of our current API design can be found here: 
https://wiki.openstack.org/wiki/Ceilometer/ComplexFilterExpressionsInAPIQueries.
The review of the patch is available here: 
https://review.openstack.org/#/c/62157/11.

It would be good, if we could reach a consensus about this design question, 
that is why I thought to start a discussion about this on the mailing list 
first and I also add an item about this to the next week's meeting agenda of 
Ceilometer. Any comments are very welcomed.

Best Regards,
Ildiko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

[Ildikó Váncsa]

Hi,

In my opinion it would be better to let the user to define a ttl value for 
his/her own samples. I do not see the use case, where it is needed to delete 
samples, also if the user is able to randomly delete some data, then the 
statistics functions will not generate a valid output for that data set, which 
was affected by the deletion. As the original question was about testing, I do 
not have a deeper knowledge about how testing works now regarding to generating 
and storing the samples. Maybe if there is a need for deleting data there, it 
can be considered that how we can handle that particular case.

How would we identify the samples, which should be deleted? If it is allowed to 
delete any samples from the system via the API, it does not sound good either. 
So if it is an all or nothing situation, I would say nothing.

Best Regards,
Ildiko

-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: Friday, January 17, 2014 1:35 PM
To: Nadya Privalova
Cc: fuel-...@lists.launchpad.net; OpenStack Development Mailing List (not for 
usage questions); Vladimir Kuklin
Subject: Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters 
and samples delete

On Fri, Jan 17 2014, Nadya Privalova wrote:

 I would ask in another way.
 Ceilometer has a mechanism to add a sample through POST. So it looks 
 not consistent not to allow user to delete a sample.
 IMHO, insertion and deletion through REST looks a little bit hacky: 
 user always has an ability to fake data collected from OpenStack 
 services. But maybe I don't see any valuable usecases.
 Anyway, it seems reasonable to have both add_sample and delete_sample 
 in API or not to have neither.

From the user PoV, that totally makes sense, agreed.

--
Julien Danjou
# Free Software hacker # independent consultant # http://julien.danjou.info

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Ildikó Váncsa]

Hi,

I've started to work on the idea of supporting a kind of tenant/project based 
configuration for Ceilometer. Unfortunately I haven't reached the point of 
having a blueprint that could be registered until now. I do not have a deep 
knowledge about the collector and compute agent services, but this feature 
would require some deep changes for sure. Currently there are pipelines for 
data collection and transformation, where the counters can be specified, about 
which data should be collected and also the time interval for data collection 
and so on. These pipelines can be configured now globally in the pipeline.yaml 
file, which is stored right next to the Ceilometer configuration files.

In my view, we could keep the dynamic meter configuration bp with considering 
to extend it to dynamic configuration of Ceilometer, not just the meters and we 
could have a separate bp for the project based configuration of meters.

If it is ok for you, I will register the bp for this per-project tenant 
settings with some details, when I'm finished with the initial design of how 
this feature could work.

Best Regards,
Ildiko

-Original Message-
From: Neal, Phil [mailto:phil.n...@hp.com] 
Sent: Tuesday, January 07, 2014 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

For multi-node deployments, implementing something like inotify would allow 
administrators to push configuration changes out to multiple targets using 
puppet/chef/etc. and have the daemons pick it up without restart. Thumbs up to 
that.

As Tim Bell suggested, API-based enabling/disabling would allow users to update 
meters via script, but then there's the question of how to work out the global 
vs. per-project tenant settings...right now we collect specified meters for all 
available projects, and the API returns whatever data is stored minus filtered 
values. Maybe I'm missing something in the suggestion, but turning off 
collection for an individual project seems like it'd require some deep changes.

Vijay, I'll repeat dhellmann's request: do you have more detail in another doc? 
:-)

-   Phil

 -Original Message-
 From: Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) 
 [mailto:vijayakumar.kodam@nsn.com]
 Sent: Tuesday, January 07, 2014 2:49 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: chmo...@enovance.com
 Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
 From: ext Chmouel Boudjnah [mailto:chmo...@enovance.com]
 Sent: Monday, January 06, 2014 2:19 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
 
 
 
 
 
 On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata 
 Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.com wrote:
 
 In this case, simply changing the meter properties in a configuration 
 file should be enough. There should be an inotify signal which shall 
 notify ceilometer of the changes in the config file. Then ceilometer 
 should automatically update the meters without restarting.
 
 
 
 Why it cannot be something configured by the admin with inotifywait(1) 
 command?
 
 
 
 Or this can be an API call for enabling/disabling meters which could 
 be more useful without having to change the config files.
 
 
 
 Chmouel.
 
 
 
 I haven't tried inotifywait() in this implementation. I need to check 
 if it will be useful for the current implementation.
 
 Yes. API call could be more useful than changing the config files manually.
 
 
 
 Thanks,
 
 VijayKumar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Ildikó Váncsa]

Hi Doug,

Answers inline again.

Best Regards,
Ildiko

On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa 
ildiko.van...@ericsson.commailto:ildiko.van...@ericsson.com wrote:
Hi,

I've started to work on the idea of supporting a kind of tenant/project based 
configuration for Ceilometer. Unfortunately I haven't reached the point of 
having a blueprint that could be registered until now. I do not have a deep 
knowledge about the collector and compute agent services, but this feature 
would require some deep changes for sure. Currently there are pipelines for 
data collection and transformation, where the counters can be specified, about 
which data should be collected and also the time interval for data collection 
and so on. These pipelines can be configured now globally in the pipeline.yaml 
file, which is stored right next to the Ceilometer configuration files.

Yes, the data collection was designed to be configured and controlled by the 
deployer, not the tenant. What benefits do we gain by giving that control to 
the tenant?

ildikov: Sorry, my explanation was not clear. I meant there the configuration 
of data collection for projects, what was mentioned by Tim Bell in a previous 
email. This would mean that the project administrator is able to create a data 
collection configuration for his/her own project, which will not affect the 
other project's configuration. The tenant would be able to specify meters 
(enabled/disable based on which ones are needed) for the given project also 
with project specific time intervals, etc.

OK, I think some of the confusion is terminology. Who is a project 
administrator? Is that someone with access to change ceilometer's 
configuration file directly? Someone with a particular role using the API? Or 
something else?

ildikov: As project administrator I meant a user with particular role, a user 
assigned to a tenant.




In my view, we could keep the dynamic meter configuration bp with considering 
to extend it to dynamic configuration of Ceilometer, not just the meters and we 
could have a separate bp for the project based configuration of meters.

Ceilometer uses oslo.config, just like all of the rest of OpenStack. How are 
the needs for dynamic configuration updates in ceilometer different from the 
other services?

ildikov: There are some parameters in the configuration file of Ceilometer, 
like log options and notification types, which would be good to be able to 
configure them dynamically. I just wanted to reflect to that need. As I see, 
there are two options here. The first one is to identify the group of the 
dynamically modifiable parameters and move them to the API level. The other 
option could be to make some modifications in oslo.config too, so other 
services also could use the benefits of dynamic configuration. For example the 
log settings could be a good candidate, as for example the change of log 
levels, without service restart, in case debugging the system can be a useful 
feature for all of the OpenStack services.

I misspoke earlier. If we're talking about meters, those are actually defined 
by the pipeline file (not oslo.config). So if we do want that file re-read 
automatically, we can implement that within ceilometer itself, though I'm still 
reluctant to say we want to provide API access for modifying those settings. 
That's *really* not something we've designed the rest of the system to 
accommodate, so I don't know what side-effects we might introduce.

ildikov: In case of oslo.config, I meant the ceilometer.conf file in my answer 
above, not pipeline.yaml. As for the API part, I do not know the consequences 
of that implementation either, so now I'm kind of waiting for the outcome of 
this Dynamic Meters bp.

As far as the other configuration settings, we had the conversation about 
updating those through some sort of API early on, and decided that there are 
already lots of operational tools out there to manage changes to those files. I 
would need to see a list of which options people would want to have changed 
through an API to comment further.

ildikov: Yes, I agree that not all the parameters should be configured 
dynamically. It just popped into my mind regarding the dynamic configuration, 
that there would be a need to configure other configuration parameters, not 
just meters, that is why I mentioned it as a considerable item.

Doug



Doug



If it is ok for you, I will register the bp for this per-project tenant 
settings with some details, when I'm finished with the initial design of how 
this feature could work.

Best Regards,
Ildiko

-Original Message-
From: Neal, Phil [mailto:phil.n...@hp.commailto:phil.n...@hp.com]
Sent: Tuesday, January 07, 2014 11:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

For multi-node deployments, implementing something like inotify would allow 
administrators to push configuration changes out

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Ildikó Váncsa]

Hi,

(You didn't Cc the list, not sure if it was on purpose. I'm not adding it back 
to not break any confidentiality, but feel free to do so.)

Sorry that was just a mistake.

  The point is to configure the data collection configuration for the 
  currently existing meters differently for tenants. It is not just 
  about enabling or disabling of meters. It could be used to change the 
  interval settings of meters, like tenantA would like to receive 
  cpu_util samples in every 10 seconds and tenantB would like to receive 
  cpu_util in every 1 minute, but network.incoming.bytes in every 20 
  seconds. As for disabling meters, for instance tenantA needs 
  disk.read.requests and disk.write.requests, while tenantB doesn't.

 Ok, so this is really about something the _operator_ wants to do, not users. 
 I still don't think it belongs to an API, at least not specific to Ceilometer.

My idea was just about providing the possibility to configure the data 
collection in Ceilometer differently for the different tenants, I didn't mean 
to link it to an API or at least not on the first place. It could be done by 
the operator as well, for instance, if the polling frequency should be 
different in case of tenants.

Best Regards,
Ildiko

 --
 Julien Danjou
 -- Free Software hacker - independent consultant
 -- http://julien.danjou.info
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Ildikó Váncsa]

Hi,

  My idea was just about providing the possibility to configure the data 
  collection in Ceilometer differently for the different tenants, I 
  didn't mean to link it to an API or at least not on the first place. 
  It could be done by the operator as well, for instance, if the polling 
  frequency should be different in case of tenants.

 Yeah, that would work, we would just need to add a list of project to the 
 yaml file. We are already doing that for resources anyway, we can do it for 
 user and project as well.

Ok, that sounds good. Then I will create a blueprint based on this direction.

Best Regards,
Ildiko

 --
 Julien Danjou
 ;; Free Software hacker ; independent consultant ;; http://julien.danjou.info
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

[Ildikó Váncsa]

Hi Doug,
OK, so like I said, we did not design the system with the idea that a user of 
the cloud (rather than the deployer of the cloud) would have any control over 
what data was collected. They can ask questions about only some of the data, 
but they can't tell ceilometer what to collect.

There's a certain amount of danger in giving the cloud user (no matter their 
role) an off switch for the data collection. As Julien pointed out, it can 
have a negative effect on billing -- if they tell the cloud not to collect data 
about what instances are created, then the deployer can't bill for those 
instances. Differentiating between the values that always must be collected and 
the ones the user can control makes providing an API to manage data collection 
more complex.

Is there some underlying use case behind all of this that someone could 
describe in more detail, so we might be able to find an alternative, or explain 
how to use the existing features to achieve the goal? For example, it is 
already possible to change the pipeline config file to control which data is 
collected and stored. If we make the pipeline code in ceilometer watch for 
changes to that file, and rebuild the pipelines when the config is updated, 
would that satisfy the requirements?

ildikov: Thanks for the clarification. The base idea was to provide the 
possibility of different data collection configuration for projects. Reflecting 
to the dynamic meter configuration and the possible API based solution, it 
seemed to be possible to provide the configuration possibility to the users of 
the cloud as well. At this point, I haven't considered the billing aspect, 
which would be affected by this extra option, as you mentioned it above, so it 
was definitely a wrong direction. Finally we've reached a consensus with Julien 
by making the required changes in pipeline.yaml and the related codebase.

ildikov: Thanks to both of you for the effort in clarifying this.

Best Regards,
Ildiko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Complex query BP implementation

[Ildikó Váncsa]

Hi guys,

The first working version of the Complex filter expressions in API queries 
blueprint [1] was pushed for review[2].

We implemented a new query REST resource in order to provide rich query 
functionality for samples, alarms and alarm history. The future plans (in 
separated blueprints) with this new functionality is extending it to support 
Statistics and stored queries. The new feature is documented on Launchpad 
wiki[3], with an example for how to use the new query on the API.

What is your opinion about this solution?
I would appreciate some review comments and/or feedback on the implementation. 
:)

[1]  
https://blueprints.launchpad.net/ceilometer/+spec/complex-filter-expressions-in-api-queries
[2]  
https://review.openstack.org/#/q/status:open+project:openstack/ceilometer+branch:master+topic:bp/complex-filter-expressions-in-api-queries,n,z
[3]  
https://wiki.openstack.org/wiki/Ceilometer/ComplexFilterExpressionsInAPIQueries

Thanks and Best Regards,
Ildiko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Extended query filtering feature

[Ildikó Váncsa]

Hi All,

As a resumption of the Improving Ceilometer API query filtering session of the 
HK Design Summit, I created a document about supporting complex query filters 
in Ceilometer. The document contains a brief summary of the previously 
suggested idea. The second part of the etherpad discuss the details of 
supporting the complex filtering expressions in the queries according to the 
discussion on the design summit session.

A new blueprint will also be submitted this week about the improved idea.

The link to the etherpad: 
https://etherpad.openstack.org/p/Ceilometer_extended_API_query_filtering

Please feel free to comment the document above. If you choose to write your 
comments into the etherpad doc, please use the Authorship colors option or you 
can also send the comments via email.

Thanks and Best Regards,
Ildiko Vancsa
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev