from:"Csatari, Gergely \(Nokia \- HU\/Budapest\)"

Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

2018-10-23 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Yes, https://github.com/State-of-the-Edge/glossary is a good initiative. Maybe 
we should all just start using the terms defined there and contribute if we 
have problems with the definitions.

Br,
Gerg0

From: Teresa Peluso 
Sent: Friday, October 19, 2018 4:39 PM
To: Csatari, Gergely (Nokia - HU/Budapest) ; 
OpenStack Development Mailing List (not for usage questions) 
; ful...@redhat.com; 
edge-comput...@lists.openstack.org
Cc: openstack-s...@lists.openstack.org
Subject: RE: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the 
use of terms "Edge" and "Far Edge"

Fyi – could this help?  
https://www.linuxfoundation.org/blog/2018/06/edge-computing-just-got-its-rosetta-stone/

https://imasons.org/ starting to host workshops about this as well 
https://imasons.org/events/2018-im-edge-congress/

From: Csatari, Gergely (Nokia - HU/Budapest) 
mailto:gergely.csat...@nokia.com>>
Sent: Friday, October 19, 2018 1:05 AM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>; 
ful...@redhat.com<mailto:ful...@redhat.com>; 
edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>
Cc: 
openstack-s...@lists.openstack.org<mailto:openstack-s...@lists.openstack.org>
Subject: [EXTERNAL] Re: [Edge-computing] [openstack-dev] [Openstack-sigs] 
[FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

Hi,

I’m adding the ECG mailing list to the discussion.

I think the root of the problem is that there is no single definition of „the 
edge” (except for 
[1<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_The-5FEdge=DwMGaQ=gxW9PgscCAGwFImBgfkGkoANogu61GVPNv0sglxAtik=JcbYkw8s_8JtubERIbsy_0Qc_q0zGK9nUrtf2IWVNmQ=VtNo9cSRcnVhW9PH68IA26gNRrJ96V0O7MHTeONQ-hY=J6lr_T9m7mkisVR7l1QzmBki20r5He3fuZXvbYg-EPs=>]),
 but it changes from group to group or use case to use case. What I recognise 
as the commonalities in these edge definitions, are 1) a distributed cloud 
infrastructure (kind of a cloud of clouds) 2) need for automation or everything 
3) resource constraints for the control plane.

The different edge variants are putting different emphasis on these common 
needs based ont he use case discussed.

To have a more clear understanding of these definitions we could try the 
following:

  1.  Always add the definition of these to the given context
  2.  Check what other groups are using and adopt to that
  3.  Define our own language and expect everyone else to adopt

Br,
Gerg0

[1]: 
https://en.wikipedia.org/wiki/The_Edge<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_The-5FEdge=DwQGaQ=gxW9PgscCAGwFImBgfkGkoANogu61GVPNv0sglxAtik=JcbYkw8s_8JtubERIbsy_0Qc_q0zGK9nUrtf2IWVNmQ=VtNo9cSRcnVhW9PH68IA26gNRrJ96V0O7MHTeONQ-hY=J6lr_T9m7mkisVR7l1QzmBki20r5He3fuZXvbYg-EPs=>

From: Jim Rollenhagen mailto:j...@jimrollenhagen.com>>
Sent: Thursday, October 18, 2018 11:43 PM
To: ful...@redhat.com<mailto:ful...@redhat.com>; OpenStack Development Mailing 
List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Cc: 
openstack-s...@lists.openstack.org<mailto:openstack-s...@lists.openstack.org>
Subject: Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the 
use of terms "Edge" and "Far Edge"

On Thu, Oct 18, 2018 at 4:45 PM John Fulton 
mailto:johfu...@redhat.com>> wrote:
On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen 
mailto:j...@jimrollenhagen.com>> wrote:
>
> On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur 
> mailto:dtant...@redhat.com>> wrote:
>>
>> Hi all,
>>
>> Sorry for chiming in really late in this topic, but I think $subj is worth
>> discussing until we settle harder on the potentially confusing terminology.
>>
>> I think the difference between "Edge" and "Far Edge" is too vague to use 
>> these
>> terms in practice. Think about the "edge" metaphor itself: something rarely 
>> has
>> several layers of edges. A knife has an edge, there are no far edges. I 
>> imagine
>> zooming in and seeing more edges at the edge, and then it's quite cool 
>> indeed,
>> but is it really a useful metaphor for those who never used a strong 
>> microscope? :)
>>
>> I think in the trivial sense "Far Edge" is a tautology, and should be 
>> avoided.
>> As a weak proof of my words, I already see a lot of smart people confusing 
>> these
>> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we
>> adopt a different terminology, even if it less consistent with typical 
>> marketing
>> term around the "Edge" movement.
>
>
> FWIW, we created rough definitions of "edge" and "far edge"

Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

2018-10-19 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I’m adding the ECG mailing list to the discussion.

I think the root of the problem is that there is no single definition of „the 
edge” (except for [1]), but it changes 
from group to group or use case to use case. What I recognise as the 
commonalities in these edge definitions, are 1) a distributed cloud 
infrastructure (kind of a cloud of clouds) 2) need for automation or everything 
3) resource constraints for the control plane.

The different edge variants are putting different emphasis on these common 
needs based ont he use case discussed.

To have a more clear understanding of these definitions we could try the 
following:

  1.  Always add the definition of these to the given context
  2.  Check what other groups are using and adopt to that
  3.  Define our own language and expect everyone else to adopt

Br,
Gerg0



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

From: Jim Rollenhagen 
Sent: Thursday, October 18, 2018 11:43 PM
To: ful...@redhat.com; OpenStack Development Mailing List (not for usage 
questions) 
Cc: openstack-s...@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the 
use of terms "Edge" and "Far Edge"

On Thu, Oct 18, 2018 at 4:45 PM John Fulton 
mailto:johfu...@redhat.com>> wrote:
On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen 
mailto:j...@jimrollenhagen.com>> wrote:
>
> On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur 
> mailto:dtant...@redhat.com>> wrote:
>>
>> Hi all,
>>
>> Sorry for chiming in really late in this topic, but I think $subj is worth
>> discussing until we settle harder on the potentially confusing terminology.
>>
>> I think the difference between "Edge" and "Far Edge" is too vague to use 
>> these
>> terms in practice. Think about the "edge" metaphor itself: something rarely 
>> has
>> several layers of edges. A knife has an edge, there are no far edges. I 
>> imagine
>> zooming in and seeing more edges at the edge, and then it's quite cool 
>> indeed,
>> but is it really a useful metaphor for those who never used a strong 
>> microscope? :)
>>
>> I think in the trivial sense "Far Edge" is a tautology, and should be 
>> avoided.
>> As a weak proof of my words, I already see a lot of smart people confusing 
>> these
>> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we
>> adopt a different terminology, even if it less consistent with typical 
>> marketing
>> term around the "Edge" movement.
>
>
> FWIW, we created rough definitions of "edge" and "far edge" during the edge 
> WG session in Denver.
> It's mostly based on latency to the end user, though we also talked about 
> quantities of compute resources, if someone can find the pictures.

Perhaps these are the pictures Jim was referring to?
 
https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0#

That's it, thank you!

// jim



I'm involved in some TripleO work called the split control plane:
  
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html

After the PTG I saw that the split control plane was compatible with
the type of deployment discussed at the edge WG session in Denver and
described the compatibility at:
  
https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane

> See the picture and table here: 
> https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview
>
>> Now, I don't have really great suggestions. Something that came up in TripleO
>> discussions [1] is Core/Hub/Edge, which I think reflects the idea better.
>
>
> I'm also fine with these names, as they do describe the concepts well. :)
>
> // jim

I'm fine with these terms too. In split control plane there's a
deployment method for deploying a central site and then deploying
remote sites independently. That deployment method could be used to
deploy  Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack
N. Deploy a Hub using stack N+1 and then deploy an Edge using stack
N+2 etc.

  John

>>
>> I'd be very interested to hear your ideas.
>>
>> Dmitry
>>
>> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp
>>
>> ___
>> openstack-sigs mailing list
>> openstack-s...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
> __
> 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

[openstack-dev] [edge][glance][ptg]: Image handling wiki updated

2018-10-15 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I've updated the Image handling in edge environment wiki 
[1] based 
on the notes 
[2] from the 
Denver ptg discussions.

Please check and comment.

Thanks,
Gerg0

[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/glance-stein-edge-architecture
__
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] [edge][keystone][ptg]: Keystone edge architectures wiki updated

2018-10-15 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I've updated the Keystone edge architectures wiki 
[1] based on the 
notes [2] we 
generated in the Denver workshop.

Please check and comment.

Thanks,
Gerg0

[1]: https://wiki.openstack.org/wiki/Keystone_edge_architectures
[2]: https://etherpad.openstack.org/p/keystone-stein-edge-architecture

__
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] [ironic][edge] Notes from the PTG

2018-09-28 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi Jim,

Thanks for sharing your notes.

One note about the jumping automomus control plane requirement.
This requirement was already identified during the Dublin PTG workshop 
[1].
 This is needed for two reasons the edge cloud instance should stay operational 
even if there is a network break towards other edge cloud instances and the 
edge cloud instance should work together with other edge cloud instances 
running other version of the control plane. In Denver we deided to leave out 
these requirements form the MVP architecture discussions.

Br,
Gerg0

[1]: 
https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG



From: Jim Rollenhagen mailto:j...@jimrollenhagen.com>>
Reply-To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 19, 2018 at 10:49 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [ironic][edge] Notes from the PTG

I wrote up some notes from my perspective at the PTG for some internal teams 
and figured I may as well share them here. They're primarily from the ironic 
and edge WG rooms. Fairly raw, very long, but hopefully useful to someone. 
Enjoy.

Tuesday: edge

Edge WG (IMHO) has historically just talked about use cases, hand-waved a bit, 
and jumped to requiring an autonomous control plane per edge site - thus 
spending all of their time talking about how they will make glance and keystone 
sync data between control planes.

penick described roughly what we do with keystone/athenz and how that can be 
used in a federated keystone deployment to provide autonomy for any control 
plane, but also a single view via a global keystone.

penick and I both kept pushing for people to define a real architecture, and we 
ended up with 10-15 people huddled around an easel for most of the afternoon. 
Of note:

- Windriver (and others?) refuse to budge on the many control plane thing
- This means that they will need some orchestration tooling up top in the 
main DC / client machines to even come close to reasonably managing all of 
these sites
- They will probably need some syncing tooling
- glance->glance isn’t a thing, no matter how many people say it is.
- Glance PTL recommends syncing metadata outside of glance process, and a 
global(ly distributed?) glance backend.
- We also defined the single pane of glass architecture that Oath plans to 
deploy
- Okay with losing connectivity from central control plane to single edge 
site
- Each edge site is a cell
- Each far edge site is just compute nodes
- Still may want to consider image distribution to edge sites so we don’t 
have to go back to main DC?
- Keystone can be distributed the same as first architecture
- Nova folks may start investigating putting API hosts at the cell level to 
get the best of both worlds - if there’s a network partition, can still talk to 
cell API to manage things
- Need to think about removing the need for rabbitmq between edge and far 
edge
- Kafka was suggested in the edge room for oslo.messaging in general
- Etcd watchers may be another option for an o.msg driver
- Other other options are more invasive into nova - involve changing 
how nova-compute talks to conductor (etcd, etc) or even putting REST APIs in 
nova-compute (and nova-conductor?)
- Neutron is going to work on an OVS “superagent” - superagent does the 
RPC handling, talks some other way to child agents. Intended to scale to 
thousands of children. Primary use case is smart nics but seems like a win for 
the edge case as well.

penick took an action item to draw up the architecture diagrams in a digestable 
format.

Wednesday: ironic things

Started with a retrospective. See 
https://etherpad.openstack.org/p/ironic-stein-ptg-retrospective for the notes - 
there wasn’t many surprising things here. We did discuss trying to target some 
quick wins for the beginning of the cycle, so that we didn’t have all of our 
features trying to land at the end. Using wsgi with the ironic-api was 
mentioned as a potential regression, but we agreed it’s a config/documentation 
issue. I took an action to make a task to document this better.

Next we quickly reviewed our vision doc, and people didn’t have much to say 
about it.

Metalsmith: it’s a thing, it’s being included into the ironic project. Dmitry 
is open to optionally supporting placement. Multiple instances will be a 
feature in the future. Otherwise mostly feature complete, goal is to keep it 
simple.

Networking-ansible: redhat building tooling that integrates with upstream 
ansible modules for networking gear. Kind of an alternative to n-g-s. Not 
really much on plans here, RH just wanted to introduce it to the community. 
Some

Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

2018-09-08 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I’m in.

Br,
Gerg0

From: Miguel Lavalle 
Sent: Saturday, September 8, 2018 10:30 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next 
week - ACTION NEEDED

Hi Ildikó,

Wednesday lunch is fine with me

Regards

On Fri, Sep 7, 2018 at 5:30 PM, Ildiko Vancsa 
mailto:ildiko.van...@gmail.com>> wrote:
Hi Training Team,

As a couple of us will be at the PTG next week it would be great to get 
together one of the days maybe for lunch.

Wednesday would work the best for Kendall and me, but we can look into other 
days as well if it would not work for the majority of people around.

So my questions would be:

* Are you interested in getting together one of the lunch slots during next 
week?

* Would Wednesday work for you or do you have another preference?

Please drop a response to this thread and we will figure it out by Monday or 
early next week based on the responses.

Thanks,
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

Re: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-22 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

This is good news. We could even have an hour session to discuss ideas about 
TripleO-s place in the edge cloud infrastructure. Would you be open for that?

Br, 
Gerg0

-Original Message-
From: James Slagle  
Sent: Tuesday, August 21, 2018 2:42 PM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud 
deployment use cases (new squad)

On Tue, Aug 21, 2018 at 2:40 AM Csatari, Gergely (Nokia - HU/Budapest) 
 wrote:
>
> Hi,
>
> There was a two days workshop on edge requirements back in Dublin. The notes 
> are stored here: 
> https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG I think 
> there are some areas there what can be interesting for the squad.
> Edge Computing Group plans to have a day long discussion in Denver. Maybe we 
> could have a short discussion there about these requirements.

Thanks! I've added my name to the etherpad for the PTG and will plan on 
spending Tuesday with the group.
https://etherpad.openstack.org/p/EdgeComputingGroupPTG4


--
-- James Slagle
--

__
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] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-21 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

There was a two days workshop on edge requirements back in Dublin. The notes 
are stored here: 
https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG I think 
there are some areas there what can be interesting for the squad. 
Edge Computing Group plans to have a day long discussion in Denver. Maybe we 
could have a short discussion there about these requirements. 

Br, 
Gerg0

-Original Message-
From: James Slagle  
Sent: Monday, August 20, 2018 10:48 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud 
deployment use cases (new squad)

As we start looking at how TripleO will address next generation deployment 
needs such as Edge, multi-site, and multi-cloud, I'd like to kick off a 
discussion around how TripleO can evolve and adapt to meet these new challenges.

What are these challenges? I think the OpenStack Edge Whitepaper does a good 
job summarizing some of them:

https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf

They include:

- management of distributed infrastructure
- massive scale (thousands instead of hundreds)
- limited network connectivity
- isolation of distributed sites
- orchestration of federated services across multiple sites

We already have a lot of ongoing work that directly or indirectly starts to 
address some of these challenges. That work includes things like 
config-download, split-controlplane, metalsmith integration, validations, 
all-in-one, and standalone.

I laid out some initial ideas in a previous message:

http://lists.openstack.org/pipermail/openstack-dev/2018-July/132398.html

I'll be reviewing some of that here and going into a bit more detail.

These are some of the high level ideas I'd like to see TripleO start to
address:

- More separation between planning and deploying (likely to be further defined
  in spec discussion). We've had these concepts for a while, but we need to do
  a better job of surfacing them to users as deployments grow in size and
  complexity.

  With config-download, we can more easily separate the phases of rendering,
  downloading, validating, and applying the configuration. As we increase in
  scale to managing many deployments, we should take advantage of what each of
  those phases offer.

  The separation also makes the deployment more portable, as we should
  eliminate any restrictions that force the undercloud to be the control node
  applying the configuration.

- Management of multiple deployments from a single undercloud. This is of
  course already possible today, but we need better docs and polish and more
  testing to flush out any bugs.

- Plan and template management in git.

  This could be an iterative step towards eliminating Swift in the undercloud.
  Swift seemed like a natural choice at the time because it was an existing
  OpenStack service.  However, I think git would do a better job at tracking
  history and comparing changes and is much more lightweight than Swift. We've
  been managing the config-download directory as a git repo, and I like this
  direction. For now, we are just putting the whole git repo in Swift, but I
  wonder if it makes sense to consider eliminating Swift entirely. We need to
  consider the scale of managing thousands of plans for separate edge
  deployments.

  I also think this would be a step towards undercloud simplification.

- Orchestration between plans. I think there's general agreement around scaling
  up the undercloud to be more effective at managing and deploying multiple
  plans.

  The plans could be different OpenStack deployments potentially sharing some
  resources. Or, they could be deployments of different software stacks
  (Kubernetes/OpenShift, Ceph, etc).

  We'll need to develop some common interfaces for some basic orchestration
  between plans. It could include dependencies, ordering, and sharing parameter
  data (such as passwords or connection info). There is already some ongoing
  discussion about some of this work:

  http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html

  I would suspect this would start out as collecting specific use cases, and
  then figuring out the right generic interfaces.

- Multiple deployments of a single plan. This could be useful for doing many
  deployments that are all the same. Of course some info might be different
  such as network IP's, hostnames, and node specific details. We could have
  some generic input interfaces for those sorts of things without having to
  create new Heat stacks, which would allow re-using the same plan/stack for
  multiple deployments. When scaling to hundreds/thousands of edge deployments
  this could be really effective at side-stepping managing hundreds/thousands
  of Heat stacks.

  We may also need further separation between a plan and it's deployment state
  to have this modularity.

- Distributed management/application of configuration. Even though the

Re: [openstack-dev] [tripleo][Edge][FEMDC] Edge clouds and controlplane updates

2018-08-17 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Some comments inline.

From: Alan Bishop 
Sent: Thursday, August 16, 2018 7:09 PM

