Re: [openstack-dev] [Policy][Group-based-policy] SFC Use Case

[Sumit Naiksatam]

Hi Naresh, I believe you are hitting this bug:

https://bugs.launchpad.net/group-based-policy/+bug/1418839

Try an AWS-type template [1] and it should work. Alternatively, you
can get the HOT template to work in your local environment by applying
this small fix:
https://review.openstack.org/#/c/160629/1/gbpservice/neutron/db/servicechain_db.py

Thanks,
~Sumit.

[1] 
https://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/gbp-templates/firewall-lb-servicechain/fw.template

On Mon, Nov 2, 2015 at 10:28 PM, NareshA kumar
 wrote:
> Hi Sumit,
> Can you kindly share an example yaml file for firewall. With my yaml file I
> am able to create vm through heat but while creating service node it says
> "Invalid file format".
>
> Regards.
> Naresh
>
> On Mon, Nov 2, 2015 at 1:31 PM, Sumit Naiksatam 
> wrote:
>>
>> Hi Naresh, You should be able to use the same heat templates.
>>
>> Thanks,
>> ~Sumit.
>>
>> On Fri, Oct 30, 2015 at 3:06 AM, NareshA kumar
>>  wrote:
>> > Hi,
>> > I have tried GBP in Kilo. Now I want to try GBP+SFC integration in Kilo.
>> > Regarding which i have few questions,
>> >
>> > Is GBP+SFC supported now in Kilo?
>> > If yes, please suggest me some links to follow.
>> > For creating SFC in kilo where can I find heat templates?
>> >
>> > Regards,
>> >
>> > Naresh.
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Michal Rostecki]

Hi,

+1 to what Steven said about Kubernetes.

I'd like to add that these 3 things (pid=host, net=host, -v) are 
supported by Marathon, so probably it's much less problematic for us 
than Kubernetes at this moment.


Regards,
Michal

On 11/03/2015 12:18 AM, Steven Dake (stdake) wrote:

Gosh,

Kubernetes as an underlay is an interesting idea.  We tried it for the
first 6 months of Kolla’s existence and it almost killed the project.
  Essentially kubernetes lacks support for pid=host, net=host, and –v
bind mounting.  All 3 are required to deliver an operational OpenStack.

This is why current Kolla goes with a bare metal underlay – all docker
options we need are available.

Regards
-steve


From: Georgy Okrokvertskhov mailto:gokrokvertsk...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 3:47 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Mesos orchestration as discussed at
mid cycle (action required from core reviewers)

Hi Steve,

Thank you for the update. This is really interesting direction for Kolla.
I agree with Jeff. It is interesting to see what other frameworks will
be used. I suspect Marathon framework is under consideration as it adds
most of the application centric functionality like HA\restarter, scaling
and rolling-restarts\upgrades. Kubernetes might be also a good candidate
for that.

Thanks
Gosha

On Mon, Nov 2, 2015 at 2:00 PM, Jeff Peeler mailto:jpee...@redhat.com>> wrote:

On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake)
mailto:std...@cisco.com>> wrote:
> Hey folks,
>
> We had an informal vote at the mid cycle from the core reviewers, and it 
was
> a majority vote, so we went ahead and started the process of the
> introduction of mesos orchestration into Kolla.
>
> For background for our few core reviewers that couldn’t make it and the
> broader community, Angus Salkeld has committed himself and 3 other 
Mirantis
> engineers full time to investigate if Mesos could be used as an
> orchestration engine in place of Ansible.  We are NOT dropping our Ansible
> implementation in the short or long term.  Kolla will continue to lead 
with
> Ansible.  At some point in Mitaka or the N cycle we may move the ansible
> bits to a repository called “kolla-ansible” and the kolla repository would
> end up containing the containers only.
>
> The general consensus was that if folks wanted to add additional
> orchestration systems for Kolla, they were free to do so if they did the
> development and made a commitment to maintaining one core reviewer team 
with
> broad expertise among the core reviewer team of how these various systems
> work.
>
> Angus has agreed to the following
>
> A new team called “kolla-mesos-core” with 2 members.  One of the members 
is
> Angus Salkeld, the other is selected by Angus Salkeld since this is a 
cookie
> cutter empty repository.  This is typical of how new projects would 
operate,
> but we don’t want a code dump and instead want an integrated core team.  
To
> prevent a situation which the current Ansible expertise shy away from the
> Mesos implementation, the core reviewer team has committed to reviewing 
the
> mesos code to get a feel for it.
> Over the next 6-8 weeks these two folks will strive to join the Kolla core
> team by typical means 1) irc participation 2) code generation 3) effective
> and quality reviews 4) mailing list participation
> Angus will create a technical specification which will we will roll-call
> voted and only accepted once a majority of core review team is satisfied
> with the solution.
> The kolla-mesos deliverable will be under Kolla governance and be managed 
by
> the Kolla core reviewer team after the kolla-mesos-core team is 
deprecated.
> If the experiment fails, kolla-mesos will be placed in the attic.  There 
is
> no specific window for the experiments, it is really up to Angus to decide
> if the technique is viable down the road.
> For the purpose of voting, the kolla-mesos-core team won’t be permitted to
> vote (on things like this or other roll-call votes in the community) until
> they are “promoted” to the koala-core reviewer team.
>
>
> The core reviewer team has agreed to the following
>
> Review patches in kolla-mesos repository
> Actively learn how the mesos orchestration system works in the context of
> Kolla
> Actively support Angus’s effort in the existing Kolla code base as long as
> it is not harmful to the Kolla code base
>
> We all believe this will lead to a better outcome then Mirantis developing
> some code on their own and later dumping it into the Kolla governance or
   

Re: [openstack-dev] [Policy][Group-based-policy] SFC Use Case

[NareshA kumar]

Hi Sumit,
Can you kindly share an example yaml file for firewall. With my yaml file I
am able to create vm through heat but while creating service node it says
"Invalid file format".

Regards.
Naresh

On Mon, Nov 2, 2015 at 1:31 PM, Sumit Naiksatam 
wrote:

> Hi Naresh, You should be able to use the same heat templates.
>
> Thanks,
> ~Sumit.
>
> On Fri, Oct 30, 2015 at 3:06 AM, NareshA kumar
>  wrote:
> > Hi,
> > I have tried GBP in Kilo. Now I want to try GBP+SFC integration in Kilo.
> > Regarding which i have few questions,
> >
> > Is GBP+SFC supported now in Kilo?
> > If yes, please suggest me some links to follow.
> > For creating SFC in kilo where can I find heat templates?
> >
> > Regards,
> >
> > Naresh.
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next week

[Oleg Bondarev]

Just realized that tomorrow is a non-working day in Russia due to Unity
Day.
Still will try to attend the first meeting.

Thanks,
Oleg

On Mon, Nov 2, 2015 at 9:47 PM, Ryan Moats  wrote:

> Ditto Ryan (regXboi) Moats
>
> Carl Baldwin  wrote on 11/02/2015 11:47:27 AM:
>
> > From: Carl Baldwin 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 11/02/2015 11:48 AM
> > Subject: Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next
> week
>
> >
> > Thanks, Brian.  I'm planning to be there.
> >
> > Carl
> >
> > On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley 
> wrote:
> > > A few of us had a discussion this week at Summit and decided to
> re-start the
> > > weekly Neutron Distributed Virtual Router (DVR) meeting.  The goal is
> to
> > > help:
> > >
> > > - Stabilize DVR - fix the bugs
> > > - Address performance/scalability issues
> > > - Get the DVR jobs voting again
> > >
> > > Meetings will be on Wednesdays starting next week at 15:00 UTC.  I'm
> in the
> > > process of updating
> > >
> http://eavesdrop.openstack.org/#Neutron_Distributed_Virtual_Router_Meeting
> > > with a link to the meeting page and agenda, which is currently at
> > > https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
> > >
> > > -Brian
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] SR-IOV subteam

[Nikola Đipanov]

Hello Nova,

Looking at Mitaka specs, but also during the Tokyo design summit
sessions, we've seen several discussions and requests for enhancements
to the Nova SR-IOV functionality.

It has been brought up during the Summit that we may want to organize as
a subteam to track all of the efforts better and make sure we get all
the expert reviews on stuff more quickly.

I have already added an entry on the subteams page [1] and on the
reviews etherpad for Mitaka [2]. We may also want to have a meeting
slot. As I am out for the week, I'll let others propose a time for it
(that will hopefully work for all interested parites and their
timezones) and we can take it from there next week.

As always - comments and suggestions much appreciated.

Many thanks,
Nikola

[1] https://wiki.openstack.org/wiki/Nova#Nova_subteams
[2] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Cinder Mitaka Deadlines

[John Griffith]

On Mon, Nov 2, 2015 at 7:27 PM, Sean McGinnis  wrote:

> Cinder Release Schedule
>
> After some discussion at the Mitaka Design Summit, the Cinder team will be
> altering our release schedule for this release to simplify deadlines and
> closer align with the established OpenStack release schedule.
>
> Overall Deadlines for Mitaka [1]
>
> * Mitaka-1 (Dec 1-3)
> * Mitaka-2 (Jan 19-21)
> * Mitaka-3 (Mar 1-3)
>   * Final release for client libraries
>   * FeatureFreeze
>   * Soft StringFreeze
> * Mitaka Release (April 7)
>
>
> Based on these dates, the following are the deadlines for Cinder changes
> to be
> merged:
>
> * New backend drivers (Jan 19, 7:59 UTC)
> * Spec/blueprint approval deadline (Jan 19, 7:59 UTC)
> * New features and driver functionality (Mar 1, 7:50 UTC)
>   * Note: changes that require client updates will need to be
>   made available in enough time for both client and
>   service changes to merge.
>
> After the stated deadlines, it will be at the discretion of the Cinder core
> team whether to allow any exceptions based on scope of work and perceived
> risk.
>
> To increase the odds that your code will be accepted in Mitaka - do not
> wait
> until close to the deadlines to submit your work. Code needs to be reviewed
> and CI testing performed before it merges. This may take some time. Do not
> expect that code submitted prior to the deadline means that it will be
> accepted.
>
> Note to new driver submitters:
> All requirements stated here [2] and in related pages still apply. Even
> though
> the deadline has been pushed out, all third party CI and code quality
> requirements must still be met.
>
> Sean (smcginnis)
>
> [1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
> [2] https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

​Seems reasonable to me, and a descent balance of process/deadlines without
going overboard.​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

[Joshua Harlow]

Thanks robert,

I've started to tweak https://review.openstack.org/#/c/209661/ with 
regard to the outcome of that (at least to cover the basics)... Should 
be finished up soon (I hope).


Robert Collins wrote:

Hi, at the summit we had a big session on distributed lock managers (DLMs).

I'd just like to highlight the conclusions we came to in the session (
 https://etherpad.openstack.org/p/mitaka-cross-project-dlm
 )

