date:20141027

On Mon, Oct 27, 2014 at 4:42 AM, Ihar Hrachyshka  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
 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)
>  wrote:
>> Hi Doug:
>>
>> On 10/26/14, 6:01 PM, "Doug Wiegley"  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"  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

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

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley  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"  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" 
>>>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
>>> >h

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

2014-10-27 Thread Sergey Lukjanov

Ack.

On Fri, Oct 24, 2014 at 4:41 PM, Ilya Sviridov 
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=juno&metric=commits&project_type=stackforge&module=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  wrote:
> On Tuesday, October 21, 2014, Roman Bogorodskiy 
> wrote:
>>
>> On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon 
>> wrote:
>> > On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy
>> >  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 
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 mailto:amit.gan...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, October 24, 2014 at 2:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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/listi

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 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
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  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  
To:"OpenStack Development Mailing List (not for usage questions)" 
, 
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  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 
> wrote:
> 
>> On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon > > 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).

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

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" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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 
> 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:

>>
>> 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  wrote:
>
> - Original Message -
>> From: "Carl Baldwin" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> 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 
>> 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

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

2014-10-27 Thread Ricardo Carrillo Cruz

I think what you are trying to achieve is to have a branch that tracks
upstream for the upstream projects, and another branch that tracks local
development in your Gerrit project.
You may want to check Jeepyb:

http://ci.openstack.org/jeepyb.html

That tool is what Openstack CI uses to manage gerrit repo creation.
Let's take as an example that you wanted to have python-neutronclient
project in your Gerrit, that tracks upstream.

You would do something like this:

1. Install jeepyb and configure the projects.ini file according to your
environment.
1. Add python-neutronclient.config file to the folder your manage-projects
expect it to find (acl-dir parameter from previous step), with contents
similar to :

[access "refs/heads/*"]


abandon = group neutron-core


label-Code-Review = -2..+2 group neutron-core


label-Workflow = -1..+1 group neutron-core





[access "refs/heads/proposed/*"]


abandon = group neutron-milestone


label-Code-Review = -2..+2 group neutron-milestone


label-Workflow = -1..+1 group neutron-milestone





[access "refs/tags/*"]


pushSignedTag = group neutron-release





[receive]


requireChangeId = true


requireContributorAgreement = true





[submit]


mergeContent = true

2. Create an entry in gerrit/projects.yaml file from project-config repo
like:

- project: openstack/python-neutronclient


  upstream: https://git.openstack.org/openstack/python-neutronclient


  options:


- track-upstream

3. Run 'manage-projects python-neutronclient'

After this, the tool would create the project 'python-neutronclient' with
the acl defined from step 1 and set it to track upstream (as per the option
depicted on step 2).
After this, you could just create branches off master from the Gerrit UI
(or define them upfront in the acl in step 1, but this way would get you
started faster).

If you use the upstream openstack_project::review.pp manifest the
configuration to get this going is greatly reduced (it's a mega manifest
that installs gerrit, jeepyb and other things), I can help you with that.

Regards


2014-10-27 15:22 GMT+01:00 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 appr

[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  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"  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

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  wrote:

> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
>  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)
> >  wrote:
> >> Hi Doug:
> >>
> >> On 10/26/14, 6:01 PM, "Doug Wiegley"  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" 
> 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 w

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

On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami  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  wrote:
>>
>> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
>>  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)
>> >  wrote:
>> >> Hi Doug:
>> >>
>> >> On 10/26/14, 6:01 PM, "Doug Wiegley"  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" 
>> >>> 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
>> "

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

2014-10-27 Thread Mandeep Dhami

Got it. So we will be discussing this in the 2PM meeting today. Correct?

Regards,
Mandeep

On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery  wrote:

> On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami 
> 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 
> wrote:
> >>
> >> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
> >>  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)
> >> >  wrote:
> >> >> Hi Doug:
> >> >>
> >> >> On 10/26/14, 6:01 PM, "Doug Wiegley"  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" 
> >> >>> wrote:
> >> >>>
> >> Good questions Doug.  My answers are as follows:
>

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] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

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  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"  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" 
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 projec

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"  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 
>>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" 
>>>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" 
> wrote:
>
>>

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"  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 
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" 
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" 
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 b

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

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

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

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

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

Excerpts from Ben Nemec's message of 2014-10-27 11:39:31 -0700:
> 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.
> 

Regardless of the changes that need to happen outside TripleO's
projects, we will have new things to configure, and new user interface
elements to discuss in Tuskar. I also want to check in on the status of
any changes we do need to drive. I want to use the scheduled sessions
for this so that anyone from those teams can come and comment, or
users/operators can come to understand how the change needs to percolate
through the rest of OpenStack.

> > 
> > * 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.
>

I think that's exactly what I'd like to see: the summary of what you
wrote about. This is for public dissemination and also for Q&A. We are
crowd-sourcing ideas in this context, not really putting together design
elements. I mostly want to make sure people who have tried it or are
interested in trying it can get connected with you and the rest of the
team in this context. "Embrace the beta testers" basically.

> >  - 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.
>

Yes, they all need to have deeper discussions on Friday. What I want to
do here is to have the people interested and responsible in these tool
sets stand up, introduce themselves, state clearly what their project
is trying to accomplish, and that is all. This way interested parties
can engage with these individuals and we can come to Friday ready to
work together on the topics that are most urgent and that have the
broadest appeal.

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

[openstack-dev] [openstack] [neutron] Comments on peer reviews

2014-10-27 Thread Gregory Lebovitz

As committed last week, I've provided review comments in the draft
peer-review process [1].

Hopefully we can discuss a bit in today's 2pm PDT Neutron weekly, and more
at Summit.

Hope it helps.

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

-- 

Open communities related email from
Gregory M. Lebovitz
___
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  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  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  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

[openstack-dev] [glance]

2014-10-27 Thread Jesse Cook

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

Jesse
___
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] [Neutron][LBaaS][Octavia] Usage Requirements

2014-10-27 Thread Angus Lees

On Wed, 22 Oct 2014 11:29:27 AM Robert van Leeuwen wrote:
> > I,d like to start a conversation on usage requirements and have a few
> > suggestions. I advocate that, since we will be using TCP and HTTP/HTTPS
> > based protocols, we inherently enable connection logging for load
> 
> > balancers for several reasons:
> Just request from the operator side of things:
> Please think about the scalability when storing all logs.
> 
> e.g. we are currently logging http requests to one load balanced application
> (that would be a fit for LBAAS) It is about 500 requests per second, which
> adds up to 40GB per day (in elasticsearch.) Please make sure whatever
> solution is chosen it can cope with machines doing 1000s of requests per
> second...

And to take this further, what happens during DoS attack (either syn flood or 
full connections)?  How do we ensure that we don't lose our logging system 
and/or amplify the DoS attack?

One solution is sampling, with a tunable knob for the sampling rate - perhaps 
tunable per-vip.  This still increases linearly with attack traffic, unless you 
use time-based sampling (1-every-N-seconds rather than 1-every-N-packets).

One of the advantages of (eg) polling the number of current sessions is that 
the cost of that monitoring is essentially fixed regardless of the number of 
connections passing through.  Numerous other metrics (rate of new connections, 
etc) also have this property and could presumably be used for accurate billing 
- without amplifying attacks.

I think we should be careful about whether we want logging or metrics for more 
accurate billing.  Both are useful, but full logging is only really required 
for ad-hoc debugging (important! but different).

-- 
 - Gus

___
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  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"  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  wrote:
>>
>> - Original Message -
>>> From: "Carl Baldwin" 
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> 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 
>>> 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