On Tue, Aug 14, 2018 at 9:20 AM Bogdan Dobrelya 
mailto:bdobr...@redhat.com>> wrote:
On 8/13/18 9:47 PM, Giulio Fidente wrote:
> Hello,
>
> I'd like to get some feedback regarding the remaining
> work for the split controlplane spec implementation [1]
>
> Specifically, while for some services like nova-compute it is not
> necessary to update the controlplane nodes after an edge cloud is
> deployed, for other services, like cinder (or glance, probably
> others), it is necessary to do an update of the config files on the
> controlplane when a new edge cloud is deployed.

[G0]: What is the reason to run a shared cinder in an edge cloud 
infrastructure? Maybe it is a better approach to run an individual Cinder in 
every edge cloud instance.

> In fact for services like cinder or glance, which are hosted in the
> controlplane, we need to pull data from the edge clouds (for example
> the newly deployed ceph cluster keyrings and fsid) to configure cinder
> (or glance) with a new backend.

[G0]: Solution ideas for Glance are listed in 
[3].

> It looks like this demands for some architectural changes to solve the > 
> following two:
>
> - how do we trigger/drive updates of the controlplane nodes after the
> edge cloud is deployed?

Note, there is also a strict(?) requirement of local management
capabilities for edge clouds temporary disconnected off the central
controlplane. That complicates the updates triggering even more. We'll
need at least a notification-and-triggering system to perform required
state synchronizations, including conflicts resolving. If that's the
case, the architecture changes for TripleO deployment framework are
inevitable AFAICT.

This is another interesting point. I don't mean to disregard it, but want to
highlight the issue that Giulio and I (and others, I'm sure) are focused on.

As a cinder guy, I'll use cinder as an example. Cinder services running in the
control plane need to be aware of the storage "backends" deployed at the
Edge. So if a split-stack deployment includes edge nodes running a ceph
cluster, the cinder services need to be updated to add the ceph cluster as a
new cinder backend. So, not only is control plane data needed in order to
deploy an additional stack at the edge, data from the edge deployment needs to
be fed back into a subsequent stack update in the controlplane. Otherwise,
cinder (and other storage services) will have no way of utilizing ceph
clusters at the edge.
>
> - how do we scale the controlplane parameters to accomodate for N
> backends of the same type?

Yes, this is also a big problem for me. Currently, TripleO can deploy cinder
with multiple heterogeneous backends (e.g. one each of ceph, NFS, Vendor X,
Vendor Y, etc.). However, the current THT do not let you deploy multiple
instances of the same backend (e.g. more than one ceph). If the goal is to
deploy multiple edge nodes consisting of Compute+Ceph, then TripleO will need
the ability to deploy multiple homogeneous cinder backends. This requirement
will likely apply to glance and manila as well.

> A very rough approach to the latter could be to use jinja to scale up
> the CephClient service so that we can have multiple copies of it in the
> controlplane.
>
> Each instance of CephClient should provide the ceph config file and
> keyring necessary for each cinder (or glance) backend.
>
> Also note that Ceph is only a particular example but we'd need a similar
> workflow for any backend type.
>
> The etherpad for the PTG session [2] touches this, but it'd be good to
> start this conversation before then.
>
> 1.
> https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html
>
> 2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane
>

[3]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment

Br,
Gerg0

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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] [edge][glance][nova][starlngx]: Edge sessions on the PTG

2018-08-14 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

We will have a whole day discussion on edge on the Tuesday of the PTG [1] where 
we plan [2] to have discussions on image handling, Nova, Keystone and StarlingX.
If you are interested in any of these please add your name to the name lists. 
Also if you have some ideas to discuss during the day please add it to the list.

Thanks,
Gerg0

[1]: https://www.openstack.org/ptg#tab_schedule
[2]: https://etherpad.openstack.org/p/EdgeComputingGroupPTG4
__
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] [edge][glance]: Image handling in edge environment

2018-07-27 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

The meeting will take place on 2018.08.01 18-19h CET.
Here I attach the invitation.

Br,
Gerg0



From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Friday, July 20, 2018 1:32 PM
To: 'edge-computing' ; 'OpenStack 
Development Mailing List (not for usage questions)' 

Cc: 'jokke' 
Subject: RE: [edge][glance]: Image handling in edge environment

Hi,

We figured out with Jokke two timeslots what would be okay for both of us for 
this common meeting.

Please, other interested parties give your votes to here: 
https://doodle.com/poll/9rfcb8aavsmybzfu

I will evaluate the results and fix the time on 25.07.2018 12h CET.

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, July 18, 2018 10:02 AM
To: 'edge-computing' 
mailto:edge-comput...@lists.openstack.org>>;
 OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: [edge][glance]: Image handling in edge environment

Hi,

We had a great Forum session about image handling in edge environment in 
Vancouver [1<https://etherpad.openstack.org/p/yvr-edge-cloud-images>]. As one 
outcome of the session I've created a wiki with the mentioned architecture 
options 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment>]. During 
the Edge Working Group 
[3<https://wiki.openstack.org/wiki/Edge_Computing_Group>] discussions we 
identified some questions (some of them are in the wiki, some of them are in 
mails 
[4<http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html>]) 
and also I would like to get some feedback on the analyzis in the wiki from 
people who know Glance.

I think the best would be to have some kind of meeting and I see two options to 
organize this:

  *   Organize a dedicated meeting for this
  *   Add this topic as an agenda point to the Glance weekly meeting

Please share your preference and/or opinion.

Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[3]: https://wiki.openstack.org/wiki/Edge_Computing_Group
[4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html

--- Begin Message ---
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Csatari, Gergely (Nokia - HU/Budapest)":MAILTO:gergely.csatari@
 nokia.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='edge-comp
 uting':MAILTO:edge-comput...@lists.openstack.org
DESCRIPTION;LANGUAGE=en-US:Hi\,\n\n\n\nLet’s spend this time to discuss t
 he alternatives for Image handling in edge environment listed in here: htt
 ps://wiki.openstack.org/wiki/Image_handling_in_edge_environment\n\n\n\n*  
  Check if the alternatives were captured correctly\n*   Check the 
 pros and cons\n*   Check the concerns and questions\n*   Decide if
  an alternative is a dead end\n\n\n\nFor some strange reasons I do not rec
 eive mails from the OpenStack mailing list servers anymore\, so if you hav
 e anything to discuss about this please use #edge-computing-group or add m
 e directly to the mails.\n\n\n\nBr\,\n\nGerg0\n\n\n\n-
 -- 8< \n\nWebex: https://nokiameetings.webex.com/meet/gerg
 ely.csatari\n\nTelco if you need it:\n\nInternal : 8200300\n\nHungary: +36
 14088997\n\nGlobal numbers<https://nokiameetings.webex.com/cmp3000/webcomp
 onents/widget/globalcallin/globalcallin.do?siteurl=nokiameetings
 pe=MC=362182577=0>\n\nAccess code: 957 007 218\n\n\n\n\n\n\n\n
 \n\n\n\n
UID:04008200E00074C5B7101A82E00830EFE77B8625D401000
 0100025DF680C321C144AAD8B9C823BC15A5C
SUMMARY;LANGUAGE=en-US:Image handling in edge environment
DTSTART;TZID=Central Europe Standard Time:20180801T18
DTEND;TZID=Central Europe Standard Time:20180801T19
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180727T065827Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:webex / #edge-computing-group
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-145000478
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONS:[{"DisplayName":"webex / #edge-computing-group"\,"Loc
 ationAnnotation":""\,"LocationUri":""\,"LocationStreet":""\,"LocationCity"
 :""\,"LocationState":&qu

Re: [openstack-dev] [edge][glance]: Image handling in edge environment

2018-07-20 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

We figured out with Jokke two timeslots what would be okay for both of us for 
this common meeting.

Please, other interested parties give your votes to here: 
https://doodle.com/poll/9rfcb8aavsmybzfu

I will evaluate the results and fix the time on 25.07.2018 12h CET.

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, July 18, 2018 10:02 AM
To: 'edge-computing' ; OpenStack 
Development Mailing List (not for usage questions) 

Subject: [edge][glance]: Image handling in edge environment

Hi,

We had a great Forum session about image handling in edge environment in 
Vancouver [1<https://etherpad.openstack.org/p/yvr-edge-cloud-images>]. As one 
outcome of the session I've created a wiki with the mentioned architecture 
options 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment>]. During 
the Edge Working Group 
[3<https://wiki.openstack.org/wiki/Edge_Computing_Group>] discussions we 
identified some questions (some of them are in the wiki, some of them are in 
mails 
[4<http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html>]) 
and also I would like to get some feedback on the analyzis in the wiki from 
people who know Glance.

I think the best would be to have some kind of meeting and I see two options to 
organize this:

  *   Organize a dedicated meeting for this
  *   Add this topic as an agenda point to the Glance weekly meeting

Please share your preference and/or opinion.

Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[3]: https://wiki.openstack.org/wiki/Edge_Computing_Group
[4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html

__
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] [edge][glance]: Image handling in edge environment

2018-07-18 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

We had a great Forum session about image handling in edge environment in 
Vancouver [1]. As one 
outcome of the session I've created a wiki with the mentioned architecture 
options 
[1]. During 
the Edge Working Group 
[3] discussions we 
identified some questions (some of them are in the wiki, some of them are in 
mails 
[4]) 
and also I would like to get some feedback on the analyzis in the wiki from 
people who know Glance.

I think the best would be to have some kind of meeting and I see two options to 
organize this:

  *   Organize a dedicated meeting for this
  *   Add this topic as an agenda point to the Glance weekly meeting

Please share your preference and/or opinion.

Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[3]: https://wiki.openstack.org/wiki/Edge_Computing_Group
[4]: http://lists.openstack.org/pipermail/edge-computing/2018-June/000239.html

__
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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-07-02 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Friday, June 29, 2018 4:25 AM

In-lined comments / questions below,
Greg.

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
mailto:gergely.csat...@nokia.com>>
Date: Thursday, June 28, 2018 at 3:35 AM


Hi,

I’ve added the following pros and cons to the different options:



  *   One Glance with multiple backends 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends>]
[Greg]
I’m not sure I understand this option.

Is each Glance Backend completely independent ?   e.g. when I do a “glance 
image-create ...” am I specifying a backend and that’s where the image is to be 
stored ?
This is what I was originally thinking.
So I was thinking that synchronization of images to Edge Clouds is simply done 
by doing “glance image-create ...” to the appropriate backends.

But then you say “The syncronisation of the image data is the responsibility of 
the backend (eg.: CEPH).” ... which makes it sound like my thinking above is 
wrong and the Backends are NOT completely independent, but instead in some sort 
of replication configuration ... is this leveraging ceph replication factor or 
something (for example) ?
[G0]: According to my understanding the backends are in a replication 
configuration in this case. Jokke, am I right?

 *   Pros:
*   Relatively easy to implement based on the current Glance 
architecture
 *   Cons:
*   Requires the same Glance backend in every edge cloud instance
*   Requires the same OpenStack version in every edge cloud instance 
(apart from during upgrade)
*   Sensitivity for network connection loss is not clear
[Greg] I could be wrong, but even though the OpenStack services in the edge 
clouds are using the images in their glance backend with a direct URL,
I think the OpenStack services (e.g. nova) still need to get the direct URL via 
the Glance API which is ONLY available at the central site.
So don’t think this option supports autonomy of edge Subcloud when connectivity 
is lost to central site.
[G0]: Can’t the url point to the local Glance backend somehow?

  *   Several Glances with an independent syncronisation service, sych via 
Glance API 
[2<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API>]
 *   Pros:
*   Every edge cloud instance can have a different Glance backend
*   Can support multiple OpenStack versions in the different edge cloud 
instances
*   Can be extended to support multiple VIM types
 *   Cons:
*   Needs a new synchronisation service
[Greg] Don’t believe this is a big con ... suspect we are going to need this 
new synchronization service for synchronizing resources of a number of other 
openstack services ... not just glance.
[G0]: I agree, it is not a big con, but it is a con  Should I add some note 
saying, that a synch service is most probably needed anyway?

  *   Several Glances with an independent syncronisation service, synch using 
the backend 
[3<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend>]
[Greg] This option seems a little odd to me.
We are synching the GLANCE DB via some new synchronization service, but 
synching the Images themselves via the backend ... I think that would be tricky 
to ensure consistency.
[G0]: Yes, there is a place for errors here.

 *   Pros:
*   I could not find any
 *   Cons:
*   Needs a new synchronisation service


  *   One Glance and multiple Glance API servers 
[4<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers>]
 *   Pros:
*   Implicitly location aware
 *   Cons:
*   First usage of an image always takes a long time
*   In case of network connection error to the central Galnce Nova will 
have access to the images, but will not be able to figure out if the user have 
rights to use the image and will not have path to the images data
[Greg] Yeah we tripped over the issue that although the Glance API can cache 
the image itself, it does NOT cache the image meta data (which I am guessing 
has info like “user access” etc.) ... so this option improves latency of access 
to image itself but does NOT provide autonomy.

We plan on looking at options to resolve this, as we like the “implicit 
location awareness” of this option ... and believe it is an option that some 
customers will like.
If anyone has any ideas ?
Are these correct? Do I miss anything?

Thanks,
Gerg0

[1]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends
[2]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_wi

Re: [openstack-dev] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-06-28 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I’ve added the following pros and cons to the different options:

  *   One Glance with multiple backends 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends>]
 *   Pros:
*   Relatively easy to implement based on the current Glance 
architecture
 *   Cons:
*   Requires the same Glance backend in every edge cloud instance
*   Requires the same OpenStack version in every edge cloud instance 
(apart from during upgrade)
*   Sensitivity for network connection loss is not clear
  *   Several Glances with an independent syncronisation service, sych via 
Glance API 
[2<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API>]
 *   Pros:
*   Every edge cloud instance can have a different Glance backend
*   Can support multiple OpenStack versions in the different edge cloud 
instances
*   Can be extended to support multiple VIM types
 *   Cons:
*   Needs a new synchronisation service
  *   Several Glances with an independent syncronisation service, synch using 
the backend 
[3<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend>]
 *   Pros:
*   I could not find any
 *   Cons:
*   Needs a new synchronisation service
  *   One Glance and multiple Glance API servers 
[4<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers>]
 *   Pros:
*   Implicitly location aware
 *   Cons:
*   First usage of an image always takes a long time
*   In case of network connection error to the central Galnce Nova will 
have access to the images, but will not be able to figure out if the user have 
rights to use the image and will not have path to the images data
Are these correct? Do I miss anything?

Thanks,
Gerg0

[1]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends
[2]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API
[3]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend
[4]: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers






From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Monday, June 11, 2018 4:29 PM
To: Waines, Greg ; OpenStack Development Mailing 
List (not for usage questions) ; 
edge-comput...@lists.openstack.org
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

Thanks for the comments.
I’ve updated the wiki: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend

Br,
Gerg0

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Friday, June 8, 2018 1:46 PM
To: Csatari, Gergely (Nokia - HU/Budapest) 
mailto:gergely.csat...@nokia.com>>; OpenStack 
Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>; 
edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Responses in-lined below,
Greg.

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
mailto:gergely.csat...@nokia.com>>
Date: Friday, June 8, 2018 at 3:39 AM
To: Greg Waines mailto:greg.wai...@windriver.com>>, 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>, 
"edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>" 
mailto:edge-comput...@lists.openstack.org>>
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM
I had some additional questions/comments on the Image Synchronization Options ( 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one 
central glance for its GLANCE ENDPOINT ?
 *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when 
disconnected from Central Location ?

[G0]: This is an open question for me also

Re: [openstack-dev] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-06-11 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Thanks for the comments.
I’ve updated the wiki: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend

Br,
Gerg0

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Friday, June 8, 2018 1:46 PM
To: Csatari, Gergely (Nokia - HU/Budapest) ; 
OpenStack Development Mailing List (not for usage questions) 
; edge-comput...@lists.openstack.org
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Responses in-lined below,
Greg.

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
mailto:gergely.csat...@nokia.com>>
Date: Friday, June 8, 2018 at 3:39 AM
To: Greg Waines mailto:greg.wai...@windriver.com>>, 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>, 
"edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>" 
mailto:edge-comput...@lists.openstack.org>>
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM

I had some additional questions/comments on the Image Synchronization Options ( 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one 
central glance for its GLANCE ENDPOINT ?
 *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when 
disconnected from Central Location ?

[G0]: This is an open question for me also.


Several Glances with an independent synchronization service(PUSH)

  *   I refer to this as the PUSH model
  *   I don’t believe you have to ( or necessarily should) rely on the backend 
to do the synchronization of the images
 *   i.e. the ‘Synch Service’ could do this strictly through Glance REST 
APIs
(making it independent of the particular Glance backend ... and allowing the 
Glance Backends at Central and Edge sites to actually be different)
[G0]: Okay, I can update the wiki to reflect this. Should we keep the 
“synchronization by the backend” option as an other alternative?
[Greg] Yeah we should keep it as an alternative.

  *   I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ 
distribution of Images from Central to Edge for Image Synchronization
 *   i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites 
... especially for the small Edge Sites
[G0]: Yes, the question is how to define these synchronization policies.
[Greg] Agreed ... we’ve had some very high-level discussions with end users, 
but haven’t put together a proposal yet.

  *   Not sure ... but I didn’t think this was the model being used in mixmatch 
... thought mixmatch was more the PULL model (below)

[G0]: Yes, this is more or less my understanding. I remove the mixmatch 
reference from this chapter.

One Glance and multiple Glance API Servers   (PULL)

  *   I refer to this as the PULL model
  *   This is the current model supported in StarlingX’s Distributed Cloud 
sub-project
 *   We run glance-api on all Edge Clouds ... that talk to glance-registry 
on the Central Cloud, and
 *   We have glance-api setup for caching such that only the first access 
to an particular image incurs the latency of the image transfer from Central to 
Edge
[G0]: Do you do image caching in Glance API or do you rely in the image cache 
in Nova? In the Forum session there were some discussions about this and I 
think the conclusion was that using the image cache of Nova is enough.
[Greg] We enabled image caching in the Glance API.
 I believe that Nova Image Caching caches at the compute node ... 
this would work ok for all-in-one edge clouds or small edge clouds.
 But glance-api caching caches at the edge cloud level, so works 
better for large edge clouds with lots of compute nodes.

  *
  *   this PULL model affectively implements the location aware synchronization 
you talk about below,  (i.e. synchronise images only to those cloud instances 
where they are needed)?


In StarlingX Distributed Cloud,
We plan on supporting both the PUSH and PULL model ... suspect there are use 
cases for both.

[G0]: This means that you need an architecture supporting both.
Just for my curiosity what is the use case for the pull model once you have the 
push model in place?
[Greg] The PULL model certainly results in the most efficient distribution of 
images ... basically images are distributed ONLY to edge clouds that explicitly 
use the image.
Also if the use case is NOT concerned about incurring the la

Re: [openstack-dev] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-06-11 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

Going inline. 

-Original Message-
From: Erno Kuvaja [mailto:ekuv...@redhat.com] 
Sent: Friday, June 8, 2018 3:18 PM

Hi,

Answering inline.

Best,
Erno "jokke" Kuvaja

On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia -
HU/Budapest)  wrote:
> Hi,
>
>
>
> I did some work ont he figures and realised, that I have some 
> questions related to the alternative options:
>
>
>
> Multiple backends option:
>
> What is the API between Glance and the Glance backends?
glance_store library
> How is it possible to implement location aware synchronisation 
> (synchronise images only to those cloud instances where they are needed)?
This needs bit of hooking. We need to update the locations into Glance once the 
replication has happened.
[G0]: Okay, but how to avoid the replication to sites where the image is not 
needed?

> Is it possible to have different OpenStack versions in the different 
> cloud instances?
In my understanding it's not supported to mix versions within OpenStack cloud 
apart from during upgrade.
[G0]: Understood. This might be a problem ont he long run. With lots of edge 
cloud instance it can not be guaranteed, that all of them are upgraded in one 
go. 

> Can a cloud instance use the locally synchronised images in case of a 
> network connection break?
That depends a lot of the implementation. If there is local glance node with 
replicated db and store, yes.
[G0]: So we need a replicated Glance DB, a store and a backend in every edge 
cloud instance for this?
How the database would be syncronised in this case?

> Is it possible to implement this without storing database credentials 
> ont he edge cloud instances?
Again depending of the deployment. You definitely cannot have both, access 
during network outage and access without db credentials. if one needs to have 
local access of images without db credentials, there is always possibility for 
the local Ceph back-end with remote glance-api node. In this case Nova can talk 
directly to the local Ceph back-end and communicate with centralized glance-api 
that has the credentials to the db. The problem with loosing the network in 
this scenario is that Nova will have no idea if the user has rights to use the 
image or not and it will not know the path to that image's data.
[G0]: Okay

> Independent synchronisation service:
>
> If I understood [1] correctly mixmatch can help Nova to attach a 
> remote volume, but it will not help in synchronizing the images. is this true?
>
> As I promised in the Edge Compute Group call I plan to organize an IRC 
> review meeting to check the wiki. Please indicate your availability in [2].
>
> [1]: https://mixmatch.readthedocs.io/en/latest/
>
> [2]: https://doodle.com/poll/bddg65vyh4qwxpk5
[G0]: Please add your availability here.

Thanks, 
Gerg0 

>
>
>
> Br,
>
> Gerg0
>
>
>
> From: Csatari, Gergely (Nokia - HU/Budapest)
> Sent: Wednesday, May 23, 2018 8:59 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> ; 
> edge-comput...@lists.openstack.org
> Subject: [edge][glance]: Wiki of the possible architectures for image 
> synchronisation
>
>
>
> Hi,
>
>
>
> Here I send the wiki page [1] where I summarize what I understood from 
> the Forum session about image synchronisation in edge environment [2], [3].
>
>
>
> Please check and correct/comment.
>
>
>
> Thanks,
>
> Gerg0
>
>
>
>
>
> [1]: 
> https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
>
> [2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
>
> [3]:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events
> /21768/image-handling-in-an-edge-cloud-infrastructure
>
>
> ___
> Edge-computing mailing list
> edge-comput...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
__
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] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-06-08 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM

I had some additional questions/comments on the Image Synchronization Options ( 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one 
central glance for its GLANCE ENDPOINT ?
 *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when 
disconnected from Central Location ?

[G0]: This is an open question for me also.


Several Glances with an independent synchronization service(PUSH)

  *   I refer to this as the PUSH model
  *   I don’t believe you have to ( or necessarily should) rely on the backend 
to do the synchronization of the images
 *   i.e. the ‘Synch Service’ could do this strictly through Glance REST 
APIs
(making it independent of the particular Glance backend ... and allowing the 
Glance Backends at Central and Edge sites to actually be different)
[G0]: Okay, I can update the wiki to reflect this. Should we keep the 
“synchronization by the backend” option as an other alternative?

  *   I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ 
distribution of Images from Central to Edge for Image Synchronization
 *   i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites 
... especially for the small Edge Sites
[G0]: Yes, the question is how to define these synchronization policies.

  *   Not sure ... but I didn’t think this was the model being used in mixmatch 
... thought mixmatch was more the PULL model (below)

[G0]: Yes, this is more or less my understanding. I remove the mixmatch 
reference from this chapter.

One Glance and multiple Glance API Servers   (PULL)

  *   I refer to this as the PULL model
  *   This is the current model supported in StarlingX’s Distributed Cloud 
sub-project
 *   We run glance-api on all Edge Clouds ... that talk to glance-registry 
on the Central Cloud, and
 *   We have glance-api setup for caching such that only the first access 
to an particular image incurs the latency of the image transfer from Central to 
Edge
[G0]: Do you do image caching in Glance API or do you rely in the image cache 
in Nova? In the Forum session there were some discussions about this and I 
think the conclusion was that using the image cache of Nova is enough.

  *
  *   this PULL model affectively implements the location aware synchronization 
you talk about below,  (i.e. synchronise images only to those cloud instances 
where they are needed)?


In StarlingX Distributed Cloud,
We plan on supporting both the PUSH and PULL model ... suspect there are use 
cases for both.

[G0]: This means that you need an architecture supporting both.
Just for my curiosity what is the use case for the pull model once you have the 
push model in place?

Here is the updated wiki: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment

Thanks,
Gerg0




From: "Csatari, Gergely (Nokia - HU/Budapest)" 
mailto:gergely.csat...@nokia.com>>
Date: Thursday, June 7, 2018 at 6:49 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>, 
"edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>" 
mailto:edge-comput...@lists.openstack.org>>
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

I did some work ont he figures and realised, that I have some questions related 
to the alternative options:

Multiple backends option:

  *   What is the API between Glance and the Glance backends?
  *   How is it possible to implement location aware synchronisation 
(synchronise images only to those cloud instances where they are needed)?
  *   Is it possible to have different OpenStack versions in the different 
cloud instances?
  *   Can a cloud instance use the locally synchronised images in case of a 
network connection break?
  *   Is it possible to implement this without storing database credentials ont 
he edge cloud instances?

Independent synchronisation service:

  *   If I understood [1<https://mixmatch.readthedocs.io/en/latest/>] correctly 
mixmatch can help Nova to attach a remote volume, but it will not help in 
synchronizing the images. is this true?


As I promised in the Edge Compute Group call I plan to organize an IRC review 
meeting to check the wiki. Please indicate your availability in 
[2<https://doodle.com/poll/bddg65vyh4qwxpk5>].

[1]: https://mixmatch.readthedocs.io/en/latest/
[2]: https://doodle.com/poll/bddg65vyh4qwxpk5

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, May 23, 2018

Re: [openstack-dev] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

2018-06-07 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I did some work ont he figures and realised, that I have some questions related 
to the alternative options:

Multiple backends option:

  *   What is the API between Glance and the Glance backends?
  *   How is it possible to implement location aware synchronisation 
(synchronise images only to those cloud instances where they are needed)?
  *   Is it possible to have different OpenStack versions in the different 
cloud instances?
  *   Can a cloud instance use the locally synchronised images in case of a 
network connection break?
  *   Is it possible to implement this without storing database credentials ont 
he edge cloud instances?

Independent synchronisation service:

  *   If I understood [1<https://mixmatch.readthedocs.io/en/latest/>] correctly 
mixmatch can help Nova to attach a remote volume, but it will not help in 
synchronizing the images. is this true?


As I promised in the Edge Compute Group call I plan to organize an IRC review 
meeting to check the wiki. Please indicate your availability in 
[2<https://doodle.com/poll/bddg65vyh4qwxpk5>].

[1]: https://mixmatch.readthedocs.io/en/latest/
[2]: https://doodle.com/poll/bddg65vyh4qwxpk5

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, May 23, 2018 8:59 PM
To: OpenStack Development Mailing List (not for usage questions) 
; edge-comput...@lists.openstack.org
Subject: [edge][glance]: Wiki of the possible architectures for image 
synchronisation

Hi,

Here I send the wiki page 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment>] where I 
summarize what I understood from the Forum session about image synchronisation 
in edge environment [2], [3].

Please check and correct/comment.

Thanks,
Gerg0


[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[3]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure
__
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] [edge][glance]: Wiki of the possible architectures for image synchronisation

2018-05-23 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Here I send the wiki page 
[1] where I 
summarize what I understood from the Forum session about image synchronisation 
in edge environment [2], [3].

Please check and correct/comment.

Thanks,
Gerg0


[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[3]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure
__
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] [edge][keystone][forum]: Keystone edge brainstorming etherpad

2018-05-11 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Thanks for your comments I've added some reactions. Also thanks for the 
advertisement.

Br,
Gerg0

From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Friday, May 11, 2018 4:48 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [edge][keystone][forum]: Keystone edge 
brainstorming etherpad


On 05/10/2018 06:30 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
Hi,

I've added some initial text to the Etherpad 
[1<https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming>] of the 
Possible edge architectures for Keystone Forum session 
[2<https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone>].

Awesome, I added some of my initial thoughts, too. A very similar thread was 
brought up in Syndey, and more recently in Dublin, so a lot of those 
discussions are still fresh in my mind.



Please add your comments and also indicate your willingness to participate.

The keystone project update is scheduled for Monday [0], which gives us a good 
opportunity to advertise other important keystone-related sessions. I've added 
your forum session to it.

Thanks for proposing this. I'm looking forward to it.

[0] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21584/keystone-project-update



Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming
[2]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone





__

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-dev] [edge][keystone][forum]: Keystone edge brainstorming etherpad

2018-05-10 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I've added some initial text to the Etherpad 
[1] of the 
Possible edge architectures for Keystone Forum session 
[2].

Please add your comments and also indicate your willingness to participate.

Thanks,
Gerg0

[1]: https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming
[2]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone

__
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] Vancouver Forum - Post your selected topics now

2018-04-09 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

There are two lists of etherpads for forum brainstorming in 
https://wiki.openstack.org/wiki/Forum/Vancouver2018 and there is 
http://forumtopics.openstack.org/ .

Is my understanding correct, that ultimatelly all ideas should go to 
http://forumtopics.openstack.org/ ?

Thanks, 
Gerg0

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Monday, April 9, 2018 2:02 PM
To: OpenStack Development Mailing List ; 
openstack-operat...@lists.openstack.org
Subject: [openstack-dev] Vancouver Forum - Post your selected topics now

Hi everyone,

You've been actively brainstorming ideas of topics for discussion at the 
"Forum" at the Vancouver OpenStack Summit. Now it's time to select which ones 
you want to propose, and file them at forumtopics.openstack.org !

The topic submission website will be open until EOD on Sunday, April 15, at 
which point the Forum selection committee will take the entries and make the 
final selection. So you have the whole week to enter your selection of ideas on 
the website.

Thanks !

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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] [etsinfv][gap-03][blazar]: Network resources to be reserved

2017-12-21 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

During the Forum session about the ETSI NFV Gaps I received a request to 
clarify what network resources should be reserved.
According to the feedback from the IFA group the most important network 
resources to be reserved are bandwith and public IP addresses.

Any comments are welcome, also if you need more clarification or have more 
comments on the gaps listed in [1] do not hesitate to contact me.

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained

__
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] [First Contact] [SIG] Presence at the PTG

2017-12-18 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I’m also interested.

Br,
Gerg0

From: Kendall Nelson [mailto:kennelso...@gmail.com]
Sent: Saturday, December 16, 2017 12:27 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

Thinking more around a half a day to a full day, but if you can't make it the 
whole time I will likely type up a summary to send to the dev list at the end 
and take notes all throughout our discussions.
-Kendall (diablo_rojo)

On Thu, Dec 14, 2017 at 5:10 PM Ghanshyam Mann 
> wrote:
+1, nice idea. I will make it.

btw, what will be the meeting duration you are planning like an hour or 2 ?


-gmann


On Fri, Dec 15, 2017 at 5:55 AM, Kendall Nelson 
> wrote:
> Hello,
>
> It came up in a discussion today that it might be good to get together and
> discuss all the activities around on boarding and various other initial
> interactions to get us all on the same page and a little more
> organized/established.
>
> Given that SIGs have space the beginning of the week (Mon/Tuesday), I am
> proposing that we meet for one of these days. If you are interested, please
> let me know so I can get a headcount.
>
> -Kendall (diablo_rojo)
>
> __
> 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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

2017-12-11 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi Jay, 

Okay. Thanks for the clarification. Makes sense. 

Random-thinking:
Maybe the best would be to have a privilege level what covers the needs of 
MANO/NFVO, but still not full admin privileges. Do you think is this possible?

Br, 
Gerg0

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Monday, December 11, 2017 4:41 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the 
scope of the capacity query

On 12/11/2017 07:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> Hi Masahito,
> 
> Thanks for the answer.
> Some clarification questions. You mention that the NFVO works as both an user 
> and an admin for the cloud. Is this becouse the resource usage per user info 
> is more for cloud operators while the resource usage per tenant / per 
> resource provider is more for cloud users?
> 
> The solution you described is valid for the capacity per tenant case if I 
> understand right. Is this correct?

I think he is more referring to the fact that the MANO/NFVO service user must 
have administrative privileges in order to, for example, spawn new instances in 
multiple projects/tenants and communicate with the control plane to do things 
like adjust quotas, etc.

Best,
-jay

__
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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

2017-12-11 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi Masahito, 

Thanks for the answer. 
Some clarification questions. You mention that the NFVO works as both an user 
and an admin for the cloud. Is this becouse the resource usage per user info is 
more for cloud operators while the resource usage per tenant / per resource 
provider is more for cloud users?

The solution you described is valid for the capacity per tenant case if I 
understand right. Is this correct?

Thanks, 
Gerg0

-Original Message-
From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp] 
Sent: Friday, December 8, 2017 9:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the 
scope of the capacity query

Hi Gerg0,

I added some comments for GAP-04. It looks like NFVO works as an tenant user 
and an operator. IMHO, NFVO could calculate the capacity of the cloud.

best regards,
Masahito


On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> Hi,
> 
> During the Forum session about the ETSI NFV Gaps I received a request 
> to clarify the scope of the capacity query mentioned in [GAP-04] with ETSI 
> NFV.
> 
> The advice is that it should be possible to get the capacity of an 
> OpenStack tenant, an user and a resource provider. This is because the 
> NFVO might use different tenants and even different users to manage 
> the resources in the OpenStack instances.
> 
> Any comments are welcome, also if you need more clarification on the 
> gaps listed in [1] do not hesitate to contact me.
> 
> Br,
> 
> Gerg0
> 
> [1]: 
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined
> 
> 
> 
> __
>  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] [etsinfv][neutron][gap-09]: No state for subnets

2017-12-07 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Well, curently there is an operationalState specified into the subnets in 
IFA005/IFA006, but it was not specified what should happen when a subnet is 
disabled. This is what was commented in the joint meeting between ETSI NFV and 
OpenStack in Denver. During the discussions to resolve this issue we considered 
the suggestion to remove the state completly and decided for the removal.

By he way I use the api-ref [1] more, than the wiki. I believe it contains 
better information and for me it looks better.

[1]: https://developer.openstack.org/api-ref/network/v2/#show-subnet-details

Br,
Gerg0

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Thursday, December 7, 2017 10:05 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [etsinfv][neutron][gap-09]: No state for subnets

Hi,
Can you please elaborate more about the subnet state? FYI - 
https://wiki.openstack.org/wiki/Neutron/APIv2-specification#Subnet
Thanks
Gary

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, December 6, 2017 at 3:13 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [etsinfv][neutron][gap-09]: No state for subnets

Hi,

During the discussions in NFV#20 about the subnet state we argeed, that we 
should remove the state from the specification of subnets in IFA005 and IFA006. 
This invalidates [GAP-09] in [1].

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
__
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] [etsinfv][neutron][gap-09]: No state for subnets

2017-12-06 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

During the discussions in NFV#20 about the subnet state we argeed, that we 
should remove the state from the specification of subnets in IFA005 and IFA006. 
This invalidates [GAP-09] in [1].

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
__
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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

2017-12-06 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

During the Forum session about the ETSI NFV Gaps I received a request to 
clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.
The advice is that it should be possible to get the capacity of an OpenStack 
tenant, an user and a resource provider. This is because the NFVO might use 
different tenants and even different users to manage the resources in the 
OpenStack instances.

Any comments are welcome, also if you need more clarification on the gaps 
listed in [1] do not hesitate to contact me.

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained

__
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] Garbage patches for simple typo fixes

2017-09-22 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

Isn't it possible to ignore these patches in stackalytics? If the motivation is 
to look better there, this would solve the problem. 

Br, 
Gerg0

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: Friday, September 22, 2017 4:20 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Garbage patches for simple typo fixes

On 2017-09-22 08:30:21 -0400 (-0400), Amrith Kumar wrote:
[...]
> When can we take some concrete action to stop these same kinds of 
> things from coming up again and again?

Technical solutions to social problems rarely do more than increase complexity 
for everyone involved. Communication, documentation and education are likely 
our best options here, but I still question the degree to which the people 
pushing these sorts of contributions will actually get the message since it's 
obvious they aren't engaging meaningfully with the community before attempting 
to contribute.

Could demographic profiling help us figure out the primary motivation (whether 
it's testing the waters, stats padding or employers pushing their staff to 
contribute patches before they've had time to actually assimilate our community 
norms and expectations)?
--
Jeremy Stanley

__
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] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-09-13 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Thanks for the discussion yesterday.

Some notes about the topics we covered:
- Itroduction ETSI:
  - https://nfvwiki.etsi.org/images/WhyWhatHow-ETSINFV.pdf
- Introduction OpenStack:
  - https://nfvwiki.etsi.org/images/OpenStack_ETSI_NFV_workshop.pdf
- TST003 gaps
  - I will collect user stories for the gaps and collect feedback to make the 
gap desciptions better
- Glare
   - I will help from ETSI NFV side to implement the needed API and descriptions
- Plugtest
  - https://nfvwiki.etsi.org/images/NFV_PoCs_and_Plugtests.pdf
- Collaboration:
  - https://nfvwiki.etsi.org/images/OpenStack_Joint_meeting_TST_v2.pdf

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Tuesday, September 5, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Pierre Lynch_Internet <ply...@ixiacom.com>; Ildiko Vancsa 
<ild...@openstack.org>; 'Silvia Almagia' <silvia.alma...@etsi.org>; Diego 
Lopez_Internet <diego.r.lo...@telefonica.com>; Perala, Timo (Nokia - FI/Espoo) 
<timo.per...@nokia.com>; Laurent Vreck <laurent.vr...@etsi.org>; Michele 
CARIGNANI <michele.carign...@etsi.org>
Subject: RE: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hi,

We can try to squeeze it into the schedule. Can you collect your discussion 
topics to an etherpad so we can decide on the timing of the timeslot?

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Tuesday, September 5, 2017 3:46 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Yes, It will be even better! I can record a demo and publish it before the 
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com<mailto:mfedo...@gmail.com>]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0

-Original Message-
From: gordon chung [mailto:g...@live.ca<mailto:g...@live.ca>]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
_

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-09-09 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I’ve added this topic after TST003. Is this okay for everyone?
I think you should refer to IFA011 [1] in the VNF package data structure and 
additional data processing topic.

Br,
Gerg0

[1]: 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Friday, September 8, 2017 1:28 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Pierre Lynch_Internet <ply...@ixiacom.com>; Ildiko Vancsa 
<ild...@openstack.org>; Diego Lopez_Internet <diego.r.lo...@telefonica.com>; 
Perala, Timo (Nokia - FI/Espoo) <timo.per...@nokia.com>; Silvia Almagia 
<silvia.alma...@etsi.org>; Laurent Vreck <laurent.vr...@etsi.org>; Michele 
CARIGNANI <michele.carign...@etsi.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I created an etherpad with the topics I want to discuss:
https://etherpad.openstack.org/p/ptg-glare-etsi

There I want to make a brief overview of glare features, that may be useful for 
vnf packages support, and get a list of requirements from ETSI NFV delegates, 
they want to see in the catalog of VNF packages.

Best regards,
Mikhail Fedosin

On Tue, Sep 5, 2017 at 6:04 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

We can try to squeeze it into the schedule. Can you collect your discussion 
topics to an etherpad so we can decide on the timing of the timeslot?

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com<mailto:mfedo...@gmail.com>]
Sent: Tuesday, September 5, 2017 3:46 PM

To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Yes, It will be even better! I can record a demo and publish it before the 
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com<mailto:mfedo...@gmail.com>]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0

-Original Message-
From: gordon chung [mailto:g...@live.ca<mailto:g...@live.ca>]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunate

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-09-05 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

We can try to squeeze it into the schedule. Can you collect your discussion 
topics to an etherpad so we can decide on the timing of the timeslot?

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Tuesday, September 5, 2017 3:46 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Yes, It will be even better! I can record a demo and publish it before the 
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com<mailto:mfedo...@gmail.com>]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0

-Original Message-
From: gordon chung [mailto:g...@live.ca<mailto:g...@live.ca>]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
__
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<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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-09-04 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

One more clarification on this (GAP-05 of [1]): In this gap we are considering 
the notifications on capafity management of the infrastrucuture. For example a 
notification woudl be received when a new physical host is added or a host is 
removed. 

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained

Br, 
Gerg0

-Original Message-
From: Csatari, Gergely (Nokia - HU/Budapest) 
Sent: Monday, August 28, 2017 4:07 PM
To: openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hi, 

Thanks for the clarification. 

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko. 

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br, 
Gerg0


-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017


> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
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] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-09-01 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Thanks for the proposal. The aim of this workshop is to accelerate the 
collaboration between OpenStack and ETSI and not to execute demonstrations. 
However if you have technical questions to IFA about IFA007 then we can add 
that as an agenda point.

Br,
Gerg0

From: Mikhail Fedosin [mailto:mfedo...@gmail.com]
Sent: Friday, September 1, 2017 1:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

Hello!

I would also like to discuss the possibility of using Glare for cataloging VNF 
packages. Generally speaking Glare satisfies all the requirements from the 
standard 
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how 
glare can work with the packages. If this topic is interesting, then we can 
discuss it in more detail on Wednesday or Thursday in dedicated Glare team room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>> wrote:
Hi,

Thanks for the clarification.

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko.

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br,
Gerg0

-Original Message-
From: gordon chung [mailto:g...@live.ca<mailto:g...@live.ca>]
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017

> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
gord
__
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-08-28 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

Thanks for the clarification. 

Our understanding was that with Panko it is possible to subscribe to the state 
of the different resource of the cloud as it is descibed in [1]. This is why we 
mapped the Virtualised [Compute|Network|Storage] Resources Capacity Management 
Interfaces to Panko. 

[1]: https://wiki.openstack.org/wiki/Telemetry#Managed

Br, 
Gerg0


-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Monday, August 28, 2017 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack 
meets ETSI NFV workshop on 12.09.2017


> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined

i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you 
need storagE) and not Panko. Panko only handles storage of events (more 
metadata focused data) while Ceilometer handles the actual generation of both 
events and metrics, the latter being the one you want it seems. Gnocchi is used 
for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending the 
PTG but we can be reached on ML or #openstack-telemetry.

cheers,

--
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] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-08-28 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

Going inline. 

-Original Message-
From: Ghanshyam Mann [mailto:ghanshyamm...@gmail.com] 
Sent: Monday, August 28, 2017 1:03 PM

On Fri, Aug 25, 2017 at 10:58 PM, Csatari, Gergely (Nokia -
HU/Budapest) <gergely.csat...@nokia.com> wrote:
> Hi,
>
>
>
> During the week of the PTG ETSI NFV will have its plenary meeting in Denver.
> To benefit from this coincidence there will be a small workshop 
> between ETSI NFV delegates and OpenStack contributors in the PTG hotel.
>
>
>
> The workshop intends to provide a forum to identify and discuss the 
> common use cases and tasks between OpenStack and ETSI NFV and take 
> these items to the next level. The co-located workshop will be a 
> working event to discuss the gaps and requirements on both sides in 
> details and work on the technical solutions and next steps.
>
>
>
> We plan to cover the following agenda:
>
> ETSI NFV, Motivation and target, how to make things happen there 
> OpenStack, Motivation and target, how to make things happen there TST 
> 003 -> Gap analysis between ETSI NFV specifications and OpenStack 
> Collaboration via testing

Thanks Gergely for notifying this.
Ildiko also informed about this workshop in QA meeting and OpenStack QA team 
will try to join and help on this part.  Collaboration between both communities 
will be great. Myself and Andrea added our availability on etherpad.

[G0]: Okay, great.

> Introduction to the NFV PoC program and the opportunities around 
> Plugtests

I do not know the much details on this PoC program but would like to understand 
it more. In NEC, we are doing a PoC on NFV to deploy telecom app on multisite 
env with fault management and auto-scaling things. I would like to share that 
and collaborate in possible area.

[G0]: You will hear about the PoC program and the Plugtests from the best 
possible person. 

Br, 
Gerg0

>
>
>
> More detailed agenda and registration here:
> https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver
>
> Gaps to be discussed are here:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined
>
> (as most probably we will not have time to cover all of them, please 
> mark with +1 the ones which are interesting to you).
>
>
>
> Also please do not forget the workshop organized on Monday around 
> similar
> topics: https://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial
>
>
>
> In case of any questions do not hesitate to contact me.
>
>
>
> Br,
>
> Gerg0
>
>
>
>
> __
>  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] [os-upstream-institute][all] Get together at the PTG

2017-08-25 Thread Csatari, Gergely (Nokia - HU/Budapest)

Szia, 

Jovok. Nekem szerdatol jo. 

Udv, 
Gerg0

-Original Message-
From: Ildiko Vancsa [mailto:ildiko.van...@gmail.com] 
Sent: Friday, August 25, 2017 4:37 PM
To: openstack-dev@lists.openstack.org; openstack-d...@lists.openstack.org; 
user-committee 
Subject: [openstack-dev] [os-upstream-institute][all] Get together at the PTG

Hi Training Team and All,

As we have our next PTG coming up shortly I think that would be a great 
opportunity for the team and everyone who’s interested to meet and check where 
we are and what our future plans are. :)

I would like to ask you to raise your hand by replying to this mail if you will 
be around during the PTG week in Denver and would be interested in joining. 
Please also indicate your availability for the week.

Based on the responses we will pick a day and a time that works best for most 
to have our gathering.

Please let me know if you have any questions.

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] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-08-25 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

During the week of the PTG ETSI NFV will have its plenary meeting in Denver. To 
benefit from this coincidence there will be a small workshop between ETSI NFV 
delegates and OpenStack contributors in the PTG hotel.

The workshop intends to provide a forum to identify and discuss the common use 
cases and tasks between OpenStack and ETSI NFV and take these items to the next 
level. The co-located workshop will be a working event to discuss the gaps and 
requirements on both sides in details and work on the technical solutions and 
next steps.

We plan to cover the following agenda:

  *   ETSI NFV, Motivation and target, how to make things happen there
  *   OpenStack, Motivation and target, how to make things happen there
  *   TST 003 -> Gap analysis between ETSI NFV specifications and OpenStack
  *   Collaboration via testing
  *   Introduction to the NFV PoC program and the opportunities around Plugtests

More detailed agenda and registration here: 
https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver
Gaps to be discussed are here: 
https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
(as most probably we will not have time to cover all of them, please mark with 
+1 the ones which are interesting to you).

Also please do not forget the workshop organized on Monday around similar 
topics: https://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial

In case of any questions do not hesitate to contact me.

Br,
Gerg0

__
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] [all] Secrets of edit-constraints

2017-08-14 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

I have an interesting situation with the parametrization of edit-constraints in 
tools/tox_install.sh. This happens at the moment in neutron-lib, but as amotoki 
pointed out in [1] the same should happen in any projects (and actually was 
happening with me in Vitrage and Mistral).

Here is what I experience:
With the current parameters of edit-constraints (edit-constraints $localfile -- 
$LIB_NAME "-e file://$PWD#egg=$LIB_NAME") the library itself (neutron-lib in 
this case) is added to upper-constraints.txt and the installation fails with 
"Could not satisfy constraints for 'neutron-lib': installation from path or url 
cannot be constrained to a version".
If I modify the parameters of edit-constraints in a way that it removes the 
library (neutron-lib in this case) instead of adding (edit-constraints 
$localfile $LIB_NAME --) it my build succeeds (as I'm playing with api-ref I 
use tox -r -e api-ref, but the same also happens with tox -r -e pep8).

Is this happening with only me?

Thanks,
Gerg0

[1]: https://review.openstack.org/#/c/492158/1
__
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] [mistral][core] Proposing Andras Kovi to the Mistral core team

2017-08-10 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

+1 (from an other Nokia guy, who knows Andras personally and agrees, that he is 
a good guy ☺)

Br,
Gerg0

From: Dougal Matthews [mailto:dou...@redhat.com]
Sent: Thursday, August 10, 2017 9:54 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the 
Mistral core team



On 10 August 2017 at 06:34, Renat Akhmerov 
> wrote:
Hi,

I’d like to propose Andras Kovi to the Mistral core team.

The current statistics of Andras can be seen at [1].
Andras has been contributing for about 1.5 years and in Pike he increased his 
activity significantly, primarily reviewing. His reviews are always thorough 
and insightful. He cares about code quality. He knows both OpenStack ecosystem 
and Mistral architecture and codebase well. Adding Andras to the core team 
would be also very useful for us because he is a very active user of Mistral, 
he implemented or participated in implementation of lots of Nokia CBAM use 
cases based on Mistral.
Andras also gave an excellent presentation about Mistral performance in Boston, 
[2]. I’d really recommend to watch it if you work with Mistral as a contributor 
or as a user.
Speaking less formally, Andras is a very good guy, deep thinker with a great 
experience in software programming. Every time I have a chance to meet him 
personally it’s a lot of fun to talk to him and learn from him.

So I’m asking you to support me in this promotion. I really believe that Andras 
will be an invaluable addition to our team.

+1, from me. Andras has given some very useful reviews and I look forward to 
more :-)


[1] http://stackalytics.com/?module=mistral-group_id=akovi
[2] https://www.openstack.org/videos/boston-2017/mistral-performance-in-numbers

Thanks

Renat Akhmerov
@Nokia

__
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] [all] Upstream Training Team meeting at PTG - Are you coming?

2017-02-22 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in Savannah 3.
Br,
Gerg0

Sent from Nine

From: Ildiko Vancsa 
Sent: Feb 21, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; user-committee
Subject: Re: [openstack-dev] [all] Upstream Training Team meeting at PTG - Are 
you coming?

Hi All,

A quick reminder that we will have our face to face gathering on __Wednesday 
(tomorrow) at lunch time (12pm ET)__.

I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch box 
after the morning sessions and join us for lunch if you would like to get 
involved with the Upstream Training and/or new contributor on boarding 
activities.

Thanks and Best Regards,
Ildikó
IRC: ildikov

> On 2017. Feb 15., at 13:16, Ildiko Vancsa  wrote:
>
> Hi,
>
> We are forming a virtual upstream collaboration training team including 
> everyone who’s either helping us out with maintaining and improving the 
> training material and/or who are attending the course as coaches or mentors.
>
> We are planning to meet at the PTG in person next week on Wednesday at lunch 
> time. We picked this slot as our first face to face gathering as all of us 
> have project related assignments to drive and sessions to attend that makes 
> scheduling a meeting even more challenging.
>
> If you are interested in what we are doing and how we are trying to make the 
> on boarding process for new contributors a pleasant experience and would like 
> to join our activities meet us there!
>
> The meeting time is __Wednesday (February 22) lunch time__. I will share the 
> meeting point next week before the meeting.
>
> If you would like to have a mail reminder prior to the meeting next week 
> please reach out to me.
>
> 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

Re: [openstack-dev] Time to retire nova-docker?

2016-12-27 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Zun provides a lifecycle management interface for the containers started in the 
COE deployed with Magnum. In other words a COE is still needed for Zun. For 
more information look the Zun wiki.
Internally, to separate the started containers into different sandboxes Zun 
uses a fork of nova-docker driver which was developed further to fulfill the 
specific needs of Zun.
To have support for containers without an additional COE to Nova  Zun provides 
no solution.
I’ve added Hongbin to the mail to correct me if I’m wrong about Zun.

Br,
Gerg0

From: Esra Celik [mailto:celik.e...@tubitak.gov.tr]
Sent: Monday, December 26, 2016 7:38 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

Hi Jay, I was asking because our discussions to contribute to nova-docker 
project ran across the discussions here to retire the project :)

Hongbin, that is exactly what I meant. Using nova-docker it deploys containers 
to physical machines, not virtual machines.
Using Ironic driver with Magnum is a solution, but I guess every time creating 
a cluster with Magnum it will redeploy the operating system for the selected 
physical machine, which is not necessary.
I will investigate Zun project more, thank you very much. What would you say 
for its current maturity level?

Kimden: "Hongbin Lu" >
Kime: "OpenStack Development Mailing List (not for usage questions)" 
>
Gönderilenler: 26 Aralık Pazartesi 2016 17:53:00
Konu: Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

I guess "extra virtualization layer" means Magnum provisions a Container 
Orchestration Engines (COE) on top of nova instances. If the nova instances are 
virtual machines, there is a "extra virtualization layer".

I think you could consider using Magnum with Ironic driver. If the driver is 
Ironic, COEs are deployed to nova instances that are physical machines provided 
by Ironic. Zun project [1] could be another option for your use case. Zun is 
similar to nova-docker, which enables running containers on compute hosts. You 
could find a thoughtful introduction here [2].

[1] https://wiki.openstack.org/wiki/Zun
[2] 
http://www.slideshare.net/hongbin034/zun-presentation-openstack-barcelona-summit

Best regards,
Hongbin

On Mon, Dec 26, 2016 at 8:23 AM, Jay Pipes 
> wrote:

On 12/26/2016 08:23 AM, Esra Celik wrote:

Hi All,

It is very sad to hear nova-docker's retirement. Me and my team (3) are
working for a cloud computing laboratory and we were very keen on
working with nova-docker.
After some research about its current state I saw these mails. Will you
actually propose another equivalent to nova-docker or is it just the
lack of contributors to this project?
Some of the contributors previously advised us the magnum project
instead of nova-docker, however it does not satisfy our needs because of
the additional virtualization layer it needs.
If the main problem is the lack of contributors we may participate in
this project.
There's never any need to ask permission to contribute to a project :) If 
nova-docker driver is something you cannot do without, feel free to contribute 
to it.

That said, Magnum does seem to be where most of the docker-related 
contributions to the compute landscape have moved. So, it's more likely you 
will find company in that project and perhaps be able to make more effective 
contributions there. Can I ask what is the "extra virtualization layer" that 
you are referring to in Magnum?

Best,
-jay

__
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] [osc]: Support for allowed-address-pairs in osc?

2016-11-21 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi,

Is there any way to configure allowed-address-pairs in osc?

Thanks,
Gerg0
__
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] Let's clean up APi reference

2016-08-18 Thread Csatari, Gergely (Nokia - HU/Budapest)

Hi, 

https://review.openstack.org/#/c/327112/ targets the parameter verification for 
servers-actions.inc.

Br, 
Gerg0

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Thursday, August 18, 2016 2:33 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] Let's clean up APi reference

On 08/18/2016 08:16 AM, Akihiro Motoki wrote:
> Hi Neutron team,
> 
> As you may know, the OpenStack API references have been moved into
> individual project repositories, but it contains a lot of wrong
> information now :-(
> 
> Let's clean up API reference.
> It's now time to start the clean up and finish the cleanup by Newton-1.
> 
> I prepared the etherpad page to share the guideline of the cleanup and
> useful information.
> This page shares my experience of 'router' resource cleanup.
> 
> https://etherpad.openstack.org/p/neutron-api-ref-sprint
> 
> I hope everyone work on at least one resource :)
> The etherpad page has the progress tracking section (bottom of the page)
> Make sure to add your name when you start to work.
> 
> Feel free to ask me if you have a question.
> 
> Thanks,
> Akihiro

Fwiw, I built a burndown dashboard for this with Nova -
http://burndown.dague.org/ (source -
https://github.com/sdague/rst-burndown). It should be reasonably
adaptable to other projects if you have a host to run it on.

-Sean

-- 
Sean Dague
http://dague.net

__
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

46 matches

Mail list logo