Firstly OpenStack projects that want to use a DLM can make it a hard
dependency. Previously we've had a unwritten policy that DLMs should
be optional, which has led to us writing poor DLM-like things backed
by databases :(. So this is a huge and important step forward in our
architecture.

As in our existing pattern of usage for database and message-queues,
we'll use an oslo abstraction layer: tooz. This doesn't preclude a
different answer in special cases - but they should be considered
special and exception, not the general case.

Based on the project requirements surfaced in the discussion, it seems
likely that all of konsul, etc and zookeeper will be able to have
suitable production ready drivers written for tooz. Specifically no
project required a fair locking implementation in the DLM.

After our experience with oslo.messaging however, we wanted to avoid
the situation of having unmaintained drivers and no signalling to
users about them.

So, we resolved to adopt roughly the oslo.messaging requirements for
drivers, with a couple of tweaks...

Production drivers in-tree will need:
  - two nominated developers responsible for it
  - gating functional tests that use dsvm
Test drivers in-tree will need:
  - clear identification that the driver is a test driver - in the
module name at minimum

All hail our new abstraction overlords.

-Rob



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Implementation and policy of keystone

[Adam Young]

On 11/01/2015 08:19 AM, Toshiya Shiga wrote:

Hi.

We want to implement that the project users are able to manage the users of 
own's project.
We are considering some proposals for that.

which keystone project's policy is using "domain" (e.g. reseller)or is not using 
"domain"?
We want a proposal that meets the project of policy.


Big topic on the Keystone side of this past summit.

THe short:
Don't use domain scoped tokens.  Use Project scoped tokens.  We are 
finishing up the "domain is a project" work and also getting a way to 
set the "admin" project for a deployment;







Thanks and Regards,

---

Toshiya Shiga

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Add expected_task for instance.save() used by block_device mapping in compute.manager._build_resources

[Zhenyu Zheng]

Hi all,

We have recently meet this problem: for large scale deployment, command can
be sent concurrently, and for several times, when an instance was asked to
be delete during it is launching, we observed that the vm_state and
task_state of that instance has changed abnormally like this:

When we delete the instance while its' task state is networking:
scheduling->none->（networking）->deleting->block_device_mapping-->spawing-->none
The expected task_state should be:
networking->deleting->deleted
and the vm_state changes like this:
BUILD-ACIVE-disappear , which is also very strange for user.

After we dive deeper, we found out that in the _build_resource code, the
instance.save() for block_device_mapping doesn't contain
expected_task_state:
https://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2135
,
so it also saved "deleting" and two process keep working which causes the
above situation.

How about we add some expected_task_state also for block_device_mapping?
The expected task states can be NETWORKING, SCHEDULING, and none.

I have registered a bug for this:
https://bugs.launchpad.net/nova/+bug/1512563

Any suggestions?

Best Regards,
Zheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

[Geoff O'Callaghan]

On 03/11/2015 1:28 PM, "Robert Collins"  wrote:
>
> Hi, at the summit we had a big session on distributed lock managers
(DLMs).

Awesome.

>
> I'd just like to highlight the conclusions we came to in the session (
> https://etherpad.openstack.org/p/mitaka-cross-project-dlm
> )
>
> Firstly OpenStack projects that want to use a DLM can make it a hard
> dependency. Previously we've had a unwritten policy that DLMs should
> be optional, which has led to us writing poor DLM-like things backed
> by databases :(. So this is a huge and important step forward in our
> architecture.

Agreed and it's also a positive step.

>
> As in our existing pattern of usage for database and message-queues,
> we'll use an oslo abstraction layer: tooz. This doesn't preclude a
> different answer in special cases - but they should be considered
> special and exception, not the general case.
>
> Based on the project requirements surfaced in the discussion, it seems
> likely that all of konsul, etc and zookeeper will be able to have
> suitable production ready drivers written for tooz. Specifically no
> project required a fair locking implementation in the DLM.
>
> After our experience with oslo.messaging however, we wanted to avoid
> the situation of having unmaintained drivers and no signalling to
> users about them.
>
> So, we resolved to adopt roughly the oslo.messaging requirements for
> drivers, with a couple of tweaks...
>
> Production drivers in-tree will need:
>  - two nominated developers responsible for it
>  - gating functional tests that use dsvm
> Test drivers in-tree will need:
>  - clear identification that the driver is a test driver - in the
> module name at minimum
>
> All hail our new abstraction overlords.

This really is fantastic news.   Thanks for the 'heads up'.

Geoff

>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [app-catalog] Community App Catalog in Tokyo

[Christopher Aedo]

I want to start with a big thank you to everyone who made it to the
Community App Catalog fishbowl and working sessions last Thursday in
Tokyo.  Those of us who have been working at making the App Catalog
deliver on it's potential really appreciate your attention and input -
thanks!

Though we had several great discussions in a few different sessions, I
wanted to highlight the things I took away as being the most important
features/considerations we need to take into account for the next
cycle.

Trusted Content - Several people highlighted the importance of
guaranteeing any given content in the App Catalog was not modified at
any point.  Additionally there should be some assurance the asset was
in fact added by the user or organization indicated.  We will work on
providing a method of verifiable signatures for all assets, likely
similar to GPG signatures on Debian packages.

Approved/Supported Content - In addition to providing a mechanism to
guarantee the integrity of assets in the App Catalog, cloud operators
also asked for a way to easily highlight specific content for THEIR
users.  The use case would be a public or private cloud that wants to
provide some supported assets (apps, or app components) in that
environment.  This will allow an operator to indicate clearly which
apps in the catalog they will provide support for, while
distinguishing those assets from others in the catalog.  I was
especially happy to hear several operators were interested in this
approach as I believe this will go a long way towards allowing
different OpenStack clouds to provide "supported" content without
needing to create their own private catalogs.  The obvious broader
benefit here is that all users of OpenStack gain when multiple
operators are sharing their apps with the community.

Improving the add/modify workflow - Out of necessity, the "beta"
version of the App Catalog at launch used YAML files which were
modified via the standard OpenStack gerrity review process.  This made
it easy to quickly get the first iteration of the App Catalog out the
door, but left a lot to be desired when it comes to making it quick
and easy to add content.  In order to move forward on improving this
process, we're working on a proper API that will allow content to much
more easily added.  The web site will include a way for registered
users to add content via web form in addition to using the OpenStack
CLI (or just via the REST interface).

Additional IRC meeting times - There was a great point raised when I
was making a call for better participation in our IRC meetings.  Right
now we meet Thursdays at 1700UTC, which is a really inconvenient time
for folks in Asia & Australia.  I'm going to work on adding a second
meeting time (possibly chaired by someone else) in the next few weeks.

As requested by a few folks, the slides I used are available here:
http://www.slideshare.net/aedocw/community-app-catalog-introduction-tokyo-openstack-summit
(Unfortunately the slides don't capture the best parts of the
presentation - the live demonstration of the Horizon plugin and the
discussion we had after I ran through the background and status.)

If there are other things you'd like to see us focus on during the
next cycle, or have anything to add, please speak up on the mailing
lists or join us on IRC - thank you!

-Christopher

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] DevStack errors...

[Ian Wienand]

On 11/03/2015 10:51 AM, Thales wrote:

I'm trying to get DevStack to work, but am getting errors.  Is this
a good list to ask questions for this?  I can't seem to get answers
anywhere I look.  I tried the openstack list, but it kind of moves
slow.


Best to file a bug in launchpad, and *attach the full log*.  Very
often with devstack the root cause of a problem happens well before
the issue manifests itself as an error.

I won't say every bug gets attention immediately, but it's something
useful you can ping people with in irc, etc.

-i

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Cinder Mitaka Deadlines

[Sean McGinnis]

Cinder Release Schedule

After some discussion at the Mitaka Design Summit, the Cinder team will be
altering our release schedule for this release to simplify deadlines and
closer align with the established OpenStack release schedule.

Overall Deadlines for Mitaka [1]

* Mitaka-1 (Dec 1-3)
* Mitaka-2 (Jan 19-21)
* Mitaka-3 (Mar 1-3)
  * Final release for client libraries
  * FeatureFreeze
  * Soft StringFreeze
* Mitaka Release (April 7)


Based on these dates, the following are the deadlines for Cinder changes to be
merged:

* New backend drivers (Jan 19, 7:59 UTC)
* Spec/blueprint approval deadline (Jan 19, 7:59 UTC)
* New features and driver functionality (Mar 1, 7:50 UTC)
  * Note: changes that require client updates will need to be
  made available in enough time for both client and
  service changes to merge.

After the stated deadlines, it will be at the discretion of the Cinder core
team whether to allow any exceptions based on scope of work and perceived risk.

To increase the odds that your code will be accepted in Mitaka - do not wait
until close to the deadlines to submit your work. Code needs to be reviewed
and CI testing performed before it merges. This may take some time. Do not
expect that code submitted prior to the deadline means that it will be
accepted.

Note to new driver submitters:
All requirements stated here [2] and in related pages still apply. Even though
the deadline has been pushed out, all third party CI and code quality
requirements must still be met.

Sean (smcginnis)

[1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[2] https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

[Robert Collins]

Hi, at the summit we had a big session on distributed lock managers (DLMs).

I'd just like to highlight the conclusions we came to in the session (
https://etherpad.openstack.org/p/mitaka-cross-project-dlm
)

Firstly OpenStack projects that want to use a DLM can make it a hard
dependency. Previously we've had a unwritten policy that DLMs should
be optional, which has led to us writing poor DLM-like things backed
by databases :(. So this is a huge and important step forward in our
architecture.

As in our existing pattern of usage for database and message-queues,
we'll use an oslo abstraction layer: tooz. This doesn't preclude a
different answer in special cases - but they should be considered
special and exception, not the general case.

Based on the project requirements surfaced in the discussion, it seems
likely that all of konsul, etc and zookeeper will be able to have
suitable production ready drivers written for tooz. Specifically no
project required a fair locking implementation in the DLM.

After our experience with oslo.messaging however, we wanted to avoid
the situation of having unmaintained drivers and no signalling to
users about them.

So, we resolved to adopt roughly the oslo.messaging requirements for
drivers, with a couple of tweaks...

Production drivers in-tree will need:
 - two nominated developers responsible for it
 - gating functional tests that use dsvm
Test drivers in-tree will need:
 - clear identification that the driver is a test driver - in the
module name at minimum

All hail our new abstraction overlords.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Cross-Project meeting, Tue Nov 3rd, 21:00 UTC

[Mike Perez]

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting tomorrow at 21:00 UTC, with the
following agenda:

* Review past action items
* Team announcements (horizontal, vertical, diagonal)
* Design Summit feedback
* Proposed changes to the cross-project meeting, following the
cross-project workshop on it
* Open discussion

If you're from a horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, feel free to abuse the
relevant sections of that meeting and make sure it gets #info-ed by the
meetbot in the meeting summary.

See you there!

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] magnum on OpenStack Kilo

[Adrian Otto]

Bruce,

Another suggestion for your consideration:

The region the client is using needs to match the region the endpoint is set to 
use in the service catalog. Check that OS_REGION_NAME in the environment 
running the client is set to ‘RegionOne’ rather than ‘regionOne’. That has 
snagged others in the past as well.

Adrian

On Nov 2, 2015, at 4:22 PM, Adrian Otto 
mailto:adrian.o...@rackspace.com>> wrote:

Bruce,

That sounds like this bug to me:

https://bugs.launchpad.net/magnum/+bug/1411333

Resolved by:

https://review.openstack.org/148059

I think you need this:


keystone service-create --name=magnum \
--type=container \
--description="magnum Container Service"
keystone endpoint-create --service=magnum \
 --publicurl=http://127.0.0.1:9511/v1 \
 --internalurl=http://127.0.0.1:9511/v1 \
 --adminurl=http://127.0.0.1:9511/v1 \
 --region RegionOne

Any chance you missed the first of these two? Also, be sure you are using the 
latest Magnum, either from the master branch or from the Downloads section of:

https://wiki.openstack.org/wiki/Magnum

Thanks,

Adrain


On Nov 2, 2015, at 2:25 PM, Bruce D'Amora 
mailto:bddam...@gmail.com>> wrote:

Does anyone have any guidance for configuring magnum on OpenStack kilo? this is 
outside of devstack. I thought I had it configured and when I log into horizon, 
I see the magnum service is started, but when I execute cli commands such as:
magnum service-list or magnum container-list I get ERRORs:
ERROR: publicURL endpoint for container service not found

I added an endpoint:
openstack endpoint create \
  --publicurl http://9.2.132.246:9511/v1 \
  --internalurl http://9.2.132.246:9511/v1 \
  --adminurl http://9.2.132.246:9511/v1 \
  --region RegionOne \
  magnum

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] magnum on OpenStack Kilo

[Adrian Otto]

Bruce,

That sounds like this bug to me:

https://bugs.launchpad.net/magnum/+bug/1411333

Resolved by:

https://review.openstack.org/148059

I think you need this:


keystone service-create --name=magnum \
--type=container \
--description="magnum Container Service"
keystone endpoint-create --service=magnum \
 --publicurl=http://127.0.0.1:9511/v1 \
 --internalurl=http://127.0.0.1:9511/v1 \
 --adminurl=http://127.0.0.1:9511/v1 \
 --region RegionOne

Any chance you missed the first of these two? Also, be sure you are using the 
latest Magnum, either from the master branch or from the Downloads section of:

https://wiki.openstack.org/wiki/Magnum

Thanks,

Adrain


On Nov 2, 2015, at 2:25 PM, Bruce D'Amora 
mailto:bddam...@gmail.com>> wrote:

Does anyone have any guidance for configuring magnum on OpenStack kilo? this is 
outside of devstack. I thought I had it configured and when I log into horizon, 
I see the magnum service is started, but when I execute cli commands such as:
magnum service-list or magnum container-list I get ERRORs:
ERROR: publicURL endpoint for container service not found

I added an endpoint:
openstack endpoint create \
  --publicurl http://9.2.132.246:9511/v1 \
  --internalurl http://9.2.132.246:9511/v1 \
  --adminurl http://9.2.132.246:9511/v1 \
  --region RegionOne \
  magnum

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] DevStack errors...

[Thales]

I'm trying to get DevStack to work, but am getting errors.  Is this a good list 
to ask questions for this?  I can't seem to get answers anywhere I look.   I 
tried the openstack list, but it kind of moves slow.
Thanks for any help.
Regards, John__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [app-catalog] IRC Meeting Thursday November 5th at 17:00 UTC

[Christopher Aedo]

This is just a reminder announcement of the Community App Catalog
meeting we are planning for Thursday of this week at 17:00UTC.  It
will include a recap of the App Catalog related meetings from the
Tokyo Summit, as well as other status updates.

We are also working on setting up a second meeting time to make it
easier for folks in Asian time zones to participate via IRC.  Expect
more details on that shortly.

-Christopher


On Mon, Oct 19, 2015 at 10:41 AM, Christopher Aedo  wrote:
> Hello all!  Due to the summit we will cancel the next two weeks of IRC
> meetings for the App Catalog.
>
> The next meeting will be Thursday November 5th at 17:00UTC on
> #openstack-meeting-3
>
> The agenda can be found here:
> https://wiki.openstack.org/wiki/Meetings/app-catalog
>
> I expect we'll have a lot to talk about after Tokyo so expect some
> agenda items to be updated before the meeting.
>
> Hopefully I'll see most of you in Tokyo!
>
> -Christopher

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Steven Dake (stdake)]

From: Angus Salkeld mailto:asalk...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 4:18 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid 
cycle (action required from core reviewers)

On Tue, Nov 3, 2015 at 3:04 AM Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Hey folks,

We had an informal vote at the mid cycle from the core reviewers, and it was a 
majority vote, so we went ahead and started the process of the introduction of 
mesos orchestration into Kolla.

For background for our few core reviewers that couldn’t make it and the broader 
community, Angus Salkeld has committed himself and 3 other Mirantis engineers 
full time to investigate if Mesos could be used as an orchestration engine in 
place of Ansible.  We are NOT dropping our Ansible implementation in the short 
or long term.  Kolla will continue to lead with Ansible.  At some point in 
Mitaka or the N cycle we may move the ansible bits to a repository called 
“kolla-ansible” and the kolla repository would end up containing the containers 
only.

The general consensus was that if folks wanted to add additional orchestration 
systems for Kolla, they were free to do so if they did the development and made 
a commitment to maintaining one core reviewer team with broad expertise among 
the core reviewer team of how these various systems work.

Angus has agreed to the following

  1.  A new team called “kolla-mesos-core” with 2 members.  One of the members 
is Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie 
cutter empty repository.  This is typical of how new projects would operate, 
but we don’t want a code dump and instead want an integrated core team.  To 
prevent a situation which the current Ansible expertise shy away from the Mesos 
implementation, the core reviewer team has committed to reviewing the mesos 
code to get a feel for it.
  2.  Over the next 6-8 weeks these two folks will strive to join the Kolla 
core team by typical means 1) irc participation 2) code generation 3) effective 
and quality reviews 4) mailing list participation
  3.  Angus will create a technical specification which will we will roll-call 
voted and only accepted once a majority of core review team is satisfied with 
the solution.

I'll get stuck into this now.


  1.  The kolla-mesos deliverable will be under Kolla governance and be managed 
by the Kolla core reviewer team after the kolla-mesos-core team is deprecated.
  2.  If the experiment fails, kolla-mesos will be placed in the attic.  There 
is no specific window for the experiments, it is really up to Angus to decide 
if the technique is viable down the road.
  3.  For the purpose of voting, the kolla-mesos-core team won’t be permitted 
to vote (on things like this or other roll-call votes in the community) until 
they are “promoted” to the koala-core reviewer team.

The core reviewer team has agreed to the following

  1.  Review patches in kolla-mesos repository
  2.  Actively learn how the mesos orchestration system works in the context of 
Kolla
  3.  Actively support Angus’s effort in the existing Kolla code base as long 
as it is not harmful to the Kolla code base

We all believe this will lead to a better outcome then Mirantis developing some 
code on their own and later dumping it into the Kolla governance or operating 
as a fork.

Absolutely.


I’d like to give the core reviewers another chance to vote since the voting was 
semi-rushed.

I am +1 given the above constraints.  I think this will help Kolla grow and 
potentially provide a better (or arguably different) orchestration system and 
is worth the investigation.  At no time will we put the existing Kolla Ansible 
+ Docker goodness into harms way, so I see no harm in an independent repository 
especially if the core reviewer team strives to work as one team (rather then 
two independent teams with the same code base).

Abstaining is the same as voting as –1, so please vote one way or another with 
a couple line blob about your thoughts on the idea.

Note of the core reviewers there, we had 7 +1 votes (and we have a 9 individual 
core reviewer team so there is already a majority but I’d like to give everyone 
an opportunity weigh in).


Thanks for doing this Steve, we want to do this as much as possible in the open 
(we only have a very basic bits of PoC code, we will get stuck into getting 
this code up ASAP - and pushing it forward).

Blame the core team :)  I suspect you will end up retrying a lot of patterns we 
tried and failed with Kubernetes.  Kubernetes eventually was found to be 
non-viable by the delivery of this 2 week project:

https://github.com/sdake/compute-upgrade

Documented in this blog:

http://sdake.io/2015/01/28/an-atomic-upgrade

Re: [openstack-dev] [Kosmos] Meeting tomorrow

[Michael Johnson]

I will chair the meeting.  With Graham and Doug not available I
suspect it will be quick, but I want to have the meeting in case there
is followup from the summit.

Michael

On Mon, Nov 2, 2015 at 3:01 PM, Hayes, Graham  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi All,
>
> I will not be able to attend the meeting tomorrow, so unless
> Doug or Michael can chair, I would suggest postponing the meeting for
> a week.
>
> Thanks,
>
> Graham
>
> - --
> *Graham Hayes
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Steven Dake (stdake)]

Gosh,

Kubernetes as an underlay is an interesting idea.  We tried it for the first 6 
months of Kolla’s existence and it almost killed the project.  Essentially 
kubernetes lacks support for pid=host, net=host, and –v bind mounting.  All 3 
are required to deliver an operational OpenStack.

This is why current Kolla goes with a bare metal underlay – all docker options 
we need are available.

Regards
-steve


From: Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 3:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid 
cycle (action required from core reviewers)

Hi Steve,

Thank you for the update. This is really interesting direction for Kolla.
I agree with Jeff. It is interesting to see what other frameworks will be used. 
I suspect Marathon framework is under consideration as it adds most of the 
application centric functionality like HA\restarter, scaling and 
rolling-restarts\upgrades. Kubernetes might be also a good candidate for that.

Thanks
Gosha

On Mon, Nov 2, 2015 at 2:00 PM, Jeff Peeler 
mailto:jpee...@redhat.com>> wrote:
On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
> Hey folks,
>
> We had an informal vote at the mid cycle from the core reviewers, and it was
> a majority vote, so we went ahead and started the process of the
> introduction of mesos orchestration into Kolla.
>
> For background for our few core reviewers that couldn’t make it and the
> broader community, Angus Salkeld has committed himself and 3 other Mirantis
> engineers full time to investigate if Mesos could be used as an
> orchestration engine in place of Ansible.  We are NOT dropping our Ansible
> implementation in the short or long term.  Kolla will continue to lead with
> Ansible.  At some point in Mitaka or the N cycle we may move the ansible
> bits to a repository called “kolla-ansible” and the kolla repository would
> end up containing the containers only.
>
> The general consensus was that if folks wanted to add additional
> orchestration systems for Kolla, they were free to do so if they did the
> development and made a commitment to maintaining one core reviewer team with
> broad expertise among the core reviewer team of how these various systems
> work.
>
> Angus has agreed to the following
>
> A new team called “kolla-mesos-core” with 2 members.  One of the members is
> Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie
> cutter empty repository.  This is typical of how new projects would operate,
> but we don’t want a code dump and instead want an integrated core team.  To
> prevent a situation which the current Ansible expertise shy away from the
> Mesos implementation, the core reviewer team has committed to reviewing the
> mesos code to get a feel for it.
> Over the next 6-8 weeks these two folks will strive to join the Kolla core
> team by typical means 1) irc participation 2) code generation 3) effective
> and quality reviews 4) mailing list participation
> Angus will create a technical specification which will we will roll-call
> voted and only accepted once a majority of core review team is satisfied
> with the solution.
> The kolla-mesos deliverable will be under Kolla governance and be managed by
> the Kolla core reviewer team after the kolla-mesos-core team is deprecated.
> If the experiment fails, kolla-mesos will be placed in the attic.  There is
> no specific window for the experiments, it is really up to Angus to decide
> if the technique is viable down the road.
> For the purpose of voting, the kolla-mesos-core team won’t be permitted to
> vote (on things like this or other roll-call votes in the community) until
> they are “promoted” to the koala-core reviewer team.
>
>
> The core reviewer team has agreed to the following
>
> Review patches in kolla-mesos repository
> Actively learn how the mesos orchestration system works in the context of
> Kolla
> Actively support Angus’s effort in the existing Kolla code base as long as
> it is not harmful to the Kolla code base
>
> We all believe this will lead to a better outcome then Mirantis developing
> some code on their own and later dumping it into the Kolla governance or
> operating as a fork.
>
> I’d like to give the core reviewers another chance to vote since the voting
> was semi-rushed.
>
> I am +1 given the above constraints.  I think this will help Kolla grow and
> potentially provide a better (or arguably different) orchestration system
> and is worth the investigation.  At no time will we put the existing Kolla
> Ansible + Docker goodness into harms way, so I see no harm in an independent
> repository especially if the core reviewer team strives to work as one team
> (rather th

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Angus Salkeld]

On Tue, Nov 3, 2015 at 3:04 AM Steven Dake (stdake) 
wrote:

> Hey folks,
>
> We had an informal vote at the mid cycle from the core reviewers, and it
> was a majority vote, so we went ahead and started the process of the
> introduction of mesos orchestration into Kolla.
>
> For background for our few core reviewers that couldn’t make it and the
> broader community, Angus Salkeld has committed himself and 3 other Mirantis
> engineers full time to investigate if Mesos could be used as an
> orchestration engine in place of Ansible.  We are NOT dropping our
> Ansible implementation in the short or long term.  Kolla will continue to
> lead with Ansible.  At some point in Mitaka or the N cycle we may move the
> ansible bits to a repository called “kolla-ansible” and the kolla
> repository would end up containing the containers only.
>
> The general consensus was that if folks wanted to add additional
> orchestration systems for Kolla, they were free to do so if they did the
> development and made a commitment to maintaining one core reviewer team
> with broad expertise among the core reviewer team of how these various
> systems work.
>
> Angus has agreed to the following
>
>1. A new team called “kolla-mesos-core” with 2 members.  One of the
>members is Angus Salkeld, the other is selected by Angus Salkeld since this
>is a cookie cutter empty repository.  This is typical of how new projects
>would operate, but we don’t want a code dump and instead want an integrated
>core team.  To prevent a situation which the current Ansible expertise shy
>away from the Mesos implementation, the core reviewer team has committed to
>reviewing the mesos code to get a feel for it.
>2. Over the next 6-8 weeks these two folks will strive to join the
>Kolla core team by typical means 1) irc participation 2) code generation 3)
>effective and quality reviews 4) mailing list participation
>3. Angus will create a technical specification which will we will
>roll-call voted and only accepted once a majority of core review team is
>satisfied with the solution.
>
> I'll get stuck into this now.


>
>1. The kolla-mesos deliverable will be under Kolla governance and be
>managed by the Kolla core reviewer team after the kolla-mesos-core team is
>deprecated.
>2. If the experiment fails, kolla-mesos will be placed in the attic.
>There is no specific window for the experiments, it is really up to Angus
>to decide if the technique is viable down the road.
>3. For the purpose of voting, the kolla-mesos-core team won’t be
>permitted to vote (on things like this or other roll-call votes in the
>community) until they are “promoted” to the koala-core reviewer team.
>
>
> The core reviewer team has agreed to the following
>
>1. Review patches in kolla-mesos repository
>2. Actively learn how the mesos orchestration system works in the
>context of Kolla
>3. Actively support Angus’s effort in the existing Kolla code base as
>long as it is not harmful to the Kolla code base
>
> We all believe this will lead to a better outcome then Mirantis developing
> some code on their own and later dumping it into the Kolla governance or
> operating as a fork.
>

Absolutely.


>
> I’d like to give the core reviewers another chance to vote since the
> voting was semi-rushed.
>
> I am +1 given the above constraints.  I think this will help Kolla grow
> and potentially provide a better (or arguably different) orchestration
> system and is worth the investigation.  At no time will we put the existing
> Kolla Ansible + Docker goodness into harms way, so I see no harm in an
> independent repository especially if the core reviewer team strives to work
> as one team (rather then two independent teams with the same code base).
>
> Abstaining is the same as voting as –1, so please vote one way or another
> with a couple line blob about your thoughts on the idea.
>
> Note of the core reviewers there, we had 7 +1 votes (and we have a 9
> individual core reviewer team so there is already a majority but I’d like
> to give everyone an opportunity weigh in).
>
>
Thanks for doing this Steve, we want to do this as much as possible in the
open (we only have a very basic bits of PoC code, we will get stuck into
getting this code up ASAP - and pushing it forward).

Here is the review for the new repo:
 https://review.openstack.org/#/c/240433

Angus


> Regards
> -steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.or

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Geoff O'Callaghan]

I'm not a core dev but this is a fantastic idea which will have a huge
benefit to openstack.

Tks Geoff
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Summit recap

[Jason Rist]

On 11/02/2015 03:29 PM, Jim Rollenhagen wrote:
> Hi friends,
>
> I wrote a recap of the summit (from my perspective) that some of you may
> find interesting. Feedback is very welcome. :)
>
> http://words.jimrollenhagen.com/mitaka-summit-recap/
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
I can't tell you how much I appreciate this.  I wish every project did this, 
particularly Horizon.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kosmos] Meeting tomorrow

[Hayes, Graham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

I will not be able to attend the meeting tomorrow, so unless
Doug or Michael can chair, I would suggest postponing the meeting for
a week.

Thanks,

Graham

- -- 
*Graham Hayes


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Georgy Okrokvertskhov]

Hi Steve,

Thank you for the update. This is really interesting direction for Kolla.
I agree with Jeff. It is interesting to see what other frameworks will be
used. I suspect Marathon framework is under consideration as it adds most
of the application centric functionality like HA\restarter, scaling and
rolling-restarts\upgrades. Kubernetes might be also a good candidate for
that.

Thanks
Gosha

On Mon, Nov 2, 2015 at 2:00 PM, Jeff Peeler  wrote:

> On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake) 
> wrote:
> > Hey folks,
> >
> > We had an informal vote at the mid cycle from the core reviewers, and it
> was
> > a majority vote, so we went ahead and started the process of the
> > introduction of mesos orchestration into Kolla.
> >
> > For background for our few core reviewers that couldn’t make it and the
> > broader community, Angus Salkeld has committed himself and 3 other
> Mirantis
> > engineers full time to investigate if Mesos could be used as an
> > orchestration engine in place of Ansible.  We are NOT dropping our
> Ansible
> > implementation in the short or long term.  Kolla will continue to lead
> with
> > Ansible.  At some point in Mitaka or the N cycle we may move the ansible
> > bits to a repository called “kolla-ansible” and the kolla repository
> would
> > end up containing the containers only.
> >
> > The general consensus was that if folks wanted to add additional
> > orchestration systems for Kolla, they were free to do so if they did the
> > development and made a commitment to maintaining one core reviewer team
> with
> > broad expertise among the core reviewer team of how these various systems
> > work.
> >
> > Angus has agreed to the following
> >
> > A new team called “kolla-mesos-core” with 2 members.  One of the members
> is
> > Angus Salkeld, the other is selected by Angus Salkeld since this is a
> cookie
> > cutter empty repository.  This is typical of how new projects would
> operate,
> > but we don’t want a code dump and instead want an integrated core team.
> To
> > prevent a situation which the current Ansible expertise shy away from the
> > Mesos implementation, the core reviewer team has committed to reviewing
> the
> > mesos code to get a feel for it.
> > Over the next 6-8 weeks these two folks will strive to join the Kolla
> core
> > team by typical means 1) irc participation 2) code generation 3)
> effective
> > and quality reviews 4) mailing list participation
> > Angus will create a technical specification which will we will roll-call
> > voted and only accepted once a majority of core review team is satisfied
> > with the solution.
> > The kolla-mesos deliverable will be under Kolla governance and be
> managed by
> > the Kolla core reviewer team after the kolla-mesos-core team is
> deprecated.
> > If the experiment fails, kolla-mesos will be placed in the attic.  There
> is
> > no specific window for the experiments, it is really up to Angus to
> decide
> > if the technique is viable down the road.
> > For the purpose of voting, the kolla-mesos-core team won’t be permitted
> to
> > vote (on things like this or other roll-call votes in the community)
> until
> > they are “promoted” to the koala-core reviewer team.
> >
> >
> > The core reviewer team has agreed to the following
> >
> > Review patches in kolla-mesos repository
> > Actively learn how the mesos orchestration system works in the context of
> > Kolla
> > Actively support Angus’s effort in the existing Kolla code base as long
> as
> > it is not harmful to the Kolla code base
> >
> > We all believe this will lead to a better outcome then Mirantis
> developing
> > some code on their own and later dumping it into the Kolla governance or
> > operating as a fork.
> >
> > I’d like to give the core reviewers another chance to vote since the
> voting
> > was semi-rushed.
> >
> > I am +1 given the above constraints.  I think this will help Kolla grow
> and
> > potentially provide a better (or arguably different) orchestration system
> > and is worth the investigation.  At no time will we put the existing
> Kolla
> > Ansible + Docker goodness into harms way, so I see no harm in an
> independent
> > repository especially if the core reviewer team strives to work as one
> team
> > (rather then two independent teams with the same code base).
> >
> > Abstaining is the same as voting as –1, so please vote one way or another
> > with a couple line blob about your thoughts on the idea.
> >
> > Note of the core reviewers there, we had 7 +1 votes (and we have a 9
> > individual core reviewer team so there is already a majority but I’d
> like to
> > give everyone an opportunity weigh in).
>
> As one of the core reviewers who couldn't make the summit, this sounds
> like a very exciting direction to go in. I'd love to see more docs (I
> realize it's still early) on how mesos will be utilized and what
> additional frameworks may be used as well. Is kubernetes planned to be
> part of this mix since mesos works with it now?
>
> __

[openstack-dev] [ironic] Summit recap

[Jim Rollenhagen]

Hi friends,

I wrote a recap of the summit (from my perspective) that some of you may
find interesting. Feedback is very welcome. :)

http://words.jimrollenhagen.com/mitaka-summit-recap/

// jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] magnum on OpenStack Kilo

[Bruce D'Amora]

Hi,
Does anyone have any guidance for configuring magnum on OpenStack kilo? this is 
outside of devstack. I thought I had it configured and when I log into horizon, 
I see the magnum service is started, but when I execute cli commands such as:
magnum service-list or magnum container-list I get ERRORs:
ERROR: publicURL endpoint for container service not found

I added an endpoint:
openstack endpoint create \
  --publicurl http://9.2.132.246:9511/v1 \
  --internalurl http://9.2.132.246:9511/v1 \
  --adminurl http://9.2.132.246:9511/v1 \
  --region RegionOne \
  magnum


but still get an error. Any ideas?__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Jeff Peeler]

On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> We had an informal vote at the mid cycle from the core reviewers, and it was
> a majority vote, so we went ahead and started the process of the
> introduction of mesos orchestration into Kolla.
>
> For background for our few core reviewers that couldn’t make it and the
> broader community, Angus Salkeld has committed himself and 3 other Mirantis
> engineers full time to investigate if Mesos could be used as an
> orchestration engine in place of Ansible.  We are NOT dropping our Ansible
> implementation in the short or long term.  Kolla will continue to lead with
> Ansible.  At some point in Mitaka or the N cycle we may move the ansible
> bits to a repository called “kolla-ansible” and the kolla repository would
> end up containing the containers only.
>
> The general consensus was that if folks wanted to add additional
> orchestration systems for Kolla, they were free to do so if they did the
> development and made a commitment to maintaining one core reviewer team with
> broad expertise among the core reviewer team of how these various systems
> work.
>
> Angus has agreed to the following
>
> A new team called “kolla-mesos-core” with 2 members.  One of the members is
> Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie
> cutter empty repository.  This is typical of how new projects would operate,
> but we don’t want a code dump and instead want an integrated core team.  To
> prevent a situation which the current Ansible expertise shy away from the
> Mesos implementation, the core reviewer team has committed to reviewing the
> mesos code to get a feel for it.
> Over the next 6-8 weeks these two folks will strive to join the Kolla core
> team by typical means 1) irc participation 2) code generation 3) effective
> and quality reviews 4) mailing list participation
> Angus will create a technical specification which will we will roll-call
> voted and only accepted once a majority of core review team is satisfied
> with the solution.
> The kolla-mesos deliverable will be under Kolla governance and be managed by
> the Kolla core reviewer team after the kolla-mesos-core team is deprecated.
> If the experiment fails, kolla-mesos will be placed in the attic.  There is
> no specific window for the experiments, it is really up to Angus to decide
> if the technique is viable down the road.
> For the purpose of voting, the kolla-mesos-core team won’t be permitted to
> vote (on things like this or other roll-call votes in the community) until
> they are “promoted” to the koala-core reviewer team.
>
>
> The core reviewer team has agreed to the following
>
> Review patches in kolla-mesos repository
> Actively learn how the mesos orchestration system works in the context of
> Kolla
> Actively support Angus’s effort in the existing Kolla code base as long as
> it is not harmful to the Kolla code base
>
> We all believe this will lead to a better outcome then Mirantis developing
> some code on their own and later dumping it into the Kolla governance or
> operating as a fork.
>
> I’d like to give the core reviewers another chance to vote since the voting
> was semi-rushed.
>
> I am +1 given the above constraints.  I think this will help Kolla grow and
> potentially provide a better (or arguably different) orchestration system
> and is worth the investigation.  At no time will we put the existing Kolla
> Ansible + Docker goodness into harms way, so I see no harm in an independent
> repository especially if the core reviewer team strives to work as one team
> (rather then two independent teams with the same code base).
>
> Abstaining is the same as voting as –1, so please vote one way or another
> with a couple line blob about your thoughts on the idea.
>
> Note of the core reviewers there, we had 7 +1 votes (and we have a 9
> individual core reviewer team so there is already a majority but I’d like to
> give everyone an opportunity weigh in).

As one of the core reviewers who couldn't make the summit, this sounds
like a very exciting direction to go in. I'd love to see more docs (I
realize it's still early) on how mesos will be utilized and what
additional frameworks may be used as well. Is kubernetes planned to be
part of this mix since mesos works with it now?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Adam Young]

On 10/26/2015 02:38 PM, Major Hayden wrote:

Hello there,

I've been researching some additional ways to secure openstack-ansible 
deployments and I backed myself into a corner with secure log transport.  The 
rsyslog client requires a trusted CA certificate to be able to send encrypted 
logs to rsyslog servers.  That's not a problem if users bring their own 
certificates, but it does become a problem if we use the self-signed 
certificates that we're creating within the various roles.

I'm wondering if we could create a role that creates a CA on the deployment 
host and then uses that CA to issue certificates for various services *if* a 
user doesn't specify that they want to bring their own certificates.  We could 
build the CA very early in the installation process and then use it to sign 
certificates for each individual service.  That would allow to have some 
additional trust in environments where deployers don't choose to bring their 
own certificates.

Does this approach make sense?

--
Major Hayden

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


FreeIPA has a Dogtag server that can be your full CA.  I would recommend 
not rolling our own.


We have a playbook that does this here: 
https://github.com/admiyo/rippowam  specifically in the 
https://github.com/admiyo/rippowam/tree/master/roles/ipaserver  role


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Sheena Gregson]

This seems like a reasonable approach.  As mentioned earlier in the thread,
our current framework allows plugins to declare which components they could
not work with, so we already have information about “incompatibility” for a
number of plugins.  The issue with this approach is that, as new plugins
are added to an existing release, the previously published plugins cannot
show that they are either (1) incompatible or (2) untested.



The proposed approach solves this problem.  Adding compatibility gives more
clarity to the users about known good combinations, and creating a gray
area for untested component combinations helps expose areas where we
haven’t done thorough testing and there may be issues, and users should
proceed with guidance/support.



*From:* Vitaly Kramskikh [mailto:vkramsk...@mirantis.com]
*Sent:* Monday, November 02, 2015 8:38 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins][UX] Component registry



Hi,

I think having both compatibility and incompatibility lists is a good idea.
I think we need just to show a warning if users pick options which are not
in compatibility list and disable options which are in incompatibility
list. We also need to be able to provide a message in case of
incompatibility: the current implementation of the wizard supports custom
messages in the wizard config and they are quite useful.



2015-11-02 16:16 GMT+07:00 Evgeniy L :

Hi,



The main reason why I think we should get all of the three states is we

don't know exactly if those plugins (which developer didn't specify) are

compatible or not, so we should not make any assumptions and prevent

the user from enabling any plugins she/he wants. The best we can do here

is to provide all of the information plugin developer knows, directly to
the user,

without us in the middle who make decisions based on incomplete data.



So lets ask plugin developer to specify a set of components which he tested

his plugin with. Plus a list of components which he tested with and he is
sure

that those are not going to working together.



On UI we can show explicitly, that this combination is tested and approved
to

be working, another combination is not working for sure (plugin developers
tested

it and explicitly specified), and there will be a lot of combination which
are going

to work together without problems, but we should say the user, that the
developer

didn't test it and he should test and use it carefully.



Thanks,



On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
wrote:

Hi fuelers,

Currently we are working on feature component registry [1] which should
help us to prevent not logical compositions of different components in
wizard tab during cluster(environment) creation. Now we have a mechanizm
of 'restrictions' which is not flexible for components provided by
plugins. In our current approach we have two states for components -
compatible/incompatible which are described in compatibility matrix
based on OpenStack components (For example: cinder-vmware storage only
compatible with vCetner hypervisor and should work when only KVM uses).
In this case we allow user to choose only that components we defently
know works well with each other. Another approach tell us to have 3
states: compatible/incompatible/ and all other components about
compatibility with others we know nothing. In that case we should show
on wizard which components compatible, which not, and others which user
can enable on his own risk. So I need your opinions: should we allow for
user choose only that coponents which are tested and defently works or
prevent her/him from choosing which are defently not works and means
potentional risk of failing deployment when component about we know
nothing isn't work together.



[1] https://blueprints.launchpad.net/fuel/+spec/component-registry

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project] Admin

[Adam Young]

On 10/24/2015 12:46 AM, Clint Byrum wrote:

Can I ask one thing though, can we use a domain name + project_name_
and not the ID?

I think we can do that.  The submitted patch for the overall spec is here:

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

and the change for Keystone is here:

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

Both of these are WIP.  Please post your changed request on the review.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking to contribute

[Adam Young]

On 11/02/2015 02:06 PM, Lisa Jenkins wrote:


Hi new dev looking to contribute and am open to anything.  Which 
projects need resources and have some low level bugs or something 
similar for a newbie to get started?


Thanks,

Lisa



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Lisa,

Welcome aboard.  There are many, many related projects, and all have a 
place for new developers.  I would ask you to consider what you really 
find interesting about cloud and make a focused investigation to that 
particular project:


https://wiki.openstack.org/wiki/Project_Teams

I personally work almost exclusively on Keystone, which tends to draw 
people either interested in Security or in integration with existing 
user databases.  Neutron for Networking, Nova for Compute. Swift, 
Cinder, Trove, Glance, and Sahara all have an aspect of Storage.  And 
there are many more.


So;  what are you interested in learning about today?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Ryan Brown]

On 11/02/2015 02:22 PM, Sean M. Collins wrote:

On Mon, Nov 02, 2015 at 03:19:42AM EST, Daniel Mellado wrote:

Also you could set up this var

LOGDAYS=1

to limit the amount of log, althougt setting the LOGDIR to /dev/null
should work too.


That is only useful if you are doing a new run of stack.sh - it won't
handle the issue of the log file growing in size.

I mean I guess the real answer is to configure logrotate. ugh.


Alternatively, you can set up a cronjob to do this:

du -sh LOGDIR | cut -f1 | grep -q G && \
 find LOGDIR -type f -exec truncate --size 0 \;

That'll cut all the logfiles down to size when the total size of your 
log directory exceeds 1 GB. I have it set to run every 3 hours on my vms.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Cody Herriges]

Sofer Athlan-Guyot wrote:
> Hi,
> 
> The idea would be to have some of the types defined oslo config
> http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types.py
> ported to puppet type.  Those that looks like good candidates are:
>  - Boolean;
>  - IPAddress;
> and in a lesser extend:
>  - Integer;
>  - Float;
> 
> For instance in puppet type requiring a Boolean, we may test
> "/[tT]rue|[fF]alse/", but the real thing is :
> 
> TRUE_VALUES = ['true', '1', 'on', 'yes']
> FALSE_VALUES = ['false', '0', 'off', 'no']
> 

Good idea.  I'd only add that we should convert 'true' and 'false' to
real booleans for Puppet's purposes since the Puppet language is now typed.

-- 
Cody



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Infra] Meeting Tuesday November 3rd at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday November 3rd, at 19:00 UTC in #openstack-meeting

US attendees: Remember that daylight savings time has ended :)

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last couple of meetings are available:

Oct 13:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-13-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-13-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-13-19.01.log.html

Oct 20:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-20-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-20-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-10-20-19.02.log.html

Additionally, last week we skipped our meeting and met at the
OpenStack Design Summit. Etherpads from our sessions are found here:
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Infrastructure

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] tasks (following "proposed priorities for Mitaka")

[Jay Pipes]

On 09/14/2015 02:41 PM, Monty Taylor wrote:

On 09/14/2015 04:58 PM, Brian Rosmaita wrote:

I'm not saying that there's no other way to do this -- e.g., you could do
all sorts of alternative workflows and configurations in the "regular"
upload process -- but the feedback I got can be summarized like this:
Given the importance of a properly-functioning Glance for normal cloud
operations, it is useful to have one upload/download workflow that is
locked down and you don't have to worry about, and a completely different
workflow that you can expose to end users and tinker with as necessary.


IMHO - a cloud that does not allow me to upload images is not a usable
cloud.

A cloud that requires me to upload images differently than another cloud
is a hardship on the users.

A cloud that makes the user know the image format of the cloud is a
hardship on the users, especially when there exist nowhere in any
existing distro tools that can actually produce the image format in
question. (yup, Im just going to sneak that one in there)

NOW - I think that the task api and the image conversion tools itself if
it's a behind the scenes kind of thing is potentially nice thing.

If "glance import-from http://example.com/my-image.qcow2' always worked,
and in the back end generated a task with the task workflow, and one of
the task workflows that a deployer could implement was one to do
conversions to the image format of the cloud provider's choice, that
would be teh-awesome. It's still a bit annoying to me that I, as a user,
need to come up with a place to put the image so that it can be
imported, but honestly, I'll take it. It's not _that_ hard of a problem.


I predicted the above problems with the tasks API as it was designed way 
back in 2013 and urged it be redesigned:


http://lists.openstack.org/pipermail/openstack-dev/2013-May/009400.html
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html

with a followup here:

http://lists.openstack.org/pipermail/openstack-dev/2013-November/019028.html

where I actually agreed with George Reese about something...

Guess I should have been more vocal.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [inspector] [neutron] DHCP Options on Neutron networks

[Kevin Benton]

This has come up before.
https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet

Can you file an RFE (request for enhancement) bug so we can discuss it in
the Neutron drivers meeting to see if it fits in with the plans this cycle?

On Mon, Nov 2, 2015 at 10:16 AM, Sam Betts (sambetts) 
wrote:

> For the ironic inspector to be able to inspect nodes that we don't know the
>
> mac addresses for we have to run a DHCP rule that will respond to all mac
>
> addresses for PXE booting the inspector ramdisk. In order to provide this
>
> functionality right now we are running our own instance of dnsmasq,
>
> configuring it independently and manually plumbing it into OpenStack. At
> the
>
> summit we discussed that we would like to move away from managing our own
> DHCP
>
> server and would like to take advantage of the existing DHCP server
> implemented
>
> by neutron. However this would require being able to set global/wildcard
> DHCP
>
> rules in neutron which I'm aware isn't possible right now, as DHCP options
> are
>
> only set on ports.
>
>
> A solution that we came up with would be the ability to set DHCP options
> on a
>
> neutron network which would apply to *any* machine that made a DHCP
> request in
>
> that network, however if any DHCP options were set on a port they would
>
> override the network level options. This way we could setup a PXE option at
>
> the network level for PXE booting any machine in that network that
> requests it.
>
>
> We'd like to get some opinions on this idea from the neutron team, we think
>
> that if implemented correctly there could be uses for it outside of the
>
> inspector use case. We look forward to any feedback.
>
>
> Sam (sambetts)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking to contribute

[Shamail]

Hi Lisa,

You can start looking at bugs with the low-hanging-fruit[1] tag as they are 
meant to be relatively easy bugs to help new contributors get used to the 
contribution workflow for OpenStack projects.

You might also want to review the how to contribute[2] page for tips on setting 
up your environment and IDs.  

Once you have done a few of these... you can find projects of interest and 
start attending their IRC meetings to identify future contributions that align 
with your interests.

All the best!

Thanks,
Shamail 


[1] https://bugs.launchpad.net/openstack/+bugs?field.tag=low-hanging-fruit
[2] https://wiki.openstack.org/wiki/How_To_Contribute


> On Nov 2, 2015, at 2:06 PM, Lisa Jenkins  wrote:
> 
> Hi new dev looking to contribute and am open to anything.  Which projects 
> need resources and have some low level bugs or something similar for a newbie 
> to get started?
> 
> Thanks,
> 
> Lisa
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Sean M. Collins]

On Mon, Nov 02, 2015 at 03:19:42AM EST, Daniel Mellado wrote:
> Also you could set up this var
> 
> LOGDAYS=1
> 
> to limit the amount of log, althougt setting the LOGDIR to /dev/null
> should work too.

That is only useful if you are doing a new run of stack.sh - it won't
handle the issue of the log file growing in size.

I mean I guess the real answer is to configure logrotate. ugh.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking to contribute

[Anita Kuno]

On 11/02/2015 02:06 PM, Lisa Jenkins wrote:
> Hi new dev looking to contribute and am open to anything.  Which projects
> need resources and have some low level bugs or something similar for a
> newbie to get started?
> 
> Thanks,
> 
> Lisa
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Hi Lisa:

Welcome and thanks for getting in touch.

Actually you ask a kind of difficult question as we have many many
projects and all of them are looking for new contributors.

A couple ways to go from here:

1) you can join the #openstack-dev channel on freenode and meet some
folks there

2) you can read some logs of the channels and meetings and see if
something suits you and join that channel:
http://eavesdrop.openstack.org/irclogs/

3) you can share some additional details about what motivates you to
contribute to openstack, what your personal goals are, if you have any
past experience with a specific language or technology and what you
would like to work on

Thanks Lisa, I hope you find something you like,
Anita (anteaya on irc)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Sean M. Collins]

On Mon, Nov 02, 2015 at 10:43:45AM EST, Davanum Srinivas wrote:
> Sean,
> 
> ah. so the tip about LOGDIR to /dev/null may work for you
> 

That's not going to work. LOGDIR is used in multiple mkdir calls.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] operator_roles in puppet-swift?

[Cody Herriges]

Matt Fischer wrote:
> I'd like to get some clarification and hopefully correction on the
> values for the two operator_roles variables. One is
> in manifests/keystone/auth.pp, and it claims "Array of strings. List of
> roles Swift considers as admin.". The other is
> in manifests/proxy/keystone.pp and it claims to be "a list of keystone
> roles a user must have to gain access to Swift.".  "gain access to" does
> not imply admin to me, it implies basic features won't work, but I'm not
> sure that's really what it means.
> 
> So are these in fact separate concepts? What I read is that despite them
> having the same name, one is for admins, and one is needed to use swift
> at all. However, since they both default to ["admin", "SwiftOperator"],
> I don't really think that's true.
> 
> Can someone clarify and then fix the comments or code?
> 

Best I can tell from the Swift docs, they are the same.  One creates
roles in Keystone and the other tells Swift which roles are important by
actually putting them in a config file.


-- 
Cody



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Multi-ip use cases

[Shraddha Pandhe]

Hi folks,

James Penick from Yahoo! presented a talk on Thursday about how Yahoo uses
Neutron for Ironic. I would like to follow up on one particular use case
that was discussed: Multi-IP support.

Here's our use-case for Multi-ip:

For Ironic, we want user to specify the number of IPs on boot. Now, we want
scheduler to find a network with sufficient IPs and then pick a host in
that subnet (Note: static IPs for baremetal). Now, when allocating network,
we want to assign all requested IPs from the same subnet as the host's
static IP. Also, we don't want to configure those IPs on the host. We only
want to display them on "nova show".

So basically we will only create one port for the host, and append all
fixed_ips in the ports fixed_ip list field.

Questions:
1. Hows do most people use the fixed_ips field in the port? What are
different ways you can populate multiple IPs in fixed_ips? One way I know
is, using neutron-client to create port, you can specify --fixed-ip as many
times as you want, and that will append fixed_ips to the port. Any other
way?

2. Is anybody else using multi-ip?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Looking to contribute

[Lisa Jenkins]

Hi new dev looking to contribute and am open to anything.  Which projects
need resources and have some low level bugs or something similar for a
newbie to get started?

Thanks,

Lisa
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next week

[Ryan Moats]

Ditto Ryan (regXboi) Moats

Carl Baldwin  wrote on 11/02/2015 11:47:27 AM:

> From: Carl Baldwin 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 11/02/2015 11:48 AM
> Subject: Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next
week
>
> Thanks, Brian.  I'm planning to be there.
>
> Carl
>
> On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley 
wrote:
> > A few of us had a discussion this week at Summit and decided to
re-start the
> > weekly Neutron Distributed Virtual Router (DVR) meeting.  The goal is
to
> > help:
> >
> > - Stabilize DVR - fix the bugs
> > - Address performance/scalability issues
> > - Get the DVR jobs voting again
> >
> > Meetings will be on Wednesdays starting next week at 15:00 UTC.  I'm in
the
> > process of updating
> >
http://eavesdrop.openstack.org/#Neutron_Distributed_Virtual_Router_Meeting
> > with a link to the meeting page and agenda, which is currently at
> > https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
> >
> > -Brian
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum]generate config files by magnum

[Egor Guz]

Steve,actually Kub is moving to fully containerize model when you need only 
kublet running at the host 
(https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html) 
and all other services will come in containers (e.g. ui 
http://kubernetes.io/v1.0/docs/user-guide/ui.html). So we will have only etcd, 
flannel, kublet preinstalled and kublet will start all necessary containers 
(e.g. https://review.openstack.org/#/c/240818/).

Wanghua, we discussed concerns about curent Fedora Atomic images during the 
summit and there are some actions points:
1. Fix CoreOS template. I started working at it, but it will take some time 
because we need to coordinate it with template refactoring 
(https://review.openstack.org/#/c/211771/)
2. Try to minimize Fedora Atomic image (Ton, will take a look at it)
3. Build Ubuntu image/template (I or Ton will pickup it, feel free to join ;))

―
Egor

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 06:37
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum]generate config files by magnum

The reason we don’t rely on cloudint more then we already do (sed is run via 
cloudiit) is because many modern distress like CentOS and Fedora Atomic have 
many parts of the host os as read-only.

I prefer the structure as it is.

Regards
-steve


From: 王华 mailto:wanghua.hum...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 12:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [magnum]generate config files by magnum

Hi forks,

Magnum needs to prepare config files for k8s and docker and add these services 
to systemd. Now we use "sed" to replace some parameters in config files. The 
method has a disadvantage. Magnum code  depends on a specific image. Users may 
want to create images by themselves. The config files in their images may be 
different from ours. I think magnum shouldn't depends on the config files in 
the image. These config files should be generated by magnum. What magnum needs 
should be just the installation of k8s, docker, etc. Maybe we can use 
cloud-init to install the softwares automatically, so that we don't need to 
create images and what we needs is just a image with cloud-init.

Regards,
Wang Hua
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

[Brant Knudson]

On Mon, Nov 2, 2015 at 12:22 PM, Cyril Roelandt  wrote:

> Hello,
>
> The libraries from the Oslo project are used everywhere in OpenStack,
> which means that a security issue in Olso code might have an impact on a
> lot of other projects. This is why I am currently trying to add support
> for the bandit[1] static checker in all of the Oslo libraries.
>
> While reviewing one of my patches[2], Victor Stinner noticed that the
> bandit configuration file (bandit.yaml) I proposed, which is basically a
> copy of the example config file[3] provided by the bandit project with
> some minor changes, might be a bit hard to maintain across all Oslo
> projects. Indeed, all configuration files could potentially have to be
> changed whenever a new checker is added to bandit, for instance.
>
> In order to make it easier to keep an up-to-date configuration file, I
> quickly wrote a proof of concept[4] that allows developers to generate a
> configuration file that fits their needs. One can now generate a working
> bandit.yaml configuration file by typing something like:
>
> $ bandit-conf-generator --disable try_except_pass --out bandit.yaml
> oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml
>
> Whenever a new version of bandit comes out, one can grab the latest
> config file example from the bandit release, and re-run the above
> command. The generated config file will include all the new checkers.
>
> What do you think? Could this be a useful tool to handle bandit
> configurations?
>
>
We could use something like this in keystone since we've got a few
repositories. There should be a way to document why the test was skipped
since otherwise we'll have to figure it out every time we update the file.
Putting a comment on the command line would wind up being unwieldy, so we
should have a config file for bandit-conf-generator... but then why not
just have bandit know how to read the bandit-conf-generator config file and
skip the extra step?

- Brant


> Cyril Roelandt.
> ---
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
> [2] https://review.openstack.org/#/c/239666/
> [3]
> https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml
> [4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

[Sean M. Collins]

On Mon, Nov 02, 2015 at 02:39:49AM EST, Oğuz Yarımtepe wrote:
> All i need is to create a firewall but instead of
> using Iptables, i want to use the hardware firewall and be able to define
> filtering rules.

In the current experimental API, Firewalls are
global in scope and cover an entire tenant. There *is* an API extension
(router insertion) that can associate a firewall with a specific tenant
Neutron router, however not every vendor supports it.

You mentioned that your firewall appliance does not route, it just
filters. Depending on how you are routing, and if you are going to
support the router insertion API extension, it could be that your
firewall appliance may not be able to filter all traffic. Unless that
is, you put the firewall appliance in, as a bump in the wire.

Really this all boils down to the point where the Firewall as a Service
API does not have good semantics for where a firewall is inserted, in
all cases. Even with the router insertion API extension, there are cases
where it doesn't cover - like DVR[1].

Currently the FwaaS community is attempting to fix this, by just having
the API express *what* ports a tenant wishes to associate with a
firewall policy, and let the implementation figure out how best to plumb
it, and where to insert filtering rules.

This means that the API will change semantics significantly, and just
inserting a hardware device at the edge would not cover all that the
newer Firewall API will be able to express.

[1]: https://etherpad.openstack.org/p/FWaaS_with_DVR

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

[Davanum Srinivas]

Cyril,

If we can add this command directly in our tox.ini and entirely avoid
having the bandit.yaml would that be even better?

-- Dims

On Mon, Nov 2, 2015 at 1:22 PM, Cyril Roelandt  wrote:

> Hello,
>
> The libraries from the Oslo project are used everywhere in OpenStack,
> which means that a security issue in Olso code might have an impact on a
> lot of other projects. This is why I am currently trying to add support
> for the bandit[1] static checker in all of the Oslo libraries.
>
> While reviewing one of my patches[2], Victor Stinner noticed that the
> bandit configuration file (bandit.yaml) I proposed, which is basically a
> copy of the example config file[3] provided by the bandit project with
> some minor changes, might be a bit hard to maintain across all Oslo
> projects. Indeed, all configuration files could potentially have to be
> changed whenever a new checker is added to bandit, for instance.
>
> In order to make it easier to keep an up-to-date configuration file, I
> quickly wrote a proof of concept[4] that allows developers to generate a
> configuration file that fits their needs. One can now generate a working
> bandit.yaml configuration file by typing something like:
>
> $ bandit-conf-generator --disable try_except_pass --out bandit.yaml
> oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml
>
> Whenever a new version of bandit comes out, one can grab the latest
> config file example from the bandit release, and re-run the above
> command. The generated config file will include all the new checkers.
>
> What do you think? Could this be a useful tool to handle bandit
> configurations?
>
>
> Cyril Roelandt.
> ---
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
> [2] https://review.openstack.org/#/c/239666/
> [3]
> https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml
> [4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][bandit] Handling bandit configuration files in Oslo.

[Cyril Roelandt]

Hello,

The libraries from the Oslo project are used everywhere in OpenStack, 
which means that a security issue in Olso code might have an impact on a
lot of other projects. This is why I am currently trying to add support 
for the bandit[1] static checker in all of the Oslo libraries.


While reviewing one of my patches[2], Victor Stinner noticed that the 
bandit configuration file (bandit.yaml) I proposed, which is basically a

copy of the example config file[3] provided by the bandit project with
some minor changes, might be a bit hard to maintain across all Oslo 
projects. Indeed, all configuration files could potentially have to be

changed whenever a new checker is added to bandit, for instance.

In order to make it easier to keep an up-to-date configuration file, I
quickly wrote a proof of concept[4] that allows developers to generate a
configuration file that fits their needs. One can now generate a working
bandit.yaml configuration file by typing something like:

$ bandit-conf-generator --disable try_except_pass --out bandit.yaml 
oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml


Whenever a new version of bandit comes out, one can grab the latest
config file example from the bandit release, and re-run the above
command. The generated config file will include all the new checkers.

What do you think? Could this be a useful tool to handle bandit
configurations?


Cyril Roelandt.
---

[1] https://wiki.openstack.org/wiki/Security/Projects/Bandit
[2] https://review.openstack.org/#/c/239666/
[3] 
https://github.com/openstack/bandit/blob/master/bandit/config/bandit.yaml

[4] https://github.com/CyrilRoelandteNovance/bandit_conf_generator

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Matthew Thode]

On 11/02/2015 08:11 AM, Jesse Pretorius wrote:
> On 29 October 2015 at 12:43, Major Hayden  wrote:
> 
>> On 10/29/2015 04:33 AM, McPeak, Travis wrote:
>>> The only potential security drawback is that we are introducing a new
>>> asset to protect.  If we create the tools that enable a deployer to
>>> easily create and administer a lightweight CA, that should add
>>> significant value to OpenStack, especially for smaller organizations
>>> that don't have experience running a CA.
>>
>> This is certainly true.  However, I'd like to solve for the use of
>> self-signed SSL certificates in openstack-ansible first.
>>
>> At the moment, each self-signed certificate for various services is
>> generated within each role.  The goal would be to make a CA at the
>> beginning and then allow roles to utilize another role/task to issue
>> certificates from that CA.  The CA would most likely be located on the
>> deployment host.
>>
>> Deployers who are very security conscious can provide keys, certificates,
>> and CA certificates in the deployment configuration and those will be used
>> instead of generating self-signed certificates.
>>
> 
> I would argue that self-signed certificates only provide an illusion of
> security and the tasks we have to generate and distribute them should be
> removed entirely. My thinking is that if a deployer wants to use
> self-signed certs, then the deployer can create them and provide their
> details as user-provided certs. That way we can do without a whole block of
> code and the dependency on memcache for distribution. This makes the
> decision to use the self-signed certs a more deliberate one and also takes
> care of the complexity of certificate distribution.
> 
> That said, I applaud the idea of using a CA role. There are a few in
> Ansible Galaxy, but I've found their implementations to be rather complex
> whereas I think they can be pretty simple. I have actually done a fair
> amount of work on the CA setup part of things in my not-yet-complete
> ansible-openvas role [1]. You are welcome to use this work as a starting
> base and develop a role which sets up a CA. The trouble I found when
> looking into how to do this properly was that there should be several CA's
> (one offline primary and more than one secondary which actually does the
> signing). This will mean that the role will require quite a bit of guidance
> for using it correctly and setting up a single CA or multi-CA environment.
> 
> Whether you develop a new role for the OpenStack-Ansible toolbox, or
> develop documentation for consuming an existing role in Ansible Galaxy, the
> concept is certainly welcome and would go a long way to simplifying a
> secure-by-default implementation of OpenStack.
> 
> [1]
> https://github.com/odyssey4me/ansible-openvas/blob/master/tasks/install_openssl_ca.yml
> 
> ---
> Jesse
> IRC: odyssey4me
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
I think doing a self signed CA can work fine, especially if the private
details are kept on the deployment host.  The specific scenario I
envision is that you provide a subca / key / passphrase to ansible and
ansible uses that info to generate certs/keys for distribution.  This is
similar to puppet's external CA setup I think.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next week

[Carl Baldwin]

Thanks, Brian.  I'm planning to be there.

Carl

On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley  wrote:
> A few of us had a discussion this week at Summit and decided to re-start the
> weekly Neutron Distributed Virtual Router (DVR) meeting.  The goal is to
> help:
>
> - Stabilize DVR - fix the bugs
> - Address performance/scalability issues
> - Get the DVR jobs voting again
>
> Meetings will be on Wednesdays starting next week at 15:00 UTC.  I'm in the
> process of updating
> http://eavesdrop.openstack.org/#Neutron_Distributed_Virtual_Router_Meeting
> with a link to the meeting page and agenda, which is currently at
> https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
>
> -Brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Learning to Debug the Gate

[Anita Kuno]

On 10/29/2015 10:42 PM, Anita Kuno wrote:
> On 10/29/2015 08:27 AM, Anita Kuno wrote:
>> On 10/28/2015 12:14 AM, Matt Riedemann wrote:
>>>
>>>
>>> On 10/27/2015 4:08 AM, Anita Kuno wrote:
 Learning how to debug the gate was identified as a theme at the
 "Establish Key Themes for the Mitaka Cycle" cross-project session:
 https://etherpad.openstack.org/p/mitaka-crossproject-themes

 I agreed to take on this item and facilitate the process.

 Part one of the conversation includes referencing this video created by
 Sean Dague and Dan Smith:
 https://www.youtube.com/watch?v=fowBDdLGBlU

 Please consume this as you are able.

 Other suggestions for how to build on this resource were mentioned and
 will be coming in the future but this was an easy, actionable first step.

 Thank you,
 Anita.

 __

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/tales-from-the-gate-how-debugging-the-gate-helps-your-enterprise
>>>
>>>
>>
>> The source for the definition of "the gate":
>> http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n34
>>
>> Thanks for following along,
>> Anita.
>>
> 
> This is the status page showing the status of our running jobs,
> including patches in the gate pipeline: http://status.openstack.org/zuul/
> 
> Thank you,
> Anita.
> 

This is a simulation of how the gate tests patches:
http://docs.openstack.org/infra/publications/zuul/#%2818%29

Click in the browser window to advance the simulation.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] [inspector] [neutron] DHCP Options on Neutron networks

[Sam Betts (sambetts)]

For the ironic inspector to be able to inspect nodes that we don't know the

mac addresses for we have to run a DHCP rule that will respond to all mac

addresses for PXE booting the inspector ramdisk. In order to provide this

functionality right now we are running our own instance of dnsmasq,

configuring it independently and manually plumbing it into OpenStack. At the

summit we discussed that we would like to move away from managing our own DHCP

server and would like to take advantage of the existing DHCP server implemented

by neutron. However this would require being able to set global/wildcard DHCP

rules in neutron which I'm aware isn't possible right now, as DHCP options are

only set on ports.


A solution that we came up with would be the ability to set DHCP options on a

neutron network which would apply to any machine that made a DHCP request in

that network, however if any DHCP options were set on a port they would

override the network level options. This way we could setup a PXE option at

the network level for PXE booting any machine in that network that requests it.


We'd like to get some opinions on this idea from the neutron team, we think

that if implemented correctly there could be uses for it outside of the

inspector use case. We look forward to any feedback.


Sam (sambetts)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] Team meeting minutes - 11/02/2015

[Renat Akhmerov]

Thanks for joining our team meeting today!

In case you missed it or just want to catch up with Mistral activities here’s 
the meeting minutes and and full log.

Minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-02-16.00.html
 

Log: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-02-16.00.log.html
 


The next meeting will be on Nov 9.

Renat Akhmerov
@ Mirantis Inc.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Change VIP address via API

[Igor Kalnitsky]

Hey Aleksey,

I agree that we need a separate API call for VIP allocation, thought I
don't agree on some points you have proposed. See my comments below.

> use PUT to change VIPs addresses (set them manually or request
> to allocate them automatically)

PUT requests SHOULD NOT be used for VIP allocation, by RESTful API
notation the PUT request should be used for changing (editing)
entities, not for creating new ones. For VIP allocation we should use
POST request. It's ok to use PUT for setting (changing) IP address.

> vips: [
> {
> 'network_role': 'management',
> 'namespace': 'haproxy',
> 'ipaddr': '10.10.10.10',
> 'node_roles': ['controller']
> },...
> ]

There I have two comments:

* We don't need the "vips" word in API output - let's return a JSON
list with VIPs and that's it.
* We don't store network_role, namespace and node_roles within VIPs.
They are belonged to network roles. So how are you going to retrieve
them? Did you plan to make some changes to our data model? You know,
it's not a good idea to make connections between network roles and
VIPs each time your make a GET request to list them.

> When it is set to None, IP address will be allocated automatically

We definitely should handle `null` this way, but I think from API POV
it would be more clearer just do not pass `ipaddr` value if user wants
it to be auto allocated. I mean, let's keep `null` as implementation
details ans force API users just do not pass this key if they don't
want to.

> When the user runs GET request for the first time, all 'ipaddr'
> fields are equal to None.

Should we return VIPs that aren't allocated, and if so - why? If they
would be just, you know, fetched from network roles - that's a bad
design. Each VIP should have an explicit entry in VIPs database table.

> There is a question, what to do when the given address overlaps
> with the network from another environment? My opinion that those
> should pass with a warning message.

The thing is that there's no way to *warn* users through API. You
could either reject or accept request. So all we can do is to
introduce some `force` flag, and if it's passed - ignore overlapping.

I didn't get what do you mean by:

> overlaps with the network of current environment which does not
> match the network role of the VIP?

Could you please explain?

Thanks,
Igor

P.S: I see this API call somehow this way http://xsnippet.org/361113/raw/

On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin  wrote:
> Hi folks,
>
> I'm working on the following story [1][2]:
> API must allow VIP to be manually set to ANY valid IP address. If the IP on
> update API is a member of any network in this environment then the address
> should be put in the assignments table so that it can not be used in any
> other
> automatic assignment. (This allows the user to override if the automatic
> allocation doesn't match their needs or in the case that they want to use
> external LB).
>
> [1] https://bugs.launchpad.net/fuel/+bug/1482399
> [2] https://review.openstack.org/230943
>
> So, I have the following proposal for now:
> Add new url (e.g. /clusters//network_configuration/vips/ ), use
> GET
> to query current VIPs info, use PUT to change VIPs addresses (set them
> manually
> or request to allocate them automatically).
> Now VIPs have the following format in API requests data:
> vips: [
> {
> 'network_role': 'management',
> 'namespace': 'haproxy',
> 'ipaddr': '10.10.10.10',
> 'node_roles': ['controller']
> },...
> ]
> So, 'ipaddr' field can be set to any (almost any) user-defined value or to
> None (null in YAML).
> When it is set to None, IP address will be allocated automatically. When the
> user runs GET
> request for the first time, all 'ipaddr' fields are equal to None. So, user
> can set some (or all)
> of them to desired values and run PUT. When the GET is run after PUT, all
> addresses will be
> filled with values. User can reset some of them to None or change to other
> IP when required.
> So, addresses will be re-allocated on the next PUT requests.
> If address given by user overlaps with some of the allocated IPs, PUT
> request will be rejected.
> There is a question, what to do when the given address overlaps with the
> network from another
> environment? overlaps with the network of current environment which does not
> match the
> network role of the VIP?
> My opinion that those should pass with a warning message.
>
> Please share your proposals and comments on this,
>
> Thanks,
>
>
> Aleksey Kasatkin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions

[openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Steven Dake (stdake)]

Hey folks,

We had an informal vote at the mid cycle from the core reviewers, and it was a 
majority vote, so we went ahead and started the process of the introduction of 
mesos orchestration into Kolla.

For background for our few core reviewers that couldn't make it and the broader 
community, Angus Salkeld has committed himself and 3 other Mirantis engineers 
full time to investigate if Mesos could be used as an orchestration engine in 
place of Ansible.  We are NOT dropping our Ansible implementation in the short 
or long term.  Kolla will continue to lead with Ansible.  At some point in 
Mitaka or the N cycle we may move the ansible bits to a repository called 
"kolla-ansible" and the kolla repository would end up containing the containers 
only.

The general consensus was that if folks wanted to add additional orchestration 
systems for Kolla, they were free to do so if they did the development and made 
a commitment to maintaining one core reviewer team with broad expertise among 
the core reviewer team of how these various systems work.

Angus has agreed to the following

  1.  A new team called "kolla-mesos-core" with 2 members.  One of the members 
is Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie 
cutter empty repository.  This is typical of how new projects would operate, 
but we don't want a code dump and instead want an integrated core team.  To 
prevent a situation which the current Ansible expertise shy away from the Mesos 
implementation, the core reviewer team has committed to reviewing the mesos 
code to get a feel for it.
  2.  Over the next 6-8 weeks these two folks will strive to join the Kolla 
core team by typical means 1) irc participation 2) code generation 3) effective 
and quality reviews 4) mailing list participation
  3.  Angus will create a technical specification which will we will roll-call 
voted and only accepted once a majority of core review team is satisfied with 
the solution.
  4.  The kolla-mesos deliverable will be under Kolla governance and be managed 
by the Kolla core reviewer team after the kolla-mesos-core team is deprecated.
  5.  If the experiment fails, kolla-mesos will be placed in the attic.  There 
is no specific window for the experiments, it is really up to Angus to decide 
if the technique is viable down the road.
  6.  For the purpose of voting, the kolla-mesos-core team won't be permitted 
to vote (on things like this or other roll-call votes in the community) until 
they are "promoted" to the koala-core reviewer team.

The core reviewer team has agreed to the following

  1.  Review patches in kolla-mesos repository
  2.  Actively learn how the mesos orchestration system works in the context of 
Kolla
  3.  Actively support Angus's effort in the existing Kolla code base as long 
as it is not harmful to the Kolla code base

We all believe this will lead to a better outcome then Mirantis developing some 
code on their own and later dumping it into the Kolla governance or operating 
as a fork.

I'd like to give the core reviewers another chance to vote since the voting was 
semi-rushed.

I am +1 given the above constraints.  I think this will help Kolla grow and 
potentially provide a better (or arguably different) orchestration system and 
is worth the investigation.  At no time will we put the existing Kolla Ansible 
+ Docker goodness into harms way, so I see no harm in an independent repository 
especially if the core reviewer team strives to work as one team (rather then 
two independent teams with the same code base).

Abstaining is the same as voting as -1, so please vote one way or another with 
a couple line blob about your thoughts on the idea.

Note of the core reviewers there, we had 7 +1 votes (and we have a 9 individual 
core reviewer team so there is already a majority but I'd like to give everyone 
an opportunity weigh in).

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

[Rich Megginson]

On 10/31/2015 08:55 AM, Emilien Macchi wrote:

At the Summit we discussed about scaling-up our team.
We decided to investigate the creation of sub-groups specific to our 
modules that would have +2 power.


I would like to start with puppet-keystone:
https://review.openstack.org/240666

And propose Richard Megginson part of this group.

Rich is leading puppet-keystone work since our Juno cycle. Without his 
leadership and skills, I'm not sure we would have Keystone v3 support 
in our modules.
He's a good Puppet reviewer and takes care of backward compatibility. 
He also has strong knowledge at how Keystone works. He's always 
willing to lead our roadmap regarding identity deployment in OpenStack.


Having him on-board is for us an awesome opportunity to be ahead of 
other deployments tools and supports many features in Keystone that 
real deployments actually need.


I would like to propose him part of the new puppet-keystone-core group.

Thank you Rich for your work, which is very appreciated.


Thanks Emilien, and everyone else for your support!


--
Emilien Macchi


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

[Mike Dorman]

+1

From: Clayton O'Neill mailto:clay...@oneill.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, November 1, 2015 at 5:13 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [puppet] Creating puppet-keystone-core and 
proposing Richard Megginson core-reviewer

+1

Big thanks for Rich for all the work he’s done so far.

On Mon, Nov 2, 2015 at 3:34 AM, Adam Young 
mailto:ayo...@redhat.com>> wrote:
On 10/31/2015 10:55 AM, Emilien Macchi wrote:
At the Summit we discussed about scaling-up our team.
We decided to investigate the creation of sub-groups specific to our modules 
that would have +2 power.

I would like to start with puppet-keystone:
https://review.openstack.org/240666

And propose Richard Megginson part of this group.

Rich is leading puppet-keystone work since our Juno cycle. Without his 
leadership and skills, I'm not sure we would have Keystone v3 support in our 
modules.
He's a good Puppet reviewer and takes care of backward compatibility. He also 
has strong knowledge at how Keystone works. He's always willing to lead our 
roadmap regarding identity deployment in OpenStack.

Having him on-board is for us an awesome opportunity to be ahead of other 
deployments tools and supports many features in Keystone that real deployments 
actually need.

I would like to propose him part of the new puppet-keystone-core group.

As a Keystone developer I have to say I am indebted to Rich for his efforts.  
+1 from me.


Thank you Rich for your work, which is very appreciated.
--
Emilien Macchi



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Hi folks,

I'm working on the following story [1][2]:
API must allow VIP to be manually set to ANY valid IP address. If the IP on
update API is a member of any network in this environment then the address
should be put in the assignments table so that it can not be used in any
other
automatic assignment. (This allows the user to override if the automatic
allocation doesn't match their needs or in the case that they want to use
external LB).

[1] https://bugs.launchpad.net/fuel/+bug/1482399
[2] https://review.openstack.org/230943

So, I have the following proposal for now:
Add new url (e.g. /clusters//network_configuration/vips/ ), use
GET
to query current VIPs info, use PUT to change VIPs addresses (set them
manually
or request to allocate them automatically).
Now VIPs have the following format in API requests data:
vips: [
{
'network_role': 'management',
'namespace': 'haproxy',
'ipaddr': '10.10.10.10',
'node_roles': ['controller']
},...
]
So, 'ipaddr' field can be set to any (almost any) user-defined value or to
None (null in YAML).
When it is set to None, IP address will be allocated automatically. When
the user runs GET
request for the first time, all 'ipaddr' fields are equal to None. So, user
can set some (or all)
of them to desired values and run PUT. When the GET is run after PUT, all
addresses will be
filled with values. User can reset some of them to None or change to other
IP when required.
So, addresses will be re-allocated on the next PUT requests.
If address given by user overlaps with some of the allocated IPs, PUT
request will be rejected.
There is a question, what to do when the given address overlaps with the
network from another
environment? overlaps with the network of current environment which does
not match the
network role of the VIP?
My opinion that those should pass with a warning message.

Please share your proposals and comments on this,

Thanks,


Aleksey Kasatkin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

[Sam Betts (sambetts)]

Auto discovery is a topic which has been discussed a few times in the past for

Ironic, and its interesting to solve because its a bit of a chicken and egg

problem. The ironic inspector allows us to inspect nodes that we don't know

the mac addresses for yet, to do this we run a global DHCP PXE rule that will

respond to all mac addresses and PXE boot any machine that requests it,

this means its possible for machines that we haven't been asked to

inspect to boot into the inspector ramdisk and send their information to

inspector's API. To prevent this data from being processed further by

inspector if its a machine we shouldn't care about, we do a node lookup. If the 
data

fails this node lookup we used to drop this data and continue no further, in

release 2.0.0 we added a hook point to intercept this state called the Node Not

Found hook point which allows us to run some python code at this point in

processing before failing and dropping the inspection data. Something we've

discussed as a use for this hook point is, enrolling a node that fails the

lookup into Ironic, and then having inspector continue to process the

inspection data as we would for any other node that had inspection requested

for it, this allows us to auto-discover unknown nodes into Ironic.


If this auto discovery hook was enabled this would be the flow when inspector

receives inspection data from the inspector ramdisk:


- Run pre-process on the inspection data to sanitise the data and ready it for

  the rest of the process


- Node lookup using fields from the inspection data:

  - If in inspector node cache return node info


  - If not in inspector node cache and but is in ironic node database, fail

inspection because its a known node and inspection hasn't been requested

for it.


  - If not in inspector node cache or ironic node database, enroll the node in

ironic and return node info


- Process inspection data


The remaining question for this idea is how to handle the driver settings for

each node that we discover, we've currently discussed 3 different options:


1. Enroll the node in ironic using the fake driver, and leave it to the operator

   to set the driver type and driver info before they move the node from enroll

   to manageable.


2. Allow for the default driver and driver info information to be set in the

   ironic inspector configuration file, this will be set on every node that is

   auto discovered. Possible config file example:


   [autodiscovery]

   driver = pxe_ipmitool

   address_field = 

   username_field = 

   password_field = 


3. A possibly vendor specific option that was suggested at the summit was to

   provide an ability to look up out of band credentials from an external CMDB.


The first option is technically possible using the second option, by setting

the driver to fake and leaving the driver info blank.


With IPMI based drivers most IPMI related information can be retrieved from the

node by the inspector ramdisk, however for non-ipmi based drivers such as the

cimc/ucs drivers this information isn't accessible from an in-band OS command.


A problem with option 2 is that it can not account for a mixed driver

environment.


We have also discussed for IPMI based drivers inspector could set a new

randomly generated password on to the freshly discovered node, with the idea

being fresh hardware often comes with a default password, and if you used

inspector to discover it then it could set a unique password on it and

automatically make ironic aware of that.


We're throwing this idea out onto the mailer because we'd like to get feedback

from the community to see if this would be useful for people using inspector,

and to see if people have any opinions on what the right way to handle the node

driver settings is.


Sam (sambetts)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra][Nova][Neutron] 6WIND Networking CI - approval for posting comments

[John Garbutt]

On 31 October 2015 at 23:06, Armando M.  wrote:
> On 30 October 2015 at 23:59, Matt Riedemann 
> wrote:
>> On 10/30/2015 7:41 AM, Armando M. wrote:
>>> On 30 October 2015 at 18:41, Francesco Santoro
>>> mailto:francesco.sant...@6wind.com>> wrote:
>>> Hi Armando,
>>> thanks for you answer.
>>>
>>> We actually just want approval for posting non voting comments to
>>> neutron.
>>> As you said we don't have a significant history on Gerrit because,
>>> after some successful tests, we stopped posting comments on neutron
>>> (and nova) waiting for core maintainers approval.
>>> Our current CI activity is obviously not long enough to request
>>> voting rights.
>>>
>>> We are still commenting back to Gerrit on ci-devstack but there is
>>> no big activity on this project.
>>> Since our idea (for future) is to obtain voting rights we need to
>>> post comments to have a stronger Gerrit activity and to let you
>>> evaluate the stability of our CI.
>>>
>>> Do you suggest to keep posting on ci-devstack or can we enable
>>> comments to neutron as well?
>>>
>>>
>>> I would be ok to have this voting for now.
>>>
>>> Having said that, Mike (cc-ed here) will be working closely with the
>>> Neutron team to re-align/improve Neutron 3rd party CI support, so stay
>>> tuned for progresses on this front.
>>>
>>> Cheers,
>>> Armando
>>>
>>>
>>> Regards,
>>> Francesco
>>> On Fri, Oct 30, 2015 at 1:17 AM, Armando M. >> > wrote:
>>>
>>>
>>>
>>> On 30 October 2015 at 02:49, Matt Riedemann
>>> mailto:mrie...@linux.vnet.ibm.com>>
>>>
>>> wrote:
>>>
>>>
>>>
>>> On 10/29/2015 12:13 PM, Francesco Santoro wrote:
>>>
>>> Dear Infra team,
>>>
>>> According to the requirements specified in [1] posting
>>> comments on
>>> patches needs approval from core maintainers of projects.
>>>
>>> Here at 6WIND we deployed and successfully tested [2]
>>> (using ci-sandbox
>>> project) our third party CI system [4] following all the
>>> steps defined
>>> in [1].
>>> We also run our CI on nova (and neutron) patches without
>>> posting
>>> comments just to test a bigger jobs load.
>>> Example artifacts are available at [3]
>>>
>>> For this reason we would like to get your official
>>> approval for posting
>>> non voting comments to both nova and neutron.
>>>
>>>
>>> The CI hasn't been doing this long enough [1] to really see how
>>> reliable it is, but it's been promising so far.
>>>
>>>
>>> [1]
>>>
>>> https://review.openstack.org/#/q/reviewer:%226WIND+Networking+CI+%253Copenstack-networking-ci%25406wind.com%253E%22+project:openstack/neutron,n,z
>>>
>>>
>>>
>>> Kind regards,
>>> Francesco
>>>
>>> [1]
>>>
>>> http://docs.openstack.org/infra/system-config/third_party.html#requirements
>>> [2] https://review.openstack.org/#/c/238139/ or
>>> https://review.openstack.org/#/c/226956/
>>> [3]
>>> http://openstack-ci.6wind.com/networking-6wind-ci/230537
>>> or
>>> http://openstack-ci.6wind.com/networking-6wind-ci/202098
>>> [4]
>>>
>>> https://wiki.openstack.org/wiki/ThirdPartySystems/6WIND_Networking_CI
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage
>>> questions)
>>> Unsubscribe:
>>>
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> Do you have any code in nova that's specific to your
>>> configuration?
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>> http://lists.openstack.org/

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Davanum Srinivas]

Sean,

ah. so the tip about LOGDIR to /dev/null may work for you

-- dims

On Mon, Nov 2, 2015 at 10:36 AM, Sean M. Collins  wrote:

> On Sun, Nov 01, 2015 at 10:12:10PM EST, Davanum Srinivas wrote:
> > Sean,
> >
> > I typically switch off screen and am able to redirect logs to a specified
> > directory. Does this help?
> >
> > USE_SCREEN=False
> > LOGDIR=/opt/stack/logs/
>
> It's not that I want to disable screen. I want screen to run, and not
> log the output to files, since I have a tiny 16GB ssd card on these NUCs
> and it fills it up if I leave it running for a week or so.
>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Sean M. Collins]

On Sun, Nov 01, 2015 at 10:12:10PM EST, Davanum Srinivas wrote:
> Sean,
> 
> I typically switch off screen and am able to redirect logs to a specified
> directory. Does this help?
> 
> USE_SCREEN=False
> LOGDIR=/opt/stack/logs/

It's not that I want to disable screen. I want screen to run, and not
log the output to files, since I have a tiny 16GB ssd card on these NUCs
and it fills it up if I leave it running for a week or so. 

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Vladimir Kuklin]

+1 to Evgeniy

There should be no type of restrictions that cannot be overriden by user.

On Mon, Nov 2, 2015 at 5:37 PM, Vitaly Kramskikh 
wrote:

> Hi,
>
> I think having both compatibility and incompatibility lists is a good
> idea. I think we need just to show a warning if users pick options which
> are not in compatibility list and disable options which are in
> incompatibility list. We also need to be able to provide a message in case
> of incompatibility: the current implementation of the wizard supports
> custom messages in the wizard config and they are quite useful.
>
> 2015-11-02 16:16 GMT+07:00 Evgeniy L :
>
>> Hi,
>>
>> The main reason why I think we should get all of the three states is we
>> don't know exactly if those plugins (which developer didn't specify) are
>> compatible or not, so we should not make any assumptions and prevent
>> the user from enabling any plugins she/he wants. The best we can do here
>> is to provide all of the information plugin developer knows, directly to
>> the user,
>> without us in the middle who make decisions based on incomplete data.
>>
>> So lets ask plugin developer to specify a set of components which he
>> tested
>> his plugin with. Plus a list of components which he tested with and he is
>> sure
>> that those are not going to working together.
>>
>> On UI we can show explicitly, that this combination is tested and
>> approved to
>> be working, another combination is not working for sure (plugin
>> developers tested
>> it and explicitly specified), and there will be a lot of combination
>> which are going
>> to work together without problems, but we should say the user, that the
>> developer
>> didn't test it and he should test and use it carefully.
>>
>> Thanks,
>>
>> On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
>> wrote:
>>
>>> Hi fuelers,
>>>
>>> Currently we are working on feature component registry [1] which should
>>> help us to prevent not logical compositions of different components in
>>> wizard tab during cluster(environment) creation. Now we have a mechanizm
>>> of 'restrictions' which is not flexible for components provided by
>>> plugins. In our current approach we have two states for components -
>>> compatible/incompatible which are described in compatibility matrix
>>> based on OpenStack components (For example: cinder-vmware storage only
>>> compatible with vCetner hypervisor and should work when only KVM uses).
>>> In this case we allow user to choose only that components we defently
>>> know works well with each other. Another approach tell us to have 3
>>> states: compatible/incompatible/ and all other components about
>>> compatibility with others we know nothing. In that case we should show
>>> on wizard which components compatible, which not, and others which user
>>> can enable on his own risk. So I need your opinions: should we allow for
>>> user choose only that coponents which are tested and defently works or
>>> prevent her/him from choosing which are defently not works and means
>>> potentional risk of failing deployment when component about we know
>>> nothing isn't work together.
>>>
>>>
>>>
>>> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

[Bogdan Dobrelya]

Here is a docs update [0] for the patch [1] - which is rather a
framework - being discussed here.
Note, that the tool fuel_noop_tests.rb Dmitry Ilyin wrote became a Noop
testing framework, which is Fuel specific. But the same approach may be
used for any set of puppet modules and a composition layer manifests
with a dataset of deployment parameters you may want it to be tracked
against potential regressions.

I believe we should think about how that Noop testing framework (and
the deployment data checks under discussion as well) might benefit the
puppet community.

[1] https://review.openstack.org/240901
[2] https://review.openstack.org/240015

On 29.10.2015 15:24, Bogdan Dobrelya wrote:
> Hello.
> There are few types of a deployment regressions possible. When changing
> a module version to be used from upstream (or internal module repo), for
> example from Liberty to Mitaka. Or when changing the composition layer
> (modular tasks in Fuel). Specifically, adding/removing/changing classes
> and a class parameters.
> 
> An example regression for swift deployment data [0]. Something was
> changed unnoticed by existing noop tests and as a result
> the swift data became being stored in root partition.
> 
> Suggested per-commit based regressions detection [1] for deployment data
> assumes to automatically detect if a class in a noop catalog run has
> gained or lost a parameter or if it has been updated to another value by
> a patch under test. Later, this check could even replace existing noop
> tests, everything will be checked automatically, unless every deployment
> scenario is covered by a corresponding template, which are represented
> as YAML files [2] in Fuel.
> Note: The tool [3] can help to get all deployment cases (-Y) and all
> deployment tasks (-S) as well.
> 
> I propose to review the patch [1], understand how it works (see tl;dr
> section below) and to start using it ASAP. The earlier we commit the
> "initial" data layer state, less regressions would pop up.
> 
> (tl;dr)
> The check should be done for every modular component (aka deployment
> task). Data generated in the noop catalog run for all classes and
> defines of a given deployment task should be verified against its
> "acknowledged" (committed) state.
> And fail the test gate, if changes has been found, like new parameter
> with a defined value, removed a parameter, changed a parameter's value.
> 
> In order to remove a regression, a patch author will have to add (and
> reviewers should acknowledge) detected changes in the committed state of
> the deployment data. This may be done manually, with a tool like [3] or
> by a pre-commit hook, or even at the CI side!
> The regression check should show the diff between committed state and a
> new state proposed in a patch. Changed state should be *reviewed* and
> accepted with a patch, to became a committed one. So the deployment data
> will evolve with *only* approved changes. And those changes would be
> very easy to be discovered for each patch under review process!
> No more regressions, everyone happy.
> 
> Examples:
> 
> - A. A patch author removed the mpm_module parameter from the
> composition layer (apache modular task). The test should fail with a
> 
> Diff:
>   @@ -90,7 +90,7 @@
>  manage_user=> 'true',
>  max_keepalive_requests => '100',
>  mod_dir=> '/etc/httpd/conf.d',
>   -  mpm_module => 'false',
>   +  mpm_module => 'prefork',
>  name   => 'Apache',
>  package_ensure => 'installed',
>  ports_file => '/etc/httpd/conf/ports.conf',
> 
> It illustrates that the mpm_module's committed value was "false".
> But the new one came as the 'prefork', likely from the apache class
> defaults.
> The solution:
> Follow the failed build link and see for detected changes (a diff).
> Acknowledge the changes and include rebuilt templates in the patch as a
> new revision. The tool [3] (use -h for help) example command:
> ./utils/jenkins/fuel_noop_tests.rb -q -b -s api-proxy/api-proxy_spec.rb
> 
> Or edit the committed templates manually and include data changes in the
> patch as well.
> 
> -B. An upstream module author added the new parameter mpm_mode with a
> default '123'. The test should fail with a
> 
> Diff:
>@@ -90,6 +90,7 @@
>   manage_user=> 'true',
>   max_keepalive_requests => '100',
>   mod_dir=> '/etc/httpd/conf.d',
>+  mpm_mode   => '123',
>   mpm_module => 'false',
>   name   => 'Apache',
>   package_ensure => 'installed',
> 
> It illustrates that the composition layer is not consistent with the
> upstream module data schema, and that could be a potential regression in
> deployment (new parameter added upstream and goes with defaults, being
> ignored by the composition manifest).
> The solution is the same

[openstack-dev] [openstack-ansible][openstack-infra] Ansible Role Testing

[Jesse Pretorius]

Hi everyone,

Currently there are jenkins macros for Ansible role testing that cover
syntax [1] and lint [2] tests. I'd like to add a generic ansible playbook
'run' test which executes a test playbook for the role, and perhaps an
'idempotence' test which executes the test playbook twice and checks that
the role does not change anything on the second run.

It should be straightforward enough to do this using the established
tests/test.yml playbook referred to by the syntax macro.

Before I go ahead and do this, are there any concerns that I may not be
aware of that may cause a conflict here? Are there any additional
suggestions or requirements that should be included?

Are there any better suggestions for the naming of the job - for now my
thinking is simply for the job names to be:
 - ansible-playbook-run
 - ansible-playbook-idempotence

[1]
https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/macros.yaml#n315
[2]
https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/macros.yaml#n330

-- 
Jesse
IRC: odyssey4me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How we can find list of medium/low bugs for nova

[Matt Riedemann]

On 11/2/2015 8:46 AM, Matt Riedemann wrote:



On 11/1/2015 2:56 AM, chandraprakash mishra wrote:


I want to just start participation in openstack-nova from low/medium
level of bugs.
I tried to list out bugs but i am confused about target .is it all bugs
based on target (Kilo,Liberty)
or we can start random bugs from _nova list bug


--
Thanks and Regards,
Chandra Prakash Mishra
Software engineer,hp
9611424996



__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



These are low/medium open nova bugs that don't have anyone assigned:

https://goo.gl/uo3vGy



As soon as I sent this I noticed that most of these low/medium nova bugs 
are 1+ years old, meaning they are probably bigger problems (effort) to 
solve that are low priority for the project, so maybe not a great place 
for a new person to start. But you're free to sift through them and see 
if there is anything worth picking up. There might also be things in 
that list that are no longer valid and we could just close out; ask 
about bugs like that in the #openstack-nova IRC channel.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How we can find list of medium/low bugs for nova

[Matt Riedemann]

On 11/1/2015 2:56 AM, chandraprakash mishra wrote:


I want to just start participation in openstack-nova from low/medium
level of bugs.
I tried to list out bugs but i am confused about target .is it all bugs
based on target (Kilo,Liberty)
or we can start random bugs from _nova list bug

--
Thanks and Regards,
Chandra Prakash Mishra
Software engineer,hp
9611424996



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



These are low/medium open nova bugs that don't have anyone assigned:

https://goo.gl/uo3vGy

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] status of the live upgrade session

[Dulko, Michal]

On Sat, 2015-10-31 at 12:08 +0800, Gareth wrote:
> Hey guys,
> 
> In this summary
> https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads, there
> is a live upgrade session. But the linked the etherpad is empty:
> https://etherpad.openstack.org/p/mitaka-crossproject-upgrades .
> 
> So what's the status or conclusion of this session?
> 

During the session Dan Smith explained how Nova achieved live upgrades
capabilities and explained the different parts of that effort. Apart
from that we've discussed the approach other projects should take on
that - Neutron, Cinder, Heat.

I've added my own notes to the Etherpad. I'm not sure if these are very
helpful, but probably it's better than nothing. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Vitaly Kramskikh]

Hi,

I think having both compatibility and incompatibility lists is a good idea.
I think we need just to show a warning if users pick options which are not
in compatibility list and disable options which are in incompatibility
list. We also need to be able to provide a message in case of
incompatibility: the current implementation of the wizard supports custom
messages in the wizard config and they are quite useful.

2015-11-02 16:16 GMT+07:00 Evgeniy L :

> Hi,
>
> The main reason why I think we should get all of the three states is we
> don't know exactly if those plugins (which developer didn't specify) are
> compatible or not, so we should not make any assumptions and prevent
> the user from enabling any plugins she/he wants. The best we can do here
> is to provide all of the information plugin developer knows, directly to
> the user,
> without us in the middle who make decisions based on incomplete data.
>
> So lets ask plugin developer to specify a set of components which he tested
> his plugin with. Plus a list of components which he tested with and he is
> sure
> that those are not going to working together.
>
> On UI we can show explicitly, that this combination is tested and approved
> to
> be working, another combination is not working for sure (plugin developers
> tested
> it and explicitly specified), and there will be a lot of combination which
> are going
> to work together without problems, but we should say the user, that the
> developer
> didn't test it and he should test and use it carefully.
>
> Thanks,
>
> On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
> wrote:
>
>> Hi fuelers,
>>
>> Currently we are working on feature component registry [1] which should
>> help us to prevent not logical compositions of different components in
>> wizard tab during cluster(environment) creation. Now we have a mechanizm
>> of 'restrictions' which is not flexible for components provided by
>> plugins. In our current approach we have two states for components -
>> compatible/incompatible which are described in compatibility matrix
>> based on OpenStack components (For example: cinder-vmware storage only
>> compatible with vCetner hypervisor and should work when only KVM uses).
>> In this case we allow user to choose only that components we defently
>> know works well with each other. Another approach tell us to have 3
>> states: compatible/incompatible/ and all other components about
>> compatibility with others we know nothing. In that case we should show
>> on wizard which components compatible, which not, and others which user
>> can enable on his own risk. So I need your opinions: should we allow for
>> user choose only that coponents which are tested and defently works or
>> prevent her/him from choosing which are defently not works and means
>> potentional risk of failing deployment when component about we know
>> nothing isn't work together.
>>
>>
>>
>> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [rpm-packaging] core reviewers nomination

[Ihar Hrachyshka]

> On 02 Nov 2015, at 15:23, Haïkel  wrote:
> 
> I'd like to propose new candidates for RPM packaging core reviewers:
> Alan Pevec
> Jakub Ruzicka
> 
> Both are involved in downstream RDO project and this group creation.
> Alan is part of the stable release team and Jakub has been working on
> our tooling since the beginning.
> Having them onboard as core reviewers would help accelerate the
> bootstrap of the project.
> 
> RPM packaging core, please vote with +/- 1.
> 
> Regards,
> H
> 

I am not a packaging core,

but I just want to express that if someone deserves the nomination, it’s Jakub 
and Alan. They did all RDO packaging heavy lifting and were key to opening RDO 
gate for more open collaboration. I hope they will stay key to the project and 
will lead it towards even more openness.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held
Tuesday UTC1200.

In other timezones the meeting is at:

EST 08:00 (Tue)
Japan 21:00 (Tue)
China 20:00 (Tue)
United Kingdom 13:00 (Tue)

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Next Nova meeting on November 5th 2015

[John Garbutt]

On 19 October 2015 at 12:14, John Garbutt  wrote:
> Hi,
>
> Due to the summit, we decided the next meeting will be:
> November 4th 2015 2100 UTC, #openstack-meeting
> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20151104T21
>
> For more details, as usual, please see:
> https://wiki.openstack.org/wiki/Meetings/Nova
>
> As normal, any questions, please do ask.

Slight issue in my previous note here, the actual details are:

Thursday November 5th 2015 2100 UTC, #openstack-meeting
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20151105T21

Not sure how I managed to miss-read my calendar in that way, but I did :(

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Pino,

Please see inline.

Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Monday, November 02, 2015 10:22 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang 
mailto:cathy.h.zh...@huawei.com>> wrote:


From: Giuseppe (Pino) de Candia 
[mailto:gdecan...@midokura.com]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.
I don't think that works. For L3 services, the packet's destination MAC must be 
set equal to the service port's MAC. That means that all the original 
destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF instance 
is shared across multiple tenants with overlapping IPs. Therefore, I use the 
MAC to identify the service chain instance and get a packet back on its 
original network path.

Cathy> Not sure why you use MAC to identify the service chain instance? It is 
better to use a separate chain ID for this purpose.

So, I won't modify the packet at all. Can you suggest another solution? And why 
so much resistance to adding a flag when we can actually show use-cases? Note 
that this is already actually running code today, using MidoNet's service 
chaining API.

Cathy> If you use a separate chainID, then you will not need a flag to handle 
the use cases. If you really need a flag, one way is to extend the SF parameter 
to specify a L2/L3 type.

thanks,
Pino


Thanks,

Cathy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [rpm-packaging] core reviewers nomination

[Haïkel]

I'd like to propose new candidates for RPM packaging core reviewers:
Alan Pevec
Jakub Ruzicka

Both are involved in downstream RDO project and this group creation.
Alan is part of the stable release team and Jakub has been working on
our tooling since the beginning.
Having them onboard as core reviewers would help accelerate the
bootstrap of the project.

RPM packaging core, please vote with +/- 1.

Regards,
H

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[Thierry Carrez]

Joe Cropper wrote:
> 
>> On Nov 2, 2015, at 4:50 AM, Thierry Carrez  wrote:
>>
>> Antoine CABOT wrote:
>>> We are pleased to introduce Watcher, a new project in the OpenStack 
>>> ecosystem. We believe that a "resource optimization" service in an 
>>> OpenStack-based cloud is a crucial component that has been missing to 
>>> date and we have started working towards filling that gap.
>>>
>>> OpenStack Watcher provides a flexible and scalable resource 
>>> optimization service for multi-tenant OpenStack-based clouds. 
>>> [...]
>>
>> Please note that this project is not an official OpenStack project yet.
>> In particular, it's not been approved by the Technical Committee to join
>> the "big tent" yet, and it was actually never proposed there.
>>
>> If you intend to propose this new project for inclusion, please propose
>> an openstack/governance change to that effect. You can find the current
>> project requirements at:
>>
>> http://governance.openstack.org/reference/new-projects-requirements.html
>>
>> In the mean time, please refrain from calling your project "OpenStack
>> Watcher". Thanks in advance!
> 
> No problem, Thierry!  Our apologies for the terminology hiccup.  We do intent 
> to propose it as part of the “big tent” in the coming months—the project’s 
> wiki and source code repository were just recently configured on 
> openstack.org and we’re actively working on the checklist of items you 
> referenced.  :-)

Sounds good! We'll likely require a bit of activity before we can judge
the inclusion anyway (that is the only way for us to judge if you're
following the OpenStack way). It's perfectly fine (and even encouraged)
to be hosted on openstack infrastructure for the time being :) I was
just adding a bit of clarification since using "OpenStack Watcher" in
the original post could have been seen as some official endorsement.

Another pointer you might be interested in: the Project Team Guide gives
a lot of information about the OpenStack way of doing things for
official Project Teams:

http://docs.openstack.org/project-team-guide/

Regards,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Jesse Pretorius]

On 29 October 2015 at 12:43, Major Hayden  wrote:

> On 10/29/2015 04:33 AM, McPeak, Travis wrote:
> > The only potential security drawback is that we are introducing a new
> > asset to protect.  If we create the tools that enable a deployer to
> > easily create and administer a lightweight CA, that should add
> > significant value to OpenStack, especially for smaller organizations
> > that don't have experience running a CA.
>
> This is certainly true.  However, I'd like to solve for the use of
> self-signed SSL certificates in openstack-ansible first.
>
> At the moment, each self-signed certificate for various services is
> generated within each role.  The goal would be to make a CA at the
> beginning and then allow roles to utilize another role/task to issue
> certificates from that CA.  The CA would most likely be located on the
> deployment host.
>
> Deployers who are very security conscious can provide keys, certificates,
> and CA certificates in the deployment configuration and those will be used
> instead of generating self-signed certificates.
>

I would argue that self-signed certificates only provide an illusion of
security and the tasks we have to generate and distribute them should be
removed entirely. My thinking is that if a deployer wants to use
self-signed certs, then the deployer can create them and provide their
details as user-provided certs. That way we can do without a whole block of
code and the dependency on memcache for distribution. This makes the
decision to use the self-signed certs a more deliberate one and also takes
care of the complexity of certificate distribution.

That said, I applaud the idea of using a CA role. There are a few in
Ansible Galaxy, but I've found their implementations to be rather complex
whereas I think they can be pretty simple. I have actually done a fair
amount of work on the CA setup part of things in my not-yet-complete
ansible-openvas role [1]. You are welcome to use this work as a starting
base and develop a role which sets up a CA. The trouble I found when
looking into how to do this properly was that there should be several CA's
(one offline primary and more than one secondary which actually does the
signing). This will mean that the role will require quite a bit of guidance
for using it correctly and setting up a single CA or multi-CA environment.

Whether you develop a new role for the OpenStack-Ansible toolbox, or
develop documentation for consuming an existing role in Ansible Galaxy, the
concept is certainly welcome and would go a long way to simplifying a
secure-by-default implementation of OpenStack.

[1]
https://github.com/odyssey4me/ansible-openvas/blob/master/tasks/install_openssl_ca.yml

---
Jesse
IRC: odyssey4me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[Joe Cropper]

> On Nov 2, 2015, at 4:50 AM, Thierry Carrez  wrote:
> 
> Antoine CABOT wrote:
>> We are pleased to introduce Watcher, a new project in the OpenStack 
>> ecosystem. We believe that a "resource optimization" service in an 
>> OpenStack-based cloud is a crucial component that has been missing to 
>> date and we have started working towards filling that gap.
>> 
>> OpenStack Watcher provides a flexible and scalable resource 
>> optimization service for multi-tenant OpenStack-based clouds. 
>> [...]
> 
> Please note that this project is not an official OpenStack project yet.
> In particular, it's not been approved by the Technical Committee to join
> the "big tent" yet, and it was actually never proposed there.
> 
> If you intend to propose this new project for inclusion, please propose
> an openstack/governance change to that effect. You can find the current
> project requirements at:
> 
> http://governance.openstack.org/reference/new-projects-requirements.html
> 
> In the mean time, please refrain from calling your project "OpenStack
> Watcher". Thanks in advance!

No problem, Thierry!  Our apologies for the terminology hiccup.  We do intent 
to propose it as part of the “big tent” in the coming months—the project’s wiki 
and source code repository were just recently configured on openstack.org and 
we’re actively working on the checklist of items you referenced.  :-)

Regards,
Joe (jwcroppe)

> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum]generate config files by magnum

[Steven Dake (stdake)]

The reason we don’t rely on cloudint more then we already do (sed is run via 
cloudiit) is because many modern distress like CentOS and Fedora Atomic have 
many parts of the host os as read-only.

I prefer the structure as it is.

Regards
-steve


From: 王华 mailto:wanghua.hum...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 2, 2015 at 12:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [magnum]generate config files by magnum

Hi forks,

Magnum needs to prepare config files for k8s and docker and add these services 
to systemd. Now we use "sed" to replace some parameters in config files. The 
method has a disadvantage. Magnum code  depends on a specific image. Users may 
want to create images by themselves. The config files in their images may be 
different from ours. I think magnum shouldn't depends on the config files in 
the image. These config files should be generated by magnum. What magnum needs 
should be just the installation of k8s, docker, etc. Maybe we can use 
cloud-init to install the softwares automatically, so that we don't need to 
create images and what we needs is just a image with cloud-init.

Regards,
Wang Hua
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang 
wrote:

>
>
>
>
> *From:* Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
> *Sent:* Saturday, October 31, 2015 10:08 PM
> *To:* Cathy Zhang
> *Cc:* Henry Fourie; OpenStack Development Mailing List (not for usage
> questions); Irena Berezovsky
> *Subject:* RE: [openstack-dev] [neutron][networking-sfc] API
> clarification questions
>
> >
> > Cathy> No restriction as long as the ports are routable. Originally we
> think we need to specify L2 and L3 service type. But later we found out it
> is not needed if we program the switch to set the next hop destination to
> the service function’s MAC. This way no matter whether it is L2 or L3, it
> always works.
> >
>
> Hi Cathy, my understanding is that:
> -for an L2 service, don't modify the packet (ignoring possible
> encapsulation to signal policy )
> -for an L3 service, set the dst MAC in the packet equal to the the service
> port's MAC
>
> How can the SDN implementation know which kind of service it's dealing
> with to decide whether to modify the MAC?
>
> Cathy> You can always modify the MAC which will work for both L2 and L3
> service.
>
I don't think that works. For L3 services, the packet's destination MAC
must be set equal to the service port's MAC. That means that all the
original destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF
instance is shared across multiple tenants with overlapping IPs. Therefore,
I use the MAC to identify the service chain instance and get a packet back
on its original network path.

So, I won't modify the packet at all. Can you suggest another solution? And
why so much resistance to adding a flag when we can actually show
use-cases? Note that this is already actually running code today, using
MidoNet's service chaining API.

thanks,
Pino


> Thanks,
>
> Cathy
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] weekly meeting #57

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151103

Feel free to add any items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

Thanks,
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.

Thanks,

Cathy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

[Oğuz Yarımtepe]

On Mon, Nov 2, 2015 at 1:36 PM, Somanchi Trinath <
trinath.soman...@freescale.com> wrote:

> Hi-
>
>
>

Hi,


> I’m confused. Do you really have an PoC implementation of what is to be
> achieved?
>
>

No indeed. I am using iptables driver to understand the FWaaS structure and
trying to replace it with our hw fw. Now my plan is to just create a fw
with some rules defined on it.


>
>
> As I look into these type of Implementations, I would prefer to have proxy
> driver/plugin to get the configuration from Openstack to external
> controller/device and do the rest of the magic.
>

Now i am bit confused about that proxy driver. Are we talking about
something like
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/drivers/linux/iptables_fwaas.py
or another external app to handle the issues? Can you make this proxy part
a bit clearer?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

[Somanchi Trinath]

Hi-

I’m confused. Do you really have an PoC implementation of what is to be 
achieved?

As I look into these type of Implementations, I would prefer to have proxy 
driver/plugin to get the configuration from Openstack to external 
controller/device and do the rest of the magic.

-
Trinath

From: Oğuz Yarımtepe [mailto:oguzyarimt...@gmail.com]
Sent: Monday, November 02, 2015 4:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas 
driver writing

Hi,

On Mon, Nov 2, 2015 at 11:25 AM, Somanchi Trinath 
mailto:trinath.soman...@freescale.com>> wrote:
Hi –

Based on this “Assuming that, it will not be routing traffic, just filtering, 
and that we will be using virtual routers of Openstack”

As I understand from the email, you might be comfortable to configure the HW-FW 
using the ReST API. So you can write a proxy driver and connect the HW-FW in 
the setup (which you have tested to make it ready to use). The proxy driver 
written helps to Configure the HW-FW and the HW-FW filters the traffic.

Having said that, I assume that the HW-FW has some intelligence to process the 
requests from proxy driver and update the FW configuration.


To be sure, calling the REST API at 
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/drivers/linux/iptables_fwaas.py#L62
 for ex to create a firewall is what you are talking about. Instead of 
iptables, a new driver will be written to handle CRUD operations.
To distinguish the tenant networks, i will be using vlan or vxlan ids while 
entering firewall rules, i think.


*HW-FW – Hardware Firewall.

Hope this helps.

-
Trinath


Did I understand you right, about the proxy driver?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] Team meeting - 11/02/2015

[Renat Akhmerov]

Hi,

I guest most people returned from the summit so I’d like to have a team meeting 
at our usual place and time: #openstack-meeting at 16.00 UTC

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Quickly highlight what we did at the summit
Discuss major items for Mitaka roadmap
Open discussion

Please add more (or more specific) items, if any.

Renat Akhmerov
@ Mirantis Inc.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

[Oğuz Yarımtepe]

Hi,

On Mon, Nov 2, 2015 at 11:25 AM, Somanchi Trinath <
trinath.soman...@freescale.com> wrote:

> Hi –
>
>
>
> Based on this “Assuming that, it will not be routing traffic, just
> filtering, and that we will be using virtual routers of Openstack”
>
>
>
> As I understand from the email, you might be comfortable to configure the
> HW-FW using the ReST API. So you can write a proxy driver and connect the
> HW-FW in the setup (which you have tested to make it ready to use). The
> proxy driver written helps to Configure the HW-FW and the HW-FW filters the
> traffic.
>
>
>
> Having said that, I assume that the HW-FW has some intelligence to process
> the requests from proxy driver and update the FW configuration.
>
>
>

To be sure, calling the REST API at
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/drivers/linux/iptables_fwaas.py#L62
for ex to create a firewall is what you are talking about. Instead of
iptables, a new driver will be written to handle CRUD operations.

To distinguish the tenant networks, i will be using vlan or vxlan ids while
entering firewall rules, i think.



> *HW-FW – Hardware Firewall.
>
>
>
> Hope this helps.
>
>
>
> -
>
> Trinath
>
>
>


Did I understand you right, about the proxy driver?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Troubleshooting cross-project comms

[Thierry Carrez]

Anne Gentle wrote:
> I wanted to write up some of the discussion points from a cross-project
> session here at the Tokyo Summit about cross-project communications. The
> etherpad is here: 
> https://etherpad.openstack.org/p/mitaka-crossproject-comms
> 
> One item that came up that I wanted to ensure we gather feedback on is
> evolving the cross-project meeting to an "as needed" rotation, held at
> any time on Tuesdays or Wednesdays. We can set up meetbot in a new
> meeting room, #cross-project-meeting, and then bring in the necessary
> participants while also inviting everyone to attend. 
> 
> I sense this helps with the timezone issues we all face, as well as
> brings together the relevant projects in a moment, while allowing other
> projects to filter out unnecessary discussions to help everyone focus
> further on solving cross-project issues.
> [...]

Hey Anne,

Thanks for the writeup. We'll still have a cross-project meeting at the
usual hour (21:00 UTC) this week (as it was scheduled already) and use
it to discuss that change (and other design summit feedback). If we can
get some consensus around the idea, we could deprecate the meeting
starting next week.

Cheers,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How we can find list of medium/low bugs for nova

[Markus Zoeller]

Christopher Aedo  wrote on 11/02/2015 01:04:54 AM:

> From: Christopher Aedo 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 11/02/2015 01:09 AM
> Subject: Re: [openstack-dev] How we can find list of medium/low bugs for 
nova
> 
> On Sun, Nov 1, 2015 at 1:22 AM, chandraprakash mishra
>  wrote:
> > My concern was how i can filter bug list for a specific project like
> > kilo,liberty etc
> > https://bugs.launchpad.net/openstack/+bugs
> 
> Chandra, you can find bugs for specific projects under their own
> launchpad sections, such as:
> 
> https://bugs.launchpad.net/nova/+bugs
> 
> A great place to start is by looking at "low-hanging-fruit" bugs which
> are expected to be relatively easy to resolve, and usually already
> have been triaged with the details on how to fix included in the bug
> thread:
> 
> https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit
> 
> -Christopher


I also like to recommend to read the (not yet merged) "bug handling 
description" of the developer's guide:

  https://review.openstack.org/#/c/192232/4/doc/source/developers.rst,cm

Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[Thierry Carrez]

Antoine CABOT wrote:
> We are pleased to introduce Watcher, a new project in the OpenStack 
> ecosystem. We believe that a "resource optimization" service in an 
> OpenStack-based cloud is a crucial component that has been missing to 
> date and we have started working towards filling that gap.
> 
> OpenStack Watcher provides a flexible and scalable resource 
> optimization service for multi-tenant OpenStack-based clouds. 
> [...]

Please note that this project is not an official OpenStack project yet.
In particular, it's not been approved by the Technical Committee to join
the "big tent" yet, and it was actually never proposed there.

If you intend to propose this new project for inclusion, please propose
an openstack/governance change to that effect. You can find the current
project requirements at:

http://governance.openstack.org/reference/new-projects-requirements.html

In the mean time, please refrain from calling your project "OpenStack
Watcher". Thanks in advance!

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable] Need group membership change for manila-stable-maint

[Thierry Carrez]

Ben Swartzlander wrote:
> After reading the wiki it sounds like we cannot simply add the core team
> as an included group. I would need to request each core team member be
> added individually. Should I make requests for the individuals? Or
> should I wait until after Tokyo when some newer better process may
> emerge for managing the group membership?
> 
> My stance is that I want all of the manila core team to be stable
> maintainers too. Having 2 groups is unnecessary bureaucracy. However I'm
> willing to follow the established process if it's working well for
> everyone else.

Yeah, the extra step is to make sure people read and agree to the stable
branch policy. We have had people in the past that approved backports
they shouldn't have approved, and explained that they didn't know about
the policy. So we implemented a clear step where we point people to the
policy and ask them to agree to follow it...

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas driver writing

[Somanchi Trinath]

Hi –

Based on this “Assuming that, it will not be routing traffic, just filtering, 
and that we will be using virtual routers of Openstack”

As I understand from the email, you might be comfortable to configure the HW-FW 
using the ReST API. So you can write a proxy driver and connect the HW-FW in 
the setup (which you have tested to make it ready to use). The proxy driver 
written helps to Configure the HW-FW and the HW-FW filters the traffic.

Having said that, I assume that the HW-FW has some intelligence to process the 
requests from proxy driver and update the FW configuration.

*HW-FW – Hardware Firewall.

Hope this helps.

-
Trinath


From: Oğuz Yarımtepe [mailto:oguzyarimt...@gmail.com]
Sent: Monday, November 02, 2015 1:10 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron][fwaas]some architectural advice on fwaas 
driver writing

Hi,
After talking with FWaaS developers at the summit (German and Sridar), i 
decided to write here also, maybe someone has an idea. I am trying to integrate 
a hardware firewall to our Openstack environment. It is a custom hardware 
running BSD on it and has a REST API for configuring. I talked with Sridar, he 
gave me the brief understanding of how FWaaS driver is working.
Either i will be hacking the community driver and calling the REST API or 
writing the driver and calling the REST API there. The problem is, we couldn't 
figured it out how will the hardware firewall be working. Assuming that, it 
will not be routing traffic, just filtering, and that we will be using virtual 
routers of Openstack, do you have a reference architecture for such a case? It 
seems everyone has its own way of using firewall appliances in OpenStack. All i 
need is to create a firewall but instead of using Iptables, i want to use the 
hardware firewall and be able to define filtering rules.
FWaaS guys said that there will be API changes in the future so at Mitaka, it 
seems the way of FWaaS will be changing and there are some plans about merging 
FWaaS and security groups.
I am now using Kilo, the solution also will be working at Liberty also. Will be 
great if you give some guidance.
Regards.

--
Oğuz Yarımtepe
http://about.me/oguzy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Evgeniy L]

Hi,

The main reason why I think we should get all of the three states is we
don't know exactly if those plugins (which developer didn't specify) are
compatible or not, so we should not make any assumptions and prevent
the user from enabling any plugins she/he wants. The best we can do here
is to provide all of the information plugin developer knows, directly to
the user,
without us in the middle who make decisions based on incomplete data.

So lets ask plugin developer to specify a set of components which he tested
his plugin with. Plus a list of components which he tested with and he is
sure
that those are not going to working together.

On UI we can show explicitly, that this combination is tested and approved
to
be working, another combination is not working for sure (plugin developers
tested
it and explicitly specified), and there will be a lot of combination which
are going
to work together without problems, but we should say the user, that the
developer
didn't test it and he should test and use it carefully.

Thanks,

On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
wrote:

> Hi fuelers,
>
> Currently we are working on feature component registry [1] which should
> help us to prevent not logical compositions of different components in
> wizard tab during cluster(environment) creation. Now we have a mechanizm
> of 'restrictions' which is not flexible for components provided by
> plugins. In our current approach we have two states for components -
> compatible/incompatible which are described in compatibility matrix
> based on OpenStack components (For example: cinder-vmware storage only
> compatible with vCetner hypervisor and should work when only KVM uses).
> In this case we allow user to choose only that components we defently
> know works well with each other. Another approach tell us to have 3
> states: compatible/incompatible/ and all other components about
> compatibility with others we know nothing. In that case we should show
> on wizard which components compatible, which not, and others which user
> can enable on his own risk. So I need your opinions: should we allow for
> user choose only that coponents which are tested and defently works or
> prevent her/him from choosing which are defently not works and means
> potentional risk of failing deployment when component about we know
> nothing isn't work together.
>
>
>
> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Plugins][UX] Component registry

[Andriy Popovych]

Hi fuelers,

Currently we are working on feature component registry [1] which should
help us to prevent not logical compositions of different components in
wizard tab during cluster(environment) creation. Now we have a mechanizm
of 'restrictions' which is not flexible for components provided by
plugins. In our current approach we have two states for components -
compatible/incompatible which are described in compatibility matrix
based on OpenStack components (For example: cinder-vmware storage only
compatible with vCetner hypervisor and should work when only KVM uses).
In this case we allow user to choose only that components we defently
know works well with each other. Another approach tell us to have 3
states: compatible/incompatible/ and all other components about
compatibility with others we know nothing. In that case we should show
on wizard which components compatible, which not, and others which user
can enable on his own risk. So I need your opinions: should we allow for
user choose only that coponents which are tested and defently works or
prevent her/him from choosing which are defently not works and means
potentional risk of failing deployment when component about we know
nothing isn't work together.



[1] https://blueprints.launchpad.net/fuel/+spec/component-registry

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

[Daniel Mellado]

Also you could set up this var

LOGDAYS=1

to limit the amount of log, althougt setting the LOGDIR to /dev/null
should work too.

Cheers

Daniel

El 02/11/15 a las 04:12, Davanum Srinivas escribió:
> Sean,
>
> I typically switch off screen and am able to redirect logs to a
> specified directory. Does this help?
>
> USE_SCREEN=False
> LOGDIR=/opt/stack/logs/
>
> thanks,
> dims
>
> On Mon, Nov 2, 2015 at 4:43 AM, Sean M. Collins  > wrote:
>
> Hi,
>
> The docs right now are a little unclear about if it is possible to
> stop
> logging the output of all the screen sessions to the local filesystem.
> It has a tendency to fill up my filesystem on my little NUCs :(
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Davanum Srinivas :: https://twitter.com/dims
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Kashyap Chamarthy]

On Sat, Oct 31, 2015 at 09:11:31AM +0900, Davanum Srinivas wrote:
> Matt,
> 
> 0.6.0 and 0.7.0 were released for Mitaka! not Liberty. Though yes, because
> of not having pins any library we release for Mitaka will end up being used
> with Liberty as well.
> http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html
> 
> No, we are not reverting. Here's my current thought as a review:
> https://review.openstack.org/#/c/240371

Sigh, I was already worrying if this was going to break some tooling
somewhere.

Thanks, Dims for the quick response, and Matt for spotting it.

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Policy][Group-based-policy] Service chain node creation fails

[NareshA kumar]

Hi Sumit,
Thanks for your response. I am just trying to create a VM as a dumb
firewall. Attached the template file for your reference.

Regards,
Naresh

On Mon, Nov 2, 2015 at 1:34 PM, Sumit Naiksatam 
wrote:

> Hi Naresh,
>
> Please send me the your template file in response to this email, I can
> take look.
>
> Thanks,
> ~Sumit.
>
> On Sun, Nov 1, 2015 at 10:26 PM, NareshA kumar
>  wrote:
> > Hi,
> > When I try to create a Service chain node by giving the yaml file as heat
> > template it says "Invalid file format". But with the same file I am able
> to
> > create a stack using "heat stack-create"  command.
> >
> > What am I missing here?
> > Is there is any log file that can provide me the details of my error?
> >
> > Anyone please help me . I am stuck here for a long time.
> >
> > Regards,
> > Naresh.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>


fw.yaml
Description: application/yaml
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Policy][Group-based-policy] Service chain node creation fails

[Sumit Naiksatam]

Hi Naresh, I can try and help you with this. Can you unicast the file to me?

Thanks,
~Sumit.

On Sun, Nov 1, 2015 at 10:26 PM, NareshA kumar
 wrote:
> Hi,
> When I try to create a Service chain node by giving the yaml file as heat
> template it says "Invalid file format". But with the same file I am able to
> create a stack using "heat stack-create"  command.
>
> What am I missing here?
> Is there is any log file that can provide me the details of my error?
>
> Anyone please help me . I am stuck here for a long time.
>
> Regards,
> Naresh.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev