date:20141027

On Mon, Oct 27, 2014 at 4:42 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 27/10/14 02:18, Li Tianqing wrote:
 Hello, Right now, we test neutron under havana release. We
 configured network_device_mtu=1450 in neutron.conf, After create
 vm, we found the vm interface's mtu is 1500, the ping, ssh, is ok.
 But if we scp large file between vms then scp display 'stalled'.
 And iperf is also can not completed. If we configured vm's mtu to
 1450, then iperf, scp all is ok. If we iperf with -M 1300, then the
 iperf is ok too. The vms path mtu discovery is set by default. I do
 not know why the vm whose mtu is 1500 can not send large file.

 There is a neutron spec currently in discussion for Kilo to finally
 fix MTU issues due to tunneling, that also tries to propagate MTU
 inside instances: https://review.openstack.org/#/c/105989/

This is something which would be quite fantastic to land in Kilo, as
multiple people have been bit by this particular issue.

 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

 iQEcBAEBCgAGBQJUThORAAoJEC5aWaUY1u571u4H/3EqEVPL1Q9KgymrudLpAdRh
 fwNarwPWT8Ed+0x7WIXAr7OFXX1P90cKRAZKTlAEEI94vOrdr0s608ZX8awMuLeu
 +LB6IA7nMpgJammfDb8zNmYLHuTQGGatXblOinvtm3XXIcNbkNu8840MTV3y/Jdq
 Mndtz69TrjTrjn7r9REJ4bnRIlL4DGo+gufXPD49+yax1y/woefqwZPU13kO6j6R
 Q0+MAy13ptg2NwX26OI+Sb801W0kpDXby6WZjfekXqxqv62fY1/lPQ3oqqJBd95K
 EFe5NuogLV7UGH5vydQJa0eO2jw5lh8qLuHSShGcDEp/N6oQWiDzXYYYoEQdUic=
 =jRQ/
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
 Several people have been requesting that we resume the Advanced
 Services' meetings [1] to discuss some of the topics being mentioned
 in this thread. Perhaps it might help people to have a focussed
 discussion on the topic of advanced services' spin-out prior to the
 design summit session [2] in Paris. So I propose that we resume our
 weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
 #openstack-meeting-3.

Given how important this is to Neutron in general, I would prefer NOT
to see this discussed in the Advanced Services meeting, but rather in
the regular Neutron meeting. These are the types of things which need
broader oversight and involvement. Lets please discuss this in the
regular Neutron meeting, which is an on-demand meeting format, rather
than in a sub-team meeting.

 Thanks,
 ~Sumit.

 [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
 [2] 
 http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y

 On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
 skand...@cisco.com wrote:
 Hi Doug:

 On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:

Hi Brandon,

 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

I agree with this sentiment.  I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.  We
love each other.  Check.  Things are going to change sometime.  Check.  We
might spin-out someday.  Check.  Now, let¹s jump to the interesting part.

 3. The main reason a spin out makes sense from Neutron is that the scope
 for Neutron is too large for the attention advances services needs from
 the Neutron Core.  If all of advanced services spins out, I see that

There is merit here, but consider the sorts of things that an advanced
services framework should be doing:

- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services

Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work.  And there
are specific reasons for that.  But, maybe we can at least take steps to
not be incompatible about it.  Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time.  It¹s at least worth a
conversation or three.

 In total agreement and I have heard these sentiments in multiple
 conversations across multiple players.
 It would be really fruitful to have a constructive conversation on this
 across the services, and there are
 enough similar issues to make this worthwhile.

 Thanks

 Sridar


Thanks,
Doug




On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

Good questions Doug.  My answers are as follows:

1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core.  If all of advanced services spins out, I see that
repeating itself within an advanced services project.  More and more
advanced services will get added in and the scope will become too
large.  There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.

Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.

Thanks,
Brandon

On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
 Hi all,

 Before we get into the details of which API goes where, I¹d like to see
us
 answer the questions of:

 1. Are we spinning out?
 2. When?
 3. With or without the rest of advanced services?
 4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
 had the Paris summit discussions on vendor split-out and adv. services
 spinout before we answer those questions?  (Yes, that question is
leading.)

 To me, the ³where does the API live² is an implementation detail, and
not
 where the time will need to be spent.

 For the record, my answers are:

 1. Yes.
 2. I don¹t know.
 3. I don¹t know; this needs some serious discussion.
 4. Yes.

 Thanks,
 doug

 On 10/24/14, 3:47 PM, Brandon Logan

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com wrote:
 Hi Brandon,

 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

 I agree with this sentiment.  I’d just like to pull-up to the decision
 level, and if we can get some consensus on how we move forward, we can
 bring a concrete plan to the summit instead of 40 minutes of Kumbaya.  We
 love each other.  Check.  Things are going to change sometime.  Check.  We
 might spin-out someday.  Check.  Now, let’s jump to the interesting part.

I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.

 3. The main reason a spin out makes sense from Neutron is that the scope
 for Neutron is too large for the attention advances services needs from
 the Neutron Core.  If all of advanced services spins out, I see that

 There is merit here, but consider the sorts of things that an advanced
 services framework should be doing:

 - plugging into neutron ports, with all manner of topologies
 - service VM handling
 - plugging into nova-network
 - service chaining
 - applying things like security groups to services

 … this is all stuff that Octavia is talking about implementing itself in a
 basically defensive manner, instead of leveraging other work.  And there
 are specific reasons for that.  But, maybe we can at least take steps to
 not be incompatible about it.  Or maybe there is a hierarchy of Neutron -
 Services - LB, where we’re still spun out, but not doing it in a way that
 we have to re-implement the world all the time.  It’s at least worth a
 conversation or three.

Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.

Thanks,
Kyle

[1] https://etherpad.openstack.org/p/neutron-services

 Thanks,
 Doug




 On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

Good questions Doug.  My answers are as follows:

1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core.  If all of advanced services spins out, I see that
repeating itself within an advanced services project.  More and more
advanced services will get added in and the scope will become too
large.  There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.

Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.

Thanks,
Brandon

On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
 Hi all,

 Before we get into the details of which API goes where, I’d like to see
us
 answer the questions of:

 1. Are we spinning out?
 2. When?
 3. With or without the rest of advanced services?
 4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
 had the Paris summit discussions on vendor split-out and adv. services
 spinout before we answer those questions?  (Yes, that question is
leading.)

 To me, the “where does the API live” is an implementation detail, and
not
 where the time will need to be spent.

 For the record, my answers are:

 1. Yes.
 2. I don’t know.
 3. I don’t know; this needs some serious discussion.
 4. Yes.

 Thanks,
 doug

 On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 With the recent talk about advanced services spinning out of Neutron,
 and the fact most of the LBaaS community has wanted LBaaS to spin out
of
 Neutron, I wanted to bring up a possibility and gauge interest and
 opinion on this possibility.
 
 Octavia is going to (and has) an API.  The current thinking is that an
 Octavia driver will be created in Neutron LBaaS that will make a
 requests to the Octavia API.  When LBaaS spins out of Neutron, it will
 need a standalone API.  Octavia's API seems to be a good solution to
 this.  It will support vendor drivers much like the current Neutron
 LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an
 exact duplicate.  Octavia will be growing more mature in stackforge at
a
 higher velocity than an Openstack project, so I expect by the time Kilo
 comes around it's API will be very mature.
 
 Octavia's API doesn't have to be called Octavia either.  It can be

Re: [openstack-dev] [MagnetoDB] PTL Candidacy

2014-10-27 Thread Sergey Lukjanov

Ack.

On Fri, Oct 24, 2014 at 4:41 PM, Ilya Sviridov isviri...@mirantis.com
wrote:

 Hello openstackers,

 I'd like to announce  my candidacy as PTL of MagnetoDB[1][2][3] project.

 As a PTL of MagnetoDB I'll continue my work on building great environment
 for contributors, making MagnetoDB well known and great software product.

 [1] https://launchpad.net/magnetodb
 [2] http://stackalytics.com/report/contribution/magnetodb/90
 [3]
 http://stackalytics.com/?release=junometric=commitsproject_type=stackforgemodule=magnetodb-group

 Thank you,
 Ilya Sviridov
 isviridov @ FreeNode




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FreeBSD host support

On Mon, Oct 27, 2014 at 8:39 AM, Michael Still mi...@stillhq.com wrote:
 On Tuesday, October 21, 2014, Roman Bogorodskiy rbogorods...@mirantis.com
 wrote:

 On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon joe.gord...@gmail.com
 wrote:
  On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy
  rbogorods...@mirantis.com wrote:


 [snip]


  High level overview of what needs to be done:
 
   - Nova
* linux_net needs to be re-factored to allow to plug in FreeBSD
  support (that's what the spec linked above is about)
* nova.virt.disk.mount needs to be extended to support FreeBSD's
  mdconfig(8) in a similar way to Linux's losetup


 [snip]


  What about neutron? We are in the process of trying to deprecate
  nova-network, so any new thing needs to support neutron.


 AFAIK, there's no defined migration plan yet, unless I missed that.
 Anyway, I don't see any blockers regarding an implementation of a driver
 similar to linuxbridge that'd work on FreeBSD.

 Also, Semihalf guys are working on OpenContail/FreeBSD and
 Neutron/OpenContrial support, so that's an option as well.


 I have no problem with supporting FreeBSD as a hypervisor operating system,
 especially if there is a solid team on the FreeBSD side that will commit to
 maintaining the changes required and adding the necessary CI (especially
 ensuring that when it breaks it gets fixed).

 However, I see Neutron support as a firm requirement. We've spent a large
 amount of time getting closer and closer to deprecating nova-network.
 Despite opening it up for limited development again, I don't think we should
 be making the transition plan harder by introducing new features that don't
 work with Neutron.

+1000

During Juno we closed a huge amount of the gap, I agree with Michael's
sentiment above.

Thanks,
Kyle

 Michael


 --
 Rackspace Australia

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


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

Re: [openstack-dev] [MagnetoDB] PTL Elections

2014-10-27 Thread Sergey Lukjanov

The candidates nomination part is ended. Due to the fact that we have only
one candidate, we're not running elections itself.

So, congratulations to Ilya Sviridov!

https://wiki.openstack.org/wiki/MagnetoDB/PTL_Elections_Kilo

On Wed, Oct 22, 2014 at 10:18 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi folks,

 due to the requirement to have PTL for the program, we're running
 elections for the MagnetoDB PTL for Kilo cycle. Schedule and policies
 are fully aligned with official OpenStack PTLs elections.

 You can find more info in official elections wiki page [0] and
 the same page for MagnetoDB elections [1], additionally some more info
 in the past official nominations opening email [2].

 Timeline:

 till 05:59 UTC October 27, 2014: Open candidacy to PTL positions
 October 27, 2014 - 1300 UTC October 31, 2014: PTL elections

 To announce your candidacy please start a new openstack-dev at
 lists.openstack.org mailing list thread with the following subject:
 [MagnetoDB] PTL Candidacy.

 [0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
 [1] https://wiki.openstack.org/wiki/MagnetoDB/PTL_Elections_Kilo
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html

 Thank you.

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories

2014-10-27 Thread ZZelle

Hi Ondrej,

Could you clarify your needs?

If you allow your devs to commit code on your local gerrit,
then your repo will differ from OpenStack one
and you might have merge troubles when you will resync your repo with
OpenStack one
How will you handle them?


Cédric/ZZelle





On Mon, Oct 27, 2014 at 12:24 PM, Ondrej Wisniewski 
ondrej.wisniew...@dektech.com.au wrote:

  Hi Riccardo

 thanks for pointers you provided. I had a look at the Gerrit replication
 feature and the description says:
 *Gerrit can automatically push any changes it makes to its managed Git
 repositories to another system.*

 What I need would be exactly the opposite. I need to update the Gerrit
 managed Git repository with the upstream community Git repository.
 How would I go about that?

 What I tried was defining the community repository as remote origin and
 then do git remote update. This updates the remote references but doesn't
 update the local branches.

 Thanks, Ondrej


 On 10/24/2014 06:56 PM, Ricardo Carrillo Cruz wrote:

 Hi Ondrej

  The replication between Gerrit and git mirrors is done by the Gerrit
 replication mechanism.

  If you look at this line in the gerrit manifest:


 http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/manifests/init.pp#n255

  you will see that it deploys a 'replication.config' file based on
 template:


 http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/templates/replication.config.erb

  You can find more information about how Gerrit replication works here:


 http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html

  HTH

  Regards

 2014-10-24 18:25 GMT+02:00 Ondrej Wisniewski 
 ondrej.wisniew...@dektech.com.au:

  Hi,

 I am trying to set up an OpenStack development workflow in our company.
 We have an internal Git repository mirror of all OpenStack projects we are
 working on. It is periodically updated from the upstream OpenStack
 community servers. This is used to share the code among developers.

 Furthermore I have set up a Gerrit server for the internal code review.
 The Gerrit server also works with repository mirrors of the community
 repositories which should be updated periodically. Or at least that's the
 idea. I ran into lots of problems and couldn't find a good way of
 synchronizing the developer mirrors with the Gerrit repositories.

 So to cut a long story short, here are my questions:
 How is the synchronization of the OpenStack community Git repositories
 and the Gerrit server done?
 How can I import an OpenStack project into my Gerrit system from my local
 Git mirror and keep both synchronized (at least the master branch) ?

 I would be really appreciate if someone could shed some light on this.
 Thanks, Ondrej


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


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

Re: [openstack-dev] [poppy] Proposal to add Malini Kamalambal (malini) as a Core Reviewer

2014-10-27 Thread Amit Gandhi

I am pleased to announce that Malini Kamalambal as been promoted to Core for 
Poppy.

Thanks
Amit.

From: Amit Gandhi amit.gan...@rackspace.commailto:amit.gan...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, October 24, 2014 at 2:11 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [poppy] Proposal to add Malini Kamalambal (malini) as 
a Core Reviewer

Hi folks,

I’d like to propose adding Malini Kamalambal (malini) as a core reviewer on the 
Poppy team. She has been contributing regularly since the start of Poppy, and 
has proven to be a careful reviewer with good judgment.  She also brings a lot 
of insight into Openstack best practices from her experience working on Zaqar, 
where she also is a Core Reviewer.

All Poppy ATC’s, please respond with a +1 or –1.

Thanks

Amit Gandhi
@amitgandhinz
Poppy PTL

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

Re: [openstack-dev] [Glance][Artifacts] Glance Artifacts Repository as a standalone service

2014-10-27 Thread Solly Ross

Just my two cents, since I won't be able to make it to summit:

When the artifact repository was proposed, I personally really liked the idea 
that images
were just another artifact type eventually, even if they stayed separate for 
the time being.

However, the pros that you bring up do seem to make a lot of sense -- being 
able to design an
API from scratch can lead to nicer APIs, and having the ability to use 
different backends
for images vs artifacts could be quite useful from a performance perspective.

Thus, let me propose this: what if you allowed different pools of artifacts 
to be housed on
different backends and/or endpoints?  This way, you could still put images in 
their own little bubble
without losing the image -- artifact abstraction.  It would also allow you to 
extend some of the pros
of the split to other artifact types, since a cloud admin could have other 
artifacts besides images that
needed to be in their own little bubble for performance reasons.

For instance, a cloud administrator could define three pools (for lack of a 
better term ATM): images, general, and critical-data, images and 
critical-data might be stored on specially-tuned high-performance backends, 
while critical-data might be on a large general-purpose backend.

Best Regards,
Solly Ross

- Original Message -
 From: Alexander Tivelkov ativel...@mirantis.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, October 27, 2014 8:08:47 AM
 Subject: [openstack-dev] [Glance][Artifacts] Glance Artifacts Repository as   
 a standalone service
 
 Hi stackers,
 
 It has been some time since the announcement of Artifacts initiative
 within the Glance. The feature was not complete in Juno, but is being
 actively developed now and has good chances for landing in Kilo.
 However, recently on the Glance Virtual Mini-summit we had a
 discussions which lead to an idea to change one of the core design
 concepts of the Glance Artifact repository [1]
 
 Initially we planned to run Artifact repository as part of existing
 Glance service(s): all the APIs to handle artifacts were supposed to
 be hosted by glance-api service, with glance-registry as optional
 backend. Artifact-related endpoints were designed to be in the /v2/
 branch of the API hierarchy, and were supposed to be similar in syntax
 and semantics to the existing v2/images endpoints.
 
 Now it is suggested to host artifacts as a standalone process
 listening to a different port (and probably deployed on a different
 host) and registered in the keystone as a separate service type.
 The code will be still part of the primary Glance repo - so this is
 not the question of starting another project or program, this is just
 about having a new daemon in the openstack deployment.
 
 This approach has some obvious pros and some less-obvious cons.
 Most important is the ability to load-balance images and artifacts
 independenly, being sure that any load on artifacts repo does no
 affect the performance of images - and vice versa. Also, this will
 allow us to provide different configuration options (including
 different backing storages) to these different components which will
 increase the overall flexibility and customizability of the system.
 We'll be able to design the artifacts API from scratch without the
 need to comply with the existing semantics and architecture of
 images-part, reusing only the components which are really needed.
 
 At the same time we'll loose the transparency between the concepts of
 image and artifact: initially we planned to make them very
 similar, so when we are finally ready to make images just one of the
 available artifact types, the migration may be trivial. If we now
 separate them into different services, we draw a strict border and
 potentially complicate the migration.
 
 IMHO, the pros outweigh the cons, so I personally like the idea of
 service separation - and all the participants of our virtual summit
 seemed to share the same opinion. However, it is a serious design
 change, so I'd like to hear the opinions of the wider audience.
 
 We have planned a design session in Paris  ([2]) to discuss this
 change in more details (the topic is applicable not only to Artifacta,
 but to other initiatives under the hood of Glance as well, e.g.
 metadef catalog, index service etc) - please feel free to join and
 discuss. And please do not hesitate to share any concerns in the
 mailing list before the summit starts: the more opinions we have, the
 better solution we will make.
 
 
 
 [1]
 https://etherpad.openstack.org/p/kilo-glance-artifacts-current-state-of-development
 [2] https://etherpad.openstack.org/p/kilo-glance-summit-topics-final
 
 --
 Regards,
 Alexander Tivelkov
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] How can we get more feedback from users?-- Great idea Angus!

2014-10-27 Thread Brad Topol

Angus,

Makes sense.   We need to make the process of being able to provide user 
experience feedback a pleasant user experience in itselt :-).  I went to 
https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group  but 
could not see an easy way to provide feedback from this page.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Angus Salkeld asalk...@mirantis.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, 
Date:   10/26/2014 07:20 AM
Subject:Re: [openstack-dev] [all] How can we get more feedback 
from users?-- Great idea Angus!




On Sat, Oct 25, 2014 at 1:20 AM, Brad Topol bto...@us.ibm.com wrote:
+100!   Angus this is awesome!!!   Anyway to get one of these for each 
project? 


Anyone can make an etherpad, but as Tim suggested I think we need to work 
with the Application Ecosystem WG
to do this in a consistent way. I'll look into doing that.
https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group

-Angus
 
Thanks, 

Brad 


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680 



From:Sandy Walsh sandy.wa...@rackspace.com 
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, 
Date:10/24/2014 09:46 AM 
Subject:Re: [openstack-dev] [all] How can we get more feedback 
from users? 



Nice work Angus ... great idea. Would love to see more of this.   

-S 


From: Angus Salkeld [asalk...@mirantis.com]
Sent: Friday, October 24, 2014 1:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] How can we get more feedback from users?

Hi all

I have felt some grumblings about usability issues with Heat 
templates/client/etc.. 
and wanted a way that users could come and give us feedback easily (low 
barrier). I started an etherpad (
https://etherpad.openstack.org/p/heat-useablity-improvements) - the first 
win is it is spelt wrong :-O

We now have some great feedback there in a very short time, most of this 
we should be able to solve.

This lead me to think, should OpenStack have a more general mechanism for 
users to provide feedback. The idea is this is not for bugs or support, 
but for users to express pain points, requests for features and 
docs/howtos.

It's not easy to improve your software unless you are listening to your 
users.

Ideas?

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


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

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

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

Re: [openstack-dev] [all] Key signing at the summit?

On 2014-10-26 17:01:07 -0700 (-0700), Clint Byrum wrote:
 Hi everyone! We have a summit rapidly approaching, and to my knowledge,
 no key signing event planned. That is unfortunate, as the web of trust
 that we started building in Atlanta would be quite stronger as we add
 more European developers who I'm sure will be present in large numbers
 due to proximity.
[...]

I took the prior lack of discussion on the ML to imply interest in
repeating the exercise in an organized fashion was low. Those of us
who regularly engage in ad-hoc keysigning will likely already have
business cards or slips with full key fingerprints/names and
passports or similar ID with us already. Since the majority of the
OpenStack WoT is currently between release management, quality
assurance and project infrastructure teams, I proposed this is one
of the things which can go on quietly in the background over the
course of our shared meet-up on Friday.

If there is interest in doing another Sassaman-Projected Method
exercise at future events, a USB document camera would be useful to
procure in advance (my earlier experiment with the digital
microscope worked well in the lab but was not so successful in the
wild since I ended up lacking a tall enough stand to properly
encompass larger IDs and so had to try some pretty hacky
workarounds). There is relatively inexpensive equipment on the
market which does this sort of thing well and is compact enough to
easily bring in luggage, I just don't happen to have anything like
that on hand currently.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

2014-10-27 Thread Carl Baldwin

On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com wrote:
 Hello Itzik,
 This has been discussed lately on this ML. Please see
 https://bugs.launchpad.net/neutron/+bug/1335375.

This is a good example that any create, update, or delete of a SG rule
can expose this issue.  This bug only mentions delete.  I'll update
the bug to increase the scope beyond just deletes because it really is
the same conntrack issue at the root of the problem.

Carl

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

Re: [openstack-dev] FreeBSD host support

2014-10-27 Thread Monty Taylor

On 10/27/2014 06:39 AM, Michael Still wrote:
 On Tuesday, October 21, 2014, Roman Bogorodskiy rbogorods...@mirantis.com
 wrote:
 
 On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon joe.gord...@gmail.com
 javascript:; wrote:
 On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy 
 rbogorods...@mirantis.com javascript:; wrote:

 
 [snip]
 
 
 High level overview of what needs to be done:

  - Nova
   * linux_net needs to be re-factored to allow to plug in FreeBSD
 support (that's what the spec linked above is about)
   * nova.virt.disk.mount needs to be extended to support FreeBSD's
 mdconfig(8) in a similar way to Linux's losetup

 
 [snip]
 
 
 What about neutron? We are in the process of trying to deprecate
 nova-network, so any new thing needs to support neutron.


 AFAIK, there's no defined migration plan yet, unless I missed that.
 Anyway, I don't see any blockers regarding an implementation of a driver
 similar to linuxbridge that'd work on FreeBSD.

 Also, Semihalf guys are working on OpenContail/FreeBSD and
 Neutron/OpenContrial support, so that's an option as well.
 
 
 I have no problem with supporting FreeBSD as a hypervisor operating system,
 especially if there is a solid team on the FreeBSD side that will commit to
 maintaining the changes required and adding the necessary CI (especially
 ensuring that when it breaks it gets fixed).

I believe that the CI related things that would be needed would be:

- solid devstack support
- someone willing to step up and make sure that nodepool can provide
freebsd images like ianw recently did with centos

 However, I see Neutron support as a firm requirement. We've spent a large
 amount of time getting closer and closer to deprecating nova-network.
 Despite opening it up for limited development again, I don't think we
 should be making the transition plan harder by introducing new features
 that don't work with Neutron.

I agree with Mikal on this.

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


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

[openstack-dev] [mistral] canceling team meeting today

2014-10-27 Thread Renat Akhmerov

Folks, we are canceling today's team meeting since several key members won't be 
able to join.

Sent from Renat's iPad
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] How can we get more feedback from users?-- Great idea Angus!

On 2014-10-27 10:39:02 -0400 (-0400), Brad Topol wrote:
 Makes sense.   We need to make the process of being able to
 provide user experience feedback a pleasant user experience in
 itselt :-).  I went to https:
 //wiki.openstack.org/wiki/Application_Ecosystem_Working_Group  but
 could not see an easy way to provide feedback from this page.

Perhaps a link to https://www.openstack.org/user-survey from there
would be appropriate?
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories

2014-10-27 Thread Ondrej Wisniewski

Hi Cédric,

I have basically two internal OpenStack mirrors (bare Git repositories).
One is to share code contributions among the dev team members, the other
is handled by Gerrit and this is where the devs send code for review.
Both should be updated periodically from the upstream servers. While
this works fine for the first one doing git remote update, it doesn't
seem to be that easy for the Gerrit repositories.

The push operations to the OpenStack repositories are a different story.

Ondrej

/On 10/27/2014 03:22 PM, ZZelle wrote://
/

Hi Ondrej,

Could you clarify your needs?

If you allow your devs to commit code on your local gerrit,
then your repo will differ from OpenStack one
and you might have merge troubles when you will resync your repo with
OpenStack one

How will you handle them?

Cédric/ZZelle

On Mon, Oct 27, 2014 at 12:24 PM, Ondrej Wisniewski
ondrej.wisniew...@dektech.com.au
mailto:ondrej.wisniew...@dektech.com.au wrote:

Hi Riccardo

thanks for pointers you provided. I had a look at the Gerrit
replication feature and the description says:
/Gerrit can automatically push any changes it makes to its
managed Git repositories to another system./

What I need would be exactly the opposite. I need to update the
Gerrit managed Git repository with the upstream community Git
repository.
How would I go about that?

What I tried was defining the community repository as remote
origin and then do git remote update. This updates the remote
references but doesn't update the local branches.

Thanks, Ondrej

On 10/24/2014 06:56 PM, Ricardo Carrillo Cruz wrote:

Hi Ondrej

The replication between Gerrit and git mirrors is done by the
Gerrit replication mechanism.

If you look at this line in the gerrit manifest:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/manifests/init.pp#n255

you will see that it deploys a 'replication.config' file based on
template:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/templates/replication.config.erb

You can find more information about how Gerrit replication works
here:

http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html

HTH

Regards

2014-10-24 18:25 GMT+02:00 Ondrej Wisniewski
ondrej.wisniew...@dektech.com.au
mailto:ondrej.wisniew...@dektech.com.au:

Hi,

I am trying to set up an OpenStack development workflow in
our company. We have an internal Git repository mirror of all
OpenStack projects we are working on. It is periodically
updated from the upstream OpenStack community servers. This
is used to share the code among developers.

Furthermore I have set up a Gerrit server for the internal
code review. The Gerrit server also works with repository
mirrors of the community repositories which should be updated
periodically. Or at least that's the idea. I ran into lots of
problems and couldn't find a good way of synchronizing the
developer mirrors with the Gerrit repositories.

So to cut a long story short, here are my questions:
How is the synchronization of the OpenStack community Git
repositories and the Gerrit server done?
How can I import an OpenStack project into my Gerrit system
from my local Git mirror and keep both synchronized (at least
the master branch) ?

I would be really appreciate if someone could shed some light
on this.
Thanks, Ondrej

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

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

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

2014-10-27 Thread Itzik Brown

- Original Message -
 From: Carl Baldwin c...@ecbaldwin.net
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, October 27, 2014 5:27:57 PM
 Subject: Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking 
 ongoing traffic

 On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com
 wrote:
  Hello Itzik,
  This has been discussed lately on this ML. Please see
  https://bugs.launchpad.net/neutron/+bug/1335375.

 This is a good example that any create, update, or delete of a SG rule
 can expose this issue.  This bug only mentions delete.  I'll update
 the bug to increase the scope beyond just deletes because it really is
 the same conntrack issue at the root of the problem.

 Carl

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

Carl,

FWaaS has the same issues as well.
What do you suggest - open a new bug or updating the current one?

Thanks,
Itzik

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

Re: [openstack-dev] FreeBSD host support

2014-10-27 Thread Drew Fisher



On 10/27/14 9:35 AM, Monty Taylor wrote:

snip

 I have no problem with supporting FreeBSD as a hypervisor operating system,
 especially if there is a solid team on the FreeBSD side that will commit to
 maintaining the changes required and adding the necessary CI (especially
 ensuring that when it breaks it gets fixed).
 
 I believe that the CI related things that would be needed would be:
 
 - solid devstack support

I do not want to hijack this thread with Solaris specific questions, but
this point is a major sticking point for us too.  To my knowledge,
modifying devstack for anything not RHEL/Ubuntu is out of the question
(they're not interested in supporting other OSes).  We desperately WANT
to push our Solaris driver upstream and we're in the process of getting
our CI infrastructure in place to do so, but devstack has been out of
the question so far.

If devstack itself (not CI, but devstack) is a hard requirement for
integration we need to probably start up a different thread on what the
best way for other OSes like FreeBSD and Solaris to work around this
issue.  What should we be looking at?  A compatible devstack clone that
configures Solaris as a single-host development OpenStack rig?

-Drew


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

Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group

Excerpts from Daniel Comnea's message of 2014-10-27 04:16:32 -0700:
 Yes i did but if you look at this example
 
 https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
 
 
 the flow is simple:
 
 CPU alarm in Ceilometer triggers the type: OS::Heat::ScalingPolicy which
 then triggers the type: OS::Heat::AutoScalingGroup
 
 
 
 Now what i want is to be able to always maintain a min number of instances
 in my Group, if is min_size been reached than trigger HEAT to spun a new
 one to be min_size + n
 

Sounds like you're expecting Heat to respond to the stop/delete of one
of the instances in the group.

It doesn't do that.. yet. There's a very large scale effort under way
called 'convergence' that will add such a capability to Heat (by having
Heat try to assert that reality should match intention). Until then it
doesn't support this use case very well.

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

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

2014-10-27 Thread Carl Baldwin

I think I'd suggest opening a new bug for FWaaS since it is a
different component with different code.  It doesn't seem natural to
extend the scope of this bug to include it.

Carl

On Mon, Oct 27, 2014 at 9:50 AM, Itzik Brown itbr...@redhat.com wrote:

 - Original Message -
 From: Carl Baldwin c...@ecbaldwin.net
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, October 27, 2014 5:27:57 PM
 Subject: Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking 
 ongoing traffic

 On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com
 wrote:
  Hello Itzik,
  This has been discussed lately on this ML. Please see
  https://bugs.launchpad.net/neutron/+bug/1335375.

 This is a good example that any create, update, or delete of a SG rule
 can expose this issue.  This bug only mentions delete.  I'll update
 the bug to increase the scope beyond just deletes because it really is
 the same conntrack issue at the root of the problem.

 Carl

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

 Carl,

 FWaaS has the same issues as well.
 What do you suggest - open a new bug or updating the current one?

 Thanks,
 Itzik

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

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

[openstack-dev] [Neutron][IPv6] No meeting tomorrow

2014-10-27 Thread Collins, Sean

I look forward to seeing everyone in Paris!
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-27 Thread Ian Wells

On 25 October 2014 15:36, Erik Moe erik@ericsson.com wrote:

  Then I tried to just use the trunk network as a plain pipe to the
 L2-gateway and connect to normal Neutron networks. One issue is that the
 L2-gateway will bridge the networks, but the services in the network you
 bridge to is unaware of your existence. This IMO is ok then bridging
 Neutron network to some remote network, but if you have an Neutron VM and
 want to utilize various resources in another Neutron network (since the one
 you sit on does not have any resources), things gets, let’s say non
 streamlined.


Indeed.  However, non-streamlined is not the end of the world, and I
wouldn't want to have to tag all VLANs a port is using on the port in
advance of using it (this works for some use cases, and makes others
difficult, particularly if you just want a native trunk and are happy for
Openstack not to have insight into what's going on on the wire).


  Another issue with trunk network is that it puts new requirements on the
 infrastructure. It needs to be able to handle VLAN tagged frames. For a
 VLAN based network it would be QinQ.


Yes, and that's the point of the VLAN trunk spec, where we flag a network
as passing VLAN tagged packets; if the operator-chosen network
implementation doesn't support trunks, the API can refuse to make a trunk
network.  Without it we're still in the situation that on some clouds
passing VLANs works and on others it doesn't, and that the tenant can't
actually tell in advance which sort of cloud they're working on.

Trunk networks are a requirement for some use cases independent of the port
awareness of VLANs.  Based on the maxim, 'make the easy stuff easy and the
hard stuff possible' we can't just say 'no Neutron network passes VLAN
tagged packets'.  And even if we did, we're evading a problem that exists
with exactly one sort of network infrastructure - VLAN tagging for network
separation - while making it hard to use for all of the many other cases in
which it would work just fine.

In summary, if we did port-based VLAN knowledge I would want to be able to
use VLANs without having to use it (in much the same way that I would like,
in certain circumstances, not to have to use Openstack's address allocation
and DHCP - it's nice that I can, but I shouldn't be forced to).

My requirements were to have low/no extra cost for VMs using VLAN trunks
 compared to normal ports, no new bottlenecks/single point of failure. Due
 to this and previous issues I implemented the L2 gateway in a distributed
 fashion and since trunk network could not be realized in reality I only had
 them in the model and optimized them away.


Again, this is down to your choice of VLAN tagged networking and/or the OVS
ML2 driver; it doesn't apply to all deployments.


 But the L2-gateway + trunk network has a flexible API, what if someone
 connects two VMs to one trunk network, well, hard to optimize away.


That's certainly true, but it wasn't really intended to be optimised away.

 Anyway, due to these and other issues, I limited my scope and switched to
 the current trunk port/subport model.



 The code that is for review is functional, you can boot a VM with a trunk
 port + subports (each subport maps to a VLAN). The VM can send/receive VLAN
 traffic. You can add/remove subports on a running VM. You can specify IP
 address per subport and use DHCP to retrieve them etc.


I'm coming to realise that the two solutions address different needs - the
VLAN port one is much more useful for cases where you know what's going on
in the network and you want Openstack to help, but it's just not broad
enough to solve every problem.  It may well be that we want both solutions,
in which case we just need to agree that 'we shouldn't do trunk networking
because VLAN aware ports solve this problem' is not a valid argument during
spec review.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Permissions differences for glance image-create between Icehouse and Juno


Hello Glancers,

Peter and I are having issues working with a Juno Glance endpoint. 
Specifically, a glance image-create ... --is_public=True CLI command 
that *was* working in our Icehouse cloud is now failing in our Juno 
cloud with a 403 Forbidden.


The specific command in question is:

glance image-create --name cirros-0.3.2-x86_64 --file 
/var/tmp/cirros-0.3.2-x86_64-disk.img --disk-format qcow2 
--container-format bare --is_public=True


If we take off the is_public=True, everything works just fine. We are 
executing the above command as a user with a user called admin having 
the role admin in a project called admin.


We have enabled debug=True conf option in both glance-api.conf and 
glance-registry.conf, and unfortunately, there is no log output at all, 
other than spitting out the configuration option settings on daemon 
startup and a few messages like Loaded policy rules: ... which don't 
actually provide any useful information about policy *decisions* that 
are made... :(


Any help is most appreciated. Our policy.json file is the stock one that 
comes in the Ubuntu Cloud Archive glance packages, i.e.:


http://paste.openstack.org/show/125420/

Best,
-jay

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

2014-10-27 Thread Jorge Miramontes

Hey German,

I totally agree on the security/privacy aspect of logs, especially due to
the SSL/TLS Termination feature.

After looking at BP [1] and the spec [2] for metering, it looks like it is
proposing to send more than just billable usage to cielometer. From my
previous email I considered this tracking usage (billable usage can be
a subset of tracking usage). It also appears to me that there is an
implied interface  for cielometer as we need to be able to capture metrics
from various lb devices (HAProxy, Nginx, Netscaler, etc.), standardize
them, and then send them off. That said, what type of implementation was
HP thinking of to gather these metrics? Instead of focusing on my idea of
using logging I'd like to change the discussion and get a picture as to
what you all are envisioning for a possible implementation direction.
Important items for Rackspace include accuracy of data, no lost data (i.e.
when sending to upstream system ensure it gets there), reliability of
cadence when sending usage to upstream system, and the ability to
backtrack and audit data whenever there seems to be a discrepancy in a
customer's monthly statement. Keep in mind that we need to integrate with
our current billing pipeline so we are not planning on using cielometer at
the moment. Thus, we need to make this somewhat configurable for those not
using cielometer.

Cheers,
--Jorge

[1] 
https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-meter-lbaas

[2] https://review.openstack.org/#/c/94958/12/specs/juno/lbaas_metering.rst


On 10/24/14 5:19 PM, Eichberger, German german.eichber...@hp.com wrote:

Hi Jorge,

I agree completely with the points you make about the logs. We still feel
that metering and logging are two different problems. The ceilometers
community has a proposal on how to meter lbaas (see
http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/lbaas_met
ering.html) and we at HP think that those values are be sufficient for us
for the time being.

I think our discussion is mostly about connection logs which are emitted
some way from amphora (e.g. haproxy logs). Since they are customer's logs
we need to explore on our end the privacy implications (I assume at RAX
you have controls in place to make sure that there is no violation :-).
Also I need to check if our central logging system is scalable enough and
we can send logs there without creating security holes.

Another possibility is to log like syslog our apmphora agent logs to a
central system to help with trouble shooting debugging. Those could be
sufficiently anonymized to avoid privacy issue. What are your thoughts on
logging those?

Thanks,
German

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Thursday, October 23, 2014 3:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

Hey German/Susanne,

To continue our conversation from our IRC meeting could you all provide
more insight into you usage requirements? Also, I'd like to clarify a few
points related to using logging.

I am advocating that logs be used for multiple purposes, including
billing. Billing requirements are different that connection logging
requirements. However, connection logging is a very accurate mechanism to
capture billable metrics and thus, is related. My vision for this is
something like the following:

- Capture logs in a scalable way (i.e. capture logs and put them on a
separate scalable store somewhere so that it doesn't affect the amphora).
- Every X amount of time (every hour, for example) process the logs and
send them on their merry way to cielometer or whatever service an
operator will be using for billing purposes.
- Keep logs for some configurable amount of time. This could be anything
from indefinitely to not at all. Rackspace is planing on keeping them for
a certain period of time for the following reasons:
   
   A) We have connection logging as a planned feature. If a customer turns
on the connection logging feature for their load balancer it will already
have a history. One important aspect of this is that customers (at least
ours) tend to turn on logging after they realize they need it (usually
after a tragic lb event). By already capturing the logs I'm sure
customers will be extremely happy to see that there are already X days
worth of logs they can immediately sift through.
   B) Operators and their support teams can leverage logs when providing
service to their customers. This is huge for finding issues and resolving
them quickly.
   C) Albeit a minor point, building support for logs from the get-go
mitigates capacity management uncertainty. My example earlier was the
extreme case of every customer turning on logging at the same time. While
unlikely, I would hate to manage that!

I agree that there are other ways to capture billing metrics but, from my
experience, those tend to be more complex

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

2014-10-27 Thread Mandeep Dhami

Hi Kyle:

Are you scheduling an on-demand meeting, or are you proposing that the
agenda for next neutron meeting include this as an on-demand item?

Regards,
Mandeep


On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery mest...@mestery.com wrote:

 On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
 sumitnaiksa...@gmail.com wrote:
  Several people have been requesting that we resume the Advanced
  Services' meetings [1] to discuss some of the topics being mentioned
  in this thread. Perhaps it might help people to have a focussed
  discussion on the topic of advanced services' spin-out prior to the
  design summit session [2] in Paris. So I propose that we resume our
  weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
  #openstack-meeting-3.
 
 Given how important this is to Neutron in general, I would prefer NOT
 to see this discussed in the Advanced Services meeting, but rather in
 the regular Neutron meeting. These are the types of things which need
 broader oversight and involvement. Lets please discuss this in the
 regular Neutron meeting, which is an on-demand meeting format, rather
 than in a sub-team meeting.

  Thanks,
  ~Sumit.
 
  [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
  [2]
 http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
 
  On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
  skand...@cisco.com wrote:
  Hi Doug:
 
  On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
 
 Hi Brandon,
 
  4. I brought this up now so that we can decide whether we want to
  discuss it at the advanced services spin out session.  I don't see the
  harm in opinions being discussed before the summit, during the summit,
  and more thoroughly after the summit.
 
 I agree with this sentiment.  I¹d just like to pull-up to the decision
 level, and if we can get some consensus on how we move forward, we can
 bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
 We
 love each other.  Check.  Things are going to change sometime.  Check.
 We
 might spin-out someday.  Check.  Now, let¹s jump to the interesting
 part.
 
  3. The main reason a spin out makes sense from Neutron is that the
 scope
  for Neutron is too large for the attention advances services needs
 from
  the Neutron Core.  If all of advanced services spins out, I see that
 
 There is merit here, but consider the sorts of things that an advanced
 services framework should be doing:
 
 - plugging into neutron ports, with all manner of topologies
 - service VM handling
 - plugging into nova-network
 - service chaining
 - applying things like security groups to services
 
 Š this is all stuff that Octavia is talking about implementing itself
 in a
 basically defensive manner, instead of leveraging other work.  And there
 are specific reasons for that.  But, maybe we can at least take steps to
 not be incompatible about it.  Or maybe there is a hierarchy of Neutron
 -
 Services - LB, where we¹re still spun out, but not doing it in a way
 that
 we have to re-implement the world all the time.  It¹s at least worth a
 conversation or three.
 
  In total agreement and I have heard these sentiments in multiple
  conversations across multiple players.
  It would be really fruitful to have a constructive conversation on this
  across the services, and there are
  enough similar issues to make this worthwhile.
 
  Thanks
 
  Sridar
 
 
 Thanks,
 Doug
 
 
 
 
 On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
 wrote:
 
 Good questions Doug.  My answers are as follows:
 
 1. Yes
 2. Some time after Kilo (same as I don't know when)
 3. The main reason a spin out makes sense from Neutron is that the
 scope
 for Neutron is too large for the attention advances services needs from
 the Neutron Core.  If all of advanced services spins out, I see that
 repeating itself within an advanced services project.  More and more
 advanced services will get added in and the scope will become too
 large.  There would definitely be benefits to it though, but I think we
 would end up being right where we are today.
 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.
 
 Yes the brunt of the time will not be spent on the API, but since it
 seemed like an opportunity to kill two birds with one stone, I figured
 it warranted a discussion.
 
 Thanks,
 Brandon
 
 On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
  Hi all,
 
  Before we get into the details of which API goes where, I¹d like to
 see
 us
  answer the questions of:
 
  1. Are we spinning out?
  2. When?
  3. With or without the rest of advanced services?
  4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
 have
  had the Paris summit discussions on vendor split-out and adv.
 services
  spinout

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami dh...@noironetworks.com wrote:
 Hi Kyle:

 Are you scheduling an on-demand meeting, or are you proposing that the
 agenda for next neutron meeting include this as an on-demand item?

Per my email to the list recently [1], the weekly rotating Neutron
meeting is now an on-demand agenda, rather than a rollup of sub-team
status. I'm saying this particular topic (advanced services spinout)
will be discussed in Paris, and it's worth adding it to the weekly
Neutron meeting [2] agenda in the on-demand section. This is a pretty
large topic with many interested parties, thus the attention in the
broader neutron meeting.

Thanks,
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
[2] https://wiki.openstack.org/wiki/Network/Meetings

 Regards,
 Mandeep


 On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery mest...@mestery.com wrote:

 On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
 sumitnaiksa...@gmail.com wrote:
  Several people have been requesting that we resume the Advanced
  Services' meetings [1] to discuss some of the topics being mentioned
  in this thread. Perhaps it might help people to have a focussed
  discussion on the topic of advanced services' spin-out prior to the
  design summit session [2] in Paris. So I propose that we resume our
  weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
  #openstack-meeting-3.
 
 Given how important this is to Neutron in general, I would prefer NOT
 to see this discussed in the Advanced Services meeting, but rather in
 the regular Neutron meeting. These are the types of things which need
 broader oversight and involvement. Lets please discuss this in the
 regular Neutron meeting, which is an on-demand meeting format, rather
 than in a sub-team meeting.

  Thanks,
  ~Sumit.
 
  [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
  [2]
  http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
 
  On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
  skand...@cisco.com wrote:
  Hi Doug:
 
  On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
 
 Hi Brandon,
 
  4. I brought this up now so that we can decide whether we want to
  discuss it at the advanced services spin out session.  I don't see
  the
  harm in opinions being discussed before the summit, during the
  summit,
  and more thoroughly after the summit.
 
 I agree with this sentiment.  I¹d just like to pull-up to the decision
 level, and if we can get some consensus on how we move forward, we can
 bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
  We
 love each other.  Check.  Things are going to change sometime.  Check.
  We
 might spin-out someday.  Check.  Now, let¹s jump to the interesting
  part.
 
  3. The main reason a spin out makes sense from Neutron is that the
  scope
  for Neutron is too large for the attention advances services needs
  from
  the Neutron Core.  If all of advanced services spins out, I see that
 
 There is merit here, but consider the sorts of things that an advanced
 services framework should be doing:
 
 - plugging into neutron ports, with all manner of topologies
 - service VM handling
 - plugging into nova-network
 - service chaining
 - applying things like security groups to services
 
 Š this is all stuff that Octavia is talking about implementing itself
  in a
 basically defensive manner, instead of leveraging other work.  And
  there
 are specific reasons for that.  But, maybe we can at least take steps
  to
 not be incompatible about it.  Or maybe there is a hierarchy of Neutron
  -
 Services - LB, where we¹re still spun out, but not doing it in a way
  that
 we have to re-implement the world all the time.  It¹s at least worth a
 conversation or three.
 
  In total agreement and I have heard these sentiments in multiple
  conversations across multiple players.
  It would be really fruitful to have a constructive conversation on this
  across the services, and there are
  enough similar issues to make this worthwhile.
 
  Thanks
 
  Sridar
 
 
 Thanks,
 Doug
 
 
 
 
 On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
  wrote:
 
 Good questions Doug.  My answers are as follows:
 
 1. Yes
 2. Some time after Kilo (same as I don't know when)
 3. The main reason a spin out makes sense from Neutron is that the
  scope
 for Neutron is too large for the attention advances services needs
  from
 the Neutron Core.  If all of advanced services spins out, I see that
 repeating itself within an advanced services project.  More and more
 advanced services will get added in and the scope will become too
 large.  There would definitely be benefits to it though, but I think
  we
 would end up being right where we are today.
 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before

Re: [openstack-dev] [all] Key signing at the summit?

Excerpts from Jeremy Stanley's message of 2014-10-27 07:45:27 -0700:
 On 2014-10-26 17:01:07 -0700 (-0700), Clint Byrum wrote:
  Hi everyone! We have a summit rapidly approaching, and to my knowledge,
  no key signing event planned. That is unfortunate, as the web of trust
  that we started building in Atlanta would be quite stronger as we add
  more European developers who I'm sure will be present in large numbers
  due to proximity.
 [...]
 
 I took the prior lack of discussion on the ML to imply interest in
 repeating the exercise in an organized fashion was low. Those of us
 who regularly engage in ad-hoc keysigning will likely already have
 business cards or slips with full key fingerprints/names and
 passports or similar ID with us already. Since the majority of the
 OpenStack WoT is currently between release management, quality
 assurance and project infrastructure teams, I proposed this is one
 of the things which can go on quietly in the background over the
 course of our shared meet-up on Friday.
 

Often it's not clear that one needs to dive into the WoT until two people
are on opposite sides of the planet wanting to communicate in some secure
fashion. Because of this, I feel a need to facilitate key signing even
if there aren't that many who are excited about it.

We're short on time, and I think trying to push the full process will tax
too many. I like the idea of ad-hoc keysigning quietly in the background,
as that will also help educate people on how to grow their trust network
themselves, without just attending events like our signing party in
Atlanta.

Unless somebody else wants to gather the list of fingerprints and secure
a space for a larger meeting, I would just encourage everyone to bring
copies of your fingerprint and proof of your identity so that others can
sign your key. If you're unsure of how to do this, I suggest you ask in
#openstack-infra or directly ask any of us who you've seen discussing
key signing in the past.

 If there is interest in doing another Sassaman-Projected Method
 exercise at future events, a USB document camera would be useful to
 procure in advance (my earlier experiment with the digital
 microscope worked well in the lab but was not so successful in the
 wild since I ended up lacking a tall enough stand to properly
 encompass larger IDs and so had to try some pretty hacky
 workarounds). There is relatively inexpensive equipment on the
 market which does this sort of thing well and is compact enough to
 easily bring in luggage, I just don't happen to have anything like
 that on hand currently.

I thought it worked quite nicely, but I do think it stressed you out too
much and we should look at securing a camera for mid-cycles and the
next summit.

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

Re: [openstack-dev] [TripleO] Summit scheduling - using our time together wisely.

I'm anxious to get titles for the scheduled sessions so that people can
start planning their daily schedules. I have heard some opinions about
the Neutron/Nova/Ironic work that needs to happen to support L3 (I think
we should still bring it up) and also a bit about Cinder HA. I think
these are things that will benefit from a f2f conversation with the
OpenStack community at large.

I also think that the biggest theme I see beyond that is UI/onboarding.
So I think we should split the 2 40 minute sessions into these two
things:


* L3 Networking + Cinder HA
 - Summary of changes needed in Cinder/Neutron/Nova/Ironic/etc.
 - Configuration changes needed
 - UI changes

* TripleO's onramp - All things new contributor
 - QuintupleO progress report
 - Tuskar progress report
 - Alternative implementations roll call
   - Kolla
   - Puppet
   - Ansible

The rest of the things in the etherpad will make for a good agenda for
Friday.

Does anyone have anything to add, or dissent to register?

Excerpts from Clint Byrum's message of 2014-10-16 13:14:26 -0700:
 The format has changed slightly this summit, to help encourage a more
 collaborative design experience, rather than rapid fire mass-inclusion
 summit sessions. So we have two 40-minute long slots, and one whole day
 of contributor meetup.[1]
 
 Our etherpad topics page has received quite a few additions now [2], and
 so I'd like to hear thoughts on what things we want to talk about in the
 meetup versus the sessions.
 
 A few things I think we should stipulate:
 
 * The scheduled sessions will be heavily attended by the community at
   large. This often includes those who are just curious, or those who
   want to make sure that their voice is heard. These sessions should be
   reserved for those topics which have the most external influence or
   are the most dependent on other projects.
 
 * The meetup will be at the end of the week so at the end of it, we
   can't then go to any other meetups and ask for things / participate
   in those design activities. This reinforces that scheduled session
   time should be focused on things that are externally focused so that
   we can take the result of those discussions into any of the sessions
   that are after.
 
 * The Ops Summit is Wendesday/Thursday [3], which overlaps with these
   sessions. I am keenly interested in gathering more contribution from
   those already operating and deploying OpenStack. It can go both ways,
   but I think it might make sense to have more ops-centric topics
   discussed on Friday, when those participants might not be fully
   wrapped up in the ops sessions.
 
 If we can all agree on those points, given the current topics, I think
 our scheduled sessions should target at least (but not limited to):
 
 * Cinder + CEPH
 * Layer 3 segmentation
 
 I think those might fit into 40 minutes, as long as we hash some things
 out here on the mailing list first. Cinder + CEPH is really just a
 check-in to make sure we're on track to providing it. Layer 3, I've had
 discussions with Ironic and Neutron people and I think we have a plan,
 but I wanted to present it in the open and discuss the short term goals
 to see if it satisfies what users may want for the Kilo time frame.
 
 So, I would encourage you all to look at the etherpad, and expand on
 topics or add more, and then reply to this thread with ideas for how
 best to use our precious time together.
 
 [1] http://kilodesignsummit.sched.org/overview/type/tripleo
 [2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics
 [3] http://kilodesignsummit.sched.org/overview/type/ops+summit

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

[openstack-dev] [DevStack][Neutron] Creating bridges automatically?

2014-10-27 Thread Collins, Sean

Hi,

I am currently working on my Neutron docs for DevStack[1], and realized
that there is some common pieces between provider networking API
extension and the l3 networking API extension.

In both cases, the administrator is directed to manually create a bridge
device and add the physical interface to it[2].

I have a patch into DevStack that does this in the provider networking
case[3] - and a Vagrant setup I use for the l3 networking extension has
a puppet recipie that automatically adds the public interface to the
bridge after DevStack runs[4].

Should we have DevStack go ahead and wire up the bridge and interface
when using the L3 agent?

[1]: https://review.openstack.org/#/c/131201/
[2]: http://docs.openstack.org/admin-guide-cloud/content/install_neutron-l3.html
[3]: http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#n654
[4]: https://github.com/sc68cal/chef-devstack/blob/master/recipes/default.rb#L55

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

2014-10-27 Thread Doug Wiegley

Hi Jay,

Let’s add that as an agenda item at our Weekly IRC meeting.  Can you make
this timeslot?

https://wiki.openstack.org/wiki/Octavia#Meetings


Thanks,
Doug


On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:

Sorry for top-posting, but where can the API working group see the
proposed Octavia API specification or documentation? I'd love it if the
API WG could be involved in reviewing the public REST API.

Best,
-jay

On 10/27/2014 10:01 AM, Kyle Mestery wrote:
 On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
wrote:
 Hi Brandon,

 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

 I agree with this sentiment.  I’d just like to pull-up to the decision
 level, and if we can get some consensus on how we move forward, we can
 bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
 love each other.  Check.  Things are going to change sometime.  Check.
 We
 might spin-out someday.  Check.  Now, let’s jump to the interesting
part.

 I think we all know we want to spin these out, as Doug says we just
 need to have a plan around how we make that happen. I'm in agreement
 with Doug's sentiment above.

 3. The main reason a spin out makes sense from Neutron is that the
scope
 for Neutron is too large for the attention advances services needs
from
 the Neutron Core.  If all of advanced services spins out, I see that

 There is merit here, but consider the sorts of things that an advanced
 services framework should be doing:

 - plugging into neutron ports, with all manner of topologies
 - service VM handling
 - plugging into nova-network
 - service chaining
 - applying things like security groups to services

 … this is all stuff that Octavia is talking about implementing itself
in a
 basically defensive manner, instead of leveraging other work.  And
there
 are specific reasons for that.  But, maybe we can at least take steps
to
 not be incompatible about it.  Or maybe there is a hierarchy of
Neutron -
 Services - LB, where we’re still spun out, but not doing it in a way
that
 we have to re-implement the world all the time.  It’s at least worth a
 conversation or three.

 Doug, can you document this on the etherpad for the services spinout
 [1]? I've added some brief text at the top on what the objective for
 this session is, but documenting more along the lines of what you have
 here would be good.

 Thanks,
 Kyle

 [1] https://etherpad.openstack.org/p/neutron-services

 Thanks,
 Doug




 On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Good questions Doug.  My answers are as follows:

 1. Yes
 2. Some time after Kilo (same as I don't know when)
 3. The main reason a spin out makes sense from Neutron is that the
scope
 for Neutron is too large for the attention advances services needs
from
 the Neutron Core.  If all of advanced services spins out, I see that
 repeating itself within an advanced services project.  More and more
 advanced services will get added in and the scope will become too
 large.  There would definitely be benefits to it though, but I think
we
 would end up being right where we are today.
 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

 Yes the brunt of the time will not be spent on the API, but since it
 seemed like an opportunity to kill two birds with one stone, I figured
 it warranted a discussion.

 Thanks,
 Brandon

 On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
 Hi all,

 Before we get into the details of which API goes where, I’d like to
see
 us
 answer the questions of:

 1. Are we spinning out?
 2. When?
 3. With or without the rest of advanced services?
 4. Do we want to wait until we (the royal “we” of “the Neutron team”)
 have
 had the Paris summit discussions on vendor split-out and adv.
services
 spinout before we answer those questions?  (Yes, that question is
 leading.)

 To me, the “where does the API live” is an implementation detail, and
 not
 where the time will need to be spent.

 For the record, my answers are:

 1. Yes.
 2. I don’t know.
 3. I don’t know; this needs some serious discussion.
 4. Yes.

 Thanks,
 doug

 On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 With the recent talk about advanced services spinning out of
Neutron,
 and the fact most of the LBaaS community has wanted LBaaS to spin
out
 of
 Neutron, I wanted to bring up a possibility and gauge interest and
 opinion on this possibility.

 Octavia is going to (and has) an API.  The current thinking is that
an
 Octavia driver will be created in Neutron LBaaS that will make a
 requests to the Octavia

Re: [openstack-dev] [all] Key signing at the summit?

On 2014-10-27 10:17:51 -0700 (-0700), Clint Byrum wrote:
[...]
 I thought it worked quite nicely, but I do think it stressed you
 out too much and we should look at securing a camera for
 mid-cycles and the next summit.

It worked out okay, but I basically sacrificed my ability to
participate as I was spending too much time focusing the equipment
and attempting to hold it steady (leaving me little time to
cross-check participants on the list myself). With an upright unit,
I suspect we can operate the line in more of a self-service fashion.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS


Yup, can do! :)

-jay

On 10/27/2014 01:55 PM, Doug Wiegley wrote:

Hi Jay,

Let’s add that as an agenda item at our Weekly IRC meeting.  Can you make
this timeslot?

https://wiki.openstack.org/wiki/Octavia#Meetings


Thanks,
Doug


On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:


Sorry for top-posting, but where can the API working group see the
proposed Octavia API specification or documentation? I'd love it if the
API WG could be involved in reviewing the public REST API.

Best,
-jay

On 10/27/2014 10:01 AM, Kyle Mestery wrote:

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
wrote:

Hi Brandon,


4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.


I agree with this sentiment.  I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other.  Check.  Things are going to change sometime.  Check.
We
might spin-out someday.  Check.  Now, let’s jump to the interesting
part.


I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.


3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core.  If all of advanced services spins out, I see that


There is merit here, but consider the sorts of things that an advanced
services framework should be doing:

- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services

… this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work.  And
there
are specific reasons for that.  But, maybe we can at least take steps
to
not be incompatible about it.  Or maybe there is a hierarchy of
Neutron -
Services - LB, where we’re still spun out, but not doing it in a way
that
we have to re-implement the world all the time.  It’s at least worth a
conversation or three.


Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.

Thanks,
Kyle

[1] https://etherpad.openstack.org/p/neutron-services


Thanks,
Doug




On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:


Good questions Doug.  My answers are as follows:

1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core.  If all of advanced services spins out, I see that
repeating itself within an advanced services project.  More and more
advanced services will get added in and the scope will become too
large.  There would definitely be benefits to it though, but I think
we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.

Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.

Thanks,
Brandon

On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:

Hi all,

Before we get into the details of which API goes where, I’d like to
see
us
answer the questions of:

1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv.
services
spinout before we answer those questions?  (Yes, that question is
leading.)

To me, the “where does the API live” is an implementation detail, and
not
where the time will need to be spent.

For the record, my answers are:

1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.

Thanks,
doug

On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:


With the recent talk about advanced services spinning out of
Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin
out

of

Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.

Octavia is going to (and has) an API.  The current thinking is that
an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API.  When

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

2014-10-27 Thread Brandon Logan

Hi Jay,
Just so you have some information on the API before the meeting here is
the spec for it:

https://review.openstack.org/#/c/122338/

I'm sure there is a lot of details that might be missing but it should
give you a decent idea.  Sorry for the markup/markdown being dumb if you
try to build with spinx.  Probably easier to just read the raw .rst
file.

Thanks,
Brandon

On Mon, 2014-10-27 at 14:05 -0400, Jay Pipes wrote:
 Yup, can do! :)
 
 -jay
 
 On 10/27/2014 01:55 PM, Doug Wiegley wrote:
  Hi Jay,
 
  Let’s add that as an agenda item at our Weekly IRC meeting.  Can you make
  this timeslot?
 
  https://wiki.openstack.org/wiki/Octavia#Meetings
 
 
  Thanks,
  Doug
 
 
  On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:
 
  Sorry for top-posting, but where can the API working group see the
  proposed Octavia API specification or documentation? I'd love it if the
  API WG could be involved in reviewing the public REST API.
 
  Best,
  -jay
 
  On 10/27/2014 10:01 AM, Kyle Mestery wrote:
  On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
  wrote:
  Hi Brandon,
 
  4. I brought this up now so that we can decide whether we want to
  discuss it at the advanced services spin out session.  I don't see the
  harm in opinions being discussed before the summit, during the summit,
  and more thoroughly after the summit.
 
  I agree with this sentiment.  I’d just like to pull-up to the decision
  level, and if we can get some consensus on how we move forward, we can
  bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
  We
  love each other.  Check.  Things are going to change sometime.  Check.
  We
  might spin-out someday.  Check.  Now, let’s jump to the interesting
  part.
 
  I think we all know we want to spin these out, as Doug says we just
  need to have a plan around how we make that happen. I'm in agreement
  with Doug's sentiment above.
 
  3. The main reason a spin out makes sense from Neutron is that the
  scope
  for Neutron is too large for the attention advances services needs
  from
  the Neutron Core.  If all of advanced services spins out, I see that
 
  There is merit here, but consider the sorts of things that an advanced
  services framework should be doing:
 
  - plugging into neutron ports, with all manner of topologies
  - service VM handling
  - plugging into nova-network
  - service chaining
  - applying things like security groups to services
 
  … this is all stuff that Octavia is talking about implementing itself
  in a
  basically defensive manner, instead of leveraging other work.  And
  there
  are specific reasons for that.  But, maybe we can at least take steps
  to
  not be incompatible about it.  Or maybe there is a hierarchy of
  Neutron -
  Services - LB, where we’re still spun out, but not doing it in a way
  that
  we have to re-implement the world all the time.  It’s at least worth a
  conversation or three.
 
  Doug, can you document this on the etherpad for the services spinout
  [1]? I've added some brief text at the top on what the objective for
  this session is, but documenting more along the lines of what you have
  here would be good.
 
  Thanks,
  Kyle
 
  [1] https://etherpad.openstack.org/p/neutron-services
 
  Thanks,
  Doug
 
 
 
 
  On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
  wrote:
 
  Good questions Doug.  My answers are as follows:
 
  1. Yes
  2. Some time after Kilo (same as I don't know when)
  3. The main reason a spin out makes sense from Neutron is that the
  scope
  for Neutron is too large for the attention advances services needs
  from
  the Neutron Core.  If all of advanced services spins out, I see that
  repeating itself within an advanced services project.  More and more
  advanced services will get added in and the scope will become too
  large.  There would definitely be benefits to it though, but I think
  we
  would end up being right where we are today.
  4. I brought this up now so that we can decide whether we want to
  discuss it at the advanced services spin out session.  I don't see the
  harm in opinions being discussed before the summit, during the summit,
  and more thoroughly after the summit.
 
  Yes the brunt of the time will not be spent on the API, but since it
  seemed like an opportunity to kill two birds with one stone, I figured
  it warranted a discussion.
 
  Thanks,
  Brandon
 
  On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
  Hi all,
 
  Before we get into the details of which API goes where, I’d like to
  see
  us
  answer the questions of:
 
  1. Are we spinning out?
  2. When?
  3. With or without the rest of advanced services?
  4. Do we want to wait until we (the royal “we” of “the Neutron team”)
  have
  had the Paris summit discussions on vendor split-out and adv.
  services
  spinout before we answer those questions?  (Yes, that question is
  leading.)
 
  To me, the “where does the API live” is an implementation detail, and
  not

Re: [openstack-dev] [TripleO] Summit scheduling - using our time together wisely.

2014-10-27 Thread Ben Nemec

On 10/27/2014 12:30 PM, Clint Byrum wrote:
 I'm anxious to get titles for the scheduled sessions so that people can
 start planning their daily schedules. I have heard some opinions about
 the Neutron/Nova/Ironic work that needs to happen to support L3 (I think
 we should still bring it up) and also a bit about Cinder HA. I think
 these are things that will benefit from a f2f conversation with the
 OpenStack community at large.
 
 I also think that the biggest theme I see beyond that is UI/onboarding.
 So I think we should split the 2 40 minute sessions into these two
 things:
 
 
 * L3 Networking + Cinder HA
  - Summary of changes needed in Cinder/Neutron/Nova/Ironic/etc.
  - Configuration changes needed
  - UI changes

I still have some reservations about these, as I noted in my previous
mail, but at this point I don't have an alternative suggestion so I
guess +1 from me.

 
 * TripleO's onramp - All things new contributor
  - QuintupleO progress report

This should be pretty brief, unless someone else has done a bunch of
work on it that I'm not aware of.  Nothing has really changed on my end
since the blog post I made on this about a month ago.

  - Tuskar progress report
  - Alternative implementations roll call

Any one of these seems like a potential rabbit hole that could end up
taking the entire session.  I definitely think these are important
topics to discuss, but if we're going to try to fit them into one of the
sessions I think we need to be very, very clear about the scope of the
discussion.  With basically five topics in this session, each one has
less than 10 minutes available to it.  We're talking very brief
introduction and maybe a couple of questions here.

- Kolla
- Puppet
- Ansible
 
 The rest of the things in the etherpad will make for a good agenda for
 Friday.
 
 Does anyone have anything to add, or dissent to register?
 
 Excerpts from Clint Byrum's message of 2014-10-16 13:14:26 -0700:
 The format has changed slightly this summit, to help encourage a more
 collaborative design experience, rather than rapid fire mass-inclusion
 summit sessions. So we have two 40-minute long slots, and one whole day
 of contributor meetup.[1]

 Our etherpad topics page has received quite a few additions now [2], and
 so I'd like to hear thoughts on what things we want to talk about in the
 meetup versus the sessions.

 A few things I think we should stipulate:

 * The scheduled sessions will be heavily attended by the community at
   large. This often includes those who are just curious, or those who
   want to make sure that their voice is heard. These sessions should be
   reserved for those topics which have the most external influence or
   are the most dependent on other projects.

 * The meetup will be at the end of the week so at the end of it, we
   can't then go to any other meetups and ask for things / participate
   in those design activities. This reinforces that scheduled session
   time should be focused on things that are externally focused so that
   we can take the result of those discussions into any of the sessions
   that are after.

 * The Ops Summit is Wendesday/Thursday [3], which overlaps with these
   sessions. I am keenly interested in gathering more contribution from
   those already operating and deploying OpenStack. It can go both ways,
   but I think it might make sense to have more ops-centric topics
   discussed on Friday, when those participants might not be fully
   wrapped up in the ops sessions.

 If we can all agree on those points, given the current topics, I think
 our scheduled sessions should target at least (but not limited to):

 * Cinder + CEPH
 * Layer 3 segmentation

 I think those might fit into 40 minutes, as long as we hash some things
 out here on the mailing list first. Cinder + CEPH is really just a
 check-in to make sure we're on track to providing it. Layer 3, I've had
 discussions with Ironic and Neutron people and I think we have a plan,
 but I wanted to present it in the open and discuss the short term goals
 to see if it satisfies what users may want for the Kilo time frame.

 So, I would encourage you all to look at the etherpad, and expand on
 topics or add more, and then reply to this thread with ideas for how
 best to use our precious time together.

 [1] http://kilodesignsummit.sched.org/overview/type/tripleo
 [2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics
 [3] http://kilodesignsummit.sched.org/overview/type/ops+summit
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

[openstack-dev] [tc] new big tent change in the governance repo

2014-10-27 Thread Doug Hellmann

Several people mentioned that it would be easier to review the policy changes 
in the “big tent” series if they were squashed into a single patch. I’ve done 
that in https://review.openstack.org/131227. The first version of the patch is 
the squashed series as it existed before, and the second version of the patch 
includes most of the proposed changes to wording. There were a few cases where 
significant changes were requested, and I want to let those see more discussion 
before making them.

Doug


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

Re: [openstack-dev] [all] Key signing at the summit?

2014-10-27 Thread Marty Falatic (mfalatic)

I'm relatively new to the keysigning *event* concept - can someone give a 
little more detail on this and where it comes into play? Does anyone else use a 
service (e.g., keybase.io) for this purpose?

 - Marty Falatic




-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com] 
Sent: Sunday, October 26, 2014 5:01 PM
To: openstack-dev
Subject: [openstack-dev] [all] Key signing at the summit?

Hi everyone! We have a summit rapidly approaching, and to my knowledge, no key 
signing event planned. That is unfortunate, as the web of trust that we started 
building in Atlanta would be quite stronger as we add more European developers 
who I'm sure will be present in large numbers due to proximity.

I believe we may be too late to do a mass keysigning, though if others feel we 
have time to gather fingerprints and disseminate a list for printing, then I 
will try to devote some time to it in the next 24 hours. However, I want to 
encourage everyone to print out your signature en-masse (hint hint: print it on 
your business cards) so that you can do an impromptu verification of identity 
with somebody. It may also be valuable to arrange a time where everyone can be 
present with their government issued IDs even if there isn't a mass list.

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

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

[openstack-dev] cliff 1.8.0 released

2014-10-27 Thread Doug Hellmann

The Oslo team is pleased to announce the release version 1.8.0 of cliff, our 
command line interface framework. This release is primarily being made to 
update the metadata on PyPI now that the documentation has moved to its new 
location on docs.openstack.org. It does include several other changes:

$ git log --oneline --no-merges 1.7.0..1.8.0
230c0d3 Update link to docs in README
476c1dc Bring doc build up to standard
cd551d8 Add pbr to installation requirements
728aea7 Add more detail to the README
6c5148a Updated from global requirements
d636fab Add docs environment to tox.ini
3ec9206 mock.assert_called_once() is not a valid method
a010edc Work toward Python 3.4 support and testing
cafe14e warn against sorting requirements

Please report issues through launchpad: https://launchpad.net/python-cliff/kilo

Doug


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

Re: [openstack-dev] [all] Key signing at the summit?

2014-10-27 Thread Spencer Krum

I would be excited to exchange key information at the summit. I do not have
key fingerprint on my cards at this point, but I can do the old
slip-of-paper method. I would be open to either organized fashion or ad-hoc.

Thanks,
Spencer

On Mon, Oct 27, 2014 at 12:05 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2014-10-27 18:53:26 + (+), Marty Falatic (mfalatic) wrote:
  I'm relatively new to the keysigning *event* concept - can someone
  give a little more detail on this and where it comes into play?
 [...]

 The idea being that attendees prearrange a time, place and perhaps
 requisite fingerprint list to follow some process as a group, for
 example http://keysigning.org/methods/sassaman-projected
 --
 Jeremy Stanley

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




-- 
Spencer Krum
(619)-980-7820
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] [devstack] Generic scripts for Tempest configuration

2014-10-27 Thread Timur Nurlygayanov

Thank you, Rocky!

I have reviewed these specs, looks very promising. I want to participate in
implementation.

On Sat, Oct 25, 2014 at 3:49 AM, Rochelle.RochelleGrober 
rochelle.gro...@huawei.com wrote:

  Hi, Timur.



 Check out [1].   Boris Pavlovic has been working towards what you want for
 more than a full release cycle.  There are still major issues to be
 conquered, but having something that gets us part of the way there and can
 identify what can’t be determined so that the humans have only a subset to
 work out would be a great first step.



 There are also other reviews out there that need to come together to
 really make this work.  And projects that would be the better for it
 (Refstack and Rally).  These are [2] allowing Tempest tests to run as
 non-admin, [3] making Tempest pluggable, [4] refactoring the client manager
 to be more flexible.



 I think some others may have merged already.  The  bottom line is to
 refactor tempest such that there is a test server with the necessary tools
 and components to make it work, and a tempest lib such that writing tests
 can benefit from common procedures.



 Enjoy the reading.



 --Rocky





 [1] https://review.openstack.org/#/c/94473/

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

 [3] https://review.openstack.org/#/c/89322/

 [4] https://review.openstack.org/#/c/92804/





 *From:* Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
 *Sent:* Friday, October 24, 2014 4:05 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [tempest] [devstack] Generic scripts for
 Tempest configuration



 Hi all,

 we are using Tempest tests to verify every changes in different OpenStack
 components and we have scripts in devstack, which allow to configure
 Tempest.

 We want to use Tempest tests to verify different clouds, not only
 installed with devstack and to do this we need to configure Tempest
 manually (or with some no-generic scripts, which allow to configure tempest
 for specific lab configuration).

 Looks like we can improve these scripts for configuration of the Tempest,
 which we have in devstack repository now and create generic scripts for
 Tempest, which can be used by devstack scripts or manually, to configure
 Tempest for any private/public OpenStack clouds. These scripts should allow
 to easily configure Tempest: user should provide only Keystone endpoint and
 logins/passwords, other parameters can be optional and can be configured
 automatically.



 The idea is to have the generic scripts, which will allow to easily
 configure Tempest from-the-box, without deep inspection of lab
 configuration (but with the ability to change optional parameters too, if
 it is required).


 --



 Timur,

 Senior QA Engineer

 OpenStack Projects

 Mirantis Inc

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




-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Key signing at the summit?

2014-10-27 Thread Morgan Fainberg

I am definitely game to join for key signing. I however don't have cards for 
this (come to think of it, this is an excuse to get business cards even if they 
are only for my key sig). I'll probably try and get some paper slips made up 
for this too. 

--Morgan 

Sent via mobile

 On Oct 27, 2014, at 13:47, Spencer Krum krum.spen...@gmail.com wrote:
 
 I would be excited to exchange key information at the summit. I do not have 
 key fingerprint on my cards at this point, but I can do the old slip-of-paper 
 method. I would be open to either organized fashion or ad-hoc.
 
 Thanks,
 Spencer
 
 On Mon, Oct 27, 2014 at 12:05 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2014-10-27 18:53:26 + (+), Marty Falatic (mfalatic) wrote:
  I'm relatively new to the keysigning *event* concept - can someone
  give a little more detail on this and where it comes into play?
 [...]
 
 The idea being that attendees prearrange a time, place and perhaps
 requisite fingerprint list to follow some process as a group, for
 example http://keysigning.org/methods/sassaman-projected
 --
 Jeremy Stanley
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 Spencer Krum
 (619)-980-7820
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] [devstack] Generic scripts for Tempest configuration

2014-10-27 Thread Boris Pavlovic

Timur,

I have reviewed these specs, looks very promising. I want to participate in
 implementation.


Nice! cause there will be a lot of work

Best regards,
Boris Pavlovic

On Tue, Oct 28, 2014 at 1:14 AM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 Thank you, Rocky!

 I have reviewed these specs, looks very promising. I want to participate
 in implementation.

 On Sat, Oct 25, 2014 at 3:49 AM, Rochelle.RochelleGrober 
 rochelle.gro...@huawei.com wrote:

  Hi, Timur.



 Check out [1].   Boris Pavlovic has been working towards what you want
 for more than a full release cycle.  There are still major issues to be
 conquered, but having something that gets us part of the way there and can
 identify what can’t be determined so that the humans have only a subset to
 work out would be a great first step.



 There are also other reviews out there that need to come together to
 really make this work.  And projects that would be the better for it
 (Refstack and Rally).  These are [2] allowing Tempest tests to run as
 non-admin, [3] making Tempest pluggable, [4] refactoring the client manager
 to be more flexible.



 I think some others may have merged already.  The  bottom line is to
 refactor tempest such that there is a test server with the necessary tools
 and components to make it work, and a tempest lib such that writing tests
 can benefit from common procedures.



 Enjoy the reading.



 --Rocky





 [1] https://review.openstack.org/#/c/94473/

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

 [3] https://review.openstack.org/#/c/89322/

 [4] https://review.openstack.org/#/c/92804/





 *From:* Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
 *Sent:* Friday, October 24, 2014 4:05 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [tempest] [devstack] Generic scripts for
 Tempest configuration



 Hi all,

 we are using Tempest tests to verify every changes in different OpenStack
 components and we have scripts in devstack, which allow to configure
 Tempest.

 We want to use Tempest tests to verify different clouds, not only
 installed with devstack and to do this we need to configure Tempest
 manually (or with some no-generic scripts, which allow to configure tempest
 for specific lab configuration).

 Looks like we can improve these scripts for configuration of the Tempest,
 which we have in devstack repository now and create generic scripts for
 Tempest, which can be used by devstack scripts or manually, to configure
 Tempest for any private/public OpenStack clouds. These scripts should allow
 to easily configure Tempest: user should provide only Keystone endpoint and
 logins/passwords, other parameters can be optional and can be configured
 automatically.



 The idea is to have the generic scripts, which will allow to easily
 configure Tempest from-the-box, without deep inspection of lab
 configuration (but with the ability to change optional parameters too, if
 it is required).


 --



 Timur,

 Senior QA Engineer

 OpenStack Projects

 Mirantis Inc

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




 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 Mirantis Inc

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


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

[openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack

2014-10-27 Thread Steven Hardy

Hi all,

Lately I've been spending a lot more time digging into TripleO and Tuskar,
and started looking for a way to spin up simple tests (and in particular,
play with Tuskar UI/API) without necessarily having the overhead of setting
up a full devtest environment every time.

So I decided to hack on a patch which automates starting tuskar-api via
devstack, here's a quick HOWTO if you want to try it:

1. Pull devstack patch
https://review.openstack.org/#/c/131218/

2. Add t-api to localrc
enable_service t-api
Here's my example (Ironic enabled) localrc:
https://gist.github.com/hardys/2cfd2892ce0e63fa8155

3. Add tuskar roles
git clone git://github.com/openstack/tripleo-heat-templates.git
cd tripleo-heat-templates·
tuskar-load-roles --config-file /etc/tuskar/tuskar.conf -r compute.yaml -r 
controller.yaml

3. clone+install tuskar-ui
git clone git://github.com/openstack/tuskar-ui.git
cd tuskar-ui
python setup.py install

4. Copy tuskar-ui horizon config
cp ~/tuskar-ui/_50_tuskar.py.example
/opt/stack/horizon/openstack_dashboard/local/enabled/_50_tuskar.py
sudo systemctl restart httpd.service

This provides a basically functional tuskar API and UI, which is enough for
basic testing of tuskar, tuskarclient and (to some extent) the UI.

I hit some issues, please let me know if new bugs are needed for these, or
if you can suggest solutions:

1. UI Infrastructure-Overview page always says No controller/compute node,
   even though both roles are loaded

2. UI Service configuration has no content at all

3. UI Deployment Roles page says Metering service is not enabled., but
   ceilometer is installed and active

4. UI: If, Ironic isn't available for any reason, you get a big error from the
   Nodes page of the UI

5. API: You can't create or modify roles via the API, or even view the
content of the role after creating it

6. After running tuskar-load-roles, the overcloud_roles table is always
empty (related to 1?)

I'd be interested in peoples thoughts about this general approach - ideally
I'd like to end up at a point where you could launch an overcloud template
directly via heat on devstack (with ironic enabled and the appropriate
controller/compute images in glance obviously) - has anyone else tried
that?

Steve

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

Re: [openstack-dev] [glance]


On 10/27/2014 06:18 PM, Jesse Cook wrote:

In the glance mini-summit there was a request for some documentation on
the architecture ideas I was discussing relating to: 1) removing data
consistency as a concern for glance 2) bootstraping vs baking VMs

Here's a rough draft: https://gist.github.com/CrashenX/8fc6d42ffc154ae0682b


Hi Jesse!

A few questions for you, since I wasn't at the mini-summit and I think 
don't have a lot of the context necessary here...


1) In the High-Level Architecture diagram, I see Glance Middleware 
components calling to a Router component. Could you elaborate what 
this Router component is, in relation to what components currently exist 
in Glance and Nova? For instance, is the Router kind of like the 
existing Glance Registry component? Or is it something more like the 
nova.image.download modules in Nova? Or something entirely different?


2) The Glance Middleware. Do you mean WSGI middleware here? Or are you 
referring to something more like the existing nova.image.api module that 
serves as a shim over the Glance server communication?


3) Images in Glance are already immutable, once the image bytes are 
actually uploaded to a backend block store. What conceptual differences 
are you introducing with the idea of object immutability?


4) How does the glance_store library play into your ideas, if at all?

5) How does the existing image locations collection in the Glance v2 
API work with your ideas? With an image uploaded to multiple locations 
(in Swift, Ceph clusters, wherever...), is the Router object in your 
architecture the thing that determines affinity for the best 
storage-locality to pull data from?


All the best,
-jay

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

Re: [openstack-dev] FreeBSD host support

2014-10-27 Thread Stefano Maffulli

On 10/27/2014 08:51 AM, Drew Fisher wrote:
 If devstack itself (not CI, but devstack) is a hard requirement for
 integration we need to probably start up a different thread on what the
 best way for other OSes like FreeBSD and Solaris to work around this
 issue.  What should we be looking at?  A compatible devstack clone that
 configures Solaris as a single-host development OpenStack rig?

I doubt devstack itself is a hard requirement for CI since
Windows/Hyper-V testing is done without devstack. I think what mordred
meant was that you need to provide a way like devstack for Infra team to
test things.

To put the thread back in topic, I would assume that the *BSD folks and
Oracle/Solaris would have good amount of overlap in this area.

How about you team up to either provide good patches to devstack to
support the non-linux options (if this is suitable) or develop a new
tool similar in scope to devstack for all BSD-family? Maybe that would
be good for OS X, too :)

Chat in Paris?

/stef

-- 
Ask and answer questions on https://ask.openstack.org

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

Re: [openstack-dev] [all] Key signing at the summit?

2014-10-27 Thread Angus Lees

On Mon, 27 Oct 2014 02:45:27 PM Jeremy Stanley wrote:
 If there is interest in doing another Sassaman-Projected Method
 exercise at future events, a USB document camera would be useful to
 procure in advance

Is this what the young kids these days are calling a phone?

-- 
 - Gus

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

Re: [openstack-dev] [all] Key signing at the summit?

On 2014-10-28 11:28:28 +1100 (+1100), Angus Lees wrote:
 Is this what the young kids these days are calling a phone?

Perhaps if said phone connected to the projector in a conference
room and came with a stand to hold it the right distance from a
desktop, so it could remain unmanned while people set documents on
the table for it to display. It's what us old kids used to call an
overhead projector.
-- 
Jeremy Stanley

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

Re: [openstack-dev] FreeBSD host support

2014-10-27 Thread Drew Fisher



On 10/27/14, 5:57 PM, Stefano Maffulli wrote:
 On 10/27/2014 08:51 AM, Drew Fisher wrote:
 If devstack itself (not CI, but devstack) is a hard requirement for
 integration we need to probably start up a different thread on what the
 best way for other OSes like FreeBSD and Solaris to work around this
 issue.  What should we be looking at?  A compatible devstack clone that
 configures Solaris as a single-host development OpenStack rig?
 
 I doubt devstack itself is a hard requirement for CI since
 Windows/Hyper-V testing is done without devstack. I think what mordred
 meant was that you need to provide a way like devstack for Infra team to
 test things.

Sounds good.

 
 To put the thread back in topic, I would assume that the *BSD folks and
 Oracle/Solaris would have good amount of overlap in this area.
 
 How about you team up to either provide good patches to devstack to
 support the non-linux options (if this is suitable) or develop a new
 tool similar in scope to devstack for all BSD-family? Maybe that would
 be good for OS X, too :)
 
 Chat in Paris?

I would love to.  Please ping me when you get a moment.

-Drew

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

Re: [openstack-dev] [glance] Permissions differences for glance image-create between Icehouse and Juno

2014-10-27 Thread Tom Fifield

This was covered in the release notes for glance, under Upgrade notes:

https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_3

* The ability to upload a public image is now admin-only by default. To
continue to use the previous behaviour, edit the publicize_image flag in
etc/policy.json to remove the role restriction.

Regards,


Tom

On 28/10/14 01:22, Jay Pipes wrote:
 Hello Glancers,
 
 Peter and I are having issues working with a Juno Glance endpoint.
 Specifically, a glance image-create ... --is_public=True CLI command
 that *was* working in our Icehouse cloud is now failing in our Juno
 cloud with a 403 Forbidden.
 
 The specific command in question is:
 
 glance image-create --name cirros-0.3.2-x86_64 --file
 /var/tmp/cirros-0.3.2-x86_64-disk.img --disk-format qcow2
 --container-format bare --is_public=True
 
 If we take off the is_public=True, everything works just fine. We are
 executing the above command as a user with a user called admin having
 the role admin in a project called admin.
 
 We have enabled debug=True conf option in both glance-api.conf and
 glance-registry.conf, and unfortunately, there is no log output at all,
 other than spitting out the configuration option settings on daemon
 startup and a few messages like Loaded policy rules: ... which don't
 actually provide any useful information about policy *decisions* that
 are made... :(
 
 Any help is most appreciated. Our policy.json file is the stock one that
 comes in the Ubuntu Cloud Archive glance packages, i.e.:
 
 http://paste.openstack.org/show/125420/
 
 Best,
 -jay
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!

On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery mest...@mestery.com wrote:
As discussed during the neutron-drivers meeting this week [1], we've
going to use one of the Neutron 40 minute design summit slots for
lightning talks. The basic idea is we will have 6 lightning talks,
each 5 minutes long. We will force a 5 minute hard limit here. We'll
do the lightning talk round first thing Thursday morning.

To submit a lightning talk, please add it to the etherpad linked here
[2]. I'll be collecting ideas until after the Neutron meeting on
Monday, 10-27-2014. At that point, I'll take all the ideas and add
them into a Survey Monkey form and we'll vote for which talks people
want to see. The top 6 talks will get a lightning talk slot.

I'm hoping the lightning talks allow people to discuss some ideas
which didn't get summit time, and allow for even new contributors to
discuss their ideas face to face with folks.

As discussed in the weekly Neutron meeting, I've setup a Survey Monkey
to determine which 6 talks will get a slot for the Neutron Lightning
Talk track at the Design Summit. Please go here [1] and vote. I'll
collect results until Thursday around 2300UTC or so, and then close
the poll and the top 6 choices will get a 5 minute lightning talk.

Thanks!
Kyle

[1] https://www.surveymonkey.com/s/RLTPBY6

Thanks!
Kyle

[1]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2014/neutron_drivers.2014-10-22-15.02.log.html
[2] https://etherpad.openstack.org/p/neutron-kilo-lightning-talks

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

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

2014-10-27 Thread shihanzhang

I also agree file a new bug for FWaaS








At 2014-10-28 00:09:29, Carl Baldwin c...@ecbaldwin.net wrote:
I think I'd suggest opening a new bug for FWaaS since it is a
different component with different code.  It doesn't seem natural to
extend the scope of this bug to include it.

Carl

On Mon, Oct 27, 2014 at 9:50 AM, Itzik Brown itbr...@redhat.com wrote:

 - Original Message -
 From: Carl Baldwin c...@ecbaldwin.net
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, October 27, 2014 5:27:57 PM
 Subject: Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking 
 ongoing traffic

 On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com
 wrote:
  Hello Itzik,
  This has been discussed lately on this ML. Please see
  https://bugs.launchpad.net/neutron/+bug/1335375.

 This is a good example that any create, update, or delete of a SG rule
 can expose this issue.  This bug only mentions delete.  I'll update
 the bug to increase the scope beyond just deletes because it really is
 the same conntrack issue at the root of the problem.

 Carl

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

 Carl,

 FWaaS has the same issues as well.
 What do you suggest - open a new bug or updating the current one?

 Thanks,
 Itzik

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

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

Re: [openstack-dev] [glance] Permissions differences for glance image-create between Icehouse and Juno


Right, but as you can read below, I'm using an admin to do the operation...

Which is why I'm curious what exactly I'm supposed to do :)

-jay

On 10/27/2014 09:04 PM, Tom Fifield wrote:

This was covered in the release notes for glance, under Upgrade notes:

https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_3

* The ability to upload a public image is now admin-only by default. To
continue to use the previous behaviour, edit the publicize_image flag in
etc/policy.json to remove the role restriction.

Regards,


Tom

On 28/10/14 01:22, Jay Pipes wrote:

Hello Glancers,

Peter and I are having issues working with a Juno Glance endpoint.
Specifically, a glance image-create ... --is_public=True CLI command
that *was* working in our Icehouse cloud is now failing in our Juno
cloud with a 403 Forbidden.

The specific command in question is:

glance image-create --name cirros-0.3.2-x86_64 --file
/var/tmp/cirros-0.3.2-x86_64-disk.img --disk-format qcow2
--container-format bare --is_public=True

If we take off the is_public=True, everything works just fine. We are
executing the above command as a user with a user called admin having
the role admin in a project called admin.

We have enabled debug=True conf option in both glance-api.conf and
glance-registry.conf, and unfortunately, there is no log output at all,
other than spitting out the configuration option settings on daemon
startup and a few messages like Loaded policy rules: ... which don't
actually provide any useful information about policy *decisions* that
are made... :(

Any help is most appreciated. Our policy.json file is the stock one that
comes in the Ubuntu Cloud Archive glance packages, i.e.:

http://paste.openstack.org/show/125420/

Best,
-jay

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



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



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

Re: [openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack